OracleをEC2で自前運用するということ：構築から運用まで、想像以上に重い

多くのチームがシステムをAWSへ移行するとき、最初に考えるのは「昔からIDCでOracleを自分たちでインストールしていたのだから、EC2上でも同じようにできるはず」ということです。

インスタンスを起動し、ディスクをアタッチし、Oracleをインストールし、バックアップを設定すれば、サービスは接続できるようになります。この考え方は一見すると自然です。特に、社内にDBAがいて、長年積み上げてきた運用習慣がある場合はなおさらです。

しかし実際に始めてみると、OracleをEC2に載せることは、オンプレミスのサーバーをクラウド上のサーバーに置き換えるだけではないと気づきます。

クラウド前提で運用を設計し直さず、IDC時代のやり方をそのままAWSへ持ち込むと、構築から運用まで、すべてのステップが想像以上に重くなります。引き受けているのは単なるデータベースではなく、データベース基盤のライフサイクル全体です。

背景

多くの会社には専任のDBAがいます。経験のあるDBAにとって、データベースのスペックを決めること自体は難しくありません。どれくらいの容量が必要か、どのディレクトリを分けるべきか、どのデータファイルを独立したマウントポイントに置くべきかを理解しているからです。

よくある要件は、たとえば次のようなものです。

/        250 GB
/boot      1 GB
/tmp      25 GB
/data01  250 GB
/data02  250 GB
/data03  250 GB
/data04  250 GB
/data05  250 GB
/data06  250 GB
swap      16 GB

このような構成はオンプレミス環境では珍しくありません。root、tmp、data、swapを分けることで、I/O、容量、管理境界を明確にできます。DBAの視点では、これは適当に大きなディスクを要求しているのではなく、将来の運用リスクを減らすための設計です。

ただし、EC2上では、この分割の一つひとつが自分たちで扱うべきインフラの詳細になります。

この例では、EC2にr5.largeを使うと月額およそ109.44 USD、EBSを1792 GB構成すると月額およそ215.04 USDかかります。

つまり、データベースがまだ本番稼働していない初期構築の段階で、すでに月額で台湾ドル1万元近い基礎コストが発生します。

そしてこれは請求書に見えるコストだけです。本当に重いのは、AWS Billには直接出てこない人件費、保守コスト、障害リスクです。

事前作業

ステップ1：構築は起動するだけではない

オンプレミスIDCの経験がある人なら、Linuxコマンドには慣れているはずです。swapの初期化、ディスク確認、/etc/fstabの編集は、それ自体は難しい作業ではありません。

swapを初期化します。

sudo mkswap /dev/<swap-device>
sudo swapon /dev/<swap-device>

ホスト上のディスクIDを確認します。

lsblk

確認したディスクIDを/etc/fstabへ書き込みます。

sudo vi /etc/fstab

一度だけなら、これらのコマンドは大したことがないように見えます。しかしデータベースサーバーは通常のアプリケーションサーバーとは違います。データディスクを適当にマウントすることはできませんし、「たぶんこのディスク」で判断することもできません。

/data01から/data06までがすべて独立したディスクである場合、それぞれのEBS Volumeが正しいマウントポイントに対応しているか、再起動後も正しくマウントされるか、権限がOracleの要件に合っているかを確認する必要があります。

どこか一つでも間違えると、次のような問題が起きます。

• 再起動後にデータディレクトリがマウントされない。
• マウントポイントの順序が入れ替わり、意図しない場所へデータが書き込まれる。
• ファイルシステム、権限、ownerの設定ミスでOracleが起動しない。
• ディスク容量は足りているように見えるが、実際に使われているディレクトリが想定と違う。

本番環境では、これらの問題は非常に厄介です。修正のたびに停止時間、データ整合性、復旧計画が関わってくるからです。

ステップ2：コストはEC2とEBSだけではない

EC2上の自前OracleとManaged Databaseを比較するとき、多くの人はまず月額のインスタンス費用を見ます。

