この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
丹内です。掲題のセッションをレポートします。
スピーカー
背景
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に切り出すことで、様々なメリットを享受することができます。 デプロイ周りの課題はありますが、アプリケーションの新たな作り方を模索していきたいですね。
18
