APIファーストのアプローチでマイクロサービスを構築するメリット

NGINX | 2023年1月19日

APIはクラウドネイティブアプリケーションをつなぐ役割を担い、アプリケーションを構成するマイクロサービス間の通信手段となります。アプリケーションの成長と拡張に伴い、マイクロサービスとAPIの数も増加します。多くの場合、これは避けられない結果ですが、最新のアプリケーションの信頼性、拡張性、セキュリティを確保する役割を担うPlatform Opsチームにとって大きな課題となります。F5では、この問題を「API sprawl」と呼び、以前のブログ記事で取り上げました。

APIスプロールを解消する最初の試みとして、組織はAPIの自動検出と修復のためのツールを導入し、トップダウン型のアプローチを採用することがあります。この方法は短期的には効果的ですが、APIやマイクロサービスの構築と運用を担うチームに過度な負担をかける場合が少なくありません。セキュリティやコンプライアンスの問題に対処するために既存のマイクロサービスやAPIを作り直すか、必要な承認を得るために煩雑なレビュープロセスを経る必要があるためです。そのため、多くの大規模なソフトウェア組織では、分散型のアプローチを採用し、適応型ガバナンスを活用して、開発者に必要な自律性を与えています。

直前になってセキュリティ対策を講じるよりも、この問題にはボトムアップで取り組む方が長期的には効果的です。まず、さまざまなマイクロサービスやアプリケーション向けのAPIを構築・運用するチームが関与し、多くの場合、組織のソフトウェア開発にAPIファーストのアプローチを採用することから始めます。

API-Firstとは

APIは数十年前から存在しています。しかし今や、単なる「アプリケーションプログラミングインターフェース」ではありません。APIの本質は、開発者向けのインターフェースです。あらゆるユーザーインターフェースと同様に、APIにも計画、設計、テストが必要です。APIファーストとは、APIを運用・利用するすべてのチームが、接続性とシンプルさの重要性を認識し、優先する考え方です。また、ほとんどの場合は開発者であるAPI利用者にとってのコミュニケーション、再利用性、機能性を重視します。

APIファーストへの道筋は数多くありますが、APIファーストに取り組む多くの企業にとって、最終的な目標は設計主導のソフトウェア開発アプローチです。実際には、このアプローチでは実装前にAPIを完全に定義します。まず、APIがどのように機能するかを設計し、文書化します。チームは、その成果物（一般に「APIコントラクト」と呼ばれます）に基づいて、アプリケーションの機能を実装します。

O’ReillyのeBook『Mastering API Architecture』第1章で、堅牢性と柔軟性を兼ね備えたAPIファーストのソフトウェア開発アプローチを支える設計手法をご覧ください。NGINXの提供でお届けします。

組織にとってのAPIファーストの価値

APIファースト戦略は、アプリケーションエコシステムを当初からモジュール化された再利用可能なシステムとして構築できるため、多くの場合、マイクロサービスアーキテクチャに最適です。APIファーストのソフトウェア開発モデルを採用することで、開発者と組織の双方に次のような大きなメリットがもたらされます。

開発者の生産性向上 – 開発チームは並行して作業でき、バックエンドアプリケーションのAPIに依存する他のマイクロサービスの担当チームに影響を与えることなく、そのアプリケーションを更新できます。各チームが確立済みのAPIコントラクトを参照できるため、APIライフサイクル全体を通じたコラボレーションも容易になることがよくあります。
開発者エクスペリエンスの向上 – APIファースト設計では、論理的で十分に文書化されたAPIを実現することで、開発者エクスペリエンスを重視します。これにより、開発者はAPIをシームレスに利用できます。Platform Opsチームにとって、API開発者エクスペリエンスを考慮すること<.htmla>が重要な理由をご確認ください。
一貫したガバナンスとセキュリティ – クラウドおよびプラットフォームのアーキテクトは、APIの設計段階でセキュリティとガバナンスのルールを組み込むことで、APIエコシステムを一貫した方法で構成できます。これにより、ソフトウェア開発プロセスの後半で問題が発見された場合に必要となる、コストのかかるレビューを回避できます。
ソフトウェア品質の向上 – APIを先に設計することで、APIを本番環境にデプロイできる状態になるよりもはるかに前の開発プロセス初期に、セキュリティとコンプライアンスの要件を確実に満たせます。本番環境でセキュリティ上の欠陥を修正する必要性が減るため、運用、品質、セキュリティエンジニアリングの各チームは、開発チームと直接連携し、設計段階で品質とセキュリティの基準を満たすための時間をより多く確保できます。
市場投入までの時間を短縮 – 依存関係を減らし、サービス間通信に一貫したフレームワークを使用することで、各チームはサービスをより効率的に構築、改善できます。一貫性のある機械可読なAPI仕様は、開発者とPlatform Opsチームの連携強化に役立つ手段の1つです。

