Ryo's Page

GCE でクロスリージョン+オートスケーリング第三回

前回までで，バックエンドとなる "インスタンスグループ" の作成が完了しました。これは，2 つのリージョンを跨る負荷分散を意識し，かつ "自動スケーリング" が可能な構成になっています。今回はこの続きで，"負荷分散(ロードバランサ)" の部分を作成していきます。

"バックエンドサービス" の作成

"バックエンドサービス" は，その中に "インスタンスグループ" と関連する "バックエンド"が含まれます。またその役割には，インスタンスに対するヘルスチェックの設定やセッションパーシステンスの設定，CDN の利用有無等があります。以下，このような "バックエンドサービス" を作成していきます。

"ヘルスチェック" の作成

"ヘルスチェック" のルールを個別のオブジェクトとして作成します。この作成した "ヘルスチェック" を，後に "バックエンドサービス" にアタッチします。これは複数のバックエンドサービスからアタッチすることができます。

"ヘルスチェック" のルールには，モニタする URL のパスやポート番号，チェック間隔，タイムアウト値等が含まれます。今回はチェックする URL のみ指定し，その他はデフォルトとします。また，"ヘルスチェック" を含む "負荷分散(ロードバランサ)" サービスからのリクエストをインスタンスが受け取れるようにするため，ファイアウォールルールも設定します。

site1 への "ヘルスチェック" を作成

site1 では，チェックする URL を /site1/index.txt にします。ヘルスチェック名を「mygce-site1-health-check」とします。

$ gcloud compute http-health-checks create mygce-site1-health-check \
  --request-path "/site1/index.txt"

site2 への "ヘルスチェック" を作成

site1 では，チェックする URL を /site2/index.txt にします。ヘルスチェック名を「mygce-site2-health-check」とします。

$ gcloud compute http-health-checks create mygce-site2-health-check \
  --request-path "/site2/index.txt"

"ファイアウォールルール"

"負荷分散(ロードバランサ)" サービスは，130.211.0.0/22 がソース IP アドレスとなります(このレンジについては，ここの「ヘルスチェックのソース IP とファイアウォールルール」節をご覧ください)。これから 80 番ポートへのアクセスを下記コマンドで許可します。ファイアウォール名は「mygce-firewall-healthcheck」としました。

$ gcloud compute firewall-rules create mygce-firewall-healthcheck \
  --source-ranges '130.211.0.0/22' \
  --allow tcp:80

site1 の "バックエンドサービス" の作成

site1 の "バックエンドサービス" の作成

セッションパーシステンスを一般的によく使われる cookie ベースとし，ヘルスチェックを上記で作成した「mygce-site1-health-check」に設定した "バックエンドサービス"「mygce-site1-bs」を作成します。

$ gcloud compute backend-services create mygce-site1-bs \
  --session-affinity generated_cookie \
  --http-health-checks mygce-site1-health-check \
  --global

"バックエンドサービス" に "バックエンド" を追加

「mygce-site1-bs」に，前回作成した site1 の「mygce-site1-ig-asia」「mygce-site1-ig-us」の 2 つの "バックエンド" を追加します。

$ 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 \
  --global

site2 の "バックエンドサービス" の作成

site2 の "バックエンドサービス" の作成

セッションパーシステンスを一般的によく使われる cookie ベースとし，ヘルスチェックを上記で作成した「mygce-site2-health-check」に設定した "バックエンドサービス"「mygce-site2-bs」を作成します。

$ gcloud compute backend-services create mygce-site2-bs \
  --session-affinity generated_cookie \
  --http-health-checks mygce-site2-health-check \
  --global

"バックエンドサービス" に "バックエンド" を追加

「mygce-site2-bs」に，前回作成した site2 の「mygce-site2-ig-asia」「mygce-site2-ig-us」の 2 つの "バックエンド" を追加します。

$ 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」としています。

$ gcloud compute url-maps create mygce-url-map \
  --default-service mygce-site1-bs

"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 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 としています。

