本記事は 2026 年 5 月 28 日 に公開された「 Introducing the next generation of Amazon OpenSearch Serverless for building your agentic AI applications 」を翻訳したものです。 本日、AI エージェントを構築するお客様向けに設計されたフルマネージドの検索およびベクトルエンジン、次世代 Amazon OpenSearch Serverless を発表します。次世代 OpenSearch Serverless は、コンピューティングリソースをゼロから 1 秒あたり数千リクエストを処理できる規模までスケールアップし、アイドル時にはゼロまでスケールダウンします。ピーク時の容量に合わせてプロビジョニングした OpenSearch Service クラスターと比べて、最大 60% のコストを削減できます。 次世代 OpenSearch Serverless は数秒でリソースを作成し、容量のスケールアップは前世代の最大 20 倍高速です。即時のリソース作成と、 Vercel や Kiro といった AI 開発プラットフォームとのネイティブ統合により、AI エージェント向けの本番環境対応の検索およびベクトルバックエンドを、インフラを管理せずに数分でデプロイできます。 次世代 OpenSearch Serverless の使い方 次世代 OpenSearch Serverless を使い始めるには、 Amazon OpenSearch Service コンソール の Serverless メニューで Create collection を選択します。 瞬時にオートスケーリングし、コスト最適化のためゼロまでスケールダウンする NextGen コレクションを作成します。リリース時点では、コレクションタイプとして全文検索とベクトル検索のみをサポートしています。既存の OpenSearch Serverless インフラを使う場合は、 Switch to Classic を選択してください。 コレクションを最速で作成するには、 Express create を選択します。設定は不要で、デフォルト設定と一致するセキュリティポリシーが自動で適用されます。一部の設定項目は後から変更できます。 Create collection を選択すると、OpenSearch Serverless は数秒でリソースをプロビジョニングします。 AWS Command Line Interface (AWS CLI) や AWS SDK でも OpenSearch Serverless のコレクションを作成できます。コレクショングループを作成する CLI コマンドの例を示します。 aws opensearchserverless create-collection-group \ --name channy-nextgen-group \ --standby-replicas ENABLED \ --generation NEXTGEN \ --description "My NextGen collection group" \ --capacity-limits '{ "maxIndexingCapacityInOCU": 10, "maxSearchCapacityInOCU": 10, "minIndexingCapacityInOCU": 0, "minSearchCapacityInOCU": 0 }' \ --region "us-east-1" 続いて、親のコレクショングループから世代を継承するコレクションを作成できます。サポートされるコレクションタイプは SEARCH と VECTORSEARCH です。 aws opensearchserverless create-collection \ --name channy-nextgen-collection \ --type SEARCH \ --collection-group-name channy-nextgen-group \ --standby-replicas ENABLED \ --description "My collection in NextGen group" \ --region "us-east-1" 次世代 OpenSearch Serverless の管理について詳しくは、 Amazon OpenSearch Serverless のドキュメント をご覧ください。 OpenSearch Serverless でエージェント開発を加速する Vercel での本番環境対応エージェントアプリケーションの構築をサポートするため、Vercel コンソール内で新しい OpenSearch コレクションを作成したり、既存の OpenSearch Serverless コレクションに接続したりできるようになりました。検索バックエンドを数秒で作成し、アプリケーションの成長に合わせてオンデマンドで機能を追加できます。詳しくは、 AWS for Vercel をご覧ください。 Claude Code、Cursor、Kiro を使えば、アイデアから動作するプロトタイプまで数分で到達できます。 OpenSearch Agent Skills は、OpenSearch のインテリジェンスをエージェントに直接組み込むスキルのリポジトリです。各スキルには特定のワークフローのドメイン知識、ベストプラクティス、複数ステップの実行ロジックがカプセル化されています。そのためエージェントは、結果を得るだけでなく、その結果に至った過程まで理解できます。 Kiro Powers の OpenSearch Launchpad を使えば、ガイド付きでエンドツーエンドにアーキテクチャを設計し、検索アプリケーションを高速に開発できます。 提供開始 次世代 Amazon OpenSearch Serverless は本日より一般提供を開始し、Amazon OpenSearch Serverless が現在利用可能なすべての AWS 商用リージョンで利用できます。 次世代 OpenSearch Serverless では、インデックス作成、検索、 GPU アクセラレーション に使用する OpenSearch Compute Unit (OCU) ベースのコンピューティングに対して課金されます。ストレージは GB 月単位で別途課金されます。詳しくは、 Amazon OpenSearch Service の料金 をご覧ください。 ぜひお試しいただき、 AWS re:Post for Amazon OpenSearch Service または通常の AWS Support 窓口からフィードバックをお寄せください。 — Channy 著者について Channy Yun (윤석찬) Channy は AWS News Blog のリードブロガーであり、AWS Cloud のプリンシパルデベロッパーアドボケイトです。オープンウェブの愛好家でブロガーでもあり、コミュニティ主導の学習と技術の共有を大切にしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

