失敗: 仮想化ストレージによって引き起こされた分散キャッシュパフォーマンスの悲劇

インターネットでこの文章を見たのを覚えています:

明日と事故のどちらが先に起こるかは分かりません。私たちは自然災害の前では無力です。

この文を運用・保守作業に当てはめると、事故のほとんどは自然災害ではなく人為的災害であると考えられます。

本日お伝えしたいのは、プライマリ コンピュータ ルームとバックアップ コンピュータ ルームの移行後、仮想化の経験不足とチーム間のコミュニケーションの盲点により、分散キャッシュのパフォーマンスの悲劇が最終的に引き起こされたことです。

[[224572]]

- 01. 障害発生 -

コンピュータ ルームの切り替え後の最初の営業日には、アプリでも PC でも、すべてのユーザーがログイン、アカウントの開設、取引に時間がかかることを経験しました。一部のユーザーは、直接エラーコードを受け取ったことさえあります。

「理論的に完璧な」監視システムが実装されるまでは、分散システムの障害箇所を特定するのは非常に面倒で複雑です。システムは分散されているため、特に基本的な共有サービスでは障害も分散されます。一度断層が発生すると、いつでも崩壊する可能性があります。

さて、本題に戻りますが、手動操作とメンテナンス、および半自動ツールの努力により、最終的にボトルネック ポイントが特定されました。これは次の簡単な概略図に示されています。

図1. 関連するシステムアクセスプロセスの概略図

上の図によると、障害の原因は「アカウント システムのキャッシュ スライスの「説明のつかない」パフォーマンス低下によりブロックが発生した」ことです。

アカウントシステムはシステムチェーン全体の中でより基本的なものであるため、そのパフォーマンスと安定性が低下すると、ドミノ効果が引き起こされます。

図の上部のリンク：ポイント 1、2、3 は、アカウントの開設やログインなどのビジネス シナリオに直接影響します。

図の下のリンク（ポイント 1、2、3、4）は、取引や支払いなどのビジネス シナリオに間接的に影響します。

できるだけ早く復旧するために、次の2つの暫定的な救済措置を採用しました。

大幅なダウングレード: 一部のアプリケーション要求を Redis から Oracle クラスターに切り替えます。

ブルートフォース電流制限: ネットワーク アクセスの一部をブロックして、データベースへの負荷を軽減します。

しかし、PaaS、フォールト トレランス、動的スケーリングなどのメカニズムが完璧でない場合、同様の障害が発生したときに、「戦車を救うためにポーンを犠牲にする」という強引なアプローチを取る以外に、すぐに解決できる方法はありません。

- 02. 失敗の原因 -

つまり、障害が発生したとき、私たちは混乱し、いくつかの推測が頭に浮かびました。

ネットワークの問題: 新しいコンピューター ルームの帯域幅が混雑しています... ネットワークに問題がありますか?

ハードウェアの問題: スイッチが壊れていますか?仮想マシンのリソースは「過剰販売」されていますか?

セキュリティ問題: ハッキングされましたか? DDoS？

アーキテクチャの問題: Redis、Sentinel、Proxy のバグはどこにありますか?

これら 4 つの問題が次々と解消された後、「アクセス リンク モニタリング」の分析機能を使用して調査したところ、不審な点が見つかりました。

パフォーマンス低下の考えられる原因。次の図は ELK ログ分析からのものです。

図 2. アカウント システム - Redis ノードの iostat ステータス

図3. アカウントシステム - プロキシノードのiostatステータス

図5. アカウントシステム - 一定期間のキャッシュリンクの監視データ

このヒントに従ってサーバーに入り、確認してください。次の画像は Linux コマンドラインからのものです。

図6. アカウントシステム - Redisノードのiostatコマンドの結果

図7. アカウントシステム - RedisノードのI/Oが高い場合の異常なプロセス

基本的に、キャッシュ パフォーマンスの低下を引き起こす「原因」は I/O であると結論付けることができます。ただし、Redis の永続化機能が有効になっていないという前提では、主な原因は以下になります。

