東京リージョンリリースの噂があった頃からGCPをちょっとだけ触っていたのですが、業務も含めメインはAWSでした。
この度GCP検証でまとまった時間が取れたため、初投稿となりますが以下に記載させて頂きます。
マサカリはやさしく投げてくださいｗ
クラウドはAWSの方が長く触っていることもあり、GCPでのHTTP(S)ロードバランサー構築に必要な工程をAWSでのALB/CLB構築工程に当てはめて記載しました。
なお、構築する中でAWSで言うところのAutoScalingの設定も必要だったのでまとめて記載します。(1.～5.)
そして、リージョン超えロードバランシングはGCPにしか出来ない機能なので重点的に記載します。(6.以降～)
※あらかじめVMインスタンスがある前提です。
1.～5.の工程まで『Google Compute Engine(GCE)』内での操作になります。
下記の手順は、4.インスタンステンプレートの作成時に起動イメージを指定するのですが、
前工程として1～3が必要となっています。
1.スナップショット取得
AWSでは可能な3.のイメージ作成を最初から取得できれば良いのですが、GCPでは2.のディスク作成、またそのためにスナップショット取得が必要になります。最終的に各リージョンで起動させたいVMインスタンスのスナップショットを取得しましょう。
2.ディスク作成
続いてディスクの作成です。
先ほど取得したスナップショットを[ソースの種類]>[ソーススナップショット]を選択した後に、[ソース スナップショット]から指定します。
※お気づきの方もいらっしゃると思いますが、左欄の[ディスク]をクリックすると先ほどスナップショットを取得したVMインスタンスのディスクが既にあります。後述するのですが、ワケあってこの工程を実施しています。
※また、ゾーンの指定があるのですがここは何を選んでも大丈夫なのでは、、と思っています。念のためVMインスタンスと同じリージョンにしました。
3.イメージ作成(AWSでのAMI取得と同義)
はい、やっとここまで来ました。
ここで2.で作成したディスクを指定するのですが、注意書きで『VMインスタンスに関連付けられているディスクからイメージを作成することはできません』と書かれている通り、2.でディスクを明示的に作成しなかったものは選択できません。
この辺はAWSのAMI取得と大きな違いがあると思いました。
※ソースの指定で[CloudStorageファイル]を指定することもできるのですが、こちらはまだ試していません。。
4.インスタンステンプレート(AWSでのAutoScalingの起動設定と同義)
余計な切り分けポイントを増やさないために権限はゆるゆるにしました。(たいしたデータ入ってないし大丈夫、大丈夫ｗ)
下部の[管理、ディスク、ネットワーキング、SSH 認証鍵]もデフォルトでOKです。
※外部IPが自動で割当らなかったらすいません。エフェメラルになっていればOKです。
ブートディスクの指定は以下のようになります。ここで3.にて作成したイメージを指定します。
5.インスタンスグループ作成(AWSでのAutoScalingグループ設定と同義)
最後に4.で作成したインスタンステンプレートをインスタンスグループに割り当てます。
実は、[既存のインスタンスを選択]という選択肢もあるのですが、こちらをクリックすると「使用できるインスタンスがありません」と出力されるので[インスタンステンプレートを使用]を選んだという背景があります。
※マルチゾーンを選択するとリージョン内で各ゾーンに分散可能です。(AWSで言うところのAZ)
東京リージョンはa,b,cの3つのゾーンがあります。(AWSの東京リージョンのAZはa,cの2つ)
まだ続きがあって、自動スケーリングの台数や閾値指定など色々あるのですが、リージョン超えロードバランシングの確認には支障が無いものの、今後の負荷試験を考慮してオンにしました。
インスタンスの最小値、最大値を1にしておけば台数が増えて料金がかかるといったことも発生しません。
※負荷試験の際は最大値を増やしていきます。
ヘルスチェックも中身はデフォルトです。
そうすると値が厳しすぎると注意書きが出てきたので指定値に合わせました。
VMインスタンス画面に自動でインスタンスが立ち上がっていればOKです。
インスタンス名の末尾にランダムで文字列入ります。
6.HTTP(S)ロードバランサー構築
やっとタイトルの登場です。
ここからは『ネットワーキング』内での操作になります。
負荷分散の中にもTCP負荷分散やUDP負荷分散がありますが、HTTP(S)負荷分散を選択します。
(いわずもがなですが、、)
この3つを作成しないと最終的に機能しません。
6-1.バックエンドの設定
ロードバランサー配下の転送先になります。5.で作成したインスタンスグループを選択します。
ここではリージョン超え分散を実現するために、tokyoとus-eastのインスタンスグループを紐付けました。
(ずっとtokyoという名前で記述しておりましたが、us-eastというものも同様に作成しております。)
6-2.ホストのパスとルール
ロードバランサーに払い出される一つのIPアドレスに対して、柔軟に設定することが可能でした。
■異なるURLに対してそれぞれのバックエンドに振り分ける(VirtualDomain的な動き)
tokyo.ほげほげ.com➝バックエンド：http-tokyo
us-east.ほげほげ.com➝バックエンド：http-us-east
■同じURLに対してパスを指定することにより、それぞれのバックエンドに振り分ける(AWSのALB的な動き)
test.ほげほげ.com/tokyo/* ➝バックエンド：http-tokyo
test.ほげほげ.com/us-east/* ➝バックエンド：http-us-east
あとは、どれにも一致しなかった時のバックエンドも指定できます。(デフォルトで存在します。)➝バックエンド：http-tokyo
設定は、こんな感じになります。
ひとつ想定外だったのが、同じURL・同じパスに対してリージョン間で分散するためのバックエンド設定ができなかったこと。(設定入れると怒られました。。)
が、これも得た情報だと指定したリージョンで処理できなくなったら、よしなに他リージョンに転送してくれる、もしくは近いリージョンを判断して転送してくれるとか・・今後の負荷試験が楽しみです。
【2/3追記】
完全に誤ってました。↑の設定は可能です！！
私が設定できない！と記載していた原因は、バックエンドの設定を個別に作成していて(http-tokyoやhttp-us-east)、同じURL・パスに対して、2つのバックエンドの設定をぶら下げようとしていたからでした。。orz
なので、同じバックエンドの設定で(下記の例だとhttp-api)配下に2つのインスタンスグループ(instance-group-tokyo,instance-group-us-east)を指定すれば設定可能でした。(http-webも同様の設定です。)
※(2017/02/03)
バックエンドの設定画面で『バックエンドバケットを作成または選択』が設定できるようになってました。
GCSの静的コンテンツを指定する際に利用するのかなと思います。(余談です。)
ということで以下の設定が可能となりました。
これで、test.ほげほげ.com/* や/web/* , /api/* というアクセスをすれば、
tokyoリージョンに近ければ ➝バックエンド：http-tokyoに
us-eastリージョンに近ければ➝バックエンド：http-us-eastになるはずです。(動作確認結果は、7-1.)
6-3.フロントエンドの設定
こちらはロードバランサーのインターネット側の設定です。デフォルトでOKです。
※HTTPSを使用したい場合は証明書の用意が必要です。
グローバルIPが払い出されますので、上記URLのAレコード追加の際に必要になるため控えておきましょう。
7.リージョン超えロードバランシング動作確認
実際にやってみた
※アクセスログを見るとなお良し。
tokyo.ほげほげ.com→バックエンド：http-tokyo
us-east.ほげほげ.com→バックエンド：http-us-east
test.ほげほげ.com/tokyo/* →バックエンド：http-tokyo
test.ほげほげ.com/us-east/* →バックエンド：http-us-east
どれにも一致しなかった時
全て想定通りの動きになりましたね！
1つのロードバランサーで複数のリージョンに分散できることが確認できました。
7.1リージョン超えロードバランシング動作確認(その2)
アクセス元の確認と、手間を省くためcurlで確認しました。
■asia-east(台湾)リージョンからのアクセス
[XXX@instance-asia-east ~]$ curl "http://metadata.google.internal/computeMetadata/v1/instance/zone" -H "Metadata-Flavor: Google"
projects/xxxxxxxxxxxx/zones/asia-east1-b
[XXX@instance-asia-east ~]$ curl http://test.ほげほげ.com/
This is Tokyo page.
■us-west(オレゴン)リージョンからのアクセス
[XXX@instance-us-west ~]$ curl "http://metadata.google.internal/computeMetadata/v1/instance/zone" -H "Metadata-Flavor: Google"
projects/xxxxxxxxxxxx/zones/us-west1-b
[XXX@instance-us-west ~]$ curl http://test.ほげほげ.com/
This is US-east page.
できました。。
やっとやりたいことができました。
これができればかなり実用的ですし、あとは負荷試験次第です。
※負荷をかける側の準備で手間取ってます。。
<所感>
ロードバランサーに割り当てられるIPアドレスたった1つでさまざまな処理をしていることから
どこまで負荷に耐えられるか非常に気になります。
ということで、次回はHTTP(S)ロードバランサーに高負荷をかけた時の検証結果を記載予定です。
AWSのロードバランサー(ALB/ELB)の場合、スケールアウトするのに時間がかかるため、
GCPのHTTP(S)ロードバランサーが1つでどれだけ処理できるのか検証結果が楽しみです。
(100万/秒処理できるんだとか！？)
https://cloudplatform.googleblog.com/2013/11/compute-engine-load-balancing-hits-1-million-requests-per-second.html
【誤字脱字修正】
・エフェラメル→エフェメラル
・VirtualServer→VirtualDomain
・2つ目の動作確認画面
test.ほげほげ.com/us-east/* →バックエンド：http-us-east
↓
us-east.ほげほげ.com→バックエンド：http-us-east
(2017/2/3)
・バックエンド設定全般の修正