Tomoya Oka サーバーレスは死なぬ！みんな EDA(Event Driven Architecture) として使ってるでしょ？ 

1 Speaker Tomoya Oka @cyberarchitect Cloud Solutions Architect AWS認定試験対策本を書きました(昔) 好きなAWSサービス: Fargate, Lambda, RDS 

2 2019年以来の参加です！！！(うれしい。写真は2019年のもの) 

3 ここ1年ぐらい、サーバーレスよもやま話への雑感(1/3) ー Amazon Prime Video開発チームのブログ記事に纏わる論争 • 発端は、Amazon Prime Video開発チームが公開して下さった Tech記事*1。AWS Lambda、AWS Step Functionsを組み 合わせたサーバーレスアーキテクチャの監視の仕組みを採用したが うまくスケールしなかったため、Amazon ECS Task内で処理が 完結するようにし、ECSの機能でスケーリングとコスト削減できるよ うにリアーキした事例。 • DHHさんは、このTech記事を例に、サーバーレスやマイクロサービス アーキテクチャのような複雑な分散システムは、本来Amazonのよ うな膨大なサービスが組み合わさった大規模システムで使われるも のであり、単一のアプリを公開するだけのシステムで安易に採用す べきでない、と主張されている*2と、自分は解釈しました。 • サーバーレスアーキテクチャとマイクロサービスアーキテクチャは同列に語 られるべきものなのか？という疑問は残った。 (元のTech記事では、マイクロサービスの話はしていない) *1 Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% *2 Even Amazon can't make sense of serverless or microservices 

