社内API管理のベストプラクティス

NGINX | 2020年9月02日

Karthik Krishnaswamyプロダクトマーケティング担当ディレクター | F5

一部の消費者向けAPIは広く普及し、Google MapsやStripeのように誰もが知る存在となっています。しかし、APIエコノミーを真に支えているのは社内APIです。

内部API（ここでは、組織内のクライアントと開発者にのみ公開されるAPIを指します）は、企業のデジタルトランスフォーメーションの取り組みを支える重要な柱です。内部APIの構築は通常、デジタル製品やサービスを開発するための第一歩となります。実際、IDCが最近実施した調査「API：デジタルビジネスの成否を分ける決定要因」によると、アプリケーションと製品の内部統合を支援することは、企業におけるAPI開発の取り組みで最優先事項の1つです。

内部APIが重要なのはなぜでしょうか。内部APIにはどのようなメリットがあるのでしょうか。そして何より、内部APIの管理に最適なアーキテクチャとは何でしょうか。このブログでは、これらの疑問に答え、内部APIをセキュアかつ大規模に提供するためのヒントをご紹介します。

内部APIが重要な理由

内部APIは、組織内に分散するバックエンドシステムを事業部門（LOB）内の他の開発者が利用できるようにすることで、データサイロを解消し、システム間の橋渡しをします。たとえば、製造業のマーケティング部門では、適切な市場セグメントをターゲットとして収益を最大化するために、特定の製品やモデルを値引きすべきか判断できるよう、サプライチェーン部門が使用するシステムの情報を把握する必要がある場合があります。

内部APIはどのようにサイロを解消するのでしょうか。HTMLやJSONなどの標準形式によるデータ交換をサポートする共通インターフェースを提供します。APIは構築だけでなく利用も容易かつ迅速です。これは、独自仕様のデータベースコネクターや難解なデータ交換プロトコルを使用してデータリポジトリから情報を取得する方法とは対照的です。APIはこうした障壁を減らすことで、生産性を大幅に向上させます。これらのAPIは、外部の開発者や第三者には公開されません。内部APIのトラフィックは組織内、つまり企業ファイアウォール内にとどまります。

内部APIのメリット

内部APIは、市場投入までの時間を短縮し、ソフトウェア開発にかかる時間とコストを削減します。ここでは、そのメリットを詳しく見ていきます。

運用効率

内部APIは、ビジネスのさまざまな部門を連携するための使いやすい抽象化レイヤーを提供し、変化する要件に柔軟に対応できるようにします。各事業部門（LOB）のアプリケーションごとにサイロ化された技術スタックを構築する代わりに、組織全体の開発者が共通の内部API群を利用してデータにアクセスできます。これにより、重複を排除してソフトウェア開発時間を短縮し、開発者とIT部門の生産性を向上させます。

System of Recordの開発

内部APIは、組織内の主要なデータ要素について信頼できる情報源となるシステム・オブ・レコードの構築を促進します。データの整合性を確保するには、特定の情報に対するシステム・オブ・レコードは1つだけでなければなりません。各LOBが独自のデータや、わずかに異なるバージョンのデータを保持していると、不一致や混乱が生じます。内部APIは、この信頼できる唯一の情報源に効率的にアクセスするための仕組みです。

コスト削減

効率化によってコストを削減できます。各LOB内で大幅なカスタマイズを施した独自プラットフォームを構築する必要はありません。また、実質的にポイントツールにすぎない高価なコネクターや統合機能を構築または購入する必要もありません。

一例として、エストニア政府は、すべての政府機関をシームレスに接続するデータ交換プラットフォーム「X‑Road」を運用しています。エストニア国民は運転免許証を携帯する必要さえありません。人口登録簿と車両登録簿は別々のデータリポジトリですが、免許情報を両者から迅速に取得できるためです。この世界銀行のレポートでは、X‑Roadによって情報へのアクセスが容易になったことで、エストニア政府と国民が2014年の1年間だけで節約できた時間を、控えめに見積もって280万人時と推定しています。

内部APIの管理ガイドライン

内部APIを管理するためのベストプラクティスをいくつか見ていきましょう。

API管理ツールを使用する

社内向けと外部向けの両方のAPIを効率的に定義、公開、保護、監視、分析するには、API管理ソリューションが必要です。また、社内の開発者が公開済みAPIについてすぐに把握できる開発者ポータルも必要です。

高いパフォーマンスを確保

