OCI Queue

解決する課題

物理的なメッセージブローカー（Kafka や RabbitMQ など）を自前で構築・運用せずに、疎結合な非同期連携をすぐに始められます。

• アクセス急増でバックエンドが詰まる → キューでバッファ
• 送信側（プロデューサ）と処理側（コンシューマ）を疎結合にして独立にスケールしたい
• 失敗したジョブを安全に退避・再試行したい（DLQ）
• 標準の HTTP/REST API で言語を問わず連携したい

主要概念と用語

• キュー（Queue）: メッセージを格納するエンドポイント。作成時にメッセージエンドポイントの FQDN が払い出される
• プロデューサ / コンシューマ: メッセージを送る側 / 取り出して処理する側
• PutMessages / GetMessages / DeleteMessages / UpdateMessages: メッセージの送信・取得・削除・可視性更新を行う REST 操作
• 可視性タイムアウト（Visibility timeout）: GetMessages で取り出したメッセージを一時的に他のコンシューマから隠す時間。既定 30 秒
• デッドレターキュー（DLQ）: 配信試行回数（delivery count）が上限を超えたメッセージの退避先
• チャネル（Channel）: キュー内の論理的なサブグループ。channelId を指定して送受信すると、特定チャネルのメッセージだけを順序付きで扱える（関連メッセージのグルーピングに利用）
• コンシューマグループ（複数コンシューマ）: 同一キューを複数のコンシューマで並列に GetMessages して水平にスケール

仕様・制限・クォータ

• メッセージ保持期間は 最大 7 日（既定値、キュー作成時に設定）
• メッセージ最大サイズは 既定 128 KiB（キュー単位で設定可能。大きいデータは Object Storage に置き参照を渡す）
• 可視性タイムアウトは既定 30 秒、最大 12 時間（43,200 秒）
• ロングポーリングは GetMessages の timeoutInSeconds で指定（最大 30 秒）
• プル型（コンシューマが GetMessages でポーリング）
• 順序保証はチャネル単位で行われる（チャネルを使わない場合は標準キュー同様、ベストエフォート）
• アクセスは REST API / OCI SDK / OCI CLI から。データプレーン操作はメッセージエンドポイント、管理操作（作成・削除）はコントロールプレーン

内部の仕組み

コンシューマがキューを GetMessages でポーリングしてメッセージを取得すると、可視性タイムアウトの間そのメッセージは他のコンシューマから見えなくなり、同時に各メッセージへ一時的な receipt（レシート） が払い出されます。処理が成功したら receipt を使って DeleteMessages で削除、処理が長引く場合は UpdateMessages で可視性タイムアウトを延長します。可視性タイムアウトが切れると再び見えるようになり、別のコンシューマに再配信されます。

メッセージごとに 配信回数（delivery count） がカウントされ、設定した上限（maximum delivery attempts）を超えると DLQ へ自動的に移動します。OCI Queue は at-least-once（最低1回）配信のため、同じメッセージが2回以上配信される可能性があり、コンシューマ側の冪等な処理が前提になります。

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

• Queue + Functions: メッセージ到着を OCI Functions（FaaS）で処理するワーカー（Connector Hub 連携やポーリングで起動）
• キューの深さでスケール: 滞留メッセージ数に応じてコンシューマ（OKE の Pod や Compute）の台数を増減
• DLQ で失敗を退避し、原因調査・再投入する
• 大きいペイロードは Object Storage に置き、キューにはオブジェクト参照（URI）だけを載せる
• ロングポーリング（timeoutInSeconds を長め）で空ポーリングのリクエストを減らす
• 関連イベントは チャネル でグルーピングし、エンティティ単位の順序を担保する

運用・監視

• OCI Monitoring のメトリクス名前空間 oci_queue を使用。主な指標は以下
  • Messages（可視メッセージ数）/ InFlightMessages（処理中のメッセージ数）
  • DeadLetterMessages（DLQ 滞留数）
  • GetMessages / PutMessages などの API 呼び出し数
• 滞留増 → コンシューマ不足やダウンストリーム障害を疑う
• DLQ に溜まる → 処理ロジック / 権限（IAM ポリシー）/ メッセージフォーマットを確認
• 操作監査は OCI Audit ログ、メトリクスのしきい値超過は Alarm で通知

コスト

リクエスト課金が中心です。空ポーリングを減らすほど安くなります。

セキュリティ

• IAM ポリシーでアクセス制御。manage queues（管理）と、データプレーン操作の use queues / read queues などを最小権限で付与する
• 通信は TLS（HTTPS） で暗号化。保存時はサービスによる暗号化に加え、カスタマー管理キー（OCI Vault の鍵） を指定可能
• メッセージエンドポイントへのアクセスはネットワークポリシー（プライベートアクセス）で制限する

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# キューを作成（コンパートメント指定。可視性タイムアウト等は作成後に設定可）
oci queue queue-admin create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name jobs

# 作成したキューのメッセージエンドポイントを確認
oci queue queue-admin get --queue-id "$QUEUE_OCID" \
  --query "data.\"messages-endpoint\"" --raw-output

# メッセージを送信（データプレーン: --endpoint にメッセージエンドポイントを指定）
oci queue messages put-messages \
  --endpoint "$MESSAGES_ENDPOINT" \
  --queue-id "$QUEUE_OCID" \
  --messages '[{"content":"{\"id\":\"job-1\"}"}]'

# メッセージを受信（ロングポーリング: timeout-in-seconds=20）
oci queue messages get-messages \
  --endpoint "$MESSAGES_ENDPOINT" \
  --queue-id "$QUEUE_OCID" \
  --visibility-in-seconds 30 \
  --timeout-in-seconds 20

# 処理完了後、レシートで削除
oci queue messages delete-message \
  --endpoint "$MESSAGES_ENDPOINT" \
  --queue-id "$QUEUE_OCID" \
  --message-receipt "$RECEIPT"