コンセプトのレビュー: API 管理と API ゲートウェイ

原作者:NGINX

元のリンク:コンセプトレビュー: API 管理と API ゲートウェイ

転載元:NGINX オープンソースコミュニティ


NGINX の唯一の公式中国語コミュニティ (すべてnginx.org.cn ) 

マイクロサービス アーキテクチャの台頭により、API の数が劇的に増加し、それによって一連の課題と解決策も生まれています。この記事を読んで、API に関連する基本的な概念 (API ファースト、API の普及、API 管理、API ゲートウェイ、API 開発者エクスペリエンス) について学習してください。

APIファーストとは何ですか?

API ファースト」アプローチは、アプリケーションの設計が API から始まり、その後コーディングされる開発モデルです。API は後付けではなく、必要な確立された製品です。開発プロセス全体は API 仕様から始まり、アプリケーションは最初に API として概念化されます。これは、従来の「コードファースト」アプローチとはまったく対照的です。従来の「コードファースト」アプローチでは、モノリシックコードが最初に来て、API 設計が後から来ます。

API ファースト戦略は、アプリケーション エコシステムがモジュール式の再利用可能なシステムとして確実に開始されるため、マイクロサービス アーキテクチャに特に適しています。早い段階で API に注意を払うことで、API リクエストとデータの構造に注意を向けることができ、開発者が最も必要とする機能を API が提供し、後で不要であることが判明する機能に開発者の時間を浪費することを避けることができます。 

なぜ API ファースト モデルを採用するのでしょうか?

企業が API ファースト モデルを採用する (つまり「API ファースト企業」になる) と、API (社内および社外の両方) に優先順位が付けられ、API ライフサイクルが自社のビジネスに与える影響を認識します。企業にとって、API ファーストは、バックエンド サービスの更新と変更が容易になるため、市場投入までの時間が短縮されることを意味します。 

API ファーストのアプローチを採用すると、生産性が向上するだけでなく、より強力なソフトウェアの開発にも役立ちます。チームはゼロから始める必要がなく、プロジェクト全体で API とコードを再利用できるため、開発者は設計に集中できます。ほとんどの問題はコードを書く前に解決されるため、作業が軽減され、結果的にコストが削減されます。 

また、API ファースト モデルは API ガバナンスを簡素化し、運用チームに優れた制御と可観測性を提供します。API の制御と可視性が向上すると、チームは API の現状と将来の可能性を理解できるようになります。

APIファーストのセキュリティリスク

API はオープンであることが多く、優れた機能を提供するだけでなく、すべての開発者が API にアクセスできることも意味します。残念ながら、すべての開発者が純粋な意図を持っているわけではありません。 

成功する API ファースト モデルを作成するには、API セキュリティ戦略を一元的に定義し、API ライフサイクル全体にわたってセキュリティを統合する必要があります。API ファースト モデルはセキュリティ中心の哲学を強調しているため、以前のコード中心のモデルよりも強力なセキュリティ境界があります。 

API のスプロールとは何ですか?

API Sprawl」では、企業のデジタル変革に伴い発生する 2 つの絡み合った問題、つまり API の急増と、複数のアーキテクチャおよびチームにわたる API の分散について説明します。 

多くの要因が API クリープの原因となる可能性があります。最も一般的な要因には次のようなものがあります。 

  • ハイブリッド インフラストラクチャ - 今日の企業の 81% は、パブリック クラウド、オンプレミス データ センター、エッジ インフラストラクチャを含む 3 つ以上のアーキテクチャで運用されています。 

  • マイクロサービス アーキテクチャ – マイクロサービス アーキテクチャの人気の高まりにより、新しいサービスが継続的に開始され、API エンドポイントが急増しています。 

  • 継続的なソフトウェア展開 - 開発者は、数十の API または API の複数のバージョンを短期間で迅速に開発できます。 

  • 放棄された API  – 開発者が他のプロジェクトのサポートや作業に移ると、以前に作成した API の管理と保守を停止します。 

API のスプロール化が問題となるのはなぜですか?

