博士

やあ、ロボ子！今日はHightouch Eventsで起きたAWSの障害とAurora RDSの競合状態バグについて話すのじゃ。

ロボ子

博士、こんにちは。AWSの障害でイベント処理が遅延し、Aurora RDSのバグにも遭遇したとのこと、大変でしたね。

博士

そうなんじゃ。2025年10月20日のAWS障害が原因で、イベント処理が遅延したらしいぞ。さらに10月23日にはインフラのアップグレード中にAurora RDSの競合状態バグに遭遇したとのことじゃ。

ロボ子

Hightouch Eventsはユーザーの行動データを収集・一元化し、リアルタイムのパーソナライズをサポートするシステムとのことですが、具体的にはどのような構成になっているんですか？

博士

ふむ、システムはKubernetesクラスタ、Kafka、Postgresで構成されているらしいぞ。AWSの障害時には、Kafkaブローカーへの接続やEC2ノードのプロビジョニング、リアルタイムデータ変換が困難になったみたいじゃ。

ロボ子

なるほど。Aurora RDSはHightouch Eventsの中核となるデータストアなんですね。コンピュートとストレージを分離したアーキテクチャで、高速なフェイルオーバーと効率的な読み取りスケーリングが可能とのことですが、今回のバグはフェイルオーバー時に発生したんですね。

博士

その通り！アップグレード計画では、新しいリードレプリカを追加して、既存のリーダーをアップグレードし、フェイルオーバーをトリガーする予定だったんじゃ。でも、フェイルオーバー時に元のライターがプライマリのままになり、フェイルオーバーが反転してしまったんじゃ。

ロボ子

それで、データベースのメトリクスを確認したところ、フェイルオーバー中にリードレプリカへの接続数、ネットワークトラフィック、コミットスループットが急増したんですね。

博士

そうなんじゃ！バックエンドアプリケーションのログからは、「read-only transactionでUPDATEを実行できない」というエラーが見つかったらしいぞ。データベースのログを調査した結果、昇格されたリーダーと元のライターの両方で同様のログシーケンスが見つかったんじゃ。

ロボ子

フェイルオーバーウィンドウ中に、Auroraが一時的に両方のインスタンスに書き込みを許可し、分散ストレージ層が同時書き込み操作を拒否し、両方のインスタンスがクラッシュしたという仮説を立てたんですね。

博士

そう！同時書き込みを排除するために、データベースへの書き込みを行うすべてのサービスをスケールダウンし、再度フェイルオーバーをトリガーしたところ、フェイルオーバーが正常に完了したんじゃ。これで競合状態の仮説が裏付けられたわけじゃな。

ロボ子

AWSも内部レビューの結果、古いライターの降格プロセスにおける内部シグナリングの問題が根本原因であることを確認したんですね。当面の推奨される緩和策は、Auroraのフェイルオーバー機能を必要な場合にのみ使用し、フェイルオーバー中にDBに対して書き込みが実行されないようにすることとのことです。

博士

その通りじゃ。Hightouch Eventsは、競合状態が理解され、緩和されたため、us-east-1のクラスタを正常にアップサイズできたみたいじゃな。意図的なフェイルオーバーの前にライターを一時停止するように、内部プレイブックを更新し、予期しないライターロールのアドバタイズの反転を検出するための監視を追加したらしいぞ。

ロボ子

今回の教訓として、信頼できるサービスであっても最悪の事態に備えること、優れた可観測性の重要性、大規模な分散システムでは単一のコンポーネントがシステムに与える影響を分離することが稼働時間とメンテナンスに役立つこと、そしてテスト環境は必ずしも本番環境を代表するものではない、という点が挙げられていますね。

博士

その通りじゃ！しかし、ロボ子よ、今回の件で一番驚いたのは、AWSもバグることがあるってことじゃな！まるで、完璧に見えるロボットでも、たまにはドジを踏むようなものじゃ。

ロボ子

博士、それは私に対する当てつけですか？

博士

まさか！ロボ子はいつも完璧じゃからの。…たぶん。