ITシステムと冗長化を取り巻く上状況

クラウドサービスの業務利用が本格化した近年においても、ITシステムと冗長化は切っても切り離せない概念です。オンプレミス環境において、機器の故障や過剰な負荷に備えた冗長構成は、ハードウェアの調達や人的リソースを必要とし導入・運用コストが高いものでした。 しかし近年、クラウドインフラサービスが普及したことによって、比較的手軽に冗長構成を実現することができるようになりました。 クラウド環境では、用途に合わせた柔軟なサーバサイジングが可能かつ、クラウンドベンダーが予め用意した多種多様なサービスを使用することができます。もちろん、その使用はクラウドベンダーが提供するサービスの範囲内に制限されるため、ユーザーは必要な要件を満たしたサービスを選択する必要があります。 今回は、クラウド環境で冗長化を実現するサービスの一つとして、Google Cloudの提供するCloud Load Balancingについて紹介いたします。Cloud Load Balancingは、Googleが提供するGoogle検索やGmailといったサービスと同等の高性能かつ低レイテンシの負荷分散を、低コストで利用できるサービスです。 記事の前半はCloud Load Balancingの概要を、後半ではCloud Load Balancingの設定方法を画像とともに解説いたしますので、是非ご覧ください。 > Google Cloud 運用監視 – 代行サービス 詳細はこちら > クラウドの利用料を6%OFF！JIG-SAW Prime

簡単に高可用性を実現！　Cloud Load Balancingとは？

ロードバランサは、外部からのアクセスなどによって生じる負荷を、事前に設定したルールに従い複数のサーバに振り分ける装置です。これにより、過負荷によってトラブルが起こりうるリスクを低減させるほか、メンテナンスや障害などで利用できないサーバをチェック・分散対象から外すことにより、システムの可用性維持に役立ちます。 Google Cloudの提供するロードバランシングサービス「Cloud Load Balancing（クラウドロードバランシング）」では、上記に加え以下のような特徴があります。

• Googleサービスと同等のインフラストラクチャを利用することで、毎秒 100 万件以上のクエリに対応
• エニーキャストIPアドレスをフロントエンドとすることにより、リージョンを跨った負荷分散と低レイテンシを実現
• ソフトウェアベースのロードバランサであるため、リソースの制限を受けない
• 自動スケーリングにより、トラフィックの増減に合わせた対処が可能
• 様々な要件に対応した多種多様なロードバランサを実装（L4/L7、内部負荷分散/外部負荷分散、マルチリージョン/シングルリージョン、プロキシ/パススルーetc…）

外部 HTTP(S) ロードバランサの特徴

今回検証で使用する外部 HTTP(S) ロードバランサは、プロキシベースのレイヤ7負荷分散です。外部 HTTP(S) ロードバランサを使用することで、クライアントからのアクセスを複数のリージョンに配置したバックエンドに分散させることが可能です。 また、Google Cloud Armorを併用することで、分散型サービス拒否攻撃（DDoS）などの標的型攻撃からの防御やIPアドレスの制限が可能となります。

検証：Webアプリに外部HTTP(S) ロードバランサを設定してみた

前提

今回検証として作成する環境は、フロントエンドで設定するIPアドレスにアクセスすると、各リージョンに配置されたインスタンスグループのインスタンスにトラフィックが割り振られるというシンプルな構成です。 今回の検証では、従来のHTTP（S）ロードバランサを使用しています。

バックエンドの構成

「バックエンドの構成」では、トラフィックを割り振るバックエンドを設定します。 バックエンドには、同じくGoogle Cloudが提供するCloud Storage上に配置したバックエンドバケットか、本項で作成するバックエンドサービスを選択します。 バックエンドサービスでは、以下のバックエンドタイプを選択することができます。

• インスタンスグループ
• GCE&CKEバックエンド
• 外部バックエンド
• App Engine, Cloud Run, Cloud Functions

