システムの安定性と高可用性の保証

I.はじめに

高同時実行性、高可用性、高パフォーマンスはインターネットの 3 つの高アーキテクチャと呼ばれ、この 3 つはエンジニアやアーキテクトがシステム アーキテクチャの設計で考慮しなければならない要素の 1 つです。今日は、3 つの H における高可用性について説明します。これは、私たちがよく言うシステムの安定性でもあります。

> この記事ではアイデアについてのみ説明し、詳細についてはあまり触れません。全文読むのに5～10分程度かかります。

2 番目に、高可用性の定義

N 9 は、システムの可用性の程度を定量化するために業界で一般的に使用されており、Web サイトの稼働時間の割合に直接マッピングできます。

可用性を計算する式は次のとおりです。

ほとんどの企業は、フォーナイン、つまり年間ダウンタイムが 53 分を超えてはならないことを要求していますが、この目標を達成することは依然として非常に困難であり、各サブモジュールが相互に協力する必要があります。

システムの可用性を向上させるには、まずシステムの安定性に影響を与える要因を知る必要があります。

3. 安定性に影響を与える要因

まず、システムの安定性に影響を与える一般的な問題のシナリオをいくつか整理してみましょう。これらは大きく 3 つのカテゴリに分類できます。

• 人的要因不当な変更、外部からの攻撃など

• ソフトウェア要因コードのバグ、設計の抜け穴、GC の問題、スレッド プールの例外、上流および下流の例外

• ハードウェア要因ネットワーク障害、マシン障害など

適切な薬は次のとおりです。1つ目は失敗前の予防、2 つ目は失敗後の迅速な回復力です。以下にいくつかの一般的な解決策について説明します。

4. 安定性を向上させるためのいくつかのアイデア

4.1 システムの分割

分割の目的は、使用できない時間を減らすことではなく、障害の影響を軽減することです。大規模なシステムはいくつかの小さな独立したモジュールに分割されているため、1 つのモジュールの問題が他のモジュールに影響を与えることはなく、障害の影響が軽減されます。システムの分割には、アクセス レイヤの分割、サービスの分割、データベースの分割が含まれます。

• アクセス層とサービス層は通常、ビジネスモジュール、重要性、変更頻度などの次元に応じて分割されます。

• データ層は通常、まずビジネスに応じて分割されますが、必要に応じて垂直方向に分割することもできます。つまり、データのシャーディング、読み取りと書き込みの分離、ホット データとコールド データの分離です。

::: hljsセンター

4.2 デカップリング

:::

システムを分割した後は、複数のモジュールに分割されます。モジュール間には強い依存関係と弱い依存関係があります。依存性が強い場合、依存者に問題がある場合には、依存者も問題に関与することになります。このとき、プロセス全体の呼び出し関係を整理し、弱い依存呼び出しにすることができます。依存性の低い呼び出しは、MQ の方法で分離できます。たとえ下流で問題が発生したとしても、現在のモジュールには影響しません。

4.3 テクノロジーの選択

適用性、メリット・デメリット、製品の評判、コミュニティ活動、実戦事例、拡張性などを総合的に評価し、現在のビジネスシナリオに適したミドルウェア＆データベースを選択できます。事前の調査は十分でなければなりません。まず比較、テスト、研究を行ってから決定を下してください。ナイフを研ぐことは、誤って木を切ることと同じではありません。

4.4 冗長展開と自動フェイルオーバー

サービス層の冗長展開はわかりやすいです。サービスは複数のノードを展開します。冗長性だけでは十分ではありません。障害が発生するたびに手動でシステムを復旧する必要があり、システムの使用不能時間が必然的に増加します。したがって、システムの高可用性は、多くの場合、「自動フェイルオーバー」によって実現されます。つまり、ノードがダウンした後は、アップストリーム トラフィックを自動的に削除できる必要がありますが、これらの機能は基本的にロード バランシング検出メカニズムを通じて実現できます。

データ層となるとさらに複雑になりますが、一般に参考となる成熟したソリューションがあります。一般に、1 つのマスターと 1 つのスレーブ、1 つのマスターと多数のスレーブ、および複数のマスターと複数のスレーブに分けられます。ただし、一般的な原則として、データ同期は複数のスレーブを実現し、データ シャーディングは複数のマスターを実現します。フェイルオーバー中に、新しいマスター ノードが選択アルゴリズムを通じて選択され、外部にサービスを提供します (ここでは、強整合性が存在しない場合)書き込み時に同期が行われるため、フェイルオーバー中に一部のデータが失われます)。詳細については、Redis Cluster、ZK、Kafka などのクラスター アーキテクチャを参照してください。

