要約

  • Kinesisのフロントエンドは、仲間のサーバーが増えると既存機も通信に使うスレッドを増やした。増設が全台をOS設定の上限に押し上げ、経路情報を作れなくした。
  • 再起動時の情報再構築と利用者のリクエスト処理が資源を奪い合った。原因を取り除いても、一斉にサービスへ戻すことはできなかった。

サーバーを買い足したのに、使えるサービスが減った。2020年11月25日、米国北バージニアのKinesisで起きたのは、そんな増設だった。

AWSの事故報告によると、規模の小さいフロントエンドの増強が、全サーバーをOS設定の最大スレッド数に到達させた。同社は増強を引き金、スレッドの上限を根本原因と整理している。利用者の注文が急増したという話に置き換えると、この事故の肝が消える。

新しいサーバーには処理能力がある。同時に、既存のサーバーにも新しい相手と連絡を取る仕事を発生させる。容量を足すたびに、その容量を管理する費用も増えていた。

案内役の地図ができなくなった

Kinesisのバックエンドは、分割されたデータストリームをセル単位のクラスターで処理していた。フロントエンドは認証、流量制限、適切な処理先への振り分けを担当する。そのために必要なのが、構成メンバーと各シャードの担当を示す情報だった。

各フロントエンドは、この地図を複数の情報源から組み立てる。ほかのフロントエンドから受け取るメッセージもその一つで、相手ごとにOSのスレッドを作っていた。新規サーバーが入ると、すでに稼働中のメンバーも相手を見つけ、通信を準備する。認識に最大1時間かかることもあった。

上限に達すると、地図の構築が完了しなくなった。処理先の能力が残っていても、入り口から依頼を届けられない。裏方の調整が、商品としてのサービスを止めた。

バックエンドをセルに分けた設計だけでは、フロントエンドの共有範囲は狭くならない。「分離済み」という説明を聞いたら、どの部品が何から切り離されているのかまで確認する必要がある。サービス名や構成図の箱だけでは分からない。

戻すにも順番があった

AWSは追加した容量を撤去し、十分なテストをせずにOSの上限を上げることは避けた。そこから、復旧を急げば急ぐほどよいとはいかない時間が始まった。

起動したサーバーは地図を作り直す。この作業と、利用者から来るリクエストが同じ資源を使う。一度に戻しすぎると応答が遅れ、異常なサーバーと判定されて再び外されかねない。せっかく増やした復旧台数が、また減ることになる。

起動時には周囲のサーバーを頼る代わりに、基準となるメタデータの保存先を直接読むよう設定が変えられた。それでも数千台のフロントエンドを戻すペースは、毎時数百台に抑えられた。最初の一群がリクエストを受け始めたのは太平洋標準時10時07分。Kinesisが正常に戻ったのは22時23分で、その間にエラー率は下がっていった。

問題の特定、修正、全体の回復は、それぞれ別の到達点だった。購買の場で見せられる平常時の処理量には、この立て直しの速度が含まれていないことがある。機械を持っていることと、その機械に安全に仕事を戻せることの間に、営業時間が落ちていく。

補助機能が本業の入口をふさいだ

影響はKinesisを直接使う顧客だけにとどまらなかった。CognitoはAPI利用状況を分析する情報をKinesisに送り、送れない分を手元で一時保存していた。長引く障害でバッファー処理の潜在的な不具合が表れ、ウェブサーバーが詰まった。利用者の認証や一時的な認証情報の取得に支障が出た。

記録のための情報が、利用者を通す入口を止めた。バッファーの存在だけでは、切り離しができているか判断できない。満杯になった後に何を続け、何を止めるかが決め手になる。

CloudWatchではメトリクスとログの処理に問題が生じ、一部のアラームがデータ不足の状態に入った。それを使う反応型の自動スケーリングも遅れた。Lambdaではメトリクスのバッファーが実行ホストのメモリーを圧迫し、呼び出しのエラーが増えた。一つの上流障害が、下流の別々の資源制約を表に出した。

通常のサービス状況の投稿ツールもCognitoに依存していた。依存の少ない予備ツールは動いたが、手作業が多く、担当者も使い慣れていなかったため、初期の発信に遅れが出た。故障を説明する道具にも、故障から離れた足場が必要だった。

「もっと大きい機械」の意味

事故後にAWSが示した短期策には、CPUとメモリーの大きな機械へ移り、サーバーの総数を減らす案があった。総数を減らせば、各サーバーが連絡する相手と必要なスレッドも減る。性能向上を買うと同時に、連絡先を減らすわけだ。

スレッド監視の細分化、上限引き上げのテスト、起動時間の短縮も挙げられた。キャッシュの分離、一部の大型サービス向けフロントエンドの分割、セル化の加速は、共有する範囲を変える対策だった。

AWSの静的安定性の解説は、依存先の不調があっても既存の仕事を続けられるよう、事前に備える設計を扱っている。耐障害性と障害分離の説明には、予備の資源を用意する費用も登場する。空き容量には請求が来る。回復を待つ時間にも、顧客の側で費用が発生する。

この報告書には現在のフロントエンド上限や直近の全体再起動試験は載っていない。条件が分かる現行試験があれば、現在の復旧能力を判断し直せる。2020年の記録から確実に持ち帰れる質問はある。増設後の処理量に加えて、全体を立て直す速度も買えているだろうか。