API のスプロール化は、企業に運用面とセキュリティ面で大きな課題をもたらします。API エンドポイントが複数のチームや環境にわたって急増するにつれて、API の保護と管理が深刻な課題になります。企業にとって、API のスプロール化は、開発者の生産性の低下、やり直し作業の増加、レビュー時間の遅延などの隠れたコストをもたらすことがよくありますが、このようなコストは測定が難しく、手遅れになるまで気付かないことがよくあります。 

API クリープに関する主な課題には次のようなものがあります。 

  • 可視性の欠如 – ハイブリッド アーキテクチャでは、API トラフィックと構成を統一的に把握することが困難です。 

  • 明確なソースの欠如 - 開発者は API や最新のドキュメントを見つけるのが困難です。 

  • 信頼性の低下 - 構成ミスがより一般的になり、ビジネスの中断を容易に引き起こす可能性があります。 

  • セキュリティ上の脅威の増加 – 安全でない API エンドポイントは簡単にターゲットになります。 

API スプロールの詳細と、それが重大な脅威となる理由については、ブログ投稿「API クリープと戦うための 5 つの方法 (および API クリープについて懸念する必要がある理由)」を参照してください。 

API管理とは何ですか?

API 管理」とは、企業が API を監視および公開するために使用するツールとプロセスを指します。一部の環境では、API 管理は、運用環境で API を管理し、ポリシーの定義、構成のプッシュ、レポートとアラートの生成、およびすべての API ゲートウェイにわたる可視性の提供を行うコントロール プレーンを特に指します。 

現在、最新のアプリケーションのほとんどは API を使用して構築されています。API は、2 つのアプリケーションが相互に通信できるようにし、製品とサービスがリクエストと応答の形式で対話できるようにするソフトウェア インターフェイスです。 

API 管理ソリューションは、開発チーム間で API を公開および共有するプロセスを簡素化する主要なツールと機能を提供します。以下に、強力な API 管理の実現に役立つコンポーネントと使用例を示します。

インフラストラクチャー

  • API マネージャー — API の公開、API パフォーマンスの監視、アクセス制御ポリシーの適用など、API ライフサイクルを完全に管理する単一のインターフェイスを提供する管理プレーン (「API マネージャー」と呼ばれることもあります)。 

  • API 開発者ポータル - 開発者ポータルは、外部 API のカタログ、包括的なドキュメント、サンプル コードなど、API 利用者がすぐに使い始めるのに役立つリソースを公開できるオンライン プラットフォームです。開発者ポータルを使用すると、サードパーティの開発者がアプリケーションを登録し、API キーと JWT キーを取得することもできます。 

  • API ゲートウェイ : バックエンドと API コンシューマー間のトラフィックを保護し、処理します。API ゲートウェイの機能には、API 呼び出しの検証、適切なバックエンドへのリクエストのルーティング、システムの過負荷を防止または DDoS 攻撃を軽減するためのレート制限の実装、パフォーマンスを向上させるための SSL/TLS トラフィックのオフロード、およびエラーと例外の処理が含まれます。 

  • API 分析 — API 管理ソリューションは、ダッシュボードやレポートなどの視覚化機能を通じて重要な洞察を提供します。API 分析は、API 所有者が API メトリクス、使用状況、トラフィック傾向、どの開発者が主要な API コンシューマであるかなど、さまざまな運用面に関する洞察を得るのに役立ちます。 

  • API セキュリティ — セキ​​ュリティは API 管理の重要な側面です。強力なセキュリティがなければ、誰でも API やデータにアクセスし、安全でない API を呼び出して悪意のある行為を行うことができます。API セキュリティには、認証、認可、ロールベースのアクセス制御 (RBAC)、およびレート制限が含まれます。 

  • API ガバナンス - API および API ゲートウェイにおけるルールとセキュリティ保護の適用を指します。柔軟な API ガバナンス モデルを実装すると、ログ、エラー応答コード、TLS 構成などのグローバル ポリシーのバランスをとることができます。 

  • 定義と公開 - API 管理ソリューションは、ベース パス (URL)、リソース、エンドポイントなどの意味のある API を定義するための直感的なインターフェイスを提供します。 

