---
title: AWS上のKafka運用をどうシンプルにするか
tags: 
author: [蘇躍君](https://image.docswell.com/user/KDCloud)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4EQYP66LJP.jpg?width=480
description: AWS上のKafka運用をどうシンプルにするか by 蘇躍君
published: October 04, 26
canonical: https://image.docswell.com/s/KDCloud/KJWY14-2026-10-04-230320
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4EQYP66LJP.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/KJ4WY44571.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LE1Y64427G.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GEWGWXX2J2.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/47ZL5664J3.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/YJ6W922GJV.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GJ5MN22XJ4.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LE3W2KK4E5.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/8EDKZ3357G.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/V7PKD44DJ8.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/2JVV1XXGJQ.jpg)

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