開発者による効果的な API の作成をプラットフォーム エンジニアが支援するための 5 つの戦略
Google Cloud Japan Team
※この投稿は米国時間 2024 年 1 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。
最新のアプリケーションでは、複雑な機能を処理して超高速のパフォーマンスを実現し、記録的な速さで具現化する API を構築することが開発者に求められています。プラットフォーム エンジニアは、そのような開発者に適切なツールや手法を提供して API 開発の負担を軽減する縁の下の力持ちです。
では、プラットフォーム エンジニアが API 開発に影響を与えるには、どうすればよいでしょうか？それには、大きく分けて 5 つの戦略が存在します。以下の戦略を実践することで、プラットフォーム エンジニアは開発者がより優れた API を作成する手助けができます。
- API と内部プラットフォームを製品として扱う
- API 管理を内部プラットフォームに組み込む
- プロキシとポリシーのための CI / CD パイプラインを構築する
- 開発者が利用するためのゴールデンパスを作成する
- API の管理と自動化のために Apigee を活用する
各戦略を詳しく見ていきましょう。
1. API と内部プラットフォームを製品として扱う
優れたデジタル コネクテッド エクスペリエンスは、API、つまりアプリケーション同士の対話を可能にするデジタル メカニズムによってもたらされます。簡単に言えば、API はサービス統合を可能にするソフトウェア製品にすぎません。消費者向けに出荷される他のソフトウェア製品と同様に API も、ソフトウェア開発ライフサイクル（SDLC）のような体系的プロセスを使用して、テスト、保護、デプロイ、管理が行われるべきです。内部プラットフォームは、このようなデジタル製品の提供を可能にします。それは、共通のツールセットと、組織の考えや提供価値を体現した「独善的」なテンプレートを開発者が使用できるようにすることで実現されます。たとえば、組織の要件で、API にアクセスしようとするすべてのアプリケーションに OAuth トークンの提示が義務付けられているとします。この場合、プラットフォーム エンジニアは、フロー コールアウトを使用して OAuth v2 ポリシーをプロキシにアタッチするために使用される共有フロー パイプラインを利用可能にするゴールデンパスを作成するでしょう。
API がそうであるように、内部プラットフォームも製品です。社内のサイロを取り払い、組織でチーム横断的に連携して要件を理解することは、プラットフォーム エンジニアリング チームの主要な役割です。この連携により、開発者にとってより良いツールがもたらされます。
2. API 管理を内部プラットフォームに組み込む
プラットフォーム エンジニアの中核となる責務は、開発者が使用する内部プラットフォームを作成することです。この内部プラットフォームは、独善的なテンプレートやツールに開発者がアクセスできるようにすることで、開発者に自律性をもたらします。これらのテンプレートやツールを作成すれば、API 管理のさまざまな側面をプラットフォームで処理できるようになります。API 管理を内部プラットフォームに組み込むことで、標準化、セキュリティ、割り当て、モニタリング、自動デプロイなどをプラットフォームに搭載することができます。
3. プロキシとポリシーのための CI / CD パイプラインを構築する
API はデジタル製品であるため、コードを通じて作成、管理されなくてはなりません。プラットフォーム エンジニアの一般的なタスクは、API のソフトウェア開発ライフサイクルを自動化するために CI / CDパイプラインを作成することです。標準的な CI / CD パイプラインは、静的コード解析、単体テスト、デプロイ、統合テストで構成されます。
大まかに言うと、開発者はローカルでプロキシを開発し、Git を使ってプロキシコードをソースコード リポジトリに commit します。commit により、テストを実施してフィードバックを提供する自動化されたパイプラインが開始されます。成功すると、コードは本番環境にリリースされるまで、さまざまな環境にプロモートされます。構築した API は組織内の他の人が見つけられるようにしておく必要があります。内部 API の置き場所として便利なのが API Hub です。外部 API の検出と顧客向けのドキュメントには、デベロッパー ポータルを利用できます。
4. 開発者が利用するためのゴールデンパスを作成する
ゴールデンパスは、開発者のベロシティを向上させるコードとツールを統合したテンプレートで構成されます。その名が示すように、ゴールデンパスは開発者がソフトウェアを構築する際に最も抵抗の少ないパスを見つけるのを助けるもので、多くの場合にセルフサービスのテンプレートとワークフローを活用します。これらのテンプレートは、共通のタスクと独善的な戦略で構成されます。Apigee で API を開発する場合、標準的なゴールデンパスには以下が含まれます。
- スタートガイド
- プロキシ / ポリシー作成 / モック バックエンド用のスキャフォールディング テンプレート
- 自動的に挿入される標準的な共有フロー構成
- テストとデプロイのための CI / CD パイプライン
- API レジストリ テンプレート
5. API の管理と自動化のために Apigee を活用する
今回の主役である Apigee について説明します。Apigee は、API を構築、管理、保護するツールをプラットフォームチームに提供する API 管理プラットフォームで、ライフサイクル全体を通して API を管理するために使用できます。Apigee の API は、顧客とビジネス ロジック（バックエンド）の間に位置するデジタル インターフェースであるプロキシから始まります。プロキシは API ポリシーのアタッチメント ポイントとしても機能し、組織が API の動作をプログラムできるようにします。さらに、プロキシは API をバックエンドへの直接アクセスから切り離し、複雑さを隠すことも可能にします。プラットフォーム エンジニアは、開発者をプロキシの作成に集中させることで、より優れた API を作成できるようサポートします。プラットフォームは、API がどのように機能するかに関して独善的でなければなりません。Shared Flows などの Apigee ツールを使用すると、標準化と整合性を確保することができます。また、FlowCallout ポリシーとフローフックを使用すれば、これらのポリシーをプロキシにアタッチし、API 間で再利用できます。
より良い API を構築する
プラットフォーム エンジニアは、API と内部プラットフォームを製品として扱い、API 管理をプラットフォームに組み込み、API の管理と自動化のために Apigee を活用し、プロキシとポリシーのために CI / CD パイプラインを構築し、開発者が利用するためのゴールデンパスを作成することで、開発者が Apigee を使ってより優れた API を構築することを手助けできます。開発者を支援する方法について、さらに詳しいガイダンスをご希望の場合は、こちらの詳細なホワイト ペーパーをご確認ください。まだ Apigee をお使いでない場合は、詳細をご覧になるか、こちらから利用を開始していただけます。
-カスタマー エンジニア David Rush
-デベロッパー リレーションズ エンジニア Emanuel Burgess