マイクロサービスは、普及が進んでいる新しいソフトウェア開発アーキテクチャのアプローチです。多くの企業が、このフレームワークを使用して既存の社内アプリケーションを再設計したり、新しいアプリケーションを構築したりしています。マイクロサービスアーキテクチャでは、クライアントとマイクロサービスベースのアプリケーション間、およびアプリケーションを構成するマイクロサービス間の通信にAPIが使用されます。APIクライアントがバックエンドアプリケーションにリソースを要求すると、APIゲートウェイがトラフィックを適切なマイクロサービスにルーティングします。また、APIゲートウェイは呼び出しを認証し、レート制限を適用することで、外部の攻撃者が企業のファイアウォールを突破した場合に発生し得る攻撃を防ぎます。

マイクロサービスはモノリシックアプリケーションよりも通信量が多く、マイクロサービス間では大量の「East-West」トラフィックが発生します。そのため、高スループット（1秒あたりのリクエスト数）で処理し、応答を迅速に返せる高性能なゲートウェイを選択することが非常に重要です。クライアントからのリクエストによって、異なるマイクロサービスへの複数のAPI呼び出しが発生することも少なくありません。そのため、APIゲートウェイで1つの呼び出しに遅延が生じるだけでも、連鎖的な影響が発生し、レイテンシーが大幅に増加する可能性があります。

企業ネットワーク外のクラウドを経由して呼び出しをルーティングしない

APIのライフサイクル全体を管理できる第1世代のクラウドベースソリューションもありますが、内部APIの処理には適していません。これらのアーキテクチャでは、データプレーン（APIトラフィックを処理するAPIゲートウェイ）とコントロールプレーン（API管理機能を実行）が密結合されているため、実行時には内部APIへのすべての呼び出しをAPI管理ソリューションのクラウド経由でルーティングする必要があります。これには2つのデメリットがあります。

レイテンシーの増加 – 内部API呼び出しを処理するためにクラウドを経由すると、通信経路が遠回りになり、必然的にパフォーマンスが低下します。
企業のゼロトラストポリシーに違反する – 内部API呼び出しをクラウドにルーティングする必要があるため、ファイアウォールに通信許可用の穴を開けなければなりません。その結果、企業ネットワークが攻撃や侵害のリスクにさらされ、不要な複雑さが生じます。

セキュリティ上の理由から、内部APIトラフィックは企業ファイアウォールの内側に留める必要があり、外部クラウドにAPI呼び出しをルーティングすることはできません。これは、自社のプライベートクラウド環境でアプリケーションとAPIをホストしている企業にも当てはまります。

NGINXはどのように役立つのか

NGINXは、さまざまな方法で内部APIの管理を支援します。

NGINXは、そのパフォーマンスで高く評価されています。独立系テクノロジー調査会社GigaOmによると、NGINXは毎秒30,000件を超えるリクエストを処理する場合でも、API呼び出しをエンドツーエンドで30 ms未満で処理できます。ベンチマーク結果の詳細については、F5の「ブログ」をご覧ください。リアルタイムAPIを提供するための詳細なガイドラインをまとめた「リファレンスアーキテクチャ」も公開しています。
NGINXとNGINX Plusは、マイクロサービス開発で広く採用されているインフラストラクチャであるコンテナ向けに設計されています。フットプリントは約2 MBで、サポート対象のLinuxサーバー（ベアメタル、クラウド、仮想環境）上、またはKubernetesなどのプラットフォームでオーケストレーションされたDockerコンテナ内で直接実行できます。
NGINX API管理ソリューションの革新的なアーキテクチャは、スケーラビリティを考慮して設計されています。NGINXは、APIゲートウェイ（NGINX Plus）とAPI管理ソフトウェア（NGINX Controller ［現F5 NGINX Management Suite］）を分離することで、分散型API管理をサポートします。両者の間にランタイム依存関係がないため、追加のスクリプト、データベース呼び出し、その他のコントロールプレーンロジックなどの不要なオーバーヘッドを伴わずにAPIトラフィックを処理できます。この分離型アーキテクチャにより、Controller ［NGINX Management Suite］とNGINX Plus APIゲートウェイの導入先を最大限柔軟に選択できます。オンプレミス、パブリッククラウドのほか、企業ネットワークがクラウドまで拡張されている場合は、複数のパブリッククラウドにまたがって導入することも可能です。APIトラフィックを処理するNGINX Plus APIゲートウェイは企業ファイアウォールの内側に独立して導入できるため、内部API呼び出しを企業ネットワーク外のクラウド経由でルーティングする必要はありません。

社内APIを利用していますか？または、社内APIの開発を計画していますか？社内APIをクラウド経由でルーティングしていますか？ぜひ下のコメント欄でお聞かせください。まずは、NGINX Controllerの30日間無料トライアル［NGINX Management Suite］を今すぐ開始するか、ユースケースについてF5にお問い合わせください。