疎結合の非同期処理

このパターンは？

重い処理や急増するリクエストを、直接同期呼び出しせずにいったん「間に箱を挟んで」捌く構成。OCI では Queue / Notifications / Events を組み合わせて疎結合を実現します。

• スパイクをバッファして取りこぼさない
• 失敗をリトライ／DLQで安全に退避
• 送信側（プロデューサ）と処理側（コンシューマ）を独立にスケール

構成

[フロント/Producer]
   │ イベント発生
   ▼
Notifications トピック (同報) ──► 複数サブスクリプション
   │                                 ├─ ORACLE_QUEUE ─► OCI Queue ─► ワーカー(Functions / Container Instances / OKE) ─► NoSQL / Object Storage
   │                                 └─ EMAIL / SLACK ─► 人へ通知
   │                                            │
   │                                            └─ 失敗(配信回数超過) ─► DLQ(退避)
   │
別解: Events ルール (リソースイベントを内容ベースでルーティング) ──► Functions / Notifications / Streaming

コンポーネントの役割と使い分け

• OCI Queue: バッファ。コンシューマが GetMessages でポーリングし、可視性タイムアウト＋DLQ（最大配信回数で移動）で確実に処理。channelId（チャネル）で関連メッセージの順序を担保
• OCI Notifications: 1メッセージを複数サブスクリプションへ同報（ファンアウト）。ORACLE_QUEUE / ORACLE_FUNCTIONS を宛先にできるのが要点
• OCI Events: OCI リソースの状態変化（CloudEvents 形式）を条件で振り分け、Functions / Notifications / Streaming へ流す
• ワーカー: Functions（短時間・サーバーレス）/ Container Instances・OKE（長時間・常駐）

設計の勘所

• 処理は冪等に（OCI Queue / Notifications / Events はいずれも at-least-once 配信＝重複し得る）
• 厳密な順序が要るなら、Queue のチャネル（channelId） か、Streaming のメッセージキー（同一キー＝同一パーティション） を使う
• ワーカーはキューの深さ（Monitoring の oci_queue 名前空間：可視メッセージ数 / InFlightMessages）でスケール。OKE なら Pod、Compute なら台数を増減
• 大きいペイロードは Object Storage に置き、メッセージにはオブジェクト参照（URI）だけを入れる（Queue の既定メッセージサイズは 128 KiB、Notifications は 64 KB）

Well-Architected の観点

• 信頼性: バッファ・可視性タイムアウト・DLQ で取りこぼさない
• パフォーマンス効率: 送信／処理を独立スケール、ロングポーリングで空ポーリングを削減
• コスト最適化: Functions は GB 秒の従量課金でアイドル時は無料、スパイクに過剰投資しない

よくある落とし穴

選び方の早見表

AWS との対応

AWS の同パターン（SQS / SNS / EventBridge）を OCI に置き換えると次の対応になります。