1. 要件ヒアリング（質問で情報収集）
   ↓
2. 環境タイプ選択（Dev/Test/Staging/Production）
   ↓
3. アーキテクチャパターン選択
   ↓
4. 各コンポーネントサイジング
   ↓
5. 費用算出
   ↓
6. Markdown + HTML出力

Q: 見積もる環境を選択してください
A) 開発環境 - 開発者が機能開発・単体テストを行う環境
B) テスト環境 - QAチームが結合テスト・E2Eテストを行う環境
C) ステージング環境 - 本番同等構成でリリース前検証を行う環境
D) 本番環境 - 実際のユーザーがアクセスする環境
E) 全環境セット - CI/CDパイプライン含む全環境

Q: 使用するクラウドを選択してください
A) AWS - Amazon Web Services
B) Azure - Microsoft Azure
C) GCP - Google Cloud Platform
D) マルチクラウド - 複数クラウドを併用

Q: ScalarDB Cluster のライセンス形態を選択してください
A) 直接契約 Standard - ¥100,000/Pod/月（基本機能）
B) 直接契約 Premium - ¥200,000/Pod/月（高度な機能・優先サポート）
C) AWS Marketplace Pay-as-you-go Standard - $1.40/Pod/時間（約¥153,300/Pod/月）
D) AWS Marketplace Pay-as-you-go Premium - $2.80/Pod/時間（約¥306,600/Pod/月）※推定

※ ライセンス費用はPod数に応じて課金されます
※ AWS Marketplace版はAWS請求に一本化、短期利用に最適
※ 直接契約は長期利用でコスト効率良好
※ 詳細はScalar社営業担当にお問い合わせください

AWS Marketplace Pay-as-you-go 利用時の制約:
- リソース制限: 各Pod最大 2 vCPU / 4 GB memory
- 制限超過時: Podが自動停止
- 課金単位: 1 Pod = 1単位 (2 vCPU / 4 GB memory)
- 計算方法: max(vCPU/2, memory/4GB) で単位数を決定

メリット:
- AWS請求に一本化
- 契約手続き不要
- 短期利用・PoC向け
- いつでもキャンセル可能

デメリット:
- 長期利用では直接契約より割高
- リソース制限あり

Q: 想定するトランザクション量を選択してください
A) 小規模 - 〜500 TPS
B) 中規模 - 〜2,000 TPS
C) 大規模 - 〜10,000 TPS
D) 超大規模 - 10,000 TPS以上（具体的な数値を入力）

Q: 目標可用性を選択してください
A) 99.0% - 年間ダウンタイム87.6時間まで許容
B) 99.9% - 年間ダウンタイム8.76時間まで許容
C) 99.95% - 年間ダウンタイム4.38時間まで許容
D) 99.99% - 年間ダウンタイム52分まで許容

Q: ScalarDB v3.17 クライアントサイド最適化を有効にしますか？
A) 有効にする（推奨）- 最大2倍の性能向上、900〜2,400 TPS/Pod
B) 有効にしない - 従来性能、500〜2,000 TPS/Pod
C) 検討中 - 最適化の有無で両パターン試算

※ 最適化設定（アプリケーション側）:
  - scalar.db.cluster.client.piggyback_begin.enabled=true
  - scalar.db.cluster.client.write_buffering.enabled=true
※ サーバー側推奨設定:
  - scalar.db.consensus_commit.async_commit.enabled=true
  - scalar.db.consensus_commit.one_phase_commit.enabled=true（単一DB時）

Q: Transaction Metadata Decoupling を使用しますか？
A) 使用する - メタデータを別テーブルに分離（テーブル設計がシンプル）
B) 使用しない（デフォルト）- 従来構成（既存システム互換）

※ Decouplingの特徴:
  - アプリケーションテーブルにメタデータカラムが追加されない
  - 既存テーブルには適用不可（スキーマ作成時に設定が必要）
  - 総ストレージサイズは変わらない

Q: デプロイ戦略を選択してください
A) Rolling Update - 標準的なローリングアップデート
B) Blue/Green - 2系統を切り替える方式（ダウンタイムゼロ）
C) Canary - 段階的にトラフィックを移行する方式
D) A/B Testing対応 - 機能フラグによるA/Bテスト対応

