세션 유형
Break out
세션명
How Samsung modernized architecture for real-time analytics
강연자
Jewon Lee
Head of SmartThings Cloud Engineering, Samsung Electronics
세션요약자
안종규(Jonggyu Ahn)
핵심내용 요약
- 실시간 분석을 위해 스트리밍 데이터 분석 아키텍처를 현대화한 방법을 공유
- Apache Flink용 Amazon Kinesis Data Analytics를 사용하여 자체 관리형 Apache Spark에서 완전 관리형 스트림 처리 플랫폼으로 전환한 방법과 완전 관리형 Kinesis Data Streams 및 Amazon MSK를 사용하여 규모에 맞게 데이터를 안전하게 스트리밍
키워드
- 자체 관리형 Apache Spark
- 완전관리형 데이터 스트리밍 아키텍처 AWS Kinesis
- 데이터 분석 Apache Flink J1
상세내용
Samsung SmartThings
- 수억 명 이상의 사용자와 장치를 지원하는 홈 IoT 플랫폼
- 삼성 Smart TV, 냉장고 같은 직접 연결된 장치 / 허브 연결 장치 / Cloud to Cloud (C2C)로 연결
- IoT 장치에서 전송되는 모든 데이터는 클라우드를 통해 전송
Before Samsung SmartThings 데이터 플랫폼
- 데이터 플랫폼이 데이터 처리를 담당하며, 하루 평균 약 30테라바이트의 데이터를 처리
- Apache Spark 프레임워크를 Apache Hadoop 클러스터 위에서 데이터 처리 엔진으로 사용했으며 이 모든 것은 ec2에서 실행되는 자체 관리형 서비스
- 분산 이벤트 스트리밍 플랫폼은 Spark 앱이 Kafka 또는 Kinesis와 같은 여러 센서 또는 소스에서 데이터를 가져와 ETL을 처리
- 데이터베이스로 Hbase 사용
- SmartThings 사용자의 급격한 증가로 프로세스가 획기적으로 증가하여 챌린지 필요
- 단일 ec2 인스턴스의 동일한 노드에서 원사를 사용하여 Hadoop 클러스터 위에서 실행하는 것은 매우 어렵고, 데이터를 처리하는 동안 지연 및 성능 저하가 발생
- Hadoop 클러스터의 노드 수 증가 및 Spark 오토 스케일링 등 결과적으로 비용 증가
- 한 달 동안 받은 하루 평균 5회 이상의 즉각적인 경고 및 Livy 또는 Yarn 같은 Spark 구성 요소의 오류로 인해 Hadoop에서 중단된 경우의 수치
- 데이터 플랫폼 아키텍처 개선 필요
데이터 플랫폼 이전 프로젝트로 세 가지 목표를 설정
- 비용 효율성 향상
- 안정성과 가용성 개선
- 운영 효율성 향상
인허브, 인 하우스 Hadoop 클러스터 보다 비용이 적게 들고 더 나은 운영 효율성 및 안정성을
보장하는 대안 필요
대체 솔루션 주요 고려 사항
- 초당 수십만 건의 요청을 수신하므로 실시간으로 대규모 처리 가능
- 고가용성으로 쉬운 클러스터 유지 관리. 완전 관리형 솔루션
- 로드 및 애플리케이션이 워크로드에 따라 자동으로 확장 가능. 즉 Auto Scaling 가능
- 고려 사항에 따라 대안 솔루션으로 Apache Spark와 Apache Flink 후보 선정
Apache Flink용 Kinesis 데이터 분석 선택
- 데이터 플랫폼은 실시간으로 데이터를 처리하는 애플리케이션이 대부분이기 때문에 Apache Spark의 마이크로 비트 처리보다 Apache Flink의 실시간 데이터 처리 모델이 더 적합
- 서버리스, 완전 관리형 솔루션, 독립적 작동, 주기적 저장 지점 생성 가능
- Apache Spark to Apache Filnk 마이그레이션
데이터 플랫폼 현재 아키텍처
- 데이터 처리 부분과 데이터 제공 부분
- 이전 아키텍처와 달리 Apache Flink용 Kinesis 데이터 분석으로 대체되고, 들어오는 트래픽은
먼저 Kafka가 관리하고 Apache Flink용 Kinesis 데이터 분석에서 소비 - 데이터베이스와 데이터베이스에 액세스하는 마이크로 서비스에 집계 및 저장
- eks로 컨테이너화되어 데이터 플랫폼의 마이크로서비스 운영
CI/CD 개선
- CI/CD를 단일 워크플로로 결합
- 애플리케이션 코드가 git에 등록되면 CI 도구를 활용하여 자동으로 빌드를 시작
- CI 도구는 배포 작업을 호출하고 Spinnaker는 각 애플리케이션의 Jenkins 작업을 호출하여 Jenkins 서비스가 실행될 때 배포
- 마지막으로 다운로드한 서버 및 구성 파일을 사용하여 Flink 애플리케이션 생성 및 업데이트
개선 사항을 통해 여러 애플리케이션에 동시에 구성을 적용하고, Spinnaker 기반 CD 인프라를
활용하여 배포를 추적
극복해야 하는 세 가지 주요 과제
- Apache Flink용 Kinesis 데이터 분석이 스마트 데이터 플랫폼에 적합하기 때문에 마이그레이션을 결정했지만 마이그레이션까지 이어지는 프로세스가 상당히 복잡
- 1. CPU 사용량에 따라 빠르게 변경되는 Auto Scaling
- 2. Spark와 Flink의 성능 차이
- 3. 스트리밍 데이터의 오프셋을 적절하게 관리
Challenge 1. CPU 사용량에 따라 빠르게 변경되는 Auto Scaling
- 애플리케이션이 15분 동안 CPU를 75% 이상 사용하면 확장하고 6시간 동안 CPU를 10%
미만으로 사용하면 축소하는 로직으로 스케일 인을 결정하는데 시간이 너무 오래 걸리고, 애플리케이션 기반으로 요구 사항을 스케일 아웃할 수 없거나 확장할 수 없다고 생각됨 - 문제를 극복하기 위해 사용자 지정 Auto Scaling을 구축
- Amazon Cloud watch는 CPU 사용을 추적하고 AWS Lambda는 애플리케이션 병렬 처리 값을 변경
- CPU가 스케일 인 또는 스케일 아웃 조건을 놓치는 경우 이러한 구성 요소 및 스케일링 정책을 관리하기 위해 terraform을 사용
- 병렬화 최소 최대 CPU 임계값 등과 같은 쿨다운 값을 설정하여 각 애플리케이션에 대해 서로 다른 확장 정책을 설정 가능. 적합한 자체 확장 정책 설정
- 이벤트 볼륨에 맞게 자동으로 확장할 수 있는 덕분에 궁극적으로 운영 비용을 절감
Challenge 2. Spark와 Flink의 성능 차이
- Apache Flink용 Kinesis 데이터 분석은 Kinesis 처리 장치(kpu)라는 리소스 할당 단위를 사용
- 단일 kpu는 1 코어 4GB의 메모리와 50GB의 트리를 제공
- Apache Flink는 일반적인 스트리밍 데이터 처리 측면에서 Spark에 비해 더 나은 성능을 보이지만 애플리케이션 속성에 따라 Spark 보다 낮은 성능을 보여 후속 조치를 구현
- 첫번째 후속 조치는 Async I/O. Apache Flink는 하나의 이벤트를 차례로 처리하기 때문에 IO
외부 시스템과의 상호 작용이 필요한 경우 비동기 IO를 적용하는 것이 좋음 - SmartThings 데이터 플랫폼이 데이터를 처리하기 위해 다른 마이크로 서비스와 자주 상호 작용하는 것을 고려하여 비동기 IO를 적용
- 두번째는 Flink가 데이터를 하나씩 처리하는 완전한 스트리밍 데이터 처리 방법으로 작동하기 때문에 데이터베이스 일괄 읽기 및 쓰기 적용. SmartThings 데이터 플랫폼은 hbase를 데이터베이스로 사용
- 성능테스트 결과 메모리와 체크포인트 용량이 약간 증가하더라도 각 베이스는 배치 쓰기가 절대적으로 필요하다는 결론
Challenge 3. 스트리밍 데이터의 오프셋 관리
- 일반적으로 SmartThings 데이터 플랫폼에서 Kafka를 사용하여 가져오지만 경우에 따라 kubernetes 및 Kinesis 데이터 스트림을 사용하여 데이터 수집
- Apache에서 Kinesis 데이터 스트림의 데이터를 검색하는 경우 오프셋은 dynamodb에서 관리되지만 Apache Flink에서 개체를 관리하는 것은 Apache Spark를 수행하는 것과 다르기 때문에 주의 필요
- Apache Flink의 Kafka 커넥터는 체크포인트가 저장될 때마다 미리 예약된 Kafka Topic에 옵션을 저장. 오프셋은 Apache Flink의 포인트를 사용하는 경우 세이브 포인트에 저장
- 포인트가 사용되지 않을 때 Kafka 주제의 값 Apache Flink의 클래스 커넥터는 저장 포인트에 완전히 의존하며 dynamodb에 오프셋을 저장하지 않음
- 따라서 Kinesis 데이터 스트림에 대한 데이터를 검색할 때 Apache Flink의 저장 지점 기능을 사용하려면 Apache Flink용 Kinesis 데이터 분석의 스냅샷을 활성화 필요
Impact 1 : 확장성
- 수십 개의 데이터 처리 애플리케이션에 모두 Auto Scaling을 적용하여 트래픽이 4배 증가하더라도 트래픽 증가를 관리할 수 있는 시스템을 구축
- 응용 프로그램 kpu가 사용하는 차트에서 볼 수 있듯이 운영을 위한 인적 자원이 이벤트의 트래픽 패턴에 따라 이동
- 데이터 처리를 위한 리소스가 자동으로 동적으로 확장 및 축소됨을 의미
Impact 2 : 안정성과 가용성
- SmartThings 데이터 플랫폼 실시간 데이터 처리 구성 요소를 서버리스로 마이그레이션하거나 실시간 데이터 처리 구성 요소를 구성하여 작동법의 문제를 해결, 계단식 오류의 근본적인 원인을 제거
- 각 애플리케이션에 대한 독립적인 클러스터로 인시던트가 발생해도 다른 애플리케이션에 영향을 미치지 않아 클러스터가 다운되더라도 안정성을 크게 향상
Impact 3 : 효율성
- 클러스터 노드를 직접 관리할 때 오류 복구에 1시간 이상 걸렸지만 이제는 Application에 할당된 클러스터를 몇 분 안에 복구 가능
- 데이터 처리에 대한 알림이 40% 미만으로 감소했으며, 마이그레이션 후 장애 복구 및 수동 클러스터 복구 사례가 없고, 총 소유 비용 감소
- 컴퓨팅 리소스가 500kpu에서 600kpu로 증가했음에도 불구하고 이러한 효율성 개선으로 전체 운영 리소스를 약 80%까지 크게 감소
- Apache Flink용 Kinesis 데이터 분석을 통해 데이터 플랫폼을 현대화
기대사항
- 과거 Spark 앱을 배포하는데 1분이 걸렸다면, Kinesis 데이터 분석을 사용하면 2~4분이 소요.
Flink 애플리케이션을 훨씬 빠르게 배포할 수 있다면 효율성을 높이는데 많은 도움이 될 듯함 - apache flink용 Kinesis 데이터 분석은 아직 로거 및 kpu 지표에 대해 다른 로그 수준 사용을 지원하지 않음. 이러한 기능의 대부분은 AWS 서비스 팀에서 개발 중으로 알고 있음
Bespin’s Comment
- 유지관리 및 효율성이 중요한 데이터 플랫폼 관련하여 AWS의 서버리스, 완전 관리형 서비스를 활용한 마이그레이션 모범 사례를 확인할 수 있었습니다.
- IoT 및 실시간 데이터 수집 및 분석에 대한 확장성, 고가용성을 확보하고, 비용 절감까지 이룬 사례로써 활용 가능합니다.