$ openssl req -x509 -newkey rsa:2048 -keyout mygce.key -out mygce.crt
$ openssl rsa -in mygce.key -out mygce-nopass.key # ← 秘密鍵のパスフレーズを解きます

"SSL 証明書リソース" の登録

上記で作成した SSL 証明書「mygce.crt」と秘密鍵「mygce.key」を "SSL 証明書リソース" として登録します。その名前を「mygce-cert」としています。

$ gcloud compute ssl-certificates create mygce-cert \
  --certificate mygce.crt \
  --private-key mygce-nopass.key

"ターゲットプロキシ" の作成

上記で作成した "SSL 証明書リソース"「mygce-cert」と，"URL マップ" 「mygce-url-map」を使い "ターゲットプロキシ"「mygce-target-proxy」を作成します。

$ 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 にブラウザからアクセスしてみます。

https://mygce.fastriver.net/site1/index.txt
https://mygce.fastriver.net/site2/index.txt

すると，前回でそれぞれの index.txt の中に記した「site1」または「site2」の文字がブラウザに表示されるはずです。セッションパーシステンスを確認したい場合は，一旦ブラウザを終了して新たな cookie でアクセスしてみるのも良いでしょう。

というわけで，これでクロスリージョンの負荷分散かつオートスケーリングな Web サーバが出来上がりました。今回の例は本当に簡易的な構成ですので，実際の運用ではもっと複雑な要件があり，複雑な設定をすると思います。その際は gcloud コマンドのヘルプやら Google が提供するドキュメント等を参考にしてください。

ではさようなら。

GCE でクロスリージョン+オートスケーリング第三回

2017年1月17日火曜日

GCE でクロスリージョン+オートスケーリング第一回

GCE ってすごいかも

Google Compute Engine(GCE) でグローバル IP アドレスを確保する際，大きな特徴としてリージョンを指定する・しないの選択が可能です("グローバル転送ルール" (後述) のときのみ)。リージョン指定しなくて良いってことは，例えばあるリージョンが戦争とかで壊滅状態になったときに何もしなくても同一 IP アドレスで別のリージョンで運用継続できるってこと?

だとすると，個人的にはこりゃすごいと関心してしまいます(違ってたらすみません,ご指摘ください)。オンプレだとマルチホーミングして AS 取得して BGP で... などとしていたことが，いとも簡単にコマンドやブラウザから椅子に座りながらチョイチョイで設定可能です。

ちょっと外れますが，おそらく AWS だとこのようなリージョンを超えた Elastic IP address の設定は出来ないと思われます。Multi AZ は可能ですが，disaster 対策や冗長化には Endpoints の CNAME で対処していると私は理解しています(間違ってたらごめんなさい, ご指摘いただけると助かります)。

また，この仕組みにより GCE では cross regional な負荷分散も可能にします。つまり異なるリージョンにある末端インスタンスノードにリクエストを分散できるようです。

これらについては，おそらく「今更」感バリバリと思いますが個人的には今更感動しています。そんなこんなで，仕事柄 AWS で Web システムを構築することが多い私が，そこでよくやる基本的なオートスケーリングなサーバ構成を GCE でも作ってみようか，しかもクロスリージョンで! という気になり，ちょっとやり方をメモしようとこれを書くことにしました(基本中の基本なことになっちゃいますが...)。

今回作るものの概要

こんな感じのものを作る

というわけで本当に基本的なものですが，今回は以下イメージのような基礎的な Web サーバのシステムを作ってみます。

よくある Web サーバシステムの図

よくある，DMZ に LB がいて，それが 2 本の足を持っていてその下の独立したプライベートネットワーク上に Web サーバが複数台いるというやつです。LB がその Web サーバ達にリクエストを振り分けるって感じです。

これを Google Compute Engine で表現してみます。末端ノードの Web サーバは，固定台数でなくオートスケーリングにします。GCE はインフラ的なネットワーク設計をある程度意識しなくて良いので下記のような感じです。

