企业云迁移战略规划

Executive Summary

You operate two on‑prem data centers with an OpenStack private cloud and a partially containerized Kubernetes estate. With a mid‑market scale, a 1–5M budget, and dual compliance drivers (HIPAA and China MLPS Level 3/等保三级), the recommended target is a compliant, phased hybrid-cloud architecture:

• Primary principle: data residency by jurisdiction. PHI governed by HIPAA remains in a HIPAA-eligible US region under a Business Associate Agreement (BAA). China personal/important data remains in Mainland China on a cloud platform certified for MLPS Level 3.
• Cloud model: a dual-region, dual-landing-zone approach using providers that (a) operate MLPS Level 3–certified services in Mainland China and (b) offer HIPAA-eligible services with BAA in the US. Options include a single hyperscaler with separate China operations or a two‑provider design. Select only services published as HIPAA‑eligible and MLPS3‑certified.
• Migration method: prioritize low‑risk rehost for most VMs, replatform databases to managed services, and incrementally refactor containerized components to managed Kubernetes. Use blue/green and canary releases to avoid disruption.
• Compliance-by-design: implement MLPS3 controls (boundary protection, audit, graded protection governance) and HIPAA safeguards (encryption, access control, audit, incident response) from day one in the landing zones.
• Timeline: 6–9 months in three waves (pilot, core apps, tail), with clear rollback paths and measurable success KPIs (cost, reliability, security posture, migration velocity).

This plan balances risk, compliance, cost, and speed without aggressive cutovers that could disrupt business.

Current State Assessment

• Infrastructure analysis

  • Two data centers with OpenStack-based virtualization, mixed VM generations, and shared storage.
  • Partial Kubernetes adoption (on-prem): some stateless services containerized; stateful components and legacy systems remain on VMs.
  • Network: dual-site interconnect; perimeter security via firewalls; limited micro‑segmentation internally.
  • Tooling: basic monitoring/logging; limited centralized IAM; backups via snapshot + file-level jobs; DR RPO/RTO vary by system.
  • Constraints: maintenance windows are tight; limited DevOps automation for legacy apps; hardware refresh due within 12–24 months.

• Application architecture assessment

  • Tiering
    • Tier 1: customer-facing services, APIs supporting web/mobile; moderate to high peak variability; some containerized.
    • Tier 2: ERP/MES/financial subsystems; mostly VM-based; complex dependencies.
    • Tier 3: analytics/reporting; batch; can tolerate longer RTO.
  • Technology stack: Java/.NET/Node microservices; relational DBs (MySQL/PostgreSQL/SQL Server), Redis; message queues (e.g., RabbitMQ/Kafka).
  • Non-functionals: target availability ≥99.9% for Tier 1; current DR mostly active‑passive; limited automated scaling.

• Data distribution status

  • PHI for healthcare workflows; subject to HIPAA; currently intermixed with general PII in shared DB clusters.
  • China personal/important data subject to PIPL/CSL/DSL; some cross-site replication between the two DCs.
  • Data sizes (indicative): OLTP DBs 1–3 TB each; data lake/files 20–50 TB; object archives 10–20 TB.
  • Current protections: in-transit TLS for some services; at-rest encryption inconsistent; audit logs retained, but not centralized nor immutable.

Migration Strategy

• Cloud environment selection recommendations

  • China workloads: choose a Mainland China cloud platform with published MLPS Level 3 certifications for the intended services (compute, VPC, managed Kubernetes, managed DB, object storage, logging/SIEM, KMS/HSM). Ensure ICP filings and graded protection filing are planned.
  • HIPAA workloads (PHI): choose a cloud offering HIPAA‑eligible services and willing to execute a BAA. Use only services listed as HIPAA‑eligible by the provider.
  • Architecture pattern options
    • Option A (preferred if you want one vendor family): use a hyperscaler’s China regions (operated by local partners) for China data and the same hyperscaler’s US regions for HIPAA. Accounts/tenancies are separate; implement consistent guardrails via policy templates.
    • Option B: China CSP (MLPS3) + US CSP (HIPAA BAA). Connect only where legally permissible; avoid cross‑border transfer of personal/PHI unless approved under applicable regulations.

