Amazon Lambdaを使用する際にApache APISIXが必要な理由

サーバーレスとAmazon Lambda

サーバーレスとは？

サーバーレスコンピューティング、または単にサーバーレスは、現在のソフトウェア市場で人気のあるトレンドです。ますます多くの企業が、従来のサーバー指向のアーキテクチャから、より高速でコスト効率の良いサーバーレスアーキテクチャに移行しています。

サーバーレスアーキテクチャは、インフラストラクチャを管理せずにアプリケーションを構築および実行する方法です。必要なインフラストラクチャをクラウドベンダーまたは自己展開型のサーバーレスプラットフォームに展開し、管理します。これにより、エンジニアはインフラストラクチャの構築、管理、スケーリングに多くの労力を費やすことなく、アプリケーションのビジネスロジックに集中できます。ビッグ3のクラウドベンダー（Amazon Web Services、Microsoft Azure、Google Cloud）は、最高のサーバーレスサービスを提供することに大きな関心を示しています。例えば、Amazon Lambdaは、AWS（Amazon Web Services）のコアサーバーレスコンピューティングサービスです。

以下の図に示すように、従来のデプロイ方法とは異なり、Amazon Lambdaを使用すると、ソースファイルをアップロードし、実行環境を選択して実行するだけで、操作結果を得ることができます。サーバーへのアップロードやコンパイルの手順から解放されます。このプロセスでは、サーバーのデプロイ、ランタイムのインストール、コンパイルはすべてAmazonのサーバーレスコンピューティングプラットフォームによって管理および実行されます。エンジニアは、ソースコードと実行環境の関連設定を維持するだけで済みます。

これに関連する技術はBaaS（Backend as a Service）で、サーバーサイドコンポーネントを記述および管理せず、アプリケーションのすべての部分を完全に外部委託することを意味します。サーバーレスは、コードが実行される新しいホスティング環境です。

なぜサーバーレスが必要なのか？

サーバーレスにはいくつかの利点があります：

• 開発者にとって、サーバーレスはよりフレンドリーです。サーバー管理の詳細を抽象化し、エンジニアがビジネスコード自体に集中できるようにします。
• コスト面では、サーバーレスは使用量に応じた支払い方式です。
• パフォーマンス面では、リクエストトラフィックに応じて自動スケーリングできます。
• 関数に割り当てられるメモリ量を調整することで、コードの実行と応答時間を最適化することもできます。

サーバーレスを使用する際にAPIゲートウェイが必要な理由

サーバーレスには弱点もあります：

• 関数のURLがアプリケーションにハードコードされている。
• 煩雑な認証および認可ロジック。
• クラウドベンダーへの依存度が高い：クラウドベンダーがダウンすると、サービスもダウンする。
• 異なるクラウドベンダー間でスキームが大きく異なり、特定の標準がないため、移行には通常コストがかかる。

APIゲートウェイはこれらの問題を本質的に解決できます。組み合わせることで、サーバーレスは堅牢なアーキテクチャになります。以下の図は、Amazonのサーバーレスサービスを使用して簡単なWebサービスを迅速に組み立てる方法を示しています。APIゲートウェイは、認証、ルート定義、リクエストのプロキシを提供する上で重要です。Apache APISIXを例にとると、AWSとAzureのサーバーレスサポートを提供しています。アプリケーションに関数URLをハードコードする代わりに、サーバーレスプラグインを有効にするルートを定義できます。関数URIのホットアップデートの柔軟性により、異なるFaaS（Function as a Service）クラウドサービスプロバイダーへの更新が容易になります。さらに、このアプローチは煩雑な認証および認可の苦痛を軽減します。

Apache APISIX

Apache APISIXは、Apache Software Foundation (ASF)の下にあるクラウドネイティブのAPIゲートウェイです。動的でリアルタイム、高性能なAPISIXは、ロードバランシング、動的アップストリーム、カナリアリリース、サーキットブレーカー、認証、可観測性などの機能を提供します。Apache APISIXを使用して、サービス間の従来の南北および東西トラフィックを処理できます。同時に、K8s Ingress Controllerとしても使用できます。APISIXは、組み込みプラグインを通じてエコシステムを拡張し、認証、セキュリティ、可観測性、トラフィック管理、マルチプロトコルアクセスなど、APIゲートウェイのさまざまな使用シナリオをカバーします。もちろん、サーバーレス関連のプラグインも多く含まれています。