BUYMAのPersonal Shopper API（PS-API）が、gRPC、SQS、Webhook、非同期処理を活用して、マイクロサービスとモノリスをつなぎながらスケールする仕組みを紹介します。 こんにちは、エニグモのフェルナンドです。 SELLチームに所属し、出品者向け機能の開発を担当しています。 今回は、私たちのチームで運用している「PS-API」についてご紹介します。 日々増え続けるリクエストをどのように処理しているのか、そのアーキテクチャの裏側についてお話ししたいと思います。 👉 English version is also available below. BUYMAでは、パーソナルショッパー（出品者）が商品を出品する方法がいくつかあります。 マイページ から直接商品を登録する方法もあれば、 CSVインポート を使って一括登録する方法もあります。 さらに、自社システムを運用している大規模なパートナーや事業者向けには、 Personal Shopper API（通称：PS-API） を利用した連携手段も提供しています。 運用要件によっては、より深いカスタム連携を行うケースもあります。 これらの機能を利用する出品者が増えるにつれて、PS関連システムの保守・改善は、楽しくもあり、同時にとてもチャレンジングなものになっていきました。 出品方法の概要：My Page、CSVインポート、PS-API、カスタム連携 今回は、 PS-API について紹介します。PS-APIがどのように動いているのか、なぜ非同期APIとして設計したのか、そしてマイクロサービスと大規模なモノリスをつなぐシステムを運用する中で学んだリアルな教訓について共有します。 PS-APIの目的：BUYMAのコアプラットフォームへの連携レイヤー BUYMAはマーケットプレイスであり、商品登録は出品者にとって重要な日常業務のひとつです。 大量の商品を管理している出品者にとって、1件ずつ手動で商品を登録するのはとても大きな負担になります。 CSVインポートでその負担を減らすことができますが、在庫・価格・商品情報を自社システムで管理しているパートナーにとっては、API連携が自然な選択肢になります。 そこで登場するのがPS-APIです。 PS-APIでは、出品者が以下のような操作を行えます。 商品の登録・更新 在庫やバリエーションの管理 注文情報の取得 発送依頼の処理 PS-APIは、出品者側のシステムとBUYMAのコアプラットフォームをつなぐ、強固な連携レイヤーとして機能しています。 PS-APIは、出品者システムとBUYMAのコアプラットフォームをつなぐ連携レイヤー 課題：マイクロサービスと既存モノリスの連携 BUYMAの主要な業務処理の多くは、現在もメイン環境、つまり巨大なモノリシックなシステム上で動いています。 一方で、PS-APIはモダンなマイクロサービスとして実装されています。 私は以前にサーバーレス開発の経験はありましたが、大規模なマイクロサービスアーキテクチャに本格的に関わるのはこれが初めてでした。 キュー、ワーカー、リトライ、サービス間通信、Webhook配信といった分散システムの世界に入っていくのは、本当に、とても勉強になりました。 PS-APIとBUYMAメインシステムのアーキテクチャ概要 ※ アーキテクチャは、おおまかに言うとこのような構成になっています。 ここで重要な設計思想は次の点です。 PS-APIは最終的な処理先ではない 外部システムとBUYMAのモノリスをつなぐ「オーケストレーションレイヤー」である なぜ非同期処理なのか PS-APIにおける最大の設計判断のひとつが、多くの処理を非同期にしたことです。 出品者が商品登録リクエストを送信した場合、システムはすべての処理を同期的に実行して、最終結果を即時で返すわけではありません。 代わりに、次のような流れをたどります。 リクエストを受け付ける 処理用のキューに積む（即時レスポンス） BUYMA側で後続処理を行う（ワーカーによる非同期処理） 最終結果をWebhookで返す この方式には、決定的なメリットがあります。 1. トラフィックスパイクの吸収 出品者は、ときどき大量のリクエストを一斉に送信します。 ここで言う「大量」とは、監視ダッシュボードが悲鳴を上げるレベルの量です。 非同期キューを使うことで、急激なトラフィック増加をそのままコアシステムに流し込むのではなく、一度バッファとして受け止めることができます。 リクエストは順番を待ち、システムが耐えられる制御されたペースで処理されます。 最終的な商品登録処理がBUYMAのメインシステムに依存しているため、このバッファリング層は非常に重要な役割を担っています。 非同期キューにより、外部からの大量リクエストを一度バッファリングする 2. 障害時のグレースフル・デグラデーション（確実なリカバリー） 下流システムが一時的に利用できない場合でも、出品者が同じリクエストを手動で再送する必要はありません。 リクエストは安全にキューに残り、下流システムが復旧したあとに自動で処理を再開できます。 ユーザーに「成功するまで何度もリトライしてください」とお願いするより、はるかに健全です。 アプリへの信頼を完全に失ってしまう前、システム側で吸収できることは吸収すべきです。 3. コアプラットフォームの保護 商品登録や注文関連の主要な処理は、BUYMAのモノリシックなメイン環境で実行されています。 そのため、このコアシステムを過負荷から慎重に保護する必要があります。 PS-APIが外部トラフィックを受け止め、モノリス側へリクエストを渡すペース（スループット）を制御します。 これは、マイクロサービスの柔軟性と、モノリスの安定性を両立するための設計です。 gRPCとSQS：通信方式の適材適所 PS-APIでは、すべての通信を同じ方法で扱っているわけではありません。 処理の性質、つまり即時性が必要か、耐久性が必要かに応じて、gRPCとAmazon SQSを明確に使い分けています。 gRPC gRPCは主に、即時のレスポンスが必要な内部サービス間通信で利用しています。 これは、PS-APIが現在の処理を続行する前に、信頼できる内部レスポンスを必要とするケースです。 たとえば、以下のような用途で使っています。 パートナーシステムとLive PS-API間の通信 パートナーシステムとSandbox PS-API間の通信 ブランド情報やカテゴリ情報などのマスターデータ取得 SQS 一方で、より重い業務処理にはSQSベースの非同期処理を利用しています。 たとえば、BUYMAのメインシステムと連携する以下のような処理です。 商品登録・更新 注文の発送依頼処理 なぜこの設計がうまく機能するのか gRPCとSQSを組み合わせることで、それぞれの通信方式を多様な場面で使うことができます。 gRPCは、高速な内部リクエスト・レスポンス通信に、SQSは、耐久性のある非同期業務処理に使います。 特徴 gRPC SQS（非同期キュー） 主な用途 内部サービス間の直接通信 重い業務処理、モノリス連携 処理モデル 同期的（即時レスポンス待ち） 非同期的（Event-Driven） メリット 高速、型安全（Protobuf）、明確な契約 耐久性、リトライ容易、スパイク吸収 具体例 マスターデータ（ブランド/カテゴリ）取得 商品の登録・更新、発送依頼処理 SQSとWebhookによる非同期ループの完成 重い処理はSQSを利用します。リクエストを受け付けると、ペイロードを保存し、その後の業務処理をワーカーが非同期で進めます。 重要なのは、SQSは「処理の完了イベント」にも利用されている点です。 商品登録が完了すると、その結果がキュー経由でPS-APIに返され、そこから出品者へWebhookレスポンスが送信されます。 Webhookは単なるAPIの即時レスポンスではなく、非同期処理の最終通知なのです。 gRPC、SQS、WebhookによるPS-APIの通信フロー この区別には、いくつかのメリットがあります。 BUYMAのメインシステムを急激なトラフィック増加から保護できる 多くの出品者が同時に商品更新リクエストを送った場合でも、リクエストをキューに積み、段階的に処理できます。 信頼性が向上する 下流システムの一部が一時的に利用できない場合でも、リクエストが消えてしまうことはなく、出品者がすべてを手動で再試行する必要もありません。 スケールしやすい基盤になる APIリクエストの受付、キュー処理、Webhook配信をそれぞれ個別に改善できます。 本当の課題：スケール PS-APIは当初、小規模なユースケースを想定して設計されていたため、現在のトラフィック規模にはそぐわなくなっています。 サービスの普及に伴い、APIを利用する出品者数とリクエスト数が急増しました。このスケールアップに伴い、スケーラビリティや運用面でいくつかの課題が表面化してきました。 レートリミット キューのボトルネック 処理状況の可視性 「リクエストは成功したのに、商品はどこにありますか？」という問い合わせ この最後の質問に対する答えは、時々こうなります。 “技術的には……まだキューのどこかにあります。” または、 “Webhookはエラーメッセージ付きで送信されました。” 非同期システムの運用は、設計するよりもずっと面白くなってくるのがこのあたりです。 APIを作ること自体ももちろん大変です。 しかし、リクエストが今どの処理段階にあるのかを、関係者全員が理解できるようにすることは、また別の難しさがあります。 そして多くの場合、後者の方が難しいです。 非同期システムに潜む複雑さ 外から見ると、APIリクエストはとてもシンプルに見えます。 POST /api/v1/products.json しかし内部では、実際には以下のような複雑なパイプラインが走っています。 API → バリデーション → データベース → キュー → ワーカー → ストレージ → 画像ダウンロード → 後続処理（または「下流プロセッサ」） → 完了イベント → キャッシュ無効化 → Webhook配信 APIは、単なるエンドポイントというより、空港の手荷物管理システムのようになっていきます。 システムは信頼されている。でも、リクエストが今どこにあるのかを完全に把握するのは難しい――そんな世界です。 オンプレミスからAWSへの移行 出品処理におけるデータベースのトランザクション速度を改善するうえで、大きな転機となったのがインフラのAWS移行とDBアップグレードです。AWSのリソースを活用することで、DB接続の安定性や処理性能が向上し、インポート速度も改善されました。 もちろん、AWSへ移行したりDBをアップグレードしたりしたからといって、すべてのボトルネックが簡単に消えるわけではありません。それでも、DB接続の安定性やトランザクション処理速度の改善は、非同期処理全体のパフォーマンスに大きく影響します。 今後も改善していくこと：本当の「スケール」に向けて PS-APIはもともと少数のユーザーを想定して作られていましたが、その想定も今は昔です。 現在も、出品者が安心して運用を任せられる強固な基盤を目指し、以下の領域を継続的に改善しています。 より良いレートリミット戦略の実装 リクエスト状態の可視性向上 画像ダウンロード処理の高速化とワーカーのオートスケーリング 技術的な専門知識がない出品者でも、スムーズに連携を開始できるようPS-APIドキュメントを拡充 モノリスとマイクロサービスをまたぐ運用の改善 私たちの目標は、単に大量のリクエストを「受け付ける」ことではありません。 数千件規模のスパイクにも安定して対応し、出品者のビジネスを裏から確実に支える、真に信頼できるAPIシステムへ進化させ続けることです。 注記: 本記事内の画像は、内容をわかりやすく表現するためにAIで生成したイメージ画像です。 Building for Scale: Inside the Event-Driven Architecture of the BUYMA Personal Shopper API Good day, I’m Fernand from Enigmo. I’m part of the SELL team, where I work on developing features that support sellers. This time, I’d like to talk about “PS-API,” a system operated by our team. I’ll share some insights into the architecture behind it and how we handle the continuously growing number of requests every day. At BUYMA, personal shoppers have several ways to list products on the platform. Some sellers manage listings directly from My Page . Others use CSV import for bulk operations. For larger partners and businesses that operate their own systems, we also provide integration options through the Personal Shopper API , or PS-API. In some cases, we even support deeper custom integrations depending on the seller’s operational needs. As more sellers began using these features, maintaining and improving the PS systems became both fun and challenging. Listing options: My Page, CSV import, PS-API, and custom integrations This time, I would like to introduce PS-API : how it works, why we designed it as an asynchronous API, and what we learned from operating a system that connects a microservice with a large monolithic platform. Purpose of PS-API BUYMA is a marketplace where product registration is one of the most important daily operations for sellers. For sellers managing large catalogs, manually listing products one by one quickly becomes painful. CSV import helps, but for partners that already manage inventory, pricing, and stock through their own systems, API integration becomes the natural next step. That is where PS-API comes in. It allows sellers to: create and update products manage stock and variants receive order information handle shipment requests PS-API acts as an integration layer between personal shoppers’ systems and BUYMA’s core platform. PS-API connects seller systems with BUYMA’s core platform The Challenge: When a Microservice Meets a Monolith Most of BUYMA’s core business processes still run in the main environment, which is a monolithic system. PS-API, however, was implemented as a microservice. Although I had experience with serverless development before, this was my first time working on a microservice architecture. Moving into a world of queues, workers, retries, internal service communication, and webhook delivery was very educational. Very educational... ※ The architecture looks something like this. High-level architecture of PS-API and BUYMA’s main system The key point here is: PS-API is not the final destination. It is the orchestration layer between external personal shopper systems and BUYMA’s platform. Why Asynchronous Processing One of the biggest design decisions in PS-API was to make many operations asynchronous. When a seller sends a product registration request, the system does not process everything synchronously and immediately return the final result. Instead: The request is accepted. It is queued for processing. BUYMA processes it downstream. The final result is sent back via webhook. This approach gives us several important advantages. 1. Handling Traffic Spikes Sellers sometimes send bulk requests. And by “bulk,” I mean enough requests to make the monitoring dashboard emotionally unavailable. With asynchronous queues, sudden traffic spikes can be absorbed without immediately overwhelming the core system. Requests can wait in the queue and be processed at a controlled pace. This is especially important because the final product registration still depends on BUYMA’s main system. synchronous queues buffer sudden request spikes before they reach the core platform 2. Better Failure Recovery If a downstream system is temporarily unavailable, sellers do not need to resend the same request manually. The request can remain in the queue, and processing can resume once the downstream system recovers. This is much better than asking users to keep retrying until they lose faith in the service entirely. 3. Protecting the Core Platform Because the main product registration and order processes still happen inside BUYMA’s monolithic environment, we need to protect that system carefully. PS-API absorbs external traffic and controls how requests are passed to the core platform. This allows the monolith to process requests at a safer and more predictable pace. Microservice optimism meets monolith realism. gRPC and SQS: Choosing the Right Communication Style In PS-API, not all communication is handled in the same way. Some processes require quick, direct communication between internal services. Other processes need durable asynchronous execution because they may take longer, depend on the BUYMA core platform, or require retries. For that reason, we use both gRPC and SQS, depending on the characteristics of each process. gRPC We mainly use gRPC for internal service-to-service communication where an immediate response is required. These are cases where PS-API needs a reliable internal response before continuing the current process. BUYMA Partners System ↔ Live PS-API communication BUYMA Partners System ↔ Sandbox PS-API communication Retrieving master data, such as brand data and category data Using gRPC gives us several advantages: fast internal communication clear service contracts through protobuf definitions better type safety between services predictable request-response behavior SQS For heavier business operations, we use SQS-based asynchronous processing. This includes communication with BUYMA’s main system for operations such as: product listing and update order shipment request processing These operations eventually affect BUYMA’s core platform, where product and order data are actually processed. Instead of forcing the original API request to wait until all downstream processing is complete, PS-API accepts the request, stores the payload, and lets the business process continue asynchronously. SQS is also used for process completion events. For example, after product listing or product update processing is completed, the completion result is sent back through the queue. PS-API then imports the result and sends the appropriate webhook response to the seller system. This is an important point: webhook delivery is not simply a response to the original API request. It is the final notification after asynchronous processing has completed. gRPC, SQS, and Webhook complete the asynchronous processing loop Why This Design Works Well Using gRPC and SQS together allows each communication pattern to be used where it fits best. gRPC is used for fast internal request-response communication. SQS is used for durable asynchronous business processing. This separation gives us several benefits. It protects BUYMA’s main system from sudden traffic spikes. If many sellers send product update requests at the same time, those requests can be queued and processed gradually. It improves reliability. If part of the downstream system is temporarily unavailable, requests do not simply disappear, and sellers do not need to retry everything manually. It gives us a better foundation for scaling. API request handling, queue processing, and webhook delivery can each be improved separately. This combination is one of the key reasons PS-API can operate as a bridge between external seller systems and BUYMA’s existing core platform. The Real Challenge: Scale Originally, PS-API was intended for a relatively small number of users. That assumption aged beautifully. As adoption increased, both the number of sellers and the number of requests grew significantly. With that growth came several familiar challenges: rate limits queue bottlenecks processing visibility issues inquiries like “The request succeeded, but where is my product?” The answer to that last question is sometimes: "Technically… somewhere in the queue." Or: "The webhook was already sent, along with an error message." This is where operating asynchronous systems becomes much more interesting than designing them. Building the API is one thing. Helping everyone understand the flow of request is another. And usually, that is the harder part. The Hidden Complexity of Async Systems From the outside, an API request may look simple: POST /api/v1/products.json But internally, the flow may look more like this: API → validation → database → queue → worker → storage → image download → downstream processor → completion event → cache invalidation → webhook delivery At some point, API starts looking less like an endpoint and more like airport baggage handling. Everyone trusts the system. No one is entirely sure where the suitcase is. From On-Premise to AWS One major improvement came from moving our infrastructure from on-premise servers to AWS, along with upgrading the database. This improved the transaction speed of import-related database operations. Of course, moving to AWS and upgrading the database did not magically remove every bottleneck. Software remains committed to teaching humility. However, it gave us a much stronger foundation, especially for asynchronous processing. For systems that depend heavily on queues, workers, and scalable processing capacity, infrastructure flexibility matters a lot. What We Are Still Improving Even after these improvements, scalability remains an ongoing challenge. The API layer can scale relatively well, but many core processes still depend on the main environment, where scaling is naturally more difficult. We are continuing to improve areas such as: better rate-limit strategies faster image download processing autoscaling for workers better visibility into request status smoother operations across monolith and microservice boundaries expanded PS-API documentation so that even sellers without technical expertise can smoothly start integrating with the platform The goal is not simply to accept the request. The real goal is to make PS-API a system sellers can rely on and one that can handle thousands of requests. Note: The images in this article were created using AI-generated visuals and are intended for conceptual illustration. hrmos.co

