Cloud Service
メッセージング
OCI Queue / Notifications / Events / Streaming の使い分けを一枚で。疎結合・同報・ルーティング・ストリームの違いを即断。
ひと目で使い分け
| やりたいこと | 選ぶもの |
|---|---|
| バッファして1対1で確実に処理（ワーカー分配） | OCI Queue |
| 1メッセージを複数の宛先へ同報（ファンアウト・通知） | OCI Notifications |
| OCIリソースの状態変化で振り分け・自動連携 | OCI Events |
| 順序付き・再読み込み・高スループットのストリーム | OCI Streaming |
詳細比較
| 観点 | OCI Queue | OCI Notifications | OCI Events | OCI Streaming |
|---|---|---|---|---|
| モデル | キュー(1対1) | Pub/Sub(1対多) | イベントルール配信 | ストリーム |
| 配信方式 | プル(GetMessages) | プッシュ | プッシュ(ルーティング) | プル(オフセット読取) |
| 順序 | チャネル(channelId)で保証 | 保証なし | 保証なし | パーティション内で保証(キー) |
| 再読み込み | 不可(削除で消える) | 不可 | 不可 | 可(保持期間内・オフセット) |
| 配信保証 | at-least-once | at-least-once | at-least-once | at-least-once |
| 代表用途 | ワーカーへのバッファ/DLQ | アラーム通知/同報 | リソースイベント駆動 | ログ/IoTのリアルタイム |
| AWS対応 | SQS | SNS | EventBridge | Kinesis(Kafka互換) |
迷ったらこの順で考える
- 複数の宛先（メール/Slack/関数/Queue）へ同じものを配りたい → Notifications（確実に処理するなら Notifications → OCI Queue / Functions）
- 送信側と処理側を切り離してバッファし、確実に1件ずつ捌きたい → OCI Queue
- OCIリソースの状態変化（オブジェクト作成・DBバックアップ完了など）で振り分けて自動化 → Events
- 大量データをリアルタイムに・複数コンシューマで再生したい / Kafka資産を活かす → Streaming
- Queue＝疎結合キュー（プル・可視性タイムアウト・DLQ）。SQS 相当
- Notifications（ONS）＝トピックへの publish を全サブスクリプションへ同報。SNS 相当
- Events＝Oracle 定義のリソースイベントを CloudEvents 形式でルール配信。EventBridge 相当
- Streaming＝順序付き・再読み込み可能なストリーム（Kafka 互換 API）。Kinesis 相当
ファンアウトの作り方（OCI 流）
AWS の「SNS + 複数SQS」に相当するのが Notifications + OCI Queue です。Notifications 単体は at-least-once で DLQ を持たないため、取りこぼしを防ぎたい宛先は Queue で受けます。
| 要件 | 構成 | 勘所 |
|---|---|---|
| 同報だけでよい（通知） | Events/アラーム → Notifications → Email/Slack/PagerDuty | 最も一般的。人への通知に最適 |
| 確実なファンアウト＋後続処理 | Notifications → 複数の ORACLE_QUEUE / ORACLE_FUNCTIONS | Queue 側で可視性タイムアウト・DLQ・再試行を担保 |
| イベントを内容で振り分け | Events ルール(条件) → Functions / Notifications / Streaming | Events のアクションは3種に限定される |
OCI Events のターゲット（アクション）は Functions / Notifications / Streaming の3種類のみ。EventBridge のように Queue を直接ターゲットにはできないため、Queue へ渡したいときは Events → Notifications（ORACLE_QUEUE） か Events → Functions → Queue を挟みます。
Events が購読するのは Oracle が定義した OCI リソースイベント（CloudEvents）が中心で、EventBridge の PutEvents のように任意の独自アプリイベントを投入する仕組みではありません。アプリ固有のイベントを流すなら Streaming（Kafka 互換） か Queue を使います。
Queue と Streaming はどっち？（混同しやすい）
| 観点 | OCI Queue | OCI Streaming |
|---|---|---|
| 本質 | 取り出すと消える疎結合キュー | 順序付き・再読み込み可能なログ |
| 消費モデル | GetMessages → 処理 → DeleteMessages | オフセットを進めて読む(消えない) |
| 順序の単位 | チャネル(channelId) | パーティション(メッセージキー) |
| 並列消費 | 複数コンシューマで取り合い分配 | コンシューマグループで各自オフセット |
| 再処理 | 不可（削除で消失） | 可（保持期間内に巻き戻し） |
| 最大保持 | 7日 | 168時間(7日) |
| 向く用途 | タスク分配・ジョブワーカー | リアルタイム分析・イベント再生 |
| AWS対応 | SQS | Kinesis Data Streams |
OCI Queue / Notifications / Events / Streaming は いずれも at-least-once（最低1回）配信で、重複が起こりえます。コンシューマは冪等に作るのが鉄則。厳密な順序が要るなら Queue はチャネル、Streaming はメッセージキーで同一パーティションに寄せます。
関連サービスとの線引き
| 紛らわしいもの | 役割 | Events/Streaming との違い |
|---|---|---|
| Connector Hub (Service Connector) | ログ/メトリクス/イベント/ストリームを常時転送するパイプライン | Events=単発ルーティング。常時転送・配信は Connector Hub |
| Resource Scheduler | リソースの定期起動/停止(cron相当) | Events 自体に cron はない。定期実行は Resource Scheduler |
| Notifications | publish の単純同報(Pub/Sub) | Events=内容でルーティング。Notifications=同報のみ |
- Events に cron 機能を期待する → 定期実行は Resource Scheduler（EventBridge Scheduler 相当は分離）
- Notifications で確実処理を期待する → DLQ がないので Queue/Functions を挟む
- 大ペイロードをそのままキューへ → Queue/Notifications はサイズ上限あり。本体は Object Storage に置き参照(URI)だけ渡す
関連: OCI Queue / OCI Notifications / OCI Events / OCI Streaming
OCI Service
メッセージングを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cheatsheets
比較で見る軸
クラウド: OCI / カテゴリ: cheatsheets / 難易度: basic
導入後に効く点
導入後の運用手順、権限、監視、更新方法まで含めて評価します。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- OCI
- カテゴリ
- cheatsheets
- 難易度
- basic
- 関連資格
- —
- 設計柱
- —
判断チェックリスト
- 自社の用途が「cheatsheets」に近いか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。