4 月 29 日の Braze 障害: 何が起こったのか、なぜ発生したのか、そしてどのように対応しているのか

Braze プラットフォームのサービス アーキテクチャを理解する

Braze は、米国内の 8 つのクラスターごとに個別のサーバー セットを維持しています。 Braze US 01 ～ 07 クラスターはアマゾン ウェブ サービス (AWS) でホストされ、Braze US 08 クラスターは Microsoft Azure でホストされます。 これらの各環境で、Braze は複数のアベイラビリティ ゾーンを使用し、システムの各部分に冗長性を持たせています。 アベイラビリティ ゾーンに障害が発生した場合は、障害のあるアベイラビリティ ゾーンのルーティングと処理を定期的かつ透過的に無効にします。 これにより、クラウド サービス プロバイダーの停止中にもサービスの提供可能性を確実に維持できるようになります。

いくつかの例外を除いて、米国の各クラスターには独自の専用インフラストラクチャがあり、特定のクラウド リージョン内のすべての環境で使用される少数のコンポーネントを除いて、これらのクラスターはリスクを軽減するために相互に高度に分離されています。 1 つのクラスターでの中断が他のクラスターに影響を与えるということです。

Braze プラットフォームのリアルタイム処理ワークロードの強度のため、2013 年以来、Rackspace と提携して、MongoDB データベースを実行するためのカスタム構成のハードウェアをホストすることで、AWS と Azure の使用を補完してきました。 当社の AWS および Azure 環境は、AWS Direct Connect および Azure ExpressRoute プライベート クラウド コネクタを使用して構成されており、専用の光ファイバー ケーブルを介して、クラウド環境を Rackspace データ センターに維持されている内部ネットワークに接続します。 この暗号化された接続は、1 秒あたり 100 ギガビットを超えるネットワーク トラフィックを送信する複数のインターフェイスをサポートするネットワーク リンクを利用して、クラウドと Rackspace 環境の間に高パフォーマンスのアクセスを提供します。

Rackspace のカスタム環境には、Braze 専用のキャビネットに収容された数百台の物理サーバーがあります。 このセットアップには、冗長電源と冗長トップオブラック スイッチが含まれます。 トップオブラック スイッチは、サーバー ラック内に設置され、同じサーバー ラック内のデバイスとサーバーを接続するネットワーク デバイスです。 これらのスイッチは、影響を与えないフェールオーバーについて少なくとも年に 1 回テストされます。 昨年のテストは、2023 年 8 月 3 日に無事に開催されました。このカスタム環境では、MongoDB データベース用に数万の仮想化コンテナーを維持しています。 当社のクラウド環境と同様に、当社では、中断を最小限に抑え、あるコンテナが当社のデータベース内の他のコンテナに影響を与えるリスクを軽減するために、米国の異なるクラスター上のコンテナ間で高レベルの物理的分離を維持しています。

4 月 29 日の障害の原因とその対応

最初の部分的なスイッチ障害

4 月 29 日 09:15 UTC、Rackspace サーバー キャビネットに接続されているプラ​​イマリ Cisco Nexus ネットワーク スイッチに部分的な障害が発生しました。 故障したスイッチに障害が発生し、フェイルオーバーによってセカンダリ ネットワーク スイッチが自動的にアクティブ化されず、故障したスイッチがプライマリとして維持されました。

ネットワーク スイッチは、「フレーム」と呼ばれるネットワーク パケットを宛先に転送することによってトラフィックをルーティングします。 これを効率的に行うために、これらのスイッチは、デバイスを相互に接続するネットワーク トポロジの理解を維持します。 ネットワーク ルートは、個々のコンポーネントの障害や速度の低下に応じて動的に変更されるのが一般的です。 これらの変更が発生すると、スイッチと他のネットワーク デバイスは相互に通信して、ネットワーク トポロジの正確な理解を維持します。

大規模なネットワークでは、デバイス間に複数のパスが存在することが多く、ルーティングの「ループ」（つまり、パケットが目的の宛先で停止できず、発信元にループバックする状態）が発生する可能性があります。 ループは「ブロードキャスト ストーム」を引き起こす可能性があり、トラフィックが無限にループし、ネットワーク リンクが飽和状態になり、停止が発生します。 これを防ぐために、スイッチは冗長リンクの識別に役立つメッセージを送信するようにプログラムされています。 これらのメッセージはスパニング ツリー ブリッジ プロトコル データ ユニット (BPDU) と呼ばれ、スパニング ツリー プロトコル (STP) と呼ばれるネットワーク プロトコルの一部です。 次に、スイッチはこの情報を使用してトラフィック ポートをブロックし、トラフィックのルーティング時にループが発生するのを防ぎます。 物理リンクまたはスイッチに障害が発生した場合、STP はトラフィックを送信できる他の物理リンクを識別し、接続を維持するために以前はパッシブ (つまりブロックされていた) リンクをアクティブに昇格させるために使用できるため、冗長性の提供に役立ちます。

