スケーラビリティを高める5つの主要パターン

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

アプリケーションが通貨にも等しい価値を持つ経済において、可用性は極めて重要です。応答しないアプリは即座に削除され、Yelpの辛辣な低評価レビューさながらの速さと皮肉をもって、インターネット上で酷評されます。

インターネットの黎明期から、組織はアプリケーション（当時はWebサイト）を24時間365日利用できるよう努めてきました。インターネットは眠ることも、休暇を取ることも、病欠することもないからです。

そのニーズ（実際には要件）に応えるため、可用性を確保する初期のアプリケーションサービスの1つとして、スケーラビリティが登場しました。可用性のニーズに応えるアプリケーションサービスの中で、最も広く知られ、よく理解されているのが負荷分散です。

ただし、負荷分散にはさまざまな形態があり、この中核技術を活用して実装できるスケーラビリティパターンも数多く存在します。今回は、アプリケーションとインターネットを24時間365日オンラインかつ利用可能な状態に保つために活用されている、代表的な5つのスケーラビリティパターンをご紹介します。

グローバルサーバーロードバランシング（GSLB）

GSLBという名称は、実態をまったく適切に表していません。そもそも重要なのはサーバーの負荷分散ではなく、サイトの可用性でした。現在では、その意味がアプリの可用性にまで広がっています。

GSLBを使用すると、1つのデータセンター（クラウドまたは従来型）が応答しない場合に、別のデータセンターを見つけられるようにすることができます。GSLBはドメインレベルまたはホストレベルで適用できます。そのため、example.comの接続先ロケーションを切り替えられるほか、api.example.com.

最も基本的なGSLBでは、DNSベースの簡易的な負荷分散を使用します。ドメインまたはホストに関連付けられたIPアドレスのリストを保持し、最初のIPアドレスが利用できない場合は、リスト内の2番目、さらに3番目、4番目という順にリクエストを振り分けます。

このプロセスは、次の2つのステップで構成されます。

1. グローバルロードバランサーに適切なIPアドレスを問い合わせます。これはGSLBに常につきまとう欠点です。過去15分以内、またはcheese.comのIPアドレスに現在設定されているTTLの期間内に問い合わせていた場合、前回受信した応答が返されます。そのため、その間にそのサイトが停止しても、接続できません。
2. GSLBへの問い合わせで返されたサイトのIPアドレスにリクエストを送信します。多くの場合、これは独自のアルゴリズムと意思決定プロセスを使用して、リクエストを適切なリソースに転送するローカルロードバランサーです。

通常、ステップ1の判断に高度なインテリジェンスはなく、特定のサイトが応答しているかどうかだけに基づいて行われます。それでも、この仕組みにより、クラウド、ホスティングプロバイダー、オンプレミスなど複数のロケーションを利用して可用性を確保できます。地理的に分散した地域のロケーションを戦略的に選択することで、自然災害やインターネット障害の影響を回避できます。

ただし、これはどちらかといえばDR（災害復旧）やBC（事業継続）のシナリオです。ほかにも、位置情報やアプリケーションパフォーマンスなど、より高度なGSLBアプリケーションサービスを活用するシナリオがあります。たとえば、サイトAのアプリのパフォーマンスが低下している場合、問題が解決するまで訪問者をサイトBに誘導できます。また、パフォーマンスの向上を図るため、地理的に最も近い拠点へユーザーを誘導することもできます（光速という物理的な制約がある以上、距離はアプリのパフォーマンスに影響するためです）。

どのような基準で判断する場合でも、基本的なパターンは変わりません。GLSBは、利用可能なサイトのいずれかのIPアドレスを返すことで、物理的に離れた複数のサイトにリクエストを分散します。APIでもアプリでも、GSLBは可用性を確保するための最上位のパターンです。

従来型のロードバランシング（POLB）

接続ベースの可用性

Plain Old Load Balancing（POLB）は、標準的なTCPベースの負荷分散を表すために私が好んで使う用語です。このパターンでは、アプリを複製し、クライアント（ユーザーやデバイス）とアプリ間の接続を確立できるようにするだけで、可用性を確保できます。

