--- title: Kafka運用をシンプルにするには？ tags: author: [蘇躍君](https://docswell.com/user/KDCloud) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/PER9ZY3LJ9.jpg?width=480 description: Kafka運用をシンプルにするには？ by 蘇躍君 published: September 07, 26 canonical: https://docswell.com/s/KDCloud/K7N6X8-2026-09-07-230853 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/PER9ZY3LJ9.jpg) Kafka運用をシンプルにするには？ ― ストレージ分離で変わる Scaling・Recovery・運用負荷 2026.09.04 蘇 躍君 / K・D・Cloud株式会社 1 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/P7XQ9G96EX.jpg) 自己紹介 蘇 躍君 K・D・Cloud株式会社 代表取締役 / Cloud Solutions Architect AWS 2024 / 2025 Japan AWS All Certifications Engineers 現在の取り組み ● リアルタイムデータ基盤の技術課題 Kafkaを中心とした技術課題に対するソリューション設計・提案 ● 主なテーマ Scaling・Recovery・運用負荷・コストの改善 ● アーキテクチャ Cloud Native Architecture / Compute-Storage Separation の活用 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/37K9P4PG7D.jpg) 企業がKafka運用で直面している課題 ビジネスの成長に伴い、Kafka基盤の運用はますます複雑になっています 急増するデータ量 とキャパシティ計画 ↻ ◆ $ Scalingのたびに 発生するデータ移動 障害時の復旧が重い コストと運用負荷 が高止まり ・データ量の予測が難しい ・Partitionの再配置 ・Broker障害でリーダー再選出 ・Cross-AZのデータ転送 ・将来を見越した過剰なリソー ス確保 ・大量のデータコピー ・データ同期（Replicaコピー） ・ディスク/ノードの無駄 ・長時間のRebalanceで性能に 影響 ・復旧までに時間がかかり、 SLAに影響 ・監視・チューニング・障害対 応が必要 ・投資効率が悪化 根本原因の一つは「Broker（Compute）とStorageの強い結合」 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/LJ3WXLX5J5.jpg) 従来のKafkaアーキテクチャ（Broker + Storage） Producer ・各Brokerがデータと計算を両方保持 ・データは各ノードのディスク（EBS / Local Disk）に保存 ・Partitionは複数BrokerにReplicaとして 保存 Broker A (Leader) Broker B (Follower) Broker C (Follower) Local Disk / EBS Local Disk / EBS Local Disk / EBS ・データと計算が密結合 Replication Replication Consumer 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/8JDK2N2YEG.jpg) なぜScalingが重くなるのか？ データ移動（Reassignment）が必須になる Before Scaling 1 リソース追加/減少 ・Brokerを追加/削除する必要がある ・負荷に応じて頻繁にScalingが発生 Broker A P1 P4 Broker B P2 P5 Broker C P3 P6 Reassignment（データコピ ー） 2 Partitionの再配置 ・新しいBrokerにPartitionを再配置 After Scaling ・既存のデータを別ノードへコピー Broker A P1 3 Broker B P2 Broker C P3 Broker D P4 パフォーマンスへの影響 ・大量のデータ転送でNetwork/Diskが逼迫 ・Rebalance中は遅延増大、スループット低下 データ量が増えるほど、再配置のコストと時間は増大 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/VEPK151278.jpg) なぜBroker障害時のRecoveryが重くなるのか？ データは各Brokerのディスクに分散している 1 Broker障害発生 Broker B 障 害 リーダーBrokerがダウン 2 リーダー再選出 Broker A (Leader) Broker B (Down) Broker C (Follower) Local Disk / EBS Local Disk / EBS Local Disk / EBS 他のReplicaから新リーダーを選出 3 データ同期（Replicaコピー） 新リーダーへ追従するため、別のBrokerからデータ コピー コピー（データ同期） 4 復旧完了 すべてのReplicaが同期完了後、通常運用へ データが分散しているため、復旧に時間とリソースが必要 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/27VVYPYX7Q.jpg) アーキテクチャの変革：ComputeとStorageの分離 ・Shared Storageを採用：データは共通のストレージに 集約（例：S3互換オブジェクトストレージ） Producer ・Stateless Broker：Brokerはデータを持たず、計算/ネ ットワーク処理に集中 ・データは一元管理：Partitionデータは1箇所に保存、 コピー不要 ・Kafka互換のまま：クライアントやエコシステムはそ のまま利用可能 Broker A (Stateless) Broker B (Stateless) Broker C (Stateless) Broker D (Stateless) Shared Storage（オブジェクトストレージ） S3互換 / 共有ストレージ Consumer 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/5JGL9P9R7L.jpg) 変革によって得られる効果 ◆ Scalingが圧倒的にシンプル Recoveryが高速で確実 運用負荷とコストを削減 ・データ移動なしでBroker追加/削除 ・Broker障害時も即座に再起動 ・Cross-AZ転送コストを大幅削減 ・秒単位でスケールイン/アウト ・データ同期が不要 ・ストレージコストを最適化 ・Rebalanceが不要 ・短時間で復旧完了 ・設計/チューニングが簡素化 ・ビジネスへの影響を最小化 ・SLAを安定して維持 ・運用チームの負荷を軽減 Kafkaの互換性を保ちながら、クラウドネイティブな次世代基盤へ 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/47QYW2WYEP.jpg) まとめ ストレージ分離がもたらす本質的な変化 ✓ 根本原因の解消 ComputeとStorageの分離が、Kafka運用の根植えとなる課題 を解消 ✓ ビジネス俊敏性の向上 迅速なScalingと高速なRecoveryで、変化に強いデータ基盤 を実現 ✓ コスト最適化と運用簡素化 ✓ 今あるKafkaエコシステムを 継続利用 シンプルで強いKafka基盤へ 複雑・重い 運用 シンプル・軽い 運用 インフラコストと運用負荷を同時に削減 API/ツール/クライアントはそのまま Scaling簡単 ◆ Recovery高速 運用負荷削減 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/KE4WKLKZJ1.jpg) （参考）ストレージ / 運用の選択肢 S3 S3互換ストレージ 高い耐久性・低コスト・大容量に最適 ログデータの長期保存に最適 EBS Regional EBS / SSD 低レイテンシを必要とするワークロードに適合 Brokerのメタデータやログに活用 FSx NFS・FSx（共有ファイ ル） マルチAZでの低レイテンシと高可用性を両立 企業システムに適した選択肢 OTel モニタリング＆アラート OpenTelemetry等で統一的に可視性を確保 早期検知と迅速な対応を実現 ワークロード要件に応じて最適な組み合わせを選択可能 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/L71YXLXDJG.jpg)