OCI Queue+Kafka実践Vol1 SQS/MSK対比の三択メッセージング選定

1. この記事について — OCIのメッセージング基盤をどう選ぶか

OCIには、メッセージングとストリーミングを担うサービスが3つ存在します。キューイングを担うOCI Queue、Kafka互換APIを持つ従来型のOCI Streaming(以下、classic Streaming)、そして2025年にGAしたフルマネージドKafkaクラスターサービスのStreaming with Apache Kafka(以下、Kafka版)です。AWSでいえば、それぞれAmazon SQS・Amazon Kinesis Data Streams・Amazon MSKに近い役割を持ちますが、3つのうちどれを選ぶべきかは、名前だけでは判断できません。

本記事は、「OCI Queue + Streaming with Apache Kafka実践」シリーズの第1弾として、この三択を整理したうえで、QueueとKafka版の2サービスを実際に動かすところまでを扱います。classic Streamingについては、比較・位置づけの整理にとどめ、実機での構築はQueue・Kafka版の2本に絞ります。

1-1. 本記事のゴール

本記事は、OCIのメッセージング領域における3つのサービスを、単体の機能紹介ではなく「どれを選ぶべきか」という設計判断として整理することをゴールにしています。読み終えた時点で、次の状態になっていることを目指します。

• OCI Queue・classic Streaming・Kafka版の3つについて、用途・課金モデル・互換性の違いを説明でき、案件に応じて選択できる
• OCI Queueの無料枠(月100万リクエスト・64KB単位)を理解し、無料枠内でキュー作成からDLQ・チャネル・長ポーリングまでを実践できる
• Kafka版の最小構成クラスターを作成し、SASL-SCRAM認証での接続からトピックのproduce/consumeまでを一通り実践できる
• OCI EventsやEvent Hub Classicといった名前の似た(あるいはかつて存在した)サービスと、本記事が扱うQueue/Streaming系サービスを混同せずに整理できる

OCI Queueは2022年12月にGAしたキューイングサービス、Kafka版は2025年8月にGAしたばかりの新しいフルマネージドKafkaサービスです。両者は提供開始時期が3年近く離れているにもかかわらず、「OCIでSQSやMSK相当のサービスを探している」という同じ検索意図から辿り着く読者が多いため、本記事では1本の記事の中でまとめて扱い、使い分けの判断材料を提供します。

具体的な典型ユースケースとしては、次のようなケースを想定しています。

• マイクロサービス間の非同期処理をキューで疎結合にしたいが、OCIでSQS相当のサービスがあるのか分からない
• Kafkaベースのイベント駆動基盤をOCI上に構築したいが、自前でKafkaクラスターを運用管理する負荷は避けたい
• 既存のclassic Streamingを使っているが、Kafka版との違いや移行の要否を整理したい
• AWSのSQS/MSKでの実務経験があり、OCI版の仕様差・料金差を正確に押さえたうえで移行検討したい

これらのユースケースに共通するのは、「OCIのメッセージング基盤は3つあるが、どれがSQS相当でどれがMSK相当なのか、公式ドキュメントを読むだけでは整理しづらい」という悩みです。本記事の§3では、この三択を1枚の決定表に落とし込みます。

この三択を正しく理解しておくことは、単なる知識の整理にとどまりません。誤った選択をすると、後から移行コストが発生する場面もあります。たとえば、当初classic Streamingで小さく始めたワークロードが、Kafka生態系のツール(Kafka Connect・スキーマレジストリ等)への依存を強めていった結果、後になってKafka版への移行が必要になるケースは十分に想定されます。逆に、単純なタスクキューの用途にKafka版を選んでしまうと、ブローカー管理という不要な運用負荷を抱え込むことになります。本記事は、この判断を最初の設計段階で正しく行えるよう、料金・仕様・互換性の3軸から三択を整理します。

1-2. 読者像

本記事は、AWSでAmazon SQSやAmazon MSKを使った実務経験があり、OCIでの対応サービスを正確に把握したいエンジニアを主な読者として想定しています。具体的には、マルチクラウド戦略の一環でOCI上にもメッセージング基盤を持ちたいと考えているエンジニア、あるいはOCI案件でメッセージング/ストリーミング基盤の選定を任されたインフラ/クラウドエンジニアなどです。

