OCHaCafe Premium メッセージングことはじめ

Transcript

1. メッセージング ことはじめ Oracle Cloud Hangout Café Premium Kyotaro Nonaka, Yuki Sogawa Solutions Architect Oracle Japan
2. アジェンダ 1. メッセージング 基礎 2. OCIで利用できるメッセージング基盤 1. OCI Streaming 2. OCI Streaming with Managed Kafka 3. OCI Queue 4. Oracle Transactional Event Queues 3. サービスの比較と選定 4. デモ 2 Copyright © 2025, Oracle and/or its affiliates.
3. 自己紹介 Yuki Sogawa / 曽川宥輝 3 Copyright © 2025, Oracle and/or its affiliates. @sogawa-yk • Cloud Native系製品担当 • Oracle Cloud Hangout Caféメンバー • 趣味: ツーリング、バンド活動 CoE本部 / ソリューションアーキテクト部
4. 自己紹介 Kyotaro Nonaka / 野中恭大郎 ソリューション・アーキテクト 日本オラクル株式会社 4 Copyright © 2025, Oracle and/or its affiliates @non_kyon • AppDev/Messaging/NoSQL/Frontend • Oracle Cloud Hangout Caféメンバー /Oracle Groundbreakers Advocate • 元ERPパッケージ開発者 • 趣味は釣りとかキャンプとか
5. メッセージング 基礎 5 Copyright © 2025, Oracle and/or its affiliates.
6. メッセージングとは？ 異なるシステムやアプリケーション間でデータを交換するための手法 6 Copyright © 2025, Oracle and/or its affiliates. メッセージング基盤を使わない場合 プロデューサ（送信側）とコンシューマ（受信側）が 直接通信する メッセージング基盤を使う場合 メッセージング基盤がプロデューサとコンシューマの間に入る プロデューサ コンシューマ プロデューサ メッセージング基盤 コンシューマ メッセージング基盤を使う利点 プロデューサとコンシューマを疎結合にし、非同期でデータをやり取りできるようになる
7. なぜ非同期メッセージングが必要なのか 同期通信の場合 • コンシューマの処理能力に合わせてプロデューサが待つ 必要がある • どこかのサービスが落ちると処理全体が失敗 • 一つのリクエストが次のリクエストを待つため、遅延が発 生 非同期通信の場合 • コンシューマの処理能力に合わせてメッセージを処理で きる • 一つのサービスがダウンしても被害が最小限 • すぐにレスポンスを返せるので遅延が少ない 7 Copyright © 2025, Oracle and/or its affiliates. プロデューサ コンシューマ コンシューマが処理できな いときは待つ必要がある プロデューサ メッセージング基盤 コンシューマ コンシューマに関係なく送り 付けることができる 処理能力に見合った速さ で取得できる
8. 一般的な非同期メッセージングモデル Point to Point プロデューサとコンシューマが１対１で通信するモデル 順番通りに一つずつ処理したい場合など Pub/Sub プロデューサとコンシューマが多対多で通信するモデル 状態の変化（イベント）などを複数のシステムに伝えたい 場合など 8 Copyright © 2025, Oracle and/or its affiliates. プロデューサ プロデューサ プロデューサ コンシューマ コンシューマ コンシューマ メッセージング基盤 メッセージング基盤
9. メッセージのデリバリー戦略 at-most-once デリバリー • メッセージ毎に、そのメッセージは0 回か1回配信される • メッセージは重複しない • メッセージが失われる可能性があ る at-least-once デリバリー • メッセージ毎に、少なくとも1回成 功するように潜在的に複数回配 信が行われる • メッセージの重複があり得る • メッセージの複製が失われない Exactly-once デリバリー • メッセージ毎に正確に1回の配信 が受信者に対して行われる • メッセージは重複しない • メッセージは失われたり複製された りしない 9 Copyright © 2025, Oracle and/or its affiliates.
10. OCIで利用できるメッセージング 基盤 10 Copyright © 2025, Oracle and/or its affiliates.
11. メッセージ基盤の分類 • Pub/Sub • at-least-once • パーティション単位でスケールアウト • 同一パーティション内での配信順 序保証 • メッセージの再利用が前提 Copyright © 2025, Oracle and/or its affiliates. 11 • Point to Point, Pub/Sub • Exactly-once • キューは同一インスタンスで動作 • 同一トランザクション内で配信順序 保証 • メッセージの再利用が可能・一度 だけのメッセージ処理が可能 • Point to Point • at-least-once • 自動でスケールアップ • 同一パーティション内での配信順 序保証 • 一度だけのメッセージ処理が前提 OCI Streaming Managed Kafka Oracle TxEventQ OCI Queue
12. OCIで利用できるメッセージングサービスの概要 • OCI Streaming • Pub/Subメッセージングモデルのメッセージ基盤 • システムログ収集など、不特定多数へのメッセージ配信に最適 • OCI Streaming with Managed Kafka (LA) • Pub/Subメッセージングモデルのメッセージ基盤 • マネージドサービスのKafka • OCI Streamingと近いユースケース • OCI Queue • Pub/Subモデル（実体的にはPoint to Point）のメッセージ基盤 • フロントサイトとバックエンドの接続など、特定多数へのメッセージ配信に最適 • Oracle Transactional Event Queues (TxEventQ) • Point to Point, Pub/Subの両方に対応する、Oracle Databaseに搭載されたメッセージ基盤 • より正確に（重複なく）配信したい場合 12 Copyright © 2025, Oracle and/or its affiliates.
13. OCI Streaming (Kafka) とOCI Queueの違い Streaming (Kafka) 目的: 不特定多数へのメッセージ配信 同じメッセージを複数の目的のコンシューマが利用 例）システムログ収集 OCI Queue 目的: 特定多数へのメッセージ配信 メッセージの処理目的は一つ 例）ECサイトの受発注処理 13 Copyright © 2025, Oracle and/or its affiliates. フロントサイト ORDER処理 アプリケーション システムログ Streaming リアルタイム処 理 バッチ処理 システムログ システムログ モニタリング・ アラート ログ分析・キャパシティ プランニング Queue ORDER処理 リクエスト ORDER処理 リクエスト
14. OCI Streaming 14 Copyright © 2025, Oracle and/or its affiliates.
15. OCI Streaming 特徴 • フルマネージドのPub/Subモデルメッセージングサービス • 複雑になりやすいサービス間やコンポーネント間の接続経路を、 Streamingを経由する形にすることでシンプルにすることが可能 • Streamingに接続するためのAPIやSDKを提供 • Kafka互換APIを提供 15 Copyright © 2025, Oracle and/or its affiliates. IoT Mobile/Web Activities App Kafka Client Streaming Events API Gateway Database System Object Storage Functions
16. OCI Streaming 基本的な処理の流れ ①プロデューサ(メッセージ送信クライアント)はメッセージを OCI Streaming に公開 ②コンシューマ(メッセージ受信クライアント)が OCI Streaming 上のメッセージを取得 （Pull型） ③コンシューマが取得したメッセージを処理 ※メッセージは一定期間保持されるため、再度取得して処理も可能 16 Copyright © 2025, Oracle and/or its affiliates. プロデューサ コンシューマ ① ② ③ OCI Streaming
17. OCI Streaming メッセージのデリバリ戦略 at-most-once デリバリー • メッセージ毎に、そのメッセージは0 回か1回配信される • メッセージは重複しない • メッセージが失われる可能性があ る at-least-once デリバリー • メッセージ毎に、少なくとも1回成 功するように潜在的に複数回配 信が行われる • メッセージの重複があり得る • メッセージの複製が失われない Exactly-once デリバリー • メッセージ毎に正確に1回の配信 が受信者に対して行われる • メッセージは重複しない • メッセージは失われたり複製された りしない 17 Copyright © 2025, Oracle and/or its affiliates.
18. OCI Streaming Streamingの概念 18 Copyright © 2025, Oracle and/or its affiliates. 概念 説明 Message Base64エンコードされたデータ（KeyとValueで構成） Stream Partitionで区切られた追加のみ可能なMessageストア Partition Streamの中の区切り Key Messageの識別子 Offset Partition内でのMessageの識別子 Stream Pool Streamをグループ化したもの 0 1 2 3 4 5 Partition0 0 1 2 3 4 Partition1 0 1 2 3 4 5 6 Partition2 Stream Messageの追加 (KeyによってPartitionに分配) Offset
19. OCI Streaming ProducerとConsumer 19 Copyright © 2025, Oracle and/or its affiliates. Producer Messageを書き込む役割 • 同じKeyのMessageは同一のPartitionに配信される • Keyを指定することで、Partition内での配信順序を保 持できる Consumer Messageを読み出す役割 • Messageが作成された順に、Messageを読み出す • Partitionが複数ある場合は、Messageの順序は保証 されない • どこまでMessageを読みだしたかはOffsetを用いて判断 0 1 2 0 1 0 Stream Producer A PutMessage API GetMessage API Producer B Producer C Consumer A Consumer B Consumer C Partition0 Partition1 Partition2 Key0 Value Key2 Value Key1 Value Key2 Value Key0 Value
20. OCI Streamingのユースケース ログやWebアクティビティデータの収集 • システムログやユーザーのアクティビティログをメッセージとして収集 • リアルタイム/バッチ処理などの必要なタイミングに応じて収集したメッセージを利用 • OCI Streamingにメッセージが保存されているので、必要なタイミングで再利用できる 20 Copyright © 2025, Oracle and/or its affiliates. アプリケーション アクティビティデー タ システムログ リアルタイム処 理 バッチ処理 アクティビティデー タ システムログ アクティビティデー タ システムログ モニタリング・ アラート UI反映・UX向上 のための機能 機械学習による 分 析・レコメンド ログ分析・キャパシティ プランニング Streaming Service Connector Hub Logging Logging
21. OCI Streaming with Managed Kafka 21 Copyright © 2025, Oracle and/or its affiliates.
22. OCI Streaming with Managed Kafka (LA) 特徴 • フルマネージドのApache Kafka • AD/FDにまたがる高可用性構成 • Apache Kafka APIとの100%互換性 • Kafka Streams • Admin APIs なども利用可能 • クラスタ管理でZookeeperとKraftが選択可能 • OCIサービスとの統合 • OCI Vaultを使って暗号化キーを安全に保存・管理 • OCI Monitoringを使ってメトリクスを取得 • OCI Loggingを使ってクラスタレベルのログを取得 22 Copyright © 2025, Oracle and/or its affiliates.
23. OCI Streaming with Managed Kafka OCI Streamingとの比較 23 Copyright © 2025, Oracle and/or its affiliates. 概念（Managed Kafka） 概念（OCI Streaming） 説明 Message Message Base64エンコードされたデータ （KeyとValueで構成） Topic Stream Partitionで区切られた追加のみ可 能なMessageストア Partition Partition Topic (Stream)の中の区切り Key Key Messageの識別子 Offset Offset Partition内でのMessageの識別子 0 1 2 3 4 5 Partition0 0 1 2 3 4 Partition1 0 1 2 3 4 5 6 Partition2 Topic Messageの追加 (KeyによってPartitionに分配) Offset
24. OCI Streaming with Managed Kafkaのユースケース IoTデータのリアルタイム処理 • IoT機器から流入する大量のデータを、Managed Kafkaが受け口となってキューイングする • トピックに書き込まれたメッセージをリアルタイムにデータを取得・処理して別トピックに書き戻す ※ Kafka StreamsアプリケーションはComputeなどにデプロイ 24 Copyright © 2025, Oracle and/or its affiliates. IoT Data 自動車やスマート家 電のセンサーからの データをStreaming に送信 Kafka workload メッセージとして データをトピックに入 れ、分散して保持 Kafka Streams アプリケーション トピックからリアルタ イムにデータを取 得・処理 別のトピックに結果 を格納 Autonomous Data Warehouse IoT Apps 分析モデルにより、 サジェストやアラー トなどの結果を返 す アプリがキューイ ングされたデー タを利用する Autonomous Data Warehouse Cloud Service
25. OCI Queue 25 Copyright © 2025, Oracle and/or its affiliates.
26. OCI Queue 特徴 • フルマネージドのメッセージングキューサービス • カーソル（オフセット）やパーティションの考慮不要で、メッセージの取り扱いが容易 • オートスケールも可能 • At least once配信なので、コンシューマーが消費したメッセージの削除を担保することでExactly onceに近づける • 配信順序はベストエフォート • チャネル機能 • 個々のメッセージを独立して処理する目的 26 Copyright © 2025, Oracle and/or its affiliates.
27. OCI Queue 基本的な処理の流れ ①プロデューサ(メッセージ送信クライアント)はメッセージを OCI Queue に公開 ②コンシューマ(メッセージ受信クライアント)が OCI Queue 上のメッセージを取得 ③コンシューマが取得したメッセージを処理 ④コンシューマがOCI Queueに対して処理したメッセージの削除をリクエスト 27 Copyright © 2025, Oracle and/or its affiliates. プロデューサ OCI Queue コンシューマ ① ② ④ ③
28. OCI Queue メッセージのデリバリ戦略 at-most-once デリバリー • メッセージ毎に、そのメッセージは0 回か1回配信される • メッセージは重複しない • メッセージが失われる可能性があ る at-least-once デリバリー • メッセージ毎に、少なくとも1回成 功するように潜在的に複数回配 信が行われる • メッセージの重複があり得る • メッセージの複製が失われない exactly-once デリバリー • メッセージ毎に正確に1回の配信 が受信者に対して行われる • メッセージは重複しない • メッセージは失われたり複製された りしない 28 Copyright © 2025, Oracle and/or its affiliates.
29. OCI Queueの機能 デッド・レター・キュー（DLQ） 正常に処理されていないメッセージを格納する方法として、デッド・レター・キューを提供 • メッセージがキューから取得されるたびに、メッセージの配信回数が増加 • メッセージの配信回数が設定値を超えると、メッセージはデッド・レター・キューに移動 • キューの設定値(最大配信試行回数)はキューの作成時または変更時に指定可能 デッド・レター・キューに転送されたメッセージが削除されるのは以下の2パターン • 設定した保存期間が過ぎ、サービスによって削除 • メッセージを処理後のコンシューマなどによって手動で削除 29 Copyright © 2025, Oracle and/or its affiliates.
30. OCI Queueの機能 チャネル 一時的なキュー内の宛先として機能する • プロデューサはメッセージを特定のチャネルに公開可能 • コンシューマはメッセージを取得するチャネルのフィルタリングが可能 • 複数のチャネルがフィルタリングされたときには、その複数のチャネルからランダムに選択されメッセージを取得(ランダム・チャネル) • チャネルのフィルタリングをしない場合はキュー・レベルでランダム・チャネルから取得 30 Copyright © 2025, Oracle and/or its affiliates.
31. OCI Queueの機能 チャネル機能のユースケース 31 Copyright © 2025, Oracle and/or its affiliates. メッセージ処理の公平性を担保する 複数のプロデューサが同じキューにメッセージを Publishする場合に、あるプロデューサ(P1)からの メッセージが突然急増すると、他のプロデューサから のメッセージのConsumeが大幅に遅延する チャネル機能を利用すると、キュー・レベルのランダ ム・チャネルからメッセージを取得できるため、メッセー ジ処理の偏りをなくし、公平性を高めることができる
32. OCI Queue チャネル機能のユースケース 一時キューとして利用（リクエスト/レスポンス・パターン） 本来Pub/Subモデルの非同期メッセージングでは、リクエストとレスポンスは切り離されたものになる • レスポンス先をリクエスト元に正確に返却するには、リクエスト元の特定が必要 • 一時キューとしてプロデューサごとにチャネルを持つことで、コンシューマはメッセージが格納されたチャネルをみてリクエスト 元を特定できる 32 Copyright © 2025, Oracle and/or its affiliates.
33. OCI Queue ユースケース フロントエンドとバックエンドの接続 33 Copyright © 2025, Oracle and/or its affiliates. フロントサイト ORDER処理 Queue ORDER処理 リクエスト ORDER処理 リクエスト フロントサイト Queue 処理リクエスト B サービスA サービスB サービスC 処理リクエストA 処理リクエストC
34. Oracle Transactional Event Queues 34 Copyright © 2025, Oracle and/or its affiliates.
35. Oracle Transactional Event Queues (TxEventQ) 特徴 Oracle Databaseに統合された堅牢で多機能なメッセージ・キューイング・システム • TxEventQへのエンキュー/デキュー、TxEventQと他のメッセージングシステム間のメッセージ伝播機能を提供 • イベントの発行/消費とデータベース上のデータ変更が１つのトランザクション内で完結 • 標準のデータベース機能（リカバリ、セキュリティなど）がサポートされる • あらゆる機能が自動化されたマネージドなサービス (Autonomous Database) • Okafkaライブラリを利用して、Kafka互換APIによる透過的なアクセスが可能 35 Copyright © 2025, Oracle and/or its affiliates. イベント/メッセージを送信する側のクライアント Producer Consumer エンキュー デキュー TxEventQ 伝播 伝播 TxEventQ TxEventQ
36. Oracle Transactional Event Queues (TxEventQ) 基本的な処理の流れ ①プロデューサ(メッセージ送信クライアント)はメッセージを TxEventQ に公開 ②TxEventQが、コンシューマに通知をPush ③コンシューマが取得した通知をもとにメッセージを取得 ④コンシューマが取得したメッセージを処理 36 Copyright © 2025, Oracle and/or its affiliates. プロデューサ コンシューマ ① ②、③ ④ TxEventQ
37. Oracle Transactional Event Queues (TxEventQ) メッセージのデリバリ戦略 at-most-once デリバリー • メッセージ毎に、そのメッセージは0 回か1回配信される • メッセージは重複しない • メッセージが失われる可能性があ る at-least-once デリバリー • メッセージ毎に、少なくとも1回成 功するように潜在的に複数回配 信が行われる • メッセージの重複があり得る • メッセージの複製が失われない exactly-once デリバリー • メッセージ毎に正確に1回の配信 が受信者に対して行われる • メッセージは重複しない • メッセージは失われたり複製された りしない 37 Copyright © 2025, Oracle and/or its affiliates.
38. Oracle Transactional Event Queues (TxEventQ) メリット TxEventQのメリット: 1. DMLとイベント処理を1つのデータベース・トランザクション内で実行できる 2. Exactly-Onceのイベント送信を保証 3. イベントドリブンなワークフローを簡単に作成できる－受信、処理、送信 38 Copyright © 2025, Oracle and/or its affiliates. Begin transaction T1 Write and Send Event A Commit Begin transaction T2 Receive Event A Process Send Event B Commit Oracle Database Transactional workflow イベントAはT1がコミットされた時にのみ送られる イベントAはT1がコミットされるまで受信しない
39. Oracle Transactional Event Queues (TxEventQ) イベントストリーム イベントストリーム（シャード）：論理的なキュー • 水平分割による高い同時実行性とスループットを実現する • イベントストリームは自動でパーティション化 • パーティションが分かれることで、ディスクが分かれる • 結果的にディスクI/Oのスケールが可能 39 Copyright © 2025, Oracle and/or its affiliates. キュー表 インスタンス Consumer ProducerA イベントストリーム1 パーティション1 パーティション2 パーティション3 キュー表 a1 a2 a3 a1 a2 a3
40. Oracle Transactional Event Queues (TxEventQ) メッセージ伝播 • メッセージは1つのキューから別のキューに伝播できる • アプリケーションは同じデータベース・キューに接続されていなくても相互に通信可 （宛先キューは同じデータベースでもリモート・データベースでも可能）➡ リモートでの処理のオフロード、バックアップ • 伝播により、多くの受信者にメッセージを展開可能、異なるキューのメッセージを1つのキューに結合することもできる • 送信順序を保持したまま受信可能 40 Copyright © 2025, Oracle and/or its affiliates. P 伝播 伝播 C 伝播 異なるキューのメッセージを1つのキューに伝播 P P C C 1つのキューから異なる複数の別のキューに伝播
41. Oracle Transactional Event Queues (TxEventQ) • Kafka APIアプリケーションとOracle APIアプリケー ションがメッセージの互換性を持つ • Kafka Java APIはOracle Databaseサーバーに接続し、メッ セージング・プラットフォームとしてTxEventQを使用可能 • KafkaをTxEventQに置き換えての使用が可能 • KafkaとTxEventQが相互にメッセージのやりとりでき るように • Kafka Java APIを使用することでKafkaからTxEventQへ、 TxEventQからKafkaへ相互にメッセージを送れるように 41 Copyright © 2025, Oracle and/or its affiliates. KafkaとOracle Databaseの互換性 KafkaのAPIを使用してTxEventQへのエンキュー・デキューが 可能に KafkaとTxEventQのメッセージのやり取りが透過的に Producer Consumer Producer Consumer Producer Consumer TEQ TEQ TEQ TEQ Producer Consumer API
42. Oracle Transactional Event Queues (TxEventQ) 代表的なユースケース 42 Copyright © 2025, Oracle and/or its affiliates. 金融取引 資金の移動など、メッセージの重複や損失が重大な問題を引き起こす場合 Begin transaction T1 資金移動イベントAを送信 Commit Begin transaction T2 Receive Event A 資金移動処理 資金移動完了イベントBを送信 Commit Oracle Database イベントBはT2がコミットされるまで送信しない 資金移動処理が重複して 処理されることがない
43. サービスの比較と選定 それぞれの使い分けを考える 43 Copyright © 2025, Oracle and/or its affiliates
44. 使い分けポイント 1. 必要なスループットを考える 2. メッセージの特性を整理する 3. デリバリ方式から考える 44 Copyright © 2025, Oracle and/or its affiliates
45. スループットの違い(OCI Streaming / OCI Queue) Queue • メッセージ: 128KB • ストレージ/キュー: 2GB Streaming • メッセージ: 1MB • ストレージ/Stream: 無制限(最大保持期間有り) 必要なスループットを考える Copyright © 2025, Oracle and/or its affiliates 45 Producer Consumer OCI Queue - 1000 APIリクエスト/秒 - 10MB イングレス/秒 - 512KB PutMessage/秒 or 20メッセージ /秒 - 1000 APIリクエスト/秒 - 10MB エグレス/秒 - ２MB GetMessage/ 秒 or 20メッセージ /秒 Streaming Producer - 無制限リクエスト数 - 1MB 書込み/秒/パー ティション - 5リクエスト/秒/ Consumer Group - 50 Consumer Group/Stream Consumer Group
46. メッセージの特性を整理する 扱うメッセージはどのような特性を持つかを整理することで、自ずと選択肢が絞られる • メッセージは、特定のコンポーネントに向けたものか？ • 個々のメッセージを、他のメッセージとは独立して処理する必要があるか？ • メッセージの処理中に、他のコンシューマに利用されることを許容するか？ • メッセージの処理は一度だけか？ • 「メッセージの再利用」は起こり得るか？ 46 Copyright © 2025, Oracle and/or its affiliates YESがあれば、Queueが選択肢として有力
47. 「メッセージの再利用」とは • Pub/Sub • at-least-once • パーティション単位でスケールアウト • 同一パーティション内での配信順 序保証 • メッセージの再利用が前提 Copyright © 2025, Oracle and/or its affiliates 47 • Point to Point, Pub/Sub • Exactly-once • キューは同一インスタンスで動作 • 同一トランザクション内で配信順序 保証 • メッセージの再利用が可能・一度 だけのメッセージ処理が可能 • Point to Point • at-least-once • 自動でスケールアップ • 同一パーティション内での配信順 序保証 • 一度だけのメッセージ処理が前提 OCI Streaming Managed Kafka Oracle TxEventQ OCI Queue
48. OCI Streaming (with Managed Kafka)のメッセージ取得 Offset, Cursor Offset : Partition内でのMessageの識別子 • Offsetを保存しておくことで、そのOffsetから読み出しを再開できる • 0, 1, 2, 4, 5, 7 のように、必ずしも密にはならず、「次のOffsetを算出して読み出しを再開」という処理は書けない Cursor : SDKを利用する際にStreamからMassageを読み出す際のポインタ • OCI Streamingのみの概念 • OffsetのポインターとなるCursorを、Partitionを指定してAPIリクエストで生成(実体は文字列) • 作成したCursorを利用して、PartitionからMessageを読み出し • Cursorは都度生成せず、Message取得時に取得できるNextCursorを利用する • Cursorは作成後5分経つと失効する • Kafkaの場合はこのCursorの概念はなく、OffsetをCommitすることでKafka側でどこまでMessageを読み出した かを管理 48 Copyright © 2025, Oracle and/or its affiliates 0 1 2 4 5 7 Partition Stream Offset Cursor
49. Cursorの詳細 • Cursorは5つの種類があり、作成時に対応するパラメータとともに指定 • TRIM_HORIZON: 全てのMessageを取得、パラメータ無し • AT_OFFSET: 特定のOffset以上のMessageを取得、パラメータはOffset • AFTER_OFFSET: 特定のOffsetより大きなMessageを取得、パラメータはOffset • AT_TIME: 指定した時間以降のMessageを取得、パラメータはTime • LATEST: Cursorの初回生成後に追加されたMessageを取得 • Cursor作成時の種類は、どのようにMessageを取得したいかで決める 49 Copyright © 2025, Oracle and/or its affiliates Offset - 0 Timestamp – 00:00 Offset - 1 Timestamp – 00:01 Offset - 2 Timestamp – 00:02 Offset - 3 Timestamp – 00:03 TRIM_HORIZON AT_OFFSET(1) AFTER_OFFSET(1) AT_TIME(00:03) ※Cursor 生成 Offset – 4 Timestamp – 00:04 LATEST
50. Consumer Groupの概要 • 複数のConsumerでグループを構成 • Group内のConsumerは、それぞれ単一のPartitionから読み出す • 同じGroup内の複数のConsumerが、同一のPartitionからMessageを読み出すことはできない • Groupが異なれば、同一のPartitionから複数回Messageを読み出す • Consumer Groupを利用する際はCommitの概念があり、Streaming側でMessageがどこまで読み出されたか を管理する 50 Copyright © 2025, Oracle and/or its affiliates Consumer 1 Consumer 2 Consumer 3 Grp. A 0 1 2 0 1 0 Stream Partition0 Partition1 Partition2 Consumer 4 Consumer 5 Consumer 6 Grp. B
51. StreamingやKafkaで対応しきれないケース 前述のようにStreamingやKafkaでは「どこまでメッセージを読み出したか」をコンシューマ側やStreaming/Kafka側で 管理ができる しかし、「メッセージが処理済みかどうか」はStreaming/Kafka側で管理できず、コンシューマ側での実装が必要になる 51 Copyright © 2025, Oracle and/or its affiliates 注文処理サービス Streaming 注文リクエスト Streamingを使って実装する場合、 取得したメッセージが他のコンシューマによって • 注文処理の途中かどうか • 注文処理が完了していないかどうか • 注文処理に失敗しているかどうか などは外部のデータストアなどでステータス管 理を行う必要がある リクエスト3 リクエスト2 リクエスト1 リクエスト1 リクエスト1 リクエスト2 リクエスト3
52. メッセージの状態 公開中 • メッセージは、1つ以上のプロデューサによってキューに公開 • 各プロデューサにて保存期間を指定 • 保存期間が指定されていない場合、メッセージはキュー(サービスの単位)で定義された保存期間に応じる 処理中 • 複数のコンシューマが1つのキューからメッセージを消費可能 • コンシューマ数はスケーリング可能 • メッセージは一度コンシューマに配信されると、表示タイムアウトに応じて他のコンシューマから見えなくなる 更新中 • メッセージの処理に予想よりも時間がかかる場合、コンシューマはメッセージの表示タイムアウトを延長可能 • 表示タイムアウトを延長すると、メッセージの削除権は維持され、他のコンシューマから見えない状態が続く 削除中 • コンシューマにメッセージが配信され処理された後は、別のコンシューマへの再配信を防ぐためにメッセージ削除が必要 OCI Queue Service の原則 Copyright © 2025, Oracle and/or its affiliates 52
53. 2つのタイムアウト ポーリング・タイムアウト • コンシューマがメッセージの取得を待機する時間 • タイムアウトが経過して消費可能なメッセージがない 場合、リクエストは空のレスポンスを返す • ポーリング・タイムアウトを増やすと、コンシューマが キューにメッセージをリクエストする回数が減る • デフォルトは30秒 表示タイムアウト(メッセージロック) • 他のコンシューマに表示されない期間 • コンシューマは、別のコンシューマが同じメッセージを取 得できないように、メッセージをロック可能 • キュー・レベル/メッセージの消費または更新時に指定 することが可能 OCI Queue Service の概念 Queue Consumer GetMessage リクエスト 指定(設定)した時間、Consumerがポーリン グ 消費可能な メッセージがあれば それを取得 Consumer タイムアウト時は 空のレスポンス を返却 Consumer Queue Consumer A GetMessage リクエスト 指定(設定)した時間、メッセージをロック メッセージロック 中はメッセージ が見えない Copyright © 2025, Oracle and/or its affiliates 53 Consumer B
54. メッセージ配信の仕組み (Put/Get/Update/Delete) Copyright © 2025, Oracle and/or its affiliates 54 1. Producerは、デフォルトのメッセージ保持時間でメッセージをキューに送信 Producerは、キュー サービスがメッセージを受信して保存したという確認を受け取る 2. Consumer A は、表示タイムアウト A 内に処理することになっているメッセージを受信 3. Consumer B は、利用可能な唯一のメッセージがConsumer A によって既に消費されているため、何も受信しない 4. Consumer A は表示タイムアウト A 内にメッセージを処理できなかったため、メッセージを更新して表示タイムアウトを延長 5. Consumer B は再度メッセージを受信しようとするが、利用可能な唯一のメッセージがConsumer A によって消費および拡張されたため、受信できない 6. 延長された表示タイムアウトが経過すると、メッセージが再び表示されるように 7. Consumer B は 3 回目のメッセージの受信を試みる Consumer B はメッセージを受信 これは、表示タイムアウト B 内に処理することになる 8. Consumer A はメッセージを受信しようとするが、Consumer B がメッセージを消費したため、何も受信しない。Consumer A は、メッセージの表示タイムアウトを延長したり、メッセー ジを削除したりすることができなくなる 9. Consumer B はメッセージを正常に処理し、キューからメッセージを削除しようとする。Consumer B は、メッセージが完全に削除されたという確認を受け取り、このメッセージは他の Consumerに配信されることはない
55. メッセージのデリバリ戦略 OCI上で選べるサービスを添えて at-most-once デリバリー • メッセージ毎に、そのメッセージは0 回か1回配信される • メッセージは重複しない • メッセージが失われる可能性がある at-least-once デリバリー • メッセージ毎に、少なくとも1回成 功するように潜在的に複数回配 信が行われる • メッセージの重複があり得る • メッセージの複製が失われない exactly-once デリバリー • メッセージ毎に正確に1回の配信 が受信者に対して行われる • メッセージは重複しない • メッセージは失われたり複製された りしない 55 Copyright © 2025, Oracle and/or its affiliates OCI Queue OCI Streaming OCI Streaming with Kafka Oracle TEQ (Autonomous DB)
56. デモ Managed Kafka - Getting Started 56 Copyright © 2025, Oracle and/or its affiliates
57. デモ TEQ with Okafka on Helidon MP 57 Copyright © 2025, Oracle and/or its affiliates
58. TEQ の Kafka互換APIを見てみよう ライブラリ TEQのKafka互換性は • okafka • kafka-clients • aqapi • ojdbc の組み合わせで実装 互換がないバージョンもあるので、 ライブラリ同士のバージョンに気 を付ける ex., • okafka 23.6.0.0 • kafka-clients 3.7.1 • aqapi 23.3.0.0 • ojdbc11 23.5.0.24.07 58 Copyright © 2025, Oracle and/or its affiliates
59. TEQ の Kafka互換APIを見てみよう ハマったポイント ライブラリ同士の互換性 • ドキュメントの図に2.8.0と書かれているが、実際には利用するOkafkaが依存するバージョンをMavenリポジトリなど で確認して利用する • 現時点で最新の okafka 23.6.0.0 を利用する場合は kafka-clients は 3.7.1 JEP-290対応(これはHelidonの話) • デシリアライズ可能なクラスを制限する機能 • メッセージのConsumeの際にデシリアライズが必要なので、必要なpackage名をMETA-INF/helidon/serial- config.properties に追加しておく必要がある • https://helidon.io/docs/v4/mp/security/jep-290 59 Copyright © 2025, Oracle and/or its affiliates
60. ご清聴ありがとうございました！ 60 Copyright © 2025, Oracle and/or its affiliates