その比較自体は間違っていません。しかし不完全です。

EC2上でOracleを運用するなら、少なくとも次の項目も考える必要があります。

• EBS容量、IOPS、Throughputの設計。
• Snapshot、バックアップ保持、リージョン間冗長化。
• OS PatchとOracle Patch。
• 監視Agentのインストールと保守。
• Log収集、アラーム、通知。
• 復旧訓練と障害対応ドキュメント。
• 権限制御、鍵、接続セキュリティ、監査。

これらはすべて作業であり、多くは一度きりでは終わりません。

データベースは成長し、トラフィックは変化し、セキュリティ修正は継続的に発生し、バックアップ戦略もコンプライアンスや業務要件によって変わります。自前運用を選ぶなら、これらの責任はずっとチームに残ります。

ステップ3：監視は自分でつなぎ込む必要がある

RDSでは、多くのデータベースメトリクスをCloudWatchから直接確認できます。しかしOracleをEC2内にインストールする場合、ホスト層、ディスク層、データベース層の監視を自分たちでつなぎ込む必要があります。

基本的にはCloudWatch AgentとSystems Manager Agentをインストールし、収集した監視情報をCloudWatchへ送信できるよう、EC2 Instance Profile Roleに適切な権限を付与します。

そこからさらに、実務上の疑問が出てきます。

• CloudWatch Agentの設定ファイルは誰が保守するのか。
• どのmount pointのディスク使用率を収集するのか。
• Memory、swap、disk I/O、processも収集対象にするのか。
• Oracle listener、tablespace、archive logは追加監視するのか。
• Agentが壊れたときにアラームは出るのか。
• ディスク追加やマウントポイント変更時に、監視設定も更新されるのか。

監視がEC2のCPUだけで止まっているなら、データベースの可観測性としてはまだかなり足りません。

Oracleで深夜に人を起こす問題は、CPUが高いことだけではありません。archive logの枯渇、tablespace不足、I/O latencyの悪化、異常な接続数、バックアップ失敗、バッチ処理によるリソース枯渇などです。

これらはすべて、追加の設計が必要です。

ステップ4：データベースのインストールも「次へ」を押すだけではない

Red Hat Enterprise Linuxを使う場合、経験のあるDBAやシステム管理者にとって、パッケージインストール前に信頼できるsourceを確認し、GPG keyを検証し、公式repoへ切り替えることは自然な作業です。

しかしEC2上では、さらにもう一段あります。

専門的なDBAは、AMIに最初から入っているsourceをそのまま信頼しないかもしれません。公式repoを指定したり、会社のセキュリティ基準に従って承認済みの社内パッケージソースを使うことを求める場合もあります。これらの要求は妥当ですが、Oracleをインストールする前に、OSレベルのパッケージソース、依存関係、インストール権限、セキュリティ検証を先に処理しなければならないということでもあります。

もし過去にGUIでのインストールに慣れていると、全手順をコマンドで行う環境では、かなり早い段階で詰まる可能性があります。さらに厄介なのは、そうした問題がOracle自体の故障ではなく、OS、パッケージ、権限、インストール手順が事前にそろっていないことから起きる点です。

災難の始まり

ここまで来ると、データベースのデータをまだ投入していないにもかかわらず、事前作業だけでかなりの時間を消費していることに気づきます。

しかし、これはまだ始まりにすぎません。

本当に厄介なのは、データベースがシステムに使われ始めたあと、オンプレミス時代の習慣とクラウド環境の差が一つずつ表面化してくることです。

災難1：時刻が一致しない

あるとき、利用者からデータベースの時刻が一致しないと報告がありました。DBAの直感的な対応は、OS時刻を直接変更することでした。

sudo timedatectl set-time "2026-07-17 10:33:00"

単体サーバーであれば直感的に見える操作ですが、AWS上では連鎖的な問題を起こしやすくなります。

