コンテナ クラウド プラットフォームにマイクロサービスをデプロイするときに API ゲートウェイを選択するにはどうすればよいですか?

マイクロサービスはますます普及しており、ますます多くの企業がマイクロサービス アーキテクチャを採用し始めています。今日、ある人から、優れたマイクロサービス実装ベンダーを推薦してほしいと頼まれました。しかし、マイクロサービスの導入は簡単ではなく、マイクロサービスの実装に欠かせない重要なコンポーネントが API ゲートウェイです。コンテナ クラウド プラットフォームにマイクロサービスを展開する場合、API ゲートウェイの実装機能、展開方法、製品の選択が重要になります。

名前が示すように、ゲートウェイは、セキュリティ チェック、認証と承認、ルーティングの配布、フロー制御、ヒューズ保護などの重要な役割を担うネットワーク ゲートウェイです。 API ゲートウェイは、API のネットワーク ゲートウェイおよびチャネルです。これはマイクロサービス プラットフォーム全体の中枢であり、API リクエストと応答の唯一の方法です。コンテナ クラウドの弾力的なスケーリング特性を活用し、マイクロサービスの利点を組み合わせるには、コンテナ クラウド プラットフォーム上にマイクロサービスを展開すると、API ゲートウェイの実装と展開がより複雑になります。

[[238635]]

1. APIゲートウェイ

API ゲートウェイは、サービスを呼び出す唯一のノードであり、リクエスト応答の入口と出口となるサーバーです。 API ゲートウェイは、内部システムのアーキテクチャをカプセル化し、さまざまなクライアントに API を提供します。通常、認証と承認、アクセス制御、ルーティング、負荷分散、キャッシュ、ログ記録、フロー制限、変換、マッピング、フィルタリング、回路遮断、登録、サービス オーケストレーション、API 管理、監視、統計分析などの他の機能も実装する必要があります。

API ゲートウェイの機能から、その重要性がわかります。峠は一人でも守れるが、一万人でも突破することはできない。 API ゲートウェイはこのような重要な責任を担っています。サービスシステム全体のセキュリティバリアであるだけでなく、多くのサービスガバナンス機能も備えています。したがって、コンテナ クラウドとマイクロサービス システムを構築するには、適切な API ゲートウェイを実装または選択することが重要な問題となります。これにより、API ゲートウェイの展開では、安全性を確保するために接触面を可能な限り減らす必要があることも決定されます。

2. APIゲートウェイの役割と価値

現在では、API エコノミーを提唱し、OpenAPI を確立してパートナーや顧客にクラウド API サービスを提供したり、サービスの数に応じて一定の料金を請求したりする人も多くなっています。今はこれについては説明しませんが、マイクロサービス アーキテクチャを採用する場合、API ゲートウェイ コンポーネントは不可欠です。

マイクロサービス API ゲートウェイについては、多くの人が詳しく紹介しています。重要な理由としては、クライアントとマイクロサービス間の通信、マイクロサービスの再構築、プロトコル変換などが必要なため、そのような役割を担う API ゲートウェイが必要になることです。

API ゲートウェイは、統合機能を提供し、外部インターフェースを統合し、オープン アプリケーションを保護し、アプリケーション開発を加速し、データの価値を実現し、ビジネス トレンドを監視および分析し、オープン プラットフォームの構築を支援します。

1. 相互接続と相互運用性のための統合

API は、企業間のシステムとビジネス エコシステム全体を統合するためのインターフェースです。マイクロサービスアーキテクチャーやESBアーキテクチャーに関わらず、システムやサービスの統合を実現し、データやサービスの共有を実現し、企業全体のリソースを活性化し、重複した投資や構築を削減することが非常に重要な価値です。

2.標準化と正規化を実現するために統一された外部インターフェースを提供する