GCE ではこんな感じの図

必要な GCE 要素の概要

ネットワーク

あまり意識せず「default」のネットワークを使います。自動的に cross region なサブネットに切られているはずです。AWS とは根本的に考え方が違います。個人的には GCE の方が未来を感じます。

"負荷分散(Load Balancer)"

GCE のロードバランサは AWS の ELB と違って，さぁロードバランサを作るぞ！って感じではなく，以下のような要素を組み立てていきます。

"グローバル転送ルール"

待受の IP アドレスとポートを定義する(BIG-IP で言えば Virtual Server の部分か)。この IP アドレスは前述のリージョンを指定しないものを割り当てることができる。

"ターゲットプロキシ"

その名の通りここは Reverse Proxy の役割だろう。どうもクライアントからの直接のリクエストは一旦ここで受け取ってるっぽい。SSL Termination もここでやる。その後リクエストを解釈して X-Forwarded-For 等の Proxy 用の HTTP ヘッダを追加している。

"URL マップ"

URL により振り先定義するところ(Apache とか NGINX とかで言えば、Location による振り分け)。

"バックエンドサービス"

末端のインスタンスグループを取りまとめているところ。BIG-IP で言えば pool だろうか。ヘルスチェックや persistence はここでやってる。

"インスタンスグループ"

インスタンスグループは，その名の通りインスタンスの集まりです。"自動スケーリング" を利用したい場合はここで定義できます。"インスタンスグループ" に含まれる各インスタンスの雛形は "インスタンステンプレート" で定義します。その中にインスタンスの "イメージ" も含まれ、これは以下の手順で作成することになります。

"公開イメージ" から "ディスク" 作成
作成した "ディスク" をブートディスクとしてアタッチしてインスタンスを生成
OS にログインしてお好きなようにカスタマイズ
"ディスク" を消さないようにインスタンス削除
孤立したディスクから "イメージ" 作成

というわけで今回はここまでとします。次回は具体的に gcloud コマンドを使って実装していくことにします。

GCE でクロスリージョン+オートスケーリング第一回

GCE でクロスリージョン+オートスケーリング第二回

GCE でクロスリージョン+オートスケーリング第二回

前回では，GCE でこんなものを作ってみようかな，ということについての概要を書きました。今回はそれを具体的に作っていきます。

構成

上図は，今回作成する構成を簡単に表したものです。"負荷分散(ロードバランサ)" で HTTPS(443)ポートでリクエストを受け付け，"ターゲットプロキシ" で SSL 終端処理を行います。その後 "URLマップ" で /site1 という URL と /site2 という URL へのリクエストを解釈して，それぞれ異なる "バックエンドサービス" に振り分けます。

"インスタンスグループ"はそれぞれの "バックエンドサービス" 内に 2 つづつ用意し，異なるリージョンに配置します。これはリージョンを跨ぐ負荷分散を実現するための準備です。

"インスタンスグループ" 内のインスタンスは "自動スケーリング" によりスケールイン/アウトを繰り返すよう設定します。この場合は "管理対象インスタンスグループ" として作成します。このため，インスタンスの雛形を定義する "イメージ" を作成し，さらにその起動設定を "インスタンステンプレート" で定義する必要があります。

では，まず "イメージ" の作成から具体的にやっていきましょう。今回は "負荷分散(ロードバランサ)" の "バックエンド" となる "インスタンスグループ" の作成まで行うこととします。

なお，以降 GCE の Web GUI コンソールは使わず，全て gcloud コマンドで行います。gcloud コマンドの操作方法についてはここでは触れません。gcloud からの認証(gcloud auth login)やプロジェクトの作成，およびデフォルトのプロジェクト設定についても既に行っていることとします。

また，GCE に作るオブジェクトの名前は全て「mygce-」というプレフィクスをつけたいと思います。

"イメージ" の作成まで