4 ここ1年ぐらい、サーバーレスよもやま話への雑感(2/3) ー 熱量を失ったサーバーレスという世界（個人の所感） • Singular Perturbations社の西谷さんが、AWSを辞められた後、 サーバーレス市場に関する率直な思いをブログ記事にされた。*1。 • 「ぶっちゃけ2022年現在、サーバーレス自体は盛り上がっていませ ん。」という言及に勝手にショックを受けるわたし・・・*2 • 西谷さんは、サーバーレスに盛り上がりが感じられない理由の1つとして、 FaaSに関してはAWS Lambda一強の状態が続いており、しか もその状態がずっと続いている(激しい競争がない、心躍るアップ デートがない、つまり盛り上がってない)ことを挙げられています。 • でも西谷さんは「個人的には『Everything will be serverless』を 信じてます」と結んで下さっています！！！(涙 • あと、「サーバーレス、というよりもFaaSが一番向いているのはやは りイベント・ドリブンなシステムだと思う。」という言及もありました。ここ 重要と思います。 *1 熱量を失ったサーバーレスという世界（個人の所感） - Sweet Escape *2 西谷さんは、わたしにとって吉田さん(@yoshidashingo)たちServerless Heroesの方々と並 ぶ「サーバーレススター」なのです！！！ 

5 ここ1年ぐらい、サーバーレスよもやま話への雑感(3/3) ー Serverless in 2023 • Thoughtworks Technology Podcastのサーバーレス回*1。ゲス トに『Programming AWS Lambda』*2著者のMike Robertsさ んを迎え、「2023年時点でのサーバーレスの現状」がテーマ。 • 40分あるので様々なトピックがでてきます。サーバーレスとは？、サー バーレスはFaaSだけではない、Lambdaの機能追加、Azureや Google Cloudの動向、ベンダーロックイン、設計・開発のベストプラ クティス、などなど。 • AWSのサーバーレスサービスを題材に会話は進むのですが、「AWS はマネージドサービスにAuto-Scaling機能を追加したものを 『サーバーレスである』と言いがち、サーバーレスをブランディングの手 段にしている」というのはよくぞ言ってくれた！という感じ。 • トピックは多岐に渡りますが、1行で要約すると、「サーバーレスはいつ 使うべきか、どう使うべきか、そして、サーバーレスとはそもそも何なの か？に関して、未だに混乱がある」と言えそうです。 *1 Serverless in 2023 | Thoughtworks *2 Programming AWS Lambda [Book] - O'Reilly 

6 自分は「サーバーレス」の現状についてどう思っているか  自分の「推しクラウド」はAWSなので、AWSを例にとってサーバーレスの話をさせて下さい。  サーバーレスはFaaS(AWSならAWS Lambda)だけを指すものではなく、周辺のAmazon API Gateway、 Amazon SQS、Amazon SNS、Amazon DynamoDB等のサーバーレスサービスを組み合わせた「アーキテク チャ」のことをサーバーレスと考えている  仕事やコミュニティ、Web上等で、普段からサーバーレスサービスを活用した事例やユースケースを当たり前のように目 にしているので、サーバーレスが衰退している、という感覚はない。コモディティ化はしていると思う。 (Generative AIと同じぐらいの熱量はあるか、と問われるとそこまでじゃない)  クラウドは、多数のサービスがネットワーク上で連携して動作する仕組みなので、本質的に大規模分散システム。 サーバーレスは、分散したサービス同士を、「イベント」というトリガーを起点に連携動作させるための仕組み(イベン ト駆動)*1、というのがユースケースの本命ではないかと思う。 本プレゼンにおける私の「サーバーレス」へのスタンスは以下の通りです。 *1事実、re:Invent 2022の「Serverless and Application Integration」カテゴリの中で一番多い セッションは、Event-driven architectures (EDA)に関するものだった Serverless and Application Integration sessions at AWS re:Invent 2022 | AWS Compute Blog 

午前中のEric JohnsonさんのKEYNOTEより Not all EDA is serverless but all serverless is EDA 

というわけでAWSで イベント駆動って例えば どういうの？ というお話をします！ 

その前に・・ 

10 本プレゼンにおける「サーバーレスサービス」の定義 「下にあるサーバーの設計や運用を意識する必要がない」「利用した分だけ課金」「自動スケーリング」「高可用 性の提供」の特徴を備える赤枠内のサービスを、本プレゼンにおける「サーバーレスサービス」と呼ぶものとする。 コンピューティング データストア アプリケーション統合 AWS Lambda Amazon Simple Storage Service (Amazon S3) Amazon DynamoDB Amazon Simple Queue Service (Amazon SQS) Amazon Simple Notification Service (Amazon SNS) AWS AppSync Amazon API Gateway AWS Step Functions Amazon EventBridge AWS Fargate Amazon Aurora Serverless Amazon Redshift Serverless Amazon EMR Serverless Amazon Kinesis AWS Glue VPCを意識した設計が必須。また、多くのユー スケースでECS Taskが常時起動するケースが 多いと思われるため、サーバーレスサービスという よりも「コンテナ用のマネージドコンピューティング リソース」という分類の方が適切ではないか？ 他にもOpenSearchとかNeptuneとか・・ サービスによってはVPCを意識した設計が必要であっ たり、xCU単位で最低料金が課金されるなどの理由 から、サーバーレスサービスというよりも、「Auto Scaling機能を持ったマネージドサービス」という分類 の方が適切ではないか？ 微妙の壁 本プレゼンにおける「サーバーレスサービス」の例 *参考 Serverless Computing – Amazon Web Services 

11 Event Driven Architecture(EDA)のおさらい(1/2) Event Driven Architecture(EDA、長いので「イベント駆動」と省略します)の登場人物。イベント駆動の定義 は情報ソースによって差異がありますが、今回はAWS社の定義*1に則るものとします。 イベント プロデューサー イベント ルーター/バス/ ブローカー イベント コンシューマー *1 イベント駆動型アーキテクチャ イベントとは ・・・ システムの状態が変更されたことを示すシグナル 

12 Event Driven Architecture(EDA)のおさらい(2/2) イベント駆動における、各登場人物の役割。イベント駆動の仕組みを採用することで、登場人物間のつながりは 疎結合となり、登場人物単位のスケーリングや信頼性向上がやりやすくなる。 イベント プロデューサー イベント ルーター/バス/ ブローカー イベント コンシューマー *参考イベント駆動型アーキテクチャ イベントとは ・・・ システムの状態が変更されたことを示すシグナル イベントを発生させる もの イベントに応じて フィルタや後続処理 への振り分けを行う もの 受信したイベントを 処理するもの 役割 具体例 ✓ S3 ✓ API Gateway ✓ Web/モバイルアプリ ✓ EventBridge ✓ SNS ✓ SQS ✓ Kinesis Data Streams ✓ Lambda ✓ Step Functions ✓ Kinesis Data Firehose 

13 イベント駆動のユースケースとしてよく見る気がする例(1/3) ー S3イベントトリガー、エラーイベントトリガー 基本中の基本すぎて意識しづらいが、S3イベントを起点とした後続処理の自動実行は最も利用されていると思わ れるユースケース。また、AWSサービスのエラーイベントをトリガーとした処理もよく利用される。あとconfigとか。 Amazon Simple Storage Service (Amazon S3) データレイク Amazon EventBridge AWS Glue ①S3PUT イベント ②Glueジョブ トリガー ➂データ 取得 Amazon Redshift ④データ変換・ ロード Amazon EventBridge ④`-1 エラー発生 イベント ④`-2 SNS 呼び出し Amazon Simple Notification Service (Amazon SNS) ④`-3 エラー 通知 ⑤可視化へ 

14 イベント駆動のユースケースとしてよく見る気がする例(2/3) ー オンライン処理のバックエンドの非同期処理化 これも古くからあるパターン。SQS部分をSNSや、EventBridge経由のStep Functions呼び出しに差し替えた パターンもよく使われる。 Users Amazon API Gateway Amazon Simple Queue Service (Amazon SQS) ①API アクセス ②Lambda 発火 ➂メッセージ 送信 AWS Lambda ④メッセージ 要求 ⑤非同期 処理 AWS Lambda 

15 イベント駆動のユースケースとしてよく見る気がする例(3/3) ー Step Functionsによる、オンプレミスのジョブネットのリプレイス いわゆるオーケストレーションパターン。2019年以降、Step FunctionsがサポートするAWSサービスのカバレッジ が非常に広くなったことと、ステートマシンの制御表現や、エラー処理の機能追加・改善により、採用頻度が増えた。 AWS Serverless Airline Bookingサンプル*1より *1 Orchestration and choreography patterns - AWS Prescriptive Guidance 近年の、Step Functionsの代表的アップデート Update Date エラーの識別やリトライ処理の機能改善 September 07, 2023 ステートマシンの複数バージョンとエイリアスのサ ポート June 22, 2023 35のAWSサービスと、1100のAPIアクションの サポート追加 February 17, 2023 Mapステートによる、大規模並列ワークフロー 処理のサポート追加 December 01, 2022 コンソールでのExecution Detailsの参照機 能追加 May 09, 2022 GUIベースでのステートマシンのデザインを可能 にするAWS Step Functions Workflow Studioの追加 June 17, 2021 ステートマシン 実行 

16 (余談)個人的には経験していないが、実際のところどうなんだろうと思っているアーキテクチャ ー 100%サーバーレスや、コレオグラフィーパターン マイクロサービスのアーキテクチャを組むとして、APIの実行基盤含めてフルサーバーレスにするケースって普通にある のでしょうか・・？(私ならまずECS+Fargateで考えてしまう・・)。また、コレオグラフィーパターンの実例も勉強した いと思っています。 *参考 What a typical 100% Serverless Architecture looks like in AWS! | by Xavier Lefèvre | Serverless Transformation | Medium 

17 (余談)個人的には経験していないが、実際のところどうなんだろうと思っているアーキテクチャ ー Event-driven serverless story generation Generative AIのようにテキストが生成されたタイミングで後続処理の実行が必要なユースケースは、サーバーレス と相性が良い。OpenAIの部分は、今後Bedrockに置き換わっていくでしょう(期待)。 *参考 Implementing an event-driven serverless story generation application with ChatGPT and DALL-E | AWS Compute Blog イベント駆動処理部分 

18 (余談)個人的には経験していないが、実際のところどうなんだろうと思っているアーキテクチャ ー Build next-gen applications with event-driven architectures CloudWatch EventsからEventBridgeに進化した一番の目玉ポイントは、独自の業務イベントをイベント定 義し、サービス(アプリ含む)間で受け渡し可能になったところのはず。実例などを通し、Pros/Consを調査したい ところ。 *参考 Build next-gen applications with event-driven architectures | re:Invent 2022 業務ロジックがAWSサービス の「設定」としてアプリケーション コードと切り離される。 良し悪しがある。 CDKでビジネスロジック含めてLambdaや EventBridgeをデプロイし、アプリ/インフラの境界 なくコードで管理する未来がくる・・・のか・・？ 

19 サーバーレスパターン AWS社が、イベント駆動以外にもサーバーレスサービスを組み合わせた様々なデザインパターンを公開して下さって います。これら幅広いノウハウと実例の蓄積が、サーバーレスが広く普及していることを物語っていると思います。 *参考 サーバーレスパターン 

20 まとめ 「S3のイベントをトリガーにした処理」と聞くと「何をいまさら」と思われる方が多いと思いま すが、CloudWatch Events(現EventBridge)がリリースされるまでは、EC2で定期 的にポーリングして状態の確認をしていました。 このように、実はサーバーレスの恩恵を受けているけれども、それを意識せず使っている、 というケースが今後も増えていくのではないでしょうか。 マルチクラウド利用が一般化してきている昨今、Integrationの必要性は益々高くなっ ており、サーバーレスサービスを活用したアプリケーション統合は今後も盛んに利用されて いくと考えています！！！サーバーレスは死なぬ！！！ 

Tomoya Oka @cyberarchitect Thank you!