Q: データベース構成パターンを選択してください
A) 単一データベース - 1種類のデータベースのみ使用（シンプル構成）
B) 異種複数データベース - 複数種類のデータベースを併用（ScalarDBの真価を発揮）
C) マルチリージョン構成 - 地理分散されたデータベース構成

Q: バックエンドデータベースを選択してください
[AWS]
A) Aurora PostgreSQL - 高可用性RDBMS（推奨）
B) Aurora MySQL - MySQL互換の高可用性RDBMS
C) RDS PostgreSQL - 標準的なPostgreSQL
D) DynamoDB - NoSQL（高スケール・書き込みヘビー向け）

[Azure]
A) Azure Database for PostgreSQL - 高可用性PostgreSQL
B) Azure SQL Database - SQL Server互換
C) Cosmos DB - NoSQL（グローバル分散向け）

[GCP]
A) AlloyDB - 高性能PostgreSQL互換（推奨）
B) Cloud SQL for PostgreSQL - 標準的なPostgreSQL
C) Cloud Spanner - グローバル分散SQL

Q: 使用するデータベースの組み合わせを選択してください（複数選択可）
[AWS]
A) Aurora PostgreSQL + DynamoDB - RDBMS + NoSQL（推奨パターン）
B) Aurora PostgreSQL + Aurora MySQL - 異種RDBMS
C) Aurora PostgreSQL + DocumentDB - RDBMS + Document DB
D) カスタム組み合わせ - 独自の組み合わせを指定

[Azure]
A) Azure PostgreSQL + Cosmos DB - RDBMS + NoSQL（推奨パターン）
B) Azure PostgreSQL + Azure SQL - 異種RDBMS
C) カスタム組み合わせ - 独自の組み合わせを指定

[GCP]
A) AlloyDB + Cloud Spanner - 高性能RDBMS + グローバル分散SQL（推奨パターン）
B) Cloud SQL PostgreSQL + Firestore - RDBMS + NoSQL
C) カスタム組み合わせ - 独自の組み合わせを指定

[マルチクラウド]
A) Aurora PostgreSQL (AWS) + Cosmos DB (Azure) - クラウド間分散
B) AlloyDB (GCP) + DynamoDB (AWS) - 高性能 + 高スケール
C) カスタム組み合わせ - 独自の組み合わせを指定

Q: アプリケーションアーキテクチャを選択してください
A) 標準構成 - API Gateway + BFF + Process API + System API（推奨）
B) シンプル構成 - API Gateway + Backend API
C) マイクロサービス構成 - 複数のドメインサービス + Event Driven
D) カスタム構成 - 独自のアーキテクチャを指定

Q: API Gatewayを選択してください
A) Kong OSS (DB-less) - 高機能OSS API Gateway、DB-lessモード（推奨）
B) Kong Enterprise (DB-less) - 商用版Kong、高度な機能・サポート付き
C) Kong OSS (PostgreSQL) - PostgreSQLバックエンド構成
D) Kong Enterprise (PostgreSQL) - 商用版Kong、PostgreSQLバックエンド
E) AWS API Gateway - AWSマネージド
F) Azure API Management - Azureマネージド
G) Google Cloud Endpoints / Apigee - GCPマネージド
H) Nginx Ingress - シンプルなIngress Controller
I) 不要 - API Gatewayを使用しない

Q: Kongの構成モードを選択してください
A) DB-less (declarative) - 設定をYAML/JSONで管理、GitOps親和性高い（推奨）
B) PostgreSQL - 従来型、Admin API経由で動的設定変更可能
C) Hybrid Mode - Control PlaneとData Planeを分離

※ DB-lessモードの特徴:
- 設定ファイルをGitで管理可能
- 起動時に設定をロード
- Admin APIは読み取り専用
- Kubernetes環境に最適

Q: 監視システムを選択してください
A) Prometheus + Grafana - OSSスタック（推奨）
B) Datadog - SaaSモニタリング
C) New Relic - APM中心のSaaS
D) CloudWatch / Azure Monitor / Cloud Monitoring - クラウドネイティブ
E) 既存の監視システムを使用

