クラウド

AWSの障害対策：マルチAZ・再試行・バックアップの基本

2026/10/17 シリーズ「AWS 入門」 第9回 / 全9回

🤖 AIを使用して執筆

AWS で起きる障害と、信頼性の柱の考え方

障害は、影響の及ぶ範囲で分けると考えやすい。

AWS は、ワークロード（一つの目的のために動くシステムのまとまり）のデータと資源を複数のアベイラビリティーゾーンに分け、必要なときはリージョンにも分けるよう勧めている¹⁵。各リージョンは、物理的にも論理的にも独立し、三つ以上のアベイラビリティーゾーンを持つ¹⁵。

信頼性の柱の設計原則は五つある¹。

冗長化と自動の復旧：ELB、Auto Scaling、Route 53

Auto Scaling： Auto Scaling グループは、有効にしたアベイラビリティーゾーンに、インスタンスを同じ数ずつ置こうとする。ゾーンが戻ると、自動で偏りを直す。直すときは、新しいインスタンスを先に起動してから、古いものを終了する¹⁶。

インスタンスが異常かどうかは、ヘルスチェックで決める。既定のヘルスチェックは、EC2 の状態の確認で、たまに失敗しただけでは何もしない。ロードバランサーのヘルスチェックの結果は、既定では使わない。有効にすると、ロードバランサーが異常と報告したインスタンスを、Auto Scaling が次の定期の確認で異常とし、入れ替える⁴。AWS は、障害を見つけたら自動の処理で直し、クラウドでは、再起動するときに資源ごと入れ替えるのがよいとしている¹⁷。

Route 53： Route 53 は、AWS の DNS（名前からサーバーのアドレスを引く仕組み）のサービスで、ヘルスチェックも持つ。決めた間隔（10 秒か 30 秒）で、インターネットの上から相手に要求を送り、届くか、使えるかを確かめる¹⁸¹⁹。確かめるサーバー（ヘルスチェッカー）のうち 18% を超える数が正常と報告すれば、正常とみなす¹⁹。フェイルオーバー（異常なときに予備へ切り替えること）のルーティングにすると、正常なときは本来の宛先を、異常なときは別の宛先を、DNS の答えとして返す²⁰。

タイムアウトと再試行：遅い相手に全体が巻き込まれないために

タイムアウト： AWS は、接続と要求にタイムアウトを決め、既定の値に頼らないよう勧めている。ライブラリの中には、既定のタイムアウトが無限か、サービスの目標より長いものがあるからである²¹。待ち行列も長くしすぎない。呼び出した側があきらめた古い要求を処理し続けることになるからである²²。

再試行は利己的である： AWS のエンジニアの Marc Brooker は、Builders’ Library で、再試行を「利己的」と書いた。クライアントは、再試行することで、成功の見込みを上げる代わりに、サーバーの時間をより多く使う²。失敗がまれで一時的なら、再試行はよく効く。失敗の原因が過負荷なら、再試行はかえって悪くする²³。

再試行は、呼び出しの層が重なると掛け算で増える。Brooker は、5 段に重なった呼び出しで、各層が 3 回ずつ試すと、一番下のデータベースへの負荷は 243 倍になり、回復はまず見込めないと書いた。AWS の慣行は、軽い操作では、再試行を呼び出しの重なりの一か所に限ることだという²。信頼性の柱も、再試行は一つの層だけで行うよう勧めている²³。

指数バックオフとジッター： 再試行の間隔は、試すたびに長くする（指数バックオフ）。ただし、多くのクライアントが同じ瞬間に失敗すると、同じ間隔で一斉に再試行してしまう。そこで間隔にランダムな幅（ジッター）を加え、再試行を時間の上にばらす²。Brooker が 2015 年に AWS のブログで比べた中では、待ち時間を 0 から上限までの一様な乱数にする「フルジッター」が、呼び出しの回数を最も少なくした²⁴。

待ち時間 = random_between(0, min(上限, 基準の時間 × 2 ^ 試した回数))

