APIゲートウェイとロードバランサの違いと選択のポイント
APIゲートウェイとロードバランサは、どちらもモダンアプリケーションの構築に役立ちます。機能が重複する部分もありますが、両者は別物で、ユースケースが異なります。この記事では、APIゲートウェイとロードバランサの違い、それぞれの実装例、ウェブアプリケーションに合ったツールの選び方について説明します。
ロードバランサとは
ロードバランサとは、APIリクエストのトラフィックを複数のサーバーに分散させるためのツールです。ロードバランサを構成要素として取り入れ、特定のリソースへの過負荷を防ぐことで、システムの反応速度を向上させ、障害を抑制できます。
クライアントがサービス（例えばウェブサイトや動画）にリクエストを送信すると、ロードバランサがこれを受信し、その処理と応答をどのサーバーに担当させるかを決定します。これを表したのが、下の図です。各種のクライアントと、リクエストに応じた処理を行うバックエンドのサーバーファームとの間に、ロードバランサがあります。
ロードバランサのメリット
ロードバランサはさまざまな機能を備えており、次のような形で役立ちます。
クライアントとサーバーの間に、ロードバランサという間接接続のレイヤーが加わることで、クライアントからサーバーへの直接接続をブロックできます。いずれかのサーバーが変更されたり、サーバーファームから削除されたりしても、クライアントはこれを関知せず、影響を受けません。
ロードバランサはサーバーの不具合を検知し、該当するサーバーをローテーションから除外できます。また、現時点で最も処理が高速なサーバーや飽和状態にあるサーバーを把握できます。ロードバランサはその情報に基づいて、各サーバーに割り当てる接続を増減します。こうしたヘルスチェック機能やパフォーマンス追跡機能は実用的で有益です。
HTTPSオフロードなどの高度な処理をこなすロードバランサもあります。その場合、クライアントはHTTPSでロードバランサとセキュアに接続し、ロードバランサはHTTPでバックエンドサーバーと接続します。
キャッシングやコンテンツベースのルーティングなど、機能がさらに豊富なロードバランサもあります。
ロードバランサのユースケース
ここまでに説明したロードバランサの役割を知れば、ロードバランサがどのような状況で役立つかおわかりいただけたことでしょう
結局のところ、複数のサーバーによるネットワークサービスを構築する際には、ロードバランサは必須です。サーバーの使用率の最適化につながるほか、いずれかのサーバーで障害が発生した場合や、そのサーバーをローテーションから除外した場合に、ある程度の信頼性を確保できます。
APIゲートウェイとは
APIゲートウェイについて詳しくは、別の解説記事をお読みいただければと思いますが、要点だけ説明すると、APIとはコンピューティングリソース同士が通信するためのインターフェースであり、APIゲートウェイとはAPIコンシューマとAPIの仲立ちとなるものです。
APIゲートウェイの役割
APIコンシューマとAPIの間になぜ仲立ちを置くかというと、例えばネットワーク内のさまざまな場所にAPIを分散してデプロイしているときに、APIゲートウェイの高度な機能を活かして、APIのセキュリティ、オブザーバビリティ、信頼性を向上させることができるからです。APIゲートウェイには次のような機能があります。
トラフィック制御
APIゲートウェイを利用して適用できるトラフィック制御機能としては、キャッシュとレート制限の2つが特に一般的です。
- キャッシュは、APIコンシューマにとっては応答の高速化につながり、バックエンドサーバーにとっては繰り返し発生する過負荷を防ぐ効果があります。
- レート制限は、所定の時間内でコンシューマが実行できるリクエストの合計回数を抑制し、コンシューマによるAPIの濫用や悪用を未然に防ぐ効果があります。
その他にも、例えばリクエストの検証や変換などのトラフィック制御機能があります。
認証と認可
APIゲートウェイは、APIコンシューマの認証と認可も可能です。
例えば、ここに防御が必要なAPIがあり、コンシューマはこのAPIを利用する前に、ID検証のための認証情報を渡す必要があるとします。APIゲートウェイを導入していない場合には、こうした検証を個々のAPIに実装する必要があります。しかしゲートウェイがある場合には、そちらで代行できるため、API側の負担が軽くなります。個々のAPIに任せた場合、コンシューマのID検証やアクセス許可が一貫して適用される保証がないため、ゲートウェイで対応することは重要です。
APIゲートウェイを利用して、このプロセスを明確に取り入れ、すべてのAPIに一律に適用することによって、セキュリティ態勢の一貫性が高まり、リスクを抑えられます。
主なAPI認証手法について、詳しくはこちらをご覧ください。
メトリクスとログ
APIは、ひとまとまりの独立した機能であり、プロダクトとしても提供できます。その場合、APIオーナーは、自分たちのプロダクトをどのユーザーがどの程度利用しているか知る必要があります。APIゲートウェイでは、使われたAPI、そのレイテンシ、エラー率などのデータから、個別のリクエストの具体的な情報に至るまで、各種のメトリクスを収集できます。
ロードバランシング
APIはロードバランシングに関する処理の一部に対応できますが、ロードバランサ自体の代わりにはなりません。さまざまなバックエンドサーバーにトラフィックを振り分ける機能はAPIゲートウェイにもあり、アクティブやパッシブのヘルスチェックに基づいて、サーバーをローテーションから除外するタイミングを判断します。次のセクションでは、APIゲートウェイとロードバランサを併用する方法について、さらに詳しく説明します。
APIゲートウェイの主なユースケース
APIゲートウェイのユースケースで最も一般的なのは、APIコンシューマと各種APIの間に、間接接続のレイヤーを配置する用途です。
このユースケースを示したのが下の図です。この図はAPIが1つですが、実際には、単一のAPIゲートウェイから数十個や数百個のAPIに対してトラフィックを転送することもあります。
APIゲートウェイとロードバランサの併用
APIゲートウェイとロードバランサの基礎に関するここまでの説明を踏まえて、両者を併用する方法を見ていきましょう。以下、要件の変化に応じてアーキテクチャがどのように変わっていくかを図示していきます。
まずは、1つのAPIと、そのAPIを利用するコンシューマがあるとします。この時点では、APIゲートウェイもロードバランサもありません。
やがて、このAPIを利用するコンシューマが増え、APIのサービスが過負荷になってきました。APIサーバーのインスタンスをいくつか追加で立ち上げる必要があります。そして、インスタンス間で負荷を分散するために、ロードバランサを導入することにします。
ここで導入したロードバランサは、APIエンドポイント間の負荷分散に加えて、HTTPSオフロードにも対応しています。しかし、クライアントの数はその後も増え続けています。APIサーバーの数をさらに増やしてもよいのですが、ここでいくつか要望が出てきました。まずは、いくつかの要素に応じてキャッシュの精度を調整できるAPI対応のキャッシュを導入すること。次に、個々のクライアントが所定の時間で実行できるAPIコールの回数に上限を設けること。さらに、APIの使用状況についてのメトリクスも追加で収集することです。そこで、APIゲートウェイを導入することにします。APIと同様に、可用性が非常に優れたAPIゲートウェイを採用します。
ここでは、2つのAPIゲートウェイをペアで導入しました。必要なポリシーはすべてここで適用します。ゲートウェイは実質的にサービスであるため、その手前にロードバランサを配置します。必要なときには、ゲートウェイはさらに増やせます。また、ゲートウェイのメンテナンスを1つずつ行えば、APIクライアントの動作を妨げる心配はありません。そのほか、ここでは一連のAPIエンドポイントを新たに追加しました。APIゲートウェイはそちらのエンドポイントに対しても負荷分散を行い、異なるポリシーを適用します。当面はこの構成でうまくいくでしょう。なお、この構成にはロードバランサとAPIゲートウェイの両方が活用されています。
ロードバランサとAPIゲートウェイを利用することで、サービスの品質、セキュリティ、パフォーマンス、信頼性は向上します。両者は相乗効果を発揮し、それぞれに最適な用途は補完関係にあります。