記事：Alibabaの10億レベルの並行システム設計（2021バージョン）
リンク：https：//pan.baidu.com/s/1lbqQhDWjdZe1CBU-6U4jhA抽出コード：8888
目次
コース開始後、理論知識の説明が増えたとの報告もあり、例を見たいと思っています。私はこれらの声に注意を払い、あなたの提案に感謝します.04の初めに、私はこれに応えたいと思います。
コースを設計する際には、基本章の最初の5つの講義を主に使用して、高並行性システム設計の基本概念をいくつか紹介します。全体的なフレームワークを確立するのに役立つことを願っています。後続の進化の章と実際の戦闘の章。関連する知識ポイントを1つずつ拡張および拡張します。たとえば、このレッスンではダウングレードについて説明しましたが、ダウングレードスキームの種類と適用可能なシナリオについては、運用と保守の章でケースの形で詳しく紹介します。この設計の理由は、コースが相互にリンクされることを期待するためです。前のセクションの少しのスペース。表面にポイントを取り、徐々に拡大します。もちろん、さまざまな声がコースの内容を継続的に最適化する私の動機です。私はすべての提案を真剣に受け止め、コースを継続的に最適化し、懸命に努力してあなたと一緒に進歩します。
次に、正式にコースに入りましょう。このレッスンでは、高並行性システム設計の2番目の目標である高可用性について引き続き理解していきます。このレッスンでは、システムの使いやすさを向上させるためのアイデアと方法を直感的に理解する必要があります。これにより、フォローアップのポイントまでこれらのコンテンツを説明すると、すぐに対応でき、参照することもできます。システムでユーザビリティの問題が発生した場合。これらの方法は最適化されています。
高可用性（HA）
高可用性（HA）は、システムを設計するときによく耳にする用語です。これは、システムが障害なく動作する能力を指します。
多くのオープンソースコンポーネントドキュメントに見られるHAソリューションは、コンポーネントの可用性を向上させ、システムのダウンタイムやサービス不能を防ぐためのソリューションです。たとえば、Hadoop 1.0のNameNodeが単一のポイントであることがわかっています。障害が発生すると、クラスター全体が使用できなくなります。Hadoop2で提案されているNameNode HAソリューションは、2つのNameNodeを同時に開始します。1つはアクティブです。アクティブNameNodeに障害が発生すると、スタンバイNameNodeをアクティブ状態に切り替えてサービスを提供し続けることができます。これにより、Hadoopが障害なく継続的に実行できるようになり、これも改善されます。その可用性。
一般的に、同時実行性が高くトラフィックが多いシステムの場合、システム障害はシステムパフォーマンスの低下よりもユーザーエクスペリエンスに悪影響を及ぼします。1日に100万人を超えるアクティブユーザーがいるシステムを想像してみてください。1分間の障害が数千人のユーザーに影響を与える可能性があります。また、システムの毎日のアクティビティが増えると、1分間の障害時間の影響を受けるユーザーの数も増え、システムの可用性に対する要件が高くなります。
そこで本日は、システム設計のアイデアを提供するために、高い同時実行性の下でシステムの高可用性を確保する方法を理解していただきます。
ユーザビリティ測定
ユーザビリティは抽象的な概念です。それを測定する方法を知る必要があります。関連する概念は、MTBFとMTTRです。
MTBF（平均故障間隔）：平均故障間隔を意味し、2つの故障間の時間を表します。これは、システムが正常に動作するための平均時間です。この時間が長いほど、システムの安定性が高くなります。
MTTR（平均修復時間）：障害の平均回復時間を意味し、平均故障時間としても理解できます。値が小さいほど、ユーザーへの障害の影響は小さくなります。
可用性はMTBFとMTTRの値と密接に関連しています。次の式を使用してそれらの関係を表すことができます。可用性= MTBF /（MTBF + MTTR）この式で計算された結果は比率であり、この比率はシステムの可用性。一般的に言えば、システムの可用性を説明するために数ナインを使用します。
実際、この写真から、1ナインと2ナインの可用性は非常に簡単に達成できることがわかります。LanxiangTechnicalSchoolからのフォークリフトがない限り、基本的には人間の操作と保守によって達成できます。
スリーナインの後、システムの年間障害時間は3日から8時間に急激に減少しました。フォーナインの後、年間の故障時間は1時間未満に短縮されました。このレベルの可用性では、完全な運用および保守義務システム、トラブルシューティング手順、およびビジネス変更手順を確立する必要がある場合があります。また、システム設計についてさらに考慮する必要がある場合もあります。たとえば、開発中に、障害が発生した場合に手動の介入なしで自動的に回復できるかどうかを検討する必要があります。もちろん、ツールの構築に関しては、障害の原因を迅速にトラブルシューティングし、システムを迅速に復元するために、さらに改善を加える必要があります。
ファイブナインに達した後、障害は人的資源によって回復することはできません。障害が発生してからアラームを受信してから、コンピューターの電源を入れてサーバーにログインして問題に対処するまで、10分ほどかかった可能性があると想像してみてください。したがって、このレベルの可用性では、システムの耐災害性と自動回復機能を調べます。マシンに障害の処理を許可することによってのみ、可用性インジケーターがより高いレベルに引き上げられます。
一般的に、コアビジネスシステムの可用性はフォーナインに達する必要があり、非コアシステムの可用性は最大でスリーナインで許容されます。実際の作業では、同様のステートメントを聞いたことがあるかもしれませんが、レベルやビジネスシナリオが異なるシステムでは、可用性要件が異なります。
現在、可用性の評価指標についてある程度理解していると思いますが、次に、高可用性システムの設計で考慮する必要のある要素を見てみましょう。
高可用性システム設計のアイデア
成熟したシステムの可用性は、システム設計とシステムの運用および保守という2つの側面から保証する必要があります。これらは両方とも連携して機能し、不可欠です。では、システムの高可用性の問題を解決するために、これら2つの側面からどのように始めるのでしょうか。
1.システム設計
「障害に対する設計」は、高可用性システムを設計する際の最初の原則です。100万QPSを実行する同時実行性の高いシステムでは、クラスター内のマシンの数は数百または数千であり、1台のマシンの障害は正常であり、障害はほぼ毎日発生する可能性があります。千マイルを獲得するために前もって計画してください。システムを設計する際には、障害の発生を重要な考慮事項とし、障害を自動的に検出する方法と障害発生後に解決する方法を事前に検討する必要があります。もちろん、先を見越して考えることに加えて、フェイルオーバー（フェイルオーバー）、タイムアウト制御、ダウングレードと電流制限など、いくつかの特定の最適化方法を習得する必要もあります。
一般的に、ノードがフェイルオーバーする状況は2つあります。
- これは、完全にピアノード間のフェイルオーバーです。
- これは、等しくないノードの間にあります。つまり、システムにはプライマリノードとスタンバイノードがあります。
ピアノード間のフェイルオーバーは比較的簡単です。このタイプのシステムでは、すべてのノードが読み取りおよび書き込みトラフィックを担当し、状態はノードに格納されず、各ノードは別のノードのミラーイメージになることができます。この場合、特定のノードへのアクセスが失敗した場合は、単にランダムに別のノードにアクセスします。たとえば、次のように、500を超えるTomcat要求が表示されたときに、別のTomcatノードの要求を再試行するようにNginxを構成できます。
非ピアノードのフェイルオーバーメカニズムははるかに複雑です。たとえば、プライマリノードと複数のスタンバイノードがあります。これらのスタンバイノードは、ホットスタンバイ（オンラインでサービスも提供するスタンバイノード）またはコールドスタンバイ（バックアップとしてのみ使用）にすることができます。その場合、コードに方法を制御する必要があります。メインマシンとスタンバイマシンに障害があるかどうか、およびメインマシンとスタンバイマシンを切り替える方法を検出します。最も広く使用されている障害検出メカニズムは、「ハートビート」です。クライアントのマスターノードにハートビートパケットを定期的に送信することも、バックアップノードからハートビートパケットを定期的に送信することもできます。ハートビートパケットが一定時間受信されない場合、マスターノードに障害が発生したと見なすことができ、マスター選択操作をトリガーできます。マスターの選出の結果は、複数のバックアップノードで合意する必要があるため、PaxosやRaftなどの特定の分散コンセンサスアルゴリズムが使用されます。
フェイルオーバーに加えて、システム間の呼び出しタイムアウトの制御も、高可用性システムの設計における重要な考慮事項です。
複雑な同時実行性の高いシステムは通常、多くのシステムモジュールで構成されており、キャッシュコンポーネント、キューサービスなど、多くのコンポーネントやサービスにも依存しています。それらの間で最も恐れられている呼び出しは、失敗ではなく遅延です。失敗は通常瞬時に発生し、再試行することで解決できるためです。特定のモジュールまたはサービスの呼び出しで比較的大きな遅延が発生すると、呼び出し元はこの呼び出しでブロックされ、呼び出し元が占有していたリソースを解放できなくなります。このようなブロッキング要求が多数ある場合、呼び出し元はリソースが不足しているために電話を切ります。システム開発の初期段階では、タイムアウト制御は通常無視されるか、正しいタイムアウト期間を決定する方法がありません。
モジュールがRPCフレームワークを介して呼び出され、タイムアウト期間がデフォルトで30秒であるプロジェクトを以前に経験しました。通常、システムは非常に安定して実行されますが、比較的大量のトラフィックが発生し、RPCサーバーに一定数の低速要求が表示されると、RPCクライアントスレッドはこれらの低速要求で30秒間ブロックされ、RPCクライアントはスレッドが呼び出されている限り、Hangupを使用します。その後、障害レビュー中にこの問題を発見した後、RPC、データベース、キャッシュ、およびサードパーティサービスの呼び出しのタイムアウト期間を調整して、システム全体の雪崩を引き起こすことなく、遅い要求が発生したときにタイムアウトをトリガーできるようにしました。 。タイムアウト制御が行われるので、タイムアウト期間をどのように決定しますか？これはより難しい問題です。
タイムアウト期間が短いと、多くのタイムアウトエラーが発生し、ユーザーエクスペリエンスに影響します。タイムアウト期間が長いと、機能しません。システム間の通話ログを収集して99％の応答時間を計算し、この時間に基づいてタイムアウト期間を指定することをお勧めします。通話履歴がない場合は、経験に基づいてのみタイムアウト期間を指定できます。ただし、どの方法を使用する場合でも、タイムアウト期間は静的ではなく、後続のシステムメンテナンスプロセスで継続的に変更する必要があります。
タイムアウト制御は、実際には要求を永久に保持するのではなく、一定期間後に要求を失敗させ、次の要求のためにリソースを解放することです。これはユーザーにとって有害ですが、システム全体の可用性を確保しながら少数の要求を犠牲にするため、これは必要です。
また、システムの高可用性を確保するために、他に2つの損失の多いソリューションがあります。それらは、劣化と電流制限です。
ダウングレードは、コアサービスの安定性を確保するために非コアサービスを犠牲にする慣行です。たとえば、Weiboを投稿するときは、最初にスパム対策サービスの検査を行ってコンテンツが広告であるかどうかを検出し、次にそれを渡した後にデータベースへの書き込みなどのロジックを完了します。スパム対策の検出は、多くのポリシーマッチングを伴うため、比較的重い操作です。毎日のトラフィックでは時間がかかりますが、それでも正常に応答できます。ただし、同時実行性が高い場合、ボトルネックになる可能性があり、Weiboを公開するメインプロセスではないため、スパム対策サービスの検出を一時的にオフにして、メインプロセスをより安定させることができます。
現在の制限は別の考え方であり、同時要求の速度を制限することによってシステムを保護します。たとえば、Webアプリケーションの場合、1台のマシンで1秒あたり1,000リクエストのみを処理するように制限すると、超過部分はクライアントに直接エラーを返します。このアプローチはユーザーエクスペリエンスに悪影響を及ぼしますが、極端な並行性の下では無力な行為であり、短期間の動作であるため、許容されます。実際、ダウングレードであろうと現在の制限であろうと、まだ詳細に議論することがたくさんあります。システムが後のコースで進化し続けるので、それを詳細に分析し、基本的には説明しません。
2.システムの運用と保守
システム設計段階では、システムの可用性を確保するために、上記の方法を採用することができますが、システムの運用・保守のレベルで何ができるのでしょうか？実際、この2つからシステムを改善する方法を考えることができます。グレーリリースとフォールトドリルの側面。可用性。
ビジネスの円滑な運営中、システムに障害が発生することはめったになく、障害の90％はオンライン変更フェーズ中に発生することを知っておく必要があります。たとえば、新機能がある場合、設計上の問題により、低速のデータベースリクエストの数が倍増し、システムリクエストの速度が低下して誤動作します。変更がない場合、データベースが理由もなく非常に多くの遅い要求を生成するにはどうすればよいでしょうか？したがって、システムの可用性を向上させるには、変更管理に注意を払うことが重要です。問題が発生した場合に迅速にロールバックして回復するために必要なロールバック計画を提供することに加えて、別の主要な方法はグレーリリースです。
灰色のリリースとは、システムの変更が一度にオンラインにプッシュされるのではなく、一定の割合で徐々に進行することを指します。一般に、グレースケールパブリッシングはマシンディメンションで実行されます。たとえば、最初に10％のマシンに変更を加え、ダッシュボードでシステムパフォーマンスインジケーターとエラーログを確認します。一定期間実行した後、システムインジケータが比較的安定していて、エラーログが多数ない場合は、変更の全量が促進されます。
グレーリリースは、開発、運用、保守の学生に絶好の機会を提供し、システムの高可用性を確保するための重要なレベルであるオンライントラフィックへの変更の影響を観察できるようにします。
グレーリリースは、システムの通常の動作条件下でシステムの高可用性を保証する運用および保守方法です。では、障害が発生したときのシステムのパフォーマンスをどのように知るのでしょうか。ここでは、別の方法である障害ドリルに依存しています。
障害ドリルは、システムの潜在的な可用性の問題を発見するために、ローカル障害が発生したときにシステム全体がどのように動作するかを観察するためのシステムのいくつかの破壊的な方法を指します。
複雑な同時実行性の高いシステムは、ディスク、データベース、ネットワークカードなど、非常に多くのコンポーネントに依存しています。これらのコンポーネントはいつでもどこでも失敗する可能性があり、一度失敗すると、バタフライ効果のようにサービス全体が利用できなくなりますか？わからないので、フォールトドリルは特に重要です。
私の意見では、フォールトドリルは、より一般的な「カオスエンジニアリング」の考え方と同じです。カオスエンジニアリングの創始者として、2010年にNetfixによって発売された「カオスモンキー」ツールは、フォールトドリルの優れたツールです。オンラインシステム上のオンラインノードをランダムにシャットダウンすることで障害をシミュレートし、エンジニアがそのような障害の影響を理解できるようにします。
もちろん、これはすべて、システムがいくつかの異常な状況に耐えることができるという前提に基づいています。システムがまだこれを達成していない場合は、オンライン展開構造とまったく同じ別のオフラインシステムを構築してから、本番システムに影響を与えないように、このシステムでフォールトドリルを実行することをお勧めします。
コース概要
このレッスンでは、システムの可用性を測定する方法と、並行性の高いシステムを設計するときに高可用性を確保する方法を理解しました。そうは言っても、開発と運用の観点から、使いやすさを向上させる方法は異なることがわかります。
開発は障害への対処方法に焦点を合わせており、キーワードは冗長性とトレードオフです。冗長性とは、記事に記載されているフェイルオーバーやマルチアクティブアーキテクチャなど、障害が発生したサービスを置き換えるスペアノードとクラスターがあるという事実を指します。選択とは、警察の喪失とセキュリティのセキュリティを指します。メインサービス。
運用保守の観点からは、変更管理や障害訓練の実施方法など、障害を回避する方法に重点を置いて、より保守的になっています。
この2つを組み合わせることで、完全な高可用性システムを形成できます。
また、システムの使いやすさの向上は、ユーザーエクスペリエンスの犠牲やシステムパフォーマンスの犠牲に基づく場合があることにも注意する必要があります。また、対応するシステムを構築してメカニズムを改善するには、多くの人的資源が必要です。したがって、程度を把握する必要があり、過度の最適化を行うべきではありません。記事で述べたように、コアシステムでのフォーナインの可用性はすでに需要を満たすことができ、ファイブナインまたはシックスナインの可用性を盲目的に追求する必要はありません。
また、一般的なシステムやコンポーネントは究極のパフォーマンスを追求しているので、パフォーマンスを追求せず、究極の使いやすさだけを追求している人はいますか？答えはイエスです。たとえば、構成が分散されているシステムの場合、他のシステムの起動時に構成を提供するだけでよいので、数秒で返すことができ、10秒でOKです。これは、他のシステムの起動速度を上げるだけです。システム。ただし、可用性の要件は非常に高く、6ナインにさえ達します。その理由は、構成を取得するのに時間がかかるが、取得できないためです。
この例を挙げて、使いやすさとパフォーマンスの間にトレードオフがある場合があることをお知らせしますが、選択はシステムによって異なり、一般化することはできません。