はじめに
Oracle Cloud Infrastructure（以下、OCI）では、Computeインスタンスから カスタムイメージ を作成できます。
カスタムイメージを利用すると、特定時点のインスタンスのブート・ディスクをイメージ化し、そのイメージから新しいComputeインスタンスを作成できます。
たとえば、以下のような用途で利用できます。
- 標準構成済みOSイメージの作成
- ミドルウェア導入済みイメージの作成
- 同一構成のインスタンス展開
- 構築済み環境の複製
- 障害時の再作成用イメージ
- 変更作業前の切り戻し用イメージ
- 定期的なブート・ディスク保全
本記事では、OCIのカスタムイメージの概要と、定期的に仮想マシンのバックアップデータとして利用する運用 について整理します。
あわせて、気になる仕様として以下にも触れます。
- カスタムイメージ作成時に対象インスタンスの停止が伴うこと
- カスタムイメージ作成にかかる所要時間が明確に公表されていないこと
- アタッチ済みBlock Volumeのデータはカスタムイメージに含まれないこと
- バックアップ用途として使う場合の注意点
1. カスタムイメージとは
カスタムイメージ は、OCI Computeインスタンスのブート・ディスクから作成する独自イメージです。
OCIでは、インスタンスを起動する際にイメージを指定します。
通常はOracleが提供するプラットフォーム・イメージを使いますが、既存インスタンスからカスタムイメージを作成することで、その時点のOSや設定を含んだイメージを保持できます。
既存Computeインスタンス
↓
カスタムイメージ作成
↓
カスタムイメージ
↓
新しいComputeインスタンスを作成
カスタムイメージを使用すると、イメージ作成時にインストールされていたソフトウェアや構成を含むインスタンスを起動できます。
2. カスタムイメージに含まれるもの・含まれないもの
カスタムイメージは、主に ブート・ディスク を対象としたイメージです。
そのため、アプリケーションの配置場所やデータの保存場所によって、バックアップとしての意味が変わります。
| 項目 | カスタムイメージに含まれるか |
|---|---|
| OS | 含まれる |
| OS設定 | 含まれる |
| ブート・ディスク上のファイル | 含まれる |
| インストール済みソフトウェア | 含まれる |
| ミドルウェア設定 | ブート・ディスク上にあれば含まれる |
| アタッチ済みBlock Volumeのデータ | 含まれない |
| 外部ファイルストレージ上のデータ | 含まれない |
| Object Storage上のデータ | 含まれない |
重要なのは、カスタムイメージにはアタッチされたBlock Volumeのデータは含まれない という点です。
たとえば、以下のような構成の場合です。
Boot Volume
- OS
- ミドルウェア
- 設定ファイル
Block Volume
- アプリケーションデータ
- ログ
- ファイル
- DBデータ
カスタムイメージで取得されるのは、基本的にBoot Volume側です。
Block Volume側のデータを保護したい場合は、別途 Block Volume Backup やアプリケーションバックアップを利用する必要があります。
3. カスタムイメージの主な利用用途
カスタムイメージは、バックアップ用途だけでなく、標準化や複製にも利用できます。
| 利用用途 | 内容 |
|---|---|
| 標準OSイメージ | パッチ適用済み、セキュリティ設定済みの標準イメージを作る |
| テンプレート化 | ミドルウェアやエージェント導入済みのイメージを作る |
| 複製 | 同じ構成のインスタンスを複数作成する |
| 検証環境作成 | 本番相当の構成を検証環境に展開する |
| 変更前保全 | 大きな変更作業前に切り戻し用として取得する |
| 障害時復旧 | 障害時に同じ構成のインスタンスを再作成する |
| 定期保全 | ブート・ディスクの状態を定期的に保存する |
特に、OSやミドルウェア設定を含めた「サーバ構成の状態」を保持したい場合に有効です。
4. カスタムイメージをバックアップ用途で使う考え方
カスタムイメージは、定期的に取得することで、Computeインスタンスのブート・ディスクに対するバックアップのように利用できます。
定期的にカスタムイメージを作成
↓
世代管理
↓
障害時にカスタムイメージから新規インスタンス作成
ただし、カスタムイメージは一般的なバックアップ機能とは少し性質が異なります。
どちらかというと、インスタンス再作成用のOSイメージ として考えるのが自然です。
カスタムイメージを使った復旧イメージ
障害発生
↓
直近のカスタムイメージから新規Computeを作成
↓
必要に応じてBlock Volume Backupからデータボリュームを復元
↓
アプリケーション起動
このように、カスタムイメージは OS・設定・ミドルウェア構成の復旧 に使い、データ領域は別途Block Volume Backupなどで復旧する構成が現実的です。
5. 定期バックアップ運用として利用する場合の構成例
カスタムイメージを定期的に取得する場合、ブート・ディスクとデータ領域の保護方法を分けて考える必要があります。
Compute Instance
├─ Boot Volume
│ └─ カスタムイメージで定期保全
│
└─ Block Volume
└─ Block Volume Backupで定期保全
この構成では、以下のように役割を分けます。
| 対象 | 保全方法 |
|---|---|
| Boot Volume | カスタムイメージ |
| Block Volume | Block Volume Backup |
| アプリケーションデータ | Block Volume Backupまたはアプリケーションバックアップ |
| DBデータ | DBネイティブバックアップ |
| 設定ファイル | カスタムイメージ、構成管理、Gitなど |
カスタムイメージだけで仮想マシン全体のバックアップが完結するわけではありません。
インスタンスの構成に応じて、複数のバックアップ方式を組み合わせる必要があります。
6. カスタムイメージ作成時の停止について
カスタムイメージをバックアップ運用で使う場合に最も注意したいのが、カスタムイメージ作成時のインスタンス停止 です。
OCIドキュメントでは、実行中のインスタンスのイメージを作成すると、インスタンスが停止し、数分間使用できない状態になり、プロセス完了後に再起動すると説明されています。
実行中インスタンス
↓
カスタムイメージ作成開始
↓
インスタンス停止
↓
カスタムイメージ作成
↓
インスタンス再起動
そのため、カスタムイメージを定期的なバックアップ用途で利用する場合、無停止バックアップとしては扱えません。
業務時間中に取得すると、サービス停止が発生する可能性があります。
注意点
| 注意点 | 内容 |
|---|---|
| 停止が伴う | 実行中インスタンスから作成すると、インスタンスが一時停止する |
| サービス影響がある | アプリケーション停止やユーザー影響が発生する可能性がある |
| 再起動が伴う | イメージ作成完了後にインスタンスが再起動する |
| 停止時間は固定ではない | 数分と記載されているが、明確な完了時間は公表されていない |
| メンテナンス時間帯が必要 | 本番環境では夜間・休日などの実施を検討する |
7. 作成時間が明確に公表されていない点
カスタムイメージ作成にかかる所要時間について、OCIドキュメントでは 数分間使用できない状態になる という説明はあります。
一方で、以下のような要素に応じて、実際の所要時間は変わる可能性があります。
- インスタンスの状態
- ブート・ディスクのサイズ
- OSのシャットダウンにかかる時間
- 実行中プロセスの状態
- イメージ作成時の内部処理
- リージョンやサービス側の状況
そのため、必ず何分で完了する という前提で運用設計するのは避けた方がよいです。
運用上の考え方
数分で終わる前提ではなく、
メンテナンス時間を確保して実施する
特に本番環境では、事前に検証環境で以下を確認しておくことを推奨します。
- カスタムイメージ作成にかかる実測時間
- インスタンス停止時間
- アプリケーション停止・起動時間
- OS再起動後のサービス起動状態
- 業務影響
- 監視アラートの発報有無
8. 同一インスタンスで同時に複数イメージは作成できない
カスタムイメージ作成中のインスタンスについて、追加のカスタムイメージを作成することはできません。
また、カスタムイメージ作成を開始すると、同じインスタンスに対して20分のタイムアウトが実装され、その間は同じインスタンスの別イメージを作成できません。
Instance-A
↓ カスタムイメージ作成中
↓
Instance-Aの追加イメージ作成は不可
ただし、別のインスタンスのイメージは同時に作成できます。
Instance-A → Image-A 作成中
Instance-B → Image-B 作成可能
この仕様は、複数インスタンスを順番にバックアップする運用を考える際に重要です。
9. カスタムイメージを定期バックアップ運用に使う場合のメリット
カスタムイメージを定期取得する運用には、以下のメリットがあります。
| メリット | 内容 |
|---|---|
| 復旧時に新規インスタンスを作りやすい | イメージからインスタンスを起動できる |
| 構成済み状態を保持できる | OS設定や導入済みソフトウェアを含められる |
| 変更前の保全に使える | パッチ適用や設定変更前に取得できる |
| テンプレートとして再利用できる | 同一構成のサーバ展開に利用できる |
| 障害時の再作成がしやすい | インスタンスを作り直す手段として使える |
特に、手作業で多くの設定を行っているサーバでは、カスタムイメージがあると再構築の手間を減らせます。
10. カスタムイメージを定期バックアップ運用に使う場合のデメリット
一方で、以下のデメリットや注意点もあります。
| デメリット | 内容 |
|---|---|
| 停止が伴う | 実行中インスタンスから作成すると停止・再起動が発生する |
| 取得時間が読みにくい | 所要時間が明確に保証されていない |
| データボリュームは含まれない | Block Volumeのデータは別途バックアップが必要 |
| 世代管理が必要 | 古いイメージの削除運用が必要 |
| 保存コストが発生する | 格納されているイメージには課金が発生する |
| リージョン間レプリケーション非対応 | カスタムイメージのリージョン間レプリケーションはサポートされていない |
| 復旧手順の整備が必要 | イメージ作成だけではDRや復旧運用は完成しない |
バックアップ用途として使う場合は、取得運用だけでなく、復旧手順 と 世代削除運用 まで考える必要があります。
11. カスタムイメージと他のバックアップ方式の使い分け
カスタムイメージだけでなく、OCIには複数のバックアップ・保全手段があります。
| 方式 | 主な対象 | 向いている用途 |
|---|---|---|
| カスタムイメージ | Boot Volume中心 | OS・設定・ミドルウェア構成の再作成 |
| Boot Volume Backup | Boot Volume | ブート・ボリューム単位の復元 |
| Block Volume Backup | Block Volume | データボリュームのバックアップ |
| Volume Group Backup | 複数ボリューム | VM構成全体に近い単位での整合性確保 |
| Object Storage | ファイル・バックアップデータ | 長期保管、外部バックアップ |
| DBネイティブバックアップ | データベース | DB整合性を考慮したバックアップ |
使い分けの考え方
インスタンス構成をテンプレート化したい
→ カスタムイメージ
Boot Volumeを復元したい
→ Boot Volume Backup
データボリュームを復元したい
→ Block Volume Backup
複数ボリュームをまとめて保護したい
→ Volume Group Backup
DB整合性を重視したい
→ DBネイティブバックアップ
カスタムイメージは便利ですが、バックアップ要件をすべて満たすものではありません。
12. 本番環境での推奨運用
本番環境でカスタムイメージを使う場合、以下のような運用が現実的です。
定期バックアップの主役
→ Boot Volume Backup / Block Volume Backup / DBバックアップ
構成済みOSの保全
→ カスタムイメージ
大きな変更作業前の切り戻し用
→ カスタムイメージ
新規展開用テンプレート
→ カスタムイメージ
カスタムイメージを定期取得する場合でも、停止が伴う点を考えると、毎日頻繁に取るというよりは、以下のようなタイミングで取得するのが扱いやすいです。
- 月次パッチ適用後
- ミドルウェア更新後
- 重要な設定変更前
- 重要な設定変更後
- 週次または月次のメンテナンス時間帯
データ保護については、Block Volume Backupやアプリケーションバックアップを併用する方が安全です。
13. 設計時の注意点
1. 無停止バックアップとして設計しない
カスタムイメージ作成時にはインスタンス停止が伴うため、無停止バックアップとして設計しない方がよいです。
業務影響があるシステムでは、必ずメンテナンス時間を確保します。
2. 所要時間を固定値として扱わない
ドキュメントでは数分間の停止と説明されていますが、作成完了までの時間が明確に保証されているわけではありません。
運用設計では、実測と余裕を持ったメンテナンス時間を前提にします。
3. データボリュームを別途保護する
カスタムイメージにはアタッチ済みBlock Volumeのデータは含まれません。
データボリュームがある場合は、Block Volume Backupやアプリケーションバックアップを必ず組み合わせます。
4. 復旧先のネットワーク設定を考慮する
カスタムイメージから新規インスタンスを作成する場合、復旧先のVCN、サブネット、NSG、Private IP、DNS、Load Balancerなどをどうするかを決めておく必要があります。
5. 定期的に復旧テストを行う
カスタムイメージを取得していても、実際に起動できなければ意味がありません。
定期的に以下を確認します。
カスタムイメージから新規インスタンスを起動できるか
OSが正常に起動するか
アプリケーションが起動するか
必要なBlock Volumeをアタッチできるか
ネットワーク接続できるか
14. まとめ
OCIのカスタムイメージは、Computeインスタンスのブート・ディスクをもとに独自イメージを作成し、そのイメージから新しいインスタンスを起動できる機能です。
OS設定やミドルウェア導入状態を含めて保全できるため、以下の用途に向いています。
構成済みインスタンスのテンプレート化
変更作業前の切り戻し用
障害時の再作成用
定期的なブート・ディスク保全
一方で、バックアップ用途として使う場合には重要な注意点があります。
カスタムイメージ作成時にインスタンス停止が伴う
作成所要時間は明確に保証されていない
アタッチ済みBlock Volumeのデータは含まれない
古いイメージの世代管理が必要
保存コストが発生する
復旧手順の整備が必要
そのため、カスタムイメージは「仮想マシン全体の完全バックアップ」というより、OS・設定・ミドルウェア構成を保持するためのイメージバックアップ として使うのが自然です。
実運用では、以下のように役割分担することを推奨します。
OS・ミドルウェア・設定
→ カスタムイメージ
Boot Volume単位の復元
→ Boot Volume Backup
データボリューム
→ Block Volume Backup
DBデータ
→ DBネイティブバックアップ
長期保管
→ Object Storage
特に本番環境では、カスタムイメージ作成時の停止影響と作成時間の不確実性を考慮し、メンテナンス時間帯で実施することが重要です。
また、カスタムイメージを定期取得するだけでなく、実際にそのイメージからインスタンスを起動できるか、定期的に復旧テストを行うことが大切です。