【AWS Innovate】【2023/10/26】サーバレスセッションまとめ

概要

2023/10/26開催のAWS Innovateのうち、サーバレス関連セッションをまとめました。
(基本的には資料からの抜粋となります)

なお、本AWS Innovateは2023/10/30までオンデマンド公開中になります。
※各セッションの資料のみダウンロードすることも可能
また、アンケートに回答することで 25 USD の AWS クレジットを獲得できます。

内容

T2-1：サーバーレスで開発したときに直面するブロッカーとは何か、どのように解決していくか

ゴール

• コンセプトの理解
• サーバーレスのよくあるブロッカー
  - サービス固有のリソース制限
  - 開発手法に関する戸惑い
  - サービスの組み立て方の理解
  - 推測が難しいコスト見積もり

まとめ

• コンセプトについて

  • 企業の背景として、ビジネスロジックの構築に集中したい
  • ただし「ビジネスロジック=サービス」ではない
    • ビジネスロジックはサービスの一部分でありサービス運営には色々な非機能要件が存在している(セキュリティ/ログ・メトリクス/デプロイ方法)
    • 非機能要件では独自開発ではなく、AWSのサーバレスサービスの一任することで重要なビジネスロジックに注力することができる。

• サーバーレスのよくあるブロッカー

  • サービス固有のリソース制限
    • サーバーレスでは大きな処理を一つ持つより、小さな処理を並列で実行する
  • 開発手法に関する戸惑い
    • コンテナによるパッケージングや、普及している WEB フレームワークを持ち込む方法が充実してきている。
  • サービスの組み立て方の理解
    • サーバーレスのアーキテクチャパターンをカタログ的に利用して、小さなコンポーネントからはじめて、大きく仕立てていく。
  • 推測が難しいコスト見積もり
    • 概算見積もりをしておき、早めにパイロットでの実績費用を確認する。その後正式見積もりを。

セッションメモ

• ビジネスロジックに集中したい

  • ビジネスロジックはサービスの一部分であり、サービス運営には色々な非機能要件が存在している(セキュリティ/ログ・メトリクス/デプロイ方法)
  • 非機能要件では独自開発ではなく、AWSのサーバレスサービスの一任することで重要なビジネスロジックに注力することができる。
    

• サーバレスによる代表的な効果

  • サーバ管理不要
  • 柔軟なスケーリング
  • 十分に考慮された高可用性
  • アイドル時のリソース確保が不要

• サーバレスとブロッカーについて

  • サーバレスのよくあるブロッカー
    • サービス固有のリソース制限
      • Lambda15分制限など
    • 開発手法に伴う戸惑い
      • サーバを意識しないということは、サーバにSSH接続して中に入ることができない。
      • 従来利用のフレームワーク等が扱えるのかわからない
    • サービスの組み立て方の理解
      • サービス単体ではなく、サービス同士(SQSと一緒に利用等)の組み合わせを把握する必要がある
    • ★コスト推測が困難
      • スケールアウト/インが自動処理されるから

サービス固有のリソース制限

• ブロッカー：Lambdaの15分利用制限など
• 解決方法：AWSサービスを用いた並列処理
• よくあるユースケース
  • S3にファイルをput→Lambdaをトリガー
    • 大規模CSVや音楽ファイルは肥大になりがち、Lambdaでファイル分割して処理するれば良いけどどうやる？(1ファイルが15分以内に終わるように処理したい・・)
    • 分割実行部分をAWS側でやってほしいサービスをユーザが求めていた
      • 解決するサービス：AWS Step Functions Distributed MAP

        • S3に格納されたCSVファイル内のビジネスロジックを適用して処理を行う
          

        • 100レコードとか指定サイズに分割して後段のLambdaに並列処理させた後、出力結果はまとめて取得することができる。

      • AWS Step Functions Distributed MAP導入メリット
        • 処理高速化
        • スケーラビリティ
        • コスト削減
          

開発手法の戸惑い

• ブロッカー：従来のサービスはファイルシステムを使いたがる

