Fastlyの大規模障害に「マルチCDNは非現実的」 正しい対策は？ “CDNの中の人”に聞く
コメント
注目のコメント
結局はDNSの向き先をどうするのかって話からは逃れられない訳で。
クライアントからの問い合わせに単一レコードを返す場合は、その単一レコードの向き先をCDN手前準備したCDN分散の仕組みに向けたとしても、そこがシングルポイントになるのでそこが息をしなかった場合、CDNを切り替えるどころか全く応答を返せなくなるので何の解決にもなってません。
という事は必然的にDNSが複数レコードを返した場合にクライアント側の再施行(応答が無かった場合に他のAレコードを試すようにブラウザ含むクライアントアプリが気を利かせているがこれはクライアントアプリ側の実装次第)頼みでやるわけです。
これが無いとそもそも一瞬でDNSから障害発生側を抜いたとしても最短でもTTLに設定された時間はダウンします。そしてTTLを極端に短時間にするとDNS関連のリクエストが跳ね上がるので現実的ではない。
DNSに複数レコード突っ込む前提ならまぁやれば普通にできてしまうのでは？
CloudFrontみたいな完全従量課金ならリクエスト飛んだ分だけなのでコスト的にそんなに問題になる気はしませんけどね。
ただ、、、SSL証明書を入れて回る事とかはまぁ手でやっても年一とかだからまぁ良いとしてもキャッシュクリアとかキャッシュしないpath追加とか運用が面倒かもしれませんね。当然手でやらずにスクリプトとかでやるようにするんでしょうけど。
あとWAFみたいなCDNにも効くFWとか入れてる場合はさらに面倒ですねぇ。
やってできなくはないので、やりたいならやれば良いんじゃないですか？って感じですかね。現状の構成次第ではいろいろ面倒かもしれませんけど。特にFW部分。この記事はCDN大手のアカマイ側の人間のopinionなので、もちろんマルチCDNは非現実的と主張します。
ただ、実際には新たな技術とビジネスモデルを使ってマルチCDNを提供しているスタートアップが既に二、三年前から出てきています！ここにもう少し詳しく
https://wired.jp/2021/06/12/fastly-cdn-internet-outages-2021/
また、今回の障害は Python などの ライブラリダウンロードにも影響があったので、以下にサービスのフロント側のCDNを冗長化しても、バックエンドのバッチなどで、外部サービスからのダウンロードが前提となってしまっていた場合は、影響を受ける可能性があります。
その点も加味しながら、一言にミッションクリティカルと言っても、
外部サービスに依存している部分をどう考えるかは、各社考えたほうが良いのかも。
（オンプレだけで運用していたときは、NW以外は殆どコントロール出来たんだけど、今は無理ですし）