今回は、バックエンドタイプで「インスタンスグループ」を選択し、東京リージョンとトロントリージョンに配置された２つのインスタンスグループを含むバックエンドサービス「demo-backend」を作成しました。 またこの時、「ヘルスチェック」を設定することで、バックエンドの死活監視が可能です。 条件を満たさないバックエンドは何らかの異常があると判定し、トラフィックを振り分けないようにします。これにより、いずれかのバックエンドで何らかの異常があった場合も、クライアントは正常なバックエンドにアクセスすることができます。 ヘルスチェックを設定する場合は、後述の「ファイアウォールルールの作成」にて、Google Cloudプローバーからのトラフィックを許可する必要があることにご注意ください。 今回は、5秒間に一度各バックエンドにトラフィックを送信するヘルスチェック「demo-health-check」を作成しました。

ホストとパスのルール

「ホストとパスのルール」は、フロントエンドで設定するIPアドレスとバックエンドを紐付ける設定です。 クライアントからのリクエストのパスにより、どのバックエンドにトラフィックを割り振るかという条件を設定します。 HTTP ロードバランサの転送ルールではTCPポート80と8080のみを、HTTPSロードバランサの転送ルールではTCP ポート443のみを参照します。 今回は、全てのホスト・全てのリクエストを前項で作成したバックエンドサービス「demo-backend」に割り振るよう設定しました。

フロントエンドの構成

「フロントエンドの構成」では、作成したロードバランサに対しクライアントがアクセスする際のIP アドレス、ポート、プロトコルを指定します。 本項で設定するIP アドレスが、クライアントがアクセスするグローバルIPアドレスとなります。事前に静的IPアドレスを取得している場合は、IPアドレス欄より選択可能です。 HTTPSロードバランサを作成する場合は、プロトコルで「HTTPS（HTTP/2を含む）」を選択し、証明書を作成する必要があります。 今回はプロトコルで「HTTP」を選択し、IPアドレスを「エフェメラル」としたフロントエンド「demo-frontend」を作成しました。

ファイアウォールルールの作成

本項はGoogle Cloud の「ロードバランサの作成」には存在しませんが、「バックエンドの構成」でヘルスチェックを作成した場合は必要な設定です。 ヘルスチェックを機能させるために、VPCネットワーク＞ファイアウォールより、Google Cloud プローバーからのバックエンドへの上り（内向）のトラフィックを許可するファイアウォールルールを作成します。

結果

これで設定は完了です。最終的な各項の設定は、以下になります。 では、ロードバランサが無事起動したことを確認し、フロントエンドで設定したIPアドレスにアクセスしてみましょう。 最寄りの東京リージョンの配置されたバックエンドにアクセスすることができました。 次に、東京リージョンに配置されたバックエンドのインスタンスを停止し、再度同じIPアドレスにアクセスしてみました。 すると、現在正常なトロントリージョンに配置されたバックエンドにアクセスが割り振られました。 このように、外部HTTP(S)ロードバランサを設定することで、いずれかのバックエンドで異常が起きた場合も、クライアントは正常なバックエンドにアクセスすることが可能となります。 > Google Cloud 運用監視 – 代行サービス 詳細はこちら > クラウドの利用料を6%OFF！JIG-SAW Prime

終わりに

今回は、Google Cloud上にWebアプリケーションを作成し、外部HTTP(S) ロードバランサの設定方法を紹介いたしました。 冗長構成には必要不可欠なロードバランサは、Google Cloud ではCloud Load Balancingの利用で簡単に設定することができます。今回紹介した外部HTTP(S)ロードバランサの他にも、Google Cloudには多種多様なロードバランサが用意されていますので、是非ご活用ください。 最後に、当社ではGoogle Cloudの利用料が6％OFFになる 請求代行サービス や、 システムの監視運用サービスをご提供しております。ご興味がございましたら、ぜひご相談ください。さいごまでお読みいただきありがとうございました。