内部 API を管理するためのベスト プラクティス

一部の消費者向け API は非常に普及しており、よく知られている名前になっています (Google Maps や Stripe など)。しかし、内部 API は API エコノミーの真の原動力です。

内部 API (組織内のクライアントと開発者にのみ公開される API) は、企業のデジタル変革の取り組みの重要な柱です。 内部 API の構築は通常、デジタル製品やサービスの開発における最初のステップです。 実際、IDC の最近の調査「API – デジタル ビジネスの成功と失敗を決定する要因」によると、アプリケーションと製品の内部統合をサポートすることは、企業における API 開発イニシアチブの最優先事項の 1 つです。

内部 API が重要なのはなぜですか? 内部 API の利点は何ですか? そして重要なのは、それらを管理するための最適なアーキテクチャは何かということです。 このブログでは、これらの質問に答えて、内部 API を安全かつ大規模に提供できるように支援します。

内部 API が重要な理由

内部 API は、組織のさまざまなバックエンド システムを解放して事業部門 (LOB) 内の他の開発者が使用できるようにすることで、データ サイロのロックを解除し、橋渡しを行います。 たとえば、製造業者のマーケティング組織は、適切な市場セグメントをターゲットにして収益を最大化するために、特定の製品やモデルを割引するかどうかを決定するために、サプライ チェーン組織が使用するシステムに対する可視性が必要になる場合があります。

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

内部APIの利点

内部 API により、市場投入までの時間が短縮され、ソフトウェア開発の時間とコストが削減されます。 メリットを詳しく見ていきましょう。

運用効率

内部 API は、ビジネスのさまざまな部分を接続するための簡単に使用できる抽象化レイヤーを提供し、変化する要件に適応する柔軟性を提供します。 各 LOB のアプリケーションごとにサイロ化された技術スタックを作成するのではなく、組織全体の開発者は共通の内部 API プールからデータにアクセスできます。 これにより重複が排除され、ソフトウェア開発時間が短縮され、開発者と IT の生産性が向上します。

記録システムの開発

内部 API は、組織内の主要なデータ要素の信頼できるソースとして機能する記録システムの開発を促進します。 データの整合性を確保するには、特定の情報に対して 1 つのレコード システムのみが存在する必要があります。 各 LOB に独自のデータがあったり、バージョンがわずかに異なっていたりすると、矛盾や混乱が生じます。 内部 API は、この唯一の真実のソースにアクセスするための効率的なメカニズムです。

コスト削減

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

たとえば、エストニア連邦政府は、すべての政府機関をシームレスに接続するデータ交換プラットフォームである X-Road を運営しています。 エストニア国民は運転免許証を携帯する必要すらありません。なぜなら、その情報は人口登録簿と車両登録簿からすぐに取得できるからです。ただし、2つのデータリポジトリは別々です。 世界銀行のこの報告書では、 X-Road によって情報へのアクセスが容易になったことで、エストニア政府と国民は 1 年間 (2014 年) で 280 万時間の労働時間を節約できたと控えめに見積もっています。

内部 API の管理に関するガイドライン

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

API管理ツールを使用する

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

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

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

マイクロサービスはモノリシック アプリケーションよりも「チャット」が多く、マイクロサービス間の「東西」トラフィックが大量に発生します。 したがって、高いスループット (1 秒あたりのリクエスト数) で処理し、非常に迅速に応答を配信できる高性能ゲートウェイを選択することが非常に重要です。 クライアントのリクエストによって、異なるマイクロサービスへの複数の API 呼び出しが生成されることが多いため、API ゲートウェイで 1 回の呼び出しでも遅延が発生すると、連鎖的な影響が生じ、非常に長い待ち時間が発生する可能性があります。

企業ネットワーク外のクラウド経由で通話をルーティングしない

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

• レイテンシが増加 – 内部 API 呼び出しを処理するためにクラウドにホップするのは回りくどいため、必然的にパフォーマンスが低下します。
• 企業のゼロトラスト ポリシーに違反します – 内部 API 呼び出しはクラウドにルーティングする必要があるため、ファイアウォールに穴を開ける必要があります。 これにより、企業ネットワークが攻撃や侵害にさらされ、不必要な複雑さが生じます。

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

NGINX はどのように役立ちますか?

NGINX は、内部 API の管理に役立ついくつかの方法を提供します。

• NGINX はそのパフォーマンスで知られています。 独立系技術調査アナリストの GigaOm によると、NGINX は 1 秒あたり 30,000 件を超えるリクエストのレートでも、エンドツーエンドで 30 ミリ秒未満で API 呼び出しを処理できます。 ベンチマーク結果の詳細については、当社のブログをご覧ください。 リアルタイム API を提供するための詳細なガイドラインを含むリファレンス アーキテクチャを公開しました。
• NGINX と NGINX Plus は、マイクロサービスの開発に最適なインフラストラクチャであるコンテナ向けに設計されています。 フットプリントのサイズが約 2 MBの NGINX と NGINX Plus は、サポートされている 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 [NGINX Management Suite]の 30 日間無料トライアルを開始するか、弊社にお問い合わせの上、ユースケースについてご相談ください。