前回のブログでは、モノリシックなアプリケーションの接続に好まれるコネクティビティ ソリューションである、エンタープライズ サービス バス (ESB) について説明しました。
今回のブログでは、今日最新の分散型世界における API ゲートウェイの役割について説明します。また、ESB と API ゲートウェイを比較し、これらのコネクティビティ ソリューションがどのように共存し、レガシー アプリケーションとモダン アプリケーションの両方をサポートできるかについて考察します。
API ゲートウェイ
API ゲートウェイは、クライアントとサービスの間にあるモダン インフラのコンポーネントであり、クライアントにとって単一のエントリ ポイントとして機能します。ESB と同様に、API ゲートウェイは異種のサービスを接続し、統合します。しかし、API の台頭により、連携面におけるタスクがより重視されています。
図: API ゲートウェイ
API ファーストの設計と API マネジメント
ESB とはもともと、かつての標準化問題に対する技術的なソリューションでした。その問題は、API におけるプロトコルの標準化によって解決されました。現在、スペックファーストの API 開発は開発チームを切り離し、ビジネスと顧客の成果を優先することで、ビジネス要件に焦点をあてています。API ファーストの設計により、ビジネス主導の「製品」に対してより良い再利用性と関連性をもたらします。
マイクロサービス型のアーキテクチャにより、管理対象のサービス数が急増しました。API マネジメントは、設計、ドキュメンテーション、デプロイ、ディスカバリ、そしていわゆる “Day 2” 段階での懸念事項など、API ライフサイクル全体を考慮することで、この管理タスクを簡素化します。その中心となるのがコネクティビティの問題で、API ゲートウェイはこれに対応しています。ここでその方法について考えてみましょう。
API ゲートウェイのメリット
API ゲートウェイは、すべての API に共通する機能を一元化することでオーバーヘッドを削減し、より無駄のないマイクロサービスを実現します。認証、ロギング、モニタリングといった横断的な関心事をいったん実装してしまえば、ゲートウェイ レベルで処理することができます。
また、API ゲートウェイは、サービスの実装の詳細からクライアントを切り離し、複数のマイクロサービスを単一のクライアント API に統合できます。
API ゲートウェイと連携する開発者ポータルでは、API ディスカバリ、ドキュメンテーション、また利用が容易であることを保証し、API の実装や再利用を促進します。
API ゲートウェイは、特定の API コールに必要なラウンドトリップ数を減らすことにより、パフォーマンスを向上できます。オーケストレーションにより、バックエンドでの複数の API コールを、クライアントから API ゲートウェイへの 1 往復に集約することができます。また、API ゲートウェイは、キャッシュ戦略を活用し、サービスの負荷を軽減することもできます。
さらに、API ゲートウェイは、クライアントと API ゲートウェイ間のリクエストに関連するロギング、モニタリング、およびアナリティクス データの提供基盤としても役立ちます。
最後に、API ゲートウェイ レベルでプラグインやポリシーを適用することで、すべてのサービスに一貫したベスト プラクティスを適用できます。これには、セキュリティ、トラフィック制御、リクエストとレスポンスの変換、ロギングなどの領域が含まれます。
API ゲートウェイと ESB の比較
API ゲートウェイと ESB の類似点は明らかです。いずれのソリューションも、サービスと通信するための一元的な仲介役として機能します。ただし、API ゲートウェイは、さらなる利点を備えた最新のアプローチを提供しています。
ESB は非常に複雑なシステムへと発展する可能性があります。一方、API ゲートウェイは明確なスコープを持ち、特に横断的な関心事とクライアント、サービス間の通信にフォーカスしています。そのため、API ゲートウェイには無駄がなく、より専門性を保つことができます。
ESB とは対照的に、API ゲートウェイは分散化を実現します。この点では、クラウドに移行中の企業とハイブリッドなアプローチを取ろうとしている企業の両方で役立ちます。
ESB は、チーム間の結合を強め独立性を低下させる、大規模で中枢性のモノリスです。一方、API ゲートウェイは、チームのスリム化と専門性の向上を可能にし、各チームがそれぞれのタスクに集中できるようにします。
API ゲートウェイと開発者用ポータルは、デザインファーストの API アプローチをも促進し、ディスカバリ主導の消費マインドを促します。各クライアントに適切な API を提供することで、API ゲートウェイはその実装と再利用率を増進します。
適切な API ゲートウェイの選択
API ゲートウェイの選択においては、いくつかの基準を検討する必要があります。
デプロイの複雑度
まず、ゲートウェイの技術的要件を検討します。最低限実行可能なインストールを行うには、いくつのピースをセットアップする必要があるのでしょうか？初期導入の複雑さは、その後のメンテナンス要件にも影響する可能性があります。
専用製品 vs. オープン ソース
プラットフォームの拡張性や長期サポートの可能性について検討しましょう。API ゲートウェイを既存環境に導入することは、多くのチームに影響を及ぼす重要なアーキテクチャレベルの変更を余儀なくします。サード パーティ製品の終息によって削除せざるを得なくなるようなことは回避したいところです。
スケーリングの容易性
API ゲートウェイは、クライアントとサービス間のインタラクションのたびに、クリティカル パスに踏み込みます。将来的な成長の計画と、API ゲートウェイが水平方向にも垂直方向にもスケール可能かどうかを検討しましょう。スケール管理は、Kubernetes のようなオーケストレーターによる宣言型のアプローチによって実現するのがベストであるといえます。
機能セット
API ゲートウェイは、API のライフサイクル全体をサポートする必要があります。また、組織は API ゲートウェイの役割を慎重に検討し、機能セットの規模に関わらず、その役割を具体的に果たす製品を探す必要があります。
モダン エンタープライズにおける ESB ＋ API ゲートウェイの威力
現在 ESB を使用していて、アーキテクチャに API ゲートウェイの導入を検討している企業は、次にどのようなステップを踏めばよいのでしょうか。
IT 組織がアジリティと迅速なイノベーションを目指す場合、独立性が高く、無駄がなく、フォーカスしたチーム カルチャーを構築する必要があり、またそのためには多様な技術ソリューションとアプローチを受け入れる必要があります。この異種混交性については、次のような例が挙げられます。
- オンプレミスまたはクラウドオンリー➡ ハイブリッドクラウド/マルチクラウド環境
- 集中型 ➡ 分散型
- モノリス型アーキテクチャ ➡ マイクロサービス
- サーバー ➡ サーバーレス関数、Kubernetes、コンテナー
- 組織共通言語 ➡ 多言語のチームおよび組織
統合プラットフォームについては、API に焦点を当てるべきです。API コネクティビティは新しい競争の場であり、API ゲートウェイはこの目的に特化したソリューションです。
徐々にハイブリッドなアプローチを取る方法が出発点としては適しているかもしれません。新しい API に API ゲートウェイを実装し、機会や時間が許す限りより多くのサービスを取り込むことにより、モノリスである ESB を徐々に分解していきます。ESB からビジネス ロジックを 1 つずつ抽出し、新しいマイクロサービスに分散させます。
目標は、ESB を新規開発のクリティカル パスから外すことであり、必ずしも完全に置き換えることではありません。結局のところ、ESB は、アップグレードされない可能性のあるレガシー サービスに対してまだ役割を担っているのです。
さらに、新しい API と、API ゲートウェイによって開放される API マネジメント機能にも注目しましょう。コネクティビティを通じて価値を生み出せば、基盤となる実装は自然に最も価値のあるものへと移行するはずです。API コネクティビティに注力することは、モダン エンタープライズにとって価値を生み出す行為であるに違いありません。
Kong の API ゲートウェイを使ってどのように「カスタマーファースト」の組織を実現できるか興味をお持ちですか？
Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。
記事参照： 2022 年 1 月 4 日
Brad Drysdale
© Kong Inc. 2022
「API Infrastructure: ESB versus API Gateway (Part 2)」
