API Gateway と Load Balancer

インターネット技術の発展に伴い、ネットワークデータへのリクエスト数が劇的に増加し、サーバーへの負荷が大きくなっています。初期のシステムアーキテクチャでは、通常、ロードバランサーを使用してネットワークトラフィックを複数のサーバーに分散させ、単一サーバーの負荷を軽減していました。

しかし、現在では、多くの異なる種類のバックエンドサービスが外部にAPIを公開しており、APIの数が増え続けています。その結果、主にロードバランサーに依存するシステムアーキテクチャの限界が明らかになりました。ロードバランサーは主にレイヤー4で動作し、レイヤー7での機能が限られているためです。これにより、主にレイヤー7で動作し、広範な拡張機能を提供するAPI Gatewayというインフラストラクチャが登場しました。

この記事では、ロードバランサーとAPIゲートウェイの特徴を紹介し、その違いを探ることで、読者がそれらの関係をよりよく理解できるようにします。

ロードバランサーとは何か？

ロードバランサーの主な役割は、複数のバックエンドサービスに対して負荷分散機能を提供し、異なる負荷分散アルゴリズムに基づいてトラフィックを分散させることです。ロードバランサーの歴史は長く、以下の段階に大別できます。

• 第一段階: この段階のロードバランサーは通常、ハードウェアデバイスで構成されており、高性能で高信頼性ですが、柔軟性が低く、コストが高いです。

• 第二段階: ロードバランサーはソフトウェアで実装されるようになり、より柔軟で拡張性が高く、ソフトウェア配布で登場するため、コストが低くなりました。LVS（Linux Virtual Server）はこのタイプの例です。

• 第三段階: クラウドコンピューティング技術の台頭に伴い、ロードバランサーもクラウド版を持つようになりました。このようなロードバランサーの大きな利点は、企業が低コストで高性能な負荷分散サービスを利用できることです。もう一つの利点は、クラウドコンピューティングの拡張性と弾力性を活用して、全体の可用性を向上させることができることです。クラウドロードバランサーの例として、AWSのClassic Load Balancer、Application Load Balancer、Network Load Balancerがあります。

トラフィックの分散とネットワークの拡張性の向上に加えて、ロードバランサーはネットワークセキュリティの強化にも使用できます。例えば、内部サーバーを公衆インターネットから隔離し、悪意のある攻撃や不正アクセスを防ぐことができます。簡単なユースケースとして、機密情報を含む内部サーバーをロードバランサーで内部ネットワーク内に隔離し、そのセキュリティを効果的に保護することができます。

APIゲートウェイとは何か？

短期的に見ると、APIゲートウェイはAPIトラフィックを管理および転送するインフラストラクチャであり、主にレイヤー7で動作します。ロードバランサーにはない強力な拡張性を提供し、認証、可観測性、カスタムプラグインなどを含みます。その主な特徴は以下の通りです。

• 豊富なルーティング戦略: APIゲートウェイはレイヤー7で動作するため、HTTP/HTTPSレイヤーのデータを解析できます。そのため、リクエストパス、ドメイン、ヘッダーなどの条件に基づいて、さまざまなアップストリームサーバーにリクエストを転送できます。

• 認証: APIゲートウェイは、APIレベルで複数の認証方法をサポートし、不正なリクエストを防ぎます。例えば、OAuth2やJWTなどです。認証はビジネスロジックから分離され、独立して非侵入的または最小限の侵入でビジネスコードに影響を与えません。

• レート制限: 異なるルーティングレベルで細かいレート制限を適用し、悪意のある攻撃を防ぎ、バックエンドサービスの過負荷を避けることができます。

• 可観測性: 可観測性とは、システムの外部から内部プログラムの実行状態やリソース使用率を観察する能力を指します。APIゲートウェイは、ログをKafka、Google Cloud Logging Service、Elasticsearchなどにリンクし、関連するメトリクスをprometheus、datadogなどにリンクすることをサポートします。

• 拡張性: APIゲートウェイ自体がゲートウェイであるため、異なる企業の異なるアプリケーションシナリオに適応できるように設計されています。例えば、異なる認証方式、カナリアリリース、セキュリティポリシー、ログ収集などです。さらに、APIゲートウェイはユーザーが拡張機能を選択したり、カスタム開発を行ったりできるようにする必要があります。そのため、拡張性が強く、利用可能な拡張機能の選択肢も多岐にわたります。例えば、Apache APISIXには13種類の異なる認証拡張機能があり、市場で一般的な認証要件のほとんどをカバーしています。

現在、市場には多くの異なるAPIゲートウェイが存在します。例えば、Apache APISIX、Kong、Tyk、Zuulなどです。開発者は、特定の要件に応じて最も適切なAPIゲートウェイを選択できます。

APIゲートウェイとロードバランサーの主な違い

異なる焦点領域

APIゲートウェイとロードバランサーはどちらもレイヤー4とレイヤー7のプロキシをサポートしていますが、APIゲートウェイは主にレイヤー7に焦点を当て、ロードバランサーは主にレイヤー4に焦点を当てています。

そのため、レイヤー4で動作するロードバランサーには多くの利点があります。まず、APIゲートウェイと比較してプロトコル解析のオーバーヘッドが少なく、スループット能力が高いです。次に、クライアントのIPアドレスを透過的に転送するのに対し、APIゲートウェイは通常、HTTPヘッダーを通じてクライアントのIPアドレスを渡します。

