マイクロサービスはなぜAPIゲートウェイを必要とするのか

マイクロサービスとは何か

マイクロサービスアーキテクチャ（通常、マイクロサービスと呼ばれる）は、アプリケーションを開発するために使用されるアーキテクチャの一種です。マイクロサービスを使用すると、大規模なアプリケーションを複数の独立したコンポーネントに分割できます。各コンポーネントには独自の責任があります。ユーザーリクエストを処理する際、マイクロサービスベースのアプリケーションは、その応答を共同で生成するために多くの内部マイクロサービスを呼び出すことがあります。マイクロサービスはインターネットの発展の結果であり、インターネットの急速な成長により、システムのアーキテクチャは常に変化しています。

全体として、システムのアーキテクチャは、モノリシックアーキテクチャからSOAアーキテクチャ、そしてマイクロサービスアーキテクチャへと進化してきました。各アーキテクチャの具体的な進化と利点・欠点を以下の表に示します。

アーキテクチャタイプ	説明	利点	欠点
モノリシックアプリケーションアーキテクチャ	すべての機能コードを単一のサービスにパッケージ化します。	1. シンプルなアーキテクチャで、プロジェクトの開発と保守コストが低い。	すべてのモジュールを結合することは、小規模なプロジェクトの開発と保守には有益ですが、大規模なプロジェクトでは問題を引き起こす可能性があります。例えば、 1. プロジェクト内のモジュールが密結合すぎて、1つのモジュールのパフォーマンス問題がプロジェクト全体の停止を引き起こす可能性がある。 2. プロジェクトの拡張性が低い。
SOAアーキテクチャ	「サービス指向アーキテクチャ」という用語で、通常は複数のサービスを含みます。 サービスは通常、オペレーティングシステムのプロセス内で独立して存在し、サービス間の通信は依存関係または通信メカニズムを通じて行われます。 最終的には、一連の機能を提供します。	1. システム統合：システム全体の観点から、企業システム間の通信問題を解決し、以前は無秩序で構造化されていないネットワーク接続を管理された構造化されたスター構成に変換します。 2. サービス指向システム：機能の観点から、ビジネスロジックを再利用可能で組み合わせ可能なサービスに抽象化し、サービスオーケストレーションを使用してビジネスプロセスの迅速な再構築を実現します。 3. ビジネスサービス指向：企業の観点から、企業の機能を再利用可能で組み合わせ可能なサービスに抽象化します。	1. サービスを集中化すると、サービス間の依存関係が生まれ、1つのサービスの障害が他のサービスに連鎖的に影響を与える可能性があります。 2. サービス間の依存関係と呼び出し関係が複雑で、テストとデプロイが困難です。
マイクロサービスアーキテクチャ	マイクロサービスはSOAの進化形です。マイクロサービスアーキテクチャの重要なポイントの1つは、「ビジネスを徹底的にコンポーネント化し、サービス化する必要がある」ということです。 元の単一のビジネスシステムは、独立して開発、設計、デプロイできる複数の部分に分割されます。 これらの部分は、小さな独立したアプリケーションとして実行されます。各アプリケーションは他のアプリケーションと協力し、通信して統合と相互作用を実現します。これがマイクロサービスアーキテクチャの本質です。	1. 分散化; 2. サービスによるコンポーネント化; 3. ビジネス能力に基づいてサービスと開発チームを分割; 4. インフラストラクチャの自動化（DevOps、自動デプロイ）。	1. 開発コストが比較的高い; 2. サービスのフォールトトレランスの問題を引き起こす; 3. データの一貫性の問題を引き起こす; 4. 分散トランザクションが関与する。

したがって、マイクロサービスはインターネット発展の必然的な結果であり、多くの伝統的な企業のシステムアーキテクチャも徐々にマイクロサービス指向になっています。

しかし、インターネットビジネスの発展に伴い、APIの数も劇的に増加しており、統一されたAPI管理のためのゲートウェイも課題に直面しています。より堅牢なAPIゲートウェイを選択することで、システムの監視、災害復旧、認証、レート制限の能力を効果的に強化できます。

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

