適応型ガバナンスでAPI開発者に必要な自律性を実現

NGINX | 2022年11月10日

今日の企業では、世界各地に分散したチームが、複数のデプロイ環境にわたってAPIやマイクロサービスを構築、デプロイすることが一般的です。F5の「アプリケーション戦略の現状レポート」によると、組織の81%が、パブリッククラウド、プライベートクラウド、オンプレミス、エッジを含む3つ以上の環境で運用しています。

こうした複雑なマルチクラウドアーキテクチャの保守を担うPlatform Opsチームにとって、その信頼性とセキュリティの確保は大きな課題です。F5のレポートで調査対象となったソフトウェアエンジニアリング部門のリーダーによると、Platform Opsチームが直面するマルチクラウドの課題の上位は、可視性（45%）と一貫したセキュリティ（44%）です。

今日、APIやマイクロサービスが増加する中、APIガバナンスは、全社的なAPI戦略を計画・実施するうえで最も重要なテーマの1つになりつつあります。では、APIガバナンスとは何でしょうか。また、API戦略にとってなぜそれほど重要なのでしょうか。

APIガバナンスとは

最も基本的なレベルでは、APIガバナンスとは、ポリシーを策定し、チェックと検証を実施することで、APIの検出可能性、信頼性、可観測性、セキュリティを確保することです。これにより、最新のアプリケーションを支える複雑なシステムやビジネスプロセスの状態を可視化し、その情報を活用してAPIインフラストラクチャを継続的に進化させることができます。

APIガバナンスが必要な理由

APIガバナンスは、組織全体のAPI戦略を実現する手段であり、その戦略的重要性はいくら強調してもしすぎることはありません。適切なガバナンスがなければ、APIの設計、運用、製品化に一貫性を持たせることはできません。

ガバナンスの実施方法が不適切だと、負担の大きい要件が課され、チームの作業が遅れることが少なくありません。一方、APIガバナンスを適切に実施すれば、作業を削減し、承認プロセスを効率化できます。また、組織内の各チームがAPI戦略全体の目標達成に貢献しながら、それぞれ独立して機能できるようになります。

どの種類のAPIをガバナンスの対象にすべきか

API戦略の一環として効果的なAPIガバナンス計画を策定するには、まず本番環境で使用しているAPIの種類と、その管理に必要なツール、ポリシー、ガイダンスを特定します。現在、ほとんどの企業チームは、主に次の4種類のAPIを扱っています。

外部API – 外部の利用者や開発者に提供し、データや機能とのセルフサービス型の統合を可能にします
内部API – 内部アプリケーションとマイクロサービスの接続に使用され、組織内の開発者のみが利用できます
パートナーAPI – パートナー組織の開発者にデータやアプリケーションへのアクセスを共有することで、戦略的なビジネス関係の構築を促進します
サードパーティAPI – サードパーティベンダーからサービスとして提供され、多くの場合、決済処理やデータまたはアプリケーションへのアクセスの実現に利用されます

企業内の各種APIは、セキュリティと信頼性を確保し、必要とするチームやユーザーがアクセスできるように管理する必要があります。

利用できるAPIガバナンスモデル

APIガバナンスの定義と適用には、さまざまな方法があります。NGINXでは、通常、お客さまが次の2つのモデルのいずれかを適用しています。

一元管理型 – 中央のチームが変更をレビューして承認します。運用規模によっては、このチームがボトルネックとなり、進行が遅れる可能性があります
分散型 – 各チームが自律的にAPIを構築・管理できます。市場投入までの時間は短縮されますが、全体的なセキュリティと信頼性が損なわれます

しかし、企業がAPIファーストの取り組みを進め、本番環境のAPI数が増えるにつれて、どちらのモデルも機能しにくくなります。中央集権型モデルでは、多くの場合、さまざまな段階でレビューや承認を必要とする画一的なアプローチを導入しようとします。その結果、開発チームの作業が遅れ、摩擦が生じます。開発者が不満を募らせ、要件を回避する方法を見つけることさえあります（いわゆる厄介な「シャドーIT」）。

もう1つのモデルである分散型ガバナンスは、当初はAPI開発者にとってうまく機能しますが、時間の経過とともに複雑さが増していきます。APIをデプロイする各チームが頻繁に連携しなければ、APIごとに設計や動作が異なる、バージョン変更によってサービス間で停止が発生する、チームやサービスによってセキュリティの適用にばらつきが生じるなど、API全体で一貫したエクスペリエンスを提供できなくなります。APIを構築するチームにとっては、作業量と複雑さが増すことで、最終的には集中型モデルと同様に、開発がほとんど進まなくなります。

クラウドネイティブアプリケーションでは、個々のマイクロサービス間の通信や、リクエスト元への応答の返送にAPIを利用します。企業が柔軟性と俊敏性を求めてマイクロサービスの導入を進めるなか、APIの無秩序な増加は今後も続きます。そのため、複雑で絶えず変化するこうした環境では、APIガバナンスに別のアプローチが必要です。