まず，インスタンスの雛形となる "イメージ" を作成します。今回は GCP が公開している CentOS 7 の "イメージ" をベースとし，その上に Apache (httpd)が稼働するようにします。また，前出の図のように機能が異なる Web サーバに URL で振り分けを行いますので，2 つの "イメージ" を作成します。今後、これらのサイトを便宜上「site1」「site2」と呼びます。

site1 の "イメージ" の作成

site1 の "イメージ" は，「"ディスク" 作成」→「インスタンス起動」→「Apache等インストール/設定」→「インスタンスを削除して "ディスク" 解放」→「"イメージ" 作成」といった手順で作成します。

"公開イメージ" から "ディスク" 作成

CentOS7 の "公開イメージ" から名前が「mygce-site1-disk」という "ディスク" を作成します。"ゾーン" は任意のものを設定しています。

$ gcloud compute disks create mygce-site1-disk \
  --image-family=centos-7 \
  --image-project=centos-cloud \
  --zone asia-east1-b

作成した "ディスク" をブートディスクとしてアタッチしてインスタンスを生成

1 で作成した "ディスク" からインスタンスを立ち上げます。この後，これにログインして好みの設定にしていきます。"ゾーン" は任意です。--metadata で「ryo」というユーザでログインする際に必要な ssh 公開鍵(~/.ssh/id_rsa.pub)を渡しています。インスタンス名を「mygce-site1-tmp-instance」としています。

$ gcloud compute instances create mygce-site1-tmp-instance \
  --disk name=mygce-site1-disk,boot=yes \
  --metadata "ssh-keys=ryo:$(cat ~/.ssh/id_rsa.pub)" \
  --zone asia-east1-b

OS にログインしてカスタマイズ

上記 2 の実行が成功すると，作成されたインスタンスの IP アドレスが表示されます(下記では xxx.xxx.xxx.xxx で表示しています)。ssh でそれにログインします

$ ssh ryo@xxx.xxx.xxx.xxx

[ryo@mygce-site1-tmp-instance]$ sudo yum install httpd -y
[ryo@mygce-site1-tmp-instance]$ sudo mkdir /var/www/html/site1
[ryo@mygce-site1-tmp-instance]$ echo "site1" | sudo tee /var/www/html/site1/index.txt
[ryo@mygce-site1-tmp-instance]$ sudo systemctl enable httpd
[ryo@mygce-site1-tmp-instance]$ exit

"ディスク" を消さないようにインスタンス削除

上記 2 で作成したインスタンス「mygce-site1-tmp-instance」を削除します。これは，インスタンスに関連付けられたディスクからはイメージの作成ができないためです。なお下記コマンド例では -q で削除の確認を行わないようにしていますのでご注意ください。

$ gcloud compute instances delete mygce-site1-tmp-instance --zone asia-east1-b -q

"ディスク" から "イメージ" 作成

下記コマンドで，上記 1, 3 で作成/編集した "ディスク"「mygce-site1-disk」から「mygce-site1-image」という名前の "イメージ" を作成します。この際，--family というオプションが必要になりますが，これは任意の文字列を指定します。ここでは「mygce-site1-image-family」としました。

$ gcloud compute images create mygce-site1-image \
  --source-disk-zone=asia-east1-b \
  --source-disk mygce-site1-disk \
  --family mygce-site1-image-family

site2 の "イメージ" の作成

site2 の "イメージ" は「site1 の "イメージ" から "ディスク" 作成」→「インスタンス起動」→「/var/www/html/index.txt の内容を変更」→「インスタンス削除」→「"イメージ" 作成」という手順で行います。

site1 の "イメージ" から "ディスク" 作成

これまでに作成した 1 つ目の "イメージ" を元に下記コマンドで "ディスク" 「mygce-site2-disk」を作成します。この際，--image-family オプションに上記 5 で指定した「mygce-site1-image-family」与えます。

$ gcloud compute disks create mygce-site2-disk \
  --image-family=mygce-site1-image-family \
  --zone=asia-east1-b

作成した "ディスク" をブートディスクとしてアタッチしてインスタンスを生成