特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCIでSQS相当のサービスを使いたい場合、Queueとclassic Streamingのどちらを見ればよいのか
• OCIでMSK相当のフルマネージドKafkaを使いたい場合、Kafka版はいつGAして、今どのバージョンに対応しているのか
• OCI QueueはAlways Free枠の対象なのか、それとも別枠の無料階層があるのか
• Kafka版のクラスターは、最小構成でどの程度の料金で試せるのか
• 「Event Hub」という名前をOCIの文脈で見かけたが、これは本記事のStreaming系サービスと関係があるのか

こうした読者は、多くの場合「AWSで動かしている非同期処理・イベント駆動基盤を、そのままOCIに置き換えられるか試したい」という動機で本記事にたどり着きます。本記事は、起動手順だけでなく、SQS/MSKとの仕様対比や料金試算にも重点を置いて解説します。

一方で、OCIでのメッセージング基盤構築が初めてという読者にも配慮し、各サービスの基本概念(キュー・パーティション・可視性タイムアウト・ブローカー等)は、専門用語として前置きなく使うのではなく、必要な箇所でSQS/MSKの対応概念と紐付けながら説明します。すでにOCI Queueの基本操作に慣れており、Kafka版との違いだけを知りたい読者は、§2-2以降やハンズオン(§5)から読み始めても支障がない構成にしています。

なお、本記事は「OCI Functions & API Gatewayサーバーレス実践 Vol1」で、OCI EventsというCloudEvents準拠のイベント通知サービスを扱い済みです。本記事が扱うOCI Queue・Kafka版・classic Streamingは、いずれもメッセージ本体をやり取りするデータプレーンのサービスであり、リソースの状態変化を検知して通知するOCI Eventsとは目的が異なります。両者を同じ「イベント駆動」という括りで混同しないよう、§1-3で改めて整理します。

これらの前提を満たしていない場合でも、各章で必要な範囲は都度補足します。OCIそのものが初めての方は、まず「OCI入門」シリーズのVol1(テナンシ・コンパートメント・Always Free枠)から着手することをお勧めします。すでにOCI Queueやclassic Streamingを使っており、Kafka版との違いだけを知りたいという読者は、§3の三択決定表から読み始めても内容を把握できる構成にしています。

1-3. なぜ今これを書くか

本記事を今書く理由は、大きく3つあります。

1つ目は、OCI Queue・classic Streaming・Kafka版という3つのメッセージング系サービスを横断して比較し、「いつどれを選ぶか」を体系的に整理した日本語記事が、現時点でほぼ見当たらないことです。個々のサービスの単体紹介や移行ガイドは存在しますが、SQS/MSK実務者が知りたい仕様逐項対比・料金試算・三択の使い分けまでを1本でまとめた記事は空白のままです。

2つ目は、名称混同の解消です。以前公開した「OCI Functions & API Gatewayサーバーレス実践 Vol1」では、OCI Eventsサービスと、Oracle PaaS時代のKafka互換メッセージングサービスであった「Event Hub Cloud Service」(通称Event Hub Classic)との混同に注意するよう予告していました。Event Hub Classicは2023年5月31日にEOL(サービス終了)となっており、その後継はOCI Streamingです。本記事は、この「Event Hub Classicの後継系譜」を実際に引き継ぐ記事として、classic StreamingとKafka版がどう位置づけられるのかを§3で整理し、前作の予告を回収します。

3つ目は、鮮度です。Kafka版は2025年8月27日にGAしたばかりで、GAから1年に満たない戦略サービスです。この時点で日本語の実践記事はほぼ存在せず、対応バージョンや最小構成クラスターの料金といった基本情報すら、体系的にまとまった一次情報が少ない状態です。本記事は、公式ドキュメントを直接確認したうえで、この空白を埋めることを目指しています。

本記事は、次の構成で進みます。§2ではOCI Queue・classic Streaming・Kafka版それぞれの料金体系とGA履歴を整理します。§3では三択の使い分け決定表とEvent Hub Classicからの系譜を整理します。続く§4ではOCI Queueのハンズオン(無料枠内で完結)を扱います。§5ではKafka版クラスターのハンズオン(最小構成での作成から接続確認まで)を扱います。§6では、落とし穴チェックリストとしてまとめます。

