デプロイメント戦略 — Beta → 本番マルチクラウド移行¶

対象フェーズ: Closed Beta 〜 GA（General Availability） 作成日: 2026-04-19 最終更新: 2026-04-19 ステータス: 承認待ち 関連コメント: Notion Design Docs（2026-04-18）「SQSを採用するようにしているが、Oracleや自前のバッジ処理などで利用する場合などを複数検討した上でシステムを提案するように」

1. エグゼクティブサマリー¶

Recerdo は Viejoアプリ（旧友・仲良かったグループとのSocialMedia）として、大手SNSと異なり "限定クローズド" なトラフィック特性を持つ。この特性を最大限活かすため、以下の二段階デプロイ戦略を採る。

設計原則: コードベースは 単一 を維持し、クラウド事業者・ミドルウェア実装は ハードコードせず、Feature Flag + 環境変数（12-factor config）+ アダプタパターン（Hexagonal Architecture） で差し替え可能にする。これにより、Beta → 本番切替時に「リポジトリを書き換える」のではなく「環境変数とフラグを切り替える」だけで移行できる。

Beta 段階の実装配置方針¶

• 設計上は per-service 分離を維持しつつ、Beta 段階では統合運用を許容する。
• 本番昇格前にサービス分割前提の運用手順（CI/CD・監視・ロールバック）へ段階移行する。

2. Notion レビューコメント対応マトリクス¶

3. クラウド選定理由と制約¶

3.1 OCI ファースト戦略の根拠¶

• コスト優位性: OCI の標準コンピュートは AWS EC2 比で 約57%安価、ブロックストレージで 約78%安価、外向きデータ転送で 約13倍安価（AWS: 100GB/月 vs OCI: 10TB/月の常時無料枠）
• S3 互換オブジェクトストレージ: OCI Object Storage は Amazon S3 互換 API を提供し、Garage と同じクライアントコードで切替可能
• MySQL HeatWave / MySQL Database Service: フルマネージド MySQL。ただし MariaDB 互換性を保つ ため、MySQL 独自機能（例: 8.0 の JSON_TABLE、CHECK 制約の差、空間データ関数の差）は使用しない。ウィンドウ関数は MariaDB 10.6+ でも利用可のため OK。参考: MariaDB vs MySQL Compatibility
• 日本リージョン: 東京（ap-tokyo-1）・大阪（ap-osaka-1）を両方提供、リージョン間DRが組める
• 除外クラウド: 中国系パブリッククラウド（Alibaba Cloud / Tencent Cloud）、および日本リージョンを持たない一部ヨーロッパ系クラウドは データ主権要件・レイテンシー要件 から除外

3.2 AWS 併用範囲（Cognito のみ）+ FCM¶

OCI ファーストとしつつも、以下の領域のみ AWS / Firebase を維持 する：

3.3 除外候補と根拠¶

4. Beta フェーズ物理構成（セルフホスト）¶

4.1 物理配置の原則¶

Closed Beta では "VPS（計算）" と "レンタルサーバー（ストレージ/メール）" を 物理的に分離 する。

• 計算層: XServer VPS（6 core / 10 GB RAM） — 全マイクロサービスを Docker Compose で稼働（Beta は単一ノードのため軽量運用）。本番は OCI Container Instances または OKE（OCI Kubernetes Engine）
• ストレージ/メール層: CoreServerV2 CORE+X（6 GB ストレージ） — Garage（S3互換 OSS）、Postfix+Dovecot+Rspamd、静的アセット、バックアップ

flowchart TB
  subgraph Client["クライアント"]
    iOS["iOS App"]
    Android["Android App"]
    Web["Web"]
  end

  subgraph Edge["エッジ (Cloudflare 無料プラン)"]
    CF["Cloudflare CDN + WAF"]
  end

  subgraph VPS["XServer VPS 6 core / 10 GB (計算層)"]
    GW["API Gateway (Traefik)"]
    Auth["Auth Svc"]
    Core["Core Svc (Users/Orgs/Events/Timeline)"]
    Album["Album Svc"]
    Media["Media Transcoder (ffmpeg / HLS / libheif)"]
    Msg["Messaging Svc"]
    Notif["Notification Svc"]
    Audit["Audit Svc"]
    Perm["Permission Svc"]
    Admin["Admin Console Svc"]
    FF["Feature Flag Svc (Flipt)"]
    Queue["Redis + BullMQ (キュー)"]
    DB["MySQL (MariaDB互換スキーマ)"]
    Loki["Grafana Loki"]
  end

  subgraph Rental["CoreServerV2 CORE+X 6GB (ストレージ/メール層)"]
    Garage["Garage (S3互換 OSS) — 写真/動画/HLS"]
    Mail["Postfix + Dovecot + Rspamd"]
    Backup["MySQL バックアップ (日次)"]
    StaticAssets["静的アセット"]
  end

  subgraph External["外部マネージド (AWS は Cognito のみ + Firebase)"]
    Cognito["AWS Cognito"]
    FCM["Firebase FCM"]
  end

  Client --> CF
  CF --> GW
  GW --> Auth
  GW --> Core
  GW --> Album
  GW --> Msg
  GW --> Admin
  Auth -.JWT検証.-> Cognito
  Album -- S3 API --> Garage
  Media -- S3 API --> Garage
  Core -- 読み書き --> DB
  Core -- enqueue --> Queue
  Queue -- 非同期 --> Audit
  Queue -- 非同期 --> Notif
  Queue -- 非同期 --> Media
  Notif --> FCM
  Notif -- SMTP --> Mail
  DB -- 日次バックアップ --> Backup

