API Gateway

単一のモノリシック アプリケーションからマイクロサービス アーキテクチャに移行すると、多くの問題が解決されます。これにより、チームが独立して作業し、サービスを個別に展開し、必要に応じてシステムの一部を拡張することができます。ただし、クライアントはこれらすべての独立したサービスとどのように対話するのかという新たな課題も生じます。 10、50、または数百の小さなマイクロサービスがある場合、モバイル アプリまたは Web ページはそれぞれのマイクロサービスに直接接続する必要があるでしょうか? ここで、API ゲートウェイ パターン が登場します。このガイドでは、API ゲートウェイとは何なのか、なぜそれが必要なのか、そして API ゲートウェイがどのようにマイクロサービス システムを簡素化するのかについて、簡単な言葉と現実世界の例えを使用して詳しく説明します。 現実世界の例え: ホテルの受付係 あなたが大規模な高級リゾートホテルにチェックインしていると想像してください。リゾートにはさまざまな部門があります。 ハウスキーピング（クリーンシートの場合） ※ルームサービス（お食事） ※コンシェルジュ（ツアー予約担当） Billing (請求書を支払うため) 清潔なタオルが必要な場合は、リゾート内を歩いて清掃棟を探す必要はありません。夕食が食べたければ、キッチンのドアをノックする必要はありません。代わりに、フロントデスクの受付に電話してください。 受付担当者がお客様のご要望を伺い、どの部門が解決できるかを判断し、おつなぎするか、対応させていただきます。 このシナリオでは: あなたはクライアント (モバイル アプリまたはブラウザ) です。 受付は API ゲートウェイです。 部門 (ハウスキーピング、ルームサービス、請求) は マイクロサービス です。 問題: クライアントからサービスへの直接通信 ゲートウェイがどのように機能するかを説明する前に、ゲートウェイを「使用しない」場合に何が起こるかを見てみましょう。 e コマース アプリケーションに 3 つの個別のマイクロサービスがあるとします。 ユーザー サービス (プロファイルを管理) 製品サービス (カタログの管理) 注文サービス (チェックアウトの管理) API ゲートウェイがない場合、クライアント アプリは個別のリクエストを各サービスの個別のアドレス (IP または URL) に直接送信する必要があります。

Web 開発の初期の頃、ソフトウェア アプリケーションの構築は簡単でした。コードを記述し、それを単一の実行可能ファイルまたは展開可能なアーカイブにパッケージ化し、サーバー上で実行するだけでした。 モノリシック アーキテクチャとして知られるこのアプローチは、何十年にもわたって業界に役に立ちました。 しかし、アプリケーションが数百人の開発者と数百万人の同時ユーザーを抱える大規模なエンタープライズ プラットフォームに成長するにつれて、モノリスには限界が見え始めました。デプロイメントは遅くなり、リスクが高く、データベースがボトルネックになり、コードベースが複雑すぎて単一の開発者が理解できないようになりました。 これらのスケーリングのボトルネックを解決するために、業界は マイクロサービス アーキテクチャ に移行しました。開発者は、単一の巨大なアプリケーションを構築するのではなく、HTTP/REST、gRPC、メッセージ ブローカーなどの軽量プロトコルを介して通信する、小規模で独立した疎結合サービスのコレクションにシステムを分割します。 この記事では、マイクロサービスが最新のアプリケーションにもたらす主な利点、マイクロサービスによってもたらされる深刻な課題、そしてこのアーキテクチャが次のプロジェクトに適しているかどうかを判断する方法を分析します。 1. モノリシック アーキテクチャとマイクロサービス アーキテクチャ 詳細に入る前に、これら 2 つの設計パラダイムの基本的な違いを視覚化しましょう。 モノリスでは、すべてのモジュール (ユーザー管理、製品カタログ、注文処理など) が同じ実行スペースを共有し、単一の共有データベースに書き込みます。 マイクロサービス セットアップでは、各サービスが独自のプロセスで実行され、独自のプライベート データベースを管理し、クリーンな API を公開します。 API ゲートウェイ はクライアントの単一のエントリ ポイントとして機能し、リクエストを適切なバックエンド サービスにルーティングします。 2. マイクロサービスの利点 マイクロサービス アーキテクチャを採用すると、大規模な最新のシステムに推奨される選択肢となる、いくつかの魅力的な利点が得られます。 A. 独立した展開可能性とリリース速度 モノリスでは、チェックアウト システムに小さな変更をデプロイするには、アプリケーション全体を再構築して再デプロイする必要があります。 1 つのチームの機能が壊れると、リリース全体がブロックされます。 マイクロサービスでは、各サービスに独自の独立した CI/CD パイプラインがあります。配送サービス チームは、在庫チームや支払いチームと調整することなく、1 日に 10 回アップデートを展開できるため、機能の配信速度が大幅に向上します。