序章

重要なシステムにサービスを提供するように設計された信頼性とパフォーマンスの高いインフラストラクチャに対する需要が高まる中、スケーラビリティと高可用性という用語はこれ以上人気がありません。 増加したシステム負荷の処理は一般的な懸念事項ですが、ダウンタイムの削減と単一障害点の排除も同様に重要です。 高可用性は、これらの後者の考慮事項に対処する大規模なインフラストラクチャ設計の品質です。

このガイドでは、正確に高可用性とは何を意味し、インフラストラクチャの信頼性をどのように向上させることができるかについて説明します。

高可用性とは何ですか?

コンピューティングでは、可用性という用語は、サービスが利用可能である期間、およびユーザーからの要求に応答するためにシステムが必要とする時間を表すために使用されます。 高可用性とは、一定期間、高レベルの運用パフォーマンスを保証するシステムまたはコンポーネントの品質です。

可用性の測定

多くの場合、可用性は、特定のシステムまたはコンポーネントから特定の期間に予想される稼働時間を示すパーセンテージとして表されます。100%の値は、システムに障害が発生しないことを示します。 たとえば、1年間で99%の可用性を保証するシステムでは、最大3。65日のダウンタイム(1%)が発生する可能性があります。

これらの値は、スケジュールされたメンテナンス期間とスケジュールされていないメンテナンス期間の両方、およびシステム障害の可能性から回復する時間など、いくつかの要因に基づいて計算されます。

高可用性はどのように機能しますか?

高可用性は、インフラストラクチャの障害対応メカニズムとして機能します。 それが機能する方法は、概念的には非常に単純ですが、通常、いくつかの特殊なソフトウェアと構成が必要です。

高可用性はいつ重要ですか?

堅牢な本番システムをセットアップする場合、ダウンタイムとサービスの中断を最小限に抑えることが優先度が高いことがよくあります。 システムとソフトウェアの信頼性に関係なく、アプリケーションやサーバーをダウンさせる可能性のある問題が発生する可能性があります。 インフラストラクチャに高可用性を実装することは、これらのタイプのイベントの影響を減らすための有用な戦略です。 高可用性システムは、サーバーまたはコンポーネントの障害から自動的に回復できます。

システムの高可用性を実現する理由は何ですか?

高可用性の目標の1つは、インフラストラクチャの単一障害点を排除することです。 単一障害点は、テクノロジースタックのコンポーネントであり、サービスが利用できなくなった場合にサービスの中断を引き起こします。 そのため、冗長性を持たないアプリケーションの適切な機能に必要なコンポーネントは、単一障害点と見なされます。 単一障害点を排除するには、スタックの各レイヤーに冗長性を持たせる必要があります。 たとえば、ロードバランサーの背後にある2つの同一の冗長Webサーバーで構成されるインフラストラクチャがあるとします。 クライアントからのトラフィックはWebサーバー間で均等に分散されますが、サーバーの1つがダウンした場合、ロードバランサーはすべてのトラフィックを残りのオンラインサーバーにリダイレクトします。

このシナリオのWebサーバー層は、次の理由で単一障害点ではありません。

  • 同じタスクの冗長コンポーネントが配置されている
  • このレイヤーの最上位のメカニズム(ロードバランサー)は、コンポーネントの障害を検出し、その動作をタイムリーな回復に適応させることができます

しかし、ロードバランサーがオフラインになるとどうなりますか?

説明したシナリオでは、実際には珍しいことではありませんが、負荷分散レイヤー自体が単一障害点のままです。 ただし、この残りの単一障害点を排除することは困難な場合があります。 冗長性を実現するために追加のロードバランサーを簡単に構成できますが、障害の検出と回復を実装するためのロードバランサーの上に明確なポイントはありません。

冗長性だけでは高可用性を保証できません。 スタックのコンポーネントの1つが使用できなくなったときに、障害を検出してアクションを実行するためのメカニズムを導入する必要があります。

冗長システムの障害の検出と回復は、上から下へのアプローチを使用して実装できます。上の層は、そのすぐ下の層の障害を監視する責任があります。 前のシナリオ例では、ロードバランサーが最上位層です。 Webサーバーの1つ(最下層)が使用できなくなった場合、ロードバランサーはその特定のサーバーへの要求のリダイレクトを停止します。

Diagram 01: Load Balancers / Top-to-bottom