OS時刻を手動で変更した結果、CloudWatchはメトリクスの時刻が不正だと判断し、監視データが正常に書き込まれなくなりました。表面上はCloudWatchにデータがないように見えます。しかし調査していくと、根本原因はホスト時刻が手動で変更されていたことでした。

この種の問題が厄介なのは、最初はAgentが壊れているのか、IAM権限が間違っているのか、ネットワークが通らないのか、それとも時刻そのものが問題なのか判断しにくいことです。DBA、運用、クラウドチームが何度か確認したあとで、実は操作習慣の違いが原因だったと分かります。

より適切な対応は、システム時刻を直接変更することではありません。

• NTPまたはchronyで標準時刻へ同期させる。
• OS timezoneが必要な時区、たとえばAsia/Taipeiに設定されているか確認する。
• データベース、アプリケーション、レポートシステムでUTCを使うのかローカル時刻を使うのかを事前に決める。
• ホスト時刻のずれによって監視データが欠落しないようにする。

sudo timedatectl set-timezone "Asia/Taipei"

時刻の問題は小さく見えます。しかしデータベース、監視、監査、レポートが関わると、すぐにチーム横断の問題になります。

災難2：Snapshotがあるだけではバックアップ戦略にならない

EC2上でOracleを自前運用するとき、多くの人はまずEBS Snapshotを思い浮かべます。

Snapshotは有用です。しかし、それだけで完全なデータベースバックアップ戦略にはなりません。Oracleのようなデータベースでは、データ整合性、archive log、復旧時間、復旧ポイントを考える必要があります。

さらに厄介なのは、このマシンのroot diskも初期状態のきれいなディスクではないことです。/etc/fstabには複数のデータディスク向けに多くのカスタム設定が入っています。そのためrootをそのままリストアすると、古いディスクUUIDが書かれているせいで、新しく復元したEC2が起動できなかったり、マウントが異常になったりする可能性があります。

この時点で、復旧作業は「Snapshotからマシンを作る」だけでは済みません。たとえば次のような流れになります。

1. Snapshotからroot volumeを復元する。
2. 復元したroot volumeを別の利用可能なEC2へアタッチする。
3. /etc/fstab内の古いディスクUUIDに関する設定を修正、または一時的にコメントアウトする。
4. root volumeを起動対象のEC2へ戻す。
5. /data01から/data06までのデータディスクを一つずつ復元する。
6. 各データディスクが正しいmount pointへ戻っていることを確認する。

忘れてはいけないのは、/data01から/data06までがすべて同じ容量であることです。すべてのディスクが似て見える場合、復旧時にはVolume ID、UUID、ファイルシステムラベル、実際のマウントポイントを慎重に確認しなければなりません。

間違ったディスクをマウントすると、サービスが起動しないだけではありません。誤ったディレクトリにデータが書き込まれ、後始末がさらに苦しくなることもあります。

本番環境で使えるバックアップ戦略なら、少なくとも次の問いに答えられる必要があります。

• バックアップはどれくらいの頻度で取得するのか。
• 特定時点へ復旧できるのか。
• バックアップ失敗時、誰に通知されるのか。
• バックアップはどれくらい保持するのか。
• アカウント間またはリージョン間で保管する必要があるのか。
• 復旧手順を実際に演習したことがあるのか。
• 復旧後、アプリケーションはどのように切り替えるのか。

最も怖いのは、バックアップがないことではありません。皆がバックアップはあると思っていたのに、事故が起きてから使えない、復旧手順を誰も知らない、あるいは復旧時間がシステムの許容範囲を大きく超えると分かることです。

自前Oracleをうまく運用することはもちろん可能です。ただし、それには成熟したDBAプロセスと、そのプロセスを長期的に維持するチームの意思が必要です。

災難3：Patchとメンテナンスウィンドウは消えない

データベースはインストールして終わりではありません。

EC2にはPatchが必要です。Linuxパッケージは更新が必要です。セキュリティ脆弱性は追跡しなければなりません。Oracle自体にもバージョン更新やセキュリティ更新があります。Patchのたびに、リスク評価が必要になります。

