記事ディレクトリ
序文
高可用性 HA (High Availability) は、分散システム アーキテクチャの設計において考慮する必要がある要素の 1 つであり、通常、システムがサービスを提供できない時間を設計によって削減することを指します。多くの企業の高可用性目標はフォーナイン、つまり 99.99% であり、これは年間システムのダウンタイムが 8.76 時間であることを意味します。システムの高可用性を確保するために、イベント前、イベント中、イベント後の 3 つの段階で技術レベルとビジネス レベルから問題を解決します。
事前
技術レベル
分散アーキテクチャと負荷分散:
分散型の冗長アーキテクチャを採用して、単一障害点を回避します。
ハードウェアの冗長性とは、単一のデバイスの障害によってシステム全体がダウンするのを防ぐために、重要なハードウェア コンポーネントの複数のバックアップを使用することを指します。たとえば、データ センターでは、1 つのコンポーネントの障害がサービス全体に影響を及ぼさないようにするために、複数のサーバー、複数のネットワーク パス、複数の電源などが配備されていることがあります。ハードウェアの冗長性には通常、サーバー、ストレージ デバイス、ネットワーク機器、電源が含まれますが、これらに限定されません。同じ都市内でデュアルアクティブ、2 か所で 3 つのセンター、遠隔地でマルチアクティブといった、いわゆるマルチアクティブ アーキテクチャです。ソフトウェアの冗長性により、複数のソフトウェア インスタンスまたはコピーを展開することでシステムの可用性が向上します。 。高可用性環境では、重要なサービスが複数のサーバーまたはノードで実行され、1 つのノードに障害が発生した場合でも、他のノードがサービスを提供し続けることができます。この手法は、各サービスが異なるサーバーまたはコンテナーで実行されている複数のインスタンスを持つ可能性があるマイクロサービス アーキテクチャで特に一般的です。
ロード バランサーを使用してトラフィックのバランスをとり、各ノードの負荷を均一にします。負荷分散は、ネットワーク トラフィックとリクエストを複数のサーバーまたはリソースに分散するための技術です。その目的は、リソースの使用を最適化し、スループットを最大化し、応答時間を短縮し、単一リソースの過負荷を回避することです。ロード バランサーは、要求を受信したときに事前設定されたルールに基づいてバックエンド サーバー ファームにトラフィックを分散するソフトウェアまたはハードウェア デバイスです。これらのルールは、サーバーの現在の負荷、状態、地理的位置などのさまざまな要因に基づくことができます。負荷分散により、ワークロードを複数のサーバーに分散でき、システムの可用性と信頼性が向上します。
ハードウェア負荷: 転用はハードウェアによって行われます。一般的なハードウェアには、比較的高価な F5 や Array などの商用ロード バランサが含まれます。その利点は、これらのサービスを保守する専門のメンテナンス チームが存在することです。欠点は、高価であることです。販売量が大きすぎるため、一般にインターネット システムで使用されることはほとんどありません。主に金融業界の基幹サービスに使用されます。
ソフトウェア負荷: Nginx/ などのソフトウェアを介して流用されます。 LVS/HAProxy、Linux ベースのオープンソースの無料負荷分散ソフトウェア。これらはすべてソフトウェア レベルで実装されており、コストは非常に低くなっています。 OSI モデルの作業レベルに応じて、7 層の負荷と 4 層の負荷に分けることができます。レイヤ7負荷とは、URLなどのアプリケーション層の情報に基づいてネットワークの第7層で動作する負荷分散のことで、主にNginxが代表的です。レイヤ 4 の負荷は、主に LVS を表す IP+ポートに基づく負荷分散です。
データのバックアップとフェイルオーバー:
基本的な考え方は、分散システム内のノードをバックアップすることであり、バックアップはコールド スタンバイとホット スタンバイに分けられます。データセンターは通常、ビジネスサービスを提供するアクティブと、サービスを提供せずバックアップとフェイルオーバーのみを提供するスタンバイの2種類に分けられます。
コールド バックアップもスケジュールされたバックアップであり、データのバックアップにはメインのプッシュまたはバックアップ プルが使用されます。
ホット バックアップとは、メイン データ センターに障害が発生した場合に転送できるように、メイン データ センターのリアルタイム バックアップを意味します。このとき、マスタとスレーブのデータレプリケーション方式には同期方式と非同期方式がありますが、同期させるとパフォーマンスが低下するため、通常は非同期方式が使用され、この場合、ある程度のデータ遅延が発生します。
フェイルオーバーには 2 つのモードがあり、それぞれに長所と短所があります。
アクティブ/パッシブ モードでは、1 つのサーバー (またはサービス インスタンス) がアクティブ ノードとして実行され、すべてのリクエストを処理します。一方、別のサーバー (または複数のサーバー) はパッシブ ノードとして機能し、スタンバイ状態になります。アクティブ ノードに障害が発生すると、システムは自動的にパッシブ ノードに切り替わり、パッシブ ノードがサービスを引き継ぐため、システムのダウンタイムが削減されます。このモデルの利点はシンプルで明確であることですが、欠点はバックアップ リソースがほとんどの時間アイドル状態であることです。
アクティブ/アクティブ モードでは、すべてのサーバーがアクティブでリクエストを処理します。このモデルではリソースの使用率が向上しますが、管理の複雑さも増加します。この設定では、1 つのノードに障害が発生した場合、全体のパフォーマンスに影響を与えることなく、他のノードがそのワークロードを引き継ぐことができる必要があります。これには、より複雑な負荷分散および同期メカニズムが必要になることがよくあります。
自動化されたデプロイメントとスケーリング:
自動化は高可用性を実現するための鍵です。これには、自動化された障害の検出と回復、負荷の変化に対応するリソースの自動スケーリング、自動化された展開と構成管理が含まれます。自動化により人的エラーが削減され、運用保守の効率が向上します。
監視および警報システム:
効果的な監視システムは、アプリケーションとインフラストラクチャの健全性をリアルタイムで追跡できます。これには、サーバーのパフォーマンス指標 (CPU 使用率、メモリ使用量、ネットワーク トラフィックなど) とアプリケーション レベルの指標 (応答時間、エラー率など) の監視が含まれます。モニタリングは、問題を適時に検出し、小さな問題が大きな問題に発展するのを防ぐための措置を講じるのに役立ちます。
アプリケーション ログを収集および分析して、潜在的な問題をタイムリーに発見し、迅速に対応して解決します。
自動アラート システムを設定して、潜在的な問題をすぐにチームに通知します。
ビジネスレベル
災害復興計画：
バックアップ リカバリ、システム移行、緊急運用手順を含む災害復旧計画を作成します。これには、緊急連絡先やチームが緊急事態に迅速に対応するための手順も含まれます。
チーム メンバーとともに災害復旧計画を定期的にトレーニングおよびテストし、実際の状況で効果的であることを確認します。
セキュリティ対策:
厳密な認証および認可メカニズムを実装して、許可されたユーザーのみが機密情報にアクセスしたり、インスタンスを変更したりできるようにします。
進行中
技術レベル
自動障害検出と回復:
事前設定された自動フェイルオーバー ポリシーが有効かどうかを確認し、有効でない場合は災害復旧計画を有効にします。通常の状況では、損失を最小限に抑えるために、迅速なバージョンのロールバックを実装する必要があります。
リアルタイム監視とログ分析:
システムのパフォーマンスをリアルタイムで監視し、リアルタイムの指標を追跡して、その後の問題を回避します。
リアルタイム アラート システムを通じて、潜在的な問題についてチームに即座に通知し、迅速な対応を実現します。
その後
技術レベル
事故の分析と改善:
事故分析を実施して、故障の原因を深く理解します。
同様の問題が再発しないように対策を講じ、システムを改善します。
ビジネスレベル
ユーザーへの通知とコミュニケーション:
何が問題でどのような措置が講じられたかを説明する詳細なインシデント レポートをユーザーに提供します。
ユーザー フィードバックを収集して、システムのユーザー エクスペリエンスを向上させます。
トレーニングと知識の共有:
学んだ教訓をトレーニング計画に組み込んで、チームが学んだ教訓を確実に習得できるようにします。
チームが互いの経験から学べるようにする知識共有メカニズムを実装します。
口語的な要約
システムの高可用性を確保するために、イベント前、イベント中、イベント後の 3 つの段階、および技術レベルとビジネス レベルを通じて、システムを包括的に処理できます。トラブルが起こらないように最善を尽くしなければならないため、事前の準備が最も重要です。技術レベルで実行できることはいくつかあります。まず、分散アーキテクチャの採用、冗長性の実装、ソフトウェアの観点からのクラスター展開の実装、およびハードウェアの観点からのマルチアクティブ戦略の実装です。 2 つ目は、データのバックアップと自動フェイルオーバーを適切に実行することです。 3 番目は、自動化されたデプロイメントと柔軟なスケーリングで適切な仕事をすることです。私の会社は独自に DevOps プラットフォームを開発し、自動化された CICD を実装しました。現在、リソースの柔軟なスケーリングはありません。アプリケーション ノードの数は手動で変更できます。各地でのマルチアクティブ戦略は現在も福州、北京にあり、サーバーはシンガポールに設置されています。 4つ目は監視と警報で、現在勤務している会社ではprometheus+grafanaを利用しており、K8sが提供するプローブを利用してサーバや一部アプリケーションの主要指標を監視し、警報と連携して担当者に速やかに通知して処理を行っています。ビジネスレベルでのポイントは2つあり、1つは緊急対応チームを編成すること、あるいは各プロジェクトの責任者に対して特別な災害復旧訓練を実施し、災害復旧計画の有効性を定期的にテストすることです。 2 つ目は、操作権限と外部依存関係を厳密に制御することです。私の会社は現在、自社開発の開発サービス プラットフォームをベースにしています。制御権限の一部のロールのみがサービスの変更を許可します。MySQLRedis などのミドルウェアについては、固定構成のアプリケーション リソースのみが提供されます」 。
当然ながら、緊急時に自動フェイルオーバーを実行できることが最善ですが、そうでない場合は、ただちに災害復旧計画を開始してください。問題の原因がサービスの変更である場合は、ただちにバージョンをロールバックして、サービスの安定した動作を確保してください。同時に、問題の再発を避けるためにモニタリング指標にも注意を払う必要があります。その後、技術レベルで事故分析を行い、故障原因を検討し、システムを改善するための技術的措置を講じるのは当然です。ビジネス レベルでは、トレーニングと学んだ教訓に関する知識の共有を提供し、影響を受けるユーザーに詳細なインシデント レポートを提供し、広報活動を実施し、補償を提供し、ユーザー フィードバックを収集し、ユーザー エクスペリエンスを最適化します。
最後に書きます
高可用性の一般的な概要はより理論的なものであり、最終的な概要には具体的な実践方法が追加されています。私が参加する機会や完全な体制に参加する機会があれば、実際の企業レベルの事例に基づいて説明します。