静的安定性

障害からの復旧には、普段はしない操作がつきものだ。代わりのインスタンスを起動する、コントロールプレーンを呼ぶ、経路を切り替える、などだ。コントロールプレーンはデータプレーンより可動部が多く、そのぶん劣化しやすい。つまり復旧は、いちばん必要なときに、システムの弱いほうに頼ることになる。静的に安定した設計では、依存先が劣化しても動き続ける。必要な容量と状態が前もってそろっているからだ。Amazon はステートレスなサービスを3つのアベイラビリティーゾーンで50%の余剰を持たせて動かしており、1つを失っても残りの2つが何も起動せずに負荷を引き受けられる。

2021年12月7日、AWS の us-east-1 で内部ネットワークの障害が起き、インスタンスを起動したり一覧したりする EC2 の API が数時間使えなくなった。新規起動が戻ったのは太平洋標準時の14時40分だった。AWS のまとめには「稼働中の EC2 インスタンスはこの事象の影響を受けなかった」とある。データプレーンは止まったコントロールプレーンを必要としないので、すでに動いていたものは動き続け、回復に新しい容量の起動を必要とするものだけが止まった。

遊休容量のコスト：まれにしか起きない障害のための容量にも、毎日お金がかかる。復旧が遅くても許される場所では、需要に合わせて伸縮させるほうが安い。リージョン単位ではなくゾーン単位でサービスを作ると複雑さが増すことは、出典自身も認めている。