ロードバランサー（プロキシと呼んでも構いません）は接続要求を受信すると、利用可能なアプリインスタンスを選択し、そのインスタンスに接続を転送します。ロードバランサーが積極的に関与するのは、ここまでです。これは、2人の同僚を引き合わせる「紹介メール」のようなものです。最初のやり取りには積極的に参加しますが、その後はCCに移り、通常はそれ以上関与しません。

リクエストの転送先はアルゴリズムだけで決まるため、私はPOLBという用語を使っています。残念ながら、リクエストの分散に使用するアルゴリズムによっては、さまざまな問題が発生する可能性があります。たとえば、ラウンドロビンでは、処理能力やパフォーマンスは考慮されません。単に「次のアプリ」を選択し、そこにリクエストを転送します。「最小接続数」を選択すると、ほかにより高速なリソースがあっても、特定のリソースに負荷が集中し、パフォーマンスが急速に低下する可能性があります。そのため、可用性を維持するうえで、アルゴリズムの選択が極めて重要になります。

POLBは、コンテナ環境内や多くのクラウドネイティブな負荷分散サービスで標準的に使用される負荷分散方式です。

パーシステンス

スティッキーセッションとSSL

3層アプリケーションは、一般にステートフルであるという特性があります。つまり、アプリケーションの動作に不可欠な情報を、リクエストとレスポンスの間で保持します。ショッピングカート、認証情報、ステータス、最後に閲覧したページ、処理のどの段階にいるかといった情報は、多くの場合「セッション」の一部として保存されます。ただし、3層フレームワークを使用して開発された多くのアプリでは、そのセッションがデータベースではなく、アプリケーションサーバーまたはWebサーバーに保存されていました。そのため、いったん特定のサーバーに接続すると、すべての情報を利用できるようにするには、同じサーバーに継続してアクセスする必要がありました。

ロードバランサーはさまざまな方法でパーシステンスを実装していましたが、最も一般的だったのはCookieベースの方式です。セッションIDをCookieに保存し、ロードバランサーがそのIDを使用してリクエストを適切なサーバーに転送することで、実質的にアルゴリズムによる選択プロセスを回避していました。

買い物客が安心して利用するためにSSL/TLSの使用が不可欠になると、同じ問題が生じました。SSL/TLSは、クライアントと特定のアプリケーションサーバー間にセキュアなセッションを確立します。その接続を介して交換されるデータを通信の両端で復号して利用できるようにするには、ロードバランサーがクライアントのリクエストを最初に接続したサーバーへ送信できる必要がありました。ロードバランサーは、セッションベースのパーシステンスを実現する手法と同じものを使用することで、SSL/TLSベースのパーシステンスをサポートできるようになりました。

使用するパーシステンスの種類にかかわらず、動作パターンは同じです。セッションがすでに確立されていることを示す情報がある場合、ロードバランサーは既存の接続を維持し、ユーザーセッションの継続中はその接続が保持されるようにします。そのような情報がない場合は、設定とアルゴリズムに基づいてリソースを選択し、接続を確立します。

これは、負荷分散アルゴリズムを選択する際のキャパシティプランニングに影響します。このシナリオでは、継続中のセッションが単一のリソースに集中して過負荷になる一方で、ほかのリソースがアイドル状態になることを防げるため、最小接続数方式が適しています。ほかのアルゴリズムでは、単一のリソースが多数のユーザーセッションを同時に維持することになり、そのサーバーに振り分けられたすべてのユーザーのパフォーマンスに悪影響を及ぼす可能性があります。

ホストベースの負荷分散

仮想サーバー