• Migration methodology (portfolio “6R” mix)

  • Rehost (lift‑and‑shift): 50–60% of VM-based apps with minimal change using cloud-native migration services (e.g., agent-based block replication). Use for legacy but stable workloads.
  • Replatform: databases to managed relational DBs; caches/queues to managed equivalents; apps to managed Kubernetes. Gains in resilience, backup, and patching without major code changes.
  • Refactor: selective microservices that already run on K8s to adopt cloud-native capabilities (autoscaling, managed ingress, service mesh if needed).
  • Replace: commodity components (monitoring/logging, WAF, CI runners) with cloud-native services to reduce ops toil.
  • Retire: identify low-usage or duplicated components during application rationalization.

• Phasing and timeline

  • Phase 0 (2–4 weeks): discovery, dependency mapping, data classification, compliance gap analysis, landing zone design.
  • Phase 1 Pilot (4–6 weeks): stand up landing zones (China + US), set up private connectivity, migrate 2–3 low‑risk services (one containerized, one VM, one DB replica) to validate tooling, performance, and compliance controls.
  • Phase 2 Core migration (8–12 weeks): wave‑based moves for Tier 1/2, starting with stateless services, then DBs via CDC, then the remainder. Parallel hardening of security and observability.
  • Phase 3 Tail and optimization (4–8 weeks): remaining workloads, decommission on‑prem where applicable, implement cost governance, finalize DR tests and compliance artifacts.
  • Cutover windows: blue/green with DNS TTL control for stateless; DBs via CDC with minutes‑level downtime during final cut; rollback to prior environment maintained until verification passes.

Technical Solution

• Target architecture design

  • Landing zones (per region/jurisdiction)
    • Multi-account/subscription model (prod/non‑prod/security/log‑archive).
    • Guardrails: organization policies, tagging standards, budget alerts, preventive/detective controls as code.
  • Networking
    • VPC/VNet per environment with segregated subnets (public, private app, data).
    • Private service endpoints for managed DB, storage, and KMS.
    • Hybrid connectivity: dedicated private circuit (e.g., Direct Connect/ExpressRoute or CSP equivalent) from DCs to each cloud; IPsec VPN as backup. No default cross‑border data flows.
  • Compute and platforms
    • Managed Kubernetes for containerized services; autoscaling enabled; managed ingress with WAF in front.
    • VM compute for legacy workloads; PaaS where feasible (managed DB, cache, message queue).
  • Data platform
    • Managed relational DB (multi‑AZ), managed Redis; object storage with lifecycle policies and immutability for logs/backups.
    • Backup strategy: cross‑AZ replication; cross‑region only within same jurisdiction and after compliance review.
  • Observability
    • Centralized logging (agent-based forwarders to managed log service), metrics/traces, SIEM integration; log immutability and retention per HIPAA/MLPS needs.
  • Identity and access
    • Central IAM with least privilege, role-based access, MFA/conditional access; workload identities for apps; break‑glass procedures.

• Network and security planning

  • Perimeter: managed WAF + Anti-DDoS; API gateway for external APIs; bastion host for admin with PAM.
  • Segmentation: security groups/NSGs and network ACLs; deny‑by‑default; service-to-service allowlists.
  • Cryptography: TLS 1.2+ everywhere; at‑rest encryption with customer‑managed keys (KMS/HSM); key rotation policies; envelope encryption for PHI.
  • Secrets: managed secrets store with automatic rotation.
  • Vulnerability and patch management: managed scanners; CIS benchmarks for OS/K8s; image signing and admission control.
  • Compliance mapping highlights
    • HIPAA: access control, audit/logging, encryption, transmission security, backup/restore, incident response, BAA in place.
    • MLPS Level 3: graded protection filing, boundary protection (firewall/WAF/IDS), security audits with centralized logs, vulnerability management, security management system, DR drills, operator security agreements.
  • Data sovereignty
    • PHI stays in US region; China personal/important data stays in Mainland China.
    • Any cross‑border transfers undergo PIPL compliance procedures (e.g., security assessment or standard contractual clauses as applicable), data minimization, and de‑identification where feasible.