• 解決方法：従来と同様に利用できるサービス適用、または載せ替え

  • 理由としては「既存アプリの仕様で多い」「スキルセットの都合」
  • Lambdaで扱えるファイルシステム「Lambdaの/tmp　MAX10GB」「EFS」これらは従来のファイルシステムとしてアクセス可能または、「AWSSDKで接続可能なS3(オブジェクトストレージ)」

• ブロッカー：フレームワークを使いたいが、フレームワークのサイズが大きすぎてパッケージサイズが足らない

• 解決方法：コンテナパッケージを利用しよう

  • そもそもLambdaはZIPパッケージとコンテナパッケージから選択可
  • ZIP:最大250MB,コンテナ最大：10GB
    • メリット：コンテナサービスのビルドパイプラインを作成することでパッケージ手法を統一することができる
    • Zip形式の継続利用でも同じ手法がとれる
      

• ブロッカー：既存のWebフレームワークを使用したい

• 解決方法：「web-adapter」を利用することで「Lambdaイベント」をHTTPに変換可能。変換するとWebアプリとしてLambda関数にデプロイされたWebAPのWEBフレームワークで扱いやすくなる。

  • 結果はHTTPからLambdaイベントに変換されて各種サービスに帰って行く。
    

サーバレスサービスの管理者について(閑話)

• 従来通りインフラチームが管理する場合は、以下デメリットがある。
  • Lambda,API-GateWayがインフラ管理だとリソース払い出し設定変更申請などがあり、アジリティがでない
  • 理想はLambda関数/API-Gatewayエンドポイントクリエイトとかはアプリチームの権限とする。
  • その場合インフラ担当は何するの？
    • インフラは可観測性基盤/アカウント統制/認証統制など

組み合わせ

• ブロッカー：SQS,API-GWなどサービスごとの組み合わせがわからない

• 解決方法： サーバレスの重要項目は、サーバレスパターンの組み合わせでつくれる。サーバレスはとにかくパターンに当てはめること

  • 業務系APIで求められること

    • 通信をインターネット経由にしたくない(閉域網がいい)
    • オンプレミスと連携したい
    • レガシーシステムのモダン化
    • 基幹システムへのリクエスト制限

  • 事例：業務系APIで求められがちなオンプレミスからAPI-GWへのアクセス

    • インターネットアクセスは不可にしつつVPC内でAPI-Gatewayの利用を可能にする
      

  • 事例：ログデータ・収集分析など

    • 用途に応じてサービスの利用を分ける
      

  • 事例：サーバレスパターンのまとめ

    • 枯れた既存のパターンを使用するのが一番良い
      

推測が難しいコスト

• ブロッカー：Lambdaは導入しやすいけど実績が少ないから費用感がわからない
• 解決方法：事例を参考に概算見積&パイロット版の導入

  • ほしい概算見積(プロジェクト企画/検証フェーズに進む予算感)の粒度

    • アクティブ会員数：10000
    • 月額金額：1000$

  • ほしい正式見積(本番稼働及び今後の費用予測)の粒度

    • 初年度：xxx$
    • 次年度：成長率を係数とした費用感

  • やり勝ちな見積
    

  • 概算見積の解決方法：例示アーキテクチャ図に係数をかけて見積もる。

  • 正式見積の解決方法：パイロット環境を構築し、パイロットでの実績を元に見積
    

T2-2：サーバーレスを“安全・安心”に使うためのパターン集

ゴール

• 安全・安心にサーバレスを扱うための理解
  - サーバーレスにおける責任範囲
  - 安全・安心に利用する為の機能とパターンについて

まとめ

• 安全・安心なサーバレスを実現するためにはサービスの可用性だけでなく、繋ぎ目を意識する必要がある
• 懸念事項は多数存在する
  • メモリ
  • 脆弱性
  • コストデプロイ
  • 可観測性
  • 通信
  • ダウンストリーム
  • etc

セッションメモ

• 安全・安心の定義
  • 安全：危険が無く安心なこと
  • 安心：気にかかることがなく落ち着いていること
  • サーバレスを使う上での安全安心
    • インフラ運用を行わなくてもいいから安心・安全ともいえる
    • ただしコスト/セキュリティは顧客管理なので、サーバレスで利用できる機能を用いて安全・安心を確保する必要がある
