適応型ガバナンスにより、API 開発者に必要な自律性がもたらされます

今日の企業は、通常、複数のデプロイメント環境にまたがって API とマイクロサービスを構築およびデプロイする、世界中に分散したチームで構成されていることがよくあります。 F5 のアプリケーション戦略の現状レポートによると、組織の 81% がパブリック クラウド、プライベート クラウド、オンプレミス、エッジにわたる 3 つ以上の環境で運用しています。

これらの複雑なマルチクラウド アーキテクチャの信頼性とセキュリティを確保することは、それらの保守を担当するプラットフォーム運用チームにとって大きな課題です。 F5 レポートで調査されたソフトウェア エンジニアリング リーダーによると、可視性 (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 の信頼性とセキュリティを確保するために必要な制御をプラットフォーム運用チームに提供する代替モデルを提供します。

適応型ガバナンスの中心にあるのは、制御 (一貫性の必要性) と自律性 (ローカルで意思決定を行う能力) のバランスを取り、企業全体の俊敏性を実現することです。 実際には、適応型ガバナンス モデルは意思決定をチーム間で分割して分散します。

プラットフォーム運用チームは、共有インフラストラクチャ (API ゲートウェイと開発者ポータル) を管理し、API 全体の一貫性を確保するためのグローバル ポリシーを設定します。 ただし、API を構築するチームは、そのサービスまたは事業分野の専門家として機能します。 個々のビジネス コンテキストの要件を満たすために、ロールベースのアクセス制御 (RBAC)、サービスのレート制限など、API のローカル ポリシーを設定して適用する権限が与えられます。

適応型ガバナンスにより、各チームまたは事業部門は、組織の共有インフラストラクチャを使用しながら、ワークフローを定義し、必要な制御レベルのバランスをとることができます。

NGINX で API の適応型ガバナンスを実装する

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

• 共有インフラストラクチャの提供- APIプロキシとドキュメントを公開するためのAPIゲートウェイと開発者ポータルへのアクセスをチームに提供します。
• チームに権限を与える– 共有ワークスペース内でチームが API のオンボードとライフサイクルの管理を行えるように支援します。
• グローバルポリシーとローカルコントロールのバランスをとる– 共有インフラストラクチャ全体にグローバルポリシーを設定し、チームにサービスのきめ細かな制御を提供します。

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

共有インフラストラクチャを提供する

組織全体のチームが API を構築しており、認証と承認、mTLS 暗号化など、同様の機能をマイクロサービスに含める必要があります。 また、社内チーム、ビジネス パートナー、外部開発者など、API 利用者がドキュメントとバージョン管理を利用できるようにする必要があります。

プラットフォーム運用チームは、チームに独自のソリューションを構築することを要求するのではなく、共有インフラストラクチャへのアクセスを提供できます。 API Connectivity Manager のすべてのアクションと同様に、UI または完全に宣言的な REST API を使用してこれをわずか数分で設定でき、API Connectivity Manager を CI/CD パイプラインに統合できます。 この投稿では、UI を使用していくつかの一般的なワークフローを説明します。

API Connectivity Manager は、インフラストラクチャとサービスという 2 種類のワークスペースをサポートしています。 インフラストラクチャ ワークスペースは、プラットフォーム オペレーション チームが API ゲートウェイ クラスターと開発者ポータル クラスターの形式で共有インフラストラクチャをオンボードおよび管理するために使用されます。 サービス ワークスペースは、API 開発者が API とドキュメントを公開および管理するために使用されます。

共有インフラストラクチャをセットアップするには、まずインフラストラクチャ ワークスペースを追加します。 左側のナビゲーション列で[インフラストラクチャ]をクリックし、タブの右上隅にある[+ 追加]ボタンをクリックします。 ワークスペースに名前を付けます (ここでは、チーム センテンス(単純な「Hello, World!」を構築する架空のチーム))。 API)。

次に、ワークスペースに環境を追加します。 環境には、API ゲートウェイ クラスターと開発者ポータル クラスターが含まれます。 ワークスペースの名前をクリックし、 [アクション] 列の…アイコンをクリックして、ドロップダウン メニューから[追加]を選択します。

