マイクロサービス構築における API ファースト アプローチの利点
API はクラウド ネイティブ アプリケーションの結合組織であり、アプリケーションのコンポーネント マイクロサービスが通信する手段です。 アプリケーションが成長し、拡張するにつれて、マイクロサービスと API の数も増加します。 これはほとんどの場合避けられない結果ですが、最新のアプリケーションの信頼性、スケーラビリティ、セキュリティの確保を担当するプラットフォーム運用チームにとっては大きな課題となります。 私たちはこの問題を「API スプロール」と呼んでおり、以前のブログ投稿でこれについて書きました。
API の拡散を解決するための最初の試みとして、組織は、自動化された API 検出および修復のためのツールを実装することで、トップダウン アプローチを試みる場合があります。 これは短期的には効果的ですが、API とマイクロサービスの構築と運用を担当するチームに過度の負担をかけることがよくあります。 セキュリティとコンプライアンスの問題に対処するために、既存のマイクロサービスと API を作り直すか、必要な承認を得るために困難なレビュー プロセスを経る必要があります。 このため、多くの大規模ソフトウェア組織は、適応型ガバナンスを使用して開発者に必要な自律性を与える分散型アプローチを採用しています。
土壇場で安全策を講じるよりも、問題に対するボトムアップのアプローチの方が長期的には効果的です。 さまざまなマイクロサービスやアプリケーション用の API を構築および運用するチームが最初に関与し、多くの場合、組織内のソフトウェア開発にAPI ファーストのアプローチを採用することから始めます。
API ファーストとは何ですか?
API は何十年も前から存在しています。 しかし、それらはもはや単なる「アプリケーション プログラミング インターフェイス」ではありません。 本質的に、API は開発者インターフェースです。 他のユーザー インターフェイスと同様に、API には計画、設計、テストが必要です。 API ファーストとは、API を運用および使用するすべてのチームにわたって接続性とシンプルさの重要性を認識し、優先順位を付けることです。 ほとんどの場合は開発者である API 消費者のコミュニケーション、再利用性、機能性を優先します。
API ファーストへの道は数多くありますが、API ファーストの取り組みに乗り出すほとんどの企業にとって、ソフトウェア開発に対する設計主導のアプローチが最終目標となります。 実際には、このアプローチは、実装前に API が完全に定義されることを意味します。 作業は、API がどのように機能するかを設計し、文書化することから始まります。 チームは、結果として得られる成果物（多くの場合、 API 契約と呼ばれる）に基づいて、アプリケーションの機能をどのように実装するかを決定します。
NGINX 提供の O'Reilly の電子書籍『 Mastering API Architecture』の第 1 章で、耐久性と柔軟性を兼ね備えたソフトウェア開発への API ファースト アプローチをサポートするための設計手法について説明します。
組織にとっての API ファーストの価値
API ファースト戦略は、アプリケーション エコシステムがモジュール式の再利用可能なシステムとして開始されることを保証するため、マイクロサービス アーキテクチャに最適です。 API ファーストのソフトウェア開発モデルを採用すると、開発者と組織の両方に次のような大きなメリットがもたらされます。
- 開発者の生産性の向上- 開発チームは並行して作業できるため、アプリケーションの API に依存する他のマイクロサービスで作業しているチームに影響を与えることなく、バックエンド アプリケーションを更新できます。 すべてのチームが確立された API 契約を参照できるため、API ライフサイクル全体でのコラボレーションが容易になることがよくあります。
- 開発者エクスペリエンスの強化- API ファースト設計では、API が論理的で適切に文書化されていることを保証することで、開発者エクスペリエンスを優先します。 これにより、開発者が API を操作するときにシームレスなエクスペリエンスが実現します。プラットフォーム運用チームがAPI 開発者エクスペリエンスを考慮することが非常に重要である理由について説明します<.htmla>。
- 一貫したガバナンスとセキュリティ- クラウドおよびプラットフォーム アーキテクトは、API 設計フェーズでセキュリティとガバナンスのルールを組み込むことで、API エコシステムを一貫した方法で整理できます。 これにより、ソフトウェア プロセスの後半で問題が発見されたときに必要となるコストのかかるレビューを回避できます。
- ソフトウェア品質の向上– 最初に API を設計することで、API を本番環境に展開する準備ができるかなり前に、開発プロセスの早い段階でセキュリティとコンプライアンスの要件が満たされることが保証されます。 運用環境でセキュリティ上の欠陥を修正する必要性が減るため、運用、品質、セキュリティ エンジニアリング チームは開発チームと直接連携して、設計段階で品質とセキュリティの基準が満たされていることを確認する時間が増えます。
- 市場投入までの時間の短縮- 依存関係が少なくなり、サービス間通信のフレームワークが一貫性を持つため、さまざまなチームがより効率的にサービスを構築および改善できます。 一貫性があり、機械可読な API 仕様は、開発者とプラットフォーム運用チームがより効率的に連携するのに役立つツールの 1 つです。
全体として、API ファーストのアプローチを採用することで、企業はより柔軟でスケーラブルかつ安全なマイクロサービス アーキテクチャを構築できるようになります。
共通API仕様の採用がどのように役立つか
一般的なエンタープライズ マイクロサービスおよび API 環境では、プラットフォーム運用チームが日々追跡できる以上のコンポーネントが稼働しています。 標準の機械可読 API 仕様を採用することで、チームは環境内で現在動作している API を理解し、監視し、意思決定を行うことができます。
共通の API 仕様を採用すると、API 設計フェーズでの関係者とのコラボレーションの改善にも役立ちます。 API 契約を作成し、それを標準仕様として正式に定めることで、API がどのように機能するかについてすべての関係者が共通の認識を持つことができます。 また、再利用可能な定義と機能をチーム間で共有することも容易になります。
現在、3 つの一般的な API 仕様があり、それぞれがほとんどの種類の API をサポートしています。
- OpenAPI – すべてのウェブ API とウェブフックの JSON または YAML 記述
- AsyncAPI – イベント駆動型 API の JSON または YAML 記述
- JSON スキーマ– API に使用されるスキーマ オブジェクトの JSON 記述
REST API は現在運用中の API の大部分を占めており、OpenAPI 仕様は REST API の API 定義を記述する標準的な方法です。OpenAPI 仕様は、特定の API がどのように機能するかを記述する機械可読な契約を提供します。 OpenAPI 仕様は、NGINX を含むさまざまな API 管理および API ゲートウェイ ツールで広くサポートされています。このブログの残りの部分では、OpenAPI 仕様を使用していくつかの重要なユースケースを実現する方法に焦点を当てます。
OpenAPI 仕様は、JSON または YAML で API を定義するためのオープン ソース形式です。 次の簡単な API の例に示すように、幅広い API 特性を含めることができます。 ここでは、単純な HTTP GETリクエストが、架空の食料品リストにあるアイテムのリストを返します。
オープンAPI: 3.0.0情報:
バージョン: 1.0.0
タイトル: 食料品リスト API
説明: OpenAPI 仕様を説明するサンプル API
サーバー:
url: https://api.example.io/v1
パス:
/list:
get:
説明: 買い物リストにあるもののリストを返します
応答:
'200':
説明: リストが正常に返されました
コンテンツ:
スキーマ:
タイプ: 配列
項目:
タイプ: オブジェクト
プロパティ:
item_name:
タイプ: 文字列
OpenAPI 仕様に準拠した定義は、人間と機械の両方が判読可能です。 つまり、各 API がどのように機能するかを文書化した単一の真実のソースが存在することを意味し、これは API を構築および運用するチームが多数ある組織では特に重要です。 もちろん、API を大規模に管理、統制、保護するには、API プラットフォーム内の他のツール (API ゲートウェイ、開発者ポータル、高度なセキュリティ) も OpenAPI 仕様をサポートしていることを確認する必要があります。
Mastering API Architectureの第 1 章では、OpenAPI 仕様を使用して REST API を設計する方法について詳しく説明します。
共通API仕様を採用するメリット
OpenAPI 仕様などの共通 API 仕様を使用すると、次のようないくつかの利点があります。
- 相互運用性の向上- 共通の機械可読仕様により、さまざまなシステムやクライアントが API 契約を消費して使用できるようになります。 これにより、プラットフォーム運用チームは複雑なアーキテクチャをより簡単に統合、管理、監視できるようになります。
- 一貫したドキュメント- API 契約は、エンドポイント、リクエストとレスポンスの形式、その他の関連する詳細を含む標準形式で文書化されます。 多くのシステムでは、契約を使用して包括的なドキュメントを生成し、明確性を提供し、開発者が API の使用方法を理解しやすくすることができます。
- より優れたテスト– API 仕様を使用してテストを自動的に生成および実行できるため、API 実装が契約に準拠し、期待どおりに動作していることを確認できます。 これにより、API を本番環境に公開する前に問題を特定できるようになります。
- セキュリティの強化- 高度なセキュリティ ツールは OpenAPI 仕様を使用して API トラフィックとユーザーの動作を分析できます。 API リクエストが API エンドポイントでサポートされているメソッド、エンドポイント、およびパラメータに準拠していることを確認することで、ポジティブ セキュリティ<.htmla> を適用できます。 不適合なトラフィックはデフォルトでブロックされるため、マイクロサービスが処理する必要がある呼び出しの数が削減されます。
- より容易な進化– 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 ゲートウェイが必要とするすべてのイングレス、バックエンド、およびルーティング構成が含まれています。 Ansible などのツールを使用して簡単な CI/CD 自動化スクリプトを作成することにより、REST API を使用して API をコードとしてデプロイおよび管理できます。
OpenAPI 仕様を使用して API を公開する方法の詳細については、 API Connectivity Manager のドキュメントを参照してください。
開発者ポータル用のAPIドキュメントを生成する
ドキュメントの維持は、API チームにとって頭痛の種となることがよくあります。 しかし、開発者ポータル上の古いドキュメントも、API の無秩序な増加の大きな兆候です。 API Connectivity Manager は OpenAPI 仕様を使用してドキュメントを自動的に生成し、開発者ポータルに公開します。これにより、API 開発者の時間が節約され、API コンシューマーが常に必要なものを見つけられるようになります。 API 接続マネージャー ユーザー インターフェースまたは REST API を介して、OpenAPI 仕様ファイルを直接アップロードできます。
開発者ポータルに 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およびインスタンス マネージャーのドキュメントを参照してください。
API セキュリティと脅威モデリング、および API ゲートウェイで認証と承認を適用する方法の詳細については、 『Mastering API Architecture 』の第 7 章を参照してください。
まとめ
マイクロサービスとアプリケーションを構築するための API ファーストのアプローチは、組織にさまざまなメリットをもたらします。 OpenAPI 仕様 (または人間と機械の両方が判読可能な他の共通 API 仕様) に沿ってチームを調整することで、チーム間でのコラボレーション、コミュニケーション、運用が可能になります。
最新のアプリケーションは、複雑なクラウドネイティブ環境で動作します。 API を運用するための API ファースト アプローチを可能にするツールを導入することは、API ファースト戦略を実現するための重要なステップです。 NGINX を使用すると、OpenAPI 仕様を使用して、分散したチームや環境全体で API を大規模に管理できます。
NGINX Management Suite の 30 日間無料トライアルを開始します。これには、 API Connectivity Manager 、API ゲートウェイとしてのNGINX Plus 、API を保護するNGINX App Protectへのアクセスが含まれます。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"