• Data migration plan

  • Discovery and classification: tag datasets as PHI, PII, business-confidential; define allowed residency.
  • Databases
    • Use cloud-native Database Migration Service with CDC for near‑zero downtime. Steps: provision target, schema conversion/validation, start CDC, run consistency checks, schedule cutover, verify, then decommission.
    • Rollback: keep source in read‑write until verification; if fail, revert DNS/app config and resume writes to source.
  • Files/object storage
    • Parallelized sync tools or managed data transfer services with checksums and resumable copies; immutable logs for chain‑of‑custody.
  • K8s workloads
    • Container registry migration to a managed registry; rebuild images with base images meeting CIS benchmarks; redeploy via Helm/Kustomize; adopt HPA/PodDisruptionBudgets; phased canary.
  • Backups and DR
    • Before each cutover: full backup + point‑in‑time restore test; after cutover: test restore in target; document RPO/RTO.

Implementation Assurance

• Team organization structure

  • Cloud Program Governance: Steering Committee (IT, Security, Compliance, Business).
  • Cloud Center of Excellence (CoE): Enterprise Architect (lead), Security Architect, Network Architect, DevOps Lead, Data/DBA Lead, Compliance Officer.
  • Workstreams: Landing Zone, Network/Connectivity, Security/Compliance, App Migration (by wave), Data Migration, Observability/Operations, Change Management & Training.
  • RACI: CoE owns standards and guardrails; App owners own functional testing; Security owns control validation; PMO tracks milestones and risk.

• Risk control measures

  • Downtime risk: blue/green and canary; CDC for DBs; rehearsed runbooks; maintenance windows agreed with business.
  • Data loss/corruption: dual control on cutovers; validated backups; checksum verification; immutable logs.
  • Compliance gaps: pre‑migration control checklists; use only provider services documented as HIPAA‑eligible and MLPS3‑certified; execute BAA; MLPS filing with local regulator; periodic internal audits.
  • Performance regressions: performance baselines; load tests in target; right‑sizing and autoscaling policies; dedicated connectivity with QoS.
  • Cost overrun: tagging and budgets; guardrails preventing oversize instances; commit discounts only after 4–8 weeks of baseline; continuous rightsizing.
  • Vendor lock‑in: use open standards (K8s, Terraform), abstracted data layers where feasible; document exit plans.
  • Cross‑border compliance: data localization by default; DPIA and legal approvals before any transfer; data minimization/anonymization.

• Success metrics definition

  • Migration velocity: ≥80% of in‑scope apps migrated within 6–9 months with <1 h downtime per Tier 1 cutover.
  • Reliability: ≥99.9% availability for Tier 1; DR RPO ≤15 min (CDC) and RTO ≤1 h for critical DBs.
  • Security/compliance: 100% HIPAA-eligible/MLPS3-certified services; 0 critical vulnerabilities outstanding; audit logs retained per policy; successful MLPS filing and HIPAA control attestation.
  • Cost: 20–30% infra TCO reduction vs baseline by month 6 post‑migration through rightsizing/auto‑scaling/lifecycle policies.
  • Operations: MTTR improved by 30%; deployment frequency increased by 2x for refactored services; mean lead time reduced by 30%.

Additional guidance

• Budget envelope (indicative allocation, not vendor-specific):
  • 25–35% network and connectivity (private links, edge, firewalls/WAF).
  • 25–35% compute/database platform (managed K8s/DB, VM capacity).
  • 10–15% storage and backup/DR.
  • 10–15% security and observability (SIEM, logging, scanners).
  • 10–15% services and training (migration factory, compliance, runbooks).
