AWS上のKafka運用をどうシンプルにするか

AWS上のKafka運用を どうシンプルにするか ストレージ分離から考える Scaling・Recovery・コスト K・D・Cloud株式会社 2026.09 蘇 躍君

02 会社紹介 K・D・Cloud株式会社 専門領域 代表取締役 AWSアーキテクチャ設計 蘇 躍君 AWSを中心としたクラウドアーキテクチャ設計と、 リアルタイムデータ基盤の導入支援に取り組んでいま す。 データ基盤 Kafka・CDC・リアルタイム連携 支援範囲 PoC、導入、移行、運用 2 / 11

03 Kafkaとは何か 多数のシステム間でイベントを受け渡す、分散型イベントストリーミング基盤 Producer 業務システム センサー アプリ イベント Kafka › Topicに保存 順序をPartitionで管理 再利用 Consumer › 分析 通知 別システム › 同じイベント を 複数用途で読 む 注文、在庫更新、クリック、位置情報、ログなど「起きた事実」 技術上の要点 高スループット、永続化、再読み取り、複数Consumer、Partition単位の順序 Source: Apache Kafka Documentation, Introduction / Design 3 / 11

04 Kafkaをわかりやすく言うと 一度流したイベントを、必要なシステムがそれぞれ利用できる共通基盤 個別連携が増える構造 イベントを共有する構造 注文 通知 注文 在庫 分析 在庫 配送 AI 配送 接続先が増えるほど、変更影響が広がる 通知 Kafka 分析 イベント共有 AI 新しい用途をConsumerとして追加しやすい 4 / 11

05 Kafkaはどんな場面で使われるのか 業務イベント連携 CDC 注文・決済・在庫更新を 複数システムへ配信 DBの変更を取得し、 検索・分析・別DBへ反映 EC、金融、基幹連携 データ移行、同期、DWH IoT・モビリティ ログ・行動分析 センサーや車両位置を 継続的に収集 アクセスや操作イベントを 蓄積して即時分析 製造、物流、設備監視 不正検知、推薦、監視 共通する条件：イベント量が多い、接続先が増える、後から再処理したい Source: Apache Kafka Documentation, Use Cases 5 / 11

06 AWS上のKafka運用で難しくなる点 SCALING RECOVERY COST Broker追加後も、 Partition再配置とデータ移 動が残る Broker障害時に、 Replica復旧がネットワー クとI/Oを使う ピークに合わせた計算資源と 保持期間に合わせたディスク を抱える 増設＝即時の容量増加 とは限らない 復旧時間がデータ量に 引っ張られる CPUとStorageを別々に 最適化しにくい 共通項：Brokerが「処理」と「長期データ保持」を同時に担う Source: Apache Kafka Documentation, Design / Operations 6 / 11

07 ストレージ分離で、Brokerの役割を軽くする 耐久データを共有ストレージへ、Brokerを処理中心へ 従来型 Broker Broker ストレージ分離型 Broker 処理 処理 処理 Data Data Data Broker Broker Broker 処理 処理 処理 Shared / Object Storage 耐久データを一元化 Replicaごとにデータを保持 変わるのは「データの置き場所」だけではなく、運用の依存関係 Conceptual architecture. Apache Kafka tiered storage and cloud-native implementations differ in scope. 7 / 11

08 Scaling：計算資源の追加とデータ再配置を切り離す 負荷上昇 即時に処理へ Broker追加 › Throughput / Connection Compute capacity › Data copyを待ちにくい 設計時に確認する指標 1 Network ingress / egress Source: Amazon MSK documentation, broker scaling and partition management 2 Partition数とleader分布 3 再配置中のp99 latency 4 追加容量が有効になるまで の時間 8 / 11

09 Recovery：復旧時間を「保持データ量」から離す Broker障害 LOCAL REPLICA Replica再構築・大量コピー SHARED STORAGE Broker再参加 Traffic復帰 見るべき値：RTO、Under Replicated Partitions、復旧中のNetwork / p99 latency Source: Apache Kafka Operations; Amazon MSK monitoring guidance 9 / 11

10 Cost：容量ではなく、コストの結び付きを見る 従来型 ストレージ分離型 Compute ピークThroughputに合わせる 処理負荷に合わせて調整 Storage Retention × Replicaで増える 耐久層へ集約しやすい Network / I/O 再配置・復旧時に増える 大規模コピーを減らしやすい Operations 容量計画と再配置が必要 監視対象と障害境界が変わる 公開事例では、Kafka関連コストを50%以上削減した例も 実際の効果は、トラフィック・保持期間・読み取り特性・現行構成によって異なります Source: AWS pricing guidance; AutoMQ published benchmarks and production cases 10 / 11

ご清聴ありがとうございました Kafka・AWS上のデータ基盤について、 技術的なご質問や情報交換がございましたら、お気軽にご連絡ください。 K・D・Cloud株式会社 Web https://k-d-cloud.com Email [email protected] 技術検討・PoCに関するご相談も承ります 11 / 11