1-4. 本記事の対象外

本記事は、あくまで「Vol1」として、3サービスの使い分け判断・OCI Queueの無料枠内ハンズオン・Kafka版の最小構成クラスターでの接続確認までをスコープとしています。次のようなテーマは本記事のスコープ外とし、続編での取り扱いを検討します。

• MirrorMaker 2を使ったKafka版のクロスリージョンDR(ディザスタリカバリ)構成
• mTLS認証を使った、SASL-SCRAM以外の接続方式の詳細設定
• 本番運用を想定した3ブローカー以上のHA Cluster設計とキャパシティプランニング
• Kafka ConnectやOCI GoldenGateなど、周辺エコシステムとの統合パターン

これらのテーマは、いずれも本記事で扱う最小構成クラスターでの基本操作が前提となるため、まず本記事でKafka版の基礎を固めたうえで取り組むことをお勧めします。本記事があえてクロスリージョンDRや本番HA Cluster設計まで踏み込まないのは、これらを扱う前に、まずKafka版という基盤そのものの料金感覚と、classic Streaming・OCI Queueとの使い分け判断を確実に押さえておくべきだと考えているためです。

それでは、次の§2で3サービスの料金体系を正確に押さえたうえで、§3で三択の使い分けに進みます。

2. サービス仕様と料金

本章では、OCI Queue・classic Streaming・Kafka版という3サービスの料金体系を、公式一次情報に基づいて整理します。特にKafka版はGAから1年未満のサービスであるため、対応バージョンや最小構成の料金について、第三者情報ではなく公式ドキュメントを直接確認した内容のみを記載します。

2-1. OCI Queueの料金体系 — 無料枠とメッセージサイズ

OCI Queueには、月次で次の無料階層があります。1リクエストは64KB単位で換算され、これより大きいメッセージは複数リクエストとしてカウントされます。

この無料階層は、Always Free(永年無料)のリソース一覧とは別枠です。OCI QueueはAlways Free対象サービスの一覧そのものには含まれていませんが、料金体系の内部に月100万リクエストまでの無料階層が組み込まれており、実質的にAlways Freeテナンシでも(課金設定を有効化していない状態でも)一定規模のハンズオンを完結できる仕組みになっています。この点は§4-1で改めて扱います。

メッセージサイズの上限は、2024年1月25日のリリースで128KBから256KBに拡大されています。本記事執筆時点の上限は256KBです。

無料枠を超えた場合の月額費用感を掴むために、リクエスト数別の概算費用を整理すると、次のようになります。

この試算からも分かる通り、OCI Queueはリクエスト単価そのものが低く設定されているため、無料枠を超過した後も、よほど大規模なワークロードでない限り、月額費用は小さく収まる傾向があります。本記事のハンズオン(§4)のような検証規模であれば、無料枠を超えること自体がまず考えにくい水準です。

2-2. Kafka版の料金体系 — OCPU課金とクラスター最小構成

Kafka版は、Always Free対象外のサービスです。課金は「①サービス料」と「②インフラ実費(パススルー)」の2階建て構造になっています。①はクラスターに割り当てたブローカーのOCPU数に応じて発生するKafka版自体の利用料、②は選択したブローカーシェイプのCompute単価とBlock Volume使用量が実費でパススルー課金される分です。

Kafka版のクラスターには、用途に応じて2種類の構成があります。

ブローカーに割り当てるOCPU数は1〜80の範囲で選択でき、メモリはシェイプに応じて自動的に比例配分されます(Arm系は1 OCPUあたり6GB、x86系は1 OCPUあたり8GB)。本記事では最小構成としてA1.Flex 2 OCPU(メモリは6GB/OCPUの自動配分で12GB)・Block Storage 200GBを採用します。本記事の§5では、この構成に沿ってStarter Cluster(1ブローカー)を作成します。

利用できるブローカーシェイプは、Arm(Ampere)ベースのVM.Standard.A1.Flexに加え、x86系ではVM.Standard.E6.Flex・VM.Standard.E5.Flex・VM.Standard3.Flex・VM.Standard.x86.Genericが選択可能です。いずれもOCPU数とメモリ量を個別に指定できる可変シェイプであり、A1.Flexが低いOCPU単価に設定されている分、コストを抑えたい検証用途ではArm系が有力な選択肢になります。

