
Cloud Load BalancingでWebアプリにロードバランサを設定【外部 HTTP(S) 編】
ITシステムと冗長化を取り巻く上状況

クラウドサービスの業務利用が本格化した近年においても、ITシステムと冗長化は切っても切り離せない概念です。オンプレミス環境において、機器の故障や過剰な負荷に備えた冗長構成は、ハードウェアの調達や人的リソースを必要とし導入・運用コストが高いものでした。
しかし近年、クラウドインフラサービスが普及したことによって、比較的手軽に冗長構成を実現することができるようになりました。
クラウド環境では、用途に合わせた柔軟なサーバサイジングが可能かつ、クラウドベンダーが予め用意した多種多様なサービスを使用することができます。もちろん、その使用はクラウドベンダーが提供するサービスの範囲内に制限されるため、ユーザーは必要な要件を満たしたサービスを選択する必要があります。
今回は、クラウド環境で冗長化を実現するサービスの一つとして、Google Cloudの提供するCloud Load Balancingについて紹介いたします。Cloud Load Balancingは、Googleが提供するGoogle検索やGmailといったサービスと同等の高性能かつ低レイテンシの負荷分散を、低コストで利用できるサービスです。
記事の前半はCloud Load Balancingの概要を、後半ではCloud Load Balancingの設定方法を画像とともに解説いたしますので、是非ご覧ください。
なぜ冗長化が必要なのか
クラウド環境を冗長化することが求められるのには、いくつかの理由があります。最大の理由は、耐障害性を確保することです。システムにトラブルが発生した場合も、すぐに予備のシステムへと切り替えることで、業務上の機会損失の発生を最小限に抑えることができます。
冗長化を行っていないと、復旧するまで業務を進めることができず、丸ごと損失となってしまいます。このような事態を回避できるのが、冗長化の強みです。
また、障害の発生を未然に防ぐという意味でも冗長化は有効です。何らかの事情でアクセスが増加しサーバーの負荷が増えた時や、サイバー攻撃を受けた場合にも、冗長化されていればサーバーダウンの事態を回避できます。
ロードバランサーの役割
冗長化を検討する上で、重要な役割を担うのがロードバランサーです。ロードバランサーは、サーバーに発生する負荷を分散させて小さくすることができます。
大量のアクセスが一つのサーバーに発生した場合でも、外部からのトラフィックを仮想IPアドレスに対して一度アクセスさせ、余裕を持ってサーバーへアクセスできるよう整理してくれます。
ロードバランサーを実装すれば、サーバーの安定したパフォーマンスを常に維持できるのはもちろん、メンテナンス時にサービスを維持したり、ダウンしたサーバーを避けてユーザーを案内したりが可能です。
簡単に高可用性を実現! Cloud Load Balancingとは?

ロードバランシングをクラウドで利用できるサービスに、Google Cloudの提供す「Cloud Load Balancing(クラウドロードバランシング)」が挙げられます。
Googleサービスと同じインフラストラクチャの利用により、毎秒100万件を超えるクエリに対応できたり、リージョンを跨った負荷分散や、低レイテンシーを実現できるのが特徴です。
また、ソフトウェアベースで動作するロードバランサーであるため、リソースの制限は受けません。トラフィックの状況に応じた自動スケーリングにも対応し、高い柔軟性を備えます。
外部 HTTP(S) ロードバランサの特徴

今回検証で使用する外部 HTTP(S) ロードバランサは、プロキシベースのレイヤ7負荷分散です。外部 HTTP(S) ロードバランサを使用することで、クライアントからのアクセスを複数のリージョンに配置したバックエンドに分散させることが可能です。
Cloud Load Balancingでは、HTTP(S)トラフィックを扱うApplication Load BalancerとTCP/UDPのトラフィックを担当するNetwork Load Balancerに分類されます。状況に応じて、これらを使い分けることが求められます。
また、Google Cloud Armorを併用することで、分散型サービス拒否攻撃(DDoS)などの標的型攻撃からの防御やIPアドレスの制限が可能となります。Cloud Armorは、フルマネージド対応のWAFです。Cloud Load Balancingの後ろにあるWebアプリケーションを保護できる機能を備えているため、優れた併用効果が期待できるでしょう。
検証:Webアプリに外部HTTP(S) ロードバランサを設定してみた
前提
今回検証として作成する環境は、フロントエンドで設定するIPアドレスにアクセスすると、各リージョンに配置されたインスタンスグループのインスタンスにトラフィックが割り振られるというシンプルな構成です。
今回の検証では、従来のHTTP(S)ロードバランサを使用しています。

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

今回は、バックエンドタイプで「インスタンスグループ」を選択し、東京リージョンとトロントリージョンに配置された2つのインスタンスグループを含むバックエンドサービス「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上にWebアプリケーションを作成し、外部HTTP(S) ロードバランサの設定方法を紹介いたしました。冗長性の確保は、サーバーの安定性や、障害対策を徹底する上で重要な取り組みです。
冗長構成には必要不可欠なロードバランサは、Google Cloud ではCloud Load Balancingの利用で簡単に設定することができます。状況に応じてGoogle Cloud Armorも併用すれば、より高度なセキュリティ体制を整えられるでしょう。今回紹介した外部HTTP(S)ロードバランサの他にも、Google Cloudには多種多様なロードバランサが用意されていますので、是非ご活用ください。
最後に、当社ではGoogle Cloudの利用料が6%OFFになる 請求代行サービス や、 システムの監視運用サービスをご提供しております。ご興味がございましたら、ぜひご相談ください。さいごまでお読みいただきありがとうございました。