• 停止は必要か。
• 停止時間はどれくらいか。
• Patch前にバックアップを取るべきか。
• 更新に失敗した場合、どうrollbackするのか。
• アプリケーションやDriverとの互換性はあるのか。
• 非本番環境で事前検証したのか。

チームに成熟したDBAやSREのプロセスがあるなら、これらは仕組み化できます。しかし、このOracleが特定システムに付属する一台のデータベースとして扱われているだけなら、話はたいてい「動いているなら触らない」になります。

その結果、システムは長く動き続けます。しかし誰もアップグレードに踏み切れず、メンテナンス時に何へ影響するのかも明確に分からない状態になります。

本当の問題：データベース基盤を自作している

OracleをEC2上に構築すること自体が間違いというわけではありません。

実際に必要な場面もあります。

• 特定のOracleバージョンや機能が必要。
• ライセンス形態がManaged Serviceに合わない。
• 特殊なOS、Agent、ファイルシステム要件がある。
• 社内に成熟したDBAチームと既存の標準プロセスがある。
• 高度にカスタマイズされたバックアップ、レプリケーション、運用アーキテクチャが必要。

しかし理由が「昔からIDCでそうしていたから」だけなら、注意が必要です。

EC2が提供するのはコンピュートリソースです。データベース基盤の責任までは引き受けてくれません。ディスク設計、バックアップ検証、監視の補完、Patch計画、障害復旧は、最終的にすべてチームへ戻ってきます。

だからこそ、Oracle on EC2の自前運用は想像以上に重いのです。

自分たちはデータベースを一台立てているだけだと思っていても、実際には24時間責任を持つ必要があるデータベース運用基盤を作っているのです。

結論

なぜ20年の経験を持つプロのDBAでさえ、Oracle on EC2の運用に苦戦することがあるのでしょうか。

問題は必ずしもクラウドのほうが難しいからではありません。オンプレミスとクラウドの間に巨大な技術的断絶があるからでもありません。

本当の問題は、「20年の経験」を「同じやり方を20年続けたこと」と理解してしまう人がいることです。環境、責任境界、ツールチェーンが変われば、昔から慣れている操作が今も正解とは限りません。

クラウドは、年次が長い人の習慣に自動で合わせてはくれません。OS時刻を手動で変えれば、CloudWatchはデータを受け取れなくなることがあります。/etc/fstabにUUIDを書き込めば、Snapshotからの復旧時に起動できなくなることがあります。自分の知っているインストール手順だけを信じていると、全コマンド操作、権限、repo、key検証の時点で、データ投入前に止まることもあります。

これは経験に価値がないという話ではありません。更新されない経験は、別の形の技術的負債になりやすいという話です。

20年のMySQL運用経験があるからといって、SQL ServerやOracleを必ずうまく管理できるとは限りません。同じように、20年のIDC運用経験があるからといって、クラウド上のデータベース基盤を必ずうまく管理できるとは限りません。プロフェッショナルであることは、昔どうやっていたかを知っていることだけではありません。今はなぜそのやり方を続けるべきではないのかを理解することでもあります。

チームに十分なDBA能力、明確な運用プロセス、そして自前運用でなければならない技術的またはビジネス上の理由があるなら、Oracle on EC2はもちろん選択肢になります。

しかし「クラウドに移れば運用が楽になる」と期待しながら、オンプレミスのやり方をそのままEC2へ移すだけなら、最終的にできあがるのは、クラウド上にあるように見えて、実際には古い運用思考に閉じ込められたデータベースです。

クラウドの本当の価値は、新しい方法でVMを起動できることではありません。自分たちで背負うべき責任と、Managed Serviceへ任せるべき責任を見直すことにあります。

Oracle on EC2を自前運用する最大の代償は、毎月のEC2とEBSの請求額とは限りません。

より大きな代償は、構築、監視、バックアップ、Patch、復旧、障害対応に対して、長期的に責任を持ち続けなければならないことです。