API Connectivity Managerに関する全2回シリーズの第1回です：
- APIの無秩序な増加に対処する5つの方法（対処すべき理由） – 本記事
- API開発者エクスペリエンスが重要な理由
APIは現代のインターネットをつなぐ結合組織であり、エッジからクラウドやオンプレミスのデータセンターまで、データを連携させます。F5の「2021年版アプリケーション戦略の現状レポート」によると、組織がモダナイゼーションに用いるさまざまな手法の中で、APIの活用が最も一般的です。
- 58%の組織が、最新のユーザーインターフェースを実現するためにAPIレイヤーを追加しています
- 51%がモダンアプリケーションのコンポーネント（Kubernetesなど）を追加しています
- 47%がリファクタリング（アプリケーションコード自体の変更）を行っています
- 40%は、モダナイゼーションを行わずにパブリッククラウドへ移行（リフト＆シフト）しています
API主導の経済では、APIには100%の信頼性が求められます。しかし、ビジネスやアプリケーションの規模が拡大するにつれて、運用の複雑さも増大します。クラウドネイティブアプリケーションは、設計上、分散化と非集中化が進んでおり、クラウド、オンプレミス、エッジ環境に展開された数十、数百、さらには数千ものAPIで構成されています。
F5のOffice of the CTOによる最近の調査では、デジタルトランスフォーメーションに取り組む企業にとって、「継続的なAPIスプロール」が重大な脅威であることが明らかになりました。では、これは何を意味するのでしょうか。
APIスプロールとは
APIスプロールとは、組織がデジタルトランスフォーメーションを進める中で生じる、相互に関連した2つの課題を指します。API数の急激な増加と、複数のアーキテクチャやチームにまたがるAPIの物理的な分散です。
APIスプロールを引き起こす4つの主な要因は次のとおりです。
- ハイブリッドインフラストラクチャ – 現在、企業の81%が3つ以上のアーキテクチャにまたがって運用しています。これには、パブリッククラウド、オンプレミスのデータセンター、エッジインフラストラクチャが含まれます。
- マイクロサービスアーキテクチャ – マイクロサービスアーキテクチャの採用が拡大し、新しいサービスが稼働するにつれて、APIエンドポイントが急増しています。
- 継続的なソフトウェアデプロイ – 開発者は短期間で数十ものAPI、または単一APIの多数のバージョンを次々と作成できます。
- 放棄されたAPI – 開発者は、別のプロジェクトのサポートや作業に移ると、自ら作成したAPIの管理と保守を行わなくなります。
APIの無秩序な増加は重大な脅威
多くの企業は、APIスプロールが重大な問題であることをまだ認識していません。しかし、実際には重大な問題です。APIスプロールの根本原因を理解し、対処する組織こそが、今後10年にわたって成長を遂げるでしょう。
APIスプロールは、企業に運用面とセキュリティ面で重大な課題をもたらします。複数のチームや環境にまたがってAPIエンドポイントが増加するにつれ、APIのセキュリティ確保とガバナンスは極めて困難になります。APIスプロールは、開発者の生産性低下、手戻りの増加、レビューの遅延といった隠れたコストを企業にもたらすことが多く、手遅れになるまで容易に把握できません。
APIスプロールがもたらす主な課題は次のとおりです。
- 可視性の欠如 – ハイブリッドアーキテクチャでは、APIトラフィックと構成を一元的に把握することが極めて困難です
- 信頼できる一元的な情報源が不明確 – 開発者はAPIや最新のドキュメントを見つけるのに苦労しています
- 信頼性の低下 – 設定ミスが増え、サービス停止につながります
- セキュリティ脅威の増大 – セキュリティで保護されていないAPIエンドポイントは、攻撃の標的になりやすくなります
APIの無秩序な増加にどう対処するか
レジリエントなAPIインフラストラクチャを構築するための第一歩は、継続的なAPIオーナーシップと一元化されたAPIまたはサービスカタログに関するベストプラクティスを取り入れた包括的なAPI戦略によって、APIの乱立を把握し、管理することです。次に、APIガバナンスを適用し、実用的かつスケーラブルな方法でAPIライフサイクル管理を効率化します。
NGINXでは、API管理の複雑さを軽減するために、管理プレーンソリューションを構築しました。API Connectivity Managerは、F5 NGINX Management Suiteの一部であり、APIの場所や開発者を問わず、APIの接続、ガバナンス、セキュリティ確保を単一のインターフェースで実現します。
API Connectivity Managerは、APIの無秩序な増加を抑え、大規模に管理するうえで重要な5つの戦術の実行を支援します。
戦術1：APIガバナンス戦略を導入する
管理と制御を一元化することで、単一のアーキテクチャまたはクラスター内にあるAPIの検出、接続、保護が容易になります。APIの無秩序な増加に対応するには、純粋な階層型モデルから、分散型で自律的にスケールするモデルへと発想を転換する必要があります。
NGINXによる支援 – API Connectivity Managerを使用すると、グローバルポリシーときめ細かな制御のバランスを取り、API所有者がローカルポリシーを管理できる柔軟なガバナンスモデルを実装できます。これにより、セキュリティとコンプライアンスに対する一貫した監督を損なうことなく、市場投入までの時間を短縮できます。
プラットフォームチームとインフラストラクチャチームは、ロギング、エラーレスポンスコード、TLS構成などに関するグローバルポリシーを使用して、企業全体でAPIの一貫性を確保できます。APIを構築、管理する開発者は、レート制限、認証、認可など、サービスレベルのポリシーを引き続き管理できます。
戦術2：APIディスカバリのための信頼できる唯一の情報源を構築
APIの数が増え、アプリが複雑化するにつれて、利用可能なAPIとその所在を把握し、追跡することが非常に難しくなります。APIが特定のマイクロサービスのインフラストラクチャ内に隠れていて登録されていない場合、他のマイクロサービスを担当するチームは、そのAPIを見つけて自分たちのプロジェクトに統合できません。
NGINXによる支援 – API Connectivity Managerを使用すると、開発者がAPIを見つけて利用できるサービスカタログとAPIポータルを作成できます。優れた開発者ポータルでは、利用可能なAPIとその使用方法に関する情報を一元的に提供し、認証情報を生成するためのツールも用意することで、APIの利用を促進します。
戦術3：適切なバージョン管理とドキュメント整備を徹底する
APIポータルは、最初の一歩として有効です。しかし、開発サイクル中にAPI仕様が変更されると、問題が生じます。APIを呼び出すリモートサービスも変更する必要があるためです。すべてのマイクロサービスを同じチームが同じアプリケーション向けに設計している場合は、このアプローチでも対応できる可能性がありますが、第三者による利用を目的としてAPIを公開する場合には適していません。
同時に、ドキュメントの維持管理は開発者にとって悩みの種です。当初は活発に更新されても、APIポータルはやがて放置され、サポートされていないAPIや古いドキュメントばかりのゴーストタウンと化すことが少なくありません。その結果、関係者やAPIユーザーは必要な情報を見つけられず、苛立ちを募らせることになります。
NGINXによる支援 – API Connectivity Managerを使用すると、APIの公開とドキュメント作成をAPI開発者向けのシームレスなワークフローに統合できます。API所有者は、OpenAPI Specificationを使用してAPIの公開とドキュメントの生成を同時に行えるため、時間を節約し、すべてのユーザーが常に最新のドキュメントを利用できるようになります。
戦術4：APIトラフィックのメトリクスと可視性を提供
APIがどこに配置され、どのように構成されているかを把握することは、企業が直面する最も大きな課題の1つです。環境を横断してAPIトラフィックを一貫して可視化できなければ、パフォーマンス上の問題やセキュリティ脅威を特定することは極めて困難であり、場合によっては不可能です。
NGINXによる支援 – API Connectivity Managerを使用すると、ベストプラクティスの適用とパフォーマンスおよび信頼性の確保に役立つ重要な指標へアクセスできる、単一のプラットフォームを構築できます。インフラストラクチャの所有者は、APIトラフィックと構成を監視し、標準化されたログ形式を適用して、任意の監視ソリューションにデータをエクスポートできます。
戦術5：APIセキュリティを大規模に適用
2020年には、90%を超える企業がAPIセキュリティインシデントを経験しました。新たなAPIエンドポイントが稼働するたびに、組織の攻撃対象領域は拡大します。大規模な環境では、セキュリティを付加機能として扱うことはできません。仕様策定からコーディング、デプロイまで、ライフサイクル全体に組み込む必要があります。
NGINXによる支援 – API Connectivity Managerでは、APIセキュリティの2つの主要コンポーネントであるAPIアクセス制御とAPI保護を使用して、APIを保護できます。JSON Web Token（JWT）、APIキー、またはOAuth2/OpenID Connectで認証と認可を管理し、APIアクセス制御を適用できます。今後数か月以内に、API Connectivity ManagerはNGINX App Protect WAFのサポートを追加する予定です。これにより、OWASP API Security Top 10、スキーマ検証などを標準でサポートし、APIゲートウェイを保護して、一般的な脅威や高度な脅威に対処できるようになります。
API Connectivity Managerで市場投入までの時間を短縮
APIのスプロールがもたらす課題を解決することで、複数のアーキテクチャが混在する複雑さを競争優位性へと変えられます。API Connectivity Managerは、開発者に必要なスピードと柔軟性を確保しながら、大規模なガバナンスを支えるレジリエントなAPIエコシステムの構築を支援します。
次回の記事では、API開発者エクスペリエンスを掘り下げ、CI/CD統合、セルフサービスワークフロー、APIライフサイクル管理などのトピックについて解説します。
始める
Start a API Connectivity Managerとを含むNGINX Management Suiteの30日間無料トライアルInstance Managerを開始してください。
関連リソース
- ブログ：F5 NGINX Management SuiteでアプリとAPIを接続、拡張、保護
- ソリューション概要：NGINX Management Suite API Connectivity Manager
著者について
関連するブログ記事
チュートリアル：NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。
AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。
JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。
F5 NGINXaaS for Azureのご紹介：Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト＆シフトできるため、クラウド導入とモダンアプリの展開を加速できます。
SELinuxでNGINXおよびNGINX Plusを使用する
Red Hat Enterprise Linux（RHEL）および関連ディストリビューションでSecurity-Enhanced Linux（SELinux）を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。
NGINX PlusによるAWS Auto Scalingグループの負荷分散
新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります