高可用性を実現するために答えるべき 2 つの質問

おそらく、消費者と従業員のデジタル体験への突然の移行による業務への最大の影響は、可用性です。 確かに、従業員がオフィスから自宅へ移動するにつれて、かなりの割合の組織がリモート アクセスに苦労しました。 しかし、一部の労働者だけが在宅勤務をするようになり、国民全体が突然、日常生活のデジタル化に頼るようになった。 

ノキアの調査結果を検討してみましょう。同社は、「2020年3月のアップストリームトラフィック（米国の一部のネットワーク）」では「パンデミック前のレベルと比べてアップストリームトラフィックが30％増加した」と報告しています。 または、このデータは、 4 月の第 2 週にトランザクションが 72% 増加し、ページ ビューが 29% 増加したことを示しています。  

デジタル体験に対する需要が高まっています。 アプリやウェブサイトが読み込まれないことほど、ユーザーにとってイライラすることはほとんどないでしょう。 正直に言うと、オペレーターにとって、アプリやウェブサイトが読み込まれないことほどイライラすることはほとんどないでしょう。

高可用性を実現するには、データ パスにロード バランサーを挿入するだけでは十分ではありません。 これは方程式の一部ですが、アプリや Web サイトが利用可能であることを保証するために必要な手順の 1 つにすぎません。

最初に行う必要があるのは、それほど単純ではない 2 つの質問に答えることです。

• 高可用性を実現するために、サーバー間でトラフィックをどのように分散しますか?
• サーバーの可用性を適切に検証するには、どのようなレベルのヘルスチェックが必要ですか?

一見すると、これらは実際よりも単純に見えます。 なぜなら、それらの質問に答えるには、アプリとそのインフラストラクチャについて多くのことを知る必要があるからです。

さあ、始めましょうか。

高可用性を実現するために、サーバー間でトラフィックをどのように分散しますか?

この質問は、トラフィック (リクエスト) がリソース (サーバー) 間でどのように分散されるかを決定するのはアルゴリズムであるため、実際に使用すべき適切な負荷分散アルゴリズムについて掘り下げています。 その答えは多くの要因に依存しますが、アプリのアーキテクチャと使用パターンから始まります。 

従来のアプリ (モノリス、クライアント サーバー、3 層 Web) の可用性を高めようとする場合、まったく異なる観点から使用パターンを理解する必要があります。

これは、1 つのバックエンド「サーバー」がすべてのビジネス ロジックの実行を担当するためです。 ログインしようとしていますか? 商品を注文しますか? カタログを閲覧していますか? すべて同じ「サーバー」です。 そうなると、ラウンドロビンのような単純なアルゴリズムを使用してトラフィックを分散できると考えるかもしれません。 まったく逆だ、友よ。 各ビジネス機能には、コンピューティング、メモリ、ネットワーク、およびデータの要件が異なります。 つまり、各ビジネス機能は「サーバー」に異なる負荷をかけます。 単一の「サーバー」インスタンスは、リソースを大量に消費するリクエストを大量に送信することで、すぐに過負荷になる可能性があります。

従来のアプリの可用性を確保するためにリクエストの分散を最適化する最善の方法は、最小接続ベースのアルゴリズムを使用することです。 これにより、現在開いている接続の数に基づいて、「サーバー」のインスタンス間で負荷が分散されます。 これが機能する理由は、リソースを大量に消費するリクエストは処理に時間がかかるため、接続がアクティブなままになるためです。 接続数の少ない「サーバー」にリクエストを送信することで、すべてのサーバーを利用可能な状態に維持できる可能性が高くなります。  

最新の（マイクロサービスベースの）アプリの場合、この質問への回答はより簡単になります。 これは、最新のアプリがすでに個別に拡張できるビジネス機能に分解されているためです。 同じ機能に対する一部のリクエストが他のリクエストよりも多くのリソースを消費する可能性があるため、最小接続ベースのアルゴリズムを使用することをお勧めしますが、最新のアプリ アーキテクチャではトラフィックが自然にバランスされるため、ほぼすべての「サーバー」を利用可能な状態に保つためにどのアルゴリズムでも役立ちます。

可用性に関して興味深いのは (少なくとも私にとっては)、リクエストを分散する方法を知ることは戦いの半分にしか過ぎないということです。 もう 1 つは、残念ながら赤と青のレーザーではなく、applicationの健全性状態の可視性に依存しています。

サーバーの可用性を適切に検証するには、どのようなレベルのヘルスチェックが必要ですか?

ここに、観測可能性*に関する私の論文を挿入すべきところがありますが、簡潔さと読者の健全性のために、次のように要約します。 

アプリの状態を判断するために「applicationの可用性」以外のものを使用している場合は、高可用性が危険にさらされます。 これは、他の観測可能な測定値のいずれもアプリについて何も教えてくれないからです。ネットワーク、トランスポート、プラットフォームの可用性は必要ですが、アプリがリクエストを受信できる状態であることが保証されるまで、トラフィックを送信するとトラブルを招くことになります。

可観測性の 4 つのコンポーネントはすべて重要です。 結局のところ、ネットワーク接続が失われると、残りは問題になりません。 したがって、4 つの対策すべてに注意を払い、すべてをチェックする必要があります。 アプリのアーキテクチャが何であるかは関係ありません。 すべてのアプリは、ネットワーク、トランスポート、プラットフォームの各レイヤーに依存しています。 アーキテクチャが違いを生むのはアプリ層です。アーキテクチャによって、アプリが動作しているかどうかを判断する方法が制約される可能性があるためです。

開発中は常にアプリの「ヘルスチェック」を行う方法を求める必要があります。 API 経由か HTTP リクエスト経由かを問わず、専用の「ヘルス チェック」が存在することで、開発者と運用担当者はアプリが正しく動作していることを簡単に検証できるようになります。 これには、データやパートナー API などの外部リソースへの接続を検証する機能が含まれる場合があります。 これらのコンポーネントのいずれかに障害が発生すると、アプリが使用不可になったり、消費者に応答しなくなったりする可能性があるため、必要なすべてのコンポーネントが利用可能かどうかを確認することが重要です。

高可用性は見た目よりも難しい

多くの場合、マーケティング資料では、高可用性はサーバーのクローンを作成し、その前にロード バランサーを配置するのと同じくらい簡単であると信じられています。 しかし、現実には、アプリの高可用性を確保するには、真剣な検討、測定、準備が必要です。 インスタンスが利用可能であることを確認することだけが問題ではありません。依存するすべてのアプリが利用可能であることを確認し、特定のインスタンスに過負荷をかけない方法でリクエストを分散することが問題です。

アプリの高可用性を確保するために費やす余分な作業のメリットは、顧客エクスペリエンスが向上し、アプリがダウンしていることを知らせる深夜の慌てた電話が減ることです。

_{* 実際のところ、私は観測可能性に関する論文を持っていません。 しかし、もしそうしていたら、ここに挿入されていたはずです。}