新しいビジネス アプリケーションを実装する場合、または異なるシステムやサービス間で機能を統合して、異なるサービスが提供する機能を呼び出す必要がある場合は、API ゲートウェイを使用すると、ユーザーはサービス エッジを意識することなく、統一されたインターフェイスを使用してサービスをオーケストレーションおよびアセンブルできます。企業内のさまざまなサービスでは、歴史的な理由により、提供されるインターフェースがかなり異なる場合があります。 API ゲートウェイは、このような違いを排除し、Restful インターフェースなどの標準化されたインターフェースを外部に提供できます。内部サービスが更新されると、API ゲートウェイを介して適応と変換も実行できます。これはクライアントに対して透過的であり、呼び出し元が調整を行う必要はありません。

3. オープンアプリケーションのセキュリティ保護

私たちの意見では、API ゲートウェイの最も重要な機能はセキュリティ機能です。外部に公開されるサービスの数を減らすと、システムのセキュリティが向上します。認可認証、アクセス制御を実装し、脅威と OWASP の脆弱性を防止し、SSO と統合 ID 管理を通じてセキュリティを強化し、アプリケーション、モバイル、IoT にエンドツーエンドのセキュリティ メカニズムを提供します。アプリケーション サービスのセキュリティを保護するために、API ゲートウェイにフロー制御、クォータ、フィルタリング、サーキット ブレーキング、サービス優先度制御、負荷分散などのメカニズムを実装する必要がある場合もあります。プライベート API であろうと OpenAPI であろうと、そのセキュリティは常に真剣に取り組む必要がある問題です。

4. アプリケーションとサービスの開発を簡素化して効率を向上

これらのセキュリティ メカニズムを API ゲートウェイ層に実装すると、セキュリティが向上するだけでなく、アプリケーション サービスの開発も簡素化されます。これにより、開発者は基本的な機能やコンポーネントを気にすることなく、ビジネス アプリケーションやビジネス サービスの研究開発に集中できるようになり、開発と展開の効率が向上し、収益性が向上します。 API サービスを分類および等級付けすることで、開発者のデータおよびサービスへのアクセスを簡素化および制御できます。サービスの公開と共有により、より大きなコラボレーションと開発者のエコシステムを構築できます。ビジネス サービスとビジネス アプリケーションの提供を加速します。

5. データの価値を引き出し、産業の発展を促進する

データは常に価値があり、その価値はそれがどのように使用されるかによって決まります。マイクロサービスベースの API サービスは、データの価値を実現する方法を提供します。これらの API サービスは API ゲートウェイによって管理されるため、これらの API サービスは単独で使用できるだけでなく、追加のメリットも生み出します。同時に、他の企業にコストを節約する方法を提供し、戦略的なウィンウィンの状況を実現します。

6. ビジネストレンドを監視・分析し、賢明な意思決定を支援する

API ゲートウェイには、API の監視と管理の役割もあります。どの API サービスがより頻繁に呼び出され、どの API サービスがより頻繁に呼び出されないか、誰がそれらをより頻繁に呼び出しているか、また、ピーク トラフィック時間、平均トラフィック、応答時間などをすべて監視し、統計的に分析する必要があります。このデータは、API サービスの運用や再構築、そして合理的な意思決定に役立ちます。よりインテリジェントな意思決定のために必要なデータサポートを提供します。

7. オープンプラットフォームの構築とエコシステムの構築を支援する

開放性と協力はますます拡大し、あらゆるレベルにまで広がっています。グローバル化やグローバルビレッジからチームワークまで、もはや一人で戦うことはできません。心を閉ざすと、自分自身が制限されるだけです。したがって、企業もパートナーと徐々にエコシステムを構築し、このエコシステムに統合するための独自のオープン プラットフォームを構築する必要があります。 API ゲートウェイはその重要な部分です。

3. APIゲートウェイが実現する必要がある機能

では、API ゲートウェイはどのような機能を実現する必要があるのでしょうか?一般的に、次の機能を考慮する必要があります。

1. APIセキュリティ

安全第一。私たちの社会的な交通と同じように、まず安全を確保し、次に素早く追い越すことです。これは、API ゲートウェイを実装または選択する際に最初に考慮すべきことでもあります。

