疎結合の非同期処理
送信側と処理側をキュー/通知/イベントで切り離し、急なスパイク吸収・リトライ・スケールを実現。OCI のマネージドサービスで組む疎結合・非同期処理の定番パターン。
中級信頼性パフォーマンス効率コスト最適化
このパターンは？
重い処理や急増するリクエストを、直接同期呼び出しせずにいったん「間に箱を挟んで」捌く構成。OCI では Queue / Notifications / Events を組み合わせて疎結合を実現します。
- スパイクをバッファして取りこぼさない
- 失敗をリトライ／DLQで安全に退避
- 送信側（プロデューサ）と処理側（コンシューマ）を独立にスケール
構成
横にスクロール
コンポーネントの役割と使い分け
- OCI Queue: バッファ。コンシューマが GetMessages でポーリングし、可視性タイムアウト＋DLQ（最大配信回数で移動）で確実に処理。
channelId（チャネル）で関連メッセージの順序を担保 - OCI Notifications: 1メッセージを複数サブスクリプションへ同報（ファンアウト）。
ORACLE_QUEUE/ORACLE_FUNCTIONSを宛先にできるのが要点 - OCI Events: OCI リソースの状態変化（CloudEvents 形式）を条件で振り分け、Functions / Notifications / Streaming へ流す
- ワーカー: Functions（短時間・サーバーレス）/ Container Instances・OKE（長時間・常駐）
Notifications → Queue ファンアウト
「複数システムに同報」かつ「各処理を確実に」なら Notifications トピック → 複数の OCI Queue。Notifications で配り、各 Queue がバッファ＆リトライ＆DLQを担います。Notifications 単体は at-least-once で DLQ を持たないため、確実に処理したい経路は必ず Queue（または Functions）で受け止めます。
設計の勘所
- 処理は冪等に（OCI Queue / Notifications / Events はいずれも at-least-once 配信＝重複し得る）
- 厳密な順序が要るなら、Queue のチャネル（channelId） か、Streaming のメッセージキー（同一キー＝同一パーティション） を使う
- ワーカーはキューの深さ（Monitoring の
oci_queue名前空間：可視メッセージ数 / InFlightMessages）でスケール。OKE なら Pod、Compute なら台数を増減 - 大きいペイロードは Object Storage に置き、メッセージにはオブジェクト参照（URI）だけを入れる（Queue / Notifications にはメッセージサイズの上限があるため。具体値は公式の Service Limits を参照）
Well-Architected の観点
- 信頼性: バッファ・可視性タイムアウト・DLQ で取りこぼさない
- パフォーマンス効率: 送信／処理を独立スケール、ロングポーリングで空ポーリングを削減
- コスト最適化: Functions は GB 秒の従量課金でアイドル時は無料、スパイクに過剰投資しない
よくある落とし穴
アンチパターン
- 同期呼び出しのまま重い処理を実行し、フロントがタイムアウト
- 冪等性を考えず、重複メッセージで二重課金/二重登録（at-least-once 前提を忘れる）
- Notifications だけで確実な処理を期待する（DLQ がなくリトライ枯渇でメッセージが消失）
- Queue の DLQ 未設定で、失敗メッセージが最大配信回数まで無限に再配信され続ける
選び方の早見表
| やりたいこと | 選ぶもの |
|---|---|
| バッファして1対1で確実に処理 | OCI Queue |
| 1メッセージを複数へ同報 | Notifications（＋複数 Queue） |
| OCIリソースの状態変化を内容で振り分け | Events |
| 順序付き・再読み込み・Kafka互換のストリーム処理 | Streaming |
AWS との対応
AWS の同パターン（SQS / SNS / EventBridge）を OCI に置き換えると次の対応になります。
| 役割 | OCI | AWS |
|---|---|---|
| バッファ用キュー（プル型） | OCI Queue | Amazon SQS |
| 同報（Pub/Sub ファンアウト） | Notifications | Amazon SNS |
| リソースイベントのルーティング | Events（CloudEvents） | Amazon EventBridge |
| サーバーレスのワーカー | Functions（Fn Project） | AWS Lambda |
| コンテナのワーカー | Container Instances / OKE | Fargate / ECS・EKS |
| 順序付きストリーム | Streaming（Kafka 互換） | Kinesis Data Streams |
| 大きいペイロードの退避先 | Object Storage | Amazon S3 |
OCI Pattern
疎結合の非同期処理を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
reliability
比較で見る軸
クラウド: OCI / 難易度: intermediate / 関連サービス: 7件
導入後に効く点
送信側と処理側をキュー/通知/イベントで切り離し、急なスパイク吸収・リトライ・スケールを実現。OCI のマネージドサービスで組む疎結合・非同期処理の定番パターン。
先に潰すリスク
パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。
数字・仕様の読み方
- クラウド
- OCI
- 難易度
- intermediate
- 関連サービス
- 7件
- 設計柱
- reliability / performance / cost
判断チェックリスト
- 自社の用途が「reliability / performance」に近いか確認する。
- 強みである「送信側と処理側をキュー/通知/イベントで切り離し、急なスパイク吸収・リトライ・スケールを実現。OCI のマネージドサービスで組む疎結合・非同期処理の定番パターン。」が本当に評価軸になるか確認する。
- 注意点の「パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
reliabilityperformancecostOCI QueueOCI NotificationsOCI EventsOCI FunctionsContainer Instances / OKE