先週のKagi事件に関する事後分析

 (status.kagi.com)
1 ポイント 投稿者 GN⁺ 2024-01-18 | 1件のコメント | WhatsAppで共有

Kagi.com サービス不安定問題の解決

  • 調査中 - デプロイ後に問題が発生し、チームが解決作業を進めている。 (1月12日 16:45 UTC)
  • 監視中 - 問題の原因と見られる設定変更を元に戻し、サービスが正常に戻ることを継続的に監視している。 (1月12日 18:30 UTC)
  • 更新 - 安定性を完全に回復するため、一時的にトラフィックを停止し、ユーザーをこのページにリダイレクトする予定。サービスへの負荷を制御された形で復旧させる間、状況の進展に応じて追加の詳細を提供する予定。 (1月12日 20:26 UTC)
  • 監視中 - トラフィックは復旧しており、サービスが完全に正常へ戻ることを引き続き監視している。 (1月12日 21:14 UTC)
  • 解決済み - すべてのサービスは正常に稼働中。問題解決まで待ってくれたユーザーに感謝を表明した。

事後分析

  • Kagiの技術リーダーであるZacが、先週のサービス障害に関する詳細な事後分析を共有した。
  • この事件への対応として、シニアエンジニアのSethとDevOpsエンジニアのLuanが協力して作業した。
  • サービスを悪用し、インフラのボトルネックを突いた行為者が存在しており、即時の緩和措置を講じるとともに、コードとコミュニケーションの複数の領域で改善作業を進めている。

事案の経過

  • 1月12日午後5時30分ごろ、内部監視とユーザーからの問題報告を通じて、インフラ障害が発生していることを把握した。
  • 問題の性質としては、さまざまな地域のユーザーに対して読み込みの遅延やページタイムアウトを引き起こしていた。
  • 問題の解決には相当な時間を要し、その背景、進捗状況、今後の計画について説明した。

技術的な問題解決の過程

  • 当初は偶然にも、VMの追加RAMリソースへのアップグレードと同時に問題が発生した。
  • 監視では高いレイテンシと、アプリケーションのデータベース接続プールの問題が報告されていた。
  • 接続プールは飽和状態に達しており、これは接続総数が設定された最大接続数の上限を超えていたことを意味する。
  • データベースの内部的な健全性とクエリ性能を評価する間、いくつかのインスタンスを置き換えて混雑緩和の効果を試した。
  • インスタンスの一部を置き換えることが有効に見えたため、すべての接続プールを一度に完全にリセットするためにユーザートラフィックを一時停止した。
  • データベースの状態を調査したところ、ユーザーテーブルの行に対する高い競合が根本原因であることが明らかになった。
  • この競合により書き込みレイテンシが急激に増加し、アプリケーションの接続プールにバックプレッシャーがかかり、最終的に利用可能なすべての接続が枯渇した。
  • Kagiはこれまで、GCPで利用可能な最も安価なシングルコアのデータベースを使用しており、これはデータベースを容易に麻痺させるリスクを抱えていた。
  • 悪質な行為者を特定し、24時間以内に作成されたアカウントや、短時間で60,000回以上の検索を実行した単一ユーザーアカウントを突き止めた。
  • 当該アカウントの検索機能を削除し、問題を引き起こしていた特定の書き込みを無効化するホットフィックスを発行した。
  • 深夜までに問題は完全に解決され、行為者が戻ってくる兆候がないか引き続き注意深く監視している。

今後の対応

  • この事件から多くを学び、システムをさらに強化し、インシデント発生時のコミュニケーションプロセスを改善するための即時の計画をすでに進めている。
  • まず、ステータスページの更新が迅速ではなかったことを認めている。
  • ユーザーに自動化された内部監視をより簡単に公開できるステータスページプラットフォームへ移行し、プラットフォームの健全性をリアルタイムで把握できるようにする予定。
  • 問題を引き起こすクエリを直接緩和し、同様の欠陥がさらに存在するかを確認するために負荷テストを実行している。
  • 追加の監視を導入し、インフラ内の正しい箇所をより早く指し示せるようにして、今回のように誤ったシグナルを追いかけて時間を無駄にしないようにする予定。
  • この種の悪用を検知するシステムを強化しており、性能面だけでなくコストも直接発生するため、自動化された制限を設定してそれを適用する必要がある。
  • 新しい制限はこの投稿時点ですでに施行されており、その影響を監視し、必要に応じて継続的に調整していく予定。
  • Kagiへのアクセスが誤ってブロックされたと考えられる場合は、support@kagi.com へ連絡してほしいと呼びかけている。