セキュリティ上の問題も数多く存在します。 API ゲートウェイ層では通常、統合 ID 認証を実装する必要があり、統合認証センターや権限センターに接続して認可認証、アクセス制御などの機能を実装できます。

レイテンシを最小限に抑えるには、API ゲートウェイをできるだけ薄くする必要があります。安全を前提に迅速な通過を実現します。ブロックすることはできないので、遅延をできるだけ減らす必要があります。

さらに、データ パケットが他人によって改ざんまたは偽造されるのを防ぎ、非公開データが他人に盗聴されるのを防ぐために、安全な送信を使用することを検討してください。サービス インフラストラクチャのセキュリティとサードパーティのアプリケーション/コンテンツのセキュリティも考慮する必要がある可能性があります。

2. サービスの前処理

ルーティング、フィルタリング、フロー制御、クォータ、サーキットブレーカー、変換、優先順位、負荷分散などについては、「マイクロサービスのサービスガバナンス」の記事で説明しましたので、ここでは繰り返しません。主なサービス ガバナンス戦略は、サービスが利用できなくなることを防ぎます。

3. サービスオーケストレーション

API ゲートウェイ レイヤーを使用して、複合サービス (ビジネス サービス) を構築します。これには、API ゲートウェイの開発機能、つまり、ほとんどのオープン ソース API ゲートウェイではサポートされていないサービス オーケストレーション機能が関係します。これについては、「コンテナ クラウドのサービス オーケストレーション設計」の記事でも説明しました。しかし、考慮する必要がある問題があります。マイクロサービス アーキテクチャを使用する場合、サービスをデプロイするときに複数のサービス インスタンスがデプロイされることがあります。各サービス インスタンスを登録センターに登録する必要がありますか、それともすべてのサービス インスタンスで 1 つのサービスのみを登録する必要がありますか?これは私たちが遭遇した問題です。

商用 API ゲートウェイ製品を使用する場合、基本的にはサービス オーケストレーション機能とサービス登録機能が備わっています。各マイクロサービス コードでサービス登録を実装する代わりに、API ゲートウェイのサービス登録機能を使用して、API ゲートウェイ レイヤーでサービス登録を実装できます。これにより、API ゲートウェイ層でサービス オーケストレーションを実装し、コンテナ クラウドの負荷分散機能と柔軟なスケーリング機能を最大限に活用できるようになります。マイクロサービス インスタンスは登録センターに登録する必要はなく、各マイクロサービス (1 つ以上のマイクロサービス インスタンス) は登録センターに 1 回だけ登録されます。

これにより、マイクロサービスの開発も簡素化され、マイクロサービスのビジネス実装に重点が置かれ、サービス登録、オーケストレーション、フロー制御などが API ゲートウェイ レイヤーに実装されるようになります。

4. サービス登録

API ゲートウェイ レイヤーはサービス オーケストレーション機能を提供しますが、オーケストレーションされたサービスも、新しいサービスになるために登録センターに登録する必要があります。 API ゲートウェイはサービス登録機能を提供する必要があります。

コンテナ クラウド プラットフォームと仮想マシンにそれぞれサービスがデプロイされ、コンテナ クラウド プラットフォーム内部登録センターとコンテナ クラウド プラットフォーム外部登録センターにそれぞれ登録されるという問題が発生しました。このサービスを呼び出すにはどうすればいいですか?これは、当社の開発チームの 1 つが直面している問題です。一方で、コンテナ クラウド プラットフォームの便利な継続的インテグレーションと継続的デプロイメントの機能を活用したいと考えていますが、他方では、コンテナ クラウド プラットフォームの信頼性と安定性にあまり信頼を置いていないため、同時に仮想マシン環境でのバックアップを望んでいます。また、複数のサービスインスタンスと弾力的なスケーリングの問題にも直面しています。サービスクライアント側で負荷分散を実装すると、さらに複雑になります。仮想マシンとコンテナ クラウド プラットフォームの両方にゲートウェイ サービスを展開するのは面倒です。最善の方法は、統合 API ゲートウェイを使用してルーティング構成とトラフィック分散を実装し、API エントリをさまざまなサービスまたはサービス インスタンス (仮想マシンまたはコンテナ クラウド プラットフォーム) にルーティングできるようにすることです。これは API ゲートウェイ レイヤーでの構成を通じて実現され、API ゲートウェイは独立したコンポーネントとして展開されます。たとえば、Nginx plus は eureka、consul、etcd をサポートしており、プラットフォーム全体の独立した API ゲートウェイとして独立して展開されます。