4 月 29 日のインシデントが発生し、スイッチが誤動作し始めたとき、スイッチはトポロジ変更通知と BPDU を継続的に転送し始め、ネットワークにそれらの変更通知があふれました。 これらのパケットはディストリビューション スイッチや他のスイッチに伝播し、スパニング ツリー スイッチング ループを引き起こし、ネットワークが完全に停止しました。 STP は、ループが検出されたネットワーク ポートをブロックすることでネットワーク ループを軽減するために導入されていますが、4 月 29 日のインシデントでは、故障したスイッチから誤って転送されたスパニング ツリー トラフィックにより、ネットワーク内の他のスイッチがスパニング ツリー トポロジを再分析することになりました。 その後、他のスイッチが、故障したスイッチから高優先度の BPDU パケットが送信されていることを検出したため、ディストリビューション スイッチが以前にブロックされていたポートで転送を開始し、その結果、スイッチング ループが発生してネットワークに過負荷がかかり、ネットワークがダウンしました。

Rackspace の修復

この活動の結果、Rackspace データセンターのエンジニアは、UTC 09:20 頃に予期せぬネットワーク接続の問題に関するアラートを受信し、問題への対処を開始しました。 UTC 09:39 から 10:03 の間に、Rackspace データセンターのエンジニアはネットワーク スイッチを一時停止し、プライマリ スイッチの電源を入れ直し、サーバー キャビネット内のネットワーク インターフェイス カード (NIC) を強制的にセカンダリ スイッチにフェールオーバーさせました。 NIC フェイルオーバー後、Braze 環境内の物理サーバーへの接続が復元されました。

Braze MongoDB データベースの機能の仕組み

Braze が使用する MongoDB データベースを使用すると、「シャード」と呼ばれる複数のデータベース サーバーにデータを保存できます。 MongoDB は、「mongoS」と呼ばれるルーティング サービスを提供します。これは、Braze プラットフォームのサービスからのクエリを処理し、シャード クラスター内の関連データの場所を特定し、クエリを適切な MongoDB データベースにルーティングします。 Braze には、データベースを実行し、特定の MongoDB シャードのデータを保存するプログラムである 15,000 を超える「mongoD」プロセスで構成される、数百もの個別の MongoDB データベースがあります。

各データベース シャードは、1 つのプライマリ mongoD プロセスと少なくとも 2 つのセカンダリ mongoD プロセスで構成され、障害発生時に高可用性を提供します。 各 mongoS サーバーは、クエリをルーティングできるすべての mongoD へのネットワーク接続を維持します。 これらの mongoD プロセスは、その構成内のプライマリおよびセカンダリにも接続します。 これはレプリカ セットと呼ばれます。 mongoS が特定の mongoD に接続できない場合、そのプロセスをオフラインとしてマークし、再試行をスケジュールします。 同様に、mongoD が 1 秒以内にレプリカ セットの他の mongoD メンバーに接続できない場合、タイムアウトになり、それらのプロセスがオフラインとしてマークされ、再試行がスケジュールされます。

MongoDB プロセスに対するネットワーク ループの影響とその対応方法

ネットワーク ループ中に、MongoDB プロセスが正常に接続できなかったため、各プロセスは関連するすべてのプロセスをオフラインとしてマークしました。 つまり、各 mongoS プロセスは、関連するすべての mongoD プロセスをオフラインとしてマークし、各 mongoD プロセスは、関連するレプリカ セット メンバーをオフラインとしてマークします。 ただし、Rackspace によって物理サーバーへのネットワーク接続が復元された後でも、mongoS プロセスも mongoD プロセスも、オフラインとしてマークされていた他のプロセスへのすべての接続を再確立しませんでした。

この時点で、Rackspace データベース管理者 (DBA) チームの修復作業を支援するために、Braze DevOps チームは接続を復元する方法のデバッグとテストを迅速に開始しました。 私たちの調査により、利用可能な唯一のオプションは、仮想化コンテナ内の約 16,000 の mongoD プロセスと 6,000 以上の mongoS プロセスをすべて再起動することであることが判明しました。 この取り組みの規模が非常に大きいことと、これほど多くのコンテナを迅速に再起動するための自動化が存在しなかったという事実を考慮して、Rackspace のエンジニアはインシデント中に新しいコードを作成して、オンザフライ自動化機能を作成しました。

残念ながら、再起動プロセスが進むにつれて、ドメイン ネーム システム (DNS) システムで別の問題が発生しました。 mongoS および mongoD プロセスがオンラインになると、DNS ルックアップと呼ばれるプロセスで DNS リゾルバーに情報を要求します。 再起動の速度によって継続的に DNS ルックアップが行われるため、DNS サーバーに大きな負荷がかかり、mongoD プロセスに再接続するときに mongoS レイヤーで接続タイムアウトが発生しました。 この増大する負荷に対応するために、Rackspace チームは DNS CPU 容量を増やしましたが、その後、各 mongoS から関連する mongoD プロセスへの健全な接続を作成するために、mongoS 層を 2 回再起動する必要がありました。