GN⁺の見解

  • Kagiは、ユーザーテーブルの行競合による書き込みレイテンシの問題に直面し、それがアプリケーションの接続プールにバックプレッシャーを与えてサービス停止を引き起こした。
  • この問題は、KagiがGCPで最も安価なシングルコアのデータベースを使用していたことで生じたリスクの結果だった。
  • Kagiチームは今回の事件を通じて、システムの強化、ユーザーとのコミュニケーション改善、悪用防止のための自動化された制限の設定といった措置を講じることで、サービスの安定性と透明性を高めようとする努力を示した。こうした取り組みは、ユーザーにより信頼できるサービスを提供しようとするKagiの意思を反映している。

関連記事

1件のコメント

 
GN⁺ 2024-01-18
Hacker Newsの意見

  • インフラのアップグレードと同時に発生したインシデントに関する意見

    • VM に追加の RAM リソースを投入するインフラアップグレードを行っていたのと同時にインシデントが発生したのは、まったくの偶然だったという。
    • このような「偶然」はよく起こるもので、問題解決中に自分の正気を疑いたくなることがあると述べている。
    • 問題対応中にパニックになると、別のものを壊すホットフィックスを適用してしまうことがあり、これはシステム管理者や開発者にとって残酷なマーフィーの法則になりうると警告している。

  • Kagi のステータスページに関するユーザー体験

    • ユーザーは、Kagi のステータスページがすべて正常に動作していると表示していたため、不安を感じたという。
    • 以前利用していたサービスではステータスページがすぐ更新され、自分の端末の問題ではないと分かったと比較している。
    • 今後も Kagi を使う予定だが、ポストモーテムで言及されていたように、ステータスページのコードを別のサービス／プラットフォームへ移すことを望むと述べている。

  • 個人的な経験を共有するコメント

    • 個人的に同種のサービス停止を何度も経験しており、データベース接続プールの健全性に関する問題の解決を試みたことがあると共有している。
    • データベースの一般的な飽和指標（CPU%、IOPS など）はこうした停止の間も大きく変化しないことがあり、代わりにロック競合が原因になっている可能性があると指摘している。
    • Kagi が使用している RDBMS については、グローバルな I/O 待機時間、ロック取得時間、クエリ実行時間などをグラフ化するのがよいと提案している。

  • スタートアップの経験に関するコメント

    • すべてのスタートアップは、いずれこうした問題を経験することになると述べている。
    • それを防ぐ能力を構築するだけの時間やリソースが足りなかったり、特定の問題が起こるとは想定していなかったりすることもあるという。
    • 透明性と学習は重要だが、ときには補償も重要だとし、Kagi がサービスを利用できなかった時間に対して検索クレジットの提供を検討すべきだと提案している。

  • 内部システムの可観測性に関するコメント

    • 問題をもっと早く認識すべきだったと指摘し、適切な Datadog ダッシュボードと Splunk クエリがあれば、問題はもっと早く明確になっていたはずだと述べている。
    • より良い監視に投資し、学習の機会にすべきだと助言している。

  • Kagi の信頼性に関する有料ユーザーの意見

    • Kagi のダウンタイムを経験した有料ユーザーは、Google の信頼性を当たり前のものとして受け止めていたと気づいたという。
    • 検索エンジンへのアクセスが止まることは大きな障害になりうると述べ、Kagi は大好きだが、ダウンタイムを経験したのは不快だったと共有している。
    • この経験が Kagi をより強力で信頼できるサービスにしてくれることを望むと述べている。

  • サービス停止を引き起こしたスクレイパーに関するコメント

    • あるユーザーが動かしたスクレイパーによってサービスが 7 時間停止した件について、テスト中に「大量の検索が発生したらどうなるか？」という問いを立てなかったのかと疑問を呈している。

  • Kagi の利用体験とポストモーテムに関するコメント

    • 数週間 Kagi を使っていたが、先週すぐに読み込まれなかったとき、どうすればよいのか分からなかったと共有している。
    • ポストモーテムが出る前には、すでにそのインシデントを忘れていたと述べ、検索時に意識しなくてよい体験を提供してくれるチームに感謝を示している。

  • GCP で使っていたシングルコアのデータベースに関するコメント

    • Kagi が GCP で利用可能な最も安価なシングルコアデータベースを使っていたという事実に対し、好意的な反応を示している。
    • 読み取り負荷の急増に対応し、さらに性能を引き上げられる PolyScale のようなものを検討してみてはどうかと提案している。

  • 自動化されたスクレイピングに関するコメント

    • アカウントを停止した後で連絡してきたユーザーが、そのアカウントを使って結果を自動スクレイピングしていたと主張したと述べている。
    • すべての受信 RPC / API / HTTP リクエスト、特に公開されているものについては、QPS（1 秒あたりのクエリ数）制限を設定するよう推奨している。