たとえば、Starter Clusterを1ブローカー・A1.Flex 4 OCPUで構成した場合、メモリは4 OCPU×6GB=24GBが自動的に割り当てられます。OCPU数を増やすほどメモリも比例して増える仕組みのため、メモリ量だけを個別に指定できません。処理性能の見積もりが必要な場合は、OCPU数を基準にメモリ量を逆算する形で構成を検討してください。

なお、この試算はOCPUに応じたサービス利用料のみを対象としています。ブローカーに割り当てるBlock Storageの正確な単価は本記事執筆時点で一次情報から確認できておらず、憶測での記載を避けるため試算には含めていません。実際のクラスター作成時は、OCIコンソールの費用見積もり画面で、Block Storage分を含めた総額を確認してください。

2-3. classic Streamingとの料金対比

classic Streamingは、Kafka版とは異なる従量課金モデルを採用しています。

classic Streamingは、Kafka版のようなブローカー単位のOCPU課金ではなく、データ転送量とストレージ保持量に応じた従量課金です。小規模なメッセージ量であれば、Kafka版よりも低コストで運用できる場面がある一方、Kafka互換性は部分的にとどまり、パーティション数にもテナンシ既定の上限(Universal Credits契約:200・PAYG:50、申請により引き上げ可)があります。この違いは§3-2で詳しく扱います。

2-4. SQS/MSKとの仕様対比

AWSでの実務経験がある読者向けに、Queue/Kafka版の主な仕様をSQS/MSKと対比します。本節では料金を扱わず、機能・制約面での対比に絞ります。

OCI Queueの保持期間(10秒〜7日)は、SQSの最大保持期間(14日)よりも短い点に注意が必要です。長期間のメッセージ保持が必要なワークロードでは、この上限を事前に確認しておく必要があります。可視性タイムアウトの範囲・デフォルト値はSQSとほぼ同等です。

2-5. 料金試算 — ハンズオンでいくらかかるか

§4・§5で行うハンズオンを想定した料金試算です。

OCI Queueは、無料枠(月100万リクエスト)の範囲内で完結するため、本記事のハンズオン(キュー作成・メッセージのput/get・DLQ確認・チャネル確認)にかかる追加費用は発生しません。

Kafka版は、Starter Cluster・1ブローカー・A1.Flex 2 OCPUの構成で2時間ほど検証した場合、①サービス料は次の計算になります。

OCPU: $0.05 × 2 OCPU × 2時間 = $0.20

上記の$0.20は①サービス料のみです。実際には②インフラ実費として、A1のCompute実費(約$0.01/OCPU/hr)とメモリ実費(約$0.0015/GB/hr)、およびBlock Volume実費が別途パススルー課金されますが、いずれにしても数時間の検証であれば少額で完結する規模です。OCIの新規登録者向けトライアルクレジットの範囲内でも、余裕を持って本記事のハンズオンを完了できます。

参考までに、本記事のスコープ外である本番向けHA Cluster(3ブローカー・A1.Flex 4 OCPU/ブローカー)を1ヶ月(730時間)常時稼働させた場合の①サービス料のみの概算費用は、次の通りです。

OCPU: $0.05 × (3ブローカー × 4 OCPU) × 730時間 = 約 $438

この金額は①サービス料のみであり、A1のCompute実費・メモリ実費・Block Storageやネットワーク転送量などの②インフラ実費は含まれていません。検証用のStarter Cluster(数時間・数十円規模)と、本番運用を想定したHA Cluster(月額数百ドル規模)とでは、コストの桁が大きく異なる点を、構成を決める段階で認識しておくことが重要です。

2-6. GA履歴

OCI Queueは2022年12月14日にGA(一般提供開始)しました。その後、2023年9月6日にチャネル機能、2024年1月25日に最大メッセージサイズの256KBへの拡大、2024年2月27日にConnector Hubのソース対応が追加されており、機能拡張が継続的に行われています。直近でも、2025年9月17日にOracle Cloud Console側の管理画面が刷新され、2026年2月2日には複数のConsumer Groupsへメッセージをファンアウトする機能が追加されるなど、GAから3年以上が経過した現在も継続的にアップデートが行われているサービスです。

