API Gatewayで広がるAWSのエッジコンピューティングの可能性

ども、大瀧です。
先日ローンチしたAmazon API Gatewayはその名の通り、RESTful APIを効率よく構築・運用するためのサービスとして大きな注目を集めています。今回は少し視点を変えて、API Gatewayのアーキテクチャから垣間見えるAWSのエッジコンピューティングへのアプローチについて妄想をしたためてみたいと思います ^*1。

エッジコンピューティングとは

用語自体はNTTのリリースが最初のようで、Ciscoのフォグコンピューティングも同様と見られています。

さて、ちょっと唐突ですが、クラウドコンピューティングではデータセンターにコンピューティングリソースを集中的に配置することから以下の課題が挙げられます。

• IoTデバイスなど多数のクライアントからの同時接続に耐えられない
• センサーデータなどリアルタイム性が必要な用途では、データセンターとの通信遅延が許容できない

エッジコンピューティングとは、よりクライアントに近いロケーションにコンピューティングリソースを分散配置することで、これらの課題を解決しようとするものです。

近いロケーションとはNTTであれば電話局ないしモバイル網の基地局、Ciscoであればルーター機器を配置するラックというように、当然各ベンダーのテリトリーが当てはめられるため様々な解釈ができます。少し粒度は異なりますが、CDN(Contents Delivery Network)のコンテンツノードも"分散配置"という意味でエッジコンピューティングの一つと言っても怒られないかなと思いました ^*2。

CDNとエッジコンピューティング

ただ、一般に言われるCDNは静的なWebコンテンツをキャッシュする単純なキャッシュクラスタを指すことが多く、エッジコンピューティングと呼ぶには機能面で貧弱な印象があります。 しかし、最近のCDNにはコンテンツを検閲するWAF(Web Application Firewall)機能 ^*3やリクエスト数、トラフィック量に応じた課金機能 ^*4など高機能を謳うサービスが出てきており、今後の可能性が予見される領域と言えます。 一方AWSにはCDNサービスとしてCloudFrontがあり、今回の主題であるAPI Gatewayは内部でCloudFrontを利用するアーキテクチャになっていることから、API GatewayはCloudFront(CDN)の機能を拡張するサービスひいてはエッジコンピューティングを実現する可能性を秘めたサービスと言えるのではないでしょうか(妄想です！)。例えば現在のAPI Gatewayでは、以下の機能が提供されます。

• リクエストURI、クエリストリング、リクエストヘッダ、リクエストボディの変換 ^*5
• スロットリング(RPSバーストリミット/ハードリミット)
• コンテンツキャッシュ

さらに、バックエンドにLambdaを設定、アプリケーションロジックをLambda Functionに実装することで、エッジコンピューティングらしい構成 ^*6にも見えてくると思います。図にすると、以下のような感じです。

API Gateway+Lambdaの構成上の課題

API Gateway+Lambdaが望むべきエッジコンピューティングの姿に見えているかもしれませんが、実際の構成にはいくつか課題が残ります。それぞれの挙動を検証してみると、LambdaだけでなくAPI Gatewayも、AWSのエッジロケーションのリソースでなくリージョンのリソースとしての特性が見えてきました。

検証は独自に行ったものであり、またAPI Gatewayの内部構成は公開されていないため、以下の記述は筆者の推測によるものであることをご了承ください。

例えば、API GatewayのMethodタイプをHTTP Proxyにするとき、バックエンドのサーバーへのアクセス元IPアドレスはAPI Gatewayを定義しているリージョンのEC2などのPublic IPのレンジであり、またクライアントからAPI Gatewayのキャッシュを参照するリクエストのレイテンシーを計ると、CloudFrontのキャッシュのレイテンシーよりも大きく、API Gatewayを作成したリージョンのEC2インスタンスへのレイテンシーに近いことがわかります。これらから、API GatewayはCloudFrontのリソースがリバースプロキシとなり、そのバックにAPI Gatewayの処理を行うなんらかのサーバーリソースが2段目のリバースプロキシとして動作する構成が推測されます。

そのため、エッジロケーションとリージョン間のレイテンシーがエッジコンピューティング用途だとボトルネックになってしまう可能性があると言えます。また、リージョンのリソースはエッジロケーションほど分散されているわけではないので、API GatewayおよびLambdaの同時接続数も要件を満たすものか評価する必要があるでしょう。エッジコンピューティングのアーキテクチャとしては、ロジック含めエッジロケーションで完結するような構成が理想ですね。

まとめ

API Gatewayから見えるAWSでのエッジコンピューティングの可能性について語ってみました。課題のところで触れたように、まだまだエッジコンピューティングの理想のアーキテクチャを満たすものではありませんが、API GatewayおよびLambdaはインフラ面でも今後の機能拡張に期待できるサービスだということがご理解いただけたのではないでしょうか。

API Gatewayは若いサービスですので、機能要望やバグ報告などフィードバックをAWSに寄せてサービスを育てていきましょう！

脚注