Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

2023年、Amazon Prime Videoの技術部門が公開したブログ記事がきっかけとなり、サーバーレス技術に関する議論が巻き起こりました。中には、"Serverless is Dead"という言説も散見されました。サーバーレスアーキテクチャは死んだのでしょうか?いえ、わたしはそうは思いません。サーバーレス技術は、今でも特にEDA(Event Driven Architecture)の中心技術として、広く使われています。本セッションでは、AWSを題材に、コロナ前、2019年頃からのAWSサービスアップデートや技術トレンドを振り返りつつ、サーバーレス技術が活用されている代表的なEDAを紹介します。 ※なお、AWSの「サーバーレス」は、人によりイメージするものが異なる可能性が高いため、セッション冒頭で本セッションでの「サーバレス」の定義をご説明します。

cyberarchitect

September 23, 2023
Tweet

More Decks by cyberarchitect

Other Decks in Technology

Transcript

  1. 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
  2. 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の方々と並 ぶ「サーバーレススター」なのです!!!
  3. 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
  4. 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
  5. 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
  6. 11 Event Driven Architecture(EDA)のおさらい(1/2) Event Driven Architecture(EDA、長いので「イベント駆動」と省略します)の登場人物。イベント駆動の定義 は情報ソースによって差異がありますが、今回はAWS社の定義*1に則るものとします。 イベント プロデューサー

    イベント ルーター/バス/ ブローカー イベント コンシューマー *1 イベント駆動型アーキテクチャ イベントとは ・・・ システムの状態が変更されたことを示すシグナル
  7. 12 Event Driven Architecture(EDA)のおさらい(2/2) イベント駆動における、各登場人物の役割。イベント駆動の仕組みを採用することで、登場人物間のつながりは 疎結合となり、登場人物単位のスケーリングや信頼性向上がやりやすくなる。 イベント プロデューサー イベント ルーター/バス/

    ブローカー イベント コンシューマー *参考イベント駆動型アーキテクチャ イベントとは ・・・ システムの状態が変更されたことを示すシグナル イベントを発生させる もの イベントに応じて フィルタや後続処理 への振り分けを行う もの 受信したイベントを 処理するもの 役割 具体例 ✓ S3 ✓ API Gateway ✓ Web/モバイルアプリ ✓ EventBridge ✓ SNS ✓ SQS ✓ Kinesis Data Streams ✓ Lambda ✓ Step Functions ✓ Kinesis Data Firehose
  8. 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 エラー 通知 ⑤可視化へ
  9. 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 ステートマシン 実行
  10. 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をデプロイし、アプリ/インフラの境界 なくコードで管理する未来がくる・・・のか・・?