ロードバランサー比較（AWS、Azure、GCP）

GCP入門

Publish Date: 2019-07-04

Update Date: 2020-11-25

Word Count: 1.3k

Read Times: 6 Min

メンテナンスページ表示機能要件（詳細は後述参照）を満たせるかという視点で、各クラウド事業者（AWS、Azure、GCP）がサービスとして提供しているロードバランサーについて比較、検討してみました。

カテゴリ：GCP入門合わせて読みたい

1.メンテナンスページ表示機能要件

現在、オンプレ構成（Apacheサーバ、もしくはLBアプライアンス製品）で以下の要件を実現している。

メンテナンス時間帯になったら自動的にメンテナンスページを表示したい
　例えば、AM1時00分になったら、自動的にメンテナンスページに切り替わるようにし、AM1時30分になったら、自動的に本番公開ページを表示するということがしたい
メンテナンスページには「メンテナンス時間帯」を記載したい
　ただし「メンテナンス時間帯」は毎回変わるので、都度編集が必須である
SEO対策のため、応答コードは「200」ではなく「503」としたい
特定のIPアドレスだけからは、本番公開用ページを表示し続けたい

これらの要件をクラウド標準サービスで実現出来るのか、各社のサービス仕様を確認した。

2.AWSでの実現可否

2-1.メンテナンスページ表示の構成パターン

AWSでメンテナンスページを表示する方法として、以下の3点がある模様。いずれにしても、複数のサービスを組み合わせる形となる。

Route53 ＋ S3
CloudFront ＋ S3
Application Load Balancer（ALB）＋α

2-2.実現可否

上記の3パターンのうち、要件を満たせそうなのは「Application Load Balancer（ALB）＋α」となるが「＋α」を何にするかで変わる。
事例としては、「＋α」を「Lambda関数を呼び出してNode.jsで表示」にすれば出来そうな記事がヒットした。実際に試してないが、実現は出来そう。

2-3.参考：Application Load Balancer（ALB）

「Application Load Balancer」はAWSロードバランサーのうち、もっとも高機能グレードのようだ。
ALB単独でもSorryPage（簡易なもの）の表示が可能のようだ。WAF機能、認証機能などがアドオン出来そうで、パスベースのルーティング、ロードバランサー振り分け先として、VPC 外のターゲット（IP アドレス指定）を登録できるようだ。
HTTP ヘッダーベースのルーティングもサポートしているようなので、ユーザーエージェント判別で、サイト振り分けも可能かと思われる。
執筆時点で、ALBの料金は、東京リージョンで以下の価格となっていた。

S/M/LとWAF有無により　$18.0792/月　～　$353.204/月
データ処理　0.008USD／時間

3.Azureでの実現可否

3-1.メンテナンスページ表示の構成パターン

Azureでメンテナンスページを表示する方法として、以下の2点がある模様。いずれにしても、複数のサービスを組み合わせる形となる。

Traffic Manager ＋ Web Apps
Application Gateway ＋ Blob Storage

3-2.実現可否

上記の2パターンともに要件が満たせそう。cronサーバやjobサーバで上記の設定変更をするように組み込む必要があるが、実現はできると思われる。

3-3.参考：Application Gateway

「Application Gateway」は、AWS、Azure、GCPの3社の中では一番機能が豊富で柔軟性に使えそう。
AWSと同じく、WAF機能がアドオン出来そうで、URI パスやホストヘッダーなど、HTTP 要求の追加属性に基づいてルーティングを決定出来る模様。
最大で 100 の Web サイト（ドメイン）を 1 つのアプリケーションゲートウェイに追加でき、HTTP を HTTPS に自動的にリダイレクトされ、Cookie ベースのセッションアフィニティ機能もある。
カスタムエラーページを作成、HTTP ヘッダーを書き換えまで出来るようだ。
執筆時点で、Application Gatewayの料金は、東京リージョンで以下の価格となっていた。

S/M/LとWAF有無により　$19.71/月　～　$353.204/月
データ処理　$0.008/GB　～　$0.0035/GB

4.GCPでの実現可否

4-1.メンテナンスページ表示の構成パターン

情報量が少なく、事例が見当たらない状況だが、GCPでメンテナンスページを表示する方法として、以下の1点のみと思われる。

HTTP(S) 負荷分散 | Google Cloud Load Balancing ＋ α

4-2.実現可否

事例が少ないので、試行錯誤が必要と思われるが、要件は満たせそう。cronサーバやjobサーバで上記の設定変更をするように組み込む必要があるが、実現はできると思われる。

4-3.参考：HTTP(S) 負荷分散 | Google Cloud Load Balancing

「HTTP(S) 負荷分散 | Google Cloud Load Balancing」は、他の2社（AWS、Azure）とは違い、物理的なリージョンには紐づかない、完全に論理的なソフトウェアデザインロードバランサーである。
1 つのエニーキャスト IP アドレスが、世界中のリージョンに分散されたすべてのバックエンドインスタンスのフロントエンドアドレスとして機能し、CDN機能がアドオン出来る。
ロードバランサー機能としては非常にシンプルかつ明瞭。

執筆時点で、Cloud Load Balancingの料金は、種類を問わずすべて同じ価格となっており、以下の価格となっていた。
他の2社（AWS、Azure）と同様、時間単価、データ処理量単価に基づいて料金が計算される

時間単価
　最初の 5 つの転送ルール $0.025 1 時間あたり　月あたり18.6ドル
　追加の転送ルール 1 つあたり $0.010 1 時間あたり　月あたり7.44ドル
データ処理量単価
　ロードバランサで処理された上りデータ $0.008 GB 単位

5.まとめ

各社ともに共通して言えるのは、「メンテナンスページ表示機能」ではなく「Sorryページ表示機能」や「エラーページのカスタム表示機能」といったキーワードで検索すれば、調べたい記事がヒットした。
いずれも、1個のサービスのみでは実現が難しく、複数のサービスを柔軟に組み合わせて要件を達成する必要がある。
特に「メンテナンス時間帯」の指定については、スクリプトやバッチ等で作りこむことが前提となる。
「URLPATH」によるサーバ振り分け機能は、すべてのサービスで標準機能として実装されているが、「ユーザエージェント」によるサーバ振り分け機能は、ニーズが少ないのか、AWS、Azureで明言はされていないが出来そう。
なお、いずれのサービスにおいても、ストレージサービスをウェブサーバ代わりに使うことが可能だが、ステータスコードの処理については考慮が必要。