Kafka版は2025年8月27日にGAしたサービスです。対応するApache Kafkaバージョンは、GA時点の3.6.0・3.6.1・3.7.0に加えて、2026年4月20日に3.9.1、2026年6月12日に4.0.0が追加されています。Apache Kafka 4.0.0以降は調整モードがKRaftのみとなり、それ以前のバージョンで使われていたZooKeeperベースの調整モードはサポートされません。クラスター作成時には、利用するApache Kafkaバージョンを明示的に指定する必要があります。

classic Streamingについては、GA日付の再確認は本記事のスコープ外としていますが、公式ドキュメント上は現役サービスとして扱われており、廃止やメンテナンスモードへの移行を示すアナウンスは確認できていません。詳細な位置づけは§3-2で扱います。

2-7. 料金情報の一次情報源

本章で示した料金・仕様は、いずれも次の一次情報源を確認したうえで記載しています。

料金・対応バージョンは、クラウドサービスの中でも改定頻度が高い情報です。特にKafka版はGAから1年未満で仕様変動のリスクがあるため、本記事に記載した数値は執筆時点で確認した値であり、実際に利用する際はOCIコンソールの費用見積もり画面、または公式ドキュメントの最新情報を確認することをお勧めします。

第三者のブログ記事やまとめサイトに記載された料金情報は、取得時期や前提条件の古さゆえに、そのまま引用すると読者に誤った印象を与えるおそれがあります。特にKafka版は本記事執筆時点でGAから1年に満たない新しいサービスであるため、日本語の第三者情報がそもそも少なく、英語の公式ドキュメントを直接確認する以外に正確な情報を得る手段が限られています。本記事では、確認が取れなかった項目(Block Storageの正確な単価等)について、推測で数値を補うのではなく、「公式情報から確認できていない」という事実を明示する立場を取っています。

続く§3では、この3サービスをどう使い分けるかを整理します。

3. 三択の使い分け — Queue vs Kafka版 vs classic Streaming

本章では、OCI Queue・classic Streaming・Kafka版の3つを同じ軸で比較し、「いつどれを選ぶか」を整理します。あわせて、この3サービスの系譜の起点にあたるEvent Hub Classicについても、既刊記事の予告を回収する形で整理します。

3-1. 三択決定表

まず、3つのサービスを「メッセージモデル」「Kafka互換性」「課金モデル」「典型的な用途」という4つの観点で比較します。

この表からわかる通り、3つのサービスは似た文脈で語られることがあっても、実体はまったく異なります。OCI Queueは「順序制御と可視性タイムアウトを持つキュー」であり、classic StreamingとKafka版は「パーティション型ログ」という点で共通しますが、Kafka互換性の度合い・パーティション数の上限・レイテンシで明確に差があります。

3-2. Event Hub Classicからの系譜整理

「OCI Functions & API Gatewayサーバーレス実践 Vol1」の§5-4・§8-4では、OCI Eventsサービスと「Event Hub Cloud Service」(通称Event Hub Classic)との名称混同に注意するよう述べていました。その記事で整理した事実を、本記事の文脈で改めて引用します。

この事実を踏まえると、本記事が扱う3サービスの系譜は、次のように整理できます。Event Hub Classicが2023年5月31日にEOLとなり、その役割はOCI Streaming(classic Streaming)に引き継がれました。classic Streamingは現役のサービスとして提供が続く一方、2025年8月27日にはKafka互換性を100%まで高めたKafka版がGAし、Kafka互換ワークロードの新しい選択肢として登場しています。

→ OCI Functions & API Gatewayサーバーレス実践 Vol1: イベント駆動E2Eと正確な料金比較(Event Hub混同注意の元記事)

classic StreamingとKafka版は、いずれも現役サービスとして並行提供されています。公式ドキュメントには「When to Use OCI Streaming with Apache Kafka Vs OCI Streaming」という使い分け比較表が存在し、Kafka版は分散データ保存・CDC(変更データキャプチャ)・ストリーム分析・IoT処理といった、Kafka生態系のツールをそのまま活用したい用途に、classic Streamingはアプリ間の軽量なメッセージバスとしての用途に、それぞれ適していると位置づけられています。この比較表の範囲を超えて、classic Streamingの将来的な廃止を断定する記述は、本記事では行いません。

