いらっしゃいませ。わたしは@shnskfjwrです。
わたしは毎日すごい量のServerless.ymlを書いていますが、だれにも読ませるつもりはありません。
ですが、わたしは最近ベガスに行き、さまざまなAWSタフガイ達からインストラクションを受け、ついでに所持金を1024倍にしました。
せっかくなので、一番興味深かったセッションの内容を読者のみなさんに共有します。
セッション概要
大規模サーバーレス：設計パターンと最適化
原題: Serverless at scale: Design patterns and optimizations
日時: 2019/12/2, 2:30 PM - 3:30 PM
場所: ARIA Resort & Casino
話者: Roberto Iturralde
※英語スキルが無いため、スライドベースの雑訳となります
セッション内容(雑訳)
大規模サーバーレスのネック
大規模なサーバーレス環境を構築するにあたり、ネックになるのは以下の6つです。
- タイムアウト
- API Gateway のタイムアウト(29秒)
- Lambda 実行時間のタイムアウト(15分)
- Lambda-RDS 間のコネクション数※
- スループット
- Lambda の依存関係
- Lambda の同時実行数制限
- SecretManager の同時実行数制限
- CloudWatch Metrics の同時実行数制限
※RDS Proxyの発表はこのセッションより後(だったと思う)
例えば、同期型サーバーレスAPIのイラッとくるポイントはこんなところでしょう。
- DBの負荷がクエリのパフォーマンスに影響し、Lambdaの実行時間が伸びる
- Lambdaの実行時間が長くなるとコストが増加するうえ、API Gatewayのタイムアウト(29秒)が発生する
- Lambdaのタイムアウト(15分)も発生する
- Lambdaの同時実行数制限によりAPI Gatewayがエラーになる
- SecretManager や CloudWatch Metrics の同時実行数制限に引っかかるかもしれない
まとめるとこんな感じです。1つずつ解消していきましょう。
SecretManager の同時実行数制限の最適化
Lambdaハンドラーの外部でSecretを取得します。Secretは初期化時に取得されます。
より頻繁に更新するユースケースでは、ポリシーで有効期限を設定した上でキャッシュします。
CloudWatch Metrics の同時実行数制限の最適化
CloudWatch Launches Embedded Metric Format(EMF)を使用します。
指定された形式で標準出力に記録することにより、CloudWatch が非同期でメトリクスに変換してくれます。
参考URL： https://aws.amazon.com/jp/about-aws/whats-new/2019/11/amazon-cloudwatch-launches-embedded-metric-format/
しかし…
残りはどうしましょう？
重要な問題
重要な問題、それは「そのAPIはレスポンスが必要か？」ということです。
APIレスポンスが不要の場合
いいえ、知る必要があるのは
- リクエストが正常に処理されたこと
- ペイロードが永続的に保存されたこと
だけです
APIレスポンスが不要の場合は、次の構成が可能です。
- API GatewayをSQSに直接統合します。リクエストがSQSに保存されると、API Gatewayはレスポンスを返します。
- SQSをLambdaのイベントソースとして設定します
- Lambdaは予め指定された同時実行数に従って動作し、RDSのコネクションを制御します
SQSは障害対策(DLQ)をお忘れなく。
まだLambda本体のタイムアウトが発生している場合は…
これ(左)をこれ(右)に替えてください。
つまりStep Function です。
並列で動かせるロジックはStep Function化しましょう。
APIレスポンスが必要の場合
はい
処理を続行するにはレスポンスが必要です。
APIレスポンスが必要な場合に考慮すべきポイント
- API Gatewayの制限
- スループットを低く
- クライアント側からリトライできる仕組みが必須
- クライアントへの影響
- データベースの選定
- Aurora Serverless
- DynamoDB
- 将来機能強化された他サービス
- 同期から非同期への基本パターン
- Polling
- Webhooks
- WebSockets
API非同期化の3パターンを説明。
Polling
- クライアントはリクエストを送信し、requestIDを受け取る
- バックエンドのサービスは非同期で動作し、ジョブステータスを更新する
- クライアントはジョブステータスに対してポーリングを実施する
- ジョブステータスが完了であるならば、クライアントは結果を取得する
- メリット
- クライアントの変更が最小限
- 既存のバックエンドをラップできる
- デメリット
- ポーリング頻度によっては応答が遅延する
- クライアントとサーバーのリソースが無駄遣いされる
Webhooks
※(オプション)クライアントとサービスの間で信頼関係を結ぶ
- クライアントはリクエストを送信し、API Gatewayはキューを保存したらレスポンスを返す
- バックエンドのサービスは非同期で動作する
- ジョブの完了後、バックエンドがクライアントにコールバックする
- メリット
- ポーリングを行わないため、サーバーとクライアントのリソース集約度が低い
- SNSは配信の再試行を行う
- デメリット
- クライアントがWebエンドポイントをホストする必要がある
- 再試行ポリシーが必要
- for untrusted clients, you are responsible for clients demonstrating trust and retries
WebSockets
- クライアントはリクエストを送信し、SFnの実行ARN、OpenConnワーカーのタスクトークン、およびWebSocketエンドポイントを受け取ります
- クライアントはSFnの実行ARNとタスクトークンを使用してWebSocketエンドポイントへの接続を開きます。LambdaはOpenConnタスクを完了します
- DoWork(SFnのタスク)が完了すると、SFn並列状態が完了し、コールバックを送信します
- クライアントはWebSocket経由で更新を受け取ります
- メリット
- OpenConnection を介した直接の通知であること
- クライアントのためより豊富なイベントであること
- Webおよびモバイルクライアントフレンドリー
- デメリット
- WebSocketプロトコルと関連ライブラリの知識が必要
- WebSocketはすべてのブラウザでサポートされているわけではありません
- 1秒あたり500接続の制限があります
参考URL： http://bit.ly/aws-poll-to-push
まとめ
- 負荷テスト。各種サービスのスケーリング動作を理解すること。
- コンポーネントを分離すること
- リトライはバックオフとともにあること
- バッチ処理を活用すること
- don't orchestrate code in Lambda(おそらくSFnを検討すべきという意)
- 可能な限り非同期パターンを利用すること
感想
たとえ英語スキルが十分であったとしても、きちんと理解できたか非常に怪しいものではありますが、今後の開発に取り込める部分は多々あると感じました。
なお、本セッションはすでに動画が公開されています。
本記事で紹介できなかった内容もたくさんありますので、興味をもった方は動画を御覧ください。わたしが聞いた時は(多分)なかったRDS Proxyへの言及もあります。
https://www.youtube.com/watch?v=dzU_WjobaRA