AWS主催の『イチから理解するサーバーレスアプリ開発』に参加してきました

5/9(木)に開催されたAWS主催のSeverlessの開発に関するイベントに参加してきました。 場所はAWS Loftで満席に近く、Severlessの注目度が高いなぁと改めて感じました。

Agenda

• サーバーレスのおさらい
  • 利用パターン、事例および主要サービスについて
• サーバーレスアプリケーション向きのDB設計ベストプラクティス
• エラー制御・監視の勘所

サーバーレスのおさらい

• 登壇資料は以下になります。

https://d1.awsstatic.com/serverless-jp/seminars/20190509_serverless_public.pdf

• サーバーレスとは
  • サーバがないということはなく、サーバの存在を意識しない
    • サーバー管理は不要
    • 柔軟なスケーリング
    • 十二分に考慮された高可用性
    • アイドル時のリソース確保が不要
  • ロジック開発に注力できる
    • 責任範囲を小さくできる
  • これまでは３階層構造
    • 規模の見積もり
    • 可用性設計
    • データ保全の検討
  • サーバレスでは
    • 自動スケール
    • 設計済みのリトライ
    • データ信頼性の担保
  • お客様の効果例
    • 生産性が5倍
    • コード量が３分の1に
    • 短期実装可能
  • 利用者がやること
    • アプリケーション設計
    • ロジック開発、DB設計
    • 監視、エラー制御
  • Function as a Service: ：Lambda が代表的
    • 主要コンポーネント
      • 外部IF（API Gateway, Appsync
      • 処理ロジック（Go/Java/Python/Ruby…）
      • データ保持管理（DynamoDB, RDB, SQS, S3)
      • 認証（Cognito）
      • ストリーム（Kinesis）
• リソース管理とエラー制御の基本
  • 不適切なリソース利用の防止 -> 同時実行数
  • 効率的なリソースの再利用 -> 処理タイムアウト
  • 基本的には、処理リソースの単位(ファンクション)でエラー処理を考慮する
    • フロー管理(Step Functions)も可能
• サーバーレすに置けるデータベースの考え方
  • 大量のDB接続リクエストが発生する可能性がある -> RDS側のリソースがパンクする可能性
    • 同時リクエストが少ない or 入り口でスロットリングする
    • DB接続を制御する
    • 分散型のDBを選ぶ -> DynamoDB
• パターンで考える
  • 実戦でよく使われるユースケースパターン

サーバーレスアプリケーション向きのDB設計ベストプラクティス

• 登壇資料は以下になります。

【イチから理解するサーバーレスアプリ開発】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス from Amazon Web Services Japan

• サーバーレスアプリケーションとデータベースの種類
  • LambdaとRDBを利用する際の考慮する事項
    • Lambdaはコネクションをプールする機構がない
    • VPC内リソーアクセス時のコールドスタート
      • ENIを経由する必要がある
  • DynamoDBで解決
    • コネクション数の問題を解決
    • 標準でVPC外リソースで作成される
• データベース設計プロセス
  • DynamoDBのベストプラクティス
    • テーブル数は最小限に
    • PrimaryKeyでデータを識別し、アクセスする
    • グローバルセカンダリインデックスは元テーブルから非同期レプリケーションされる別テーブルのような存在
    • １テーブルや１インデックスに複数種類のアイテムを乗せていい
  • RDBの設計プロセス
    • 業務分析と論理データモニタリング -> ER図
    • 物理データモニタリング -> テーブル定義書
    • アプリ、SQL実装
  • DynamoDBの設計プロセス
    • 業務分析と論理データモニタリング -> ER図
    • アクセスパターン設計 -> ユースケースリスト
      • 従業員情報をID検索する等
    • TableとIndex設計 -> スキーマ定義書
    • クエリ条件設計 -> クエリ条件定義書
  • DynamoDB設計テクニックとして、GSIオーバーローディング
    • https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-gsi-overloading.html

エラー制御・監視の勘所

• 登壇資料は以下になります。

https://d1.awsstatic.com/serverless-jp/seminars/20190509_Serverless_monitor_error.pdf

• DynamoDBの監視とエラー対策
  • ベースラインとして推奨されるモニタリング項目
  • APIとCapacity Unit(CU)の消費
    • APIにより計算の概念が違う
  • CUにまつわるエラー対策
    • バルクオペレーションの最中にエラーが発生した場合、returnに未処理アイテムが返却されるのでアプリケーション側での対処が必要
    • CUはパーティション単位で平均化される。Hotパーティションを作らないような設計が重要
  • TTLの活用
    • TTLはCUを消費しない
  • オートスケールを利用しても、スパイクアクセスの対応は完全対応が難しい
    • APIコントロールがいい場合もある
• Step FUnctionsの監視
  • Lambdaの方よりもStep Functionでスケールできない時もある
  • リトライ、タイムアウトなどをきちんとバンドルする
• Lambdaに関しては以下を参照

開発者におくるサーバーレスモニタリング from Amazon Web Services Japan

• サーバーレスでも運用レスではない

所感

DB設計の話しで、DynamoDBの設計プロセスと設計する際に意識する点はとても参考になりました。 通常のRDBではカラムを横に並べていくが、DynamonDBではGSIを考慮して縦に並べた方が良いということでした。 登壇資料の中の後半にドリル形式でDynamoDBの設計についてあるので、興味がある人はやってみることをお勧めします。