Cloud Tech

AWS 스토리지 이해와 EKS에서 Kafka를 위한 스토리지 고려사항

Hanhorang31 2024. 3. 23. 20:13

 

 

Overview

EKS에서 활용할 수 있는 스토리지 옵션을 확인하고, 스트리밍 플랫폼인 Kafka(카프카)에서 고려할 수 있는 스토리지를 알아보겠습니다.

 

EKS Storage Class

EKS에서는 CSI Driver를 통해 다양한 스토리지를 파드에 적재하여 관리할 수 있습니다. CSI 드라이버(Container Storage Interface Driver)는 쿠버네티스와 스토리지 사이를 제어하는 인터페이스로 다양한 스토리지 시스템과 상호작용할 수 있습니다. 다음의 아키텍처는 EBS CSI Controller를 통해 파드에서 EBS 볼륨을 적재하는 과정입니다.

  1. 특정 클래스를 정의한 PVC를 생성합니다.
  2. EBS CSI Controller가 PVC (특정 스토리지 클래스) 이벤트를 감지하여 EBS 생성, 인스턴스와 쿠버네티스 PV에 연결시켜주고 PVC와 바인드됩니다.

 

쿠버네티스 사용자에서 봤을 때 쿠버네티스 StorageClassName 옵션만 설정하면

자동으로 EBS가 프로비저닝되어 파드에 연결됩니다.

# PVC 생성
cat <<EOT > awsebs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  storageClassName: gp3 # 스토리지클래스 설정 
EOT

kubectl apply -f awsebs-pvc.yaml

 

EKS에서는 AWS에서 제공하는 스토리지를 CSI Controller로 제공합니다.

현재 제공되는 스토리지 서비스는 다음과 같습니다.

  • EBS : 볼륨 스토리지
  • EFS : 파일스토리지
  • Fsx : 파일서버용 스토리지
  • S3 : 오브젝트 스토리지

번외로, 인스턴스 스토어(로컬 볼륨)를 스토리지 클래스로 사용할 수 있는 local-path-provisioner가 있습니다.

 

위 스토리지 연결방식도 간단합니다. 클러스터에 스토리지 CSI controller를 배포하고, 스토리지클래스를 정의하면, PVC에서 해당 클래스를 선택하여 스토리지를 자동으로 구성할 수 있습니다. 아래는 EKS 공식문서를 참고하여 EFS 스토리지를 사용하는 방법입니다.

 

 

PV로 다양한 스토리지를 쓸 수 있는 만큼 특징을 잘 이해해서 쓰는 것이 중요합니다. 다음의 표는 스토리지의 특징을 간략히 정리한 표입니다.

  • Thoughput : 볼륨 처리량입니다. 표에 있는 1000MB는 gp3 볼륨 타입 기준입니다.
  • Access Mode : 노드에 접속할 수 있는 서버 수입니다. Single Node는 1:1, Multiple 은 N(서버):1(볼륨) 로 구성할 수 있습니다.
  • Availability Zone : AWS AZ를 뜻합니다. EFS 만 다중 AZ로 구성하여 스토리지를 사용할 수 있습니다.
  • Integrate S3 : S3 통합 여부 입니다.

 

그렇다면 스토리지를 어떻게 사용하는 지 서비스를 통해 확인하겠습니다.

서비스는 M/L 및 데이터 워크로드 기반의 EKS 프로젝트(DoEKS) 에서 카프카를 참고하였습니다.

 

카프카 스토리지 참고사항 : 인스턴스 스토어, EBS

카프카(Kafka)는 대용량의 실시간 데이터 스트림을 처리하기 위해 설계된 분산 스트리밍 플랫폼으로 데이터 파이프라인 구축, 실시간 분석, 데이터 통합에 사용됩니다. 카프카는 높은 처리량, 확장성, 내구성을 제공합니다. 아키텍처를 보면 그 특징을 이해할 수 있습니다.

위 그림 중앙에 있는 Kafka 서버(Broker)가 분산적으로 메세지를 처리하는데요, 이렇게 분산으로 서버를 구성하면 전체 처리량을 높이고, 단일 실패 지점을 제거하여 내구성을 높일 수 있습니다.