Q: ScalarDB Analytics（分析クエリ機能）を使用しますか？
A) 使用しない - OLTPのみ
B) 使用する（Amazon EMR） - AWS環境でSparkベースの分析
C) 使用する（Databricks） - Azure/AWS環境でDatabricks使用
D) 使用する（両方検討） - EMRとDatabricksを比較検討

Q: ScalarDB Analytics のワークロードを選択してください
A) 軽量分析 - アドホッククエリ、〜100GBデータ、同時1-5クエリ
B) 標準分析 - 定期レポート、〜1TBデータ、同時5-10クエリ
C) 大規模分析 - 複雑な分析、〜10TBデータ、同時10-20クエリ
D) メモリ集約型 - 大規模結合/集計、10TB+データ

※ ScalarDB Analyticsは読み取り専用です
※ Spark 3.4または3.5が必要です

Q: Spark実行環境の詳細を選択してください

[Amazon EMR]
A) EMR on EC2 - 標準的なEMRクラスター
B) EMR Serverless - サーバーレス実行（断続的ワークロード向け）

[Databricks]
A) All-purpose Cluster - インタラクティブ分析向け
B) Job Cluster - 定期バッチ処理向け
C) SQL Warehouse - SQLクエリ専用（JDBC接続）

※ DatabricksはAccess Mode「No isolation shared」が必須

Q: ScalarDB Analytics の課金モデルを選択してください
A) 直接契約（SDBU課金）- 33.5円/SDBU/時間、長期利用・本番環境向け
B) AWS Marketplace Pay-as-you-go - $0.0000232/unit、PoC・短期利用向け

※ 直接契約: 最小6 SDBU、詳細なサイジング計画が可能
※ AWS Marketplace: AWS請求に一本化、いつでもキャンセル可能
※ 詳細は references/scalardb-analytics-sizing.md セクション10を参照

Q: ScalarDB Analytics のSDBU（課金単位）構成を選択してください
A) 最小構成（6 SDBU）- 最小コスト、開発/PoC向け
B) 小規模（12 SDBU）- XL×2台相当、小規模本番
C) 中規模（24 SDBU）- XL×4台相当、標準本番
D) 大規模（48 SDBU）- XL×8台相当、大規模分析
E) カスタム - 具体的なSDBU数を指定

※ SDBU単価: 33.5円/SDBU/時間
※ 最小構成: 6 SDBU（約14.7万円/月・常時稼働時）

Q: ScalarDB Analytics の稼働パターンを選択してください
A) 24/7常時稼働 - 730時間/月（本番環境、リアルタイム分析）
B) 業務時間のみ - 約200時間/月（10時間/日×20日）
C) バッチ処理のみ - 約80時間/月（4時間/日×20日）
D) 断続利用 - 具体的な稼働時間を指定

※ 稼働時間を最適化することでSDBO費用を大幅削減可能

purpose: "開発者の機能開発・単体テスト"
kubernetes:
  nodes: 2
  node_type: small (2vCPU/8GB)
scalardb:
  replicas: 2
  resources: {cpu: 500m, memory: 1Gi}
database:
  size: minimal
  ha: false
api_gateway: optional
monitoring: minimal
ci_cd: required
estimated_cost_multiplier: 0.1x

purpose: "QAチームの結合テスト・E2Eテスト"
kubernetes:
  nodes: 3
  node_type: medium (4vCPU/16GB)
scalardb:
  replicas: 3
  resources: {cpu: 1, memory: 2Gi}
database:
  size: small
  ha: false
api_gateway: required
monitoring: standard
ci_cd: required
estimated_cost_multiplier: 0.3x

purpose: "本番同等構成でのリリース前検証"
kubernetes:
  nodes: 3-5
  node_type: production_equivalent
scalardb:
  replicas: 3-5
  resources: {cpu: 2, memory: 4Gi}
database:
  size: production_equivalent
  ha: true (single AZ)
api_gateway: required (production config)
monitoring: full
ci_cd: required
estimated_cost_multiplier: 0.5x

purpose: "実際のユーザーがアクセスする環境"
kubernetes:
  nodes: 5+
  node_type: large (8vCPU/32GB+)
  multi_az: true
scalardb:
  replicas: 5+
  resources: {cpu: 2, memory: 4Gi}
  pdb: {minAvailable: 3}
database:
  size: based_on_requirements
  ha: true (multi AZ)
  read_replicas: optional