APIゲートウェイは、クライアントとサービスシステム間の相互作用のための統一されたインターフェースを提供し、リクエストとレスポンスを管理する中心点として機能します。適切なAPIゲートウェイを選択することで、開発を簡素化し、システムの運用と管理効率を向上させることができます。

マイクロサービスアーキテクチャでは、APIゲートウェイはシステム設計のソリューションとして、さまざまなモジュールのマイクロサービスを統合し、サービスを統一して調整します。

システムのアクセス側面として、APIゲートウェイはクライアントに統一されたエントリーポイントを提供し、システムアーキテクチャの実装詳細を隠し、マイクロサービスをより使いやすくします。また、認証、レート制限、サーキットブレーカーなどの一般的な機能を統合し、各マイクロサービスの個別開発を避け、効率を向上させ、システムを標準化します。例えば、認証、監視、負荷分散、レート制限、劣化、アプリケーション検出などです。

なぜマイクロサービスにAPIゲートウェイが必要なのか？

上記の図に示すように、APIゲートウェイはクライアントとマイクロサービスの間の中間層として機能します。外部に対して統一されたアドレスでマイクロサービスを提供し、適切なルールに基づいて内部クラスター内の正しいサービスノードにトラフィックをルーティングできます。

APIゲートウェイがない場合、トラフィックの出入り口が統一されておらず、クライアントはすべてのサービスのアクセス情報を知る必要があります。マイクロサービスの意義は存在しません。したがって、マイクロサービスアーキテクチャにはマイクロサービスゲートウェイが必要です。さらに、APIゲートウェイはシステムの可観測性、認証、安定性、サービスディスカバリーにおいて重要な役割を果たします。

マイクロサービスが直面する課題

マイクロサービスゲートウェイは、まずAPIルーティング機能を持っている必要があります。マイクロサービスの数が増えると、APIの数も増えます。ゲートウェイは特定のシナリオでトラフィックフィルターとしても使用でき、特定のオプション機能を提供します。したがって、マイクロサービスAPIゲートウェイにはより高い要求が課せられます。例えば：

• 可観測性：過去、モノリシックアプリケーションでのトラブルシューティングは、ログをチェックしてエラーメッセージや例外スタックを確認することで行われていました。しかし、多くのサービスを持つマイクロサービスアーキテクチャでは、問題の診断が非常に困難になります。したがって、マイクロサービスの動作を監視し、異常が発生した場合に迅速にアラートを出す方法は、開発者にとって大きな課題です。
• 認証と認可：マイクロサービスアーキテクチャでは、アプリケーションはいくつかのマイクロアプリケーションに分割され、アクセスを認証し、現在のユーザーとその権限を認識する必要があります。モノリシックアプリケーションアーキテクチャの認証方法は、特にブラウザ以外のサービス呼び出しからのアクセスがある場合には適していません。マイクロサービスアーキテクチャでは、外部アプリケーションアクセス、ユーザーとサービスの認証、サービス間の認証など、さまざまな認証シナリオを考慮する必要があります。
• システムの安定性：リクエストの数がマイクロサービスの処理能力を超えると、サービスが圧倒され、システム全体の安定性に影響を与える連鎖反応を引き起こす可能性があります。
• サービスディスカバリー：マイクロサービスの分散管理は、負荷分散の実装にも課題をもたらします。

解決策

APIゲートウェイは、クライアントとサーバーの間の中間橋渡しとして、マイクロサービスシステムに統一された管理メカニズムを提供します。リクエストの配布、API管理、条件付きルーティングなどの基本的な機能に加えて、認証、監視とアラート、トレース分析、負荷分散、レート制限、隔離、サーキットブレーカーなども含まれます。

認証：以下の図は、マイクロサービスがAPIゲートウェイと連携して認証を行う方法を示しています。すべてのリクエストはゲートウェイを通過し、マイクロサービスを効果的に隠します。

監視とアラート/トレース分析：

クライアントとサーバーの間の中間層として、APIゲートウェイはマイクロサービスの監視に最適なキャリアです。