ホストベースの負荷分散は、最も一般的で広くサポートされているスケーラビリティパターンの1つです。すべてのWebサーバーは、複数のホストとして同時に動作できるため、このパターンの実装にロードバランサーは不要と思われるかもしれません。しかし、実際には必要です。Web／アプリケーションサーバーは複数の仮想サーバーをホストできますが、それらの間で必ずしも負荷を分散するわけではありません。そのため、スケールするにはロードバランサーが必要です。問題は、ホストの振り分けをロードバランサーで行うか、Web／アプリケーションサーバーに任せるかです。

Web／アプリサーバーのディレクティブを使用する場合も、外部ロードバランサーを使用する場合も、処理の流れは同じです。リクエストが送信され、ターゲット（ロードバランサーまたはWeb／アプリサーバー）が受信します。次に、ターゲットサーバーがHTTPヘッダーを調べてHost値を特定し、適切な仮想サーバーにリクエストを転送します。

ロードバランサーを使用してホストを分割すると、ホストごとにドメインを分離し、個別にスケールできるという利点があります。これにより効率が向上し、アプリケーションのスケーリングに必要なサーバー（ハードウェアおよびソフトウェア）の数を削減できる可能性があります。また、各ホストサーバーが特定の時点で処理できる負荷をより正確に予測できるため、キャパシティプランニングも容易になります。

これは、ビジネスロジックの呼び出しと画像のリクエストでは、必要なコンピューティングリソースが異なるためです。同じスケーラビリティドメインに複数のホストを混在させると、負荷が変動しやすくなり、必要なキャパシティを予測しにくくなります。ロードバランサーを単純な負荷分散に使用する場合、ホストの分割と、適切な仮想サーバーへのリクエストの振り分けは、Web／アプリケーションサーバーが担います。このアプローチには、インフラストラクチャを共有することによるデメリットもあります。バージョンの競合、パッチ適用、アプリケーションの更新によって、仮想サーバー間に問題が生じる可能性があります。

コンテナとマイクロサービスの普及に伴い、ホストベースの負荷分散を実現するIngress Controllerの利用が拡大しています。

ルーティングとリターン

レイヤー7（HTTP）ロードバランシング

レイヤー7（HTTP）ロードバランシングは、柔軟性（俊敏性？）に優れているため、私のお気に入りです。ペイロードを含め、HTTPに関するあらゆる情報に基づいてリクエストを負荷分散できます。多くの方は（賢明な判断だと思いますが）、ロードバランシングルールの対象をHTTPヘッダー内の情報に限定しています。たとえば、ホスト、HTTPメソッド、Content-Type、Cookie、カスタムヘッダー、User-Agentなどです。

HTTPロードバランシングでは、まずルーティングを行い、その後に負荷を分散します。一般的なHTTPロードバランシングのパターンは、「ルーティング –> 分散」という形を取ります。つまり、最初にリクエストの転送先となる仮想サーバーを決定し、次にアルゴリズムによって、その仮想サーバーを支えるプールからリソースを選択します。

HTTPロードバランシングでは、APIのバージョンをURI（またはカスタムHTTPヘッダー）に埋め込むAPIバージョニングなどのパターンを実現できます。ロードバランサーはバージョンを識別し、クライアントからのリクエストを実行先となる適切なバックエンドサービスに確実に送信できます。これにより、強制的にアップグレードできない場合でも、クライアントを常に円滑に移行できます。

このタイプのスケーラビリティパターンは、機能分割やデータパーティショニングなど、ほかのスケーラビリティパターンにも対応します。なかでも特に堅牢で俊敏性に優れたパターンであり、アプリケーションや、採用が拡大しているマイクロサービスをスケールアウトする際に、幅広い選択肢を提供します。

まとめると、主要なスケーラビリティパターンは5つあり、そのほとんどは組み合わせることができ、実際によく併用されています。これにより、リソースを最大限に効率よく活用し、可能な限り高いパフォーマンスを実現できます。現在いずれのパターンも使用していない場合でも、今後使用する可能性は高いでしょう。そのため、各パターンの基本構成を理解しておくことは、使用するアプリの種類やデプロイ先を問わず、スケーラブルなアーキテクチャを構築するための確かな基盤となります。

スケールを続けましょう！

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事