Aws Summit Seoul 2024

우아한형제들의 데이터 플랫폼 혁신

Amazon EMR on EKS

EMR이란 ?

Amazon EMR은 Apache Spark, Apache Hive 및 Presto와 같은 오픈 소스 프레임워크를 사용하여 페타바이트급 데이터 처리, 대화식 분석 및 기계 학습을 위한 업계 최고의 클라우드 빅 데이터 솔루션입니다.

사용 사례

빅 데이터 분석 수행

통계 알고리즘 및 예측 모델을 사용하여 대규모 데이터 처리 및 가정 분석을 실행하여 숨겨진 패턴, 상관 관계, 시장 동향 및 고객 선호도를 밝혀냅니다.

확장 가능한 데이터 파이프라인 구축

다양한 소스에서 데이터를 추출하고 대규모로 처리하여 애플리케이션과 사용자가 사용할 수 있도록 합니다.

실시간 데이터 스트림 처리

스트리밍 데이터 소스의 이벤트를 실시간으로 분석하여 장기 실행, 고가용성, 내결함성 스트리밍 데이터 파이프라인을 생성합니다.

데이터 과학 및 기계 학습 채택 가속화

Apache Spark MLlib, TensorFlow 및 Apache MXNet과 같은 오픈 소스 기계 학습 프레임워크를 사용하여 데이터를 분석합니다. 대규모 모델 훈련, 분석 및 보고를 위해 Amazon SageMaker Studio에 연결합니다.

EMR 워크로드를 EKS 클러스터에서 처리

하나의 EMR 워크로드는 다수의 Pod로 구성

EMR 워크로드에 필요한 코드, 라이브러리, 프레임워크는 컨테이너 이미지에 저장

EMRFS/S3를 데이터 저장소로 활용

Spark, Flink 지원

Why EMR on EKS?

EMR ON EKS의 장점

• 빠르고 유연한 컴퓨팅 자원 활용
  • Karpenter를 활용하여 다양한 크기, On-demand/Spot, Gravition 인스턴스를 손쉽게 혼용하여 구성 가능
• 워크로드 통합
  • 하나의 EKS 클러스트에서 다양한 EMR 워크로드 처리 가능

Data on EKS

EKS와 AWS 관리형 서비스의 조합으로 데이터 플랫폼 구축

기존 데이터플랫폼이 마주한 도전

• 비용 증가
  • EMR 고정비용
  • 신규 EC2 타입 미적용
  • 오버프로비저닝
• 낮은 민첩성
  • 불규칙한 대량 트래픽
  • 개발/운영 환경 대응, 자원 경합
• 어려운 유지 보수
  • 태스크별 의존성 주입
  • Security Group 방화벽 설정
  • EMR 버전 업그레이드

컨테이너 환경으로 재탄생

의사 결정, 워크로드 이관 과정

1. 기존 데이터플랫폼 한계점 봉착
   1. 기존 데이터플랫폼의 비용, 민첩성, 유지 보수 측면의 한계점 봉착
2. Airflow 이관
   1. EKS 클러스터로 Airflow 이관 및 Cloud-native역량 확보
3. 데이터 처리 시스템 이관
   1. EMR on EKS를 포함한 데이터 처리 시스템을 EKS 클러스터로 이관
4. 데이터 분석 도구 서빙 API 이관
   1. 데이터 분석 도구 및 서빙 API를 EKS 클러스터로 이관

EMR on EKS 효과

• 비용 개선
  • 상시 운용 노드 불필요
  • Karpenter/Yunikorn으로 효율적 스케일링
• 통합 자원 활용
  • 환경 통합으로 개발-배포 리드 타임 감소
  • 다른 컨테이너화된 서비스들과 통합되고 EKS로 인프라 운용 일원화
• 강력한 자원 격리
  • Pod 기반의 자원 할당으로 작업간 간섭 여지가 없는 강력한 자원 격리

삼성계정은 DR에 진심, 글로벌 리전 장애 조치 아키택처 사례

복원력(Resilience) 이란?

인프라나 서비스의 시스탬 장애를 복구하고, 컴퓨팅 리소스를 동적으로 확보하여 수요에 대응하거나, 구성 오류나 일시적 네트워크 문제와 같은 장애를 완화하는 워크로드의 기능

• 고가용성(HA)
  • 설계와 운영 메커니즘을 통한 일반적 장애에 대한 내성 확보
  • 서비스들, 가용성 목표를 충족시키기 위한 설계
• 재해 복구(DR)
  • 드물지만 큰 영향을 미치는 재해에 대해 특정 목표 내에서 운영 복구
  • ex) 백업 및 복구, 데이터 벙커링, RPO/RTO 관리

The “nines”

9가 늘어날 수록 다운타임 감소 파악하기 쉽게 nine로 표현

가용성 수준	가동율	연간 다운타임	일일 다운타임
1 nine	90%	36.5일	2.4시간
2 nines	99%	3.65일	14분
3 nines	99.9%	8.76시간	86초
4 nines	99.99%	52.6분	8.6초
5 nines	99.999%	5.26분	0.86초

복구시점 및 복구시간 목표(RPO/RTO)

• RPO
  • 재해 발생시 수용 가능한 데이터 손실이 어느정도인가?
• RTO
  • 재해 발생시 수용 가능한 다운타임이 어느정도인가?

재해 복구(DR) 전략

• Active/Passive
  • Backup & restore
    • RPO/RTO - 수시간
    • 우선순위 낮은 유즈케이스
    • 재해 발생 후 전체 리소스 프로비저닝
    • 이벤트 발생 후 백업 복원
    • 비용:$
  • Pilot light
    • RPO/RTO - 수분/수십분
    • 라이브 데이터
    • 서비스 유휴 상태 유지
    • 재해 발생 후 일부 리소스 생성 및 확장
    • 비용:$$
  • Warm standly
    • RPO/RTO - 수분
    • 소규모로 상시 구동
    • 비즈니스 크리티컬
    • 재해 발생 후 리소스 확장
    • 비용:$$$