• サーバレスの安心・安全を別の見方をすると？
  • サーバレスの安全・安心＝つなぎ目の安全・安心
  • コンポーネント数が増えて疎結合に繋いでいるため、「増えたサービス・DB・オンプレ」や開発手法の違いなどを境目としてみると良い
    

メモリ管理

• 従来手法：1つのサーバ内でマルチスレッド処理
• Lambda：実行環境は独立、しかしリクエスト単位でInstanceが使いまわされる
  • 同一のLambda関数を複数のユースケースで再利用する場合など、再利用時のmemoryから意図しない漏洩はユーザ側で考慮が必要
  • ユーザはメモリ上に重要データを格納しないことや破棄をする必要があることを考慮すること
    

脆弱性対応について

• 従来手法：サードパーティのセキュリティエージェント管理
• Lambda：Inspectorを有効化することで継続的なスキャンが可能
  • Securityhub,EventBritgeと連携しているから検知後の通知/対応の自動化が可能になる
    

コスト検知について

• Lambdaへの不安：知らないうちに使いすぎてコストを使いすぎてしまう。
• 解決方法：BillingサービスのBudgetを設定して日ごとに検知

コスト最適化について

• Compute Optimizer
  • Lambdaのプロビジョニングが最適なのか確認可能となる。
  • 推奨内容として現在の設定に対してオプションの提示もしてくれる

コスト最適化/パフォーマンスの最適化

• 従来手法：メトリクスを監視しながらテスト/チューニング
• Lambda：Lambda Power Tuningを使えば楽にチューニング
  • AWS Step Functionsを利用したチューニング用ステートマシンであり、Lambda関数のコストやパフォーマンスを最適化
  • 情報をjson形式で渡した場合、Lambdaの処理時間とコストの推移を確認できる。
  • コストとパフォーマンスのバランスを図で確認できる
    

デプロイについて

• Lambdaを安全にデプロイする方法
  • Lambdaへの不安：デプロイした瞬間に本番反映されてしまうのではないか
  • Lambdaでも「トラフィックのルーティング」「移行方式」の設定が可能
    • トラフィックシフト機能
      • Lambdaの新バージョンv2をリリースする場合
    • AWS SAMでも同様に線形/カナリアリリース実施が可能だからIacでも問題ない
• API Gatewayを安全にデプロイする方法
  • 自分でカナリアリリース機能を保持している
• AppConfigを利用したデプロイパターンについて
  • アプリケーションの設定を作成/管理し迅速にデプロイする機能
    • 特定のEnvやパラメータを元にA/Bテスト
    • 特定の機能解放の遠隔操作
    • Lambdaを利用してアプリケーションの設定変更を行える

可観測性について

• 大事なのはログを落としてトレーサビリティを確保すること

  • 解決方法：埋め込みメトリクスフォーマット

    • 構造化ログイベントに埋め込まれたメトリクス値を自動的にCloudwatchLogsに抽出できるようにする機能
    • 以下形式のログ出力は並列Lambdaでも対応可能かつLoggerの管理は不要となる(便利すぎ)
      

  • 解決方法：AWS Lambda Powertools(ライブラリ)を使えば埋め込みメトリクスを簡単に設定できる

    • 目的はObsirvabilityの実装を簡単に行うことができる
    • リクエストIDをカスタムログ情報として出力させてトレーシングをさせやすくなる(X-rayに有効)
    • 埋め込みメトリクスを簡単に出力できるLogger機能/Tracing/Metricsを加えた3つが主な機能となる
    • ちなみに従来のPUTMetricData APIで送付することも可能だったが、秒間150回という上限でスロットリングされる。
      ※埋め込みフォーマットは非同期なのでスロットリングされない
      
    • フィルタをかけてログを確認するのも有用な方法となる
      
    • やっぱりXrayが便利。直観的かつ詳細をドリルダウンできる
      • Lambda Power ToolsでTracerを使用することでXraySDKを使用しなくても、サブセグメントの作成が可能になる。

  • 解決方法：LambdaExtensions

    • 通常の仮想サーバではエージェントを常駐させてメトリクスを取得する
    • 通常Lambdaでは常駐ソフトが使用できないが、別プロセスで利用することが可能となる。
    • 別プロセスでモニタリングエージェントの配置が可能。
      • Lamdaのinvoke,shutdowsなどライフサイクルをトリガーに診断情報の取得、実行関数コード計測,処理前にシークレット情報の取得

  • 解決方法：Lambda Insights Performance monitaring

    • Lambdaのモニタリング/トラブルシュートに利用
    • CPU時間メモリディスクネットワーク利用率などシステムレベルのメトリクスで取得可能
    • 従来であればSSHで確認するような、コールドスタート/ワーカーシャットダウンなどの診断情報も集約されている

