API Gatewayとは何か、そしてなぜそれが重要なのか？

API入門

API（Application Programming Interface）とは何でしょうか？APIは、異なるアプリケーションやシステム間でデータを交換するための標準的な方法です。多くの開発チームは、APIファーストのアプローチを採用しており、APIの設計、実装、テスト、セキュリティ、デプロイ、トラブルシューティング、分析に焦点を当てた反復を行います。これがAPIのライフサイクル管理（APIM）です。

APIが登場する以前は、データを交換するための標準的な方法はありませんでした。コンピュータプログラムは、FTP、FTPS、SFTP、HTTPSなどのさまざまなプロトコルを使用して互いに通信していました。標準の欠如は、開発コストの増大や、権限制御、データ管理、レート制限、監査などの多くの次元で潜在的なセキュリティリスクを引き起こしていました。これはコンピュータ世界の「バベルの塔」です。十分に複雑な製品を構築するためには、異なる言語や異なるデータストレージスキームで開発されたシステムによって引き起こされる問題を解決しなければなりませんでした。

APIの出現は、この「バベルの塔」問題を解決しました。開発者は他のシステムが公開するAPIにのみ注目すればよく、その背後にある実装の詳細を理解する必要はありません。

モバイルアプリ、オンラインゲーム、ライブビデオストリーミング、リモート会議、IoTデバイスなどのクライアントデバイスとサーバー間の接続とデータ伝送は、すべてAPIなしでは成り立ちません。APIはこれらの通信において重要な役割を果たしています。

なぜAPIゲートウェイを使うのか？

APIゲートウェイは、APIのライフサイクル管理において不可欠なコンポーネントです。APIの設定、リリース、バージョンロールバック、セキュリティ、負荷分散などを担当します。さらに、APIゲートウェイはすべてのクライアントトラフィックの入り口であり、クライアントのAPIリクエストを正しい上流サービスにルーティングし、処理されたデータを元のリクエスターに返す役割を担います。このプロセス全体の安全性、信頼性、低遅延を確保します。

最初にAPIが少ない場合、APIゲートウェイは通常、Webサーバーと上流サービスが結合した仮想的なコンポーネントです。ルーティング、転送、リバースプロキシ、負荷分散などの単純な機能はApacheやNGINXなどのコンポーネントによって行われます。認証やレート制限などの他の機能は上流サービスに依存しています。

なぜAPIゲートウェイが必要なのか？

しかし、APIの数が増えるにつれて、「怠惰な」開発者たちは深刻な問題に気づきました。上流サービスの異なる部分で、同じ認証、レート制限、ロギングなどの機能が繰り返しコーディングされています。これはリソースの浪費だけでなく、コード管理の悪夢でもあります。コードの一部が変更またはアップグレードされると、他の場所のコードも更新する必要があります。この問題を解決するために、賢い開発者たちはすぐに解決策を見つけました。共通の機能を抽象化（取り出し）し、単一のコンポーネントにまとめることです。ビジネスロジックに関係ないコードを上流サービスから取り出し、ApacheやNGINXなどのコンポーネントを強化します。これが第一世代APIゲートウェイの進化です。

APIゲートウェイの進化の方向性は、ビジネスに関係ない機能をできるだけ多く組み込むことです。製品の反復を加速するために、フロントエンド開発者とバックエンド開発者はAPIゲートウェイにますます多くの要求をします。ルーティング、転送、リバースプロキシ、負荷分散などの伝統的な機能に限らず、gRPCやGraphQLなどの観測可能性のための機能も求めています。

APIゲートウェイの役割

APIゲートウェイをより柔軟で効率的にするために、APIゲートウェイ開発者は基盤構造に多くの革新を加えました。例えば：

• 機能プラグイン。APIゲートウェイに組み込まれる機能が増えるにつれて、各機能を分離して開発を容易にするにはどうすればよいでしょうか？レゴのようなプラグインメカニズムが完璧な解決策です。主流のAPIゲートウェイはすべてプラグインを使用しています。Apache APISIXでは「プラグイン」と呼ばれ、Envoyでは「フィルター」と呼ばれます。プラグインはゲートウェイ開発者を実装の詳細から解放し、新しい機能を実装するために必要な開発リソースを減らします。
• データプレーンとコントロールプレーンの分離。第一世代のAPIゲートウェイでは、データプレーンとコントロールプレーンは同じコンピュータプロセスで実装されていました。ユーザーにとってはデプロイと使用が容易ですが、重大なセキュリティリスクを引き起こします。データプレーンは外部に直接サービスを提供します。外部からデータプレーンにハッキングされると、コントロール権限やコントロールプレーンのデータ（SSL証明書など）を取得し、より壊滅的な損害を引き起こす可能性があります。そのため、現在のオープンソースAPIゲートウェイのほとんどはDPとCPを別々にデプロイし、リレーショナルデータベースやetcdを使用して設定の管理と同期を行います。