aws-lambdaプラグイン

aws-lambdaプラグインは、AWS LambdaをAPISIXと統合し、特定のURIに対するすべてのリクエストをAWSクラウドにプロキシする動的アップストリームとして機能します。有効にすると、プラグインは設定されたURIに対する進行中のリクエストを終了し、クライアントに代わってAWS Lambda Gateway URIへの新しいリクエストを開始します。この新しいリクエストには、以前に設定された認証の詳細（リクエストヘッダー、ボディ、パラメータ）が含まれます（これらはすべて元のリクエストから渡されます）。そして、APISIXでリクエストを開始したクライアントに、ヘッダー、ステータスコード、ボディを含むレスポンスを返します。このプラグインは、AWS APIキーとAWS IAMシークレットを使用した認証をサポートしています。

詳細については、APISIXまたはこのブログを参照してください。

Apache APISIXのサーバーレス関連プラグイン

Amazon Lambdaに加えて、Apache APISIXはAzure Function、Lua関数、Apache OpenWhiskなどのサーバーレス関連エコシステムとの統合もサポートし、対応するサーバーレスプラグインを提供します。

表1 Apache APISIXのサーバーレス関連プラグイン

プラグイン名	説明
serverless	ユーザーはserverlessプラグインを通じてカスタムLuaスクリプトをアップロードし、設定に応じてコードの実行フェーズを指定できます。例えば、アクセスフェーズでリクエストに対するアクセス制御を行い、ヘッダーフィルタおよびボディフィルタフェーズでレスポンスヘッダーまたはレスポンスボディを変更し、ログフェーズで個別化されたログを出力するなどです。また、serverlessプラグインはホットリロードされるため、変更を即座に反映させることができ、Apache APISIXを再起動する必要はありません。
azure-functions	APISIXをAzure Serverless Functionと統合し、特定のURIに対するすべてのリクエストをMicrosoft Azureクラウドにプロキシする動的アップストリームとして使用します。有効にすると、azure-functionsプラグインは設定されたURIに対する進行中のリクエストを終了し、クライアントに代わってAzure Functionsへの新しいリクエストを開始します。新しいリクエストには、以前に設定された認証の詳細（リクエストヘッダー、ボディ、パラメータ）が含まれます（これらはすべて元のリクエストから渡されます）。そして、APISIXでリクエストを開始したクライアントに、ヘッダー、ステータスコード、ボディを含むレスポンスを返します。
openwhisk	APISIXをオープンソースの分散サーバーレスプラットフォームであるApache OpenWhiskと統合するために使用されます。有効にすると、プラグインは設定されたURIに対する進行中のリクエストを終了し、クライアントに代わってOpenWhiskのAPIホストエンドポイントへの新しいリクエストを開始し、openwhiskプラグインはレスポンス情報をクライアントに返します。
openfunction	APISIXをオープンソースの分散サーバーレスプラットフォームであるCNCF OpenFunctionと統合し、動的アップストリームとして使用します。有効にすると、プラグインは設定されたURIに対する進行中のリクエストを終了し、クライアントに代わってOpenFunction関数への新しいリクエストを開始し、openfunctionプラグインはレスポンス情報をクライアントに返します。

まとめ

近年、マイクロサービスアーキテクチャの出現により、すべてがクラウドに移行しており、多くのクラウドサービスプロバイダーもサーバーレス関連の製品をリリースしています。サーバーレスベースの開発は非常に便利な開発モデルになっています。クラウドネイティブのトレンドに合わせて、APISIXはserverless、azure-functions、openwhisk、openfunctionプラグインを提供することでサーバーレスコンピューティングをサポートしています。

APIゲートウェイとそのサーバーレス機能についてさらに学びたい場合は、https://api7.ai/contactでお問い合わせください。