6つの恐ろしい障害の話

1. Honeycomb の CTO、Charity Majors

• 特定地域（東ヨーロッパ）のユーザーに push noti が届かない

• ASG のサイズ変更直後から発生

• Round Robin DNS record が UDP パケットサイズを超えたことで発生

2. Gremlin の CTO、Matthew Fornaciari

• ディスクがいっぱいでログを書き込めず、障害が発生

• ログローテーション機能を開発

• ディスク使用量アラートを設定

• Gremlin を通じてテストできるように追加（カオスエンジニアリング）

3. Rookout の CTO、Lirran Haimovitch

"毎日決まった時間にサーバーがダウンするという都市伝説。

数週間にわたる調査の末、防犯カメラで原因を発見。

清掃員が掃除機をつなぐためにサーバーの接続を抜いていた"

4. Lightstep の CTO、Daniel "Spoons" Spoonhower

• アプリが読み込まれない

• 当日のデプロイ、インフラ変更はなかった

• 内部ユーザーだけで発生していることを確認

• アプリロード用 API を確認中、内部ユーザーの場合は追加データを返す部分を確認

• ここ数週間で payload が徐々に増え、その日の午後に最大 payload サイズを超えたことでアプリの読み込みに失敗

5. LogDNA の CTO、Lee liu

6. Transpoit の CTO、Ting Huang

• Twitter モバイルで読めない

• 新規ライブラリでセッション Cookie をパースできない問題を発見

[kunggom]

要約されていない5番のケースは、証明書の期限切れに関する話ですね。

証明書が予定どおり失効しても問題ないと思っていたものの、それは新しく開発したシステムに限った話で、依然として使われていたレガシーシステムでは問題が発生した、という話です。しかも使っていたCI/CDソリューションでも同じ問題が起きて、事態がさらに複雑になったとのこと。

[kbumsik]

「清掃員が掃除機をつなぐためにサーバーの接続を切った」

うわぁ…

[kunggom]

原文を読んでみると、その内容は導入のためのもので、実際の障害は顧客企業側の管理者が会議のときなどにたまに使うクエリがテーブル全体をロックしていたため、そのたびにバックエンドサービスのレイテンシが際限なく増えていたという話ですね。怪しいクエリを最適化したものの見当違いだったので、顧客企業側がページがあまりにも遅いとリロードを繰り返すたびに、同じ現象が起き続けていたと。

[kunggom]

似たような個人的な経験を一つ。フリーランスとして急ぎで入ったショッピングモール関連の仕事を引き受けたときのことです。

明け方にショッピングモールで大きな作業（ソリューションの大規模なバージョンアップ）を実施し、商品決済など主要機能に問題がないことを確認したうえで再開しました。ところが午後に入ってから突然ショッピングモールのWebサイトが非常に遅くなり、ついにはほとんど止まりかける状態になりました。調べてみると、原因はショッピングモールに別途付いていた販売者向けページでした。ショッピングモールのソリューションにカスタム開発した販売者向け管理ページを接続して運用していたのですが、そこに入る瞬間に非常に重いクエリが実行されていたのです。ショッピングモール再開後、個々の販売者が販売状況を確認しようとしてアクセスするたびにMySQLへの負荷が高まり、結局ショッピングモール自体が遅くなっていました。確認すると、関連テーブルにどういうわけかインデックスが適切に張られていませんでした。最終的にはインデックスを正しく設定し、いくつかのパラメータをチューニングすることで、ショッピングモール自体が遅くなる問題を解決できました。

[kbumsik]

ああ、経験の共有ありがとうございます。

とはいえ、管理者向けやビジネス判断のための資料は aggregation を使うぶん、かなり負荷がかかりそうですね。Web開発者ではないので詳しくはわかりませんが、最近はそういうものはデータエンジニアリングの一環として、データを別に集めておくみたいですね。

[kunggom]

おっしゃる通り、そのようなデータは別途分離して処理するのが定石なのでしょうが、私が作業していたショッピングモールは理不尽な部分がかなり多いレガシーシステムだったのか、そのようなアーキテクチャ上の考慮はまったくされていませんでした。かなり古いバージョン（InnoDBではなくMyISAMがデフォルトエンジンだった時代のバージョン）のMySQLが、やはり古いバージョンのApache Webサーバーと一緒に、同じVMインスタンス内で動いていました。ショッピングモールを運営するためのソリューションも、すでにレガシーに分類されてパッチだけが出ている状況でした。作業中に感じたソリューションの構造的な問題は、そもそも最初から新しく開発された新規バージョンでは解決されていたようですが、レガシーバージョンを触っていた私にとって、その点は何の影響もありませんでした。それがもう去年のことですね。