図 2 に示すように、環境の作成パネルが開きます。 名前(およびオプションで説明) フィールドに入力し、環境のタイプ (本番または非本番) を選択して、追加するインフラストラクチャ (API Gateway クラスター、開発者ポータル クラスター、またはその両方) の+ 追加ボタンをクリックします。 「作成」ボタンをクリックして環境の設定を完了します。 詳細な手順については、 API Connectivity Manager のドキュメントを参照してください。

チームに権限を与える

事業部門、地理的地域、またはその他の論理的な境界によってチームを論理的に分離することは、成功するために必要なツールへのアクセスを奪われない限り、理にかなっています。 共有インフラストラクチャにアクセスできるからといって、チームがグローバル レベルでのアクティビティについて心配する必要はありません。 代わりに、独自の要件の定義、ロードマップの作成、マイクロサービスの構築に集中してもらいたいのです。

チームの整理を支援するために、プラットフォーム運用チームは、チームがサービスとドキュメントを整理および運用するためのサービス ワークスペースを提供できます。 これらは論理的な境界を作成し、サービスを開発するためのさまざまな環境（開発、テスト、本番など）へのアクセスを提供します。 このプロセスは、前のセクションで作成したインフラストラクチャ ワークスペースを作成するプロセスに似ています。

まず、左側のナビゲーション列で[サービス] をクリックし、タブの右上隅にある[+ 追加]ボタンをクリックします。 ワークスペースに名前を付け（ここでは、「Hello, World」サービスのapi-sentence ）、オプションで説明と連絡先情報を入力します。

この時点で、API 開発者を招待して、作成したワークスペースでプロキシとドキュメントの公開を開始できます。 API プロキシとドキュメントを公開するための詳細な手順については、 API Connectivity Manager のドキュメントを参照してください。

グローバル政策とローカルコントロールのバランスをとる

適応型ガバナンスでは、グローバル ポリシーの適用と、チームが俊敏性を高める意思決定を行えるようにすることのバランスが必要です。 プラットフォーム オペレーションによって適用されるグローバル設定を定義し、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 基本認証、JSON Web トークン) を使用して API への安全なアクセスを実現します。
• バックエンドヘルスチェック– バックエンドサービスへのリクエストの失敗を回避するために継続的なヘルスチェックを実行します。
• CORS – 外部ドメインのクライアントによるリソースへの制御されたアクセスを有効にする
• キャッシュ– キャッシュポリシーでAPIプロキシのパフォーマンスを向上
• プロキシリクエストヘッダー– 選択したヘッダーをバックエンドサービスに渡す
• レート制限– 受信リクエストを制限し、API ワークロードを保護する

次の例では、UI を使用して、API ゲートウェイ プロキシとバックエンド サービス間の通信を保護するポリシーを定義します。

左側のナビゲーション列で「インフラストラクチャ」をクリックします。 編集する API ゲートウェイ クラスターを含む環境の名前をクリックすると、その環境内の API ゲートウェイ クラスターと開発者ポータル クラスターがタブに表示されます。

ポリシーを適用する API Gateway クラスターの行で、[アクション] 列の…アイコンをクリックし、ドロップダウン メニューから[詳細構成の編集]を選択します。 左側の列の「グローバル ポリシー」をクリックすると、構成できるすべてのグローバル ポリシーのリストが表示されます。

TLS バックエンドポリシーを適用するには、その行の右端にある…アイコンをクリックし、ドロップダウン メニューから[ポリシーの追加]を選択します。 要求された情報を入力し、証明書をアップロードして、 「追加」をクリックします。 次に、 「保存して送信」ボタンをクリックします。 今後、API ゲートウェイ クラスターとバックエンド サービス間のトラフィックは TLS で保護されます。 詳細な手順については、 API Connectivity Manager のドキュメントを参照してください。

まとめ

API ガバナンスの計画と実装は、API 戦略を成功させるための重要なステップです。 分散モデルに向けて取り組み、適応型ガバナンスを利用してさまざまなチームや API の固有の要件に対処することで、API やクラウド ネイティブ環境の生産性を高めるスピードと俊敏性を犠牲にすることなく、均一なガバナンスを拡張して適用できます。

始める

NGINX Management Suite の 30 日間無料トライアルを開始します。これには、 API Connectivity Manager 、API ゲートウェイとしてのNGINX Plus 、API を保護するNGINX App Protectへのアクセスが含まれます。