또한, 카프카는 카프카는 디스크 I/O와 네트워크 I/O를 최적화하여 고성능을 제공하도록 설계되어 있습니다. 카프카 성능 고려사항으로 인프라 측면에서도도 고려가 필요한데요. 인프라 중에서도 디스크I/O 측면에서만 고려해보겠습니다.

 

Kafka with Instance Store

카프카의 리소스 병목 현상 사례를 확인하면 대부분의 원인은 네트워크, 스토리지 처리량와 같은 네트워크 연결 스토리지(EBS)를 사용하는 브로커의 스토리지 백엔드와 브로커 간에서 발생한다고 합니다.

 

여기서 필자는 EBS 대신 인스턴스 스토어를 통해 카프카를 구성하면 좋을 것이라 생각했습니다. 성능적으로 일반적인 EBS가 3000 iops인 반면 인스턴스 스토어는 20000 iops가 나올 뿐더러 비용상으로도 fsx와 비교해 저렴했기 때문인데요. 아이디어 검토을 위해 인터넷 검색 중 저와 같은 고민을 기업 블로그 글이 있어 대신 내용을 공유할까합니다.

결론부터 말하자면, 인스턴스 스토어는 데이터가 휘발적으로 노드 축소(ASG)나 이슈시 데이터 손실 문제가 발생하여 EBS 도입을 추천한다는 것입니다. 위 운영 사례로 확인했을 때 성능 대신 내구성을 더 높게 측정하였기 때문인데요. 내구성으로 인스턴스스토어와 EBS의 복원 특징을 비교하면 다음과 같이 확인할 수 있습니다.

  • 인스턴스스토어는 데이터 복원에 전체 데이터를 복원해야 하기 때문에 늦는 반면 EBS는 데이터 차이만 복원하면 되기 때문에 빠르다는 표입니다.

 

 

Kafka with EBS

위 사례처럼 내구성을 고려하여 EBS를 통해 카프카를 구성할텐데요. EBS도 유형이 다양한 만큼 선택에 고려가 필요합니다. DoEKS 카프카 내용을 참고하면 추천하는 EBS 장점과 타입은 다음과 같이 안내되어 있습니다.

 

EBS 사용 장점

  • 유연성 개선 및 빠른 복구: 복제 또는 교차 AZ/리전 복제를 제공하여 가용성이 높습니다. EBS 볼륨의 수명 주기는 카프카 브로커와 독립적이므로, 브로커가 실패하면 실패한 브로커에 연결된 EBS 볼륨을 대체 브로커에 재연결하여 메세지를 처리할 수 있습니다.
  • 규모 확장: 사용 중인 EBS 볼륨의 특성을 수정할 수 있어, 저장 공간을 피크 타임을 위해 미리 확보하거나 추가 브로커를 추가하는 대신 시간이 지남에 따라 자동으로 스케일업할 수 있습니다. (단, 축소는 불가)
  • 워크로드 최적화: SDD, HDD로 나눠 볼륨 타입을 제공합니다. 타입별 Iops와 처리량은 공식문서 볼륨 유형을 참고해주세요.

EBS 볼륨 유형 선택 고려 사항

  • SSD 볼륨(gp3): 균형 잡힌 가격과 성능을 제공하며, 독립적으로 스토리지(최대 16TiB), IOPS(최대 16,000), 처리량(최대 1,000MiB/s)을 프로비저닝할 수 있어 추천합니다.
  • st1: 자주 접근하고 처리량이 집약적인 워크로드를 위한 저비용 HDD 옵션으로, 최대 500 IOPS 및 500 MiB/s를 제공합니다.
  • Zookeeper와 같은 핵심 애플리케이션을 위해서는, 더 높은 내구성을 제공하는 프로비전드 IOPS 볼륨(io2 Block Express, io2)을 사용합니다.

 

개인적으로 EBS 타입간 비용차이는 소폭임으로 범용 SSD인 gp3타입이 좋다고 생각합니다.

카프카 성능 관련 고찰로 플랫폼개발팀 블로그 글을 공유드리니 참고 부탁드립니다.

 

배포

DoEKS에서 제공하는 카프카 예제(Strimzi Operator)를 통해 인프라를 구성하고 카프카 시스템을 확인하겠습니다. 배포는 테라폼을 통해 진행됩니다.

git clone https://github.com/awslabs/data-on-eks.git