• Tooling principles: prefer cloud-native, security-certified migration and platform services. Any third-party/open-source components must pass internal security review and comply with organizational and regulatory requirements.

This roadmap enables a compliant, low-risk transition from OpenStack to a modern, secure, and cost-effective cloud foundation, aligning with both HIPAA and MLPS Level 3 while preserving business continuity.

実行サマリ

• 対象環境: 自社運用の双活データセンター（A/A）＋小型機（AIX等）上のコア勘定系、グループ企業規模
• 目標: 業務継続性と金融級のコンプライアンスを最優先に、段階的ハイブリッド→クラウドネイティブへの移行を実現。中国国内の等保三级、金融監管要件、EU子会社のGDPRを同時満たすデータガバナンスを確立
• 戦略骨子:
  1. 現状可観測化と依存関係の完全把握、技術負債の可視化
  2. 先にクラウド基盤（ランディングゾーン）を金融コンプライアンス準拠で整備
  3. 非コア/周辺業務はRehost/Replatform、勘定系周辺をMicroservices化して段階移行
  4. 勘定系コアは当面ハイブリッド（AIX継続＋クラウドDR/只読レプリカ）→長期でRefactor計画を別立て
  5. 並行稼働・カナリア/ブルーグリーンで無停止切替、明確なロールバック設計
• コンプライアンス: 等保三级・金融級監管・GDPR・中国網安法/数安法/個情法に適合。データ越境は最小化し、必要時は法定手続（安全評価/標準契約）と暗号化・脱敏で対応
• 想定期間/規模感: 24〜36カ月、総予算1,000万超（詳細見積は別途）。成功指標はRPO≤5分/RTO≤30分（周辺系は緩和可）、主要アプリのクラウド移行率>60%、コンプライアンス適合100%

現状評価

基盤インフラ分析

• データセンター: 同城/異地の双活構成。低RPO/RTO、同期/半同期レプリケーションを実装
• 計算基盤: 小型機（AIX/UNIX系）上に勘定系、x86仮想化（VMware等）で周辺業務
• ストレージ: SAN/NAS併用、スナップショット/ボリュームレプリカ。バックアップはテープ/磁気ディスクの多層
• ネットワーク: MPLS/専用線で拠点接続、コアにFW/IPS/WAF。IPアドレスはオンプレ中心で枯渇余地あり
• 運用: 監視はAPM/NPM/ログ（SIEM）分散。自動化は一部スクリプト依存、変更管理は手動プロセス多め

アプリケーションアーキテクチャ評価

• 勘定系: モノリシック構成（COBOL/Java混在想定）、強いACID要件、ジョブ/トランザクション集中
• 周辺業務: 勘定系に同期・バッチ依存。APIは限定的、MQ/ファイル連携混在
• 可用性: 双活で可用性は高いが、ピーク対応は垂直スケール寄りで伸縮性に制約
• 技術負債: AIX依存、レガシーMQ/FTP、密結合のバッチ、設定の手作業運用

データ分布現状

• 勘定・取引・顧客PIIがDC内に集中。EU関連データは一部EU域外保管の可能性
• DWH/レポーティングは夜間バッチ集約。リアルタイム分析は限定
• データ保護: 暗号化はストレージ中心。鍵管理はオンプレKMS相当で分散管理

迁移策略

クラウド環境選定の提言

• 全体方針: ハイブリッド/マルチリージョン
  • 中国国内: 等保三级/金融監管に対応し、第三方安全認証（ISO 27001/SOC2/PCI DSS等）取得済みのクラウド。運営主体・数据主权・合规资质を確認
  • EU: GDPR対応のEUリージョンにデータ在置。越境は原則禁止、必要時はSCC/安全評価