本記事は 2026 年 5 月 14 日 に公開された「 Getting started with Change Data Capture in Amazon Aurora DSQL 」を翻訳したものです。 本日、 Amazon Aurora DSQL はパブリックプレビューで Change Data Capture (CDC) を発表しました。これにより、データベースの変更をほぼリアルタイムで Amazon Kinesis Data Streams にストリーミングできます。Amazon Aurora DSQL は、常時利用可能なアプリケーション向けのサーバーレス分散 SQL データベースです。新しいアクティブ-アクティブ分散アーキテクチャにより、シングルリージョン構成で 99.99%、マルチリージョン構成で 99.999% の可用性を実現するよう設計されているため、可用性の高いアプリケーション構築に適しています。 最新のアプリケーションでは、分析、自動化、イベント駆動アーキテクチャを支えるリアルタイムデータパイプラインへの依存度が高まっています。従来、運用データベースから下流システムへデータを移動するには、スケジュール実行されるエクスポート、ポーリングクエリ、独自のレプリケーションソリューションが必要でした。これらの方法ではレイテンシーが発生し、運用負荷が増え、システム間の整合性維持が困難になります。 CDC の登場により、Aurora DSQL は下流サービスへのデータベース変更のネイティブストリーミングをサポートするようになりました。CDC は行レベルの変更を捕捉し、外部システムにほぼリアルタイムで配信します。 本記事では、Aurora DSQL Change Data Capture を構成し、データベースの変更を Kinesis Data Streams にストリーミングする方法を説明します。CDC の仕組み、ストリーミングパイプラインの構成方法、変更イベントの消費方法を学べます。 本記事を読み終えると、データベースの変更を耐久性のあるイベントストリームに送り出し、下流のアプリケーションで処理できる動作中の CDC パイプラインを構築できます。 Change Data Capture とは Change Data Capture は、データベースに対する変更を識別および記録し、外部システムから利用できるようにします。データセット全体を繰り返しコピーするのではなく、CDC は変更のあった行のみに焦点を当てます。アプリケーションが INSERT 、 UPDATE 、 DELETE ステートメントを実行するたびに、CDC は変更を捕捉して対応するイベントを生成します。これらのイベントには通常、操作の種類、対象テーブル、変更前後のデータが含まれます。この方式によりリソース消費を抑えつつ、低レイテンシーでデータパイプラインを動作させられます。 例えば、 INSERT 操作では新しい行の値を含むイベントが生成されます。 UPDATE 操作では更新後の完全な行を含むイベントが生成されます。 DELETE 操作では削除された行の主キー値を含むイベントが生成されます。CDC は変更分のみを捕捉するため、下流システムは大きなテーブルを繰り返しスキャンせずにデータの同期を維持できます。 Aurora DSQL Change Data Capture の概要 今回のリリースで、Aurora DSQL CDC は変更イベントを Amazon Kinesis Data Streams にストリーミングできるようになりました。Kinesis Data Streams はフルマネージドかつサーバーレスのストリーミングサービスで、 AWS Lambda などの他の AWS サービスと統合でき、 Apache Kafka のような外部ストリーミングシステムとも統合できます。 Aurora DSQL CDC はネイティブな機能で、データベースの変更を継続的に記録し、ストリーミング先に発行します。アプリケーションが SQL ステートメントでデータを変更すると、Aurora DSQL は発生した行レベルの変更を捕捉し、構造化されたイベントに変換します。 各変更イベントには、データベース操作と変更対象データを記述するメタデータが含まれます。このメタデータにより、下流のコンシューマーはデータベース変更の順序を正確に再構成できます。Aurora DSQL の CDC はアプリケーションのデータベーストランザクションとは独立して動作します。Aurora DSQL は変更イベントをバックグラウンドで捕捉および配信するため、運用ワークロードのパフォーマンスに影響を与えません。現在のリリースでは、CDC はクラスターレベルで動作し、すべてのテーブルの変更を捕捉します。テーブル単位の選択的なフィルタリングはサポートされていないため、特定のテーブルのみが必要な場合は下流のコンシューマー側でフィルタリングロジックを適用する必要があります。CDC の基本概念を理解したところで、実際のアーキテクチャでこの機能がどのように活用されるか見てみましょう。 Aurora DSQL CDC のユースケース Aurora DSQL CDC は、幅広い最新のデータアーキテクチャをサポートします。CDC はデータベース変更のほぼ連続したストリームを提供するため、新しいデータに対してシステムが素早く反応できます。代表的なユースケースの 1 つが リアルタイム分析 です。多くの組織では、運用データを最小の遅延で分析システムに反映する必要があります。CDC ストリームをデータウェアハウスや分析プラットフォームで消費することで、継続的に更新されたデータセットを維持できます。これにより、ダッシュボードやレポートに最新のビジネス活動を反映できます。 もう 1 つの重要なユースケースが イベント駆動アーキテクチャ です。最新のアプリケーションの多くは、イベントを介して通信する疎結合のサービスで構成されています。CDC により、データベースの変更をアプリケーションのイベントとして扱えます。例えば、新しい注文レコードを挿入すると、決済処理や在庫更新などの下流ワークフローを起動できます。 CDC は データレプリケーションのシナリオ でも有用です。多くの組織では、運用データベース、検索インデックス、分析システムなど、用途別に複数のデータストアを運用しています。CDC によって、データ全体をコピーすることなくシステム間で増分同期できます。 最後に、CDC はデータベース活動の包括的な監査証跡を提供します。各変更がイベントとして記録されるため、CDC ストリームはコンプライアンスやトラブルシューティング目的でアーカイブおよび分析できます。 アーキテクチャの概要 次のアーキテクチャは、Aurora DSQL CDC が下流のコンシューマーへデータベース変更をストリーミングする仕組みを示しています。 アプリケーションは標準の SQL ステートメントを使用して Aurora DSQL とやり取りします。これらの操作はデータベース内の行を変更し、変更イベントの主要な発生源となります。Aurora DSQL はテーブルの変更を監視し、変更内容を記述する CDC イベントを生成します。各イベントには、操作の種類、タイムスタンプ、トランザクション識別子、行の値などの情報が含まれます。 Aurora DSQL は CDC イベントを Kinesis データストリームに発行します。ストリームは、データベースワークロードと下流処理を切り離す耐久性とスケーラビリティに優れたバッファです。コンシューマーアプリケーションはストリームからイベントを読み取り、アプリケーションの要件に従って処理します。コンシューマーは分析システムの更新、ワークフローの起動、外部データベースの同期などを行います。 このアーキテクチャにより、Aurora DSQL は信頼できる唯一の情報源となり、下流のシステムは非同期にデータを消費できます。このアーキテクチャを構築する前に、環境を準備する必要があります。 前提条件 本セクションでは、Aurora DSQL Change Data Capture を構成するために必要なツールと権限を説明します。詳細については、 前提条件 を参照してください。 AWS アカウントにアクセスできる認証情報で構成済みの AWS Command Line Interface (AWS CLI) バージョン 2 が必要です。AWS CLI は、Aurora DSQL クラスターの作成、CDC ストリームの構成、関連リソースの管理に使用します。 単一の AWS リージョンに Aurora DSQL クラスター が必要です。 クライアントマシンに PostgreSQL クライアントユーティリティ psql がインストールされている必要があります。Aurora DSQL は PostgreSQL 互換の接続を提供しており、 psql を使って接続、テーブル作成、テストデータ生成を行います。 jq ユーティリティは必須ではありませんが、JSON 出力の閲覧が容易になるため推奨します。 AWS の ID には、Aurora DSQL クラスターの作成、CDC ストリームの管理、Kinesis ストリームの作成、IAM ロールの構成を行う権限が必要です。次のポリシーが必要な権限を提供します。Aurora DSQL クラスターの作成、CDC ストリームの管理、Kinesis ストリームの作成、IAM ロールの構成に必要な IAM 権限 を以下に示します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dsql:ListClusters", "dsql:CreateCluster", "dsql:GetCluster", "dsql:DeleteCluster", "dsql:DbConnectAdmin", "dsql:CreateStream", "dsql:GetStream", "dsql:ListStreams", "dsql:DeleteStream", "dsql:UpdateCluster" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kinesis:CreateStream", "kinesis:DescribeStream", "kinesis:DescribeStreamSummary", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards", "kinesis:DeleteStream" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePolicy", "iam:GetRole", "iam:PassRole", "iam:DeleteRole", "iam:DeleteRolePolicy" ], "Resource": "*" } ] } 環境の準備ができたら、次は AWS CLI を使って Aurora DSQL CDC を有効化します。 マルチリージョンの Aurora DSQL クラスター では、CDC ストリームはストリームが作成されたリージョンに関係なく、すべてのリージョンからコミット済みの書き込みを捕捉します。Aurora DSQL クラスター、ストリーミングターゲット、IAM ロール、呼び出し元プリンシパルなどのすべてのリソースは、同じ AWS アカウントとリージョン内に存在する必要があります。複数のリージョンに CDC レコードを配信するには、各リージョンで個別のストリームを作成してください。各ストリームは独立して同じコミット済み変更のセットを配信します。 注意 : 本記事では、<プレースホルダー値> を実際の情報に置き換えてください。 ステップ 1: Kinesis データストリームを作成する Aurora DSQL CDC はイベントをストリーミング先に発行します。本記事では、ストリーミング先として Amazon Kinesis データストリームを使用します。 単一の シャード で新しい Kinesis ストリームを作成します。シャードは CDC イベントで利用可能なスループット容量を決定します。ストリームを構成する際は、ストリーミング設定でサポートされる最大レコードサイズを考慮してください。Aurora DSQL は最大 2 MiB の 行サイズ をサポートしており、CDC イベントはスキーマやワークロード次第でこの上限に近づくことがあります。設定したレコードサイズが発行されるイベントのサイズより小さい場合、配信に失敗し CDC パイプラインが機能しなくなる可能性があります。 新しい Kinesis ストリームを作成する前に、まずこのデモで使用する環境変数を設定します。 export REGION="<us-east-2>" export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export AWS_DEFAULT_OUTPUT=json export KINESIS_STREAM_NAME="<dsql-cdc-stream>" aws kinesis create-stream \ --stream-name ${KINESIS_STREAM_NAME} \ --stream-mode-details StreamMode=ON_DEMAND \ --max-record-size-in-ki-b 2024 \ --region ${REGION} ストリームを作成したら、ストリームステータスが “ ACTIVE ” になるまで待ちます。Aurora DSQL は、ストリームが完全に利用可能になるまでイベントを発行できません。 # Check stream status aws kinesis describe-stream \ --stream-name ${KINESIS_STREAM_NAME} \ --region ${REGION} \ --query 'StreamDescription.StreamStatus' 次に、ストリームの Amazon Resource Name (ARN) を取得します。 export KINESIS_STREAM_ARN=$(aws kinesis describe-stream \ --stream-name ${KINESIS_STREAM_NAME} \ --region ${REGION} \ --query 'StreamDescription.StreamARN' \ --output text) echo "Kinesis Stream ARN: ${KINESIS_STREAM_ARN}" ARN はストリームを一意に識別するもので、CDC を構成する際に必要です。後で使用する可能性があるため、ストリーム ARN をメモしておいてください。ストリーミング先が準備できたら、次に Aurora DSQL がイベントを発行する権限が必要です。 ステップ 2: CDC 用の IAM ロールを作成する Aurora DSQL は、Kinesis ストリームに書き込む権限を持つ IAM ロールを引き受けて CDC イベントを発行します。IAM ロールには、Aurora DSQL がロールを引き受けることを許可する信頼ポリシーが必要です。 信頼ポリシー は特定の Aurora DSQL クラスターへのアクセスを制限します。ロールには、Kinesis ストリームへの書き込みアクセスを付与する アクセス許可ポリシー も必要です。 まず、次のセクションのように信頼ポリシーとアクセス許可ポリシーを作成します。 # Create Trust policy cat > trust-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "dsql.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "${ACCOUNT_ID}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:dsql:${REGION}:${ACCOUNT_ID}:cluster/*" } } } ] } EOF # Create Permission policy cat > permissions-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:PutRecord", "kinesis:PutRecords", "kinesis:DescribeStreamSummary", "kinesis:ListShards" ], "Resource": "arn:aws:kinesis:${REGION}:${ACCOUNT_ID}:stream/${KINESIS_STREAM_NAME}" } ] } EOF 次に、ロールを作成してポリシーをアタッチします。 # Create an IAM Role export CDC_ROLE_NAME="<dsql-cdc-kinesis-role>" aws iam create-role \ --role-name ${CDC_ROLE_NAME} \ --assume-role-policy-document file://trust-policy.json # Attach the policy to the Role aws iam put-role-policy \ --role-name ${CDC_ROLE_NAME} \ --policy-name <cdc-kinesis-policy> \ --policy-document file://permissions-policy.json ロールを作成してアクセス許可ポリシーをアタッチしたら、ロール ARN を取得します。 aws iam get-role \ --role-name ${CDC_ROLE_NAME} \ --query 'Role.Arn' \ --output text ロール ARN をメモしておいてください。ロール ARN は CDC ストリームの作成時に必要です。権限を構成したら、CDC ストリームを作成できます。 ステップ 3: CDC ストリームを作成する CDC ストリームは Aurora DSQL クラスターと Kinesis ストリームを接続します。CDC ストリームを作成すると、Aurora DSQL はデータベースの変更を Kinesis ストリームに発行し始めます。ストリームの作成には通常数分かかり、その間に Aurora DSQL は CDC 処理に必要な内部インフラストラクチャをプロビジョニングします。 aws dsql create-stream \ --cluster-identifier ${CLUSTER_ID} \ --target-definition "{\"kinesis\":{\"streamArn\":\"${KINESIS_STREAM_ARN}\",\"roleArn\":\"${CDC_ROLE_ARN}\"}}" \ --ordering UNORDERED \ --region ${REGION} \ --format JSON # Example output { "clusterIdentifier": "2ntttwpyh6nbmi5h54h2e4p4ja", "streamIdentifier": "fntuauzlakwytxknp2k6acrxk4", "arn": "arn:aws:dsql:us-east-2:444455556666:cluster/2ntttwpyh6nbmi5h54h2e4p4ja/stream/fntuauzlakwytxknp2k6acrxk4", " status": "CREATING ", "creationTime": "2026-03-18T10:14:55.405000-04:00", "ordering": "UNORDERED", "format": "JSON" } ストリームが “ ACTIVE ” になるまで待ちます。 # Check stream status (repeat until status is "ACTIVE") export STREAM_ID="<your-stream-identifier-from-output>" aws dsql get-stream \ --cluster-identifier ${CLUSTER_ID} \ --stream-identifier ${STREAM_ID} \ --region ${REGION} \ --query 'status' ストリームが “ ACTIVE ” になると、Aurora DSQL はデータベースの変更を捕捉する準備ができます。次のステップでは、データベースの活動を生成します。 ステップ 4: データベースの変更を生成する CDC を有効化したら、データベースに変更を加えて構成を検証できます。PostgreSQL クライアントで Aurora DSQL に接続し、テスト用テーブルを作成します。CDC に参加するテーブルに主キーは厳密には必要ありませんが、定義することを推奨します。主キーがあれば Aurora DSQL は行を一意に識別でき、より意味のある変更イベントを生成できます。主キーがない場合、 INSERT および UPDATE 操作は完全な行データを含みますが、 DELETE イベントには削除された行を識別する十分な情報が含まれない可能性があります。 テーブルを作成したら、いくつかのレコードに対して挿入、更新、削除を行います。これらの操作によって Aurora DSQL が Kinesis ストリームに発行する CDC イベントが生成されます。次のコマンドで Aurora DSQL クラスターへの 接続 を確立します。 PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname ${CLUSTER_ID}.dsql.${REGION}.on.aws --region ${REGION}) \ PGSSLMODE=require \ psql -h ${CLUSTER_ID}.dsql.${REGION}.on.aws -U admin -d postgres 接続を確立したら、次のコードで主キー付きのテーブルを作成します。 CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name VARCHAR(100) NOT NULL, email VARCHAR(255), created_at TIMESTAMP DEFAULT NOW() ); 次のコードでいくつかの行を挿入します。 INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com'); INSERT INTO users (name, email) VALUES ('Bob', 'bob@example.com'); INSERT INTO users (name, email) VALUES ('Charlie', 'charlie@example.com'); 続いて、変更レコードを生成します。テストデータの生成が終わったら、データベースから切断します。 -- Update a record UPDATE users SET email = 'alice.updated@example.com' WHERE name = 'Alice'; -- Delete a record DELETE FROM users WHERE name = 'Charlie'; -- Exit from psql \q 次のステップでは、ストリームから CDC イベントを読み取ります。 ステップ 5: CDC イベントを読み取る CDC イベントは Kinesis ストリームに保存され、AWS CLI またはコンシューマーアプリケーションで読み取れます。まず、ストリーム内のシャードを一覧表示します。 # List shards in the stream aws kinesis list-shards \ --stream-name ${KINESIS_STREAM_NAME} \ --region ${REGION} 各シャードはレコードのシーケンスを表します。本例では簡単のためシャードを 1 つだけ使用していますが、本番環境のワークロードではストリームに複数のシャードを含められ、コンシューマーはすべてのレコードを読み取るためにシャードを横断的に処理する必要があります。次に、読み取りを開始する位置を指定する シャードイテレータ を取得します。例えば TRIM_HORIZON は、利用可能な最も古いレコードから読み取りを開始します。シャードイテレータを使用してストリームからレコードを取得します。CDC イベントのペイロードは Base64 でエンコードされています。ペイロードをデコードすると、イベントは読み取り可能な JSON になります。各イベントはデータベースの変更を記述し、タイムスタンプ、トランザクション識別子、スキーマ名、テーブル名などのメタデータを含みます。 # Get iterator for the first shard, starting from the beginning export SHARD_ITERATOR=$(aws kinesis get-shard-iterator \ --stream-name ${KINESIS_STREAM_NAME} \ --shard-id shardId-000000000000 \ --shard-iterator-type TRIM_HORIZON \ --region ${REGION} \ --query 'ShardIterator' \ --output text) # Fetch records from Kinesis aws kinesis get-records \ --shard-iterator ${SHARD_ITERATOR} \ --region ${REGION} # Example output { "Records": [ { "SequenceNumber": "49654...", "ApproximateArrivalTimestamp": "2026-03-18T10:24:01.153000-04:00", "Data": "eyJ0eXBlIjoiSU5TRVJUIiwic2NoZW1hIjoicHVibGljIiwidGFibGUiOiJ1c2VycyIsLi4ufQ==", "PartitionKey": "..." } ], "NextShardIterator": "AAAA...", "MillisBehindLatest": 0 } 続いて、データをデコードしてみましょう。 CDC イベントの構造とセマンティクスの理解 Amazon Kinesis Data Streams からレコードを取得した後、次のステップは CDC イベントペイロードの解釈方法を理解することです。Amazon Aurora DSQL が発行する各イベントは、データの変更とそれに関連するメタデータを記述する一貫した JSON 構造に従います。大まかに見ると、すべての CDC イベントには操作の種類、変更前後の行の状態、ソースとイベントのタイミングに関するメタデータが含まれます。 op フィールドは操作の種類を示します。パブリックプレビュー期間中、Aurora DSQL は INSERT 操作と UPDATE 操作の両方を c (create) で表します。これは、更新が行の新しいバージョンとしてモデル化されるためです。 DELETE 操作は d で表されます。 INSERT と UPDATE を区別するには、特定の主キーが過去に観測されたかを追跡する必要があります。 一般提供 (GA) の段階で、Aurora DSQL CDC は更新用の独立した u 操作タイプを導入する予定です。そのため、コンシューマーは将来のすべての行変更が c イベントのみを使い続けると仮定すべきではなく、それを踏まえてイベント処理ロジックを設計する必要があります。 op フィールドは操作の種類を示します。Aurora DSQL は INSERT 操作と UPDATE 操作の両方を c (create) で表します。これは、更新が行の新しいバージョンとしてモデル化されるためです。 DELETE 操作は d で表されます。そのため、 INSERT と UPDATE を区別するには、特定の主キーが過去に観測されたかを追跡する必要があります。 before フィールドと after フィールドは行の状態を表します。 INSERT および UPDATE 操作では、イベントには変更後の完全な行が含まれ、before フィールドは null になります。 DELETE 操作では after フィールドが null になり、before フィールドには削除された行の主キーのみが含まれます。この設計により、削除されたレコードを下流システムが識別可能なまま、ペイロードサイズを抑えられます。 各イベントには 2 種類のタイムスタンプも含まれます。ルートレベルの ts_ms および ts_ns フィールドは、変更がデータベースにコミットされた時刻を表します。 source.ts_ms および source.ts_ns フィールドは、CDC パイプラインがイベントを処理してストリームに発行した時刻を表します。これらのタイムスタンプの差は、データベースからストリーミングシステムへの伝播レイテンシーを示します。source オブジェクトには、トランザクション ID、スキーマ名、テーブル名、データベース名、クラスター識別子などの追加メタデータが含まれます。これらのメタデータは、監査、デバッグ、下流処理ロジックの構築に有用です。 詳細については、 CDC レコード形式 を参照してください。 次の例は、各種データベース操作が CDC イベントとしてどのように表されるかを示します。 # Using the output from get-records echo "<base64-encoded-data>" | base64 -d | jq 次の例は INSERT 操作を示します。”Alice” の新しい行が挿入されました。 op フィールドは “c”、 before は null 、 after には完全な行が含まれます。コミットタイムスタンプ ( ts_ms ) は CDC 発行タイムスタンプ ( source.ts_ms ) より前で、変更が CDC パイプラインを伝播するのにかかった時間を示しています。 # Example output for an INSERT { "op": "c", "before": null, "after": { "id": "521d51b6-47fd-46dc-854a-32306bfc5001", "name": "Alice", "email": "alice@example.com", "created_at": 1773843841048727 }, "source": { "version": "1.0", "ts_ms": 1773843841175, "ts_ns": 1773843841175766820, "txId": "dco7le2ijpdsjtspu7hqkf2lyi", "schema": "public", "table": "users", "db": "postgres", "cluster": "2ntttwpyh6nbmi5h54h2e4p4ja" }, "ts_ms": 1773843841076, "ts_ns": 1773843841076494565 } 次の例は UPDATE 操作を示します。Alice のメールアドレスが更新されました。 op フィールドは c で、イベントには更新後の完全な行が含まれます。Aurora DSQL は更新を行の新しいバージョンとして表すため、このイベントは構造的には INSERT と同一です。 UPDATE と INSERT を区別するには、同じ主キーが過去のイベントで現れたかを追跡する必要があります。 # Example outuput for an UPDATE { "op": "c", "before": null, "after": { "id": "521d51b6-47fd-46dc-854a-32306bfc5001", "name": "Alice", "email": "alice.updated@example.com", "created_at": 1773843841048727 }, "source": { "version": "1.0", "ts_ms": 1773843889144, "ts_ns": 1773843889144309734, "txId": "dco7lhttogt6ntspu7hrvfvsuq", "schema": "public", "table": "users", "db": "postgres", "cluster": "2ntttwpyh6nbmi5h54h2e4p4ja" }, "ts_ms": 1773843889108, "ts_ns": 1773843889108904247 } 次の例は DELETE 操作を表します。行が削除されました。 op フィールドは d 、 after フィールドは null、 before フィールドには削除された行の主キーのみが含まれます。これにより、下流システムは行データ全体を含めなくても、どのレコードが削除されたかを識別できます。 # Example output for DELETE { "op": "d", "before": { "id": "539cdc67-d1a0-4a56-b9cc-98d6f61bdef8" }, "after": null, "source": { "version": "1.0", "ts_ms": 1773843901898, "ts_ns": 1773843901898646132, "txId": "dco7lillvfrhjtspu7h36ehc3e", "schema": "public", "table": "users", "db": "postgres", "cluster": "2ntttwpyh6nbmi5h54h2e4p4ja" }, "ts_ms": 1773843901887, "ts_ns": 1773843901887887743 } これらのイベントをアプリケーションで消費することで、リアルタイムのデータパイプラインを構築できます。 Aurora DSQL CDC のイベント順序の理解 CDC を基盤としてアプリケーションを構築する際に最も重要な検討事項の 1 つが、変更イベントが下流システムに配信される順序です。イベントの処理順序は、コンシューマーが変更を解釈および適用する方法に直接影響します。 Aurora DSQL CDC は、CDC ストリーム作成時に明示的な順序設定を導入しています。この設定はストリーミング先に配信されるイベントの順序保証を定義し、追加の順序モードや統合の導入に伴って今後変化する可能性があります。Aurora DSQL CDC は現在パブリックプレビュー段階のため、下流のコンシューマーは操作タイプのセマンティクスに関する仮定をハードコードすることを避け、将来のイベント形式の拡張を許容できるよう設計する必要があります。 本記事の執筆時点では、Aurora DSQL CDC ストリームは順序を保証しないイベント配信を提供します。つまり、行やトランザクション間で厳密な順序保証なしにイベントが配信されます。詳細については、 順序と配信のセマンティクス を参照してください。この方式は高いスケーラビリティとスループットをサポートするため、効率的で大規模な変更ストリーミングを必要とするワークロードに適しています。各イベントは完全かつ一貫していますが、下流のコンシューマーは順序が前後して到着するイベントを正しく処理できるよう、冪等処理や状態の整合性確保といったパターンを使って設計する必要があります。ストリーム作成時に順序を明示することで、配信セマンティクスを最初から明確に理解した上でアプリケーションを設計できます。順序を保証しないストリームを処理するコンシューマーの設計について、ポーリングやバッチ処理などの手法を含めた詳細は、 Lambda を使用した Amazon Kinesis Data Streams のレコード処理 と 順序と重複排除の戦略 を参照してください。 ベストプラクティス Amazon Kinesis Data Streams を使用する際は、データストリームを作成し、ワークロードに合った適切なキャパシティモードを選択できます。ストリーム管理を簡素化するには、オンデマンドキャパシティモードを選びます。このモードでは、Kinesis が CDC トラフィックに合わせてスループットを自動的にスケーリングするため、シャードを手動でプロビジョニングおよび管理する必要がありません。詳細については、 適切なストリームモードを選択する を参照してください。 Amazon Aurora DSQL から Amazon Kinesis Data Streams へ CDC イベントをストリーミングする際は、ストリームでサポートされる最大レコードサイズを考慮することが重要です。Kinesis は個々のレコードのサイズに上限を設けています。CDC イベントがこの上限を超えると、ストリームにイベントを配信できません。その場合、サイズ制約が解消されるまで CDC パイプラインが機能しなくなる可能性があります。これを避けるため、データモデルの サイズ特性 を考慮し、想定されるペイロードサイズを 処理できるよう ストリーミングパイプラインとコンシューマーを構成してください。これらの上限を踏まえて設計することで、中断のない継続的かつ信頼性の高い CDC イベント配信を維持できます。 下流のシステムは、 重複イベントの処理 と順序が前後して到着するイベントの処理に対応できるよう設計してください。CDC の配信は非同期で厳密な順序を保証しないため、コンシューマーは同じイベントを複数回受信したり、順序が前後して到着するイベントを観測したりする可能性があります。正確性を保つため、アプリケーションは冪等な処理ロジックを実装し、イベントが繰り返されても結果に不整合が生じないようにする必要があります。これは通常、主キーやトランザクションのメタデータ (タイムスタンプやトランザクション ID など) を使って変更を検出および調整することで実現します。順序が重要な場合は、コンシューマーは バッチ処理 、タイムスタンプを使用したイベントの並べ替え、コミット時刻に基づく last-write-wins セマンティクスを適用できます。一部のテーブルのみを処理したい場合は、CDC ストリームにすべてのテーブルの変更が含まれるため、下流のコンシューマー側でフィルタリングロジックを適用してください。これらのパターンを踏まえてコンシューマーを設計することで、高スループットのストリーミング条件下でも信頼性と一貫性のあるデータ処理を実現できます。 クリーンアップ CDC パイプラインが正しく動作し、Amazon Kinesis Data Streams へのデータベース変更のストリーミングを検証できたら、本ウォークスルーで作成したリソースをクリーンアップできます。 Amazon Aurora DSQL の CDC ストリームを削除しても、データベース内の既存データは維持されます。ストリームを削除すると、Kinesis データストリームへの新しい変更イベントの配信が停止するだけです。同様に、Kinesis ストリームを削除してもソースデータベースには影響しませんが、ストリームに保存されている未消費の CDC レコードは完全に削除されます。 本セクションでは、本記事で作成したリソースを削除する手順を案内します。これにより、不要なコストを避けつつ、AWS 環境をクリーンに保てます。 # Delete the CDC stream aws dsql delete-stream \ --cluster-identifier ${CLUSTER_ID} \ --stream-identifier ${STREAM_ID} \ --region ${REGION} # Wait for stream deletion, then disable deletion protection and delete the cluster aws dsql update-cluster \ --identifier ${CLUSTER_ID} \ --no-deletion-protection-enabled \ --region ${REGION} # If you created a new Aurora DSQL cluster to test CDC feature aws dsql delete-cluster \ --identifier ${CLUSTER_ID} \ --region ${REGION} # Delete the Kinesis data stream aws kinesis delete-stream \ --stream-name ${KINESIS_STREAM_NAME} \ --region ${REGION} # Delete the IAM role and associated policy aws iam delete-role-policy \ --role-name ${CDC_ROLE_NAME} \ --policy-name cdc-kinesis-policy aws iam delete-role \ --role-name ${CDC_ROLE_NAME} # Clean up local files rm -f trust-policy.json permissions-policy.json これらの手順を完了すると、CDC パイプライン用に作成したリソースが削除され、AWS 環境は元の状態に戻ります。 まとめ Aurora DSQL Change Data Capture は、データベースの変更を外部システムにストリーミングするネイティブな仕組みを提供します。本記事では、データベースの変更を捕捉して Kinesis ストリームに発行する CDC パイプラインを構成しました。データベースの活動を発生させ、生成されたイベントを検証しました。Aurora DSQL CDC は独自のレプリケーションソリューションを不要にし、リアルタイムアーキテクチャの構築を簡素化します。Aurora DSQL をストリーミングシステムと統合することで、開発者はデータの変更にほぼリアルタイムで反応する応答性の高いアプリケーションを構築できます。Aurora DSQL Change Data Capture は、スケーラブルなイベント駆動システムやリアルタイム分析パイプラインを構築するための基盤となります。 著者について Vijay Karumajji Vijay は、AWS のプリンシパルデータベーススペシャリスト Solutions Architect です。商用およびオープンソースのデータベースで 20 年以上の経験を持ち、深い技術的専門知識を活かして組織のデータプラットフォームのモダナイゼーションと AWS マネージドデータベースサービスの価値最大化を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Koji Shinkubo がレビューしました。