API ゲートウェイとロード バランサーは、最新のアプリケーションを構築するための便利なツールです。これらは重複する機能もありますが、目的と用途が異なる別個のツールです。この記事では、API ゲートウェイとロード バランサーの違い、実装例、Web アプリケーションに適したツールの選び方について説明します。
ロード バランサーとは
ロード バランサーは、API リクエストのトラフィックを複数のサーバーに分散するコンポーネントです。これにより、個々のリソースの過負荷が防止されるため、システムの応答性が向上し、障害の発生が軽減されます。
サービス (Web サイトやビデオなど) に対してリクエストが行われると、ロード バランサーはリクエストを受け取り、どのサーバーがリクエストを処理して応答するかを決定します。次の図に示すように、ロード バランサーは、さまざまなクライアントとリクエストを処理するバックエンド サーバー ファームの間にあります。
ロード バランサーを使用するメリット
ロード バランサーは、以下のような便利な機能を提供します。
- クライアントとサーバーの間の間接的なレイヤーとして、サーバーへの直接接続からクライアントを保護します。つまり、サーバーが変更されても、あるいはファームから削除されても、クライアントはそれを知ることも、それにより影響を受けることもありません。
- サーバーの障害を検知してローテーションから外したり、現在最速のサーバーや飽和しているサーバーを把握できます。この情報に基づいて、接続の割り当てを増やしたり、減らしたりします。これは実用的な利点をもたらす、有用な健全性とパフォーマンス追跡機能です。
- ロード バランサーの中には、HTTPS オフロードのような、より複雑なタスクを処理できるものもあります。その場合、クライアントは HTTPS でロード バランサーに安全に接続し、ロード バランサーはバックエンド サーバーに HTTP 接続を開きます。
- ロード バランサーの中には、キャッシングやコンテンツを意識したルーティングなどの機能を提供するものもあります。
ロード バランサーの使用例
ロード バランサーの仕組みがわかったので、ロード バランサーが役立つ状況を考えてみましょう。
複数のサーバーでサポートされるネットワーク サービスを作成する場合、必ずロード バランサーが必要になります。なぜならば、ロード バランサーはサーバーの使用率を最適化し、サーバーの 1 つで障害が発生したり、ローテーションから外れた場合の信頼性を高めるのに役立ちます。
API ゲートウェイとは
詳細については、API ゲートウェイに関する記事を参照してください。簡単に言うと、API は 2 つのコンピューティング リソースが互いに通信するためのインターフェイスであり、API ゲートウェイは API コンシューマーと API の間を仲介します。
API ゲートウェイを使用する理由
なぜ API コンシューマーと API の間に仲介者が必要なのでしょうか? ゲートウェイは、(ネットワークの場合と同様に) API が分散配置された場合に、API の安全性、観測性、信頼性を高める、便利な高レベルの機能を適用します。これらの機能の一部を以下に示します。
トラフィック制御
キャッシングとレート制限は、ゲートウェイが適用できる最も一般的な 2 つのトラフィック制御メカニズムです。
- キャッシングは、API コンシューマーにレスポンスの向上をもたらし、同時にバックエンド サーバーを過度の繰り返し負荷から保護します。
- レート制限は、コンシューマーが一定期間内に発行できるリクエストの総数を減らすことで、コンシューマーによる過剰使用や乱用を防ぎます。
このほかにも、リクエストの検証や変換などのトラフィック制御機能があります。
認証と認可
API ゲートウェイは、API コンシューマーの認証と認可を行うこともできます。
API が保護されており、API を消費する前にコンシューマーが本人確認として認証情報を提供しなければならない場合、認証と認可にはさまざまな API の実装が必要になりますが、ゲートウェイはこの負担を取り除き、代わりにこれを行うことができます。各 API が一貫してコンシューマーを識別し、アクセスを許可しているか確認できないため、これは重要です。
API ゲートウェイを使用すると、このプロセスが形式化され、すべての API に均一に適用されるため、リスクを軽減し、一貫性のあるセキュリティ体制を実現できます。
メトリックとログ
API は個別の機能単位であるため、製品として提供される場合があります。その場合、API 所有者は、誰が、どの程度、製品を使用しているか知りたいでしょう。API ゲートウェイは、API、API レイテンシ、エラー率に関するメトリックや、各リクエストに関する特定の情報を収集できます。
負荷分散
API はロード バランサーの作業の一部を行うことができますが、ロード バランサーを置き換えることはできません。API ゲートウェイは、さまざまなバックエンド サーバーにトラフィックを転送し、アクティブおよびパッシブな健全性チェックを行い、サーバーをローテーションから外すタイミングを決定します。次のセクションでは、これについてさらに詳しく説明し、API ゲートウェイをロード バランサーと組み合わせて使用する方法を示します。
API ゲートウェイの一般的な使用例
API ゲートウェイの最も一般的な使用例は、API コンシューマーとさまざまな API の間に間接的なレイヤーを提供することです。
次の図は、単一 API でのこの使用例を示しています。実際には、API ゲートウェイはトラフィックを数十または数百の API に転送できます。
API ゲートウェイとロード バランサーの併用
ゲートウェイとロード バランサーの基本を説明したので、両方を併用する方法を見てみましょう。ここでは、要件の増加に伴うアーキテクチャの進化を図で示します。
最初の図では、1 つの API があり、API にはコンシューマーがおり、API ゲートウェイやロード バランサーは使用していません。
API コンシューマーが増えて API サービスが過負荷になってきたので、この API サーバーのインスタンスをさらにいくつか立ち上げて、ロード バランサーを使って負荷を分散させます。
ロード バランサーの導入により、API エンドポイントに負荷を分散させるだけでなく、HTTPS オフロードも行えるようになりましたが、API コンシューマーは増え続けています。API サーバーをさらに増やすことは可能ですが、API を認識し、いくつかの要因によってキャッシュの精度が変化するキャッシングを行うとともに、各クライアントが一定期間にコールできる回数を制限します。そして、API の利用状況についてさらにいくつかのメトリックを収集します。API ゲートウェイを導入し、API と同様に高可用性を実現します。
この例では、必要なすべてのポリシーを適用するゲートウェイのペアを導入しました。これらのゲートウェイは事実上サービスであるため、ゲートウェイの前にロード バランサーを配置します。必要に応じてゲートウェイを追加したり、API クライアントのアクティビティを中断することなく、一度に 1 つずつ保守を行うことができます。また、ゲートウェイが負荷分散を行い、別のポリシー セットを適用する API エンドポイントの第二のセットも導入しました。当面はこのアーキテクチャで十分であり、ロード バランサーと API ゲートウェイの両方を活用します。
ロード バランサーと API ゲートウェイは、サービスの品質、セキュリティ、パフォーマンス、信頼性の向上をもたらします。これらはうまく連携し、補完的な目的で最適化されています。
Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。
参照記事: 2023 年 4 月 25 日
Ahmed Koshok
© Kong Inc. 2023
「API Gateway vs Load Balancer: Which is Right for Your Application?」