UTC 17:05 頃、再起動プロセスにより、一部のクラスターがオンラインに戻り始めました。 データベースのパフォーマンスが回復し、クラスターが安定するにつれて、Braze はデータ処理とメッセージ送信能力を強化し続けました。 しかし、以前の利用不能による大量のバックログにより、その取り組みは複雑化しました。

数百の異なるデータベースで構成される Rackspace データベース環境の規模と高度さ、停止の長さ、および結果として生じるバックログの量 (数十億のメッセージと数十億の取り込まれたデータ ポイントを表す) を考慮すると、復旧プロセスに必要となるのは、 -通常の回復プロセスの現時点での適応。 これは、大量の全体処理能力の導入など、データベース リソースが進行中の処理需要とのバランスを保つために必要でした。

しかし、そうすることで、Braze がプロビジョニングできる仮想 CPU の数の AWS 制限に達し、追加のサーバー容量を追加できなくなりました。 Braze チームはこの状況を AWS チームに急速にエスカレーションし、増額を受けました。これにより、当社のエンジニアはサーバー処理能力を記録的なレベルにスケールアップすることができました。これは、Black で達成されていた以前の最大能力よりも 50% 以上高いものでした。 2023年の金曜日。

UTC 20:30 までに、US 01、US 03、US 08 を除くすべての米国クラスターはバックログの処理を終了し、残りのクラスターはインシデント前日のピーク レート以上で処理していました。 数時間以内に、すべてのクラスターがリアルタイム処理に戻り、インシデントが解決されたと宣言しました。

Braze がインシデント中に更新情報を伝達する方法

このような事件が発生した場合には、明確かつ頻繁なコミュニケーションが不可欠です。 一般に技術的な問題が発生することはまれであり、この規模の問題は Braze にとってこれまで前例のないことでしたが、私たちは影響を受ける当事者と明確かつ迅速にコミュニケーションをとるために常に最善を尽くしています。

このような状況では、当社のコミュニケーション戦略に影響を与える基本原則は、誠実さ、透明性、信頼です。 私たちは、何が起こっているかについて正直かつ率直に話す機会が 1 回しかないこと、また、インシデントに関する透明性が、その瞬間とその解決後の両方で、信頼を維持するために不可欠であることを理解しています。 結局のところ、Braze はあらゆるインシデントの説明、修復、再発防止に常に全力を尽くすということをお客様に確信していただきたいと考えています。

インシデント発生時には、ステータス ページを使用してコミュニケーションを管理し、状況に関する定期的な最新情報を提供します。 最新情報を入手するために、そのページから更新情報にサインアップすることを強くお勧めします。 4 月 29 日の停止中、私たちはステータス ページの頻繁な更新を、私の共同創業者であり CEO である Bill Magnuson からのメールで補いました。 そのメッセージはすべての Braze ダッシュボード ユーザーに送信され、必要に応じて他の顧客関係者と共有するためにアカウント チームに提供されました。

Braze が事件を追跡調査した方法と今後の防止計画

このインシデントが発生するまで、私たちはこれまでの経験から、ネットワーク スイッチが冗長化されているため、ネットワークには回復力があると信じていました。 しかし、この障害により、10 年以上にわたって当社をうまくサポートしてきたネットワーク トポロジが、壊滅的な障害に対して脆弱であることが明らかになりました。 今後さらに強化しなければならないことは明らかです。

インシデント以来、Braze と Rackspace は交換して障害のあるスイッチを交換し、Rackspace エンジニアリング チームは Braze サービスが依存するネットワーク インフラストラクチャの完全な監査を完了しました。 ハードウェア障害は、特に保証期間内の機器の場合、予測することが非常に困難ですが、異常を検出し、迅速な対応を確保するために監視が行われています。 両チームは現在、機器に故障が発生した場合でも将来のネットワーク ループを防ぐための変更を行うために協力しています。 ループに対する保護をさらに強化するためにネットワーク トポロジに有意義な変更を加える予定であるため、一部のネットワーク変更は実装に時間がかかります。 また、私たちが経験した障害シナリオをより深く理解し、ネットワーク障害後の mongoD および mongoS プロセスの自己修復機能を向上させるために、Cisco と MongoDB の両方にサポート チケットをオープンしました。

私たちはインシデント以来、Rackspace と毎日連絡を取り合い、短期的な変化に対応し、より大規模なネットワーク拡張を実行してきました。改善され、より回復力のあるネットワーク設計が達成されたと確信できるまで、今後も連絡を取り続けます。

この事件と、それが貴社のビジネスおよび顧客との関係に与えた影響について、改めてお詫びを申し上げます。 Braze が利用できなかった時間の長さは容認できません。 当社のエンジニアリングリーダーシップと経営陣は、機能停止の脆弱性をできるだけ迅速かつ効率的に特定して解決するために必要な変更をすべて行うことに全力で取り組んでおり、信頼できるパフォーマンスの高いパートナーとして再びお客様の信頼を獲得できるようにしています。

— ジョン