システムをガバメントクラウドに移行する際に必要となるプロセスにおいて、検討すべきOCIサービスを理解するための文書である。 # システム移行の全体像 OCI Cloud Adoption Framework（CAF）は、クラウド導入時に計画、適応および反復を行うためのベスト・プラクティスと規範的なガイダンスである。システム移行では、現在の状態を把握し、移行計画を検討し、実行に移すプロセスが必要である。それぞれのプロセスにおいて、OCIの活用を含めて検討が必要なタスク（図1の赤字）を本書に示す。 ![図01: システム移行の全体像](/images/oci_how-to-migrate-system-01-001.jpg) **図01: システム移行の全体像** [OCIドキュメント：Oracle Cloud Infrastructure Cloud Adoption Framework] https://docs.oracle.com/ja-jp/iaas/Content/cloud-adoption-framework/home.htm # 移行におけるOCIサービスの活用 ## プロセス設計の検討 Cloud Adoption Frameworkのプロセス設計は、ビジネス目標を達成するために必要なビジネスプロセスと技術プロセスの定義に重点を置いている。エンタープライズ・アーキテクチャ戦略によって、クラウド変革のロードマップが定義される。ガバナンス・プロセスは、リスクを最小限に抑えながらアジリティを最適化することを目指している。リスク管理プログラムにより、組織のセキュリティ要件とコンプライアンス要件を満たせる。 ### エンタープライズ・アーキテクチャの検討ガバメントクラウドにおけるアーキテクチャ検討の際にはReplatform、Rebuild、Repurchaseの3パターンを意識した検討する。ReplatformとRebuildの基本形のアーキテクチャはサンプルテンプレートを参照すること（今後提供予定）。また、移行テストはOCIの責任範囲は実施しないなど移行パターンに合わせて必要なテストのみ実施し、移行にかかるコストを最適化する。サンプルテンプレートは、GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されているガバメントクラウドテンプレート/ポリシー（メンバー専用ページ→ガバメントクラウドテンプレート/ポリシー→ガバメントクラウドテンプレート/ポリシーのダウンロードページ）を参照すること。なお、OCIでは今後提供予定となっている。 ![図02: ガバメントクラウドへの移行パターン](/images/oci_how-to-migrate-system-02-001.jpg) **図02: ガバメントクラウドへの移行パターン** #### Replatform Replatformにおいて活用可能なOCIサービスを以下に示す。 **表 01: ReplatformにおけるOCIサービスの活用** | カテゴリ | 機能 | OCIサービス | | --- | --- | --- | | データベース | RDB | Autonomous Database
Base Database Service
Exadata Database Service
MySQL HeatWave on OCI
OCI Database with PostgreSQL | | ストレージ | オブジェクトストレージ | Object Storage | | ネットワーク | ネットワーク | VCN（仮想クラウドネットワーク） | | | DNS | OCI DNS | | | NTP | OCI NTP 内部サービス | | | ロードバランシング | OCI Load Balancer
OCI Network Load Balancer | ##### データベース概要オンプレミス環境にて特定のデータベース管理システム（以下DBMS）を使用している既存のアプリケーションをOCIのクラウド上に移行する際に、OCI上でそのままサポート機能を使用できるDBMSおよび各エディションと、OCI上ではサポート機能が使用できなくなるDBMSおよび各エディションがある。 OCI上のOracle Databaseとしては、主にBase Database Service、Autonomous Database、Exadata Database Serviceがあり、それぞれ機能や制限事項が異なるので違いを理解する必要がある。 - Base Database Service - 特徴仮想マシン上でOracle Databaseを提供するサービスであり、Oracle管理のインフラストラクチャと、ユーザー管理のOracle Databaseによって、オンプレミスのOracle Databaseと同等に利用できる。（クラウド固有の制限事項あり）Databaseのパッチは任意のタイミングで適⽤でき、OSにもログインできる。また、表領域はデフォルトで暗号化されている。　 | エディション | 機能 | | --- | --- | | Standard Edition | Oracle Database Standard Edition 2が含まれ、柔軟な仮想マシン・インフラストラクチャを提供する。 | | Enterprise Edition | Data Masking and Subsetting Pack、Diagnostics and Tuning Packs、Real Application Testingが含まれる。 | | Enterprise Edition High Performance | Multitenant、Partitiong、Hybrid Columnar Compression（HCC）、Advanced Security、Label Security、
Database Vault、OLAP、Database Lifecycle Management Pack、およびCloud Management Pack for Oracle Databaseが含まれる。 | | Enterprise Edition Extreme Performance | Enterprise Edition High Performanceに加え、In-Memory Database、Active Data Guard、
Real Application Clusters、およびShardingが含まれる。 | 　 - Autonomous Database - 特徴データベースとインフラの管理・監視・チューニングを自動的に行うフルマネージド型のOracle Databaseである。多くの機能が自動化されているため利用・運用コストを最適化できる半面、制限事項もある。そのため選択の際は、使用する機能や運用方法が適用できるか確認する必要がある。　 | 種類 | サービス概要 | | --- | --- | | Autonomous Data Warehouse | データマート、データウェアハウス、データレイクなどの分析ワークロードのために最適化・完全自動化されたクラウドデータベースサービス。 | | Autonomous Transaction Processing | トランザクション、分析、バッチのワークロードを同時に実行するために最適化・完全自動化されたクラウドデータベースサービス。 | | Autonomous JSON Database | Oracle Autonomous JSON Database（AJD）は、JSONデータのトランザクションと分析に特化したバージョンの Autonomous Databaseであり、
MongoDB APIも含まれる。 | 　 - Exadata Database Service - 特徴 Exadata専有基盤上で動作しミッションクリティカル・システムや大規模ワークロード向けのデータベースサービスである。Base Database Service同様インフラストラクチャをOracleが管理しOS以上のレイヤーをユーザーが管理する。Exadata Database ServiceではデフォルトでEnterprise Edition Extreme Performanceエディションとなっているのですべてのオプション機能が使える。 [OCIドキュメント：Base Database Serviceのよくある質問] https://www.oracle.com/jp/database/base-database-service/faq/ [OCIドキュメント：Oracle Autonomous Databaseに関するFAQ] https://www.oracle.com/jp/database/technologies/datawarehouse-bigdata/adb-faqs.html [OCIドキュメント：Exadata Database Service On Dedicated Infrastructure] https://docs.oracle.com/cd/F56555_01/ecscm/index.html #### Rebuild Rebuildにおいて活用可能なOCIサービスを以下に示す。 **表 02: RebuildにおけるOCIサービスの活用** | カテゴリ | 機能 | OCIサービス | | --- | --- | --- | | API | API化 | API Gateway | | コンピュート | サーバレス | OCI Functions | | | コンテナ | OCI Kubernetes Engine（OKE）
Container Instances
Container Registry | | ストレージ | オブジェクトストレージ | Object Storage | | ネットワーク | ネットワーク | VCN（仮想クラウドネットワーク） | | | DNS | OCI DNS | | | NTP | OCI NTP 内部サービス | | | ロードバランシング | OCI Load Balancer
OCI Network Load Balancer | ##### データベースの見直し Rebuildにおいて活用可能なOCIのデータベースサービスを以下に示す。 **表 03: RebuildにおけるOCIデータベースサービスの活用** | データベースの種類 | OCIサービス | 特徴 | | --- | --- | --- | | リレーショナルデータベース | Autonomous Database | フルマネージドサービスを最大限活用し運用コストを軽減 | | リレーショナルデータベース | Base Database Service | オンプレミスのOracle DB運用を継続可能 | | リレーショナルデータベース | Exadata Database Service | 膨大なトランザクション処理や大規模DWHをはじめとしたワークロードをマネージドサービスとして運用が可能 | | リレーショナルデータベース | MySQL HeatWave on OCI | OLTPとOLAPを単一のDBとして扱えるだけでなく、DWHやデータレイクを横断するリアルタイム分析、
機械学習が実現できるMySQLベースのマネージドサービス | | リレーショナルデータベース | OCI Database with PostgreSQL | PostgreSQLをマネージドサービスとして利用 | | NoSQLデータベース | NoSQL Database | レイテンシの短い応答、柔軟なデータモデル、動的なワークロードを必要とするDBシステム | | インメモリ・キャッシュ・ソリューション | OCI Cache | セッション管理やキャッシュとして利用し、DBシステムを高速化 | ### 運用管理・セキュリティの検討運用管理・セキュリティの検討の際はマネージドサービスを活用することで、最小限のリソース利用やミドルウェアライセンスの削減、運用工数の削減などを意識した検討をする。 **表 04: 運用管理・セキュリティにおけるOCIサービスの活用** | カテゴリ | 機能 | OCIサービス | | --- | --- | --- | | 運用 | イベントドリブン
データ連携 | OCI Functions
OCI Kubernetes Engine（OKE）
Container Instances
Oracle Integration Cloud | | | バックアップ | 各サービスのバックアップ機能 | | | ログ収集 | OCI Logging | | | 変更管理 | Cloud Guard | | | インベントリ | OS Management Hub | | | コスト管理 | Cost Analysis | | | リソース管理 | OCI Tagging、Cloud Advisor | | | モニタリング | OCI Monitoring
OCI Health Checks
Oracle Threat Intelligence（脅威インテリジェンス）
Vulnerability Scanning（脆弱性スキャン） | | | 検知 | OCI Monitoring | | | リポジトリ | Container Registry | | | ビルド
デプロイ
継続的デリバリー | OCI DevOps | | セキュリティ | 全体管理 | Cloud Guard | | | 不正検知 | Vulnerability Scanning（脆弱性スキャン）
Cloud Guard | | | 脅威検知 | Oracle Threat Intelligence（脅威インテリジェンス）
Cloud Guard | | | 認証 | OCI IAM | | | 評価 | Cloud Guard | | | 証明書 | OCI Certificates | | | 暗号化キー | OCI Vault | | | WAF | Web Application Firewall（WAF） | | | DDoS | Web Application Firewall（WAF） | | | ファイアウォール | OCI Network Firewall | #### バッチ処理の見直し利用者はクラウド移行による制限の解放（ストレージ容量、物理サーバ、ミドルウェアの機能、外部システム連携など）の観点でバッチ処理の在り方を見直し、クラウドに最適化されたバッチ処理を検討する。 ![図03: バッチ処理の見直しとクラウド最適化](/images/oci_how-to-migrate-system-03.jpg) **図03: バッチ処理の見直しとクラウド最適化** マスタデータメンテナンスはACID特性を持つデータベースのために発生する処理のため、データベースの種類を見直すという観点もある。その場合は本書の**データベースの見直し**を参照すること。バッチ処理のモダン化に活用できるOCIサービスを以下に示す。 **表 05: バッチ処理におけるOCIサービスの活用** | 最適化方針 | 処理方式 | OCIサービス | | --- | --- | --- | | 処理方式をモダン化 | マネージドサービス化 | OCI Functions
OCI Kubernetes Engine（OKE）
Container Instances
Oracle Integration | | | イベントドリブン化 | OCI Functions
OCI Kubernetes Engine（OKE）
Container Instances
OCI Events | | バッチ処理の廃止（オンライン化） | オンライン化 | OCI Functions
OCI Kubernetes Engine（OKE）
Container Instances | | | オンライン化（計算機のオートスケール） | OCI Functions
OCI Kubernetes Engine（OKE） | | | オンライン化（ストレージのオートスケール） | Object Storage | ##### バックアップの見直し利用者はバックアップをソフトウェアやジョブ、運用で実現するような方式を見直し、マネージドサービスを活用することでクラウドに最適化されたバックアップを検討する。 ![図04: バックアップの見直し](/images/oci_how-to-migrate-system-04-001.jpg) **図04: バックアップの見直し** ### 移行方式の検討 #### 移行要件の整理移行方式の検討はビジネス、技術双方の観点での要件を整理し、要件を満たす移行方式を検討する。また移行要件の優先順位を整理し、より優先度の高い要件を満たす移行方式を検討する。移行における要件例を以下表に示す。 **表 06: 移行要件例** | 分類 | 要件例 | | --- | --- | | ビジネス | 業務停止可能時間 | | | 業務停止可能回数 | | | 移行に要するコスト | | | 既存業務への影響度合い | | | 法令の遵守 | | 作業 | 作業の複雑性 | | | 作業の所要時間 | | | 作業連携や作業分担の複雑性 | | 技術 | 移行実施単位 | | | 切り戻しの容易さ | | | 回線速度と移行パフォーマンス | | | 現行構成に対する変更の有無 | #### 移行方式の検討整理した移行要件を踏まえ、システム移行方式、データ移行方式、業務切り替え方式を検討する。政府機関においては、システム一括移行やデータ一括同期、ユーザー/ロケーション/業務順次切替えのパターンが多いと想定されるが、対象システムに適した移行パターンを以下フローチャートにて検討する。 ![図05: 移行方式検討フローチャート](/images/oci_how-to-migrate-system-05.jpg) **図05: 移行方式検討フローチャート** また移行方式によっては旧環境と新環境のネットワーク接続が必要なケースもあるため、ネットワークの接続方法は[「ネットワーク接続方法（OCI編）」](https://guide.gcas.cloud.go.jp/oci/how-to-connect-network/) を参照すること。ネットワークの詳細は、GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で今後公開予定であるドキュメントを参照すること。ガバメントクラウドの移行とGSSの移行を並行して検討している場合は、どちらの移行を先行すべきか、あるいは同時移行可能か検討する。 - **システム移行方式** - システム並行稼働新環境にアーキテクチャを構築後、データを移行して旧環境と新環境を並行稼働させる。新環境が安定稼働後、旧環境を切り離すことでシステム移行が完了する。可用性要求が高い大規模システムの場合は並行稼働方式を選択するケースが多い。また、モダナイゼーションされたアーキテクチャの運用に不安がある場合などは、いつでも旧環境に戻せることがメリットとなる。 - サブシステム順次移行サブシステムや機能毎に分割して順次移行する。全てのサブシステムや機能が移行完了することでシステム移行が完了する。システム一括移行の場合、開発スケジュールがタイトになるような大規模システムの場合は、サブシステム順次移行を選択するケースが多い。また、新しい法律に係る機能を新環境にてモダンアーキテクチャで構築するなど、既存のシステムの影響を最小限にしながらモダナイゼーションを推進できる。 - システム一括移行システムを1回の移行作業で全て移行する。移行にかかるコストを抑えたい場合や、移行期間が短い場合に適した方式である。　 **表:07 システム移行方式比較** | 方式 | コスト | リスク | 作業負荷 | 移行期間 | | --- | --- | --- | --- | --- | | システム並行稼働 | 大：旧環境のシステム維持および新旧環境の
ネットワーク接続が必要 | 小：新環境でトラブルがあった際に旧環境に切り戻し可能 | 大：新旧環境のシステム運用およびシステム連携の
ためのネットワーク構築や運用が必要 | 長：新環境の正常性判断期間が必要 | | サブシステム順次移行 | 大：新旧環境のネットワーク接続が必要 | 小：新環境のトラブル範囲は移行対象のみ | 大：新旧環境のシステム連携のためのネットワーク構築や運用が必要 | 長：複数回の移行作業が必要 | | システム一括移行 | 小：移行作業にかかるコストのみ | 大：新環境でトラブルがあった際に旧環境に切り戻せない | 小：移行作業完了後は新環境の運用のみ | 短：1回の移行作業で完了 | 　 - **データ移行方式** データ移行のために業務が停止する時間はデータ移行の前処理、データ移行時間、データ移行後に新環境でサービスを開始するための後処理の時間を合計した時間となる。さらに移行失敗時の切り戻しを含めること。媒体等によるデータの物理移行について、クラウドはオンプレミスと違いユーザーがOCIのデータセンターに入館できないため、オンプレミスに比べると移行期間が長くなる点を留意する。ネットワーク経由でのデータ転送について、旧環境のネットワークの仕様などで転送速度がブロッカーとなる場合は、GSSにデータを持ち込み転送速度の速いGSSネットワーク経由で新環境にデータ転送する方式も検討する。また旧環境ネットワークのブラックボックス化やGSSの仕様などにより新旧環境のネットワークトラブルが想定されるため、早めのプロトコル疎通確認や転送速度の確認を実施する。 - データリアルタイム同期サービス停止時間は無し。新旧環境はアプリケーションレベルで同期、稼働状態とし、旧環境を停止することでシステム停止なく移行が完了。 - データ事前同期サービス停止時間は中。新環境への切替え前に新旧環境のデータを同期する。旧環境の停止、データの差分同期、新環境への切替えによって移行が完了。 - データ一括同期サービス停止時間は大。旧環境を停止後にバックアップデータを取得し新環境へ転送。新環境でバックアップデータからリストアし起動することで移行が完了。 - **業務切り替え方式** - ユーザー/ロケーション/業務順次移行特定の部門や地域を先行して移行する。先行移行に問題がない事を確認した後、先行移行以外の移行を実施することで移行が完了する。部門や地域によってシステムの影響度が違うケースなどは影響度の少ない部門や地域を先行移行することで、リスクを抑えた移行が可能となる。 - ユーザー/ロケーション/業務一括移行全ての部門や地域を一括で移行する。移行にかかるコストを抑えたい場合や、移行期間が短い場合に適した方式である。　 **表:08 ユーザー/ロケーション/業務切り替え方式比較** | 方式 | コスト | リスク | 作業負荷 | 移行期間 | | --- | --- | --- | --- | --- | | ユーザー/ロケーション/業務順次移行 | 大：旧環境のシステム維持および新旧環境の
ネットワーク接続が必要 | 小：新環境のトラブル範囲は先行移行対象のみ | 大：新旧環境のシステム運用およびシステム連携の
ためのネットワーク構築や運用が必要 | 長：先行移行対象の正常性判断期間が必要 | | ユーザー/ロケーション/業務一括移行 | 小：移行作業にかかるコストのみ | 大：新環境でのトラブル範囲が広い | 小：移行作業完了後は新環境の運用のみ | 短：1回の移行作業で完了 | 　 ### テクノロジ実装の検討 Cloud Adoption Frameworkのテクノロジ実装は、組織のニーズに合わせてデプロイされているクラウド環境に変換することに重点を置いている。ランディング・ゾーンをデプロイし、既存のオンプレミス・データ・センター・ソリューションをOCIへ移行する方法を提供する。なお、データベースおよびデータ移行の詳細は[「Replatformシステム移行ノウハウ（RDBのマネージドサービス化）」](https://guide.gcas.cloud.go.jp/oci/know-how-replatform-migrate-db/)を参照すること。 ### データベース移行データベースのクラウド移行では、インターネットまたはFastConnectやVPNなどのローカルネットワークを通して移行を行うのが一般的である。移行元と移行先のデータベースがOracle Databaseの場合、OCI Database Migrationやその他の手法で移行する。また、それ以外のリレーショナルデータベース、データウェアハウス、NoSQLデータベースなど様々な種類のデータベースをOCIに移行する際は、データベースレプリケーション機能や、OSSデータ転送ツール、またデータ転送ツールを開発することでデータ転送を実現することも可能である。 ![図06: Oracle Database移行フローチャート](/images/oci_how-to-migrate-system-06.jpg) **図06: Oracle Database移行フローチャート** [OCIドキュメント：Oracle Databaseの移行方式と選び方] https://speakerdeck.com/oracle4engineer/bmhefalseyi-xing [OCIドキュメント：Oracle Cloud Infrastructure Database Migrationの概要] https://docs.oracle.com/ja-jp/iaas/database-migration/doc/overview-oracle-cloud-infrastructure-database-migration.html ### データ移行データをクラウドに移行するにはネットワークの状態に応じて移行方法やOCIサービスを選択する必要がある。インターネットやFastConnect、VPNなどのネットワークを利用したオンラインデータ転送と、オフラインデータ転送のそれぞれで活用可能なOCIサービスを以下に示す。 #### オンラインデータ転送インターネットやFastConnectでのオンライン接続を使用して、大規模なデータをOCIへ移行する際に活用できるサービスやツールを以下に示す。 - OCI CLI OCIの標準コマンドラインツール。データ移行するサーバーにOCI CLIをインストールし、ファイルをOCI Object Storageへ一括データ移行する。ディレクトリ内のファイルを一括アップロードできるだけでなく、差分同期なども可能。 - Rclone クラウドストレージをターゲットとしたオープンソースのファイル同期ツール。ファイル同期だけでなくコピーや移動もできる。また、異なるクラウドストレージ間でファイルコピーもできる。OCI Object StorageのネイティブAPIをサポート。 - OCIFS LinuxからOCI Ojbect Storageのバケットをマウントしてデータ移行が可能。 [OCIドキュメント：OCIへのデータ移行] https://speakerdeck.com/ocise/ociji-shu-zi-liao-detayi-xing-detazhuan-song-sabisutosutorezigetouei #### オフラインデータ転送インターネットやローカルネットワークを経由せずに、オフラインで大規模なデータをOCIに移行する際に活用できるサービスを以下に示す。 - データ転送（Data Transfer）データ転送は、利用者が用意したディスクを使用しオフラインでOCIへデータを転送するサービスである。インターネットを介したデータの移動は、長い転送時間やセキュリティ上の問題により、常に実行できるとは限らない。データ転送はこれらの問題点に対処し、使いやすく、ネットワーク経由のデータ転送と比較しすばやくデータをアップロードできる。 [OCIドキュメント：データ転送サービスの概要] https://docs.oracle.com/ja-jp/iaas/Content/DataTransfer/Concepts/overview.htm ### アプリケーション移行アプリケーションはOCI Container InstancesやOCI Functionsをはじめとしたサーバーレス基盤、およびOKEを利用したマイクロサービスといったモダナイゼーションを前提とする。また、モダナイゼーションへの段階的移行などの理由でRebuildせずに移行する場合は、アプリケーション移行サービスを活用して作業工数の削減や移行期間の短縮を図る。 OCIでは現時点において、マネージドなアプリケーション移行サービスを提供していない。データやファイルを直接移行するか、OSSアプリケーション移行ツールを利用することで実現できる。 ## 改訂履歴 | 改訂年月日 | 改訂理由 | | --- | --- | | 2023年06月30日 | 新規作成 | | 2023年09月22日 | 参照先のタイトル変更に伴う修正 | | 2023年11月27日 | 「移行方式の検討」で参照先ドキュメントの記述を変更 | | 2024年02月02日 | 「データベースのエディション」部分の記述を変更
表01、表02のロードバランシングについて「OCI Network Load Balancer」を追加
表02からCDNの削除とOCI Database with PostgreSQLの追加
表03にOCI Database with PostgreSQLとOCI Cache with Redisを追加
表04のインベントリについて「テナンシ管理」を「OS Management」に修正
表04のリソース管理について「テナンシ管理」を「OCI Tagging、Cloud Advisor」に修正
表05のオンライン化（計算機のオートスケール）からコンテナインスタンスを削除
「データベース移行」に「Replatformシステム移行ノウハウ（RDBのマネージドサービス化）」と「Oracle Databaseの移行方式と選び方」へのリンクを追加
サービス名共通化など微細な文言修正| | 2024年05月10日 | 「データベースのエディション」を「データベースの概要」に変更、また同項目にExadata Database Serviceを追加
データベースの見直しの項目にExadata Database Serviceを追加
表03に特徴の項目を追加
図04、05の修正
図06を追加
データ移行の項目でストレージ・ゲートウェイ（Storage Gateway）を削除、データ転送（Data Transfer）において一部文言の修正
アプリケーション移行の項目で一部文言の修正
言葉の揺らぎを修正 | | 2024年06月14日 | サービス名変更に伴う修正「MySQL Database Service」から「MySQL HeatWave on OCI」に変更
「オンラインデータ転送」を追加
用語の揺らぎを修正| | 2024年07月19日 | サービス名変更に伴う修正「OCI Cache with Redis」から「OCI Cache」に変更
用語の揺らぎを修正| | 2024年09月02日 | 「ガバメントクラウドテンプレート」を「ガバメントクラウドテンプレート/ポリシー」に変更| | 2024年10月01日 | 正式名称改称に伴い記載を修正「Container Engine for Kubernetes（OKE）」から「 OCI Kubernetes Engine（OKE）」|

システム移行ガイド(OCI編)