アダプティブガバナンスでAPI開発者の力を引き出す

幸い、より優れた方法があります。アダプティブガバナンスは、API開発者の自律性を高めると同時に、企業全体のAPIの信頼性とセキュリティを確保するために必要な制御をPlatform Opsチームに提供する、従来とは異なるモデルです。

アダプティブガバナンスの中核となるのは、企業全体のアジリティを実現するために、統制（一貫性の確保）と自律性（各現場で意思決定を行う能力）のバランスを取ることです。実際、アダプティブガバナンスモデルでは、意思決定を分離し、各チームに分散させます。

Platform Opsチームは、共有インフラストラクチャ（APIゲートウェイと開発者ポータル）を管理し、API間の一貫性を確保するためのグローバルポリシーを設定します。一方、APIを構築するチームは、自らが担当するサービスや事業部門の専門家としての役割を担います。各チームには、それぞれのビジネス状況に応じた要件を満たすため、ロールベースのアクセス制御（RBAC）やサービスのレート制限など、APIのローカルポリシーを設定して適用する権限が与えられます。

アダプティブガバナンスにより、各チームや事業部門は、組織の共有インフラストラクチャを利用しながら、独自のワークフローを定義し、必要な管理レベルとのバランスを取ることができます。

NGINXでAPIにアダプティブガバナンスを導入

API戦略の計画と実装を開始する際は、組織に適応型ガバナンスを導入するために、以下のベストプラクティスに従ってください。

共有インフラストラクチャを提供する – APIプロキシとドキュメントを公開するためのAPIゲートウェイおよび開発者ポータルへのアクセスをチームに提供します
チームの自律性を高める – 共有ワークスペース内で、チームによるAPIの導入とライフサイクル管理を支援します
グローバルポリシーとローカル制御の両立 – 共有インフラストラクチャ全体にグローバルポリシーを設定しながら、各チームが自らのサービスをきめ細かく制御できるようにします

これらのユースケースを実現する方法を見ていきましょう。使用するのは、F5 NGINX Management Suiteの一部であるAPI Connectivity Managerです。

共有インフラストラクチャの提供

組織内の各チームがAPIを構築する際には、認証と認可、mTLS暗号化など、共通する機能をマイクロサービスに組み込む必要があります。また、社内チーム、ビジネスパートナー、外部開発者などのAPI利用者が、ドキュメントやバージョン情報を利用できるようにする必要もあります。

各チームが独自のソリューションを構築する代わりに、Platform Opsチームが共有インフラストラクチャへのアクセスを提供できます。API Connectivity Managerの他のすべての操作と同様に、UIまたは完全宣言型REST APIを使用して、わずか数分で設定できます。このREST APIにより、API Connectivity ManagerをCI/CDパイプラインに統合できます。この記事では、一般的なワークフローをUIで説明します。

API Connectivity Managerは、インフラストラクチャとサービスという2種類のワークスペースをサポートしています。インフラストラクチャワークスペースは、Platform OpsチームがAPI Gateway ClusterおよびDeveloper Portal Clusterとして共有インフラストラクチャを導入し、管理するために使用します。サービスワークスペースは、API開発者がAPIとドキュメントを公開し、管理するために使用します。

共有インフラストラクチャを設定するには、まずインフラストラクチャWorkspaceを追加します。左側のナビゲーション列で［Infrastructure］をクリックし、タブの右上隅にある［+ Add］ボタンをクリックします。Workspaceに名前を付けます（ここでは、シンプルな「Hello, World!」APIを構築する架空のチームを表す「team-sentence」とします）。

図1：Infrastructure Workspaceの追加

次に、WorkspaceにEnvironmentを追加します。Environmentには、API Gateway ClusterとDeveloper Portal Clusterが含まれます。Workspaceの名前をクリックし、…列のActionsアイコンをクリックして、ドロップダウンメニューからAddを選択します。

図2に示すように、［Create Environment］パネルが開きます。［Name］フィールド（必要に応じて［Description］フィールド）に入力し、環境の種類（本番または非本番）を選択して、追加するインフラストラクチャ（API Gateway Clusters、Developer Portal Clusters、またはその両方）の［+ Add］ボタンをクリックします。［Create］ボタンをクリックして、Environmentの設定を完了します。詳しい手順については、「API Connectivity Managerドキュメント」を参照してください。

図2：環境を作成してインフラストラクチャをオンボーディング

チームに裁量を与える

事業部門、地域、その他の論理的な境界に基づいてチームを論理的に分離することは、各チームが成果を上げるために必要なツールへのアクセスを妨げない限り、合理的です。共有インフラストラクチャを利用するために、チームがグローバルレベルの運用まで気にかける必要はありません。各チームが自らの要件の定義、ロードマップの策定、マイクロサービスの構築に集中できるようにすることが重要です。