• Active/Active
  • RPO/RTO - 실시간
  • 무중단
  • 0에 가까운 데이터 손실
  • 미션 크리티컬 서비스
  • 비용:\(\)

주요 정리

1. 기업에 계획되지 않은 다운타임은 재무적 손실과 브랜드 이미지 피해를 줄 수 있음.
2. 이를 방지하기 위해서는 실패에 대비한 복원력 설계가 필요함.
3. AWS의 고가용성과 재해 복구 전략을 적절히 활용한다면, 계획되지 않은 다운타임 발생 가능성을 최소화하고 시스템 복원력을 높여 비즈니스 연속성을 확보할 수 있음.

삼성 계정의 글로벌 Active/Active 아키택처

높은 수준의 DR을 위한 글로벌 Active/Active 아키택처로 고도화

• Action #1: 장애 복구 안정성을 위한 신규 리전 구축
• Action #2: 리전 단위 서비스 형상 일치화
• Action #4: 리전 단위 데이터 동기화

트래픽 전환 제어

대용량 트래픽을 저비용으로 효율적 전환할 수 있는 방법?

1. 글로벌 로드 밸런서 기반 트래픽 전환 제어
2. DNS 기반 트래픽 전환 제어

리전 단위 장애 복구 방식

생성형AI를 엔터프라이즈 비즈니스에 적용하기 위한 실전 방법론

문화적 수준의 기술혁신은 부작용과 순작용이 동시에 존재

• 부작용:암묵적 위험
  • 표준화 부재로 인한 기술 부채 발생 및 silo 현상
  • 대내외 정보 유출 문제
  • 거버넌스 통제력 약화 정보 식별 문제
• 순작용:비즈니스 혁신
  • 개인별 맞춤형 선택지로 (업무 효율 ⇒ 생산성)
  • 비즈니스 경쟁력
  • 신 기술/서비스 역량의 자연스러운 내재화

이미 기술 활용이 문화적으로 안착 상태라면, “관망”에서 “관리”로 전환이 필요

• 이미 어떤 형태로 건 업무에 활용하고 있음을 받아들여야 함 ⇒ 조직 차원의 수용
• 자사 비즈니스에 효과적으로 활용될 수 있게 지원해야 함 ⇒ 자사 데이터와의 결합
• 지속 관리 할 수 있도록 데이터 거버넌스를 확장해야 함 ⇒ 내부의 작은 변화로 부터

세부적으로 3단계로 내부 방향성 권장

1. 문화적 수용 결정
2. Small Success로 경험적 안착
3. 활용/적용 전사 프로세스 지속 확대

단위 기술요소가 아닌, 최적의 추진 방법론이 중요

• 어떤 프로세스에 생성형 AI를 적용하는가?
• 구체화된 흐름과 기능/비기능 요구사항은?
• 해당 프로세스는 어떤 데이터를 활용하는가?
• 대응하기 위한 최적의 기술은?

학습 및 추론, 검색증강

• 생성형 AI가 학습 및 추론해야 할것
  • ex) Code, 친절도, ~23년 데이터, 배워온 형식, 전력, 확률
  • 데이터 라이프 사이클이 충분히 긴 것 (재학습 비용이 큼)
• 검색증강 (RAG) - 찾아봐야하는거
  • ex) 가이드, 메뉴얼, 규정, 정형 데이터 (통계/집계/시스템)
  • 데이터 라이프 사이클이 짧은 것(검색 결과가 충분히 좋을 것)

핵심 포인트

• 프로세스에 맞게 잘 정리된 데이터
  • ex) Amazon S3, AWS Glue, Amazon SageMaker
• 효율적으로 참조할 수 있는 데이터 카탈로그
  • AWS Lake Formation, AWS Glue Data Catalog, Amazon Athena, Amazon OpenSearch Service
• 다양한 생성형AI 모델이 활용 가능한 인터페이스
  • Amazon Bedrock

자문 사례

• 규정집, 메뉴얼 등 문서기반의 대화형AI ⇒ 가장 일반적이고, 쉽게 접근이 가능한 적용 분야
• DBMS를 모르는 현업을 위한 DBMS 자연어 질의 ⇒ 데이터 거버넌스가 되어 있어야 하며, 결과 품질 검증에 기간 소요
• IT부서의 데이터 추출 및 데이터 분석 업무 ⇒ 데이터 거버넌스가 되어 있어야 하며, 시각화 요건에 대한 합의 중요
• 상품 추천, 상품 검색 기능 강화 ⇒ 추천 이후의 고객 인터페이스 강화, 자연어 기반 검색 강화 기능
• 영업일지, 보고서 기반의 비정형 데이터 검색 ⇒ 문서 기반의 검색, 요약으로 쉽게 접근이 가능한 적용 분야

✅ 최종 정리

이번 AWS Summit에 참석하면서, 인프라, 개발을 바라보는 시각이 많이 넓어진것같다. 이해가 가지않던 아키택처들을 보다 깔끔하게 이해할 수 있었다. 또한, 생성형 AI를 통해 보다 효율적이고 창의적인 서비스를 구축 할 수 있다는 점에 신선함을 느꼈다.

수많은 사람들이 여전히 신기술에 관심이 많고, 배우려고하는 의지가 있다는걸 또 다시 느꼈다. 나도 그런 사람들의 일원으로서 앞으로도 꾸준히 배워나가며 성장해야겠다.