OCIの監視・ログ・バックアップを小規模構成で作る手順と、復元の練習

※当ページにはAmazonアソシエイト等の広告リンクを含みます。

何が起きたら誰に知らせるかを決める

先に決めるのは、メトリクスの一覧ではなく、起きたら困ることと、対応する人です。社員30人の社内アプリなら、対応するのは1〜2人でしょう。通知が多すぎると読まれなくなるので、対応が必要なものに絞ります。

最低限見るメトリクス

題材の構成で、まず見るものを表にしました。しきい値は編集部の出発点の例です。実際の値を2週間ほど見てから調整してください。

DatabaseAvailability が0になるのは Oracle 側の障害などのときです。利用者が止めた場合は0にならず、アプリから接続できない状態も示しません。開始と停止はイベントで見ます。StorageUtilization は1時間単位なので、検知が最大1時間ほど遅れます。

LB と Autonomous のメトリクスは、有効化の設定なしで出ます。一方、Compute は Oracle Cloud Agent の Compute Instance Monitoring プラグインが動いている必要があります。経路の作り方はVCNとゲートウェイの記事で確認できます。

アラームと Notifications

通知までの流れは図のとおりです。アラームは条件を1分に1回評価し、条件を満たすとトピックへメッセージを出します。トピックに登録したサブスクリプションが、実際の届き先です。

作る順番は次のとおりです。

1. Notifications でトピックを作る。名前はテナンシ内で重複できません。
2. サブスクリプションを追加する。Email、Slack、HTTPS（Custom URL）、SMS などが選べます。
3. 届いたメールの確認リンクを開く。確認するまでは保留のままで、配信されません。
4. Monitoring でアラームを作り、通知先に先ほどのトピックを選ぶ。
5. 実際に通知が届くかを試す。

アラームの条件は、MQL という問い合わせの言葉で書けます。次は公式の例の形です。

# CPU使用率の1分平均が80を超えたら
CpuUtilization[1m].mean() > 80

# 特定のCompute からデータが届かなくなったら（absent は既定で2時間まで検知）
CpuUtilization[1m]{resourceId = "<resource_identifier>"}.groupBy(resourceId).absent()

一時的な揺れで鳴らないよう、トリガー遅延（条件が続く分数）を設定します。Autonomous のメトリクスは、アラームの間隔を5分以上にします。

AWS の CloudWatch アラームから Amazon SNS トピックへ通知する形に慣れていれば、OCI のアラームとトピックも同じ感覚で読めます。OCI では発火中の再通知も設定できます。

ログを残し、Cloud Guard で設定を見張る

メトリクスは異常に気付くためのもの、ログは原因を追うためのものです。OCI の Logging では、対応サービスごとに「サービスログ」を有効にし、ログ・グループにまとめて保管します。保持期間は既定で30日で、180日まで30日単位で延ばせます。

LBログ

LBには、アクセスログとエラーログを1つずつ持たせられます。LBの作成時に設定していなければ、LBの詳細ページの Monitoring にある Logs の欄で有効にします。LBの設定権限があれば、追加のポリシーは要りません。

経費申請アプリでは、外出先からの接続を調べることがあるので、アクセスログも有効にしておくと役立ちます。保持期間は、調査でさかのぼる日数から決めます。

VCN Flow Logs

Flow Logs は、VNICが許可または拒否した通信の記録です。NSGのルールが想定どおりかを調べるときに使います。レコードの項目はアドレス、ポート、プロトコル、パケット数、バイト数などで、通信の本文を入れる項目はありません。

有効化する単位は、VCN、サブネット、VNIC、特定のリソースから選べます。題材では、private-app と private-db のサブネットから始めると範囲を絞れます。キャプチャ・フィルタでサンプリング率やルールも決められます。ログの量は料金に関わるので、まず狭く有効にして量を見ます。

ただし、VCN DNS、DHCP、ブロックストレージへの通信など、169.254.0.0/16 の一部の通信は記録されません。すべての通信が載るわけではない点に注意してください。

Cloud Guard の前提

Cloud Guard は、リソースの設定の弱点と、利用者の危険な操作を検知するサービスです。無料のテナンシでは使えず、有料テナンシが前提です。使い始める前に、次の点を押さえます。