• 運用モデル:
  • ミッションクリティカルはマルチAZ＋遠隔DR。ネットワークは二重キャリアの専線（Direct Connect相当）＋IPsec冗長
  • ランディングゾーン（マルチアカウント/サブスクリプション、ガードレール、集中KMS/HSM、集中ログ/SIEM）

迁移方法論（重构/平移/替换）

• 勘定系コア
  • 短期: Rehost不可（AIX依存）。Replatformはリスク高のため回避。まずは「継続稼働＋クラウドDR（CDC）＋周辺切り出し」
  • 中期: 周辺ドメイン（顧客通知/レポート/チャネルAPI）をRefactor→クラウドネイティブ（Kubernetes）へ
  • 長期: コアドメイン段階的Refactor（ドメイン分割、強整合性RDB/分散トランザクション設計）
• 周辺/支援系
  • Rehost（IaaS）またはReplatform（マネージドDB/MQ/オブジェクトストレージ）を優先
• 置換（Replace）
  • 共通基盤機能（監視/日志/CMDB/ITSM）はクラウドの認証済みマネージド/業務SaaSへ段階置換

フェーズ分割とタイムライン（目安）

• P0: 0–3カ月 現状可視化/評価
  • 依存関係マップ、RTO/RPO再定義、データ分類分級、合规差分分析
• P1: 3–6カ月 基盤整備
  • ランディングゾーン、ネットワーク専線、ID統合、集中KMS/HSM、監査ログ基盤
• P2: 6–12カ月 低リスク移行
  • 周辺/読み取り系のRehost/Replatform、DWHのクラウドDR/一部移行、CDC構築
• P3: 12–18カ月 勘定系周辺の段階Refactor
  • APIゲートウェイ化、レポート/通知/顧客チャネルのクラウド化、並行稼働
• P4: 18–30カ月 コア近接領域の移行/DR高度化
  • 冗長化強化、トランザクション整合の検証、ピーク時のクラウドバースト
• P5: 30–36カ月 コアの近代化ロードマップ実行開始
  • パイロットドメインからのRefactor、双方向カットオーバー手順の反復確立

技術方案

目標アーキテクチャ設計

• 全体
  • ハイブリッドクラウド（オンプレ双活＋クラウド：マルチAZ/遠隔DR）
  • マルチアカウント構成（Prod/PreProd/Dev/Shared Services/Security）
  • ゼロトラスト原則、ネットワーク/ID/データの三層防御
• アプリ/プラットフォーム
  • コンテナ基盤: 企業管理のKubernetes（マネージドK8s可、CIS Benchmark準拠）
  • サービスメッシュ: mTLS/トラフィック制御/カナリアを活用
  • メッセージング: 認証済みマネージドMQ/ストリーム（可用性SLAと順序/Exactly-once要件を満たすもの）
  • データ基盤:
    • トランザクション系: 金融実績のあるRDB（多AZ同期/強整合、暗号化対応）
    • 分析系: レイクハウス構成（オブジェクトストレージ＋メタカタログ）、PIIは動的マスキング
  • 観測性: 分散トレース/APM/メトリクス/ログの統合。SLO管理とエラーバジェット

ネットワークとセキュリティ計画

• ネットワーク
  • 専用線×2事業者＋IPsec冗長、ルート分散設計
  • ハブ＆スポークVPC/VNet、サブネット分離（Prod/NonProd/管理）
  • egress制御、PrivateLink/専用接続を優先
• ID/アクセス
  • 企業IdP連携（SAML/OIDC）、RBAC/ABAC、JIT/強制MFA、特権アクセスは踏み台＋録画
• データ保護
  • KMS/HSMで鍵分離（BYOK/CKM）。保存/転送時暗号化、PII最小化、動的脱敏
  • ログ保管と不可改ざん（規定期間保持、WORM対応）