4.5 能力の評価

システムをオンラインにする前に、サービス全体で使用されるマシン、DB、キャッシュの容量を評価する必要があります。マシンの容量は次の方法で評価できます。

• 予想されるフロー指標 - QPS を明確にします。
• 許容可能な遅延と安全水位インジケーターを指定します (CPU%≤40%、コアリンク RT≤50ms など)。
• ストレス テストを通じて、単一のマシンが安全な水位以下でサポートできる最高の QPS を評価します (推定トラフィック比に従って複数のコア インターフェイスを同時にストレス テストするなど、混合シナリオを通じて検証することをお勧めします)。
• 最後に、マシンの具体的な数を推定できます。

QPS以外にDBやキャッシュの評価もデータ量の評価が必要ですが、方法はほぼ同様で、システムがオンラインになった後、監視指標に応じて容量を拡張・削減することができます。

4.6 迅速なサービス拡張機能とフラッドリリース機能

この段階では、コンテナであろうと ECS であろうと、単純なノードのレプリケーションと拡張は非常に簡単ですが、拡張の焦点は、サービス自体がステートレスであるかどうかを評価する必要があります。

• 現在のサービスを拡張する場合、ダウンストリーム DB 接続の最大数は何台のサーバーまでサポートされますか?
• 容量拡張後にキャッシュをウォームアップする必要はありますか?
• 大量戦略

これらの要素を事前に準備し、完全なSOP文書を整理する必要がありますが、もちろん訓練を実施し、実際に手動で操作して準備するのが最善の方法です。

フラッド放電機能とは、一般に、冗長展開の場合に、複数のノードがバックアップ ノードとして選択され、通常はトラフィックのごく一部を負担し、トラフィック フラッドのピークが来ると、ホット ノードのトラフィックの一部が転送されることを指します。トラフィック ルーティング戦略を調整してバックアップ ノードに送信します。

拡張計画に比べてコストは比較的高くなりますが、対応が早くリスクが低いというメリットがあります。

4.7 トラフィックシェーピングとヒューズの劣化

トラフィック シェーピングは一般に電流制限とも呼ばれ、主に予期せぬトラフィックによってサービスが圧倒されるのを防ぎます。また、サーキット ブレーカーは、独自のコンポーネントまたは依存するダウンストリーム障害が発生したときに、長期的なブロッキングや雪崩によって引き起こされる障害を防ぐことを目的としています。限流ヒューズの機能については、基本的にはオープンソースコンポーネントSentinelが備えており、非常にシンプルで便利ですが、注意が必要な点もいくつかあります。

• 現在の制限しきい値は通常、サービスとして構成された特定のリソースによってサポートできる最高水位であり、ストレス テストを通じて評価する必要があります。システムが反復するにつれて、この値を継続的に調整する必要がある場合があります。構成が高すぎると、システムがクラッシュしたときに保護が作動しません。また、構成が低すぎると、偶発的な怪我を引き起こす可能性があります。

• ヒューズのダウングレード - インターフェイスまたはリソースが切断された後、ビジネス シナリオと切断されたリソースの重要性に基づいて、例外をスローするかボトムアップ結果を返すかを評価する必要があります。たとえば、発注シナリオで在庫控除インターフェイスが壊れた場合、在庫の差し引きは注文インターフェイスの必須条件であるため、ヒューズが壊れてリンク全体が失敗してロールになった後にのみ例外がスローされます。製品レビューの取得に関連するインターフェイスが壊れた場合は、リンク全体に影響を与えずに空の値を返すことを選択できます。

4.8 リソースの分離

サービスの複数のダウンストリームが同時にブロックされ、単一のダウンストリーム インターフェイスがヒューズ基準に達していない場合 (たとえば、例外と低速リクエストの比率がしきい値に達していない場合)、サービス全体のスループットが低下し、より多くのスレッドが占有され、極端な場合にはスレッド プールの枯渇につながることもあります。リソース分離の導入後は、単一のダウンストリーム インターフェイスで使用できる最大スレッド リソースを制限して、サービス全体のスループットがパンクする前に影響を最小限に抑えることができます。

分離メカニズムについて言えば、ここで拡張できますが、各インターフェイスのトラフィックは RT とは異なるため、使用可能なスレッドの適切な最大数を設定するのが難しく、ビジネスが反復されるにつれて、このしきい値を維持することも難しくなります。ここでは、共有と排他を使用して、この問題を解決できます。各インターフェイスには、独自の排他スレッド リソースがあります。排他リソースがいっぱいになると、共有リソースが使用されます。共有プールが特定の水位に達すると、排他リソースは強制的に使用されます。使用して列に並んで待ちます。このメカニズムの明らかな利点は、リソースの使用率を最大化しながら分離を確保できることです。