• レポートリージョン：有効化のときに選びます。あとで変えるには無効化と再有効化が必要で、無効化するとカスタマイズと検知済みの問題の履歴が失われます。東京で運用するなら、最初に東京を選ぶか検討します。
• ターゲット：調べる範囲で、コンパートメントとその配下に効きます。問題を報告させるには、ターゲットとディテクタのレシピが要ります。ルート・コンパートメントも指定できます。
• 権限：管理用のグループを作り、cloud-guard-family のポリシーを与えます。セキュリティ情報を扱うので、対象者は絞ります。
• レシピ：ディテクタが問題を見つけ、レスポンダが対応します。最初は検知の結果を読むことから始めると安全です。

バックアップは置き場所ごとに決める

題材のデータは3か所にあります。同じ「バックアップ」でも、設定する内容が違います。

Compute のブートボリューム

Compute には、Block Volume のバックアップポリシーを割り当てます。アプリのデータは Autonomous にあるので、Compute で守るのはOSの設定とアプリの配置です。

いずれも増分バックアップです。Oracle 定義のポリシーは変更できず、別リージョンへのコピーや全体バックアップが必要なら、ユーザー定義のポリシーを作ります。バックアップは Object Storage に暗号化して保存され、Object Storage の料金がかかります。費用は保持する量で変わるので、最新は公式で確認してください。

Always Free のボリュームバックアップは、合計5個までです（2026-11-01確認）。Gold は枠をすぐ超えます。年次は5年残るので、小さな構成ではユーザー定義のポリシーで保持を短くすることも検討します。

Autonomous AI Database

Autonomous は自動でバックアップされます。ECPUモデルの既定の保持期間は60日で、1〜60日で変更できます。保持期間の中なら、任意の時点へ戻せます。単一ADのリージョンでは、バックアップはフォルト・ドメインをまたいで複製されます。

注意点は次の3つです。

• ECPUモデルでは、バックアップのストレージはDBのストレージとは別に課金されます（2026-11-01確認）。最新は公式で確認してください。
• オブジェクト・ストレージ上の外部ファイルはバックアップに含まれません。
• 長期バックアップ（3か月〜10年）は別の機能です。使えるのは新しいDBへのクローンだけで、元のDBへは戻せません。

Object Storage の領収書

領収書の取り違えや削除に備えるには、バケットのバージョニングを有効にします。無効のまま削除したオブジェクトは戻せないので、運用を始める前に設定します。バージョンの分だけ容量が増えることも見込んでおきましょう。

復元の練習をする

バックアップが「ある」ことと「戻せる」ことは別です。リリース前に一度、全体を通して戻してみます。

Compute を戻す

1. ブートボリュームのバックアップの操作メニューから Restore Boot Volume を選ぶ。
2. 戻したブートボリュームからインスタンスを作る。private-app に置き、公開IPは付けません。nsg-app は付けず、確認用のNSGを新しく作って付けます。受信は BastionのプライベートIP/32 からの TCP 22 だけにします。既定リストの全送信を外している場合は、送信に All NRT Services in Oracle Services Network への TCP 443 も足します。
3. Bastion 経由でログインし、アプリが起動するか確かめる。動的グループのルールは app 全体に効くので、戻したComputeもVaultやバケットに届きます。起動後はアプリとジョブが本番へつながらないことを確かめてから動かします。LBのバックエンドには足しません。A1 が枠を超える分は課金されるので、確認後すぐ片付けます。
4. 確認が済んだら、作ったインスタンスとブートボリュームを片付ける。

Autonomous を戻す

1. 詳細ページの More actions から Create clone を選ぶ。
2. Full clone を選び、Clone from a backup で時点を指定する。
3. ADMINのパスワードを設定する。ネットワークは Private endpoint access only にして、private-db と nsg-db を指定する。
4. 件数を確かめ、次のSQLで復旧時点を見る。

SELECT last_recover_time, last_recover_scn FROM dba_pdbs;

5. 確認が済んだらクローンを終了する。

クローンは最小2 ECPUの新しいDBなので、動かしている間は費用がかかります。また、DBを作った直後は、自動バックアップが使えるようになるまで最大4時間かかることがあります。

Object Storage を戻す

検証用のオブジェクトを1つ置いて削除し、バージョンの一覧から削除マーカーを外します。前のバージョンが現在のオブジェクトに戻ります。バージョンIDを指定した削除は、そのバージョンを消してしまう操作です。間違えないようにします。

次に読むページ

• 次の項目は「月額を見積もる」です。見積もりと予算アラートの記事で、バックアップやログも含めて構成全体の費用を説明できるようにします。
• 全体の順番は学習ロードマップで確認できます。