上記 1 で作成した "ディスク"「mygce-site2-disk」からインスタンスを生成します。ssh 鍵は 1 つ目のインスタンスを作成したときと同じように指定します。インスタンス名は「mygce-site2-tmp-instance」としました。

$ gcloud compute instances create mygce-site2-tmp-instance \
  --disk name=mygce-site2-disk,boot=yes \
  --metadata "ssh-keys=ryo:$(cat ~/.ssh/id_rsa.pub)" \
  --zone asia-east1-b

OS にログインしてカスタマイズ

上記 2 の実行が成功すると，作成されたインスタンスの IP アドレスが表示されます(下記では xxx.xxx.xxx.xxx で表示しています)。ssh でそれにログインします。

$ ssh ryo@xxx.xxx.xxx.xxx

[ryo@mygce-site2-tmp-instance]$ sudo mkdir /var/www/html/site2
[ryo@mygce-site2-tmp-instance]$ echo "site2"  | sudo tee /var/www/html/site2/index.txt
[ryo@mygce-site2-tmp-instance]$ sudo systemctl enable httpd
[ryo@mygce-site2-tmp-instance]$ exit

"ディスク" を消さないようにインスタンス削除

上記 2 で作成したインスタンス「mygce-site2-tmp-instance」を削除します。これは，インスタンスに関連付けられた "ディスク" からは "イメージ" の作成ができないためです。なお下記コマンド例では -q で削除の確認を行わないようにしていますのでご注意ください。

$ gcloud compute instances delete mygce-site2-tmp-instance --zone asia-east1-b -q

ディスクからイメージ作成

下記コマンドで，上記 1, 3 で作成/編集した "ディスク"「mygce-site2-disk」から「mygce-site2-image」という名前の "イメージ" を作成します。この際，--family というオプションが必要になりますが，これは任意の文字列を指定します。ここでは「mygce-site2-image-family」としました。

$ gcloud compute images create mygce-site2-image \
  --source-disk-zone=asia-east1-b \
  --source-disk mygce-site2-disk \
  --family mygce-site2-image-family

"インスタンスグループ" の作成まで

"負荷分散(ロードバランサ)" の "バックエンド" となる "インスタンスグループ" を作成します。今回は，米国と日本の 2 つのリージョンに跨る負荷分散を行いますので，"インスタンスグループ" を site1, site2 のそれぞれで 2 つのリージョンに作成します。

site1 の "インスタンスグループ" の作成

site1 の "インスタンステンプレート" の作成

"インスタンスグループ" を作成する前に "インスタンステンプレート" 「mygce-site1-template」を作成します。この際，マシンタイプを小さな g1-small で指定します。"イメージ" の源泉は上記で作成した「mygce-site1-image」です。ログインできるように ssh の公開鍵も登録します。

$ gcloud compute instance-templates create mygce-site1-template \
  --machine-type g1-small \
  --image-family mygce-site1-image-family \
  --metadata "ssh-keys=ryo:$(cat ~/.ssh/id_rsa.pub)"

日本のリージョンに site1 の "インスタンスグループ" を作成

まず日本リージョンの "ゾーン"「asia-east1-b」に「mygce-site1-ig-asia」という "インスタンスグループ" を作成します。"インスタンステンプレート" は上記 1 で作成した「mygce-site1-template」を指定します。

$ gcloud compute instance-groups managed create mygce-site1-ig-asia \
  --size 1 \
  --template mygce-site1-template \
  --zone asia-east1-b

"オートスケーリング" の設定

"インスタンスグループ"「mygce-site1-ig-asia」に "自動スケーリング" を設定します。ここでは，最小インスタンス数 1, 最大インスタンス数 3, スケールアウトの CPU 閾値を 80% とします。

$ gcloud compute instance-groups managed set-autoscaling mygce-site1-ig-asia \
  --max-num-replicas 3 \
  --min-num-replicas 1 \
  --target-cpu-utilization 0.8 \
  --scale-based-on-cpu \
  --zone asia-east1-b