ここでのスレッド数はリソースの一種にすぎず、リソースは接続数やメモリなどの場合もあります。

4.9 体系的な保護

系統的保護は一種の無差別電流制限であり、一言で言えば、システムが崩壊する前にすべての流入口に無差別電流制限を実施し、システムが健全な水位に戻ったら電流制限を停止するという概念です。具体的なポイントは、アプリケーション負荷、全体の平均 RT、入口 QPS、スレッド数などのいくつかの側面の監視指標を組み合わせて、システム入口トラフィックとシステム負荷のバランスをとり、システムが最大限のパフォーマンスで実行できるようにすることです。システム全体の安定性を確保しながら、可能な限りスループットを向上させます。

4.10 可観測性とアラート

システムに障害が発生した場合、まず障害の原因を突き止め、問題を解決し、最後にシステムを復旧する必要があります。トラブルシューティングの速度が障害回復全体の期間を大きく左右し、可観測性の最大の価値は迅速なトラブルシューティングにあります。次に、メトリクス、トレース、ログの 3 つの柱に基づいてアラーム ルールを設定します。これにより、システム内で起こり得るリスクや問題を事前に検出し、障害を回避できます。

4.11 プロセスを変える 3 つのコツ

変更はユーザビリティの最大の敵です。失敗の 99% は変更 (構成変更、コード変更、マシン変更など) によって引き起こされます。では、変更によって引き起こされる失敗を減らすにはどうすればよいでしょうか?

• グレースケールは、変更されたコンテンツを検証するためにトラフィックの一部を使用できるため、ユーザー ベースへの影響を軽減できます。

• ロールバック可能問題が発生した後は、効果的なロールバック メカニズムが存在する可能性があります。データの変更が含まれる場合、公開後にダーティ データが書き込まれるため、ダーティ データを確実に削除するには信頼性の高いロールバック プロセスが必要です。

• 観察可能変更前後の指標の変化を観察することで、問題を事前に大幅に発見することができます。

上記の 3 つのトリックに加えて、コード制御、統合コンパイル、自動テスト、静的コード スキャンなど、他の開発プロセスも規制する必要があります。

V. まとめ

動的に進化するシステムにおいて、障害の確率をゼロにすることはできず、できる限り障害を防ぎ、障害が発生した場合の復旧時間を短縮することしかできません。もちろん、やみくもに使いやすさを追求する必要はありませんが、結局、安定性を高める一方で保守コストやマシンコストも増加するため、システムのビジネスSLO要件と適切なものを組み合わせる必要があります。一番です。

安定性と高可用性をどのように確保するかは、非常に大きな命題です。この記事では、あまり詳細な説明はありませんが、主に誰もが知っておくべき、システムのフレームワークのセットを参照できるように、いくつかの全体的なアイデアについてのみ説明します。 。最後に、辛抱強く読んでくださった学生の皆様に感謝いたします。

文/新一

推奨されるオフライン アクティビティ:

日時： 2023年6月10日（土）14:00～18:00テーマ：徳武テクノロジーサロ​​ンNo.18～ワイヤレステクノロジーNo.4会場：杭州市西湖区雪源路77号徳武杭州研究開発センター 研修教室12階（地下鉄10号線と19号線の文三路駅G出口）

イベントのハイライト:このワイヤレス サロンでは、最新のテクノロジー トレンドと実践に焦点を当て、杭州/オンラインで次の 4 つのエキサイティングなスピーチ トピックをお届けします。「Douyin 作成ツール - iOS の消費電力監視と最適化」、「Dewu プライバシー コンプライアンス プラットフォーム」構築の実践」、「Netease Cloud Music - クライアントの大量トラフィック活動のための日次保証プログラムの実践」、「Dewu Android のコンパイルと最適化」。これらのトピックはあなたの仕事や勉強に役立つと思います。私たちはこれらのエキサイティングな技術的な内容についてあなたと議論できることを楽しみにしています。

クリックして登録: ワイヤレスサロン登録

この記事は Dewu technology のオリジナルに属し、出典: Dewu technology 公式ウェブサイト

Dewu Technology の許可なく転載することは固く禁じられています。そうでない場合は、法律に従って法的責任を調査されます。

{{名前}}

{{名前}}