4.2 VPS（計算層）: XServer VPS 6 core / 10 GB¶

内容: - 全マイクロサービスを Docker Compose（Beta は単一ノードのため軽量運用）で稼働。本番は OCI Container Instances または OKE（OCI Kubernetes Engine） - Traefik をリバースプロキシ・API Gateway として使用（Let's Encrypt 自動化） - MySQL は VPS 内で稼働。ただしスキーマ・クエリは MariaDB 互換に保つ（JSON_TABLE 等 MySQL 独自機能の不使用、ウィンドウ関数は MariaDB 10.6+ でも可） - Redis + BullMQ / asynq をキューとして利用（OSS、セルフホスト） - Grafana Loki でログ集約 - Flipt で Feature Flag 管理 - メディア変換ワーカー（ffmpeg / libheif / go-libheif） を別コンテナで起動。HLS 変換は CPU 負荷が高いため、CPU 上限設定を行い、必要に応じて第二 VPS へオフロードする（server-capacity-planning.md §3 参照）

4.3 レンタルサーバー（ストレージ/メール層）: CoreServerV2 CORE+X¶

内容: - Garage（S3互換オブジェクトストレージ OSS） を設置し、Album Service・Media Transcoder のバックエンドとする。Garage は分散 S3 互換ストレージで、少数ノード・地理分散・Geo-redundancy に最適化されている。参考: Garage Documentation - Postfix + Dovecot + Rspamd を自前構築し、トランザクションメール（通知・招待・パスワードリセット）を送信。SPF / DKIM / DMARC を設定、送信 IP を段階的に warm-up - MySQL 日次バックアップ保管（gzip + gpg 暗号化） - 静的アセット（アプリ内画像・LP）のホスティング

4.4 フォールバック構成（CoreServerV2 で Garage 起動不可の場合）¶

5. 本番移行時のクラウドマッピング¶

5.1 コンポーネントごとの Beta → 本番マッピング¶

5.2 切替単位：リポジトリ不変／環境変数可変¶

詳細は 環境抽象化 & Feature Flag 駆動切替 を参照。

6. 移行ロードマップ¶

gantt
  title Beta → 本番移行ロードマップ
  dateFormat YYYY-MM-DD
  section Beta 完成
  Closed Beta（招待制100名）          :active, b1, 2026-05-01, 60d
  Open Beta（自由登録〜1,000名）      :b2, after b1, 60d
  section 本番準備
  OCI 本番 VCN 構築                    :p1, 2026-07-01, 30d
  アダプタ・Feature Flag 動作検証      :p2, after p1, 21d
  データ移行リハーサル（3回）          :p3, after p2, 21d
  section 本番切替
  Dual-Write モード                    :c1, 2026-09-01, 14d
  読み取り切替（Feature Flag）         :c2, after c1, 7d
  書き込み切替・Beta 撤去             :c3, after c2, 14d
  GA                                   :milestone, after c3, 0d

6.1 Dual-Write モードの詳細¶

目的: Beta インフラと本番インフラの両方に同時書き込みし、無停止移行する。

実装: Feature Flag infra.dualWrite.enabled=true がONのとき、Repository レイヤが両方の接続を保持し、両系統に書く。読み取りは infra.readFrom フラグで beta / prod / both を選択。

ロールバック: Kill Switch infra.dualWrite.killswitch=true を引くだけで即座に Beta のみに戻す。

7. リスクと緩和策¶

8. 運用指標（SLO）¶

9. 参考文献¶

• Garage — 分散 S3 互換オブジェクトストレージ OSS
• Postfix + Dovecot + Rspamd 運用とデリバラビリティ
• HLS 配信パイプラインの構築（ffmpeg + マイクロサービス）
• MariaDB vs MySQL Compatibility
• Oracle Cloud Always Free Tier 仕様
• The Twelve-Factor App — Config
• AWS Prescriptive Guidance — Hexagonal Architecture

10. 関連ドキュメント¶

• コストパフォーマンス分析 — 単価ベースの比較（本ドキュメントの前提）
• 環境抽象化 & Feature Flag 駆動切替 — ハードコード排除の実装詳細
• サーバーキャパシティ計画 — XServer VPS / HLS 変換の負荷試算
• キュー抽象化設計（MS） — OSS キュー比較・アダプタ層
• Admin Console Svc（MS） — 管理者コンソールのマイクロサービス設計
• Admin Console Svc（CA） — 管理者コンソールのクリーンアーキテクチャ設計

最終更新: 2026-04-19 ポリシー適用