ロック、飽和、CDNネットワークの問題がCanvaをダウンさせた理由

原文リンク(2025-02-08)

Canvaのエンジニアリングチームは最近、昨年11月に経験した障害に関する事後報告を発表し、API Gatewayの障害と、この事故で学んだ教訓について詳しく説明した。CanvaのCTOであるBrendan Humphreys氏は、次のように認めている：

2024年11月12日、Canvaはcanva.comの可用性に影響を与える重大な障害を経験しました。午前9時8分（UTC）から午前10時（UTC）頃まで、canva.comは利用できませんでした。これは、Canvaのエディタのソフトウェアデプロイメント、ロッキングの問題、CDNプロバイダーであるCloudflareのネットワークの問題など、複数の要因によってAPI Gatewayクラスタに障害が発生したことが原因です。

Canvaのエディタはシングルページのアプリケーションで、毎日複数回デプロイされ、クライアントデバイスは階層型キャッシュシステムを使ってCloudflare経由で新しいアセットをフェッチする。しかし、CDNプロバイダー内のルーティングの問題により、2つのリージョン間のトラフィックが中断された。その結果、CDNでアセットが利用可能になると、すべてのクライアントが同時にダウンロードを開始した。その結果、270,000件以上の保留中のリクエストが同時に完了し、突然の急増につながった。Humphreys氏はこう説明する：

通常であれば、エラーが増加すると、カナリアシステムはデプロイを中止します。しかし、今回はリクエストが完了しなかったため、エラーは記録されませんでした。その結果、JavaScriptファイルに対する270,000件以上のユーザーリクエストが、同じキャッシュストリーム上で待機することになりました。

出典：Canvaエンジニアリング・ブログ

Airbnbのスタッフ・ソフトウェア・エンジニアであり、「Surfing Complexity」ブログの著者であるLorin Hochstein氏は、この停電を飽和と回復力の物語と表現している。Hochstein氏は次のように強調する：

このインシデントは、新しいバージョンのコードにバグがあったわけでも、このバージョンのコードに予期せぬ突発的な動作があったわけでもないです。インシデントの引き金となったのはデプロイであったが、前バージョンからの変更はこの停電には重要ではありません。そうではなく、クライアントが新バージョンをダウンロードしたことで発生したシステムの挙動が、障害につながったのです。

突然、新しいオブジェクトパネルがすべての待機デバイスに同時にロードされ、その結果、API Gatewayへのリクエストは毎秒150万を超え、通常のピーク負荷の約3倍の急増となった。この圧倒的な波は、ロードバランサーを「オーバーロードバランサー」に変貌させ、健全なノードを不健全なノードに変えてしまった。Hochstein氏はこう付け加える：

これはポジティブ・フィードバック・ループの典型的な例です。タスクが不健全になればなるほど、健全ななノードが受けるトラフィックが増え、それらのタスクも不健全になる可能性が高まります。

オートスケーリングが追いつかないため、API Gatewayのタスクはメモリの枯渇によって失敗し始め、最終的には完全な崩壊に至った。この問題に対処するため、Canvaのチームは手動で容量を増やすと同時に、ノードの負荷を減らすことを試みたが、結果はまちまちだった。最終的に、CDNレイヤーでトラフィックが完全にブロックされたときに、状況は緩和された。Humphreys氏はこう語る：

午前9時29分（UTC）に、一時的にCloudflareのファイアウォールルールを追加し、CDNですべてのトラフィックをブロックしました。これにより、API Gatewayにトラフィックが到達しなくなり、新しいタスクがリクエストに圧倒されることなく起動できるようになりました。その後、canva.comをステータスページにリダイレクトし、ユーザーにインシデントが発生していることを明確にしました。

Canvaのエンジニアは徐々にトラフィックを増加させ、約20分で完全に復旧させた。HackerNewsの人気スレッドでは、John Nagle氏がコメントしている：

この問題は、電力会社が「ロードテイクアップ」と呼ぶものに似ています。停電後、電源が再供給されると、起動時に多くの電力を消費する負荷があります。電力網の立ち上げは、このように一度に行われるのではなく、部分的に行われます。

当初はすべての機能要件が満たされ、自動化システムが問題を悪化させたが、Hochstein氏はこう強調する：

健全な状態に戻すために、システムの動作を適応させ、機能を変更するのはインシデント対応者の責任でした。これはレジリエンスの典型的な例であり、システムが本来扱うように設計されていない状態に陥ったときに、システムの動作を再構成するために行動することです。

Humphreys氏はLinkedinでこう締めくくっている：

全体像を把握するには、Cloudflare の非常に有能で協力的なパートナーと連携して、しばらく時間がかかりました (中略) パケットの損失、キャッシュ・ダイナミクス、トラフィックの急増、スレッドの競合、タスクのヘッドルームなどを含む興味深い物語です。

今後同様のインシデントが発生する可能性を最小限に抑えるため、チームはトラフィックの遮断と復旧のためのランブック、API Gatewayの回復力の向上など、インシデント対応プロセスの改善に注力した。

作者について

Renato Losio

Renato has extensive experience as a cloud architect, tech lead, and cloud services specialist. Currently, he lives in Berlin and works remotely as a principal cloud architect. His primary areas of interest include cloud services and relational databases. He is an editor at InfoQ and a recognized AWS Data Hero. You can connect with him on LinkedIn.

もっと見るより少なく