通信

• 基本はリソースポリシー
• VPC内のリソースにアクセスするためには、VPC Lambdaを利用
  • VPC リソースへのアクセスに、Lambda 関数を VPC 接続設定
    する必要がある
  • この機能を使えば、LambdaがVPC内のリソースに接続ができる
    ※ただし、VPC内に閉じてしまう。LambdaはVPCのENIを使ってアクセスするがパブリックIPを付与できないため外に出れなくなる
  • インターネットアクセスするためには
    • Public Subnet に NAT Gateway を設置
    • Internet Gateway を VPC に設置
    • Route Table でインターネットへの経路を追加
  • リージョナルサービスへアクセスするには (以下のいずれかが必要)
    • インターネットへの経路を確保
    • サービスごとの VPC Endpoint を利用

ダウンストリームの保護

• API GatewayとLambdaの間にSQSを挟む
  • キューやストリームのバッファリングによって受け取りトランザクション数を抑制することでコンポーネントのスループットを調整

T2-3：サーバーレスで実現する大規模メッセージング処理とワークフロー

ゴール

• サーバレスサービスを使って大規模なメッセージング処理やワークフローを組むための考慮点の理解
• メッセージング処理が大規模になった場合のよくある課題と
  それに対するソリューション・プラクティスを理解

まとめ

• メッセージの順序性、重複性とスループット
  • SQS Standard, FIFO の特性と使い分け方
  • メッセージグループの単位
  • メッセージの順序性、重複性の保証が必要なのか、立ち止まって考え直す
• 高い分散処理、スケーラビリティ
  • AWS Step Functions Distributed Map による分散処理
  • AWS Step Functions の AWS サービス統合

セッションメモ

そもそもメッセージング処理とは

• 複数のアプリケーションやシステムにおいて相互に通信を行うための方法
• 送信元と受信元を非同期に連携できる
  • 送信元は受信元の処理を待たなくても良い〇
    • 送信元：レスを待たないからパフォーマンス向上
    • 受信元：ユーザ体験の向上
    • ブローカーは分散されたデータストアにデータが格納されるから耐障害性を向上できる
    • Consumerを自動的にスケールインアウトができる
    • Consumer側のデータシステムに問題があっても問題なし。
    • Brokerに貯めているメッセージに対してコンシューマ側がスケール可能
      

大規模メッセージング処理における課題

• 連携先システム増加/キュー増加な処理
• 課題
  • メッセージの「順序性/重複性」と「スループット」はトレードオフになる
  • 月末大量処理とか1万を超えるワークフローなどどのように対応すればいいのか？
  • メッセージの順序性/重複性
    • メッセージの順序性はキューなどのブローカーを介すことでメッセージ取得の順序が変わってしまう

      • Consumer側でどのように設計？いかに順序性を保証する必要があるのか検討する必要がある。

      • メッセージの重複性は2重の処理が許容できるのだろうか

      • あるいは重複配信されたメッセージを後続処理で冪等性の担保ができるのか

      • 重複性の観点

        • at-least-once
          • 少なくとも1回以上配信
          • 冪等性のある処理が必要(Consumer側で何回実行しても同じになるような処理)
        • Exactly once
          • 確実に1回配信
          • 重複性排除の一意となるIDの付与が必要
          • パーティション/メッセージグループなど抽象化された中で一意
            

      • 順序性の観点

        • 順序保証なし
          • メッセージが入れ替わって配信される
        • 順序保証あり
          • 全てのメッセージに保証されるわけではなく、パーティション/メッセージグループなどの中で順序が保証される
          • Kinesisはシャードで一意だがFIFOキューはメッセージグループなどで抽象化されたものを使用
            

