Kafka運用をシンプルにするには？

>100 Views

September 07, 26

スライド概要

profile-image
スライド一覧

Kafkaの課題は、Kafkaそのものではなく、運用とコストにあるのかもしれません。 K・D・Cloudでは、既存のKafkaエコシステムとの互換性を維持しながら、よりクラウドネイティブでシンプルなストリーミング基盤への最適化を支援しています。重要なのは、単に「新しい製品へ移行すること」ではありません。 現在のKafka、Amazon MSK、Confluentなどの環境を前提に、本当に見直す価値があるのか。 どこにコスト削減余地があるのか。性能や可用性を維持しながら、運用負荷を下げられるのか。 まずはこの3点を整理することが重要だと考えています。 そのうえで、必要に応じてアーキテクチャ評価、PoC、移行、導入後の日本語サポートまで対応します。 Kafkaやストリーミング基盤について、「今すぐ刷新するつもりはないが、現状が最適なのか一度確認したい」という段階でも問題ありません。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

slide-thumbnail

HRBrain 会社説明資料
user-img HRBrain採用 1.3M
slide-thumbnail

イケてる起業の進め方
user-img 北原麦郎 1M
slide-thumbnail

ウェルスナビ会社紹介資料
user-img ウェルスナビ株式会社 0.9M
slide-thumbnail

見やすいプレゼン資料の作り方[ドクセル版]
資料 デザイン 資料作成 powerpoint keynote slide design
user-img モリシゲ 869K
slide-thumbnail

iCAREBOOK
icare 採用 カルチャーデック 採用資料
user-img iCARE,Inc 727.8K
slide-thumbnail

【カカクコム】会社説明資料
user-img カカクコム採用担当 664.1K
各ページのテキスト
1.

Kafka運用をシンプルにするには？ ― ストレージ分離で変わる Scaling・Recovery・運用負荷 2026.09.04 蘇 躍君 / K・D・Cloud株式会社 1

2.

自己紹介 蘇 躍君 K・D・Cloud株式会社 代表取締役 / Cloud Solutions Architect AWS 2024 / 2025 Japan AWS All Certifications Engineers 現在の取り組み ● リアルタイムデータ基盤の技術課題 Kafkaを中心とした技術課題に対するソリューション設計・提案 ● 主なテーマ Scaling・Recovery・運用負荷・コストの改善 ● アーキテクチャ Cloud Native Architecture / Compute-Storage Separation の活用 2

3.

企業がKafka運用で直面している課題 ビジネスの成長に伴い、Kafka基盤の運用はますます複雑になっています 急増するデータ量 とキャパシティ計画 ↻ ◆ $ Scalingのたびに 発生するデータ移動 障害時の復旧が重い コストと運用負荷 が高止まり ・データ量の予測が難しい ・Partitionの再配置 ・Broker障害でリーダー再選出 ・Cross-AZのデータ転送 ・将来を見越した過剰なリソー ス確保 ・大量のデータコピー ・データ同期（Replicaコピー） ・ディスク/ノードの無駄 ・長時間のRebalanceで性能に 影響 ・復旧までに時間がかかり、 SLAに影響 ・監視・チューニング・障害対 応が必要 ・投資効率が悪化 根本原因の一つは「Broker（Compute）とStorageの強い結合」 3

4.

従来の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

5.

なぜ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

6.

なぜ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

7.

アーキテクチャの変革：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

8.

変革によって得られる効果 ◆ Scalingが圧倒的にシンプル Recoveryが高速で確実 運用負荷とコストを削減 ・データ移動なしでBroker追加/削除 ・Broker障害時も即座に再起動 ・Cross-AZ転送コストを大幅削減 ・秒単位でスケールイン/アウト ・データ同期が不要 ・ストレージコストを最適化 ・Rebalanceが不要 ・短時間で復旧完了 ・設計/チューニングが簡素化 ・ビジネスへの影響を最小化 ・SLAを安定して維持 ・運用チームの負荷を軽減 Kafkaの互換性を保ちながら、クラウドネイティブな次世代基盤へ 8

9.

まとめ ストレージ分離がもたらす本質的な変化 ✓ 根本原因の解消 ComputeとStorageの分離が、Kafka運用の根植えとなる課題 を解消 ✓ ビジネス俊敏性の向上 迅速なScalingと高速なRecoveryで、変化に強いデータ基盤 を実現 ✓ コスト最適化と運用簡素化 ✓ 今あるKafkaエコシステムを 継続利用 シンプルで強いKafka基盤へ 複雑・重い 運用 シンプル・軽い 運用 インフラコストと運用負荷を同時に削減 API/ツール/クライアントはそのまま Scaling簡単 ◆ Recovery高速 運用負荷削減 9

10.

（参考）ストレージ / 運用の選択肢 S3 S3互換ストレージ 高い耐久性・低コスト・大容量に最適 ログデータの長期保存に最適 EBS Regional EBS / SSD 低レイテンシを必要とするワークロードに適合 Brokerのメタデータやログに活用 FSx NFS・FSx（共有ファイ ル） マルチAZでの低レイテンシと高可用性を両立 企業システムに適した選択肢 OTel モニタリング＆アラート OpenTelemetry等で統一的に可視性を確保 早期検知と迅速な対応を実現 ワークロード要件に応じて最適な組み合わせを選択可能 10

11.