AWSが半年近く落ちる時代に、自分のアーキはどこまで耐えられるか

先週、Ars Technicaでちょっと怖い記事を読んだ。
AWSの中東リージョン（ME-CENTRAL-1とME-SOUTH-1）がドローン攻撃で大規模にダメージを受けて、復旧に「数ヶ月かかる」という話だ。
4月30日付けのAWSダッシュボードにそのまま書いてあった。

被害の内容も具体的で、あるデータセンターではEC2サーバーラック14台がオフラインになり、さらに5台にも影響が出た。
消火設備が作動した際の浸水と冷却システムの故障も重なったらしい。
AWSは3月分の利用料金を全額免除しているが、その金額が推定1億5000万ドル。
リージョンひとつがまるごと半年近く機能しない、という状況が現実に起きている。

「別リージョンに逃げればいい」は本当に機能するか

Dubaiのスーパーアプリ「Careem」は一晩で他リージョンへの移行を完了して復旧できたと報じられていた。
すごいな、とは思う。でも正直、自分のプロダクトで同じことができるかと問われたら、すぐ「はい」とは言えない。

個人開発レベルでも、仕事のスタートアップ環境でも、「マルチリージョン対応」って言葉の重さを改めて考えさせられた。
データのバックアップはS3に取ってる。でもそのS3バケット、リージョンはどこに設定してるっけ？
という話だ。

自分が今触っているサービスを確認したら、こんな状態だった。

• RDSのスナップショットはシングルリージョンにしか保存していなかった
• Lambdaのデプロイパッケージ、別リージョンへのコピーは手動でしかやったことがない
• IaCはTerraformで書いてるが、別リージョン向けのワークスペースを用意していない

Careemみたいに一晩で移行できる体制、自分には全然できてない。

「有事の移行」ではなく「日常の設計」の話だと思う

マルチリージョン対応って、障害が起きてから考えるものじゃなくて、最初から設計に折り込んでおくものだ。
でも現実的に、スタートアップで小さいチームだと後回しにしがちなのはわかる。
優先度はいつもフィーチャー開発になる。

今回の件で少し考え方が変わった部分がある。
リージョン障害のリスクを「戦争が起きたときの話」と括ってしまうのは甘い。
大規模な自然災害でも、サイバー攻撃でも、物理インフラへのダメージというベクターは現実に存在する。
AWSが請求を止めてくれるのはありがたいが、自分のサービスが半年落ちたら請求どころの話ではない。

Terraformで書いてるなら、別リージョン向けのワークスペースを作るコストは思ったより低い。

workspace {
  name = "prod-ap-northeast-1"
}

これをap-southeast-1向けにも持っておくだけで、少なくとも「移行できる状態」には近づける。
RDSのクロスリージョンスナップショットも設定一行の話だ。

今週の自分のタスクに「バックアップ先リージョンの確認と修正」を入れた。
小さい作業だけど、今回の記事を読んで「やっておかないとな」という気持ちになった。
あなたのプロダクトのS3バケットとRDSスナップショット、一度確認してみてほしい。