マーク・マーレはNetActuateのCEOである。
10月20日は世界中の企業にとって実践的な訓練となり、その後11月18日にも別の障害が発生した。これらの大規模なインターネット障害は厳しい現実を思い出させた：もしあなたのビジネスが単一のクラウドリージョンや単一のベンダーに依存しているなら、あなたの収益はそのベンダーの最悪の日に左右されるということだ。
今回のケースでは、世界最大級のクラウドプロバイダーの一つが非常に厳しい一日を経験した。数時間に及ぶ障害は、後にドメインネームシステム（DNS）の問題に関連していたことが判明し、主要なアプリ、ウェブサイト、金融機関全体に広範な問題を引き起こした。しかし、これは単に一つのプロバイダーについての話ではない。基本的なインフラ設計の選択が、障害を局所化できるか、あるいはビジネス全体に連鎖的に広がるかを左右することを示している。
オープン、分散化、相互運用性
集中リスクはビジネスリスクである。これは金融ポートフォリオ管理で見られる分散投資と同じ概念だ。一般的な金融計画のアドバイスでは、すべての卵を一つのバスケット（単一の株）に入れるのではなく、ETF、インデックスファンド、その他の資産を組み合わせてポートフォリオを分散させるよう勧めている。私は顧客に対して、彼らのビジネスのエッジインフラについても同様のアドバイスをしている：エッジエコシステムをオープンで、分散化され、相互運用可能なものにすべきだ。
この文脈では、オープンとは、インフラの各部分が標準的なボルトやバーコードで接続されており、物流計画全体を書き直すことなくトラックを交換したり船の経路を変更したりできることを意味する。分散化とは、エンドユーザーに近いエッジロケーションで組み合わせて展開できる独立したモジュラーリソースにアクセスでき、各作業に最適な部品を選択できることを意味する。そして相互運用性とは、システムが独自のサイロにロックインされることなく異なるプロバイダーとシームレスに統合でき、新しい変更や要件に適応し、一貫したグローバル運用を維持できることを意味する。
障害やサプライヤーの変更は避けられない。あなたの切り替えコストと回復時間は、スタックのどれだけの部分が独自の仕様ではなく共通のレールを使用しているかによって決まる。
2つのチームの物語
次のように考えてみよう。2つの消費者向けアプリの2つのチームが10月20日に同じニュースで目を覚ました。
チームAはそのインフラをすべて単一のクラウドプロバイダーに複数のアベイラビリティゾーンにわたって集約していた—そしてプロバイダーの主要な米国東部リージョンハブがサービスを失ったとき、チームAのすべての顧客もサービスを失った。アプリケーションがダウンし、ログイン画面が停止し、怒った顧客がサポートデスクに殺到した。オンラインビジネスは12時間オフラインとなり、大幅な収益と生産性の損失をもたらした。
チームBも同じ障害で目を覚ました。しかし同社は移植性を念頭にインフラを構築しており、標準的なコンテナ、公開されたAPIコントラクト、そしてエニーキャスト技術を使用して単一のクラウドの外部に存在するトラフィックフロントドアでアプリをパッケージ化していた。
チームBはすでにベンダーに依存しないテレメトリフォーマット、つまり異なるプラットフォーム間でデータを収集・監視するためのオープンで分散化され相互運用可能な方法を展開していたため、障害に迅速に対応することができた。アラームが鳴ると、チームメンバーはユーザーの一部を別のリージョンに移動させただけだった。彼らはログインとチェックアウトプロセスが適切に機能していることを確認し、通常通りビジネスを続行した。顧客は一時的な遅延に気づいたかもしれないが、サービスの損失はなかった。
両チームは同じ出来事に遭遇したが、結果は劇的に異なった。そして大きな教訓は、運ではなく設計がその違いを生み出したということだ。
次の訓練まで設計上の脆弱性を忘れがちだが、この問題を無視するリスクは膨大だ。私は毎週、数十億ドルの取引を行っている企業の顧客と話をしている。8時間や12時間の障害は四半期の業績を左右する可能性がある。私はまだ、単一のクラウドプロバイダーからのインフラに毎月数百万ドルを費やしている企業を見て驚いている。彼らは目に見えないベンダーロックインにより、障害のリスクがより高いことに気づいていないのだ。
回復力を設計するための5つの戦略
1. 移植性の単位を選ぶ
収益に重要な各サービスについて、2つの環境間で完全に移動する必要がある最小のバンドルを定義する。ここでオープンソースAPIを使用し、2つの場所でシームレスに実行されることを証明できる。それをパッケージ化し、文書化する。そして次の障害が発生したとき、プラットフォーム間の移行は外科手術ではなく標準的なケアになる。
2. 計測器を標準化する
オープンテレメトリを使用して、すべてのサービス間で同じデータをトレースしていることを確認する。目標は、ダッシュボードがいくつあっても、見るダイヤルが1セットだけであることだ。監視ツールは維持しつつ、それらがすべて同じ方法で読み取ることを要求する。
3. フロントドアを中立に保つ
標準化と自律性を優先する。エニーキャストなどの技術を使用して、単一のクラウドの外部でグローバルトラフィックとDNSを所有する「中立的なフロントドア」をビジネスのために構築する。
4. どこでも同じ方法でアンダーレイを自動化する
特定のインシデントを解決するための詳細な手順書であるランブックを開発し、標準的なオープンソース構成を持つようにする。ランブックはビジネスが運営している複数ベンダーの現実を生き残ることができ、またそうすべきだ。
私は、単一のクラウドプロバイダーのサービスの囲い込まれた庭に自らを閉じ込めてしまった顧客とあまりにも多く話をしている。別のクラウドや自社のデータセンターに移行するには、膨大なエンジニアリング作業が必要になる。
オープン性と柔軟性を持って一からビルドを始めるオプションがあるなら、そのチャンスを掴むべきだ。すでに単一のベンダーにロックインされている場合でも、移植可能な方法でそのベンダーと連携し続けることができる。さらにロックインするために独自のツールを使い続ける必要はない。良い最初のステップは、中立的なフロントドアに戻り、DNSとロードバランシングの制御に焦点を当てることだ。
5. クラウド統合を再利用可能にする
複数の通信事業者間で機能する方法で統合を構築する。これは特に会社がモバイルアプリを持っている場合に重要な、単一リージョンや単一ベンダーの考え方という一般的な罠から脱出するもう一つの方法だ。
回復力は設計上の選択だ。オープンで移植可能なシステムは、クラウドやネットワークのインシデントの影響範囲を制限するのに役立つ。あるいは別の言い方をすれば、オープン標準は2回お金を節約できる。今日の統合コストと明日の切り替えコストの両方を削減するのだ。この最新の障害は、リスクを減らし回復力を強化するために、会社のインフラをオープンソースでマルチベンダー対応になるよう設計すべきだということを改めて思い出させるものだった。
