目次

AWSユースケース学習: 知財文書機密検索基盤

0. この資料で作るもの

機密文書をアクセス制御付きで検索可能にする。

項目 内容
主な機能 OpenSearch Service連携、KMS処理、監視運用
非機能要件 高可用性、高信頼性、セキュリティ統制
想定規模 同時利用 100,000
主な利用サービス OpenSearch Service, KMS, IAM, S3, CloudTrail

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 n2_kms(logos:aws-kms)[KMS] in pub
    service n1_opensearch_service(logos:aws-opensearch)[OpenSearch Service] in prv
    service n4_s3(logos:aws-s3)[S3] in prv
    service n3_iam(logos:aws-iam)[IAM]
    service n5_cloudtrail(logos:aws-cloudtrail)[CloudTrail]

    user:R --> L:n2_kms
    n2_kms:R --> L:n1_opensearch_service
    n1_opensearch_service:R --> L:n4_s3
    n1_opensearch_service:B --> T:n3_iam
    n1_opensearch_service:B --> T:n5_cloudtrail

構成図サービスリンク


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->>OpenSearch Service: リクエスト
    OpenSearch Service->>KMS: 認証/入口制御
    KMS->>IAM: 業務処理
    IAM->>S3: データ更新
    S3-->>User: 結果応答

4. データモデル(例)

論理データ 用途
confidential_entities / confidential_events / confidential_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 /confidential-doc-search, GET /confidential-doc-search/{id}, GET /confidential-doc-search/health

認可方針:

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

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

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

7. 監視と運用

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

8. コスト見積もり観点

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

8.5 料金例(目安)

前提トラフィック: 月間 5,000万リクエスト / データ転送 20TB / 保存 20TB

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

コストドライバー上位: OpenSearch Service, KMS, IAM

注意:

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

9. 次の発展課題

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

10. リスクと対策

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