総じて、APIファーストのアプローチを採用することで、企業はより柔軟でスケーラブルかつセキュアなマイクロサービスアーキテクチャを構築しやすくなります。

共通のAPI仕様の採用がもたらすメリット

一般的な企業のマイクロサービスおよびAPI環境では、Platform Opsチームが日常的に把握できる範囲を超える数のコンポーネントが稼働しています。標準化された機械可読なAPI仕様を導入して活用することで、チームは自社環境で現在稼働しているAPIを把握、監視し、適切な判断を下しやすくなります。

共通のAPI仕様を採用することで、API設計段階におけるステークホルダーとの連携強化にもつながります。APIコントラクトを作成し、標準仕様として正式に定義することで、APIの動作についてすべてのステークホルダーの認識を統一できます。また、再利用可能な定義や機能をチーム間で共有しやすくなります。

現在、一般的なAPI仕様は3つあり、それぞれがほとんどの種類のAPIをサポートしています。

OpenAPI – すべてのWeb APIとWebhookを記述するJSONまたはYAML
AsyncAPI – イベント駆動型APIを記述するJSONまたはYAML
JSON Schema – APIで使用されるスキーマオブジェクトを記述したJSON

現在、本番環境で使用されているAPIの大半はREST APIであり、REST APIのAPI定義を記述する標準的な方法がOpenAPI Specificationです。OpenAPI Specificationは、対象のAPIがどのように機能するかを記述した、機械可読なコントラクトを提供します。NGINXをはじめ、さまざまなAPI管理ツールやAPIゲートウェイツールがOpenAPI Specificationを幅広くサポートしています。以降では、OpenAPI Specificationを使用して、いくつかの重要なユースケースを実現する方法について説明します。

OpenAPI Specificationは、JSONまたはYAMLでAPIを定義するためのオープンソース形式です。次のシンプルなAPIの例に示すように、APIのさまざまな特性を含めることができます。この例では、シンプルなHTTP GETリクエストにより、架空の買い物リストに含まれる項目の一覧が返されます。

openapi: 3.0.0info:
  version: 1.0.0
  title: Grocery List API
  description: An example API to illustrate the OpenAPI Specification

servers:
url: https://api.example.io/v1

paths:
  /list:
    get:
      description: Returns a list of stuff on your grocery list             
      responses:
        '200':
          description: Successfully returned a list
          content:
            schema:
              type: array
              items:
                type: object
                properties:
                   item_name:
                      type: string

OpenAPI Specificationに準拠した定義は、人間にも機械にも読み取ることができます。つまり、各APIの動作を文書化する信頼できる唯一の情報源となります。これは、多数のチームがAPIを構築・運用する組織では特に重要です。もちろん、APIを大規模に管理、統制、保護するには、APIプラットフォームを構成するその他のツール（APIゲートウェイ、開発者ポータル、高度なセキュリティ）もOpenAPI Specificationをサポートしていることを確認する必要があります。

『Mastering API Architecture』の第1章では、OpenAPI Specificationを使用したREST APIの設計方法を詳しく解説しています。

共通API仕様を採用するメリット

OpenAPI Specificationなどの共通API仕様を使用すると、次のようなメリットがあります。

相互運用性の向上 – 共通の機械可読仕様により、さまざまなシステムやクライアントがAPIコントラクトを取り込み、利用できるようになります。これにより、Platform Opsチームは複雑なアーキテクチャを容易に統合、管理、監視できます。
一貫性のあるドキュメント – APIコントラクトは、エンドポイント、リクエストとレスポンスの形式、その他の関連情報を含む標準形式で文書化されます。多くのシステムでは、このコントラクトを使用して包括的なドキュメントを生成できるため、内容が明確になり、開発者がAPIの使用方法を理解しやすくなります。
テストの改善 – API仕様を使用してテストを自動的に生成・実行できるため、APIの実装がコントラクトに準拠し、想定どおりに動作していることを確認しやすくなります。これにより、APIを本番環境に公開する前に問題を特定しやすくなります。
セキュリティの向上 – 高度なセキュリティツールでは、OpenAPI Specificationを使用してAPIトラフィックとユーザーの行動を分析できます。また、APIリクエストがAPIエンドポイントでサポートされているメソッド、エンドポイント、パラメーターに準拠していることを検証し、ポジティブセキュリティ<.htmla>を適用できます。準拠していないトラフィックはデフォルトでブロックされるため、マイクロサービスが処理する必要のある呼び出しの数を削減できます。
容易な進化 – API仕様は、変更内容を機械可読形式と人間可読形式の両方で文書化し、伝達するための明確で標準的な方法を提供することで、APIコントラクトとアプリケーション自体の継続的な進化を促進します。適切なバージョニング手法と組み合わせることで、APIの変更がAPI利用者に与える影響を最小限に抑え、APIの後方互換性を維持できます。