API 管理の主な目的は、企業が API アクティビティを監視して、現在の開発者またはアプリケーションの要件に基づいた変更に迅速に対応できるようにすることです。

API 管理では、個々の API のライフサイクル (設計、リリース、運用、監視、非推奨) を管理することに重点が置かれています。

APIゲートウェイとは何ですか? 

API ゲートウェイは、クライアントからのリクエスト (具体的には API 呼び出し) を受け入れ、それらを適切なマイクロサービスにルーティングします。バックエンド サービスと API コンシューマー間の重要なトラフィックを保護および処理し、脆弱性、ダウンタイム、パフォーマンス低下のリスクを軽減します。 

現在、最新のアプリケーションのほとんどは API を使用して構築されています。API は、2 つのアプリケーションが相互に通信できるようにし、要求と応答の形式で製品とサービス間の対話を可能にするソフトウェア インターフェイスです。API がよりユビキタスになり、マイクロサービス アーキテクチャ全体に分散されるようになると、スケーラビリティとセキュリティを確保するために追加のインフラストラクチャが必要になります。 

API ゲートウェイを使用する理由

API ゲートウェイを使用すると、単一の API ドメイン (api.example.com など) を維持できることになります。API ゲートウェイを使用すると、すべてのクライアントに単一のエントリ ポイントを提供し、ユーザーのリクエストに基づいてリクエストを API のさまざまなバージョンにルーティングできます。API Gateway を使用すると、1 つのリクエストで複数のマイクロサービスを呼び出し、結果を集約して最適なレスポンスを提供できます。

APIゲートウェイの基本機能 

API ゲートウェイは、モノリシック アプリケーションとマイクロサービス ベースのアプリケーションの両方に使用できます。API ゲートウェイには次の機能があります。 

  • API呼び出しを行うリクエスタを認証する(AuthN) 

  • リクエスタがリクエストを行う権限を持っていることを確認します (AuthZ) 

  • リクエストを適切なバックエンドにルーティングする 

  • システムの過負荷を防ぐためにレート制限を実装する 

  • DDoS 攻撃を軽減するためにレート制限を実装する 

  • SSL/TLS トラフィックをオフロードしてパフォーマンスを向上させる 

  • エラーと例外を処理する 

APIゲートウェイとAPI管理

「API ゲートウェイ」と「API 管理」は同じ意味で使用されることがありますが、実際には同義ではありません。API ゲートウェイは、クライアントと API エンドポイントの間にあるデータ プレーンです。これは、ルーティング、ポリシー、セキュリティを担当する単一のプロキシ サーバーです。API 管理は、運用環境で API を管理するコントロール プレーンを指します。ポリシーを定義し、構成をプッシュし、レポートとアラートを生成し、すべての API ゲートウェイにわたる可視性を提供します。

理想的には、API 管理プラットフォームはインフラストラクチャに依存せず、ユースケースに最適な方法でさまざまな環境 (オンプレミスのデータセンター、クラウド プラットフォーム、エッジ ノードなど) に API ゲートウェイを自由にデプロイできるようになります。 

マイクロサービスに API ゲートウェイを使用する

マイクロサービス アーキテクチャでは、単一の API に数百のエンドポイントがあり、単一のアプリケーションに複数のマイクロサービスが含まれ、それぞれが APIを介して接続されていることがあります各マイクロサービスは多数の APIエンドポイントを公開するため、潜在的な攻撃対象領域はモノリシック アプリケーションの攻撃対象領域よりもはるかに大きくなります。 

マイクロサービスに API ゲートウェイを使用すると、クライアントと API 間のアクセスと通信が簡素化され、リスクが軽減されます。ただし、API ゲートウェイは、通常はオープンな API をカプセル化します。API は接続に必要なデータを公開し、機密データも公開する場合があります。

APIのセキュリティ

Open Web Application Security Project (OWASP) は、OWASP トップ 10 API セキュリティ リスクの中で最も一般的な脆弱性を特定しました。 

