目次

AWSユースケース学習: 予約受付スロット管理API

0. この資料で作るもの

予約枠の受付・更新を行うAPIを提供する。

項目 内容
主な機能 API Gateway連携、Lambda処理、監視運用
非機能要件 運用容易性、コスト効率、基本可用性
想定規模 同時利用 1,000
主な利用サービス API Gateway, Lambda, DynamoDB, SQS, CloudWatch

1. 構成図

architecture-beta
    service user(internet)[User]

    group vpc(logos:aws-vpc)[VPC]
    group pub[Public Subnet] in vpc
    group prv[Private Subnet] in vpc
    service n1_api_gateway(logos:aws-api-gateway)[API Gateway] in pub
    service n2_lambda(logos:aws-lambda)[Lambda] in prv
    service n3_dynamodb(logos:aws-dynamodb)[DynamoDB] in prv
    service n4_sqs(logos:aws-sqs)[SQS]
    service n5_cloudwatch(logos:aws-cloudwatch)[CloudWatch]

    user:R --> L:n1_api_gateway
    n1_api_gateway:R --> L:n2_lambda
    n2_lambda:R --> L:n3_dynamodb
    n2_lambda:B --> T:n4_sqs
    n2_lambda:B --> T:n5_cloudwatch

構成図サービスリンク


2. サービス選定表

レイヤー 主要サービス 採用理由
Edge/API API Gateway / CloudFront / WAF 公開境界を統制しやすい
App/Workflow Lambda / Step Functions / EventBridge 変更に強く自動化しやすい
Data S3 / DynamoDB / Aurora 用途別に性能と整合性を最適化
Ops/Sec CloudWatch / KMS / CloudTrail 監視・暗号化・監査を統合

3. リクエスト処理シーケンス

sequenceDiagram
    User->>API Gateway: リクエスト
    API Gateway->>Lambda: 認証/入口制御
    Lambda->>DynamoDB: 業務処理
    DynamoDB->>SQS: データ更新
    SQS-->>User: 結果応答

4. データモデル(例)

論理データ 用途
booking_entities / booking_events / booking_audit ユースケースで中心となるデータ

ポイント:

  • 認可境界を意識したキー設計にする
  • 監査/再処理のためイベント履歴を保持する

4.5 クラス図(アプリ構造)

classDiagram
    class Controller {
      +handle(request) Response
    }
    class UseCaseService {
      +execute(command) Result
    }
    class Repository {
      +save(entity)
      +find(query)
    }
    class EventPublisher {
      +publish(event)
    }

    Controller --> UseCaseService
    UseCaseService --> Repository
    UseCaseService --> EventPublisher

5. API設計(例)

POST /booking-slot-api/events, GET /booking-slot-api/status/{id}, GET /booking-slot-api/metrics

認可方針:

  • エッジで認証し、ドメイン層で認可を強制する
  • ユーザー/テナント境界を越えるアクセスを禁止する

6. 実装ステップ(最短)

Step 作業 完了条件
1 データ/イベントモデル定義 主要ユースケースが表現できる
2 API + ワークフロー実装 正常系が通る
3 監視/通知/アラート設定 異常を検知できる
4 負荷/障害テスト SLOを満たす

7. 監視と運用

対象 指標 しきい値例 対応
API 5xx率/レイテンシ(p95) SLO逸脱(99.9%未達) 直近デプロイ差分と依存障害を確認
非同期処理 遅延/滞留件数 5分以上の継続増加 コンシューマ増強・DLQ再処理
データ層 エラー率/スロットル 継続発生 キー設計・クエリ・キャパシティ見直し

8. コスト見積もり観点

サービス群 主課金軸 最適化ポイント
Compute 実行回数/時間 無駄実行削減
Data 保存量/IO ライフサイクルと圧縮
Network 転送量 キャッシュと配信最適化

8.5 料金例(目安)

前提トラフィック: 月間 10万リクエスト / データ転送 200GB / 保存 500GB

規模 月額目安 主な前提
小規模 $50-150 / 月(約¥7,500-¥22,500) 単一リージョン、最低限の冗長化
中規模 $150-400 / 月(約¥22,500-¥60,000) 本番運用、監視/バックアップ標準実装
大規模 $400-900 / 月(約¥60,000-¥135,000) 高可用構成、ピーク対策、長期保管を含む

コストドライバー上位: API Gateway, Lambda, DynamoDB

注意:

  • 上記は学習用の概算レンジ
  • 正式見積もりはAWS Pricing Calculatorで試算

9. 次の発展課題

  • Blue/Greenデプロイ
  • マルチリージョンDR
  • IaC完全自動化(CDK)
  • セキュリティ運用の自動化

10. リスクと対策

リスク 影響 予防策 検知/復旧
想定外トラフィック急増 レイテンシ悪化/エラー増加 オートスケール閾値と負荷試験を事前実施 CloudWatchアラーム + 段階的スケール
権限設定ミス 情報漏えい/操作不能 最小権限ポリシー + 定期棚卸し CloudTrail監査 + 直近変更ロールバック
依存サービス障害 一部機能停止 非同期化・リトライ・フォールバック設計 DLQ/再実行手順で復旧