TechTargetは「APIゲートウェイを使わないマイクロサービスの管理方法」に関する記事を公開した。マイクロサービスの管理はAPIゲートウェイを使うのが一般的だ。もしそれを使わない場合、どのようなメリットとデメリットがあるのか。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
TechTargetは2024年6月17日(米国時間)、「APIゲートウェイを使わないマイクロサービスの管理方法」に関する記事を公開した。
APIゲートウェイとマイクロサービスは密接に関係し合っている。開発者は通常、アクティビティーを規制するためにAPIゲートウェイを利用する。だが、APIゲートウェイを使わなくてもマイクロサービスは管理できる。場合によっては、APIゲートウェイを使わない方がよいこともある。
企業では、マイクロサービスとAPIゲートウェイはよく併用されている。では、APIゲートウェイを使わないマイクロサービス管理が適しているのはどのような場合か。
マイクロサービスとはアプリケーションアーキテクチャの一種で、アプリケーションの機能を幾つもの個別のサービス(マイクロサービス)に分割するという特徴がある。マイクロサービスアーキテクチャでは、アプリケーションを1つのマイクロサービスだけで実行するのではなく、各マイクロサービスが異なる種類のタスクを処理する。これによってモジュール化された柔軟性の高いアプローチが可能になる。
APIゲートウェイは、アプリケーションの各マイクロサービスとクライアント間の仲介役として機能し、通信を容易にして効率を高めるツールだ。APIゲートウェイは、複数のマイクロサービスインスタンス間でのリクエストのバランス調整や悪意のあるリクエストのブロックなど、パフォーマンス管理とセキュリティの重要なプロセスにも役立つ。
APIゲートウェイを使うと、クライアントとアプリケーションのやりとりがシンプルになる。例えば、マイクロサービスアーキテクチャを採用しているオンラインショッピングのアプリケーションには、製品在庫を表示するマイクロサービス、顧客が商品をショッピングカートに入れるためのマイクロサービス、商品を購入する(決済する)マイクロサービスが含まれる。
クライアントは、ショッピングカートに商品を追加する際に、「ショッピングカートのマイクロサービス」に直接接続する必要はない。その代わり、APIゲートウェイに決済を希望することを示すリクエストを送信する。APIゲートウェイはそのリクエストを解釈し、その機能を実行できるマイクロサービスにリクエストをルーティングする。
APIゲートウェイが仲介役として機能するため、アプリケーション内でリクエストを直接解釈して該当するマイクロサービスにルーティングしなくてもよくなる。APIゲートウェイがリクエストを受け取り、該当するマイクロサービスに転送して、結果をクライアントに送り返すことでリクエスト交換を完了する。
APIゲートウェイは、リクエストの整理とセキュリティ確保に役立つ。主に、次の2つの重要な観点でメリットがある。
開発者は、リクエストを受信してルーティングするロジックをマイクロサービスのアプリケーションに実装しなくてもよくなる。マイクロサービスの種類によっては、全く実装する必要がない場合もある。例えば、クライアントのIDをAPIゲートウェイ内で検証できるのであれば、アプリケーション内でIDを検証するマイクロサービスを作成する必要はない。
APIゲートウェイは、特にクライアント向けマイクロサービスを複数利用するアプリケーションの場合、APIリクエストをシンプルにすることでクライアントにメリットをもたらす。APIゲートウェイは、マイクロサービスごとに個別のAPIリクエストをクライアントに発行させる代わりに、統合APIを公開する。このアプローチでは、クライアントは、作成したリクエストをどのように実行するかの判断をAPIゲートウェイに任せることができる。つまりクライアントは、アプリケーションの内部アーキテクチャを理解する必要がないということだ。
APIゲートウェイは、チームがマイクロサービスアプリケーションを効果的に管理できるように、負荷分散、可観測性、レート制限などの追加機能を提供する。こうした機能は、APIゲートウェイ以外のツールを使っても実装できるが、APIゲートウェイを通じて多様なニーズに対応できることから、マイクロサービスアーキテクチャ内での汎用(はんよう)性の高い管理オプションだと言える。
APIゲートウェイを使うと、マイクロサービスアプリケーションがクライアントと簡単に接続できるようになるが、アーキテクチャと運用の複雑さが増すことでパフォーマンスが低下する可能性がある。次のようなAPIゲートウェイの欠点を考慮することが重要だ。
APIゲートウェイによって、アプリケーションをホストするスタックに新たな層が追加される。そのため、アプリケーションの実行に必要なインフラリソースの量が増えることになる
APIゲートウェイは構成と管理が必要な別のツールであることから、ホスティングスタックが複雑になる
リクエストをAPIゲートウェイ経由で渡す必要があることから、特にAPIゲートウェイの構成が不十分な場合やリクエストを効率的にルーティングできるリソースが不足している場合は、待ち時間が増える可能性がある
APIゲートウェイはマイクロサービスとクライアント間のやりとりのためのハブとして機能することから、APIゲートウェイで問題が起きると、アプリケーションにアクセスできなくなる可能性がある
今日のマイクロサービスアプリケーションの大半がAPIゲートウェイを使っていると言っても過言ではない。だが、APIゲートウェイに伴う潜在的なメリットがデメリットを上回るかどうかは、それぞれの開発チームがケース・バイ・ケースで判断する必要がある。
少数のマイクロサービスで構成されるアプリケーションや、限られた範囲のAPIリクエストのみを処理する必要があるアプリケーションでAPIゲートウェイを使うのはやり過ぎかもしれない。また、CPUリソースやメモリリソースが限られるエッジIoT(Internet of Things)デバイスで実行されるマイクロサービスなど、特殊なタイプのアプリケーションには、APIゲートウェイが適さない可能性がある。ただし、APIゲートウェイのオーバーヘッドは、ゲートウェイの機能とデプロイメント方法によって大きく異なる。例えば、コンテナ化されたAPIゲートウェイは非常に軽量だ。
アプリケーションがクライアントにサービスを提供しないのであれば、APIゲートウェイは必要ない。だが、今日のAPIファーストの世界ではモダンアプリケーションがクライアントにサービスを提供しないことはめったにないだろう。
アプリケーションのマイクロサービスにAPIゲートウェイのオーバーヘッドと複雑さを受け入れる余地がないシナリオでは、APIゲートウェイが提供するのと同じパフォーマンス管理とセキュリティ機能の一部を提供できる代替アプローチが2つある。
1つは、クライアントとマイクロサービスの間に仲介役を置かずにアプリケーションを実行するというアプローチだ。この場合、アプリケーションの各マイクロサービスが独自にAPIリクエストを受け取り、ルーティングし、処理できる必要がある。そのため、マイクロサービス内に実装するロジックが増える。場合によっては、通常なら必要のないマイクロサービスを追加で開発する必要があるかもしれない。
もう1つは、APIゲートウェイの直接代わりにならないとしても、同等の機能の一部を提供する次のようなツールを利用するアプローチだ。
トラフィックのルーティングを支援するために、クライアントとアプリケーションの間にロードバランサーを配置する。ロードバランサーにはAPIリクエストを解釈して管理する機能はないため、APIの管理はできないが、分散アプリケーション全体にトラフィックを最適に分散するのに役立つ。
ネットワークスイッチやファイアウォールを介してレート制限を実装できる可能性がある。ただし、その場合は、特定種類のAPIリクエストを絞り込むのではなく、リクエストのレートをプロトコルレベルで管理する必要がある。
APIプロキシは、個別のAPIにリクエストを転送することで、バックエンドサービスにクライアントからリクエストが直接転送されるのを防ぐことができる。だが、APIゲートウェイの完全な代替手段とはならない。
サービスメッシュは、アプリケーション内のマイクロサービス間のAPIベースの通信を管理できる。APIゲートウェイとの違いは、APIゲートウェイは主に外部クライアントのリクエストを管理するのに対し、サービスメッシュは内部トラフィックを扱うということだ。
Copyright © ITmedia, Inc. All Rights Reserved.