Kafkaはブローカーの広告アドレス(advertised.listeners)にクライアントが直接接続する設計のため、プライベート接続方式の差異がクライアント到達性とDNS設計に直結します。本稿はAWSのVPC PeeringとPrivateLinkを軸に、Kafkaに適した設計と試験(CCAAK)で問われやすい要点を整理します。
前提として、ここで述べる概念はApache KafkaおよびConfluentの一般的な挙動とAWS公式仕様に基づく安定的な内容です。特定ベンダの最新仕様差分や制約は環境固有になり得るため、導入時は合わせて公式ドキュメントの確認を推奨します。参考: Apache Kafka docs, Confluent docs
Kafkaクライアントは最初にブートストラップサーバへ接続し、メタデータから各ブローカーの広告名(advertised.listeners)を取得して、個々のブローカーへ張り替えます。従って、プライベート接続では「クライアントVPCから全ブローカー広告名/ポートへ私設到達できること」「名前解決が広告名と整合していること」が成功の必須条件になります。
AWSでインターネット非経由の接続を実現する主要選択肢はVPC PeeringとPrivateLinkです。前者はVPC間のL3ルーティングで到達性を作る方式、後者はNLBを介したサービス公開とInterface Endpointを使う方式です。どちらもマネージドKafka(例: Confluent系)や自前運用のどちらにも応用できますが、設計と運用ポイントは大きく異なります。
Kafkaクライアントから見た到達性の要件 (抽象図)
Kafka接続の検証に使う最低限のクライアント設定例
bootstrap.servers=broker-1.aws.internal:9093,broker-2.aws.internal:9093\nsecurity.protocol=SASL_SSL\nsasl.mechanism=PLAIN\nssl.endpoint.identification.algorithm=HTTPS\n# 実環境では認証情報やCAは適切に管理することVPC PeeringはVPC間のプライベートIPルーティングを確立し、双方向通信を可能にします。Kafkaでは各ブローカーのプライベートアドレス(もしくはプライベートDNS名)を広告し、クライアントVPCからルート・セキュリティグループ・ネットワークACLを整合させるのが基本です。
DNSはプライベートゾーン(Route 53 Private Hosted Zone等)を使い、broker-N.aws.internalのようなFQDNを広告名に合わせて解決できるようにします。注意点として、VPC Peeringはトランジティブではなく、CIDR重複も不可です。クロスアカウント/クロスリージョンのピアリングは可能ですが、経路数や制限は設計時に確認してください。
VPC Peeringの通信経路 (概念)
ブローカー側の典型的なlistener設定例 (Peering想定)
# server.properties\nlisteners=SASL_SSL://0.0.0.0:9093\nadvertised.listeners=SASL_SSL://broker-1.aws.internal:9093\nlistener.security.protocol.map=SASL_SSL:SASL_SSL\ninter.broker.listener.name=SASL_SSL\n# DNSはbroker-1.aws.internal -> 10.0.1.10 (例) をPrivate Hosted Zoneで解決PrivateLinkはサービス提供側VPCのNetwork Load Balancer(NLB)を“サービス”として公開し、利用側VPCにInterface VPC Endpoint(ENI)を作って到達性を実現します。重複CIDRや厳格なセグメンテーションが要件の環境で有効です。
Kafkaはメタデータで各ブローカーへ接続し直すため、NLB/エンドポイント設計がポイントになります。一般的には、少なくともブートストラップ用にNLBを用意し、さらにクライアントが取得する広告名がエンドポイント経由で到達できるよう、1ブローカー1エンドポイント(またはそれに相当する名前解決)を整えます。TLSはブローカー終端(パススルー)が多く、NLBはTCP/TLSパススルーとして動作させます。
PrivateLinkを使った到達性 (概念)
広告名をPrivateLinkのDNSに合わせる例
# server.properties (例。実環境のFQDNは環境固有)\nadvertised.listeners=SASL_SSL://b1.plink.example.internal:9093\n# Route53 Private Hosted Zoneなどで b1.plink.example.internal -> vpce-abcde-1.amazonaws.com をCNAMEで解決\n# NLBはb1エンドポイントからブローカー1のポートへ転送どちらも“プライベート接続”ですが、ネットワークモデルが異なるため設計・運用の勘所も変わります。Kafkaでは特にDNSと広告名の整合、そしてクライアントからブローカーへの直収要件が差分を生みます。
試験(CCAAK)観点では、重複CIDRやクロスアカウント要件、DNS/広告名の整合といった設計上のトレードオフを問われやすいです。
| 項目 | VPC Peering | PrivateLink |
|---|---|---|
| 接続モデル | VPC間ルーティング(L3)/双方向 | NLB経由の一方向(クライアント→サービス) |
| CIDR重複 | 不可 | 可(影響を受けにくい) |
| トランジティブ接続 | 不可(個別に張る) | 不可(サービス単位) |
| クロスアカウント公開 | 可 | 可(承認制) |
| DNS要件 | プライベートDNSを共有/関連付け | エンドポイントのPrivate DNSに広告名を合わせる |
| クライアント変更 | 基本的にブローカー名そのまま | エンドポイントFQDNへ切替やCNAMEが必要 |
2方式の比較（抽象トポロジ）
kcatでの接続検証例 (どちらの方式でも有効)
kcat -b broker-1.aws.internal:9093 -X security.protocol=SASL_SSL -X sasl.mechanisms=PLAIN \\\n -X sasl.username=... -X sasl.password=... -L\n# -Lでメタデータを確認し、各brokerの広告名に私設到達できているかを検証管理者視点では、接続方式の違いをKafkaの広告名・セキュリティ・運用に落とし込めることが重要です。特に“クライアントは最終的に各ブローカーへ到達する”という原則を前提に、どの方式でどう名前解決と到達性を満たすかを説明できると強いです。
また、パブリック経路を閉じた状態での証明書検証(ホスト名一致)やACL/認可、セキュリティグループの最小許可の考え方は頻出です。
試験で押さえる論点(箇条書き要約)
- クライアント->ブローカー直収が前提\n- DNSと広告名の一致\n- Peering=ルート/SG/ACL整合\n- PrivateLink=エンドポイントとNLBの対応advertised.listenersの確認コマンド例
# ブローカー上で実効設定を確認 (例)\ncat /etc/kafka/server.properties | grep -E 'listeners|advertised.listeners|inter.broker.listener.name'到達性問題は層別に切り分けます。まずDNS、次にL3到達性、最後にTLS/SASLです。PrivateLinkの場合はNLBのターゲットヘルスとエンドポイントのステータスも確認します。
ConfluentやApache Kafkaのクライアントはホスト名検証が有効なことが多く、証明書CN/SANと広告名の不一致でTLSハンドシェイクが失敗する事象がよくあります。ログでjavax.net.sslやSSLHandshakeExceptionの有無を確認しましょう。
切り分けフローチャート(簡略)
疎通と名前解決の基本コマンド例
dig +short broker-1.aws.internal\nnc -vz broker-1.aws.internal 9093\naws ec2 describe-vpc-endpoints --filters Name=vpc-endpoint-id,Values=vpce-xxxxxCCAAK
問題 1
あなたはAWS上のKafka(複数ブローカー)を別アカウントの複数VPCからプライベートに利用させたい。利用側VPCには既に他システムとのPeeringが多数ありCIDR重複の懸念が強い。クライアントはSASL_SSLで接続し、ホスト名検証を維持したい。最も適切な選択はどれか。
正解: A
CIDR重複を避けたい要件とクロスアカウント公開にはPrivateLinkが適します。Kafkaでは広告名と到達点の整合が必要なため、エンドポイントのPrivate DNSへ整合させる設計が妥当です。PeeringはCIDR重複を許容しません。パブリック経路は要件外。Transit GatewayはL3接続には有効だが重複CIDR問題は残り、KafkaのDNS整合課題も別途解決が必要です。
Confluent CloudでもVPC PeeringとPrivateLinkは使えますか？
主要クラウド上のConfluentのマネージドKafkaでは、アカウント/VPCをまたいだプライベート接続オプションとしてVPC PeeringまたはPrivateLink相当の接続を提供することが多いです。具体的な対応リージョンや制約はプランや時期により異なるため、導入時はConfluentの公式ドキュメントで最新のサポート状況をご確認ください。
PrivateLinkでKafkaを公開する際、TLSはどこで終端すべきですか？
Kafkaの認証/暗号化を単純化するため、一般的にはブローカーでTLSを終端し、NLBはTCP/TLSパススルーとして扱います。これにより証明書のホスト名検証と広告名の整合を保ちやすくなります。
VPC Peeringでうまくつながりません。どこを確認すべきですか？
順に(1) 広告名がプライベートDNSで期待どおり解決されるか、(2) ルートテーブルに相手VPC CIDRへのルートがあるか、(3) セキュリティグループ/ネットワークACLでクライアントのソースが許可されているか、(4) kcatでメタデータ取得時にどのブローカーで失敗するか、を確認してください。
NicheeLab編集部
データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。
Kafka Topic と Partition の基礎: 分散とスケーラビリティの要
CCDAK 対策と実務の両立を意識し、Topic/Partition/Replica/Consumer Group の役...
CCDAK 試験ガイド：出題範囲・配点・申込み・対策
Confluent Certified Developer for Apache Kafka (CCDAK) の出題範囲...
Confluent Certified Administrator (CCAAK) 対策: 出題範囲・配点の考え方・運用観点の要点
CCAAKに向けて、試験領域の押さえどころを運用目線で整理。プロダクションで通用する設定・監視・セキュリティの実践知を、...
Kafka の Replica と In-Sync Replicas を正しく設計する: 耐障害性と一貫性
レプリカとISRの仕組みを起点に、acks と min.insync.replicas、クリーン/アンクリーンリーダー選...
Kafka の Offset とコミット: ポジション管理と at-least-once の基礎
CCDAK 対策と実務の両立を意識して、Kafka コンシューマのオフセット管理とコミット戦略を整理。at-least-...