このアプローチは単純になる傾向がありますが、制限があります。インフラストラクチャには、ロードバランサーレイヤーの場合のように、最上位レイヤーが存在しないか、到達できないポイントがあります。 外部サーバーでロードバランサーの障害検出サービスを作成すると、新しい単一障害点が作成されるだけです。

このようなシナリオでは、分散型アプローチが必要です。 複数の冗長ノードをクラスターとして接続する必要があります。各ノードは、障害の検出と回復を同等に実行できる必要があります。

Diagram 02: Cluster / Distributed

ただし、ロードバランサーの場合、ネームサーバーの動作方法が原因で、さらに複雑になります。 ロードバランサーの障害からの回復は、通常、冗長ロードバランサーへのフェイルオーバーを意味します。これは、ドメイン名が冗長ロードバランサーのIPアドレスを指すようにDNSを変更する必要があることを意味します。 このような変更は、インターネット上で伝播するのにかなりの時間がかかる可能性があり、このシステムに深刻なダウンタイムを引き起こす可能性があります。

考えられる解決策は、DNSラウンドロビン負荷分散を使用することです。 ただし、このアプローチは、フェイルオーバーをクライアント側アプリケーションに残すため、信頼性がありません。

より堅牢で信頼性の高いソリューションは、フローティングIP など、柔軟なIPアドレスの再マッピングを可能にするシステムを使用することです。 オンデマンドIPアドレスの再マッピングは、必要なときに簡単に再マッピングできる静的IPアドレスを提供することにより、DNS変更に固有の伝播とキャッシュの問題を排除します。 ドメイン名は同じIPアドレスに関連付けたままにすることができますが、IPアドレス自体はサーバー間で移動されます。

フローティングIPを使用した高可用性インフラストラクチャは次のようになります。

Diagram 03: Floating IPs

高可用性にはどのようなシステムコンポーネントが必要ですか?

実際に高可用性を実装するには、慎重に考慮する必要のあるコンポーネントがいくつかあります。 ソフトウェアの実装だけでなく、高可用性は次のような要因に依存します。

  • 環境:すべてのサーバーが同じ地理的領域にある場合、地震や洪水などの環境条件によってシステム全体がダウンする可能性があります。 さまざまなデータセンターや地理的領域に冗長サーバーを配置すると、信頼性が向上します。
  • ハードウェア:高可用性サーバーは、停電やハードディスクやネットワークインターフェイスなどのハードウェア障害に対して回復力がある必要があります。
  • ソフトウェア:オペレーティングシステムとアプリケーション自体を含むソフトウェアスタック全体は、たとえばシステムの再起動が必要になる可能性のある予期しない障害を処理できるように準備する必要があります。
  • データ:データの損失と不整合は、いくつかの要因によって引き起こされる可能性があり、ハードディスクの障害に限定されません。 高可用性システムは、障害が発生した場合のデータの安全性を考慮する必要があります。
  • ネットワーク:計画外のネットワーク停止は、高可用性システムのもう1つの考えられる障害点を表しています。 起こりうる障害に備えて、冗長ネットワーク戦略を実施することが重要です。

高可用性を構成するために使用できるソフトウェアは何ですか?

高可用性システムの各レイヤーには、ソフトウェアと構成の点で異なるニーズがあります。 ただし、アプリケーションレベルでは、ロードバランサーは、高可用性セットアップを作成するための不可欠なソフトウェアです。

HAProxy (高可用性プロキシ)は、複数のレイヤーで負荷分散を処理できるため、およびデータベースサーバーを含むさまざまな種類のサーバーで、負荷分散に一般的な選択肢です。

システムスタックを上に移動する場合、アプリケーションエントリポイント(通常はロードバランサー)に信頼性の高い冗長ソリューションを実装することが重要です。 前述のように、この単一障害点を取り除くには、フローティングIPの背後にロードバランサーのクラスターを実装する必要があります。 CorosyncとPacemakerは、UbuntuサーバーとCentOSサーバーの両方でこのようなセットアップを作成するための一般的な選択肢です。

結論

高可用性は、信頼性エンジニアリングの重要なサブセットであり、システムまたはコンポーネントが特定の期間に高レベルの運用パフォーマンスを発揮することを保証することに重点を置いています。 一見すると、その実装は非常に複雑に見えるかもしれません。 ただし、信頼性の向上を必要とするシステムに多大なメリットをもたらす可能性があります。