Apache APISIXを例にとると、以下のアーキテクチャ図は上記の革新を示しています：

クラウドネイティブからの挑戦

過去10年間のITにおける最も大きな技術的変化はクラウドネイティブです。2013年に生まれたDockerはクラウドネイティブの幕を開けました。それ以来、ベアメタルと仮想マシンはコンテナに置き換えられ、モノリシックアーキテクチャはマイクロサービスに置き換えられました。しかし、クラウドネイティブは単純な技術革命ではありません。その背後にある原動力は、インターネット製品の急速な発展と激しい競争です。クラウドネイティブ関連技術は適切な時期に生まれ、急速に普及し、以前の技術アーキテクチャとソリューションの多くを置き換えました。具体的には、APIゲートウェイのクラウドネイティブにおける挑戦は主に以下の2つの側面から来ています：

モノリシックからマイクロサービスへ

マイクロサービスアーキテクチャが開発者の間で人気を博した後、大きな技術的配当をもたらしました。マイクロサービスは他のサービスとの結合を気にすることなく、独自のペースでアップグレードとリリースを行うことができます。製品の反復はアジャイルになり、1日に数十回、さらには数百回のリリースが行われることもあります。

しかし、マイクロサービスの発展はいくつかの副作用ももたらしました。例えば：

• APIとマイクロサービスの数は数十から数千、さらには数万に増加しました。
• どのAPIがエラーを引き起こしたかを迅速に特定するにはどうすればよいでしょうか？
• APIのセキュリティをどのように確保するか？
• サービスのサーキットブレーカーとサービスのダウングレードをどのように実現するか？

APIゲートウェイは、セキュリティ、観測可能性、カナリアリリースの問題を単独で解決することはできません。Prometheus、Zipkin、Skywalking、Datadog、Oktaなどの多くのオープンソースプロジェクトやSaaSサービスと連携して、企業により良いソリューションを提供する必要があります。

ダイナミックとクラスタ管理

最初の挑戦はエコシステムから、2番目の挑戦は技術から来ています。

ダイナミック

コンテナとKubernetesの普及により、ダイナミックはすべての基本的なクラウドネイティブコンポーネントの標準機能になりました。Kubernetes環境では、コンテナは常に作成され、破棄され、弾力的なスケーリングはオプションではなく必須になりました。

次のシナリオを想像してください：eコマース企業がプロモーションを実施し、1時間以内に数百万のユーザーが流入し、プロモーションが終了すると去ります。このシナリオでは、従来のアーキテクチャを持つ企業は、ピーク時のAPIトラフィックに対処するために物理サーバーを購入する必要があります。一方、クラウドネイティブアーキテクチャを持つ企業は、パブリッククラウド上の弾力的なリソースをいつでも使用できます。APIリクエストの数に基づいて、ネットワーク、コンピューティングパワー、データベースなどのリソースの規模を自動的に調整することができます。

コンテナの弾力的なスケーリングに関連する技術的挑戦もあります：

• 上流サービスのIPアドレスとポートが頻繁に変更される。
• IPの許可リストと拒否リストが頻繁に更新される。
• サービスの健全性の異常検出と処理。
• APIの定期的なリリース。
• サービスの登録と発見のタイムリーさ。
• SSL証明書のホットリニューアルと自動ローテーション。

これらの技術的挑戦の核心はダイナミックです。

NGINXに代表される第一世代のAPIゲートウェイは、ダイナミックな能力が弱いです。NGINXはローカルの静的設定ファイルによって駆動されるため、設定の変更があるとNGINXサービスをリロードする必要があり、クラウドネイティブ時代の企業にとっては受け入れられません。これが第一世代APIゲートウェイの最初の技術的痛みです。

クラスタ管理

2番目の技術的痛みはクラスタ管理です。

中国のSaaSオフィスソフトウェア会社であるWPSは、Microsoft Office 365のようなソフトウェアを提供しています。彼らはApache APISIXを実行する数百台の物理マシンを持ち、クライアントからのAPIリクエストを処理するために約10,000コアのCPUを使用し、毎日数百億のAPIを処理しています。

この超大型のAPIゲートウェイ環境では、開発者が各APIゲートウェイの設定を一つずつ変更し、リロードすることは不可能です。代わりに、開発者は統合コンソールを使用してクラスタ全体を操作したいと考えています。残念ながら、第一世代のAPIゲートウェイが誕生したとき、このような大規模なインスタンススケールは存在しなかったため、第一世代のゲートウェイの開発者はクラスタ管理のニーズを考慮していませんでした。

次世代APIゲートウェイ

上記の挑戦と痛みは、次世代のAPIゲートウェイを徐々に生み出しました。

次世代APIゲートウェイの特徴