この比べ方は、100 のクライアントが同じデータを書き換えようと競う場面を、模擬で動かしたものである。ジッターの無い指数バックオフは、はっきりと劣った²⁴。

AWS の SDK の再試行： AWS のサービスを呼ぶ SDK は、失敗した呼び出しを、自動で再試行する²⁵。AWS は 2026 年 5 月に、SDK の再試行の新しい動きを発表した。2026 年 10 月の時点では、環境変数で選んだときだけ使われ、2026 年 11 月に既定になる予定である²⁵²⁶。新しい動きでは、既定で、最初の呼び出しを含めて 3 回まで試し（AWS のデータベースの DynamoDB を呼ぶクライアントは 4 回）、ジッター付きの指数バックオフで待つ。一時的なエラーの基準の時間は 50 ミリ秒、呼び出しすぎで断られた（スロットリング）エラーは 1,000 ミリ秒である。権限が無いなどの、何度送っても成功しないエラーは再試行しない。再試行の回数は、トークンと呼ぶ点数で制限する。SDK のクライアントは 500 のトークンを持ち、再試行のたびに一定の数を引き、成功すると少し戻す。足りなくなると再試行をやめる²⁵。

トークンの仕組みは、失敗が続くあいだ、再試行で相手に余計な負荷をかけないためにある。Brooker も、再試行をクライアントの側のトークンの仕組み（トークンバケット）で制限するのが効くと書いている²。

再試行の上限には、AWS の外の実務にも同じ考えがある。Google の SRE の本は、一つの要求を試すのは最初の 1 回を含めて 3 回まで（再試行は 2 回まで）とし、さらにクライアントごとに、再試行が要求全体の 10% を超えたら再試行しない、という二重の上限を説明している²⁷。再試行を複数の層で重ねると、試す回数は各層の回数の積になる、とも書いている²⁸。

フォールバックを避ける： 依存先が止まったときに、別の仕組みで同じ結果を得ようとすることを、フォールバックという。AWS のエンジニアの Jacob Gabrielson は Builders’ Library で、Amazon はフォールバックを避けていると書いた。フォールバックは、効くことを示すのが難しく、ふだん動かないので、障害のときに失敗しやすい³。信頼性の柱も、一般にフォールバックは避けるべきだとしている²⁹。一方で、失敗が続く相手への呼び出しをしばらく止めるサーキットブレーカーについては、信頼性の柱は使う形を勧め²⁹、Brooker は、試しにくく、回復を遅らせることもあると書いている²。

影響の範囲を区切る： 大きなサービスを作る側では、ワークロードを、状態を共有しない複数の写し（セル）に分け、顧客ごとにどれか一つのセルに送る作り（セルベースアーキテクチャ）も使われる³⁰。10 のセルがそれぞれ 10 の要求をさばいていれば、一つのセルが壊れても、残りの 90% の要求は影響を受けない³¹。顧客ごとにサーバーの組み合わせを変えて、壊れる範囲をさらに小さくするシャッフルシャーディングも、AWS は Route 53 などで使っている³²。AWS は、この作りは複雑になるので、すべてのワークロードに向くわけではないとしている³³。

バックアップと災害復旧：RTO と RPO から選ぶ

冗長化は災害復旧ではない： AWS の災害復旧のホワイトペーパー（技術的な解説の文書）は、可用性は部品の故障を扱い、災害復旧はワークロード全体の別の写しを扱うと区別している。主の側でファイルを消したり壊したりすると、その変更は予備にも写りうる。だから、時点を指定して戻せるバックアップが要る¹²。

RTO と RPO： 備えを選ぶ前に、二つの目標を決める。目標復旧時間（RTO）は、サービスが止まってから戻るまでに許せる時間の上限である。目標復旧時点（RPO）は、最後に戻せる時点（最後のバックアップなど）から障害までのあいだで、失ってよいデータの時間の上限である³⁴。実際の事業の要求より厳しい目標を決めると、必要以上に高く、複雑な仕組みを作ることになる³⁴。