3-3. いつどれを選ぶか

3つの選択肢のいずれかを選ぶ際の判断フローを整理すると、次のようになります。

Q1. Kafka APIやKafka生態系のツール(Kafka Connect・MirrorMaker等)を
 そのまま使いたいか?
 └─ YES → Kafka版が第一候補(100%互換)
 └─ NO  → Q2へ

Q2. パーティション型のストリーミングログではなく、
 順序制御・可視性タイムアウトを持つキューが必要か?
 └─ YES → OCI Queueが第一候補
 └─ NO  → Q3へ

Q3. 軽量なアプリ間メッセージバスとして使いたく、
 Kafka互換性は必須ではないか?
 └─ YES → classic Streamingが選択肢になる
 (ただしKafka版への移行余地も検討することを推奨)
 └─ NO  → 用途を再整理し、Q1に戻って再検討

このフローが示す通り、Kafka互換のツールチェーンを活用したい場合はKafka版、タスクキューとしての用途であればOCI Queue、軽量なストリーミングバスであればclassic Streamingが、それぞれ第一候補になります。既にclassic Streamingを運用中で、Kafka生態系との連携を今後強化したい場合は、Kafka版への移行を検討する価値があります。

それでは、次の§4で実際にOCI Queueを無料枠内で動かすハンズオンに進みます。

4. Queueハンズオン — 無料枠内で完結

本章では、OCI Queueのキュー作成から、メッセージのput/get、可視性タイムアウトの確認、DLQ、チャネル、長ポーリングまでを、月100万リクエストの無料枠内で実践します。

4-1. 前提・準備

OCI Queueのハンズオンは、§2-1で整理した無料階層の範囲内で完結します。Always Freeテナンシ(課金設定を有効化していない状態)であっても、Queueの無料階層は料金体系に組み込まれた別枠のため、本章のハンズオンで追加課金が発生することはありません。ただし、これはOCI Queueというサービス単体の無料階層であり、他のAlways Free対象外サービスと組み合わせて使う場合は、それぞれの課金条件を個別に確認してください。

キューを作成するコンパートメントを決め、OCI CLIの認証設定が完了していることを確認しておきます。

4-2. キュー作成

キューは、OCIコンソールの「開発者サービス」→「キュー」から作成するか、OCI CLIで作成します。

oci queue admin queue create \
  --compartment-id <コンパートメントOCID> \
  --display-name oci-queue-kafka-vol1-queue \
  --visibility-timeout-in-seconds 30 \
  --message-retention-in-seconds 86400

visibility-timeout-in-secondsはメッセージ取得後に他のコンシューマーから見えなくなる時間、message-retention-in-secondsはメッセージがキューに保持される期間です。保持期間は10秒〜7日の範囲で指定でき、作成後の変更はできないため、用途に応じた値を作成前に検討しておく必要があります。本記事では、動作確認用に1日(86400秒)を指定しています。

4-3. メッセージのput/get

キューがACTIVE状態になったら、メッセージを送信(put)します。

oci queue messages put-messages \
  --queue-id <キューOCID> \
  --endpoint <キューのメッセージエンドポイント> \
  --messages '{"messages": [{"content": "hello from oci queue vol1"}]}'

続けて、メッセージを取得(get)します。

oci queue messages get-messages \
  --queue-id <キューOCID> \
  --endpoint <キューのメッセージエンドポイント> \
  --visibility-in-seconds 30

取得したメッセージにはreceipt(受信確認用のトークン)が含まれており、正常に処理できた場合はこのreceiptを使ってメッセージを削除します。削除しない限り、可視性タイムアウトの経過後にメッセージは再び他のコンシューマーから取得可能な状態に戻ります。

oci queue messages delete-message \
  --queue-id <キューOCID> \
  --endpoint <キューのメッセージエンドポイント> \
  --message-receipt <取得したreceipt>

4-4. 可視性タイムアウトの動作確認

可視性タイムアウトは1秒〜12時間の範囲で指定でき、デフォルトは30秒です。SQSのデフォルト値と同じ水準のため、SQS経験者であれば違和感なく設定できます。