第一世代のAPIゲートウェイとは異なり、オープンソースコミュニティがクラウドネイティブ時代の次世代APIゲートウェイの発展の主な原動力です。コミュニティと多数のオープンソース貢献者の力により、これらのAPIゲートウェイはポジティブな反復と進化のサイクルを形成する機会を得ました：

• 開発者とユーザーのニーズと痛みをより迅速に収集できる。
• これらの問題をオープンソースプロジェクトで解決しようとする。
• オープンソースプロジェクトが使いやすくなり、より多くの開発者を引きつける。

このプロセスで、次世代のAPIゲートウェイは、伝統的なゲートウェイの負荷分散とリバースプロキシの位置づけを突破し、トラフィックの接続、スケジューリング、フィルタリング、分析、プロトコル変換、ガバナンス、統合などのより多くの責任を担うようになりました（下記参照）。

APIゲートウェイは低コストの二次開発をサポート

同時に、開発者が低コストでカスタム開発を行うことを可能にすることも、次世代APIゲートウェイのハイライトになりました。統合はAPIゲートウェイの重要な機能の一つです。下流に対しては、GraphQL、gRPC、Dubboなどのプロトコル解析とプロトコル変換を行います。上流に対しては、Okta、Keycloak、Datadog、Prometheusなどの認証と観測可能性サービス、および企業内部の認証、ロギング、監査などのサービスと統合します。

APIゲートウェイは統合プロセスのすべてのコンポーネントをカバーすることはできません。そのため、開発者がプラグインを通じてカスタム開発を行い、自社のビジネスニーズを満たすことは避けられません。

異なるAPIゲートウェイは、カスタム開発のために異なるプログラミング言語と開発方法を提供します。例えば、Apache APISIXとKongはどちらもLuaを使用してネイティブプラグインを書くことができますが、EnvoyはC++を使用してネイティブプラグインを書きます。同時に、Apache APISIXはGo、Python、Node.js、Java、Wasmを使用してプラグインを開発することもできます。ほとんどの開発者はこれらの主流のプログラミング言語のいずれかを使用しています。

オープンソースと簡単なカスタム開発は、次世代APIゲートウェイの最も重要な特徴です。これにより、開発者はより多くの選択肢を得ることができます。同時に、開発者はマルチクラウドまたはハイブリッドクラウド環境でAPIゲートウェイを自信を持って使用でき、クラウドサービスプロバイダーにロックインされることを心配する必要はありません。

例：ブラックフライデートラフィックのためのAPIゲートウェイ

次に、具体的な例でAPIゲートウェイが何をするかを説明します。

ブラックフライデーには、eコマース企業は多くのプロモーションを行い、この期間中のAPIリクエストの量は通常の数十倍になります。まず、APIゲートウェイがない場合の技術アーキテクチャを見てみましょう：

上記の画像からわかるように、認証とロギング機能はOrderサービスとPaymentサービスで重複しています。eコマースサービスは通常、数千の異なるサービスで構成されています。この時、多くのコードと手順が繰り返されます。

以下の図は、APIゲートウェイを追加した後のアーキテクチャ図です：

上記からわかるように、共通のサービスをAPIゲートウェイ層に統合しました。その結果、バックエンドサービスは自社のビジネスにのみ集中し、弾力的なスケーリングのためのより多くの可能性を提供します。

プロモーションが開始すると、クライアントからの数百万のAPIリクエストがAPIゲートウェイに流入し、バックエンドサービスは迅速な弾力的なスケーリングを実行する必要があります。突然のトラフィックによって重要なビジネスが影響を受けないようにするために、APIゲートウェイで悪意のあるクローラーを識別し、スロットリング、サービスのダウングレード、サーキットブレーカーを実装する必要があります。

また、製品評価、配送状況の問い合わせなどの一部のサービスを一時的に停止することもできます。しかし、在庫情報、購入、支払いなどのコアビジネスは失敗してはいけません。そのため、K8sを通じてコンテナサービスを管理し、正常に動作するためにサービスのコピーを増やす必要があります。この時、APIゲートウェイはクライアントのAPIリクエストを新しくコピーされたレプリカサービスにルーティングし、障害のあるサービスを自動的に削除する必要があります。以下の図を参照してください：

まとめ

まとめると、APIゲートウェイは新しいミドルウェアではありません。しかし、技術アーキテクチャが進化し、製品の反復がますます速くなるにつれて、その重要性が高まっています。次世代のクラウドネイティブAPIゲートウェイの出現は、クラスタ管理、ダイナミック、エコシステム、観測可能性、セキュリティにおける企業ユーザーの痛みを解決します。

APIゲートウェイは、APIトラフィックだけでなく、Kubernetes Ingressやサービスメッシュからのトラフィックも処理でき、開発者の学習曲線をさらに短縮し、企業がトラフィックを統合的に管理するのを支援します。

お問い合わせして、Apache APISIX、API7 Enterprise Edition、API7 Cloud製品について詳しく学びましょう。