予想外に、分散キャッシュによって登録センターがこのようにダウンしてしまいました。

不具合について書く機会があるときはいつも、書き始める前に長い間モニターを見つめます。多大な苦悩と闘いの末、私は思い切ってペンを手に取りました。なぜ？

[[253487]]

なぜなら、このようなトピックは、「これだけ話しても、構成が正しくないだけではないですか？」や「このコードは豚が書いたのですか？チームにパフォーマンステストを理解している人はいますか？」などの苦情を簡単に引き起こす可能性があるからです。このようなコメントは少々挑発的で、軽蔑に満ちています。

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

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

失敗のプロセスを確認する

ここで何が起こっているのですか?まずは失敗のプロセスを振り返ってみましょう。

それは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年以上オンラインになっているのに、なぜ以前は問題がなかったのでしょうか?今日はなぜこんなことが起きたのでしょうか？皆の心にはたくさんの疑問符が浮かびました。

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

ここでは、システム フロー チャートを通じて、ローカル キャッシュ システムの主要な動作メカニズムのいくつかを簡単に説明します。

①非ローカルキャッシュの動作メカニズム

② ローカルキャッシュの動作メカニズム：キーのプリロード/更新

③ ローカルキャッシュの動作メカニズム：設定/削除操作

④ ローカルキャッシュの動作メカニズム：Get操作

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

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

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

簡単に言うと、オンライン化の初期段階では、トラフィック量とアプリケーション システム アクセスが少なかったため、ローカル キャッシュ メッセージ通知は ZK を使用して実装され、ブロードキャストも使用されていました。

しかし、トラフィックの増加とアプリケーション システムへのアクセス数の増加に伴い、送信されるメッセージ量が指数関数的に増加し、最終的に収容能力の上限に達し、ZK クラスターは崩壊しました。確かに、理由は基本的に正しく推測されていますが、送信されたメッセージの数が指数関数的に増加したのはなぜでしょうか?

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

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

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

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

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

しかし、明らかにここにはバグがあり、すべてのキーが ZK に送信されてしまいます。

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

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

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

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

***で話す

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

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

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

しかし、ある日失敗してシステムが完全にクラッシュしたらどうすればいいのでしょうか?あなたの人生に幸あれ。

著者: 王野良

編集者: 陶嘉龍、孫樹娟

出典：草食羅漢（ID：kidd_wyl）のWeChat公開アカウントから転載。