APIは、クラウドネイティブアプリケーションの結合組織であり、アプリケーションのコンポーネントであるマイクロサービスが通信するための手段です。アプリケーションが成長および拡張すると、マイクロサービスやAPIの数も増えます。これは、ほとんどの場合、避けられない結果であり、最新アプリケーションの信頼性、スケーラビリティおよびセキュリティの確保を担当するPlatform Opsチームに対して大きな課題をもたらします。私たちはこの問題をAPIスプロールと呼び、以前のブログ記事でも触れています。
APIスプロールを解決しようとする組織が最初にすることは、APIの検出と修正の自動化のためのツールを実装してトップダウンのアプローチを試みることかもしれません。これは、短期的には効果的ですが、多くの場合、APIやマイクロサービスの構築と運用を担当するチームに過度の負担を強いることになります。これらのチームは、セキュリティとコンプライアンスの問題に対処するために、既存のマイクロサービスやAPIを作り直すか、あるいは必要な承認を得るために困難なレビュープロセスを実施しなければなりません。そのため、多くの大規模なソフトウェア組織は、適応型ガバナンスを使用する分散型アプローチを採用して、開発者に必要な自律性を与えています。
土壇場で安全策を講じるよりも、ボトムアップのアプローチで問題に取り組む方が、長期的には効果的です。さまざまなマイクロサービスやアプリケーションのAPIを構築および運用するチームが必ず参加して、多くの場合、組織内のソフトウェア開発にAPIファーストのアプローチを採用することから始めます。
APIファーストとは
APIは何10年も前から存在しています。しかし、APIはもはや単なる「アプリケーションプログラミングインターフェイス」ではありません。APIの本質は、開発者インターフェイスです。他のユーザーインターフェイスと同様、APIにも計画、設計およびテストが必要です。APIファーストとは、APIを運用および使用するすべてのチームで接続性とシンプルさの重要性を認識し、それを優先することです。ほとんどの場合は開発者ですが、APIコンシューマにとってのコミュニケーション、再利用性および機能性が優先されます。
APIファーストへの道はたくさんありますが、APIファーストを目指すほとんどの企業にとっての最終目標は、設計主導によるソフトウェア開発アプローチです。実際、このアプローチは、実装前にAPIが完全に定義されていることを意味します。作業は、APIがどのように機能するかを設計および文書化することから始まります。チームは、一般的にAPIコントラクトと呼ばれる結果の成果物を頼りに、アプリケーションの機能をどのように実装するかを知らせます。
耐久性と柔軟性を兼ね備えたソフトウェア開発へのAPIファーストアプローチをサポートする設計技法については、NGINX提供のO’ReillyのeBook『Mastering API Architecture(APIアーキテクチャについて学ぶ)』の第1章をご覧ください。
組織におけるAPIファーストの価値
APIファースト戦略は、多くの場合、マイクロサービスアーキテクチャに理想的です。その理由は、アプリケーションエコシステムをモジュール式の再利用可能なシステムとして開始できるためです。APIファーストのソフトウェア開発モデルを採用することで、開発者と組織の双方に以下のような大きなメリットをもたらします。
- 開発者の生産性の向上 – 開発チームは、並行して作業できるので、アプリケーションのAPIに依存する他のマイクロサービスで作業するチームに影響を与えることなく、バックエンドアプリケーションを更新できます。すべてのチームが確立されたAPIコントラクトを参照できるため、多くの場合、APIライフサイクル全体でコラボレーションが簡単になります。
- 開発者エクスペリエンスの向上 – PIファーストの設計では、APIが論理的であり適切に文書化されていることを保証することで、開発者エクスペリエンスを優先します。これにより、APIを使用する開発者にシームレスなエクスペリエンスが提供されます。Platform OpsチームがAPI開発者エクスペリエンスを考慮することが重要な理由は、以下のとおりです。
- 一貫したガバナンスとセキュリティ – クラウドとプラットフォームの設計者は、セキュリティとガバナンスのルールをAPIの設計段階で組み込むことによって、APIエコシステムを一貫した方法で組織化できます。これにより、ソフトウェアプロセスの後半で問題が発見された場合に必要となる、コストのかかるレビューを回避できます。
- ソフトウェア品質の向上 – APIを最初に設計することで、開発プロセスの初期段階、つまりAPIが本番環境に導入される前に、セキュリティとコンプライアンスの要件を満たすことができます。本番環境でのセキュリティ問題を修正する必要が少なくなることで、運用、品質およびセキュリティのエンジニアリングチームは、より時間をかけて開発チームと直接連携して、設計段階で品質とセキュリティの標準が満たされていることを確認できます。
- 市場投入までの時間の短縮 – 依存関係を少なくして、サービス間通信のためのフレームワークを一貫させることで、異なるチームがより効率的にサービスを構築および改善できます。一貫性のある機械判読可能なAPI仕様は、開発者とPlatform Opsのチームの連携を効率化できるツールの1つです。
全体として、APIファーストのアプローチを採用することは、企業がより柔軟で、スケーラブルかつ安全なマイクロサービスアーキテクチャを構築するために役立ちます。
API共通仕様の採用は何に役立つか
一般的な企業のマイクロサービスやAPI環境では、Platform Opsチームが通常では把握しきれないほどのコンポーネントが使用されています。標準の機械判読可能なAPI仕様を受け入れ、採用することで、チームはその環境で現在稼働しているAPIを理解および監視して、意思決定することができます。
また、API共通仕様を採用することで、APIの設計段階での利害関係者との連携を改善できます。APIコントラクトを作成し、それを標準仕様に形式化することで、すべての利害関係者が、APIがどのように機能するかについて共通の認識を持つことができます。また、再利用可能な定義や機能をチーム間で共有しやすくなります。
現在、以下の3つのAPI共通仕様があり、それぞれがほとんどの種類のAPIをサポートしています。
- OpenAPI – すべてのWeb APIとWebhooksのJSONまたはYAML記述
- AsyncAPI – イベント駆動型APIのJSONまたはYAML記述
- JSON Schema – APIに使用されるスキーマオブジェクトのJSON記述
REST APIは現在の本番環境にあるAPIの大部分を構成しています。OpenAPI仕様は、REST APIのAPI定義を記述するための標準的な方法であり、特定のAPIがどのように機能するかを記述する、機械判読可能なAPIコントラクトを提供します。OpenAPI仕様は、NGINXを含むさまざまなAPI管理およびAPIゲートウェイツールにより広くサポートされています。このブログではここから、いくつかの重要なユースケースを達成するためにOpenAPI仕様をどのように使用できるかに焦点を当てます。
OpenAPI仕様は、JSONまたはYAMLでAPIを定義するためのオープンソースフォーマットです。以下の簡単なAPIの例で説明するように、幅広いAPI特性を含めることができます。この単純なHTTP GETリクエストは、架空の食料品リストの品目一覧を返します。
openapi: 3.0.0
info:
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: stringOpenAPI仕様に従った定義は、人間でも機械でも判読可能です。これは、各APIがどのように機能するかを文書化した単一の信頼できる情報源があることを意味していて、このことは、多くのチームでAPIを構築および運用する組織では特に重要です。もちろん、APIを大規模に管理、統制および保護するためには、APIゲートウェイ、開発者ポータル、高度なセキュリティなど、APIプラットフォームの残りのツールもOpenAPI仕様に対応している必要があります。
『Mastering API Architecture(APIアーキテクチャについて学ぶ)』の第1章では、OpenAPI仕様を使ってREST APIを設計する方法について詳しく説明しています。
API共通仕様の採用によるメリット
OpenAPI仕様のようなAPI共通仕様を採用することには、以下のようないくつかのメリットがあります。
- 相互運用性の向上 – 共通の機械判読可能な仕様により、異なるシステムやクライアントでもAPIコントラクトを利用できます。これにより、Platform Opsチームは、複雑なアーキテクチャの統合、管理および監視を簡単に行うことができます。
- 一貫したドキュメント – APIコントラクトは、エンドポイント、リクエストとレスポンスのフォーマット、その他の関連する詳細を含む標準フォーマットで文書化されています。多くのシステムは、APIコントラクトを使用して包括的なドキュメントを生成することで、APIの使用方法が明確になり、開発者はこれを理解しやすくなります。
- テストの効率化 – API仕様は自動的にテストを生成および実行するために使用できるので、API実装がAPIコントラクトに準拠し、期待通りに動作していることを確認しやすくなります。これは、APIが本番環境に公開される前に、APIの問題を特定するときにも役立ちます。
- セキュリティの強化 – 高度なセキュリティツールは、OpenAPI仕様を使用して、APIトラフィックとユーザー行動を分析できます。また、APIリクエストがAPIエンドポイントによってサポートされるメソッド、エンドポイント、パラメータに準拠していることを検証することで、ポジティブセキュリティを適用できます。準拠しないトラフィックはデフォルトでブロックされるので、マイクロサービスが処理しなければならないコール数が減ります。
- より簡単な進化 – API仕様は、機械と人間の両方が判読できるフォーマットで変更を文書化して伝えるための明確で標準的な方法を提供することで、APIコントラクトとアプリケーション自体の漸進的な進化を促進します。さらに、適切なバージョニングと組み合わせることで、APIの変更がAPIコンシューマに与える影響を最小限に抑え、APIの後方互換性を保証するときにも役立ちます。
全体として、API共通仕様を使うことは、APIの相互運用性、文書化、テスト、セキュリティ、そして漸進的な進化の改善に役立ちます。
NGINXがAPIファーストのソフトウェア開発をサポートする方法
NGINXは、APIの大規模な運用、監視、統制、保護を簡単にする軽量のクラウドネイティブツールセットを提供します。たとえば、F5 NGINX Management Suiteの一部であるAPI Connectivity Managerは、API運用の一元管理機能を提供します。これにより、APIゲートウェイや開発者ポータルを構成および管理できます。すべての機能は、APIファーストのツール自体であるため、REST API経由でアクセスでき、DevOpsチームのCI/CDの自動化と統合が簡単になります。
OpenAPI仕様により、NGINX製品を使用して次のことが可能になります。
APIゲートウェイへのAPIの公開
API Connectivity Managerは、OpenAPI仕様を使用してAPIの公開と管理を合理化します。API開発者は、NGINX Management Suiteのユーザーインターフェイスまたは完全宣言型のREST APIのいずれかを使用して、APIゲートウェイにAPIを公開できます。APIは、APIプロキシとしてゲートウェイに追加されます。APIプロキシは、APIゲートウェイが受信APIリクエストをバックエンドのマイクロサービスに送るために必要なすべてのイングレス、バックエンドおよびルーティングの設定を含みます。REST APIを使用して、Ansibleなどのツールで簡単なCI/CD自動化スクリプトを作成することで、APIをコードとして導入および管理できます。
OpenAPI仕様を使用してAPIを公開する完全な手順については、API Connectivity Managerのドキュメントを参照してください。
開発者ポータル用のAPIドキュメントの生成
ドキュメントの保守は、APIチームの悩みの種となることがよくあります。しかし、開発者ポータル上の古くなったドキュメントは、APIスプロールの主要な症状でもあります。API Connectivity Managerは、OpenAPI仕様を使用して自動的にドキュメントを生成し、開発者ポータルに公開することで、API開発者の時間を節約し、APIコンシューマが必要なものを必ず発見できるようにします。OpenAPI仕様のファイルは、API Connectivity ManagerのユーザーインターフェイスまたはREST APIを介して直接アップロードできます。
APIドキュメントを開発者ポータルに公開する完全な手順については、API Connectivity Managerのドキュメントを参照してください。
ポジティブセキュリティの適用によるAPIエンドポイントの保護
OpenAPI仕様を使用して、NGINX Plus APIゲートウェイへのAPIリクエストがAPIのサポート内容に準拠していることを確認することもできます。ポジティブセキュリティ（許可するものを定義し、それ以外をブロックするセキュリティモデル）を適用することで、悪意のあるリクエストがバックエンドサービスの潜在的な脆弱性を調査できないように防ぐことができます。
この記事の作成時点では、API Connectivity Managerを使用してNGINX App Protect WAFを設定することはできませんが、この機能は2023年後半に利用可能となる予定です。しかし、Instance Manager（別のNGINX Management Suiteモジュール）とOpenAPI仕様を使用して、WAFのカスタムポリシーを記述することができます。詳しくは、NGINX App Protect WAFおよびInstance Managerのドキュメントを参照してください。
APIセキュリティと脅威のモデル化、およびAPIゲートウェイで認証と認可を適用する方法については、『Mastering API Architecture(APIアーキテクチャについて学ぶ)』の第7章で詳しく説明されています。
まとめ
マイクロサービスやアプリケーションを構築するためのAPIファーストのアプローチは、多くの点で組織のメリットとなります。チームでOpenAPI仕様（または人間でも機械でも判読できる他のAPI共通仕様）を共有することで、チーム間のコラボレーション、コミュニケーション、運用が簡単になります。
最新アプリケーションは、複雑なクラウドネイティブ環境で動作しています。API運用におけるAPIファーストのアプローチを可能にするツールを採用することは、APIファースト戦略を実現するための重要なステップです。NGINXでは、OpenAPI仕様を使用することで、分散したチームや環境全体でAPIを大規模に管理できます。
NGINX Management Suiteの30日間無料トライアルを今すぐ始めましょう。API Connectivity Manager、APIゲートウェイとしてのNGINX Plus、APIを保護するNGINX App Protectを利用できます。