動作確認として、get-messagesで取得した直後に(削除せず)再度get-messagesを実行すると、可視性タイムアウトが経過するまで同じメッセージは返らないことを確認できます。タイムアウト経過後に再度実行すると、削除されていないメッセージが再び取得可能になっていることが分かります。この挙動は、コンシューマー側の処理が失敗した際に、メッセージが失われずに再配信される仕組みの基盤になっています。

4-5. DLQ(Dead Letter Queue)の設定

同じメッセージが繰り返し処理に失敗する場合、そのメッセージを退避させる先としてDLQを設定できます。DLQ自体もOCI Queueの通常のキューとして作成し、送信元のキューにmax-delivery-attempts(最大配信試行回数)を指定して紐付けます。

oci queue admin queue update \
  --queue-id <キューOCID> \
  --dead-letter-queue-config '{"deadLetterQueueId": "<DLQ用キューOCID>", "maxDeliveryAttempts": 5}'

配信試行回数(取得されるたびに増加するカウント)がmaxDeliveryAttemptsを超えると、そのメッセージは自動的にDLQへ移動します。DLQに溜まったメッセージは、保持期間の満了で自動削除される前に、原因調査のために手動で確認・消費できます。

4-6. チャネルの活用

チャネルは、1つのキュー内に自動的に作成・削除される一時的な宛先です。プロデューサーがメッセージ送信時にチャネルIDを指定することで、特定のコンシューマーグループ向けにメッセージを振り分けたり、リクエスト-レスポンス的なやり取りを1つのキューの中で完結させたりできます。

oci queue messages put-messages \
  --queue-id <キューOCID> \
  --endpoint <キューのメッセージエンドポイント> \
  --channel-id producer-a \
  --messages '{"messages": [{"content": "message for channel producer-a"}]}'

コンシューマー側がチャネルIDを指定してget-messagesを呼び出すと、そのチャネルのメッセージのみを取得できます。チャネルIDを指定しなければ、利用可能なチャネルからランダムにメッセージが返されます。SQS経験者にとって、チャネルは個別のキューを大量に作らず宛先を増やせる仕組みとして理解すると分かりやすいポイントです。

4-7. 長ポーリング

メッセージが届くまでクライアント側でリクエストを繰り返す代わりに、サーバー側で一定時間メッセージの到着を待ってから応答する長ポーリングも利用できます。頻繁な空振りリクエストを減らせるため、無料枠のリクエスト数消費を抑える観点でも有効です。

続く§5では、Kafka版クラスターを最小構成で作成し、接続確認まで行います。

5. Kafkaクラスターハンズオン — 最小構成で作成から接続まで

本章では、Kafka版のクラスターを、§2-2で整理した最小構成の目安(Starter Cluster・1ブローカー・A1.Flex 2 OCPU)で作成し、SASL-SCRAM認証での接続からトピックのproduce/consume確認、そして削除による課金停止までを実践します。

5-1. 前提・準備

Kafka版はAlways Free対象外のため、課金が発生する前提でクレジットカード等の支払い情報を登録済みのテナンシが必要です。§2-5で試算した通り、数時間の検証であれば少額(OCPU分のみで約$0.20)で完結する規模ですが、Block Storage分の費用が別途発生する点は事前に認識しておいてください。

5-2. Starter Clusterの作成

OCIコンソールの「開発者サービス」→「Streaming with Apache Kafka」から、新規クラスターを作成します。作成時に指定する主な項目は次の通りです。

作成後、クラスターがACTIVE状態になるまでには一定の待機時間が発生します。クラスターページの「クラスター情報」セクションから、接続に必要なKAFKA_BOOTSTRAP_SERVERSの値を控えておきます。

5-3. SASL-SCRAM接続

Kafka版へのSASL-SCRAM認証は、クラスター作成時に発行されるスーパーユーザーの認証情報(OCI Vaultのシークレットとして保管)を使います。クライアント側のclient.propertiesは次のように設定します。

security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="<Vaultシークレットのユーザー名>" password="<Vaultシークレットのパスワード>";

bootstrap.serversには、§5-2で控えたKAFKA_BOOTSTRAP_SERVERSのSASL/SCRAMエンドポイントを指定します。認証情報はOCI Vaultに保管されるため、クライアント側にパスワードを平文で保存し続けないよう、シークレット管理の仕組みと組み合わせて運用することを推奨します。

