【re:Invent 2022】全サーバーレス開発者のためのベストプラクティス-Session Report
AWS re:Invent 2022で行われた、「Best practices for all serverless developers」のセッションレポートです。
この記事は、要点・見どころ・ポイントについてまとめます。
セッション概要
Title
Best practices for advanced serverless developers
サーバーレス上級開発者のためのベストプラクティス
当日前までは上記タイトルでしたが、説明の冒頭時にタイトル訂正がありました
↓
Best practices for all serverless developers
全サーバーレス開発者のためのベストプラクティス
Overview
Are you an experienced serverless developer? Do you want a helpful guide for unleashing the full power of serverless architectures for your production workloads? Are you wondering whether to choose a stream or an API as your event source, or whether to have one function or many? This session provides architectural best practices, optimizations, and useful cheat codes that you can use to build secure, high-scale, and high-performance serverless applications and uses real customer scenarios to illustrate the benefits.
あなたは経験豊富なサーバーレス開発者ですか？サーバーレスアーキテクチャの能力を本番ワークロードでフルに発揮するための有用なガイドをお望みですか？イベントソースとしてストリームとAPIのどちらを選ぶべきか、また、関数を1つ持つべきか、多数持つべきか、迷っていませんか？このセッションでは、安全で大規模かつ高性能なサーバーレスアプリケーションを構築するために使用できるアーキテクチャのベストプラクティス、最適化、および便利なチートコードを提供し、実際の顧客シナリオを使用してその利点を説明します。
Services
AWS Lambda, Amazon CloudWatch, AWS X-Ray
Session type
Breakout Session
Speakers
- Julian Wood, Developer Advocate, AWS
Youtube
セッション動画が公開されてます
Report
シニアデベロッパー主唱者 Julian Wood氏がブレイクアウトセッション枠で登壇
サービス開発者の育成を目指すため・サーバーレスの機能を理解してもらうためとのことで説明されてました
また実際に紹介されたスライドもアップされてますので興味ある方はご覧になってください
目次
- サーバーレスとは何?
- イベントの状態
- サービスフルなサーバーレス
- 素晴らしいFunctions
- コードとしての設定
- 試作品から商用化まで
1.サーバーレスとは何？
サーバーがあるとかないとかいう問題ではない
- serverless を「考え方」、「アプローチ」、「プラクティス」、「文化」、「働き方」で考えること
- 実現させる技術よりもビジネス価値にフォーカスすること
つまりサーバーレスとは
モダンなアプリケーションの構築と実行に最適な方法であると主張しています
サーバーレス/イベント駆動アーキテクチャ トレードオフについて説明がありました
ここではイベント駆動アーキテクチャも紹介されました
サーバーレス/イベント駆動アーキテクチャのトレードオフについては
- アプリケーションの設計方法の違い
- より多くの可動部品
- 依存関係を理解するのが難しい
- 最終的な一貫性
- 異なるテスト、監視、観察の可能性
- プラットフォームの性能とセキュリティに依存する
「サーバーレスとは何？」のベストプラクティス
- 「サーバーレス」をマインドセットとして考える
- 実現する技術よりもビジネス価値にフォーカスする
- 長期的な保守性を考慮して最適化する
- クラウドの「上」だけでなく、「中」で構築する
- データおよびイベントの流れに集中する = イベント駆動アーキテクチャ(EDA)
2.イベントの状態
同期処理で開発をすると、タスク処理が完了するまで次のタスクが始まらず遅延する原因となってしまうので、非同期処理も取り入れるよう工夫します
例えば用途に応じてAWSサービス SQS,SNS,EventBridge,Kinesisを利用できます
特に先程紹介したEDAについてはEventBridgeが大きく役立つサービスとなります。
EventBridge経由でLambda,SNS,Step Functionsなどの他サービスをトリガーさせることが可能です
「イベントの状態」のベストプラクティス
- イベントはサーバーレス・アプリケーションの言語である
- 非同期および結果整合性を採用する
- 1つまたは複数のメッセージングサービスを使う
- イベントをコンテンツやメタデータで充実させる
- イベントを伴う状態転送：ステートをイベントとして渡す
- トレードオフを考慮
3.サービスフルなサーバーレス
サーバーレスのメインサービスはLambdaを軸に考えます
LambdaランタイムにはNode.js,Python,Java,C#,Go,Ruby,RuntimeAPIの多くのサポートがされていて、開発者に適した言語で実装が可能です
EventソースからLambdaをトリガーしLambdaから他AWSサービスへの書き込みや読み込みなどが実現可能となります
またAWSのサーバーレスアプリケーション開発するうえでLambdaを使う手段もありますが
ここでAWS Lambda関数は必要なのか？という疑問も持たれることもあるでしょう
やはりLambdaの実装するコストを考えると
最速でLowコストのLambda関数を使うよりかはリソースを削除して、組み込み統合に置き換えていくことがより良い選択肢になります
そして実際に自動化させるにはStep Funstionsを活用し、
AWSサービスに対してそれぞれのイベントを振りつける場合はEventBridgeを利用していくのが重要となります
細かい各Serverless workflowsの集約はこちらから参考にしていただければと思います
「サービスフルなサーバーレス」のベストプラクティス
可能な限りサービス統合を利用する
- コードは負債である = コードよりも設定を優先する
- AWS Lambdaは転送ではなく変換として使う
- モノリシックなサービスやfunctionは避ける
- Step Functionsを使って流れを自動化する
- EventBridgeでイベントの振りつけるようにする
4.素晴らしいFunctions
Lambdaの呼び出しモデルは同期処理か非同期処理かで用途が別れます
例えば、図でいうところのALBやAPIGWの同期呼び出し。EventBridgeやS3といった非同期呼び出しがあります
またLambdaのコールドスタート問題が発生しますが、Lambdaハンドラーに対してコールドスタートを考慮しておくことも重要です
- 不要なモジュールは削除
- 共通ライブラリにより遅延を初期化
- 環境再利用時の状態
など
さらにaws-sdkをLambdaに読み込みを行う時に、コーディング次第でLambda呼び出しの時間も異なってくるので十分注意して実装しましょう
「素晴らしいFunctions」のベストプラクティス
異なったLambdaの呼び出しモデルの使い方
- Lambdaのコールドスタート最適化
- 必要なければ読み込まない、共有ライブラリの遅延初期化
- 接続の確立
- 環境再利用時の状態
- ARM/AWSのGraviton2を試す
- メモリが増える＝CPUとI/Oが比例して増える
- 必要な時だけVPCに機能を接続する
- 同時実行とクォータを理解し、同時実行予約とプロビジョニングを適切に設定
5.コードとしての設定
Infrastructure as code (IaC)がここで紹介されました
AWSインフラストラクチャとして自動化を担うフレームワークについて説明がありました
今回はAWS SAMの例を紹介に説明がありましたが、Lambdaから他サービスへのアクセス許可設定で注意しておくべき点としてワイルドカードの流用は避けることです
図の場合、権限が緩めに設定されてる状態あのでセキュリティ上よくないです
サーバーレスパターンとして様々なAWSサービスを組み合わせた構成図一覧も紹介されているので気になる方はぜひチェックしてください
「コードとしての設定」のベストプラクティス
- 需要があるフレームワークを使う
- 馴染み慣れている
"Action": "*"は設定しないこと - ポリシーテンプレートを利用する
- サーバーレスパターン集を発見する
- スタックを分割すること
- ステートフル/長期間のリソースと、よりステートレスなリソースを比較できるため
6.試作品から商用化まで
AWSのインフラサービスをマルチアカウントへデプロイするには再利用可能なインフラストラクチャテンプレート(Cfn)を用意するのがベストです
それぞれのアカウントごとにテンプレートを用意してしまってはコストがかかってくるため、１つのテンプレートに集約してデプロイできるように管理しておきます
またCI/CDフローもAWSが展開しているCode PipelineやCode Buildを活用してオートメーション化を図っていくことが重要です
実際に商用化されたときに非機能となるOps機能も注視しておくと、運用時に役立ちます
例えば
- CloudWatch Canaries
- CloudWatch Metrics
- CloudWatch Logs Insights
などを利用する
「試作品から商用化まで」のベストプラクティス
ローカルでのサービスのエミュレーションを避ける
- ビジネスロジックをローカルでテストし、残りはクラウドでテストする
- AWS SAM accelerateを試す
- バージョン管理された単一のコードベースから再利用可能なテンプレートを構築する
- CI/CDスーパーパワーを作成し、各コミットでビルド/デプロイ/テストする
- 埋め込みメトリクス形式を使用: ログからメトリクスを取得
- flags/Canariesの機能を使い調査する
- Lambda Powertoolsを使う
締め
Serverlessを学ぶにオススメされた情報サイトとして紹介されましたリンクを添付します
再学習やこれから学ぼうとしている方は参考にしてみてはいかがでしょうか
自分自身のペースで学んでいきたい方
サーバーレス知識を強化したい方
会場の雰囲気
- 会場は約300名のキャパで人気セッションのためほぼ満席
- サーバーレストピックがどの国々でも扱われているためか人気セッションの様子
- 技術的な内容が多い印象でした
まとめ
サーバーレスを扱う方を対象に学べる内容となっていました
サーバーレス開発から運用までした経験があると、「これちゃんとやっていることだな」と印象に大きく残っています
経験者とっては、IAMポリシーのワイルドカードは使わないようすることや、Lambdaの同時実行数の設定など普段から気をつけておくことの再学習になると思います
今回スケジュール都合のため、内容としては重要な要素のみピックアップしましたが興味ある方は是非添付したURLから有益な情報を得てもらえたら幸いです
以上
Discussion