(レポート)ARC308: AWS Lambdaを使用している、サーバーのない企業:AWSによるストリーミングアーキテクチャー #reinvent

丹内です。掲題のセッションをレポートします。

スピーカー

• Vyom Nagrani - Senior Product Manager, Amazon Web Services
• Jay Sandhaus - CTO, PlayOn Sports

背景

AWS Lambdaをデータプロセッシング、具体的には動画の処理やストリーミングまでのサーバレスで行った試みのレポートです。 セッションはまず、Lambdaによるサーバレスアーキテクチャの考え方の解説から始まりました。 AWS Lambdaは登場以来、CFnによるAWSリソース制御の自動化や、イベントの発生に伴う簡単な処理などが行われてきました。 このセッションでは、Lambdaをアプリケーション実行環境として捉えています。 従来のPublic Cloudではインスタンス内に複数のアプリケーションコードがデプロイされ動作していました。ECSなどコンテナ関連技術の普及に伴い、1アプリ1コンテナが原則となり、複数コンテナを1インスタンス(あるいはホスト)で動かすようになりつつあります。 ここから更に一歩進んで、「1アプリ1コンテナ」のアプリが、「関数」と呼べるくらい単純なものであれば、該当するアプリケーションコードの一部をLambda Functionとしてフルマネージドサービスに切り出すことで、アプリケーションの作り方が変わる、という主張です。 アプリケーションをLambda Functionに切り出すことで、

• イベントのlistening/polling
• キューイング
• Auto Scaling
• 耐障害性
• ロードバランシング

などを一切考えなくて良くなります。更に、コストやパフォーマンスを一層最適化することが可能です。

今回のre:Inventにおいてこの旨の主張は複数のセッション・スピーカーによって提唱されており、新規な発表が少なかったサーバサイドアプリケーションに携わるAmazon及び多数のデベロッパーが、このように考えていることが分かります。

「Lambda Functionはサーバレスのマイクロサービスである」ということも関連していますね。 つまるところアプリケーションコードがLambda Functionになっていればそれはマイクロサービスの1つであり、デプロイ先がコンテナからLambda Functionに変わるだけである、ということです。

ビデオ配信の例

高校スポーツの配信を手掛けるPlayOn!では、EC2を中心とする多数のAWSリソースから構成されるレガシーアーキテクチャを、Lambdaを中心とするアーキテクチャに作り変えました。 異なるLambda Functionをカスケードさせることによって、異なる解像度のビデオの処理やQOSの解析、サムネイルの作成などを、サーバレスで行っています。

アーキテクチャパターン

AWS Lambdaは様々なイベントをトリガーにして実行できます。 詳しい説明はスライドの22ページ以降にあるので、適宜参照してください。

AWS Lambdaを使う上での工夫

CloudTrailがS3にオブジェクトを作成したらIAMを操作しつつ管理者に通知

このパターンはCloudTrail以外にも、公式にイベントソースとしてLambdaにサポートされていないイベント全般に適用可能です。

CloudWatchに設定されたアラームでSNSによる通知を行い、それをイベントソースにしてLambda Functionを実行、AWS APIを叩いて必要なリソースを確保

S3のcreateObjectと同様に、SNSをイベントソースにすることでLambdaサポートを待たずにAWSの操作を自動化できます。

GitHubのAmazon SNS連携でLambda Functionをデプロイ

GitHubでSNSの通知を出せることを知らなかったのですが、これも可能であるそうです。 ただ、Lambda Functionのデプロイや管理は課題が多い点ですね。

感想

アプリケーションコードをLambda Functionに切り出すことで、様々なメリットを享受することができます。 デプロイ周りの課題はありますが、アプリケーションの新たな作り方を模索していきたいですね。