米国のリージョンに site1 の "インスタンスグループ" を作成

米国リージョンの "ゾーン"「us-east1-b」に「mygce-site1-ig-us」という "インスタンスグループ" を作成します。"インスタンステンプレート" は上記 1 で作成した「mygce-site1-template」を指定します。

$ gcloud compute instance-groups managed create mygce-site1-ig-us \
  --size 1 \
  --template mygce-site1-template \
  --zone us-east1-b

"オートスケーリング" の設定

"インスタンスグループ"「mygce-site1-ig-us」に "自動スケーリング" を設定します。ここでは，最小インスタンス数 1, 最大インスタンス数 3, スケールアウトの CPU 閾値を 80% とします。

$ gcloud compute instance-groups managed set-autoscaling mygce-site1-ig-us \
  --max-num-replicas 3 \
  --min-num-replicas 1 \
  --target-cpu-utilization 0.8 \
  --scale-based-on-cpu \
  --zone us-east1-b

site2 の "インスタンスグループ" の作成

site2 のインスタンスグループの作成は site1 とほぼ同じですが，以下一応コマンドを全て記しておきます。

site2 の "インスタンステンプレート" の作成

"インスタンスグループ" を作成する前に "インスタンステンプレート" 「mygce-site2-template」を作成します。この際，マシンタイプを小さな g1-small で指定します。"イメージ" の源泉は上記で作成した「mygce-site2-image-family」です。ログインできるように ssh の公開鍵も登録します。

$ gcloud compute instance-templates create mygce-site2-template \
  --machine-type g1-small \
  --image-family mygce-site2-image-family \
  --metadata "ssh-keys=ryo:$(cat ~/.ssh/id_rsa.pub)"

日本のリージョンに site2 の "インスタンスグループ" を作成

まず日本リージョンの "ゾーン"「asia-east1-b」に「mygce-site2-ig-asia」という "インスタンスグループ" を作成します。"インスタンステンプレート" は上記 1 で作成した「mygce-site2-template」を指定します。

$ gcloud compute instance-groups managed create mygce-site2-ig-asia \
  --size 1 \
  --template mygce-site2-template \
  --zone asia-east1-b

"オートスケーリング" の設定

"インスタンスグループ"「mygce-site2-ig-asia」に "自動スケーリング" を設定します。ここでは，最小インスタンス数 1, 最大インスタンス数 3, スケールアウトの CPU 閾値を 80% とします。

$ gcloud compute instance-groups managed set-autoscaling mygce-site2-ig-asia \
  --max-num-replicas 3 \
  --min-num-replicas 1 \
  --target-cpu-utilization 0.8 \
  --scale-based-on-cpu \
  --zone asia-east1-b

米国のリージョンに site2 の "インスタンスグループ" を作成

米国リージョンの "ゾーン"「us-east1-b」に「mygce-site2-ig-us」という "インスタンスグループ" を作成します。"インスタンステンプレート" は上記 1 で作成した「mygce-site2-template」を指定します。

$ gcloud compute instance-groups managed create mygce-site2-ig-us \
  --size 1 \
  --template mygce-site2-template \
  --zone us-east1-b

"オートスケーリング" の設定

"インスタンスグループ"「mygce-site2-ig-us」に "自動スケーリング" を設定します。ここでは，最小インスタンス数 1, 最大インスタンス数 3, スケールアウトの CPU 閾値を 80% とします。
```
$ gcloud compute instance-groups managed set-autoscaling mygce-site2-ig-us \
  --max-num-replicas 3 \
  --min-num-replicas 1 \
  --target-cpu-utilization 0.8 \
  --scale-based-on-cpu \
  --zone us-east1-b
```

これでリージョンを跨ぐ負荷分散を考慮した 2 つのサイトの "インスタンスグループ" を作成することができました。次回はこの続きで，"負荷分散(ロードバランサ)" の部分を作成していきます。

GCE でクロスリージョン+オートスケーリング第二回