機能の豊富さ

例えば、ロードバランサーはHTTPレイヤー7の処理能力が弱く、認証、認可、複雑なルーティングロジック、ログ収集などの機能を欠いていることが多いです。一方、APIゲートウェイはレイヤー7プロトコルの処理能力が強く、アクセス制御、ロギング、API管理、サーバーレスコンピューティングなどのさまざまな機能拡張を追加できます。

カスタム開発

今日の急速に進化する技術市場では、多くの企業がカスタム開発をサポートする能力を必要としています。APIゲートウェイは、異なるプログラミング言語のサポートや、トラフィック転送の異なる段階でカスタム処理ロジックを注入する能力など、さまざまなカスタム開発オプションを提供します。一方、ロードバランサーはカスタム開発オプションを提供しません。

トラフィック分散方法

ロードバランサーは通常、直接的なトラフィック分散を使用して負荷分散を実現します。アルゴリズムを通じて、トラフィックデータは特定のバックエンドサーバーノードに直接送信されます。つまり、トラフィックを受信する各サービスインスタンスは一貫した動作をする必要があり、ある程度の柔軟性が低下します。一方、APIゲートウェイはURL Path、Domain、Headerなどの異なる次元に基づいてトラフィックを分散します。その結果、トラフィックを受信するサービスインスタンスは異なる場合があります。例えば、プライベートAPIやGRPC APIなどで、トラフィック分散の柔軟性が非常に高くなります。

ユースケース

マイクロサービスのユースケース

マイクロサービスアーキテクチャのシステムにとって、APIゲートウェイは不可欠です。まず、さまざまなバックエンドサービスを簡単に管理およびルーティングできます。次に、APIゲートウェイは認証、認可、レート制限、転送、ロギングなどの多くの高度な機能を提供できます。そのため、異なるマイクロサービスがレート制限や認証などの機能を繰り返し実装する必要がなくなり、各マイクロサービスの機能実装がより集中し、開発コストが削減されます。

マイクロサービスアーキテクチャには多くのサービスが含まれるため、レイヤー4ロードバランサーは複数のバックエンドサービスの負荷分散には適していません。代わりに、単一のバックエンドサービスとの使用に適しています。一方、レイヤー7ロードバランサーは通常、高度な機能を提供できないため、マイクロサービスにおけるAPIゲートウェイに対する利点はあまりありません。

APIの管理とデプロイ

APIゲートウェイは、大量のAPIを管理およびデプロイする必要があるシナリオにも非常に適しています。なぜなら、強力なAPI管理機能を備えているからです。この場合、特定のAPIを簡単に有効化または無効化し、APIの転送設定を迅速に変更し、レート制限、認証、ロギングなどの機能をAPIに追加することができます。APIゲートウェイを再起動する必要はありません。

Apache APISIXを例にとると、Apache財団のトップレベルオープンソースプロジェクトであり、現在最も活発なオープンソースゲートウェイプロジェクトです。動的、リアルタイム、高性能なオープンソースAPIゲートウェイとして、Apache APISIXは負荷分散、動的アップストリーム、カナリアリリース、サーキットブレーカー、認証、可観測性などのさまざまなトラフィック管理機能を提供します。

一方、従来のロードバランサーはAPI管理に関して比較的弱く、このような豊富な高度な機能を必要としません。

高性能ネットワークアクセス

高トラフィックと極めて高い安定性を必要とするネットワークアクセスのシナリオでは、レイヤー4ロードバランサーが明らかに適しています。ネットワークの元のレイヤー4トラフィックを各バックエンドサービスに直接分散させることができ、中間層でのアプリケーションレイヤープロトコルの複数回の解析の影響を受けないため、より高いスループットを処理する能力があります。

一方、レイヤー7で動作するAPIゲートウェイは、統一されたエントリーポイントとして、プロトコルを解析する必要があるため、一定のスループット制限があります。レイヤー4のAPIゲートウェイを使用してネットワークアクセスを行うことは特に有利ではありません。なぜなら、このレイヤーはAPIゲートウェイの焦点ではないからです。このレイヤーでのロードバランサーの長年の技術的蓄積と比較すると、APIゲートウェイの利点ははるかに少ないです。

まとめ

一般的に、APIゲートウェイとロードバランサーは異なる問題を解決するために使用されるインフラストラクチャソリューションです。APIゲートウェイは主にバックエンドAPIインターフェースのプロキシとして使用され、異なるタイプのAPIにアクセスするための単一のエントリーポイントを提供し、レート制限、認証、監視などの独立した機能を提供します。一方、ロードバランサーは主にレイヤー4トラフィックの分散に使用され、複数のバックエンドサーバーにリクエストを分散させてリクエスト負荷を均等化し、システム全体の可用性とフォールトトレランスを向上させます。

合理的なアーキテクチャ設計の下では、APIゲートウェイとロードバランサーは通常一緒に使用されます。ロードバランサーはシステム全体のネットワークアクセスであり、トラフィックを複数のAPIゲートウェイインスタンスに分散させます。各APIゲートウェイインスタンスは、リクエストを個別にルーティング、認証、認可し、ネットワーク全体をより堅牢で信頼性が高く、拡張性のあるものにします。