5-4. トピック作成とproduce/consume確認

接続設定ができたら、標準のKafka CLIツール(kafka-topics.sh等)を使ってトピックを作成します。

kafka-topics.sh --create \
  --bootstrap-server <KAFKA_BOOTSTRAP_SERVERS> \
  --command-config client.properties \
  --topic oci-kafka-vol1-topic \
  --partitions 3 \
  --replication-factor 1

Starter Clusterはレプリケーション係数1がデフォルトのため、単一ブローカー構成に合わせて--replication-factor 1を指定しています。本番運用を想定したHA Clusterでは、レプリケーション係数3が標準です。

トピック作成後、標準のproducer/consumer CLIで動作確認を行います。

kafka-console-producer.sh \
  --bootstrap-server <KAFKA_BOOTSTRAP_SERVERS> \
  --producer.config client.properties \
  --topic oci-kafka-vol1-topic

kafka-console-consumer.sh \
  --bootstrap-server <KAFKA_BOOTSTRAP_SERVERS> \
  --consumer.config client.properties \
  --topic oci-kafka-vol1-topic \
  --from-beginning

producer側で入力した文字列が、consumer側にそのまま表示されれば、接続からproduce/consumeまでの一連の動作確認は完了です。Kafka版はKafka APIと100%互換のため、標準のKafka CLIツールやクライアントライブラリをそのまま利用でき、OCI固有のSDKへの書き換えは不要です。

5-5. MSK経験者向け対比コメント

MSKのクラスター運用経験がある読者にとって、Kafka版は次の点を似た感覚で扱えます。

5-6. 削除による課金停止

検証が完了したら、クラスターを削除します。Kafka版は、Container Instancesのような「停止すれば課金が止まる」仕様ではなく、クラスターが存在する限りOCPU分の課金が継続します。検証後に放置すると、意図せず課金が積み上がる原因になるため、動作確認が終わったら速やかに削除することを強く推奨します。

oci kafka cluster delete --cluster-id <クラスターOCID>

なお、MirrorMaker 2を使ったクロスリージョンDR構成、mTLS認証、本番向けの3ブローカーHA Cluster設計といった、より踏み込んだ内容は、本記事のスコープ外とし、将来のVol2候補として温存しています。

6. まとめ・落とし穴チェックリスト

本記事では、OCI Queue・classic Streaming・Kafka版という3つのメッセージング系サービスについて、料金体系・三択の使い分け・Queueハンズオン・Kafka版ハンズオンという順に整理してきました。最後に、実際に採用・運用する際に必ず確認しておきたい4つのポイントをチェックリストとしてまとめます。

3つのサービスは、名前だけを見ると似た文脈で語られがちですが、実体は「キュー(Queue)」「部分的Kafka互換のストリーミング(classic Streaming)」「100%Kafka互換のフルマネージドクラスター(Kafka版)」というまったく異なる性質を持っています。SQS/MSK実務者であれば、§3の三択決定表を判断の出発点として、案件の要件に応じた使い分けを検討してください。

次回の「OCI Queue + Streaming with Apache Kafka実践」シリーズでは、本記事で扱いきれなかった、Kafka版のMirrorMaker 2によるクロスリージョンDR構成や、mTLS認証、本番向けHA Cluster設計について扱う予定です。

本記事のQueue・classic Streamingは、Connector Hubのソースとしても指定できます(§2-6参照)。Connector HubをターゲットのLogging/Monitoring連携まで含めて深掘りしたい場合は、可観測性実践Vol1もあわせて参照してください。また、OCI上でのメッセージング基盤・データ基盤・アプリ実行基盤を横断して整備したい場合は、Data Science実践・PostgreSQL実践・Container Instances実践もあわせてご覧ください。

→ OCI可観測性・運用監視実践Vol1(Connector Hubのソース/ターゲット構成)を読む

→ OCI Data Science実践(ノートブックからモデルデプロイまでMLOps E2E)を読む

→ OCI Database with PostgreSQL実践Vol1(RDS/Aurora対比・Warm Standby DR)を読む

→ OCI Container Instances実践Vol1(サーバーレスコンテナという第3の実行基盤)を読む