1. コンピュータルームを移行すると、ディスク管理モードが変わります

元のコンピュータ ルーム: キャッシュ サービスはローカル ディスク管理モードを使用します。

既存のコンピュータ ルーム: VSAN プール共有データ ストレージにより、一部の高 I/O アプリケーションとキャッシュ サービス間で I/O 相互影響が発生します。

図8. 新しいコンピュータルームではVMWare vSphereハイパーコンバージド仮想化ディスク管理モードが使用されています

2. コンピュータルームを移行すると、仮想マシンの展開方法が変わります

元のコンピュータ ルーム: キャッシュ サービスの仮想マシンは、独立したハードウェア上に展開されます。

既存のコンピュータ ルーム: 一部の Redis と Proxy は、ビッグ データ サービスの仮想化ノードと同じ物理マシンに展開されているため、定期的にリソースの競合が発生します。

図 9. 仮想化ノードでの定期的な CPU スパイク - 分析図

以上の結論に基づき、問題を迅速に解決するために、一時的に徴用したN台の物理マシンにアカウントシステムのキャッシュスライスを移行し、ディスクをローカルモードに切り替えたところ、システムは正常に戻りました。

- 03. イベント後の振り返り -

システム障害につながる要因は、ソフトウェア設計、ハードウェアの展開、そしてもちろんチーム間の効果的なコミュニケーションなど、数多く考えられます。

そこで、私たちは、帰属分析に加えて、振り返りと質問への回答という手法を使って事件の全過程を整理し、この整理が私たちの考えを整理するのに役立つことを期待しました。

質問 1: コンピューター ルームが移行される前に、アーキテクトが仮想マシンとディスクの変更について知らないのはなぜですか?

Haomai では、ホスト、オペレーティング システム、データベース、ネットワーク、セキュリティ、周辺機器などのシステム レベルの機器はすべて「システム運用保守部門」によって管理されています。ミドルウェアのアーキテクチャ設計、研究開発、運用・保守展開は「プラットフォームアーキテクチャ部」が管轄します。

責任範囲によっては、部門間のコミュニケーションが「尻が頭を決める」状況につながる可能性があります。

アーキテクト: 私は仮想マシンとディスクの責任を負っていません。彼らはそれらを管理し、私たちのシナリオを理解するはずです。

システムの運用と保守: この変更により、運用と保守の効率が向上します。私はこれについてあなたに話しましたが、あなたは何も質問しませんでした。

別の観点から見ると、仮想化インフラストラクチャ (またはハイパーコンバージェンス) の実装経験がない場合、アーキテクトは移行の開始時に、このような変更が必然的に同様の障害に関連することを予測できない可能性があります。

質問 2: ハイパーコンバージド仮想化機器 (またはテクノロジー) を使用する理由は何ですか?ローカルディスクが不良ですか?

質問 1 の回答から、Oracle をコア データベースとする前提に影響を与えることなく、インフラストラクチャの「物理」から「仮想化」への進化をより効率的に推進し、「クラウド化」のチャネルを構築するには、「低コスト、高効率、安定性」のテクノロジ選択が金融企業にとって優先事項であることがわかります。

ハイパーコンバージド仮想化 - VSAN ストレージ自動化がもたらす運用上の利点を見てみましょう。

図10. 他のストレージと比較した利点

ローカル ディスクと比較すると、ハイパーコンバージド仮想化 (VSAN) に基づくストレージ自動化方式の最大の利点は、割り当てと回復の時間が極めて短いことと、ディスクベースのバックアップと回復がローカル ディスクよりもはるかに便利であることです。

分散キャッシュなどのシナリオでは、これは特別な要件としてのみ考えられます。

- 結論 -

さて、ここで再びいくつかの重要な原則についてお話ししましょう。この事例を共有することで、事件の全容を理解していただいたのではないかと思います。この瞬間、おそらく、さまざまな人々の心の中には、不満や賞賛、嘲笑などが残っているだろう。目的が何であれ、この共有が皆さんの助けになれば幸いです。