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 및 실시간 데이터 수집 및 분석에 대한 확장성, 고가용성을 확보하고, 비용 절감까지 이룬 사례로써 활용 가능합니다.