5. API管理

一般的に、API ゲートウェイ層では、API ライフサイクルの管理、構成、監視機能、つまり API 管理機能の実装を検討する必要があります。 APIはプライベートAPIとオープンAPIに分けられます。マイクロサービス ステージ モデルについて説明する際に、エコシステム レベルについて言及しました。これは、OpenAPI を提供し、パートナーと協力してサービス エコシステムを共同で構築することを意味します。

商用 API 管理製品には通常、API ゲートウェイ、API 開発ツール、管理コンソールなどのコンポーネントが含まれており、API ライフサイクル全体を通じて API の開発、構成、展開、監視、更新を提供します。オープンソース API ゲートウェイは通常、よりシンプルです。 API ゲートウェイの基本機能、または API ゲートウェイ実装フレームワークのみを提供します。

6. APIゲートウェイの展開

コンテナ クラウド プラットフォームにマイクロサービスをデプロイする場合、API ゲートウェイは重要な基本コンポーネントであり、そのデプロイについても慎重に検討する必要があります。これについては以前の記事で説明しました。現段階では、コンテナ クラウドは、すべてのコンポーネントをコンテナ形式で展開する必要があることを意味するものではありません。誰もが分散化について熱心に議論している今日の世界でも、中心は依然として存在します。したがって、集中型の非コンテナ化デプロイメントを使用し、マルチアクティブ高可用性モードを備えたデュアルマシン クラスターにデプロイすることをお勧めします。マスター/スレーブ モードまたはスタンドアロン展開を使用しないでください。市販製品は強力な処理能力を備えていますが、単一点障害、単一点ボトルネック、拡張の難しさも回避する必要があります。

負荷圧力が高い場合は、Web、モバイル アプリ、PC アプリなどに API ゲートウェイを個別に展開することを検討できます。

4. APIゲートウェイの選択

1. オープンソース

マイクロサービスを採用する企業が増えるにつれて、マイクロサービス API ゲートウェイの重要性を認識する人も増え、API ゲートウェイの開発と改善もますます進んでいます。多くのオープンソース製品は、ほとんどの企業の導入ニーズを満たすのに十分なほど強力です。これらのオープンソース製品に基づいて、一部の機能をカスタマイズおよび拡張し、ビジネスニーズをより適切に満たすことができます。

• Tyk は、Tyk, Inc. によって開発およびサポートされているオープンソースの API ゲートウェイ、パネル、および API 管理プラットフォームです。Try は、Go で実装されたゲートウェイ サービスです。 Tyk API ゲートウェイ、Tyk ダッシュボード、Tyk 開発者ポータル、Tyk ポンプ、Tyk アイデンティティ ブローカーなどのコンポーネントが含まれます。 Tyk オープンソース API ゲートウェイは、ルーティング、アクセス制御、データ変換、ログ記録などの実際のリクエスト管理に大幅な改善を加えました。Tyk は完全に独立して実行でき、有効な Redis データベースのみを必要とし、水平方向にスケーリングできます (以下に示すように)。

