MSK 비용구조 완전 이해하기
Amzon MSK는?
Amazon MSK (Managed Streaming for Apache Kafka)는 AWS에서 제공하는 완전 관리형 서비스로, Apache Kafka 클러스터를 손쉽게 구축, 운영, 확장할 수 있도록 돕습니다. Kafka는 높은 처리량, 내결함성, 확장성을 가진 오픈 소스 분산 스트리밍 플랫폼으로, 대량의 실시간 데이터를 안정적으로 처리하는 데 사용됩니다.
MSK는 Kafka 클러스터의 프로비저닝, 구성, 패치, 백업, 복구 등 복잡한 관리 작업을 AWS가 대신 수행하여 사용자가 인프라 운영 부담을 줄이고 애플리케이션 개발에 집중할 수 있게 합니다. 또한, 다중 AZ(가용 영역) 배포를 통해 고가용성과 데이터 복원력을 제공하며, CloudWatch, IAM 등 다른 AWS 서비스와 긴밀하게 통합되어 모니터링 및 보안 설정이 용이합니다.
주요 사용 사례로는 로그 및 이벤트 스트림 수집 및 처리, 중앙 집중식 데이터 버스 구축, 이벤트 기반 시스템 구현 등이 있습니다. MSK는 서버리스 옵션도 제공하여 사용량에 따라 자동으로 용량을 조절하며 비용 효율성을 높일 수 있습니다. 직접 Kafka 클러스터를 운영하는 것에 비해 운영 복잡성을 크게 줄이고 확장성을 확보할 수 있는 것이 큰 장점입니다.
브로커 인스턴스 유형과 크기
Amazon MSK는 Kafka 클러스터를 관리형 서비스로 제공해주지만, 클러스터를 운영하기 위해 사용하는 리소스별로 비용이 부과됩니다. 가장 큰 비용 항목은 바로 브로커 인스턴스이며, Kafka 클러스터의 크기와 성능을 결정하는 핵심 요소입니다.
MSK에서 사용하는 브로커 인스턴스는 EC2 인스턴스 기반으로, 선택하는 인스턴스 타입과 크기에 따라 시간당 요금이 다르게 부과됩니다. 예를 들어, Kafka 클러스터를 구성할 때는 최소 3개의 브로커 인스턴스를 생성해야 하며, 인스턴스 유형으로는 kafka.m5.large, kafka.m5.xlarge, kafka.m7g.large 등이 있습니다.
kafka.m5.large는 상대적으로 저렴한 인스턴스 유형으로, 개발 환경이나 소규모 테스트 클러스터에 적합합니다.
kafka.m5.xlarge 이상부터는 더 많은 CPU/메모리를 제공하지만, 이에 따라 시간당 요금도 증가합니다.
kafka.m7g.large는 ARM 아키텍처 기반의 Graviton 인스턴스이며, 동일한 워크로드를 더 저렴하게 처리할 수 있어 비용 최적화 관점에서 추천됩니다.
즉, Kafka 클러스터의 브로커 인스턴스 타입과 사이즈는 MSK 비용의 가장 큰 영향을 미치는 요소이며, 워크로드 성격(메시지 처리량, 파티션 수, 리텐션 설정)에 따라 적절한 인스턴스 타입을 선택해야 비용을 효율적으로 관리할 수 있습니다.
브로커 개수(Replication Factor 포함)의 영향
MSK에서 Kafka 클러스터의 브로커 개수는 단순히 인스턴스 개수만의 문제가 아닙니다. Replication Factor(복제 계수)와 밀접하게 연결되어 있으며, 두 요소는 MSK 비용과 클러스터의 내구성(데이터 안전성)을 동시에 좌우합니다.
브로커 개수와 비용
MSK의 브로커는 EC2 인스턴스 요금으로 과금됩니다. 예를 들어, kafka.m5.large 브로커 3대는 3대 × 시간당 비용 × 사용 시간으로 비용이 산출됩니다. 브로커를 더 많이 생성할수록 처리할 수 있는 메시지 처리량(Throughput)과 분산 처리 능력이 향상되지만, 비용은 선형적으로 증가합니다.
초기 시스템 구축 시 최소 사양으로 시작하는게 좋습니다. 신규 서비스 런칭 시 예상되는 초기 데이터 처리량이 많지 않다면, 최소한의 브로커(예: 3개)로 MSK 클러스터를 구성합니다. 서비스가 성장하고 실제 트래픽이 증가하는 시점에 맞춰 브로커를 점진적으로 확장하여 불필요한 초기 비용을 절감합니다.
또한 피크 타임 트래픽 급증에 대한 대비하는 방안이 있습니다. 사용자 접속이 폭증하여 메시지 처리량이 평소보다 5배 이상 증가하는 온라인 쇼핑몰 시스템의 경우, 평시에는 최소한의 브로커로 운영하다가, 피크 타임 전에 브로커 수를 확장하고 피크가 지나면 다시 축소하는 전략을 사용할 수 있습니다.
개발/테스트 환경에서의 비용 절감개발 및 테스트 환경에서는 실제 운영 환경만큼의 처리량이나 고가용성이 필요하지 않습니다. 따라서 운영 환경보다 훨씬 적은 수의 브로커(예: 2개 또는 최소 권장 개수) 또는 더 작은 인스턴스 타입으로 클러스터를 구성합니다.
Replication Factor와 저장 비용의 관계
Kafka의 Replication Factor는 데이터를 몇 개의 브로커에 복제할지를 결정하는 값입니다. (예: Replication Factor 3 → 동일 데이터 3개 사본 생성) Replication Factor가 높을수록 내구성은 향상되지만, 저장해야 하는 데이터 양이 Replication Factor 배로 늘어나기 때문에 저장 비용이 동일하게 증가합니다.
예로 100GB 데이터를 저장해야 하는 경우, Replication Factor 3이라면 MSK는 총 300GB 데이터를 저장하게 되며, 이에 따라 저장 비용이 3배로 발생합니다. 따라서 Replication Factor를 무조건 높게 설정하면 저장 비용 폭증의 원인이 됩니다.
Broker 개수와 Replication Factor의 조합
Replication Factor는 브로커 수보다 크거나 같을 수 없습니다. 안정성과 비용 간 균형을 맞춰 설정합니다. (예: 브로커 2대일 때는 Replication Factor 3 설정 불가)
Replication Factor 2: 저장 비용은 적지만, 브로커 1대 장애 시 데이터 유실 가능성 존재
Replication Factor 3 (권장값): 안정성 확보, 단 저장 비용이 3배
Replication Factor 4 이상: 특정 금융, 미션 크리티컬 시스템에만 권장. 비용 부담 큼.
EBS 스토리지 용량 및 I/O 요금
Amazon MSK 클러스터에서 발생하는 비용 중 중요한 부분은 브로커별 EBS 스토리지 용량 요금과 I/O 요금입니다. 먼저, EBS 스토리지 요금은 브로커마다 할당된 스토리지 용량(GB)을 기준으로 청구됩니다. 즉, 데이터를 실제로 얼마나 저장했는지와 관계없이, 설정한 용량 전체에 대해 매달 요금이 부과됩니다. 일반적으로 gp2 또는 gp3 볼륨이 사용되며, gp2는 GB당 약 $0.11~$0.12 수준의 요금이 발생합니다. gp3를 사용할 경우, 기본 요금 외에도 IOPS와 Throughput(처리량)을 별도로 설정하면 이에 따른 추가 요금이 발생합니다. 예를 들어, gp3 볼륨에서 1,000 IOPS를 설정하면 약 $0.065의 요금이, 1MB/s 처리량을 설정하면 약 $0.048의 추가 요금이 부과됩니다.
이러한 비용 구조는 Kafka의 토픽 구조와도 밀접한 연관이 있습니다. Kafka는 토픽의 Partition 개수와 Replication Factor(복제 계수)에 따라 데이터를 여러 브로커에 중복 저장합니다. 따라서, Partition이 많거나 Replication Factor가 높으면 저장해야 할 데이터 양이 많아지고, 이로 인해 EBS 스토리지 용량과 I/O 비용이 급격히 증가할 수 있습니다. 또한, Retention 기간(데이터 보관 기간)을 길게 설정하면 삭제되지 않고 저장되는 데이터가 늘어나 비용이 계속 누적됩니다.
이러한 이유로, 비용을 효율적으로 관리하기 위해서는 Retention 기간을 필요 최소한으로 유지하고, 꼭 필요한 데이터만 Kafka에 저장하며, Replication Factor를 적절히 조정하는 것이 필요합니다. 또한, gp3 볼륨을 사용하는 경우에는 IOPS와 Throughput 설정이 지나치게 높지 않은지 주기적으로 점검하고, CloudWatch나 Cost Explorer를 통해 스토리지 사용량과 I/O 패턴을 모니터링해야 합니다.
결론적으로, MSK의 EBS 스토리지와 I/O 요금은 단순히 데이터를 저장하는 비용을 넘어 Kafka의 설계와 운영 방식에 따라 크게 달라질 수 있기 때문에, 비용 절감을 위해서는 데이터 흐름과 저장 전략, 스토리지 설정을 주의 깊게 관리해야 합니다.
Data Transfer 비용
Amazon MSK에서는 Data Transfer 비용이 Kafka 클러스터 내외부의 네트워크 트래픽에 따라 발생합니다. 이 비용은 크게 클러스터 내부 통신과 클러스터 외부 통신으로 나뉘며, 가용영역(AZ) 간 데이터 전송 여부에 따라 추가 과금 여부가 결정됩니다.
먼저, 클러스터 내부 통신의 경우, Kafka 클라이언트(Producer, Consumer)와 브로커 간의 통신이 동일 AZ 내에서 이루어지면 별도의 데이터 전송 비용은 부과되지 않습니다. 그러나 클라이언트와 브로커가 다른 AZ에 위치한 경우에는 AZ 간 데이터 전송 요금이 발생하며, 이는 GB 단위로 과금됩니다. 예를 들어, ap-northeast-2 리전 기준으로 AZ 간 데이터 전송 요금은 GB당 약 $0.01 수준입니다. 따라서 MSK 클러스터를 멀티 AZ로 구성했을 때 클라이언트 또는 워크로드의 배포 위치가 AZ별로 분산되지 않으면, 예상치 못한 데이터 전송 비용이 발생할 수 있습니다.
또한, MSK 브로커에서 클러스터 외부로 데이터를 전송하는 경우, 예를 들어 다른 AWS 서비스(S3, Lambda, Redshift, Elasticsearch 등) 또는 외부 인터넷으로 데이터를 전송한다면, VPC 아웃바운드 요금이 발생합니다. 특히, 인터넷으로 나가는 트래픽의 경우에는 GB당 $0.09~$0.12 수준의 고비용 요금이 적용되므로 주의가 필요합니다. 이러한 비용은 주로 Kafka Connect 또는 데이터 처리 애플리케이션이 클러스터 외부의 대상에 데이터를 전송할 때 발생할 수 있습니다.
반면, 같은 VPC 내, 같은 AZ 내의 통신은 별도의 비용이 발생하지 않기 때문에, Kafka 클러스터의 설계에서는 AZ 간 트래픽을 최소화하고, 클라이언트와 브로커를 동일 AZ에 배치하여 불필요한 데이터 전송 비용을 줄이는 것이 중요합니다.
결론적으로, MSK의 데이터 전송 비용은 클러스터의 멀티 AZ 설정, 클라이언트 배포 위치, 클러스터 외부로의 데이터 흐름에 따라 달라지며, 특히 AZ 간 데이터 전송과 VPC 외부 전송이 비용 폭증의 주요 원인이 될 수 있으므로, 클러스터 설계 단계부터 이를 고려한 최적화 전략이 필요합니다.
Zookeeper 인스턴스 비용
Amazon MSK 클러스터의 Zookeeper 인스턴스는 클러스터 관리와 메타데이터 관리를 위해 자동으로 생성되며, 별도의 인스턴스 비용이 발생합니다. Zookeeper는 Kafka 클러스터의 리더 선출, 파티션 정보 관리, 컨트롤러 역할 등을 수행하는 핵심 컴포넌트로, MSK 클러스터 생성 시 함께 배포됩니다.
AWS에서는 Zookeeper 인스턴스를 사용자가 직접 선택하거나 구성할 수는 없으며, MSK의 클러스터 크기와 구성에 따라 AWS가 자동으로 할당하고 관리합니다. Zookeeper 인스턴스는 Kafka 브로커 인스턴스와 별도의 EC2 인스턴스 비용으로 과금되며, 인스턴스 타입과 수량은 MSK 클러스터의 브로커 개수 및 설정에 따라 AWS가 자동 결정합니다.
예를 들어, 3개 이상의 브로커로 구성된 MSK 클러스터는 최소 3개의 Zookeeper 인스턴스를 기본적으로 할당합니다. Zookeeper 인스턴스 비용은 클러스터의 가용성과 안정성을 위해 생성되며, 별도로 청구 항목(Usage Type)으로 분리되지 않고, Kafka 클러스터 인스턴스 비용에 포함되어 MSK 클러스터 요금의 일부로 통합 청구됩니다.
MSK의 비용 최적화는 브로커 개수, 인스턴스 타입, 스토리지 크기/IOPS가 핵심입니다. Zookeeper는 클러스터의 가용성을 보장하기 위해 최소 필요 수량(보통 3개)과 타입으로 자동 관리되므로 사용자가 컨트롤할 수 있는 대상이 아닙니다. 브로커 수를 줄이면 Zookeeper 리소스도 줄어들 가능성은 있으나, 이는 브로커 비용 최적화의 간접 결과일 뿐 Zookeeper 자체를 대상으로 관리하는 것이 아닙니다.
MSK 비용 최적화는 브로커와 설계 전략에 달려 있다
Amazon MSK는 Kafka의 강력한 스트리밍 기능을 완전 관리형으로 제공해 운영 복잡성을 줄여주지만, 그만큼 브로커 인스턴스, EBS 스토리지, 데이터 전송 비용 등이 복합적으로 누적되어 비용이 쉽게 커질 수 있습니다.
MSK 비용을 절감하기 위해서는 브로커 개수와 인스턴스 타입의 선택이 핵심입니다. 그리고 필요 이상으로 높은 Replication Factor, 과도한 Partition 개수, 장기 Retention 설정 등은 저장 및 처리 비용 폭증의 원인이 되므로 신중하게 관리해야 합니다. 스토리지의 경우 gp3를 활용해 IOPS/Throughput 설정을 주기적으로 점검하고, AZ 간 데이터 전송 비용이 불필요하게 발생하지 않도록 클러스터 및 클라이언트 배치를 최적화하는 것이 중요합니다.
즉, MSK의 비용 최적화는 단순히 리소스를 줄이는 것이 아니라, Kafka 클러스터의 아키텍처와 데이터 흐름을 서비스 성격에 맞춰 설계하고 주기적으로 점검하여 낭비를 없애는 것이 핵심입니다. 이를 통해 비용 효율과 안정성을 모두 확보한 Kafka 운영이 가능해집니다.
