分散キャッシュがレジストリをクラッシュさせた様子をご覧ください

失敗に関する話題を書く機会があるときは、書き始める前に長い間静かにモニターを見つめます。多大な苦悩と闘いの末、私は思い切ってペンを手に取りました。なぜ？なぜなら、このようなトピックは、「これだけ話しても、構成が適切に構成されていないだけではないのか？」や「このコードは豚が書いたものか？チームにはパフォーマンステストを理解している学生がいるのか？」といった苦情を招きやすいからです。このようなコメントは少々挑発的で、軽蔑に満ちています。

しかし、テクノロジーの世界では、ほとんどの場合、客観的なシナリオが主観的な結果を決定し、主観的な結果が客観的なシナリオを反映すると思います。シナリオと結果をつなぎ合わせて自分なりに書き出して広め、同じ経験をしたクラスメイトとチャットするのも悪いことではありません。

[[256120]]

登録センターの倒壊により、弊社システムに事故が発生しました。それはよくある出来事でしたが、始まりは予想できましたが、原因は予想していませんでした。原因は、生産ラインで長年稼働していた分散キャッシュ システムであることが判明しました。

何が起こっているのか？

まずは失敗のプロセスを振り返ってみましょう。

それは11月の取引日の午前10時頃のことでした。

ミドルウェア監視システムによってアラームがトリガーされることなく、アプリケーション チームの責任者が突然やって来て、「なぜキャッシュ応答がこんなに遅いのですか? 何をしているのですか?」と言いました。

これはトランザクションの途中であったため、ミドルウェア運用保守チームは即座に激怒し、一連の監視データを緊急に確認しました。まず、Zabbix を通じて CPU、メモリ、ネットワーク、ディスクなどの基本的な警告をチェックしましたが、すべて正常でした。次に、サービスの健全性状態を確認しました。 1回投げてみたが、不審な点は見つからなかった。

私は混乱しています。これは意味が分かりません。

10:30に「ZKクラスタ内のノードに障害があり、ポートがブロックされているため、ノード情報を取得できません。早急に対処してください。」というアラームメッセージが受信されました。

これは簡単です。 ZK サービス ポートがブロックされています。再起動するとすぐに回復します。

10:40にZKクラスター全体が麻痺し、ノードデータが取得できなくなりました。アプリケーションシステムのDubboサービスと分散キャッシュは同じZKクラスタを使用しており、この期間中にアプリケーションが再起動されていなかったため、アプリケーションサービス自体は当面影響を受けませんでした。

それは意味をなさない。過去 1 か月間、アプリケーション側でもキャッシュ側でもバージョンはリリースされていません。さらに、分散キャッシュは、一部のノード関連情報を ZK に保存することを除いて、基本的に ZK に依存しません。

10時50分にすべてのZKクラスターが再起動しましたが、10分後に再び麻痺しました。

すごいですね、何が悪かったのでしょうか?

10:55にすべてのZKクラスターが再起動されました。 1 分後、ノード数が 220,000 を超え、再びクラッシュしたことが判明しました。

10:58 に監視スクリプトを追加したところ、ノードソースが分散キャッシュシステムのローカルキャッシュサービスからのものであることが判明しました。

11:00にコンソール経由でローカルキャッシュサービスをシャットダウンした後、ZKクラスターを3回目に再起動し、スクリプト経由でローカルキャッシュによって生成された大量のノード情報を削除しました。

11時05分、生産ライン上の全てのZKクラスターは異常なく復旧しました。

嵐は過ぎ去ったが、皆の顔は混乱に満ちている。一体全体、このローカル キャッシュが登録センターのダウンを引き起こすなんてあり得るのでしょうか? 1年以上オンラインになっているのに、なぜ以前は問題がなかったのでしょうか?今日はなぜこんなことが起きたのでしょうか？

たくさんの挨拶がみんなの心を満たします。

ローカルキャッシュの仕組み

昨年、私は「#Haomai の分散キャッシュミドルウェア#」というコンテンツで当社の分散キャッシュについて比較的詳しく説明しました。そこで、ここでは、システムフローチャートを通じて、当社のローカルキャッシュシステムのコア動作メカニズムのいくつかを簡単に説明します。