• Kong は拡張可能なオープンソースのマイクロサービス API ゲートウェイです。 Kong はあらゆる RESTful API の前で実行され、プラグインを通じて拡張され、コア プラットフォームを超えた追加機能やサービスを提供します。 nginx をベースに開発されています。 Kong は、NGINX、Apache Cassandra、PostgreSQL などの信頼性の高いテクノロジーの上に展開され、アプリケーション サービスを操作および構成するための使いやすい RESTful API を提供します。
• Zuul は、Netflix が開発した JVM ベースのルーティングおよびサーバー側ロードバランサーです。主な機能は、認証、動的ルーティング、監視、復元力、ストレス テスト、カナリア テスト、負荷制限、セキュリティ、静的応答処理、アクティブ/アクティブ スイッチング管理です。 Spring Cloud の API ゲートウェイ コンポーネントとして使用され、Spring Cloud のさまざまなコンポーネントと組み合わせて使用​​できます。
• Spring Cloud Gateway は、Spring Frameworks 5、Factor プロジェクト、Spring Boot 2.0 上に構築されたプログラム可能なルーターです。ヒューズ、フィルタリング、サービス検出統合、電流制限、変換など、あらゆるリクエスト属性のルーティングを一致させる機能。比較的新しいリアクティブ プログラミングを使用します。試してみましたが、時間の制約により、多くの新しいテクノロジーを習得するのは困難だったため、一時的な解決策として Zuul を使用する必要がありました。
• NGINX または NGINX Plus は、導入、構成、開発が容易な、成熟したスケーラブルな高性能 Web サーバーとリバース プロキシを提供します。 Nginx を Lua スクリプトと組み合わせて API ゲートウェイ機能を実装することができ、NGINX Plus は認証、権限制御、負荷分散、キャッシュを管理し、アプリケーションのヘルスチェックと監視を提供できます。

他にも多くのオープンソース API ゲートウェイが存在します。ご興味がございましたら、関連情報を検索していただけます。

2. 自社開発

マイクロサービスを実装する際に、オープンソースをベースに独自の API ゲートウェイを開発したり、SpringCloud Netflix Zuul などのツールを使用してマイクロサービス ゲートウェイを実装したりする企業も数多くあります。これには、マイクロサービス ゲートウェイまたは API ゲートウェイの展開、およびサービス間の相互作用とゲートウェイが実現する必要のある機能に関連する問題が含まれます。たとえば、集中型のデプロイメントですか、それともサイドカー デプロイメントですか?企業によって採用するソリューションは異なります。私たちの観点からは、集中型の展開がより適切であるはずです。特に、ビジネス アプリケーションをより適切にサポートするために、コンテナー クラウド プラットフォームに基づいてサービス ミドル プラットフォームを構築する場合は、集中型の非コンテナー化展開の方が適しています。

API ゲートウェイを実装する方法は多数あります。ほとんどのアプリケーションにとって、API Gateway のパフォーマンスとスケーラビリティも非常に重要です。したがって、同期の非ブロッキング I/O をサポートする API ゲートウェイを作成することは理にかなっています。スケーラブルな API ゲートウェイを実装するために使用できるさまざまなテクノロジーがあります。 JVM では、Netty、Vertx、Spring Reactor、JBoss Undertow などの NIO テクノロジーに基づくフレームワークを使用します。 Node.js は、Chrome の JavaScript エンジン上に構築された人気の非 JVM プラットフォームです。 Spring Cloud Gateway は、Spring Ractor をベースにした実装です。

API ゲートウェイを独自に開発するのは依然として困難です。本番環境で使用可能なマイクロサービス ゲートウェイを実現するには、多くの機能の実装を検討する必要があります。たとえば、SpringCloud 関連のコンポーネントには、Zuul、Ribbon、EureKa、Fein、Hystrix などがあります。このうち、Zuul は APIGateway に似たコンポーネントですが、Zuul だけでは決して十分ではありません。 Ribbon はクライアント側の負荷分散ツールであり、Eureka はサービスの登録と検出に使用され、Hystrix はマイクロサービス用の回路遮断サービスを実装でき、サービスの低下に使用されます。 Fein は、内部サービスが相互に呼び出すための REST サービス プロバイダーとして使用できます。これらすべての機能（ただしこれらに限定されません）を API ゲートウェイ レイヤーに実装する必要があります。