api_gateway: required (HA)
monitoring: full + alerting
ci_cd: required
blue_green_canary: optional
estimated_cost_multiplier: 1.0x

Pod数 = max(
  性能要件Pod数,
  可用性要件Pod数,
  最小Pod数
)

性能要件Pod数 = ceil(目標TPS / TPS_per_Pod)
可用性要件Pod数 = 障害許容Pod数 + ceil(必要処理能力 / (1 - 障害時低下率))

必要Node数 = ceil(総Pod数 / Node_Capacity) × 冗長係数

Node_Capacity = (Node_CPU - System_Reserved) / Pod_CPU_Request
冗長係数 = 1.3〜1.5（障害時のリスケジュール余裕）

USD/JPY = 150円（見積もり時点の想定レート）
※実際のレートは変動するため、参考値として使用

月額SDBU費用 = SDBU数 × 月間稼働時間 × 33.5円

例: 24 SDBU × 730時間 × 33.5円 = 約58.7万円/月

**Pod数計算根拠**:
- 性能要件: 2,000 TPS ÷ 1,000 TPS/Pod（バランス型ワークロード）= 2 pods
- 可用性要件 (99.95%): 障害時も4pod稼働必要 → 最低5 pods
- 異種DB構成オーバーヘッド (+10-20%): +1 pod
- **合計: 6 pods**

**Node数計算根拠**:
- ScalarDB Pool: 6 pods × 2vCPU = 12vCPU必要 → r6i.2xlarge(8vCPU) × 2 = 16vCPU + 冗長1台 = 3台
- Application Pool: 12 pods × 1vCPU = 12vCPU必要 → m6i.xlarge(4vCPU) × 4 = 16vCPU + 冗長1台 = 5台
- System Pool: 監視・Ingress等 → m6i.large × 2台
- **合計: 10 nodes**

**データベース構成根拠**:
- Aurora PostgreSQL: マスターデータ（ユーザー、商品、注文）の参照整合性・複雑なクエリに最適
- DynamoDB: セッション管理・イベントログの高スループット書き込みに最適
- ScalarDBにより異種DB間でACIDトランザクションを実現

**Aurora インスタンスサイズ根拠**:
- 想定TPS: 2,000 TPS
- ScalarDBオーバーヘッド: 1更新あたり約5倍のI/O → 実効10,000 IOPS
- db.r6g.2xlarge: 最大20,000 IOPS対応、64GiBメモリでワーキングセット格納可能

**DynamoDB キャパシティ根拠**:
- 書き込み: 1,000 TPS × ceil(2KB/1KB) = 2,000 WCU（ScalarDBオーバーヘッド込み）
- Coordinator: 1,000 TPS × 1 WCU = 1,000 WCU
- 読み取り: 1,000 TPS × ceil(2KB/4KB) × 1（強整合性）= 1,000 RCU
- **合計: 3,000 WCU + 1,000 RCU → 余裕を見て4,000 WCU + 2,000 RCU**

**アーキテクチャ構成根拠**:
- 標準4層構成（API Gateway + BFF + Process API + System API）を採用
  - 理由: 責務の分離、スケーラビリティ、チーム分割の柔軟性
- Kong Enterprise (DB-less)を選択
  - 理由: GitOps親和性、Admin API不要、Kong Manager/Vitals/RBAC等のエンタープライズ機能
- Prometheus + Grafanaを選択
  - 理由: OSSでコスト効率良好、ScalarDB公式でPrometheus対応

**異種複数データベース構成の理由**:
| データ種別 | データベース | 選定理由 |
|----------|------------|---------|
| ユーザー情報 | Aurora PostgreSQL | 参照整合性、複雑なJOINクエリ対応 |
| 注文・在庫 | Aurora PostgreSQL | トランザクション整合性、外部キー制約 |
| セッション | DynamoDB | 高スループット読み書き、低レイテンシ |
| イベントログ | DynamoDB | 大量書き込み、TTLによる自動削除 |

→ ScalarDBにより、Aurora ↔ DynamoDB間でACIDトランザクションを実現