総じて、共通のAPI仕様を使用することで、APIの相互運用性、ドキュメント作成、テスト、セキュリティ、および段階的な進化の向上に役立ちます。

NGINXがAPIファーストのソフトウェア開発を支援する仕組み

NGINXは、APIを大規模に運用、監視、ガバナンス、保護しやすくする、軽量なクラウドネイティブツール群を提供します。たとえば、API Connectivity Managerは、F5 NGINX Management Suiteの一部であり、API運用のための一元的な管理プレーンを提供します。これにより、APIゲートウェイと開発者ポータルを構成、管理できます。このツール自体もAPIファーストであり、すべての機能にREST API経由でアクセスできるため、DevOpsチームはCI/CDの自動化と統合を容易に行えます。

OpenAPI Specificationを使用すると、NGINX製品で次のことができます。

APIをAPIゲートウェイに公開
開発者ポータル向けのAPIドキュメントを生成
ポジティブセキュリティを適用してAPIエンドポイントを保護

OpenAPI Specificationを使用して、APIをAPIゲートウェイに、ドキュメントを開発者ポータルに公開し、CI/CDパイプラインまたはユーザーインターフェースを介してWAFのセキュリティポリシーを設定します

API GatewayへのAPIの公開

API Connectivity Managerは、OpenAPI Specificationを使用して、APIの公開と管理を効率化します。API開発者は、NGINX Management Suiteのユーザーインターフェースまたは完全宣言型のREST APIを使用して、APIをAPIゲートウェイに公開できます。APIはAPIプロキシとしてゲートウェイに追加されます。APIプロキシには、受信したAPIリクエストをバックエンドのマイクロサービスに転送するためにAPIゲートウェイが必要とする、すべてのイングレス、バックエンド、ルーティングの設定が含まれます。Ansibleなどのツールを使用してシンプルなCI/CD自動化スクリプトを作成すれば、REST APIを使用してAPIをコードとしてデプロイおよび管理できます。

OpenAPI Specificationを使用してAPIを公開する手順の詳細については、API Connectivity Managerのドキュメントを参照してください。

デベロッパーポータル向けAPIドキュメントの生成

ドキュメントの維持管理は、APIチームにとって悩みの種になりがちです。一方、開発者ポータルのドキュメントが古いままになっていることは、APIスプロールの顕著な兆候でもあります。API Connectivity Managerは、OpenAPI Specificationを使用してドキュメントを自動生成し、開発者ポータルに公開します。これにより、API開発者の時間を節約し、API利用者が必要な情報をいつでも見つけられるようにします。OpenAPI Specificationファイルは、API Connectivity ManagerのユーザーインターフェースまたはREST APIから直接アップロードできます。

APIドキュメントを開発者ポータルに公開する手順の詳細については、「API Connectivity Managerドキュメント」を参照してください。

ポジティブセキュリティを適用してAPIエンドポイントを保護

OpenAPI Specificationを使用して、NGINX Plus APIゲートウェイへのAPIリクエストが、そのAPIでサポートされている仕様に準拠していることを検証することもできます。ポジティブセキュリティ（許可するものを定義し、それ以外をすべてブロックするセキュリティモデル）を適用することで、悪意のあるリクエストがバックエンドサービスの潜在的な脆弱性を探るのを防止できます。

本稿執筆時点では、API Connectivity Managerを使用してNGINX App Protect WAFを設定することはできません。この機能は2023年後半に提供される予定です。ただし、Instance Manager（NGINX Management Suiteの別のモジュール）とOpenAPI Specificationを使用して、WAF用のカスタムポリシーを作成できます。詳細については、NGINX App Protect WAFおよびInstance Managerのドキュメントを参照してください。

APIセキュリティと脅威モデリング、およびAPIゲートウェイで認証と認可を適用する方法について詳しくは、『Mastering API Architecture』の第7章をご覧ください。

まとめ

マイクロサービスやアプリケーションの構築にAPIファーストのアプローチを採用すると、組織にさまざまなメリットをもたらす可能性があります。OpenAPI Specification（または人間と機械の両方が読み取れる別の共通API仕様）を軸にチーム間の足並みをそろえることで、チームを横断したコラボレーション、コミュニケーション、運用が促進されます。

最新のアプリケーションは、複雑なクラウドネイティブ環境で稼働しています。APIの運用にAPIファーストのアプローチを取り入れられるツールの導入は、APIファースト戦略の実現に向けた重要なステップです。NGINXでは、OpenAPI Specificationを使用して、分散したチームや環境全体のAPIを大規模に管理できます。

Start a NGINX Management Suiteの30日間無料トライアルを開始してください。このトライアルでは、API Connectivity Manager、APIゲートウェイとしてのNGINX Plus、およびAPIを保護するためのNGINX App Protectをご利用いただけます。