AWS Backup： AWS Backup は、AWS の各サービスのバックアップを、一か所でまとめて自動で取るためのサービスである³⁵。バックアッププランに、いつ、どう取るかを書き³⁶、取ったバックアップは、バックアップボールトという入れ物に保管する³⁷。資源にタグを付けるだけで、プランを当てはめられる³⁸。別のリージョンへの写しも、決まった時刻に自動で取れる³⁹。料金は、保存した量、リージョンの間で写した量、戻した量などで決まり、最低料金は無い⁴⁰。AWS は、バックアップを RPO に合わせた間隔で自動で取り⁴¹、実際に戻して、データを読めるか確かめるよう勧めている。戻しただけで中を確かめないことや、バックアップがあると思い込むことを、避けるべき型に挙げている⁴²。

災害復旧の四つの方式： 一つのリージョン全体が使えなくなる場合に備える方式を、AWS は四つに分けている⁴³。信頼性の柱が示す RPO と RTO の目安は、次のとおりである⁴⁴。

パイロットライトは、データを別のリージョンに写し、中心の基盤だけを用意しておく。要求をさばくには、先に何かの操作が要る。ウォームスタンバイは、規模を縮めた、そのまま動く写しを置いておき、すぐに要求をさばける⁴⁴⁴⁵。アクティブ/アクティブは、最も複雑で費用のかかる方式である⁴⁵。

AWS は、マルチ AZ で事業の要求を満たせるのに、複数のリージョンに分ける作りを、避けるべき型に挙げている¹⁵。ホワイトペーパーも、一つのリージョンの中のマルチ AZ の構成で、多くのリスクに対応できるとしている。重要でないワークロードには、災害復旧を用意しないのも、正当な方針でありうるという⁴³。

ただし、リージョンをまたぐ方式には、実務からの注意もある。AWS の費用の助言を仕事にする Corey Quinn は 2018 年に、障害のときに新しいインスタンスをすばやく起動できることを前提にした災害復旧の計画は、本当の障害では苦しむことになりやすいと書いた。その種の問題は、皆が一斉に計画を動かす障害のときにだけ表に出るという⁴⁶。2020 年にも、計画を絶えず試していなければ、いちばん必要なときに壊れるとしている⁴⁷。

復旧の手順を試す：FIS と Resilience Hub

備えは、試さなければ、働くかどうか分からない。AWS は、本番か本番に近い環境で、障害を起こす実験（カオスエンジニアリング）を定期的に行うよう勧めている⁴⁸。人とチームの対応も含めて試す訓練（ゲームデー）も勧め、手順を書いただけで一度も動かさないことを、避けるべき型に挙げている⁴⁹。

AWS Fault Injection Service（FIS）： AWS の資源に、実際に障害を起こす実験を行うサービスである⁵⁰。実験のひな形に、起こす操作、対象、止める条件を書く。FIS は、本物の資源に本物の操作を行う⁵⁰。料金は、操作を動かしている時間と、実験に含めるアカウントの数で決まる⁵¹。

AWS Resilience Hub： アプリケーションの回復力の目標を決め、その目標に照らして今の構成を評価し、Well-Architected に基づく改善の案を示すサービスである⁵²。料金は使う版によって違い、2026 年 5 月 28 日に始まった新しい版は、作ったサービスの数や、行った評価と試験の数などで決まる⁵³。

2025 年 10 月の us-east-1 の障害：自動の仕組みが広げた影響

AWS 自身のサービスの障害も、ここまでの考え方の実例になる。2025 年 10 月 19 日から 20 日にかけて（米国太平洋夏時間）、バージニア北部のリージョン（us-east-1）で、AWS のキーバリューのデータベースである DynamoDB を起点とする障害が起きた。始まりから終わりまで、およそ 14 時間半だった⁵⁴。

原因は、DynamoDB の DNS を管理する自動の仕組みの、まれな競合だった。可用性のために、DNS を書き換える部品は三つのアベイラビリティーゾーンで独立に動いていた。そのうち一つが異常に遅れ、古い計画を新しい計画の上に書き戻した。その古い計画が後始末で消され、DynamoDB の接続先（エンドポイント）の DNS の記録が空になった。自動の仕組みは、これを直せなかった⁵⁴。

