オンプレのOracleで長く運用してきたDBAが、RDS for Oracleに移行したとき、最初に戸惑うのは性能ではなく「いつもの操作ができない」ことでした。
SSHでログインしようとしても入れない。
ALTER SYSTEM を実行しようとしても通らない。
オンプレで使っていた SYSDBA 前提の操作が、そのまま使えない。
サーバーは動いている。Oracleも動いている。なのに、これまで当たり前に使っていた運用手順が通用しない。
原因は、DBの設定ミスでも権限設定の漏れでもありませんでした。
RDSがマネージドサービスとして設計された構造上、オンプレで「当たり前」だった低レイヤーへのアクセスが、そもそも提供されていないのです。
今回の記事で伝えたいのは、RDSが劣っているという話ではありません。
マネージドの恩恵とトレードオフは表裏一体です。RDSを選ぶ時点で、オンプレの運用設計をそのまま持ち込まない前提が必要になります。
ここがポイントです。
なぜRDSではオンプレと同じ運用ができないのか
RDSは、AWSがOSとDB基盤の管理を代行するサービスです。
パッチ適用、バックアップ、フェイルオーバー、レプリケーション。これらをAWS側に任せられる一方で、ユーザーはOSやDBの深いレイヤーに直接触れることができません。
オンプレのOracle運用では、DBAがOSにログインしてリソースを確認し、カーネルパラメータを見直し、SYSDBA権限でDBの内部状態を操作することがあります。しかし、RDS for Oracleではその前提が根本から変わります。
これは単なる制限ではなく、マネージドサービスとしての設計上の選択です。ただし、事前に把握していないと、開発中に次々と壁にぶつかります。
今回、開発中に見えてきたギャップを整理すると、大きく以下の領域に分かれます。
「オンプレの感覚と、RDSで必要になる考え方」
上の図は、オンプレでの感覚と、RDSで必要になる考え方の違いを整理したものです。
ここからは、開発中に実際に表面化した設計ギャップを、具体的に見ていきます。
開発中に見えた設計ギャップ
① ストレージは「空き容量」だけを見ていると詰まる
この案件では、REDOログ・ファイルのサイズを大きく設定していたこともあり、空き容量が少なくなった局面で Storage-Full が発生しました。
Storage-Full になると、インスタンス操作やSQL*Plusでの接続にも影響し、通常の手順では復旧しづらい状態になります。
ここで注意したいのは、「空き容量がまだ少し残っているから大丈夫」とは限らない点です。
Storage-Full になると、インスタンス操作やSQL*Plusでの接続にも影響し、通常の手順では復旧しづらい状態になります。
オンプレであれば、OSにログインして一時的に領域を空ける逃げ道があります。しかし、RDS for OracleではOS上で直接ファイルを操作できません。容量が詰まってから「中に入って何とかする」ことはできず、ストレージ拡張など、RDSとして提供されている操作で対応する必要があります。
そのため、REDOログやアーカイブログのサイズ、生成量、一時的な蓄積を含めてストレージ容量を設計する必要があります。REDOログのサイズを不用意に大きくすると、容量の小さい環境では問題が表面化しやすくなります。本番環境よりも開発環境で先に問題が出るパターンです。
② アーカイブログは「出した後」の挙動まで設計する
この案件では、アーカイブログが一度RDS側のストレージに出力され、その後S3へ転送される構成でした。ただし、S3へ転送されるまで、また転送後にRDS側から削除されるまでにはタイムラグがあります。アーカイブログは生成後すぐに容量影響がゼロになるわけではありません。
退避先を用意していても、転送されるまでの間、削除されるまでの間はRDS側のストレージを使います。
生成量が多いタイミングでは、特に容量の小さい開発環境で、この一時的な蓄積によって Storage-Full になるケースがありました。
アーカイブログは「出したら終わり」ではありません。RDSでは、出力、転送、削除まで含めて容量設計する必要があります。
③ ストレージは増やせるが、必要な分を即座に増やせるわけではない
ストレージを拡張する際、以下の2点に注意が必要です。
拡張サイズは現在の割り当てから10%以上でないとエラーになる
小刻みな拡張はできません。10%未満の増量を指定するとエラーで拒否されます。開発環境のように小さい容量で構築していると、この制約が意外と効いてきます。
ストレージ変更後、一定時間は再度の変更ができない
拡張後は `storage-optimization`（ストレージ最適化）ステータスになり、完了まで数時間から数十時間かかります。ストレージ最適化が完了するか、変更から6時間が経過するまでのいずれか長い方が経過するまで、次のストレージ変更はできません。
使用量が急増するケースでは、連続した拡張ができないため、「足りなくなったら少しずつ増やせばよい」という考え方が通用しない場合があります。初期サイジングを余裕を持って設計することが重要です。
④ オンプレで当たり前だった管理操作が、別の手段に置き換わる
RDS for Oracleでは、オンプレのように SYSDBA で接続してDB全体を自由に操作する前提ではありません。代わりに以下の2つが用意されています。
RDSのマスターユーザー（master_user）
DBA権限を持ちますが、システム変更に関する一部操作が制限されます。オンプレと同じSQLをそのまま実行できない場合があります。
RDSADMINユーザー
ユーザーが直接使用することはできません。ただし、AWSが用意したパッケージやプロシージャを経由することで、システム変更に関する操作が可能です。
たとえばログスイッチは、以下のように変わります。
-- オンプレ
ALTER SYSTEM SWITCH LOGFILE;
-- RDS for Oracle
EXEC rdsadmin.rdsadmin_util.switch_logfile;
対応コマンドは少しずつ増えていますが、現時点でもカバーされていない操作があります。「いつものコマンドが通らない」という場面は、移行後に発生し得る前提で考えておくべきです。移行前に、オンプレで使っているコマンド・操作の棚卸しとRDS側の代替確認が必須です。
⑤ 障害時に必要なファイルを、OS上から直接集められない
RDSではOSへのSSHログインができないため、ファイルへのアクセスは「Amazon RDSプロシージャ」経由に限定されます。
DATA_PUMP_DIR 配下のファイルなど、マネジメントコンソールからダウンロードできないファイルは、RDSプロシージャを使って一旦S3にアップロードしてからダウンロードする手順が必要です。
特に注意が必要なのがADRディレクトリです。オンプレであれば、障害時にADR配下のファイルを確認してOracleサポートへ提供することがあります。しかし、RDS for Oracleでは**「サポートから言われたファイルをOS上で探してzip化する」というオンプレの感覚では動けません。**
RDS for Oracleでは rdsadmin.rdsadmin_adrci_util などを通じてADR関連の情報取得やインシデントパッケージ作成の手段が用意されていますが、オンプレのようにOSログインでファイルを直接収集できるわけではありません。
OracleサポートやAWSサポートに調査資料の提供を求められた場合、何をどの手順で提供できるかは事前に確認しておく必要があります。本番障害が起きてから手順を確立しようとしても遅いです。
⑥ 監査ログや診断ファイルは、出力したまま放置すると障害要因になる
オンプレでは、監査ログやトレースファイルをOS上に出力し、必要に応じて整理・退避する運用を組めます。しかし、RDSではOS上で直接ファイル操作ができません。
この案件では、Oracleのログイン監査で監査証跡をファイルとして出力していたところ、RDS内部のファイル保持数の上限に引っかかり、ファイル書き込みエラーが発生しました。その結果、RDSにログインできなくなる障害につながりました。
RDS内部のファイル保持数には上限がありますが、その上限値はAWSから公開されておらず、ユーザーが変更することもできません。上限値が非公開である以上、「どこまで出力できるか」を事前に把握することはできません。
監査ログ、トレースファイル、ダンプファイルなどをRDS内部に出し続ける設計にする場合は、定期的なクリーンアップ処理を必ず組み込んでください。監査ログはセキュリティ要件を満たすために必要ですが、出力設計を誤ると、監査ログ自体が障害要因になります。
⑦ DBのタイムゾーン設定だけでは、Schedulerジョブの時刻は保証できない
RDS for Oracleでは、オプショングループでタイムゾーンを設定できます。しかし、それだけでOracle Schedulerジョブのタイムゾーンまで意図通りになるとは限りません。
この案件では、RDSのオプショングループでタイムゾーンを設定していても、Oracle Schedulerジョブのタイムゾーンは Etc/UTC のままでした。
日本時間でスケジュール実行したいジョブがある場合、Oracle Scheduler側にも追加でタイムゾーン設定が必要になります。設定漏れがあると、ジョブが意図した時刻に動きません。これは開発中には見落とされやすく、本番稼働後に発覚すると影響が大きい問題です。
-- Oracle Schedulerのデフォルトタイムゾーンを変更する例
BEGIN
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE(
attribute => 'default_timezone',
value => 'Asia/Tokyo'
);
END;
/
RDSのタイムゾーン設定と、Oracle Schedulerのタイムゾーン設定は、分けて確認する必要があります。
⑧ Multi-AZは、配置が変わる前提で性能と運用を設計する
Multi-AZ構成では、プライマリが常に特定AZに固定され続ける前提では設計できません。障害時やメンテナンス時のフェイルオーバーにより、プライマリの配置先AZが変わる可能性があります。
この案件では、RDSとAPサーバーが異なるAZに配置された状態が発生し、AZ間のレイテンシによる処理遅延が問題になりました。一時対応として手動フェイルオーバーで配置を寄せた場面もありましたが、本来はAPサーバーとDBのAZ配置が変わり得る前提で、レイテンシ、接続先、リトライ、監視を設計しておくべきでした。
RDSを選ぶ時点で、「常に特定AZに固定され続ける」という前提ではなく、フェイルオーバーやメンテナンスで配置が変わり得る前提に切り替える必要があります。
⑨ 停止したRDSも、7日後には自動で起動する
RDSは、停止したまま放置できるサービスではありません。
Amazon RDSのDBインスタンスは、一時停止しても7日後に自動で起動します。これは、メンテナンス適用から長期間取り残されないようにするための仕様です。
この仕様を知らないと、開発環境や検証環境で思わぬコストが発生します。
たとえば、金曜夜に高スペックのRDSを停止したつもりでも、7日後に自動起動し、そのまま週末に誰も気づかず動き続けることがあります。停止中はインスタンス時間の課金は発生しませんが、ストレージやバックアップの課金は残ります。さらに、自動起動後は通常どおりインスタンス時間の課金も再開します。
オンプレやEC2の感覚で「止めておけば安心」と考えると、RDSではコスト事故につながります。
長期間使わない環境であれば、単に停止するだけでなく、自動起動後に再停止する仕組みや、不要環境の削除、スナップショット退避なども含めて設計する必要があります。
RDSでは、起動・停止も運用設計の一部です。
代替アプローチ：RDSでの運用をどう設計するか
オンプレの「低レイヤーを直接触る」アプローチはできません。しかし、RDSには別の手段が用意されています。重要なのは、オンプレのやり方を無理に持ち込むことではなく、RDSで提供されている手段に合わせて、運用設計を組み替えることです。
CloudWatch Database Insights / Performance Insights：AWR/ASHの代替として使う
オンプレのOracleでは、AWR（Automatic Workload Repository）やASH（Active Session History）でボトルネックを分析するのが定番でした。RDSでもEEライセンスのBYOL環境であればこれらは使えますが、SE2ライセンス込みモデルでは利用できません。
この代替として使えるのが CloudWatch Database Insights / Performance Insights系の可視化機能です。どのSQLが、どの待機イベントで詰まっているかをダッシュボードで可視化でき、問題のあるSQLをその場で特定できます。
以前はPerformance InsightsでボトルネックとなるSQLを特定した後、別途で実行計画の調査を実施する必要がありました。現在はCloudWatch Database Insights上でOracleの実行計画を直接確認できるようになっており、SQLの詳細情報と実行計画を同一画面で確認できます。インデックス作成前後など同一クエリの実行計画を並べて比較することも可能です。
ただし、利用できる機能や保持期間は、Database Insightsの設定モードや契約条件によって変わります。実行計画の確認まで運用で使う場合は、事前に対象インスタンスで有効化状態と利用可能な機能を確認しておくべきです。
パラメータグループ：init.oraの代替として使う
オンプレでは init.ora や SPFILE で初期化パラメータを自由に変更できましたが、RDSでは DBパラメータグループ 経由で変更します。変更不可のパラメータが存在する点と、一部パラメータの変更にインスタンス再起動が必要な点はオンプレと異なります。変更可能なパラメータの範囲を事前に確認しておくことが重要です。
拡張モニタリング：OSメトリクスの代替として使う
SSHログインができないため top や iostat は叩けませんが、拡張モニタリング を有効にすることで、OSレベルのCPU・メモリ・I/Oの詳細メトリクスをCloudWatchで確認できます。1秒間隔まで設定できるため、瞬間的な負荷スパイクの把握も可能です。
スケールアップ：チューニングより先に試す選択肢
クラウドの最大の強みは、数クリックでインスタンスクラスを変えられることです。チューニングに数日かけるより、インスタンスタイプをひとつ上げてCPUとメモリを倍にする、あるいはプロビジョンドIOPSを追加する方が、時間とコストの観点から合理的なケースがあります。問題の切り分けとして「リソース不足なのか」「SQLや設計の問題なのか」を早く見極めるための選択肢として、スケールアップも検討に入れてください。
SQLチューニング：最も重要な主戦場
インフラ側が触れない分、アプリケーション・SQLレイヤーでの最適化がオンプレ以上に重要になります。実行計画の確認（Explain Plan）、適切なインデックス設計、バインド変数の利用、統計情報の更新。これらはRDSでも変わらず有効で、かつ最も効果が出やすい領域です。
示唆：RDS採用時に設計へ織り込むべきこと
今回挙げたギャップの中には、ドキュメントを読めば事前に分かるものもあります。たとえば、SYSDBA前提の操作がそのまま使えないことや、RDS固有の管理手段を使う必要があることは、構築前の段階で把握できます。
一方で、Storage-Full、アーカイブログの一時蓄積、監査ログ出力、Schedulerの時刻設定、停止後の自動起動のように、実際に開発・検証環境で動かして初めて影響が見えやすいものもあります。
重要なのは、「PoCで動いたか」だけを見るのではなく、RDSを採用する時点で、運用設計・監視設計・コスト管理にこれらの制約を織り込んでおくことです。
容量・ストレージ挙動
ログの一時蓄積、Storage-Fullの発生条件、ストレージ拡張の制約を設計時に確認する。開発環境のサイジングは本番より小さくなりがちなため、これらが先に表面化しやすい。
ファイル操作・監査設計
大量ファイルを出力する設計がある場合、保持数の上限（非公開）と退避方法を確認する。監査ログ、トレース、ダンプファイルは、クリーンアップ処理まで運用設計に組み込む。
権限・管理操作
オンプレで使っているコマンド・権限がRDSで使えるかを一覧化し、代替手段まで確認する。「使えないことがわかった」で終わらず、「RDSではどう実現するか」まで詰めておく。
スケジューラと時刻設定
Oracle Schedulerを使うジョブがあれば、タイムゾーン設定を移行前に確認する。本番稼働後に発覚すると影響が大きい。
停止運用とコスト管理
開発・検証環境のRDSを長期停止する場合、7日後の自動起動を前提に再停止の仕組みや削除方針を決めておく。停止中も課金される項目（ストレージ、バックアップ）があることも把握しておく。
まとめ
今回のギャップを整理すると、こうなります。
RDSはAWSがOS・DB基盤を管理するトレードオフとして、ユーザーは低レイヤーに触れることができません。SYSDBA操作、OSアクセス、物理ファイル操作、一部の初期化パラメータ。これらはオンプレでは当然使えていたものが、RDSでは使えないか、別の方法に置き換わっています。
一方、CloudWatch Database Insights / Performance Insightsによる実行計画の可視化、拡張モニタリング、パラメータグループといった代替手段は年々充実しています。「以前はできなかった」ことが、アップデートで可能になっていくサービスでもあります。
重要なのは「RDSでできないことを嘆く」ことではなく、**「RDSで何ができて、何はできないのかを移行前に把握しておく」**ことです。
「起動した」「接続できた」「SQLが流れた」だけでは、RDS for Oracleを業務で使える確認にはなりません。障害時に調査できるか、容量が逼迫したときに復旧できるか、監査ログが障害要因にならないか、停止したつもりのRDSが自動起動していないか。そこまで確認して初めて「運用できる」と言えます。
ただし、これはRDSが不便だという話ではありません。OSやDB基盤の管理をAWSに任せることで、パッチ適用、バックアップ、フェイルオーバー、監視連携といった運用負荷を下げられるのがRDSの価値です。
その価値を活かすためには、オンプレと同じ操作権限を求めるのではなく、RDSで提供される仕組みに合わせて運用を再設計する必要があります。
オンプレの運用手法をそのまま持ち込むのではなく、RDSを選ぶ時点で、運用とチューニングのアプローチを切り替える。これが、RDS for Oracleを業務で使ううえで重要な前提になります。
参考リンク
関連記事
今回の話は、RDS for Oracle固有の制約というより、クラウドリフトPoCで見落としやすい設計リスクの一例です。PoCで何を確認すべきかは、以下のシリーズでも整理しています。
コメント