APIゲートウェイの監視機能の主な責任は、ゲートウェイとバックエンドサーバー間の接続異常をタイムリーに検出することです。ユーザーは監視プラットフォームでAPIのログ情報、監視情報、トレースなどを確認できます。さらに、ホストで発生した異常は自動的にコントロールパネルに報告されます。特定のゲートウェイはクライアントとサーバーの両方に二重アラートを発行できます。

レート制限、隔離、サーキットブレーカー：

インターネットビジネスの規模が拡大するにつれて、システムの同時実行性も増加します。複数のサービスが互いに呼び出されることが多く、コアリンクは最大10のサービスを呼び出すことがあります。あるサービスのRT（応答時間）が急激に上昇し、上流サービスがリクエストを続けると、悪循環が発生します。上流で結果を待つほど、上流サービスがブロックされ、最終的にはプロセス全体が使用不能になり、サービスアバランシェが発生します。

したがって、流入トラフィックを規制および管理する必要があります。以下の図は、マイクロサービスシステムがAPIゲートウェイと連携してレート制限、隔離、サーキットブレーカーを実行する方法を示しています。

主流ゲートウェイの選択

マイクロサービスでは、NGINX、Kong、Apache APISIX、Envoyなど、多くのオープンソースゲートウェイ実装が利用可能です。Java技術スタックの場合、Netflix Zuul、Spring Cloud Gateway、Soulなどのオプションがあります。しかし、「なぜNGINXやKongではなくApache APISIXを選ぶのか？」と疑問に思うかもしれません。

以下に簡単な比較を示します。

ゲートウェイ	課題	利点
NGINX	1. 設定の変更を反映するにはリロードが必要で、クラウドネイティブ技術の進歩に追いつけない。	1. 従来のアプリケーション; 2. 安定性と信頼性が高く、時間の検証に耐える; 3. 高性能
Apache APISIX	1. ドキュメントが十分に豊富で明確ではなく、改善が必要。	1. Apache Foundationのトップレベルプロジェクト; 2. 技術アーキテクチャがクラウドネイティブの原則により適合; 3. 優れたパフォーマンス; 4. 豊富なエコシステム; 5. Lua開発プラグインに加えて、Java、Go、Python、Nodeなどの言語プラグインもサポート。
Kong	1. デフォルトでPostgreSQLまたはCassandraデータベースを使用するため、アーキテクチャ全体が非常に肥大化し、高可用性の問題を引き起こす可能性がある; 2. ルーティングにトラバーサル検索アルゴリズムを使用するため、ゲートウェイに数千以上のルートがある場合、パフォーマンスが大幅に低下する可能性がある; 3. 一部の重要な機能は有料;	1. オープンソースAPIゲートウェイの先駆者で、ユーザーベースが大きい; 2. パフォーマンスはほとんどのユーザーのニーズを満たす; 3. 豊富なエコシステム; 4. LuaとGoプラグイン開発をサポート;
Envoy	1. C++で開発されているため、二次開発が難しい; 2. C++でフィルターを開発するだけでなく、WASMとLuaもサポート。	1. CNCFの卒業プロジェクトで、サービスメッシュシナリオに適しており、多言語アーキテクチャのデプロイをサポート;
Spring Cloud Gateway	1. Springコミュニティは成熟しているが、Gatewayのリソースが不足している。	1. ゲートウェイは豊富な機能を提供し、SpringBootの設定または手動コーディングで使用可能; 2. Springフレームワークは拡張性が高く、設定が容易で、保守性が良い; 3. Springコミュニティは成熟している; 4. 使いやすい; 5. Java技術スタックに便利。

まとめ

インターネットの世界が発展し続ける中、企業は急速に進化し、システムアーキテクチャは常に変化しています。マイクロサービスアーキテクチャは多くの企業に広く採用されています。

マイクロサービスのデータとAPIの量が増加するにつれて、高トラフィックの管理のために優れたAPIゲートウェイを選択することが重要です。

この記事では、一般的なAPIゲートウェイを比較し、それぞれの利点と欠点を強調しました。もしAPIゲートウェイ技術の選択プロセス中で、マイクロサービスシステムのパフォーマンス問題に直面しているか、効率的で安定したマイクロサービスシステムを構築しようとしている場合、この記事が役立つ洞察を提供することを目指しています。