OCI Notifications

解決する課題

監視アラームやシステムイベントを、宛先ごとの実装を持たずに一斉通知できます。

1つのイベントを 複数の宛先へ同報したい（メール＋Slack＋関数など）
送信側（アラーム・Events）は宛先を意識せず 疎結合に通知したい
障害アラートを Email / SMS で担当者へ飛ばしたい
イベントを Functions / OCI Queue に渡してサーバーレスに後続処理させたい

主要概念と用語

トピック（Topic）: 配信の単位。ここへ publish する。OCID で識別され、コンパートメントに属する
サブスクリプション（Subscription）: トピックの購読先。1トピックに複数登録でき、ファンアウトの実体
プロトコル（Protocol）: サブスクリプションの種類。EMAIL / SMS / HTTPS（カスタム URL）/ SLACK / PAGERDUTY / ORACLE_FUNCTIONS（関数）/ ORACLE_QUEUE（OCI Queue）
メッセージ（Message）: トピックへ publish する本文。RAW または E2E_COMPATIBLE_2（Email 整形）形式
確認（Confirmation）: Email / HTTPS / Slack などは登録時に確認リンクを踏むまで Pending で、配信されない
アラーム連携: Monitoring のアラームの宛先としてトピックを指定する典型用途

仕様・制限・クォータ

プッシュ型。トピックへの publish が、紐づく全サブスクリプションへ配信される（プル/ポーリングではない）
メッセージ本文の最大サイズは 64 KB（128,000 文字）。超過分は配信されない
配信は 少なくとも1回（at-least-once）。順序保証や重複排除はしない（厳密順序が要るなら OCI Queue / Streaming を併用）
HTTPS / Functions など失敗しうる宛先には自動リトライがあり、リトライ枯渇後はメッセージが破棄される
トピック数・サブスクリプション数・publish レートはテナンシ/リージョン単位の **サービス制限（Limits）**で管理され、引き上げ申請が可能
リージョナルサービス。トピックは作成したリージョンに閉じる

内部の仕組み

トピックへ publish されたメッセージは、トピックに紐づく全サブスクリプションへプッシュされます。Email や SMS は OCI 側のゲートウェイから送出され、HTTPS はエンドポイントへ POST、Functions はその関数を非同期に呼び出し、OCI Queue 宛てならキューにメッセージが入ります。

宛先が一時的に失敗した場合は 指数バックオフでリトライされ、それでも届かなければメッセージは破棄されます（標準では DLQ を持たないため、確実な取りこぼし防止が要る場合は後述のパターンを使います）。Email / HTTPS / Slack などは確認済み（Confirmed）サブスクリプションにのみ配信され、未確認（Pending）には配信されません。

確実に処理したいなら Queue/Functions を挟む

Notifications 単体は at-least-once で DLQ を持ちません。取りこぼしを防ぎたいときは トピック → OCI Queue（または Functions） を挟み、可視性タイムアウト・リトライ・DLQ で受け止めるのが定石です。

設計パターン / ベストプラクティス

アラーム通知: Monitoring アラーム → Notifications トピック → Email / SMS / Slack / PagerDuty（最も一般的な用途）
イベント駆動のファンアウト: Events ルール → トピック → 複数サブスクリプション（関数で自動修復＋メールで人へ通知を同時に）
サーバーレス連携: トピック → ORACLE_FUNCTIONS で軽量処理、重い/確実な処理は → ORACLE_QUEUE で受けてワーカーが消費
トピックの分離: 重要度や宛先チーム単位でトピックを分け、IAM ポリシーとフィルタ性を確保する

運用・監視

Monitoring メトリクス（oci_notification 名前空間）で PublishMessageCount や配信系メトリクスを監視し、配信失敗を検知
サブスクリプションが Pending のままだと配信されない。Email/HTTPS/Slack は確認リンクの未クリックを疑う
HTTPS エンドポイントの 証明書・到達性・5xx 応答を確認。リトライ枯渇でメッセージが消える点に注意
すべての publish / 管理操作は **Audit（監査ログ）**に記録され、誰がいつトピックを変更・送信したか追跡できる

コスト

項目	課金の考え方	備考
メッセージ配信（Email/HTTPS/Functions/Queue 等）	毎月一定量まで無料、それを超えた配信数で従量課金	Always Free 枠あり（月100万配信が目安）
SMS 配信	1通あたり課金（国・地域で単価が異なる）	電話番号宛ては別単価で割高になりやすい
トピック作成・保持	トピック自体の保持料金はかからない	課金は基本「配信した数」で発生

セキュリティ

IAM ポリシーで ons-topics / ons-subscriptions への操作（作成・publish・購読）を最小権限に制御する
アラームや Events から publish させる場合は、サービスに必要な権限のみを 動的グループ＋ポリシーで付与する
メッセージは保存・転送ともに 暗号化され、HTTPS 宛ては TLS で送出される。機微情報を本文に直接載せない
すべての操作は Audit に残るため、不審な購読追加・送信を検知できる

アンチパターン

HTTPS サブスクリプションの URL を誰でも publish/購読できる権限で放置するのは NG。確認なしで届く先や過剰権限はスパム配信・情報漏洩の温床になります。IAM で publish 権限を絞り、宛先は確認済みのもののみに保つこと。

観点	OCI Notifications	Amazon SNS
位置づけ	OCI のマネージド Pub/Sub 通知	AWS のマネージド Pub/Sub 通知
配信単位	トピック → サブスクリプション	トピック → サブスクリプション
主な宛先	Email / SMS / HTTPS / Slack / PagerDuty / Functions / OCI Queue	Email / SMS / HTTP(S) / Lambda / SQS / モバイルプッシュ
メッセージ最大	64 KB	256 KB
順序保証	なし（at-least-once）	標準: なし / FIFO トピックで順序保証あり
フィルタ	サブスクリプション側は限定的（宛先で分離）	サブスクリプションフィルタポリシーあり
確実処理の併用先	OCI Queue / Functions	SQS（ファンアウト）/ Lambda

ハンズオン / CLI例

# トピックを作成（コンパートメントを指定）
oci ons topic create \
  --name "alerts-topic" \
  --compartment-id "$COMPARTMENT_OCID"

# 作成したトピックの OCID を控える
TOPIC_OCID=$(oci ons topic list --compartment-id "$COMPARTMENT_OCID" \
  --query "data[?name=='alerts-topic'].\"topic-id\" | [0]" --raw-output)

# Email サブスクリプションを登録（宛先に確認メールが届く → リンク承認で Confirmed に）
oci ons subscription create \
  --topic-id "$TOPIC_OCID" \
  --compartment-id "$COMPARTMENT_OCID" \
  --protocol "EMAIL" \
  --subscription-endpoint "oncall@example.com"

# トピックへメッセージを publish（全サブスクリプションへ配信）
oci ons message publish \
  --topic-id "$TOPIC_OCID" \
  --title "DB CPU High" \
  --body '{"alarm":"db-cpu","level":"critical"}'

# サブスクリプションの一覧と確認状態を確認
oci ons subscription list --compartment-id "$COMPARTMENT_OCID" \
  --query "data[].{Endpoint:endpoint, Protocol:protocol, State:\"lifecycle-state\"}" --output table