マルチ AZ 構成の作り方 ── ALB・Auto Scaling・RDS で 1 つの AZ が止まっても動かす

前提条件

1. リージョン: ap-northeast-1（東京）
2. EC2・Auto Scaling・ELB・RDS の操作権限を持つ IAM ユーザーまたはロールでコンソールにログイン済みであること

以下のリソースが作成済みであることを前提とします。Web サーバーは ap-northeast-1a のパブリックサブネットだけで 2 台動いており、RDS はシングル AZ で ap-northeast-1a にあります。

まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。

> [!WARNING] > ALB・EC2・RDS は起動している間ずっと課金されます。マルチ AZ にした RDS は、スタンバイのぶん料金がおよそ 2 倍になります。検証が終わったら必ず削除してください。

手順 1: いまの構成が 1 つの AZ に寄っていることを確かめる

AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。

上部の検索バーに EC2 と入力し、「EC2」を選択します。左側ナビゲーションの「Auto Scaling」→「Auto Scaling グループ」を選択し、ha-lab-asg を開きます。「詳細」タブの「ネットワーク」で、アベイラビリティーゾーンが ap-northeast-1a の 1 つだけであることを確認します（ここにはサブネット名ではなく、AZ とサブネット ID が表示されます）。

続けて「インスタンス管理」タブを開き、2 台のインスタンスのアベイラビリティーゾーンがどちらも ap-northeast-1a であることを確認します。AZ は apne1-az4 (ap-northeast-1a) のように、AZ ID と並べて表示されます。

上部の検索バーに RDS と入力し、「Aurora and RDS」を選択します。左側ナビゲーションの「データベース」から ha-lab-db を開き、画面上部の概要の「リージョンと AZ」が ap-northeast-1a、「設定」タブの「可用性」にある「マルチ AZ」が なし、「セカンダリゾーン」が - であることを確認します。

あわせて「接続とセキュリティ」タブを開き、「を使用して接続」で エンドポイント を選択します。「エンドポイントとポート」に表示されるエンドポイントの値を控えておきます。

手順 2: Auto Scaling グループに 2 つ目の AZ を足す

EC2 コンソールの「Auto Scaling グループ」に戻り、ha-lab-asg の「詳細」タブで「ネットワーク」の「編集」をクリックします。

「アベイラビリティーゾーンとサブネット」で ha-lab-public-1c を追加します。一覧には他の VPC のサブネットも並ぶので、名前で選びます。その下の「アベイラビリティーゾーンのディストリビューション」はデフォルトのままにして、「更新」をクリックします。

「アクティビティ」タブを開きます。10 秒ほどで、ap-northeast-1c で新しいインスタンスが起動し、そのあとで ap-northeast-1a のインスタンスが 1 台終了する履歴が並びます（説明の欄は Launching a new EC2 instance: … のように英語で表示されます）。新しいインスタンスを先に起動してから古いインスタンスを終了する、再調整の動きです。

手順 3: 2 つの AZ のサーバーが応答していることを確かめる

「インスタンス管理」タブで、インスタンスが ap-northeast-1a と ap-northeast-1c に 1 台ずつになったことを確認します。

左側ナビゲーションの「ロードバランシング」→「ターゲットグループ」から ha-lab-tg を開き、「ターゲット」タブで 2 台とも Healthy で、アベイラビリティーゾーンが分かれていることを確認します。

左側ナビゲーションの「ロードバランサー」から ha-lab-alb を開き、「DNS 名」をコピーしてブラウザの新しいタブで開きます。何度か再読み込みすると、表示される AZ が ap-northeast-1a と ap-northeast-1c で入れ替わります。ブラウザが同じ接続を使い回すと同じ AZ が続くことがあるので、そのときは少し時間をおくか、別のタブで開き直します。

手順 4: RDS をマルチ AZ に変更する

RDS コンソールの「データベース」で ha-lab-db を選択し、「変更」をクリックします。

「可用性と耐久性」の「マルチ AZ 配置」で スタンバイインスタンスを作成する (本稼働環境向けに推奨) を選択します。その他の項目はデフォルトのままにして、ページ下部の「続行」をクリックします。

「変更のサマリー」画面に、マルチ AZ 配置の現在の値 なし と新しい値 あり が表示されます。変換中は性能に影響が出ることがある、という注意もここに表示されます。「変更のスケジュール」の既定は 次回の定期メンテナンス期間中に適用 なので、すぐに適用 を選び直してから「DB インスタンスを変更」をクリックします。ステータスが「変更中」になり、10 分前後で「利用可能」に戻ります（DB のサイズによって変わります）。

ステータスが「利用可能」に戻ったら、「設定」タブの「可用性」で「マルチ AZ」が あり、「セカンダリゾーン」が ap-northeast-1c になっていることを確認します。プライマリは概要の「リージョンと AZ」のとおり ap-northeast-1a のままです。変換の直後は「ストレージの初期化が進行中」と表示され、セカンダリゾーンが表示されるまで少し時間がかかることがあります。

手順 5: フェイルオーバーを起こしてエンドポイントが変わらないことを確かめる

ha-lab-db を選択し、「アクション」→「再起動」をクリックします。「DB インスタンスを再起動」の画面で「フェイルオーバーで再起動しますか?」にチェックを入れ、「確認」をクリックします。データベースの一覧に戻り、ステータスが「再起動中」になります。

ステータスが「利用可能」に戻ったら、ha-lab-db を開きます。概要の「リージョンと AZ」が ap-northeast-1c に、「設定」タブの「セカンダリゾーン」が ap-northeast-1a に入れ替わっています。一方で、「接続とセキュリティ」タブの「エンドポイントとポート」に表示されるエンドポイントは、手順 1 で控えた値から変わっていません。

「ログとイベント」タブの「最近のイベント」で、マルチ AZ のフェイルオーバーが開始・完了したイベント（Multi-AZ instance failover started. と Multi-AZ instance failover completed）を確認します。今回は開始から完了まで 1 分ほどでした。

アプリケーションは同じエンドポイントに接続し直すだけで、新しいプライマリにつながります。