스트리밍 데이터
스트리밍 데이터 분석 시스템 요건
-
데이터를 밀리세컨드 이내로 데이터 생산, 전달 및 처리
-
생명 주기가 서로 다를 수 있기 때문에 필요시 데이터에 액세스 할 수 있도록 일정 기간동안 안정적으로 데이터를 보존하여 병렬처리와 여러 애플리케이션이 동시에 액세스할 때 서로 다른 속도로 데이터를 소비하고 처리할 수 있도록 독립처리 지원
-
생성된 순서대로 캡처하여 처리되는 데이터
스트리밍 데이터 분석에 적합한 기술
1. 관계형 데이터 베이스: 병렬 처리에는 좋음 / 비동기식 처리를 하기 때문에 지연이나 순서 보장에는 좋지 않음.
2. 메세지 큐: 병렬 처리 미 지원 / 데이터 순서 보장 불가
3. Hadoop: 지연 시간이 몇 시간 ~ 며칠 걸릴 수 있음 / 병렬 처리 가능 / 데이터 순서 보장 불가
4. 커밋 로그: 병렬 처리 가능 / 데이터 순서 보장
커밋 로그가 스트리밍 데이터 분석에 가장 적합
스트리밍 데이터를 위한 커밋 로그 구조
보통 스트리밍 데이터는 생산자와 Consumer가 여러명으로 구성 된 형태.
프로듀서가 데이터를 생성하고 Consumer가 데이터를 사용하기 위해 아키텍처를 분리하여 프로듀서가 생성한 데이터를 로그에 기록하고 그 로그를 커밋해야 소비자가 데이터를 읽을 수 있다.
커밋한 데이터를 쓰여진 순서대로 저장하여 보관하기 때문에 소비자가 원하는 순서로 데이터를 읽을 수도 있다.
파티션, 샤드: 커밋 로그 여러개를 논리적인 하나의 그룹으로 저장한 것
스트리밍 데이터 분석의 단계
데이터 스트리밍 기술을 통해 다양한 소스의 대용량 고속 데이터를 실시간으로 수집 , 처리 및 분석할 수 있다.
Source: 실시간 데이터를 빠르게 생성하는 디바이스 또는 애플리케이션
Stream processing: 레코드는 생성한 순서대로 소비되어 스트리밍 ETL과 분석을 지원
Stream ingestion: 수만 개의 데이터 소스의 원시 데이터를 실시간으로 수집하고 분석을 위해 준비
Stream storage: 데이터는 쓰여진 순서대로 저장되며 지정한 기간 동안 반복적으로 소비 가능
Destination: 데이터레이크, 데이터 웨어하우스 (일반적), 데이터베이스 (사용 빈도 낮음)
Msk
오픈소스인 Apache Kafka로 스트리밍 데이터를 처리하도록 애플리케이션을 구축할 때 사용하는 완전 관리형 서비스다.
Kafka는 데이터를 생산하는 Producer랑 이를 소비하는 Consumer가 있다.
그리고 Consumer가 생산하는 데이터를 토픽 이라고 한다.
토픽: 데이터를 주제별로 나누어 구분하는 방식. 파티션으로 나누어져 브로커에 분산 저장 됨
브로커: Producer가 전송하는 데이터가 저장되는 곳, Kafka 클러스터의 스토리지 노드라고 보면 된다.
Kafka 클러스터: 둘 이상의 브로커 노드로 구성. 가용성을 위해 기본적으로 브로커들 사이의 데이터 복제를 수행
클러스터에 사용한 복제 옵션에 따라 데이터가 하나의 브로커에 전송하더라도 fail 될 경우를 대비해 여러 브로커에서 데이터를 자동 복제한다.
주키퍼: Kafka 내에 있는 별도 클러스터로, 브로커를 관리한다.
Apache Kafka 운영의 어려움
1.설치와 초기 구성의 어려움
2. 확장의 까다로움
3. 고가용성 확보의 어려움
4. 통합과 연계를 위한 개발 필요
5. 복잡한 관리와 빈번한 장애
6. 높은 유지관리 비용
MSK 주요 기능
1. Amazon MSK - 프로비전
2. Amazon MSK - 서버리스
3. MSK 커넥트
4. 계층형 스토리지
5. 보안
6. 확장성
7. 업그레이드, 파티션 리밸런싱 (서버리스)
8. MSK 커넥트 - Private DNS
9. 모니터링
10. AWS Services와 연계
11. 실시간 분석
12. Glue 스키마 레지스트리
Amazon MSK - 서버리스
- 완전 관리형의 서버리스 방식. 브로커 인스턴스 타입, 갯수에 대한 고민 없이 Kafka 사용 가능
- 서버리스에서 Kafka의 버전도 자동 관리 되기 때문에 기능만 사용하며 사용한 만큼의 비용만 지불하면 됨
Amazon MSK - 클러스터 타입 비교
Amazon MSK 프로비전
- 프로비저닝, 구성 및 튜닝 자동화
- 오픈소스 Apache Kafka와 완벽하게 호환됨
- 다양한 구성 조정 가능
- 높은 보안 수준
- 저렴한 가격
Amazon MSK 서버리스
- 적절한 클러스터 크기를 조정하거나 오버 프로비저닝할 필요 없이 Apache Kafka 클러스터를 쉽게 실행 가능
- 확장성 증가 및 축소에 대해 걱정할 필요 없이 I/O를 즉시 확장
- 파티션 재할당과 확장성 자동
- 처리량 기반 가격 정책
Amazon MSK 커넥트
AWS에서 제공하는 관리형 Kafka 커넥트로 소스 커넥터와 Sink 커넥터를 손쉽게 생성할 수 있는 기능입니다.
- 커넥터의 상태와 데이터 전송 상태 지속적 모니터링 가능
- 처리량에 맞추어 커넥터의 클러스터를 자동 확장 가능
- 커넥터 클러스터를 유지하기 위한 기본적 하드웨어 관리에 신경쓸 필요 없음
- 사용 중인 커넥터가 있으면 플러그인으로 패키징해서 MSK 커넥트에 커넥터로 배포하는 것도 가능함.
Kafka 커넥트: Apache Kafka프로젝트의 무료 오픈소스 컴포넌트, 다양한 방식의 데이터 소스와 시스템 사이에서 데이터 허브 역할을 함
주요 구성 요소 - 소스 커넥터와 Sink 커넥터 2가지
소스 커넥터를 이용하여 외부 시스템의 데이터를 토픽으로 가져올 수 있고 Sink 커넥터를 이용해 토픽의 데이터를 외부 시스템으로 내보낼 수 있다.
Amazon MSK - 계층형 스토리지
- 무제한에 가깝게 확장할 수 있는 Amazon MSK 용의 저렴한 계층형 스토리지
- Apache Kafka 토픽을 더욱 오래 보관하기에 용이
- 기존 스트림 처리 코드를 사용하여 기존 데이터를 정확한 생산 순서로 재처리
- 브로커와 계층형 스토리지 간의 데이터는 VPC 내에서 이동하며 인터넷을 경유하지 않음
- 브로커 간 세컨더리 스토리지의 데이터를 복제하지 않으므로 파티션 리밸런싱이 빠름
- 데이터를 하루 이상 또는 브로커당 1-2 TB 이상 보존해야 하는 애플리케이션에 적합
Amazon MSK - 암호화
AWS KMS(저장 데이터 암호화): Amazon MSK는 Amazon 서버 측 암호화, AWS KMS 서비스와 고객 관리 키를 사용하여 스토리지 볼륨을 암호화합니다.
TLS(전송 데이터 암호화): 전송 중인 데이터를 위한 TLS 암호화는 기본적으로 활성화되어 있습니다.
Amazon MSK - 확장성
클러스터 스케일 아웃 - 클러스터 가용성에 영향을 주지 않고 브로커를 추가하여 기존 클러스터를 확장
자동 확장 스토리지 - 브로커 가용성에 영향을 주지 않고 브로커 연결 EBS 스토리지를 확장
수직 확장성 - Apache Kafka 파티션을 재할당하지 않고도 브로커 사이즈 또는 제품군을 변경할 수 있다.
자동 확장성 - MSK 서버리스는 애플리케이션 처리량이 증가함에 따라 클러스터의 스트리밍 용량을 자동으로 확장
Scale out이라고 하는 브로커를 추가하는 방식의 수평 확장과, 브로커의 인스턴스나 storage 리소스를 변경하는 수직 확장은 주의할 점이 있다.
수평 확장: 가용영역 당 하나의 브로커를 추가하는 것이다.
이미 클러스터가 구성되어있으면 기존 가용영역을 배수에 맞춰서 브로커 개수를 추가하는 게 좋다.
Scale out으로 브로커를 추가할 때 마다 클러스터 내의 파티션 재할당 작업도 필요하다.
클러스터의 브로커 전체에 복제되고 있는 토픽의 파티션들을 새로운 브로커에도 나눠서 분배해야하기 때문이다.
수직 확장: 브로커가 사용하고 있는 인스턴스의 family type이나 사이즈를 변경
브로커의 인스턴스는 스토리지랑 달리 Scale down이 가능하다.
인스턴스 변경 작업 역시 클러스터 영향 없이 백그라운드로 수행된다.
버전 업그레이드에 대해서 지원 날짜가 만료될 때 까지 모든 Kafka 버전을 지원한다.
클러스터를 중단하지 않고서도 Kafka 버전을 업그레이드 할 수 있다.
다운타임 없이 업그레이드가 가능한 경우는 클러스터 모범 사례를 따르고 있다는 가정하에 가능하다.
MSK 클러스터를 시작할 때 Producer나 Consumer 같은 클라이언트는 Kafka 클러스터와 동일한 VPC에 있을 때만 클러스터에 액세스 할 수 있다. 클라이언트와 MSK 클러스터 간의 모든 통신은 비공개, 모든 스트리밍 데이터는 절대 인터넷을 통과하지 않는다. 클러스터와 동일한 VPC에 있는 클라이언트에서 MSK 클러스터를 연결하려면 클러스터의 Security그룹에서 클라이언트 보안 그룹의 트래픽을 수락하는 인바운드 규칙을 추가하기만 하면 된다.
퍼블릭 액세스에 대한 특정 요구 사항이 있는 경우 Kafka 2.6 버전 이상을 실행하는 MSK 클러스터에서 브로커에 대한 퍼블릭 액세스를 활성화할 수 있다.
Amazon MSK - 모니터링
CloudWatch 메트릭: CloudWatch MSK 네임스페이스에서 기본 (무료), 파티션, 브로커 레벨 및 토픽 레벨의 네 가지 모니터링 수준을 설정할 수 있습니다.
프로메테우스를 통한 개방형 모니터링: Prometheus를 통한 개방형 모니터링을 활성화하고 모니터링 기능을 Datadog, Lenses, New Relic and Sumo Logic과 같은 타사 호환 도구로 확장할 수 있습니다.
브로커 로그 스트리밍: Amazon Kinesis Data Firehose를 통해 브로커 로그를 Amazon CloudWatch
Logs, S3 또는 OpenSearch 서비스로 지속적으로 스트리밍합니다.
MSK 클러스터 CloudWatch 모니터링 지표
1. CpuSystem, CpuUser: 커널 공간, 사용자 공간에 있는 CPU의 백분율
2. RootDiskUsed, KafkaDataLogsDiskUsed, KafkaAppLogsDiskUsed: 브로커가 사용하는 루트 디스크의 백분율, 클러스터의 데이터 로그, 애플리케이션 로그에 사용된 디스크 공간의 백분율
3. NetworkRXpackets, NetworkRXerrors: 브로커에서 수신된 패킷 수, 브로커에 대한 네트워크 수신 오류 수
4. NetworkTXpackets, NetworkTXerrors: 브로커가 전송한 패킷 수, 브로커의 네트워크 전송 오류 수
5. GlobalTopicCount: 클러스터의 모든 브로커에 있는 총 토픽 수
6. PartitionCount: 복제본을 포함하여 브로커당 총 토픽 파티션 수
7. UnderReplicatedPartitions: 브로커에 대해 복제가 덜 진행된 파티션 수
MSK 모범사례
적절한 클러스터 규모 조정
- 그냥 lift and shift하지 마라. Amazon MSK 모범 사례를 가이드라인으로 사용
- MSK 클러스터에 적합한 브로커 수를 결정하고 비용을 이해하려면, MSK Sizing and Pricing 계산기를 사용하라.
적절한 구성 파라미터 설정
- 지연 시간/처리량, 내구성 및 가용성 요구 사항 관련 가이드된 튜닝 파라미터를 사용하라.
- 철저히 테스트하라.
Zookeeper 사용을 Amazon MSK로 제한
- MSK 프로비전 Zookeeper에 non-MSK 브로커 또는 애플리케이션 구성 관련 메타 데이터를 추가하지 마라.
데이터 보관기간 파라미터 조정
- 필요에 따라 클러스터 및 토픽 레벨에서 보관 기관 또는 보관 로그 크기를 미세 조정하라.
- 데이터 보관 기간을 늘리려면 계층형 스토리지 기능을 사용하라.
디스크 사용
- CloudWatch에서 KafkaDataLogsDiskUsed 지표를 모니터링할 수 있다.
- 85% 사용률로 알림 설정하라.
- 알람이 울리면 브로커 스토리지를 늘려라.
- 토픽의 보관 기간이 적절한지 확인해라.
파티셔닝
- 일반적으로 파티션이 많을수록 처리량이 늘어난다.
- 브로커 당 전체 파티션 수 < 4000
- 경험적으로, 토픽 당 파티션 수는 토픽 당 최대 인제스트 속도 (초당 MB)/2
- 또는 각 컨슈머가 각 파티션 당 지원할 수 있는 처리량을 알고 있다면 이를 분모에 사용하라.
- 따라잡을 수 있는 충분한 능력이 있는지 확인해야 한다는 점을 명심해라.
