GCE でクロスリージョン+オートスケーリング 第三回
"バックエンドサービス" の作成
"バックエンドサービス" は，その中に "インスタンスグループ" と関連する "バックエンド"が含まれます。またその役割には，インスタンスに対するヘルスチェックの設定やセッションパーシステンスの設定，CDN の利用有無等があります。以下，このような "バックエンドサービス" を作成していきます。
"ヘルスチェック" の作成
"ヘルスチェック" のルールを個別のオブジェクトとして作成します。この作成した "ヘルスチェック" を，後に "バックエンドサービス" にアタッチします。これは複数のバックエンドサービスからアタッチすることができます。
"ヘルスチェック" のルールには，モニタする URL のパスやポート番号，チェック間隔，タイムアウト値等が含まれます。今回はチェックする URL のみ指定し，その他はデフォルトとします。また，"ヘルスチェック" を含む "負荷分散(ロードバランサ)" サービスからのリクエストをインスタンスが受け取れるようにするため，ファイアウォールルールも設定します。
- site1 への "ヘルスチェック" を作成
site1 では，チェックする URL を /site1/index.txt にします。ヘルスチェック名を「mygce-site1-health-check」とします。 - site2 への "ヘルスチェック" を作成
site1 では，チェックする URL を /site2/index.txt にします。ヘルスチェック名を「mygce-site2-health-check」とします。 - "ファイアウォールルール"
"負荷分散(ロードバランサ)" サービスは，130.211.0.0/22 がソース IP アドレスとなります(このレンジについては，ここの「ヘルスチェックのソース IP とファイアウォール ルール」節をご覧ください)。これから 80 番ポートへのアクセスを下記コマンドで許可します。ファイアウォール名は「mygce-firewall-healthcheck」としました。
$ gcloud compute http-health-checks create mygce-site1-health-check \
--request-path "/site1/index.txt"$ gcloud compute http-health-checks create mygce-site2-health-check \
--request-path "/site2/index.txt"$ gcloud compute firewall-rules create mygce-firewall-healthcheck \
--source-ranges '130.211.0.0/22' \
--allow tcp:80site1 の "バックエンドサービス" の作成
- site1 の "バックエンドサービス" の作成
セッションパーシステンスを一般的によく使われる cookie ベースとし，ヘルスチェックを上記で作成した「mygce-site1-health-check」に設定した "バックエンドサービス"「mygce-site1-bs」を作成します。 - "バックエンドサービス" に "バックエンド" を追加
「mygce-site1-bs」に，前回作成した site1 の「mygce-site1-ig-asia」「mygce-site1-ig-us」の 2 つの "バックエンド" を追加します。
$ gcloud compute backend-services create mygce-site1-bs \
--session-affinity generated_cookie \
--http-health-checks mygce-site1-health-check \
--global$ gcloud compute backend-services add-backend mygce-site1-bs \
--instance-group mygce-site1-ig-asia \
--instance-group-zone asia-east1-b \
--global
$ gcloud compute backend-services add-backend mygce-site1-bs \
--instance-group mygce-site1-ig-us \
--instance-group-zone us-east1-b \
--globalsite2 の "バックエンドサービス" の作成
- site2 の "バックエンドサービス" の作成
セッションパーシステンスを一般的によく使われる cookie ベースとし，ヘルスチェックを上記で作成した「mygce-site2-health-check」に設定した "バックエンドサービス"「mygce-site2-bs」を作成します。 - "バックエンドサービス" に "バックエンド" を追加
「mygce-site2-bs」に，前回作成した site2 の「mygce-site2-ig-asia」「mygce-site2-ig-us」の 2 つの "バックエンド" を追加します。
$ gcloud compute backend-services create mygce-site2-bs \
--session-affinity generated_cookie \
--http-health-checks mygce-site2-health-check \
--global$ gcloud compute backend-services add-backend mygce-site2-bs \
--instance-group mygce-site2-ig-asia \
--instance-group-zone asia-east1-b \
--global
$ gcloud compute backend-services add-backend mygce-site2-bs \
--instance-group mygce-site2-ig-us \
--instance-group-zone us-east1-b \
--global"URL マップ" の作成
URL マップは，まずその本体を作成しその後にマッピングを設定します。今回は下記のルールで URL マップを作成します
- mygce.fatriver.net というホストへのリクエストのみ下記ルールで振り分ける
- /site1 から始まるパス → 「mygce-site1-bs」バックエンドサービスに振り分け
- /site2 から始まるパス → 「mygce-site2-bs」バックエンドサービスに振り分け
- 上記以外のリクエストは「mygce-site1-bs」に振り分け。
上記ルールの URL マップを以下のように作成します。
- "URL マップの作成"
ここでは "URL マップ" の名前を「mygce-url-map」としています。 - "Path Matcher" 及び "Host Rules" の設定
"URL マップ" は "Path Matcher" と "Host Rules" という 2 つのコンポーネントで構成されます。"Path Matcher" は，URL のパスと "バックエンドサービス" のマッピングを定義するものです。"Host Rules" は，ホスト名と "Path Matcher" のマッピング定義です。今回はホスト名は「mygce.fastriver.net」のひとつなのでこれらを一回のコマンドで定義できます。
なお "Path Matcher" にも名前をつける必要があり，ここでは「mygce-path-matcher」としています。
$ gcloud compute url-maps create mygce-url-map \
--default-service mygce-site1-bs$ gcloud compute url-maps add-path-matcher mygce-url-map \
--default-service mygce-site1-bs \
--path-matcher-name mygce-path-matcher \
--path-rules /site1=mygce-site1-bs,/site1/*=mygce-site1-bs,/site2=mygce-site2-bs,/site2/*=mygce-site2-bs \
--new-hosts mygce.fastriver.net"ターゲットプロキシ" の作成
今回は HTTPS "ターゲットプロキシ" を利用します。HTTPS "ターゲットプロキシ" では SSL 終端処理を行うので，その作成の際に SSL 証明書を登録する必要があります。ちゃんとした証明書を持っていないのでオレオレを使います。関係ありませんが，よく会社でオレオレ証明書の作り方を聞かれるのですが，意外と openssl req 一発で作れることを知らない人がいるので，一応その作り方も書いておきます。
- オレオレ SSL 証明書の作成
秘密鍵を mygce.key, 証明書を mygce.crt として作成しています。作成した後，秘密鍵は暗号化されない生の状態にする必要があります。そのファイル名を mygce-nopass.key としています。 - "SSL 証明書リソース" の登録
上記で作成した SSL 証明書「mygce.crt」と秘密鍵「mygce.key」を "SSL 証明書リソース" として登録します。その名前を「mygce-cert」としています。 - "ターゲットプロキシ" の作成
上記で作成した "SSL 証明書リソース"「mygce-cert」と，"URL マップ" 「mygce-url-map」を使い "ターゲットプロキシ"「mygce-target-proxy」を作成します。
$ openssl req -x509 -newkey rsa:2048 -keyout mygce.key -out mygce.crt
$ openssl rsa -in mygce.key -out mygce-nopass.key # ← 秘密鍵のパスフレーズを解きます$ gcloud compute ssl-certificates create mygce-cert \
--certificate mygce.crt \
--private-key mygce-nopass.key$ gcloud compute target-https-proxies create mygce-target-proxy \
--ssl-certificate mygce-cert \
--url-map mygce-url-map"グローバル転送ルール" の作成
最後に，フロントエンドの役割を受け持つ "グローバル転送ルール" を作成します。これは，待ち受けポートの定義やグローバル IP アドレスの保有有無等を定義します。"グローバル転送ルール" はリージョンを意識しません。
- "グローバル転送ルール"の作成
"グローバル転送ルール"の名前を「mygce-forwarding-rule」とします。今回は HTTPS(443) ポートでのみ待ち受けます。
$ gcloud compute forwarding-rules create mygce-forwarding-rule \
--target-https-proxy mygce-target-proxy \
--global-address \
--global \
--ports 443
上記コマンドを実行すると，付与されたグローバル IP アドレスが表示されますので，それを A レコード(!! CNAMEでない)で DNS サーバに登録すれば完成です(とりあえずの確認であれば hosts ファイルに登録すれば十分です)。
今回私は，mygce.fastriver.net というホスト名で A レコードを登録しました。そして以下の URL にブラウザからアクセスしてみます。
今回私は，mygce.fastriver.net というホスト名で A レコードを登録しました。そして以下の URL にブラウザからアクセスしてみます。
- https://mygce.fastriver.net/site1/index.txt
- https://mygce.fastriver.net/site2/index.txt
というわけで，これでクロスリージョンの負荷分散かつオートスケーリングな Web サーバが出来上がりました。今回の例は本当に簡易的な構成ですので，実際の運用ではもっと複雑な要件があり，複雑な設定をすると思います。その際は gcloud コマンドのヘルプやら Google が提供するドキュメント等を参考にしてください。
ではさようなら。
ではさようなら。
GCE でクロスリージョン+オートスケーリング 第三回
0 件のコメント:
コメントを投稿