• コンプライアンス（中国・EU）
  • 等保三级: 等保框架に沿った边界防护/访问控制/审计/恶意代码防护等の実装、等保测评計画
  • 金融監管: 交易日志留存、重大变更审批、压力测试、外包风险管理
  • GDPR: データ主体権利対応（アクセス/削除）、SCC/越境手続、DPIA実施、記録台帳
  • 中国法令: 网安法/数安法/个保法の数据出境评估、敏感数据本地化、运营商合规接入

データ移行方案

• パターン
  • オンラインCDC（変更データ捕捉）で二重書込みを避けつつ準リアルタイム同期
  • 異機種（AIX→x86）を跨ぐ場合はベンダ認証済みの商用CDC/レプリケーション製品を採用
• 勘定系
  • 短期: 本番はAIX継続、クラウド側に只読レプリカ/レポート系を同期。DRは定演習
  • 中期: ドメイン単位で新RDBへ移行（並行稼働/デュアルラン）。切替はブルーグリーン＋トランザクションドレイン
• DWH/分析
  • レイクへの増分投入（CDC→ストリーミングETL）。スキーマ進化とデータ品質ルールを実装
• データ品質/整合性
  • 勘定照合バッチの二重系実行、差分検知→自動/半自動修復
• 退出/回収
  • オンプレに残るPIIは最小化、退役時は暗号鍵廃棄と安全消去

実施保障

組織・体制

• ガバナンス/CCoE（クラウド卓越センター）
  • 企業アーキ、セキュリティ/コンプライアンス、ネットワーク、プラットフォームSRE、FinOps
• 移行ファクトリ
  • アセスメント、ワークロード波及設計、テスト自動化、カットオーバー運用
• アプリSquad
  • ドメイン別（勘定、チャネル、報告、CRM等）、プロダクトオーナー主導
• 監査/法務/風控
  • GDPR/等保/金融監管対応、データ出境審査、サプライヤ管理
• PMO
  • マイルストーン、品質/リスク、コミュニケーション計画

リスク管理策

• 技術
  • AIX依存: 当面はハイブリッド維持、互換評価とPoC、CDCで安全な切替
  • 性能劣化: 合成負荷試験（ピーク×1.5）、事前容量計画、自動スケールと限流
  • 一貫性: 分散トランザクションは極小化、二相コミット/Idempotency/補償設計
• 業務
  • 無停止切替: カナリア→段階拡大、即時ロールバックRunbook、凍結期間の設定
  • 変更管理: CAB/SoD、インフラはIaCで審査・再現性確保
• セキュリティ/合規
  • 最小権限、鍵分離、第三者テスト（渗透/红蓝对抗）、重要日志の集中保全
  • データ越境: 原則禁止、必要時はSCC/安全評価＋匿名化/脱敏
• 供給者
  • ベンダーロックイン緩和: 標準API/OSS準拠、データポータビリティ手順
  • 契約: SLA/可用性/サポート範囲/退出条項を明記
• ロールバック方針
  • データ: 切替点スナップショット、書込みフリーズ→整合性検証→本切替
  • アプリ: ブルーグリーンでDNS/ルーティング即時戻し、構成はIaCでバージョン管理

成功指標（KPI/SLI）

• 可用性/復旧
  • 勘定系RPO≤5分、RTO≤30分（周辺系RTO≤60分）
  • DR演習年2回以上、成功率100%
• 性能/拡張性
  • 月間ピークトラフィックでP95応答<300ms、スループット前年比+30%余力
• 品質/安定性
  • リリース後重大インシデント0件、欠陥流出率<1%
• コスト/運用
  • リソース無駄削減≥20%、自動化率≥70%、FinOpsによりコスト予測誤差±10%以内
• コンプライアンス
  • 等保三级测评一次合格、GDPR監査指摘ゼロ、監管報告期限遵守100%

補足方針

• 本計画では、未認証のクラウド部品や無許可ツールは使用しません。データおよび鍵は適切に分離・保護し、中国の関連法規に準拠します。価格の具体提示は行わず、詳細見積は別途要件定義に基づき実施します。