• 非ローカルキャッシュの仕組み

• ローカルキャッシュの仕組み - KEY のプリロード/更新

• ローカル キャッシュの仕組み - 設定/削除操作

• ローカル キャッシュの仕組み - 取得操作

ちなみに、歴史的な理由とリソース不足により、一部のキャッシュ システムとアプリケーション システムの ZK クラスターが混在しており、これが今回の事故の潜在的な危険をもたらしました。

ZK クラスターはどのようにしてクラッシュしたのでしょうか?

そうは言っても、ミドルウェアについてある程度理解している人であれば、この事件の全体像は大体推測できると思います。

簡単に言うと、オンライン化の初期段階では、トラフィックとアプリケーション システムへのアクセスが少なかったため、ローカル キャッシュ メッセージ通知は ZK を使用して実装され、ブロードキャストも使用されていました。しかし、トラフィックの増加とアプリケーション システムへのアクセス数の増加に伴い、送信されるメッセージ量が指数関数的に増加し、最終的に収容能力の上限に達し、ZK クラスターは崩壊しました。

確かに、理由は基本的に正しく推測されていますが、送信されたメッセージの数が指数関数的に増加したのはなぜでしょうか?

ローカル キャッシュの動作メカニズムによると、通常、そこに何が保存されるのでしょうか?

1. システムパラメータや業務パラメータなど、更新頻度は低いがアクセス頻度は高いもの。
2. 単一のキー/値が大きいため、ネットワークの消費量が多くなり、パフォーマンスが大幅に低下します。
3. サーバーにはリソース (I/O など) が不足しているか不安定ですが、安定性に対する要件は非常に高くなっています。

私は混乱しました。パラメータ情報をいくつか入れただけなので、更新頻度は非常に低かったです。これによって 5 ノードの ZK クラスターが爆発する可能性があるのでしょうか?

真実を明らかにするために、私たちはすぐにコードウォークスルーを実施し、最終的に奇妙なものを発見しました。

設計によれば、「ローカル キャッシュ動作メカニズム - 設定/削除操作」の動作メカニズムでは、キーがサーバー側のキャッシュ操作を完了したときに、キーがローカル キャッシュ ルール リストに追加されない場合、メッセージ通知をトリガーすることはできません。ただし、ここには明らかにバグがあり、すべてのキーが ZK に送信されます。

これは理解しやすいですね。アプリケーション システムは最近新しいバージョンをリリースしていませんが、キャッシュ コンソールを通じてこのキャッシュ シャードのセットに分散ロックが静かに追加されています。そのため、取引が開始されると、わずか数十分ですぐに爆発します。

バグの発見に加えて、テスト後の検証を通じて次の結論にも達しました。

1. メッセージ同期に ZK を使用する場合、ZK 自体の負荷容量は弱くなります。 MQに切り替えるべきでしょうか?
2. 監視手段が単一であり、監視が弱い。
3. システムの展開構造が無理です。インフラストラクチャ ZK はアプリケーション ZK と混在させないでください。

そうは言っても、この話はここで終わるべきです。

最後に

この物語を読んだ後、他の人と議論するのが好きな友人の中には、質問せずにはいられない人もいるかもしれません。アーキテクチャを設計し、コードを自分で書きました。その背後にある論理を知らないのですか?どうしてそんな低レベルの間違いを持ち出すのですか?

そうではないかもしれません。どの技術チームでも、コアメンバーの離脱やビジネスモデルの変更により、技術チームは多かれ少なかれ「システムが何であるかは分かっているが、それがなぜなのかは分かっていない」という状況に陥ります。どのチームもそれを避けようとしていますが、完全に排除するのは簡単ではありません。

技術マネージャーとしては、良い姿勢を持ち、あらゆる失敗を変革のプロセスと捉え、そこから要約と経験を引き出し、それを伝えて、将来同じ間違いを繰り返さないようにすることが大切です。

しかし、ある日失敗してシステムが完全に麻痺してしまったらどうなるでしょうか?

あなたの人生に幸あれ。