API1. 無効なオブジェクトレベルの認可 

API2. 壊れたユーザー認証 

API3. 過剰なデータ露出 

API4. リソース不足とレート制限 

API5. 無効な機能レベルの認可 

API6. 一括割り当て 

API7. セキュリティ保護設定エラー 

API8.インジェクション 

API9. 不適切な資産管理 

API10. ロギングとモニタリングが不十分 

こうした横行する新たな攻撃から API を保護するには、API ゲートウェイを保護することが重要になります。API ゲートウェイを保護することの重要性の詳細については、ブログ投稿「NGINX App Protect WAF による API ゲートウェイの保護」を参照してください。

API ガバナンス

API ガバナンスとは、API および API ゲートウェイにおけるルールとセキュリティ保護の適用を指します。柔軟な API ガバナンス モデルを実装すると、ログ、エラー応答コード、TLS 構成などのグローバル ポリシーのバランスをとることができます。 

API ファースト戦略を導入している組織、特に数千の API を採用している大規模な組織では、API ガバナンスを通じて一貫性を確保することで、潜在的な API のスプロール化に効果的に対抗できます。かつて API ガバナンスは開発を遅らせる可能性があると考えられていましたが、現在では API を大規模に管理する必要があります。 

API開発者のエクスペリエンスとは何ですか?

API 開発者のエクスペリエンスとは、 API を操作する際の開発者の全体的な知覚状態および感情状態を指します。これには、API をアプリケーションに統合するときに開発者に快適でスムーズなエクスペリエンスを提供するために連携して機能するインフラストラクチャ、ツール、プロセス、サポート、その他のタッチポイントが含まれます。 

API 開発者エクスペリエンスは、プラットフォーム上のあらゆるタッチポイントで最適化されたエクスペリエンスを開発者に提供する 1 つの側面です。開発者間の摩擦を軽減することで、ソフトウェア エンジニアリングのリーダーは、内部チーム開発者の生産性を向上させ、外部開発者による API やツールの採用を加速できます。 

API を設計するときは、次の基本的な質問をする必要があります。 

  • 機能 — API は何をするものですか? 

  • 使いやすさ – API はどれくらい使いやすいですか? 

  • エクスペリエンス - API の使用感はどうですか? 

開発者中心の世界では、API ライフサイクルのあらゆる段階をカバーする API 戦略を立て、ポジティブなエクスペリエンスを生み出すよう努めることが不可欠です。API 開発者のエクスペリエンスを設計するときは、API と対話するユーザーの特定、API の動作方法の定義、使いやすさの最適化、API の全体的な感触の向上がすべて重要な考慮事項となります。 

API 開発者のエクスペリエンスについて詳しくは、ブログ投稿「API 開発者のエクスペリエンスが重要な理由 」を参照してください。


NGINX の唯一の公式中国語コミュニティ (すべて nginx.org.cn )

NGINX 関連のその他の技術情報、インタラクティブな Q&A、一連のコース、およびイベント リソース: オープンソース コミュニティ公式 Web サイト |  WeChat パブリック

IntelliJ IDEA 2023.3 と JetBrains Family Bucket の年次メジャー バージョン アップデート 新しいコンセプト「防御型プログラミング」: 安定した仕事に就く GitHub.com では 1,200 を超える MySQL ホストが稼働していますが、8.0 にシームレスにアップグレードするにはどうすればよいですか? Stephen Chow の Web3 チームは来月、独立したアプリをリリースする予定ですが、 Firefox は廃止されるのでしょうか? Visual Studio Code 1.85 がリリース、フローティング ウィンドウ 米国 CISA、メモリ セキュリティの脆弱性を排除するために C/C++ の放棄を推奨 余成東 : ファーウェイは来年破壊的製品を発売し、業界の歴史を書き換える TIOBE 12 月: C# は今年のプログラミング言語になると期待される 論文30年前にLei Junが書いた「コンピュータウイルス判定エキスパートシステムの原理と設計」
{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/5246775/blog/10149743