チームが整理しやすいように、Platform Opsチームは、各チームがサービスやドキュメントを整理、運用するためのサービスWorkspaceを提供できます。これにより論理的な境界が設けられ、サービス開発用のさまざまな環境（開発、テスト、本番環境など）にアクセスできるようになります。このプロセスは、前のセクションで作成したインフラストラクチャWorkspaceの作成と同様です。

まず、左側のナビゲーション列で［Services］をクリックし、次にタブの右上隅にある［+ Add］ボタンをクリックします。Workspaceに名前を付け（ここでは「Hello, World」サービス用にapi-sentenceとします）、必要に応じて説明と連絡先情報を入力します。

図3：サービス用Workspaceの作成

この時点で、API開発者を招待し、開発者向けに作成したWorkspaceでプロキシとドキュメントの公開を開始してもらうことができます。APIプロキシとドキュメントの公開手順について詳しくは、API Connectivity Managerドキュメントを参照してください。

グローバルポリシーとローカル制御のバランス

適応型ガバナンスでは、グローバルポリシーを適用しながら、チームがアジリティ向上につながる意思決定を行えるようにすることが求められます。そのためには、Platform Opsが適用するグローバル設定を定義するとともに、API開発者が使用できるツールと意思決定の範囲を定める「ガードレール」を設け、責任範囲を明確に分ける必要があります。

API Connectivity Managerは、共有インフラストラクチャに適用されるグローバルポリシーと、APIプロキシレベルで管理されるきめ細かな制御を組み合わせて提供します。

API Connectivity Managerで利用できるグローバルポリシーは次のとおりです。

エラーレスポンス形式 – APIゲートウェイのエラーコードとレスポンス構造をカスタマイズ
ログ形式 – アクセスログを有効にし、ログエントリの形式をカスタマイズ
OpenID Connect – OpenID ConnectポリシーでAPIへのアクセスを保護
レスポンスヘッダー – レスポンスにヘッダーを含めるか、レスポンスから除外します
リクエスト本文のサイズ – 受信するAPIペイロードのサイズを制限します
インバウンドTLS – APIクライアントとのTLS接続に関するポリシーを設定
バックエンドTLS – TLSを使用してバックエンドサービスへの接続を保護します

API Connectivity Managerで利用可能なAPIプロキシポリシーは次のとおりです。

許可されるHTTPメソッド – 使用可能なリクエストメソッドを定義します（GET、POST、PUTなど）
アクセス制御 – さまざまな認証および認可方式（APIキー、HTTP Basic認証、JSON Web Token）を使用して、APIへのアクセスを保護します
バックエンドのヘルスチェック – 継続的にヘルスチェックを実行し、バックエンドサービスへのリクエスト失敗を回避します
CORS – 外部ドメインのクライアントによるリソースへのアクセスを制御できるようにします
キャッシュ – キャッシュポリシーによりAPIプロキシのパフォーマンスを向上
プロキシリクエストヘッダー – 選択したヘッダーをバックエンドサービスに渡す
レート制限 – 受信リクエストを制限し、APIワークロードを保護

次の例では、UIを使用して、API Gateway Proxyとバックエンドサービス間の通信を保護するポリシーを定義します。

左側のナビゲーション列で［Infrastructure］をクリックします。編集するAPI Gateway Clusterが含まれるEnvironmentの名前をクリックすると、そのEnvironment内のAPI Gateway ClustersとDeveloper Portal Clustersがタブに表示されます。

図4：API Gateway ClustersとDeveloper Portal Clustersのグローバルポリシーの設定

ポリシーを適用するAPI Gateway Clusterの行で、…アイコンを［Actions］列でクリックし、ドロップダウンメニューから［Edit Advanced Configuration］を選択します。左側の列で［Global Policies］をクリックすると、設定可能なすべてのグローバルポリシーの一覧が表示されます。

図5：API Gateway Clusterのポリシー設定

TLS Backendポリシーを適用するには、該当する行の右端にある［…］アイコンをクリックし、ドロップダウンメニューから［Add Policy］を選択します。必要な情報を入力して証明書をアップロードし、［Add］をクリックします。次に、［Save and Submit］ボタンをクリックします。これ以降、API Gateway Clusterとバックエンドサービス間のトラフィックはTLSで保護されます。詳しい手順については、「API Connectivity Managerドキュメント」を参照してください。

まとめ

APIガバナンスの計画と実装は、API戦略を成功に導くうえで極めて重要なステップです。分散型モデルへの移行を進め、適応型ガバナンスによってチームやAPIごとに異なる要件に対応することで、APIやクラウドネイティブ環境の高い生産性を支えるスピードと俊敏性を損なうことなく、規模を拡大しながら一貫したガバナンスを適用できます。