これらの機能を実現するには、比較的高い技術要件が必要であり、投資も少額ではありません。後々のアップデートや運用・保守も考慮する必要があるため、従来の企業には適していません。伝統的な企業には商用ソリューションの方が適しています。

3. 商用利用

商用の API ゲートウェイ製品も数多くあります。パートナー フルライフサイクル API 管理マジック クアドラントによると、主要製品には Google Apigee、CA API Management、IBM API Management、Axway、Mulesoft、TIBCO Mashary、Redhat 3Scale などがあり、そのほとんどはアメリカの企業です。国内の需要が不明確であったり、重要性が認識されていないため、関係する人材が非常に少なく、コンタクトを取ることが難しい。商用製品のコストは依然として比較的高く、大規模な従来型企業に適しています。 Axway API Management などの製品は強力かつ完全であり、ほとんどの企業のニーズを超えているため、これらの商用製品は大規模な多国籍企業や多くの支店を持つ企業に適しています。中小企業が使うにはちょっともったいないです。

• Axway は API ゲートウェイ製品を専門としています。中国チームは反応が非常に良く、親切で熱心です。これは、5 つ星の評価に値するものです!
• Apigee は現在最も人気のある API 管理製品ですが、中国では利用できないようです。 Pivatal とやり取りした際、Pivo​​tal のコンテナ クラウド製品には Apigee のサポートが組み込まれていると言われました。
• CA API Management も、Apigee に匹敵する非常に強力な製品です。しかし、CA Global、CA API Management China Teamに何度も連絡し、Webサイトにメッセージを残しましたが、一度返信があった後、それ以上の応答はありません。商品は良いのですが、サービスが悪いので悪い評価をせざるを得ません。
• TIBCO には、SOA サービスに基づくサービス ゲートウェイ製品である API Exchange Gateway 製品があることがわかりました。しかし、この製品は機能が比較的単純であり、大きな制限があります。現在、TIBCO は TIBCO が買収した製品である TIBCO Mashary のプロモーションに注力しています。現時点ではオンプレミス展開には対応していないようで制限があるが、近々対応予定とのこと。 TIBCO がさまざまなニーズに適しており、よりユーザーフレンドリーな、より優れた製品を発売してくれることを期待しています。 TIBCO China チームの皆さんの努力も期待しています。
• 3Scale API 管理も Redhat が買収した製品です。何度も連絡しましたが、それ以上の返答はありませんでした。少なくともサービスの評価が低くなってしまうのは残念です。

商品の詳しい情報については、ウェブサイト上の関連情報を参照してください。 Nginx Plus、Tyk Professional Edition、Kong Enterprise Edition などのオープンソース製品のエンタープライズ バージョンも検討できます。

V. 結論

従来の企業の場合、API ゲートウェイを導入する際には、インフラストラクチャ プラットフォームをアウトソーシングし、ビジネス アプリケーションを自社で開発するという原則に従うことができます。独自のインフラストラクチャ プラットフォームを開発するために、多くの人的リソースと資金を費やす必要はありません。成熟した製品を購入するのがより適切なアプローチです。次に、新しいビジネス アプリケーションの開発と新しいビジネスのサポートに技術リソースを集中します。十分な人的・資金的リソースがあり、業界内でプロモーションして利益を得たい場合を除き、独自のインフラ プラットフォームを開発することを検討できます。しかし、これはソフトウェア会社とあまり変わらず、コスト投資は非常に高くなります。オープンソースをベースにパッケージングを多少変更することは可能ですが、多くの顧客による実環境検証が行われず、商用製品のような安全性や安定性は確保されません。十分な技術力がない場合は、複雑な技術的問題に遭遇すると、実際のビジネスに影響が出る可能性があります。したがって、各企業はそれぞれの実際の状況に応じて適切なアプローチを選択できます。