はじめに
こちらはAWSのハンズオンテーマをGoogleCloudでやってみる企画です。
第１回の記事はこちらを参照くだい
前回のハンズオンでシングルゾーン構成のWebシステムを作成しました。
今回はシステムのマルチゾーン対応の冗長化を実装して、ゾーン障害発生時もサービス継続可能なシステムにバージョンアップしていきます。
Webサーバの冗長化
VMインスタンスのWebサーバを複数ゾーンに立てて冗長化します。
- VMインスタンスのイメージ作成
まず、VMインスタンスのイメージを作成します。ナビゲーションメニュー⇒「ComputeEngine」⇒「イメージ」へ移動して、「イメージを作成」をクリックします。
イメージ名を入力して、前回作成したVMインスタンスを選択して、「作成」します。
- イメージからVMインスタンスを複製
作成したイメージから、ゾーンbにインスタンスの複製を作成します。
作成したイメージ画面から、「インスタンスを作成」をクリックすると、VMインスタンス作成画面に遷移します。
名前を別名（ここでは「wp-instance-2」）を入力。デプロイ先に「asia-northeast1-b」を指定します。マシンタイプは最小構成の「e2-micro」を指定。ブートディスクで「wp-image-1」が選択されていることを確認します。
ファイアウォールでHTTP、HTTPSトラフィックを許可してインスタンスを作成します。
- 動作確認
これでWebサーバの冗長化は完了です。試しにブラウザに「https://」+＜それぞれのVMインスタンスの外部IPアドレス＞を入力して確認してみます。
上記の通り両方のアドレスで画面表示できました。
ヘッダー部分にちょっと差異がありますが、本題ではないのでスルーします。
DBの冗長化
次にCloudSQLに高可用化設定をして、ゾーン障害発生時にフェイルオーバー（自動切換え）するようにします。
-
CloudSQLの高可用化設定
ナビゲーションメニュー⇒「CloudSQL」へ移動して、前回作成したインスタンス概要を表示。「編集」をクリックします。ゾーンの可用性を「複数のゾーン」に変更して、セカンダリゾーンに「asia-northeast1-b」を指定します。
保存をクリックすると、再起動確認のメッセージが出るので、保存した再起動します。
これで高可用化設定はおしまいです。 -
動作確認
DBの概要メニューから「フェイルオーバー」をクリックします。確認メッセージに従ってフェイルオーバーをトリガーします。
トリガー完了後にDBの稼働場所を参照すると、「asia-northeast1-a」から「asia-northeast1-b」に切り替わったことが分かります。
HTTPロードバランサーの設定
一意のアドレスでアクセスできるよう、Webサーバの前面にHTTPロードバランサを配置します。
ロードバランサーで受けたトラフィックは、インスタンスグループを介してインスタンスに配布されます。そのためトラフィック配布先になるインスタンスグループをあらかじめ作成します。
トラフィックフローは以下の通り。
HTTPロードバランサー ⇒ インスタンスグループ ⇒ インスタンス
- インスタンスグループの作成
ナビゲーションメニュー⇒「ComputeEngine」⇒「インスタンスエンジンイメージ」へ移動して、「インスタンスグループを作成」をクリックします。
「New unmanaged instance group」を選択します。
インスタンスグループはサブネット単位で作成します。今回の構成は2つのサブネットなので、インスタンスグループも2つ作成します。
「名前」を指定して、「ロケーション」「ゾーン」を指定後サブネットを選びます。今回はdefaultを選択。
サブネット配下のVMインスタンスを選んで「作成」をします。
同じ手順でもう一つのサブネットのインスタンスグループを作成します。
-
ロードバランサーの作成
ナビゲーションメニュー⇒「ネットワークサービス」⇒「ロードバランシング」へ移動して、「ロードバランサを作成」をクリックします。
アプリケーション ロードバランサ（HTTP/S）の「構成を開始」をクリック。次画面で初期選択のまま「続行」をクリックします。
ロードバランサの名前を指定して、フロントエンドを設定します。フロントエンドの名前とタイムアウト秒を入力して「完了」をクリックします。
次にバックエンドの構成を設定します。
「バックエンドサービスを作成」をクリック。バックエンドサービス名を指定して、バックエンドとして前の手順で作成したインスタンスグループを選択します。ポート番号に「80」を指定して、「完了」をクリックします。
「バックエンドを追加」をクリックして同様の手順でもう一つのインスタンスグループをバックエンドに指定します。
同画面の下に移動して、CloudCDNのチェックを外します。ヘルスチェックで「ヘルスチェックを作成」をクリックして、ヘルスチェック名を指定。ログをオンにして保存をクリックします。さらに画面下に移動してロギングを有効にします。
ルーティングルールはそのままで、最後に「作成」をクリックします。
-
動作確認
ロードバランサが完成したら動作を確認します。ロードバランサの詳細画面で、フロントエンドのIPアドレスを確認します。「http://」+ ＜確認したIPアドレス＞をブラウザに入力して、WordPress画面が表示されればOKです。
本当にマルチゾーン対応できたか試してみる
ここまででマルチゾーン構成の設定が完了しました。
では、本当に障害が起きても大丈夫か以下のシナリオで試してみましょう。
-
ゾーンa でゾーン障害を想定
ゾーンaのインスタンスを停止、CloudSQLをゾーンbへフェイルオーバーを実行します。
-
個別インスタンスで複数個所障害発生を想定
ゾーンbのインスタンスを停止、CloudSQLをゾーンbへフェイルオーバーを実行します。
両方のシナリオともWordPress画面が表示されました！！
まとめ
思っていたよりも簡単にマルチゾーン構成ができてしまいました。
お手本にしたAWSハンズオンの手順は完了です。AWSより簡単に構築ができたと思います。
途中しれっと流してましたが、HTTPロードバランサーで、CDNを無効化してました。
GoogleCloudのHTTPロードバランサーは、外から中へのトラフィック負荷分散と、外部へのトラフィック配信両方がサポートされています。AWSでは、ALB、Cloudfrontで別々のサービスになっていますね。
乱暴に書くと、HTTPロードバランサー ＝ ALB + Cloudfront ということになります。
AWSとの機能構成の違いが分かって面白いですね。
これで終わりにしてもよいのですが、GoogleCloudでさらに機能拡張をしたら面白いかもしれません。需要があればマルチリージョン構成、オートスケーリングを追加でやってみようと思います。