影響は、DynamoDB に頼るほかのサービスに広がった。EC2 では、新しいインスタンスの起動が失敗した。物理のサーバーを管理する部品は、DynamoDB が戻った後、各サーバーを管理する権利（リース）を取り直そうとした。ところが数が多すぎて、処理が時間切れになり、やり直しの処理がさらに積まれた。部品は詰まって先に進めなくなり、技術者が手で慎重に直した⁵⁴。時間切れとやり直しが重なって負荷を増やす形は、前の節で見た再試行の危うさと似ている。一方、障害の前から動いていたインスタンスは、障害のあいだずっと正常だった⁵⁴。障害のときに起動することを前提にした作りは、起動できなかったこの時間、頼れなかったことになる。静的安定性は、この形に備える考え方である。

ロードバランサーの一種の NLB では、新しく起動したインスタンスのネットワークの設定が行き渡る前に、ヘルスチェックが行われた。そのため、正常なノードや振り分け先のインスタンスまで、異常と判断された。判断の揺れでヘルスチェックの仕組みの負荷が増え、ゾーンの間の自動の切り替えが起き、使える容量が減った。技術者は、この自動の切り替えを止めて、正常なノードを戻した⁵⁴。ヘルスチェックの失敗はインスタンスの終了にもつながった。起動がまだできなかったため、AWS のサーバーレスのサービスである Lambda の内部の仕組みの一部で容量が足りなくなり、AWS は一部の呼び出しを絞った⁵⁴。AWS は、競合を直して保護を足すまで DNS の自動の仕組みを世界中で止め、NLB には、ヘルスチェックの失敗で一度に外せる容量を制限する仕組みを足すとした⁵⁴。

インシデントについて書き続けているソフトウェアエンジニアの Lorin Hochstein は、この障害を受けて、信頼性を高めるための自動の仕組みは、知られた失敗を防ぐ一方で、新しい種類の失敗を持ち込むと書いた。ヘルスチェックは信頼性を高めるための典型的な自動の仕組みだが、この障害では問題をさらに悪くした。それでもヘルスチェックが悪いのではなく、自動の仕組みを足すことには、常に引き換えがあるという⁵⁵。

どこまで備えるかと、その費用

備えには費用がかかる。別のゾーンに足りるだけのインスタンスを置けば、ふだんは使い切らない分の料金も払う。RDS のマルチ AZ は、予備のインスタンスを動かし続ける構成で、インスタンスを動かした時間を、マルチ AZ の単価で数える。データベースへの書き込みの I/O は、予備にも書くので倍になる。本体から予備へ写す転送には、料金がかからない⁵⁶。バックアップには保存した量の料金が、リージョンをまたぐ写しには転送の料金がかかる⁴⁰。AWS のホワイトペーパーは、復旧の方式の費用が、障害やデータの損失で失うものより高いなら、規制のような別の理由が無いかぎり、その方式は入れるべきでないとしている⁴³。

だから、方式を先に選ばない。まず、ワークロードごとに RTO と RPO を決める。次に、マルチ AZ と自動の入れ替え、タイムアウトと上限のある再試行、バックアップで、その目標を満たせるかを確かめる。満たせないときに、リージョンをまたぐ方式を足す。

障害は起きる前提で、範囲と時間を決めて備える

AWS は、障害は起きるものとして、ゾーンをまたいだ冗長化と、ヘルスチェックによる自動の入れ替えを基本にするよう勧めている。依存先の不調には、タイムアウトで待つのを打ち切り、再試行は一つの層だけで回数を限り、ジッター付きの指数バックオフで間隔を空ける。冗長化は削除や破損まで写すので、データはバックアップで守る。

どこまで備えるかは、RTO と RPO で決める。一つのリージョンの中のマルチ AZ で、多くのリスクに対応できると、AWS 自身が書いている。どの備えも、試さなければ働くかどうか分からない。ただし、皆が一斉に動く大きな障害のときの振る舞いは、ふだんの試験では確かめにくいと、実務者は注意している⁴⁶⁴⁷。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。