SQS(standardキュー)の断面図

• 内部に分散されたストレージを持ち、そこに分散しているため可用性が高い
• 高い可用性を確保するために、メッセージのコピーが複数のサーバに記録されますが、メッセージを削除するときにメッセージのコピーが保存されているサーバが使用できない場合がある。
  その場合、メッセージのコピーが削除されずもう一度同じメッセージを受け取ってしまう
  

SQS(FIFOキュー)の断面図

• 順序性・重複性とスループットはトレードオフ
  • スループットが制限される理由は分散されたSQSサーバ間で整合性を取らなければいけないから
    

キューの設計ポイント

• コンシューマ側で2重に処理しないための工夫が必要

  • SQS(Standard)

    • 永続化層を準備することで、配信を逐次チェック。重複していた場合は破棄するようにする
      

  • SQS(FIFO)

    • キュー側で重複排除ができる
      • ただし、MessageBodyでIDが生成されるため、全く同じメッセージボディを別で処理したい場合はProducer側で重複排除IDを生成する必要がある
      • Consumer側の処理についてFIFOキューの場合でも、Consumerがメッセージを受信してもキューを削除しない場合があるから、DynamoDBを永続化層として用意するのが無難
        

キューだけでなくLambdaの処理を冪等にしたい場合は

• 要件：決済処理/注文処理など
• 解決方法は：AWS Lambda Powertools
  • オープンソースのユーティリティライブラリ
    • トレース、ロギング、冪等性、カスタムメトリクスなど

SQSにおける大規模メッセージング特有の課題について

• FIFOキューでも300TPS以上のスループットを出したい
  • 順序性・重複性を保証したいグループや単位を考えることから始める
  • とりあえずFIFOが必要なのか再検討する必要がある。
  • 特定条件にのみFIFOを保証する場合などがある
    
    
  • その場合Standardキューを利用することで、FIFOの性能も向上する
  • プロデューサー側がStandardとFIFOにルーティングするから、負担が増えるかと思いきや、EventBritgeを挟むことで簡易化することが可能
    

順序性は本当に保証しなければいけないのか？？

• 順序が入れ替わった場合でも、顧客に不利益がなければシステムとして成立する
• 結果が変わらない書類作成、上書きしても良い処理などは順序性を気にしない
• 注文処理、チケット予約、金融系のトランザクションなどは順序性を保証したい
• 順序性を保証したい場合は？
  • メッセージグループ単位に順序性を保証したい単位を考える

高い分散処理が求められるケース

• CSV ファイルの１行ごとに帳票を作成する夜間バッチ

• 月末、年末は特にリクエストが多く、直列処理では夜間に終わらない

• 大量の画像ファイルに対して、サムネイル画像を作成したい

• １つの動画コンテンツを５分ごとに分割し、字幕や GIF 画像を作成したい

• 大規模分散処理で有効な手段

  • StepFunctionDistributedMap
    

• 通常のStepfunctionでは40だがこの機能で10000並列処理

• ★S3を入力元として直接大規模データを読み込むことができる。

• 画像ファイルのサムネデータの加工など分割して処理できるよ

• S3にCSVファイルが入っている場合、特定の行数単位にネストされた子ワークフローに対してデータをわたし、データを処理する

• 子ワークフローに渡されたデータを元に処理ができる

• まずはLambdaで処理を行うデータベースから帳票作成に必要なデータを取ってくる

  • これで分散処理できるから効率が大変良い。
  • スロットリングエラーが怖ければ同時実行数を制限できる
    
  • Lambdaを使わなくても処理が進められる
  • Lambadaがなければコストも安価だしスロットリングも無くていい
    

StepdfunctionからAWSを呼び出すパターン

• Requestresounce
  • 同期的処理
    
• ジョブ実行
  • 非同期的処理
  • このジョブ実行パターンはLambdaやAWS Batchなど非同期サービスを簡単にワークフローに組み込める
    
• Callback
  • 外部からの実行結果をまつ
    

参照先

AWS Innovate Modern Applications