cd data-on-eks/streaming/kafka
region = ap-northeast-2 
./install.sh
  • EKS 버전은 1.27, 카프카 차트 버전은 strimzi-kafka-operator-0.38.0 입니다.
  • 인스턴스 EBS 볼륨으로 gp3, 용량이 1000기가로 구성됩니다.
  • r6i.2xlarge 인스턴스가 5대, m5.xlarge 인스턴스가 3대로 구성됩니다. 필자의 경우 비용문제로 r5.2xlarge 3대, m5.xlarge 3대로 구성하였습니다.
  • r6i.2xlarge 인스턴스가 5대로 설정하게 되면 기본 계정 vCPU 제한으로 배포가 되지 않습니다. 꼭 설정해주세요.

 

(번외) 인스토어스토어로 카프카를 구성하려는 경우 ?

스토리지클래스를 선언하고 아래 카프카 클러스터의 PVC 클래스를 변경하면 됩니다. 현재는 gp3로 정의되어있습니다.

 

 

설치에는 20분이 소요됩니다.

aws eks update-kubeconfig --region $region --name kafka-on-eks
kubectl get pods -A
kubectl get nodes -A 

 

노드 볼륨 확인

# 연결된 블록 장치 출력 
sudo lsblk -e 7 -d 
# 디스크 공간 사용량
sudo df -hT 
  • nvme 인터페이스를 사용하는 SSD가 루트 볼륨과 pvc 볼륨으로 2개가 연결됨을 확인할 수 있습니다.
  • 파일시스템 타입이 다양하지만 overlay는 컨테이너가 사용하고, tmpfs는 RAM 사용 영역, xfs 파일시스템 영역으로 분류됩니다.

 

쿠버네티스 볼륨을 확인하면 위에서 마운트된 PVC를 확인할 수 있습니다.여기서는 EBS gp3 타입을 사용하였습니다.

kubectl get pvc -A 
kubectl get storageClass -A 
kubectl get pv -A 

 

카프카 확인

# Strimzi가 관리하는 파드 
kubectl get strimzipodsets.core.strimzi.io -n kafka 
# Strimzi를 통해 생성된 클러스터 
kubectl get kafka.kafka.strimzi.io -n kafka
# Kafka topic 출력
kubectl get kafkatopic.kafka.strimzi.io -n kafka

 

Kafka 예제 Topic를 배포하여 메세지 처리를 확인하겠습니다.

cd streaming/kafka/examples/
# 토픽 생성
kubectl apply -f kafka-topics.yaml
# 토픽 확인
kubectl get kafkatopic.kafka.strimzi.io -n kafka 
----
NAME                CLUSTER   PARTITIONS   REPLICATION FACTOR   READY
my-topic            cluster   12           3                    
my-topic-reversed   cluster   12           3   

이제 창을 두개를 열어 카프카 생상자와 소비자 파드를 생성합니다. 생성 후 임의의 메세지를 입력(밑 화면 오른쪽)하면 소비자 파드에 내용이 출력됩니다.

# 생산자 생성
kubectl -n kafka run kafka-producer -ti --image=strimzi/kafka:0.14.0-kafka-2.3.0 --rm=true --restart=Never -- bin/kafka-console-producer.sh --broker-list cluster-kafka-bootstrap:9092 --topic test-topic
# 소비자 생성
kubectl -n kafka run kafka-consumer -ti --image=strimzi/kafka:0.14.0-kafka-2.3.0 --rm=true --restart=Never -- bin/kafka-console-consumer.sh --bootstrap-server cluster-kafka-bootstrap:9092 --topic test-topic

 

이제 그라파나 대시보드를 통해 카프카를 모니터링하겠습니다.

kubectl port-forward svc/kube-prometheus-stack-grafana 8080:80 -n kube-prometheus-stack

#비밀번호 확인 
aws secretsmanager get-secret-value \
--secret-id kafka-on-eks-grafana --region ap-northeast-2 --query "SecretString" --output text

그라파나 대시보드 항목에 들어가면 카프카 관련 대시보드를 확인할 수 있습니다. 대시보드 중 Zookeeper 에서 카프카 지연을 확인할 수 있습니다.

 

카프카 삭제

카프카 삭제는 다음과 같이 진행합니다.

./cleanup.sh