大規模なハイブリッド API 管理: チーム構成とプラットフォーム設計の共通課題

※この投稿は米国時間 2023 年 2 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

はじめに

「デジタルの正念場: API とアプリケーションの現状（2022 年）」で、テクノロジー業界のさまざまなリーダーから聞き取りをおこなった結果、以下の 2 つのテーマが浮かび上がりました。

1. 回答者のうち 59% が、クラウド、特にハイブリッド クラウドがビジネスを成功に導くうえで重要な要素になりつつあると考えており、今後 12 か月以内にハイブリッド クラウドの活用拡大を予定していると回答しました。

2. 成熟度の高い API 戦略を持ち、API 導入が進んでいる組織の 82% が、効率性およびアジリティが向上し、コラボレーションが活性化したと回答しました。

多くの企業で、ハイブリッド クラウド（通常、オンプレミス インフラストラクチャまたはプライベート クラウドと Google Cloud などのパブリック クラウド コンピューティング環境を組み合わせたもの）と API が、ビジネスを成功に導く鍵として活用されていることは明らかです。そんななか、ハイブリッド環境で大規模な API を管理するために、チームとプラットフォームをどのように構築するかが課題となっています。

ここでは前後半に分けて、Apigee を使用して、ハイブリッド環境で大規模な API を管理するおすすめの方法を前後半に分けてご紹介します。今回の投稿では、チームの組織とプラットフォームのセットアップに話を絞って、成功するための方法をご説明しましょう。シリーズの第 2 回目では、プラットフォームの運用方法と、クラスタ、スケーリング、自動化の最適化についてお話します。

ハイブリッド環境で大規模な API を管理するのが難しい理由

ビジネスが成長すれば、成長スピードを維持するために API の規模と数を拡大することは当然です。それにより、数千を超える API を維持し、毎秒数万ものトランザクションを処理する必要がありますが、そうした API の運用には、多くの場合まったく異なるさまざまなビジネス ユニットと多数の開発チームが関わっています。大規模なオペレーションと同様、こうした数百にもおよぶ API を中央で一元的に運営および管理するのは、非常に困難です。

ハイブリッド環境で API を運用することのメリットは、レイテンシが低下する、規制に対応しやすいなどさまざまです。ただし、そうしたメリットを実現するには、客観的かつ現実的な方法で以下に挙げた 2 つの問題を解決する必要があります。

1. API チームの構成

API チームの組織パターンにはさまざまなものがありますが、センター オブ イネーブルメント チームはなかでも特に優れています。このチームは、多数の API 作成チームと、API エキスパートが集まる中央チームが社内で連携することで組織されます。中央チームは、API プログラムが一定のルールに沿うための仕組みを構築するとともに、再利用可能なコンテンツを作成します。また、CI / CD パイプラインなどの自動化の支援や、ベストプラクティスの提供を行います。

なお、中央チームが扱う実装のレベルは、ケースごとに異なります。たとえば、中央チームが完全な CI / CD パイプラインを維持する場合も、中央チームはテンプレートを提供するのみで、連携先のさまざまな開発チームが独自パイプラインを作成する場合もあります。どちらにしても、この仕組みにより、実装の連携形態を問わず、企業全体で一貫した API モデルと適切なガバナンスおよびセキュリティ体制を実現できます。

もう一つのおすすめの戦略は、中央チームの規模を徐々に縮小していく、または役割を再定義することです。たとえば、あるお客様は、GitOps モデルを活用して社内で最も規模の大きなビジネス ユニットに独自インフラストラクチャの運用を完全に任せるというモデルを最近導入しました。このケースでは、中央チームが Apigee ハイブリッドのインストールとアップグレードの自動化を作成し、ビジネス ユニットがプラットフォームをコピーして独自に運用することで、自律運用を可能にしました。このように、各チームが連携を保ちつつ、運用を独自化する体制に徐々に移行することで、デリバリーのタイミングを遅らせることなく、一貫したガバナンスを保てます。

以下の図は、この時系列の変化をわかりやすくまとめたものです。

2. プラットフォームの設計と構築

もう一つの重要な検討事項はプラットフォームの技術的な限界です。限界を考慮した設計は、プラットフォームのパフォーマンスと安定性の向上につながります。

設計段階では、アーキテクチャの基本要件を明確にするとともに、基本原則を関係者全員と共有し、合意を得ることが非常に重要です。この段階で考慮すべき基本的な事項を一部ご紹介します。

• ランタイムをホスティングする必要のあるリージョン数

• 野心的な稼働時間の SLA を満たすためには、2 つ以上のリージョンで本番環境トラフィックを処理する組織にランタイム インスタンスをホスティングします。アップグレードを行う際には、2 つのリージョンのアップグレードのタイミングをずらしてください。

• 組織のソフトウェア開発ライフサイクル（SDLC）の各段階と、どの段階で Apigee を使用するか

• Apigee 組織を使って SDLC の境界を作成できます。たとえば、開発組織やテスト組織などを使用することで、プロキシ機能を多数活用できます。一般的にこのモデルの開発組織では、作業の効率化のために開発者に比較的寛容なアクセス権を付与します。

• 各ビジネス ユニットまたは開発チーム間で必要なアクセス権と分離のレベル

• 環境に条件付き Identity and Access Management を適用して、チーム間の境界を作成することで、必要に応じてアクセスを制限できます。

• チームの規模が非常に大きく、内部に複数の組織を作る必要がある場合は、運用権を社内の複数のチームの Apigee 組織に分割して、中央チームの管理下におくことをおすすめします。

• こうした責任共有モデルでは、そのシステムを最も消費するユーザーが、自らインスタンスを起動および運用します。チームが多数の API を運用する場合や、独自の運用ニーズを持つ場合は、中央チームの自動化を利用して Apigee ハイブリッド クラスタを起動および運用できます。この方法で、中央チームの負担が軽減すると同時に、各ビジネス ユニットが、チームのニーズに合わせて、自律的にクラスタを最適化できるようになります。

• さらに分離が必要な非常に大規模なプログラムの場合は、ビジネス ユニットごとに独立した組織を作成して、個別に完全な SDLC 組織を運用する方法もあります。5,000 もの API がすべて相互に関連を持ち、併用されることはまれなため、このレベルの大規模なプログラムを運用するお客様の多くにとって、複数の Apigee 組織への分割は妥当な結論です。

ここでご紹介した基本的な推奨事項をもとに、それぞれに合った Apigee 組織と環境の論理的な設計を作成しましょう。Apigee 組織を使用して SDLC と社内のビジネス ユニットや部署などの分離メカニズムを表現することは、さまざまな環境の設計を行ううえで有益です。

プロキシを何千も含む大規模なデプロイの場合は、SDLC モデルに沿いつつ、複数の組織を論理的なビジネス ユニットに分割することをおすすめします。多くの場合、独自の組織が必要になるのは最も大きなビジネス ユニットのみです。また、共有組織に複数のビジネス ユニットを所属させることができます。

まとめ

大規模な IT プロジェクトも、ハイブリッド クラウド環境での API 運用も、すべてに当てはまる唯一の「正しい」方法はありません。自社に合ったアプローチを見つけるには、まず組織の要件を把握し、ユースケースに合わせて Apigee を活用しましょう。シリーズ後半では、Apigee と最適なリソース（クラスタ、自動化、モニタリングなど）を運用して、大規模なハイブリッド API プログラムを管理する方法をご紹介します。

Apigee ハイブリッドの詳細と導入方法については、Google Cloud のドキュメントをご覧ください。