flowchart TB
    subgraph Internet
        Client[クライアント]
    end

    subgraph K8s["Kubernetes Cluster"]
        subgraph Gateway["API Gateway Layer"]
            Kong[Kong API Gateway<br/>DB-less Mode]
        end

        subgraph App["Application Layer"]
            BFF[BFF<br/>Backend for Frontend]
            Process[Process API<br/>ビジネスロジック]
            System[System API<br/>データアクセス]
        end

        subgraph Data["Data Layer"]
            ScalarDB[ScalarDB Cluster<br/>ACIDトランザクション管理]
        end
    end

    subgraph DB["Backend Database"]
        Primary[(Primary DB<br/>Aurora PostgreSQL)]
        Replica[(Read Replica)]
    end

    Client --> Kong
    Kong --> BFF
    BFF --> Process
    Process --> System
    System --> ScalarDB
    ScalarDB --> Primary
    ScalarDB --> Replica

flowchart TB
    subgraph Internet
        Client[クライアント]
    end

    subgraph K8s["Kubernetes Cluster"]
        subgraph Gateway["API Gateway Layer"]
            Kong[Kong API Gateway<br/>DB-less Mode]
        end

        subgraph App["Application Layer"]
            BFF[BFF]
            Process[Process API]
            System[System API]
        end

        subgraph Data["Data Layer"]
            ScalarDB[ScalarDB Cluster<br/>分散トランザクション]
        end
    end

    subgraph Databases["異種データベース"]
        subgraph RDBMS
            Aurora[(Aurora PostgreSQL<br/>マスターデータ)]
        end
        subgraph NoSQL
            DynamoDB[(DynamoDB<br/>高スループット)]
        end
        subgraph GlobalDB["グローバル分散"]
            Spanner[(Cloud Spanner<br/>地理分散)]
        end
    end

    Client --> Kong
    Kong --> BFF
    BFF --> Process
    Process --> System
    System --> ScalarDB
    ScalarDB -->|ACID| Aurora
    ScalarDB -->|ACID| DynamoDB
    ScalarDB -->|ACID| Spanner

flowchart TB
    subgraph Internet
        Client[クライアント]
    end

    subgraph AWS["AWS"]
        subgraph EKS["EKS Cluster"]
            Kong[Kong Gateway]
            App[Application Pods]
            ScalarDB[ScalarDB Cluster]
        end
        Aurora[(Aurora PostgreSQL)]
    end

    subgraph Azure["Azure"]
        CosmosDB[(Cosmos DB)]
    end

    subgraph GCP["GCP"]
        Spanner[(Cloud Spanner)]
    end

    Client --> Kong
    Kong --> App
    App --> ScalarDB
    ScalarDB -->|ACID| Aurora
    ScalarDB -->|ACID| CosmosDB
    ScalarDB -->|ACID| Spanner

flowchart LR
    subgraph Source["ソース管理"]
        GL[GitLab]
    end

    subgraph CI["継続的インテグレーション"]
        GLCI[GitLab CI]
        Build[ビルド/テスト]
        Scan[セキュリティスキャン]
    end

    subgraph CD["継続的デリバリー"]
        Argo[ArgoCD]
    end

    subgraph Environments["環境"]
        Dev[開発環境]
        Test[テスト環境]
        Staging[ステージング]
        Prod[本番環境]
    end

    GL --> GLCI
    GLCI --> Build --> Scan --> Argo
    Argo --> Dev
    Dev -->|自動| Test
    Test -->|承認| Staging
    Staging -->|承認| Prod

Q: CI/CDツールを選択してください
A) GitLab CI + ArgoCD - GitOps標準構成（推奨）
B) GitHub Actions + ArgoCD - GitHub環境向け
C) Azure DevOps + ArgoCD - Azure環境向け
D) Jenkins + ArgoCD - 既存Jenkins環境向け
E) カスタム構成 - 独自のCI/CD構成

{
  "questions": [
    {
      "question": "見積もる環境タイプを選択してください",
      "header": "環境",
      "options": [
        {"label": "開発環境", "description": "開発者が機能開発・単体テストを行う環境"},
        {"label": "テスト環境", "description": "QAチームが結合テスト・E2Eテストを行う環境"},
        {"label": "ステージング環境", "description": "本番同等構成でリリース前検証"},
        {"label": "本番環境", "description": "実際のユーザーがアクセスする環境"}
      ],
      "multiSelect": false
    }
  ]
}