AWS 2024 Summit Seoul

2024/05/16(목) AWS Summit

데이터 처리도 이제는 컨테이너로, 우아한 형제들의 데이터 플랫폼 혁신

컨테이너로 데이터 처리하기

• 데이터 처리의 어려움

  • 인프라 구성
  • 다양한 데이터 포맷, 프레임워크
  • 급격한 데이터량 증가
  • 빠르게 변화하는 비즈니스

• 컨테이너와 데이터 처리를 결합한다면?

  • 이미지 기반으로 쉽게 패키징할 수 있음
  • 컴퓨팅 작업을 빠르고 유연하게 확보할 수 있음

• 대표적인 방법: EMR on EKS

  • 특징
    • 하나의 EMR 워크로드를 다수의 Pod로 구성
    • EKS 워크로드에 필요한 코드, 라이브러리, 프레임워크를 컨테이너 이미지에 내장
    • EMRFS/S3를 데이터 저장소로 활용
    • Spark, Flink 지원
  • 장점
    • 빠르고 유연한 컴퓨팅 자원 활용 (Karpenter 활용)
    • 하나의 EKS 클러스터에서 다양한 EMR 워크로드 처리 가능
    • 다양한 오픈소스와 결합 가능
      • AI: mlflow, kuberay
      • 데이터 처리: EMR, trino
      • 노트북: jupyterHub, Zeppeling
      • 스케줄러: YuniKorn, Volcano
      • 워크플로우: Airflow 등

우아한 형제들의 데이터 플랫폼 소개

• 우아한 형제들은 추천 서비스, 리뷰 관리, 그 외 수많은 자동화를 위해 데이터를 활용하고 있다.
• 하루에 10억건 이상(1TB)의 로그를 관리, Airflow에서 700개 이상의 태스크 수행, 분석 클러스터 쿼리 4만개 이상..

컨테이너 기반 데이터 플랫폼 구축 여점

• EC2 기반 플랫폼의 한계

  • 비용 증가: EMR 고정 비용, 신규 EC2 타입 적용 어려움, 오버 프로비저닝
  • 낮은 민첩성: 불규직한 대량 트래픽, JVM 자원 경합
  • 어려운 유지 보수: 태스크별 의존성 주입, sg 및 방화벽 설정, EMR 버전 업그레이드

• 이관 과정

  • 한계점 봉착으로 Airflow 이관
  • EMR on EKS를 포함한 데이터 처리 시스템 이관
    • Spot Instance와 EKS 사용했을 때 보다 3~4배 퍼포먼스 차이 있었음, 최적화 되어있음
  • 데이터 분석 도구 및 서빙 API를 EKS로 이관

• 구조

  • 인프라: Loki와 Prometheus를 기본적으로 사용(Woowacat), ArgoCD, Karpenter, KEDA
  • 파이프라인: Apache Airflow
  • 프로세싱: EMR on EKS, Trino , Flink, Kafka connect
  • BI/분석: Tableau, Reash 등

• 효과

  • 비용 개선: 상시 운용 노드 불필요, Karpenter/Yunikorn으로 효율적 스케일링
  • 통합 자원 활용: 환경 통합으로 개발-배포 리드 타임 감소
  • 강력한 자원 격리: Pod 기반 자원 할당으로 자원 격리

분석 환경 고도화를 위한 노력

• Yunikorn 적용

  1. 반복적인 VPC 서브넷 고갈(Pod마다 IP 할당해야해서..)
     • 단순히 서브넷을 크게 해서 해결할 수 있는 문제가 아님.
  2. 단일 작업이 여러 AZ에 퍼져 처리 속도가 낮아짐
  3. 각 Job에 필요한 리소스가 각각 충족되지 않아 제대로 실행되지 않음 (Gang 스케줄링으로 해결)
  4. 노드에 비는 자원이 생김 (Bin Packing)

• Airflow 기반 셀프 서비스

  • 공용 개발 환경의 문제점

    • DAG 의존성/패키지 충돌, 데이터 오염
    • 브랜치 전략 적용 불가능
    • EMR on EKS는 Virtual Cluster이기 떄문에 프로비저닝 타임 없이 개인 환경 분리 가능

  • On-demand 개인 전용 환경 제공

    • Custom Resource 구성
    • 사용자마다 개별 “git branch sync”로 개발중인 DAG 연동

  • 고도로 추상화된 작업 제출

    • 사용하기 복잡한 부분을 추상화 하여 쉽게 서러정할 수 있도록 했다.
    • EMR Contianers API 기반
    • Metric 기반 동적 자원 할당

  • 모니터링 환경 구축

    • Spark History 서버로 클러스터 작업 이력 통합
    • Job Runner, Spark Driver/Executor의 로그 및 시스템 메트릭을 Prometheus로 통합

• EMR 컨테이너 이미지 관리

  • 커스텀 EMR 컨테이너 이미지 관리를 위한 CI/CD 운영
  • 작업 환경별 이미지 생성/활용

미래 전략 및 마무리

• Remote Shuffle Service를 활용

  • Shuffle 데이터 있는 노드가 작업 끝낼 때 까지 대기하는 기능
  • Shuffle 서비스는 정보가 모였다 흩어지기 때문에 I/O 성능 좋은 노드를 사용하는 게 중요한데, 이 기능을 AWS가 곧 지원할 예정이라고 함.

• In-place 리소스 할당 조정

  • Pod 재생성 없이 다이나믹하게 Pod 크기를 조정

• 권한/인증 개선

  • 데이터 조회시 Trino, Ranger를 활용하여 접근 권한 제어 및 마스킹 작업 진행
  • EMR on EKS는 AWS Lake Formation을 활용한 권한 제어 예정

• EKS Anyware

  • IDC(온프레미스)에 EKS Anywhere 클러스터 구축
  • 연산 작업이 많은 워크로드는 EKS Anywhere에서 처리 수행
  • EKS Any where는 AWS의 IAM Rolw과 연동하여 Seamless하게 활용 하는

• 마무리

  • 데이터 처리를 위해 EMR on EKS를 활용하여 비즈니스 민첩성 확보, 안정성 확보, 데이터 기반 의사 결정을 개선할 수 있었다.

넥슨의 LLM 에이전트 길들이기: 인프라 모니터링 서비스 적용 사례

Bedrock

• LLM은 단순히 문서 요약, 검색, 계산을 수행하는 솔루션이 아니라 생각하는 기계다.

  • LLM의 사고 능력은 산업계의 다양한 실제 문제를 해결하는데 적극 활용되고 있다. (여행 계획, 프로그래밍, 데이터 분석)

• Bedrock 서비스는 LLM을 비롯한 여러 파운데이션 모델로 생성형 AI 애플리케이션을 쉽게 구축하고 확잘할 수 있다.

  • 자체 데이터를 활용해 맞춤형 모델을 생성할 수 있고, 엔터프라이즈 수준의 보안을 보장받는다.

넥슨이 개선하고 싶은 문제

• 내부용 백오피스 서비스 다수 운영

• 서비스 별 담당자 정보와 매뉴얼 최신화 문제

• 이슈 발생시 개별로 확인 -> 많은 시간 소요

• 연관 정보를 한번에 쉽게 조회할 수 있다면?

  • 챗봇 인터페이스에 관심을 갖게 됨

• AWS의 Professional Service 지원을 받아 LLM 챗봇을 개발했다.

• Javis처럼 스스로 상황을 파악하고 최적의 답변을 내놓는 수준을 기대

  • 현실적으로는 복수의 서비스를 서로 연동하여 의미있는 답변을 나타내는 챗봇을 구현하기로 함

매트릭 데이터 분석 챗봇

• 포맷이 다양한 다른 데이터보다 간단하게 적용 가능하기에 메트릭 데이터에 대한 챗봇을 첫 목표로 잡았음

• 서비스앱 활용하여 서비스간 정보를 연동

• 사용자 접근성을 유지하기 위해 LLM 챗봇 형태로 구현

• 여러 과정의 스프린트를 진행하며 속도, 정확도, 비용을 개선해나감

• 만족스러운 점

  • AWS 가이드와 긴밀한 협업으로 TF에 참여한 담당자의 역량 향상과 노하우 습득

• 아쉬운 점

  • 기대에 못 미치는 답변 품질
  • 서비스간 연결을 위한 Key Data가 필요했다.

챗봇 준비

• 목적

  • 데이터간 연결고리를 자동으로 확보해야 한다.
    • 엔지니어-서비스-호스트-메트릭을 식별해야함
  • 변경된 정보가 즉시 반영되어야 한다.
  • 다양한 형태로 표현해야한다.

• 실시간 메트릭을 반영하여 답변해야하기에 파인튜닝은 적합하지 않음

• 따라서 Bedlock으로 모델 구성, LangChain으로 프롬프트 엔지니어링 했음

ReAct 프롬프팅

• 작업 실행 후 실행 결과를 주입하는 방법론

  • LangChain에서 주입 기능을 지원해줌 (문서)

• ReAct로 초기 구성하였음

  • 기능은 충분하지만 응답 지연 및 환각 문제 발생

이슈 및 해결

• Latency 문제

  • 응답 지연은 토큰의 양과 LLM 호출 횟수에 영향 받음
  • 반복 주입마다 Latency가 늘어남
  • -> 반복 빈도 최소화

• Hallucination 문제

  • 입력이 길고 대화 텀이 많아질수록 전체 텍스트가 적절히 처리되지 않음 (질문 의도가 희석)
  • -> 모델 분리 검토
    • Claude 2.1은 품질이 높고, Claude Instance는 빠르니 둘을 작업 단위로 섞어쓰자.

• Multi Agent

  • 역할별 임무 부여: 각 역할에 특화된 세가지 모델 분리
    • Persona 부여, 대화 및 의도 파악, 저장
    • ReAct Agent, 도구를 이용한 data 조회
    • API RAG 등의 정보 전달 서비스
  • 팁
    • @mention 기능으로 다음 대화 상대를 결정
    • Return Direct 과정으로 역할 외 과도한 개입 제한

• Plan And Execute

  • 초기 계획에 큰 리소스 투자가 필요
  • 실행간 결과 공유
  • 반성을 통해 더 완별한 Plan 완성
  • LangChain의 RumManager로 개선 가능

• Task Tools

• 기타 기법

  • Intent 분석
    • 사용자의 발화에서 목적이나 의도를 확실하게 파악
  • Slot Filling
    • 부족한 정보 재질의
  • Stream
    • 스트림 레이턴시 감소

결론

• 아직 레이턴시와 비용이 좋은 수준은 아니지만, 앞으로 어떻게 나아가야할지 알게 됨
• 아 레이턴시랑 정확도 아쉽다~
  • 내일은 LLM 모델이 알아서 더 빨라지지 않을까? ㅋㅋ
  • 그 일이 실제로 일어났습니다. 인공지능 모델의 발전이 정말 빠르게 이뤄지고 있다.
• • AI를 활용하여 개발할 때에는 변화에 능동적으로 대응하며 미래 방향성을 확립해야한다.

디지털 자산 플랫폼으로의 첫 걸음, 토큰증권 시스템 on AWS

토큰 증권이란 무엇인가?

• = 블록체인으로 발행하는 증권

• 전세계적으로 발행된 토큰증권의 시가총액은 약 23조원

• STO(Security Token Offering)

  • 증권 토큰 발행의 약자
  • 분산원장 기술을 기반으로 디지털화딘 자본시장법 상 증권을 발행하는 것을 뜻함
  • ICO와 IPO의 중간 단계

• 투자 계약 증권

  • 다른 사람이 하는 공동사업에 금전 등을 투자하고 결과에 따라 손익을 귀속 받는 권리가 표시된 것

• 예전에는 종이로 실물 증권을 가지고 있었는데, 현재는 전자 증권이 발전되었다.

• 이때 증권 데이터를 하나의 중앙 시스템에 기록하지 않고 분산 원장에 기재하는 것이 바로 토큰증권 기술이다.

• 토큰증권을 발행하면 자회사 할인으로 돈이 이동하는 절차에서의 문제없이 바로 자금을 전달할 수 있다.

• STO를 통한 경쟁 구도의 변화

  • 기존의 증권사는 상장된 상품을 동일하게 팔았지만, STO가 도입되면 증권사가 차별화된 상품, 마케팅으로 증권을 발행할 수 있다.

• 바뀌게될 점

• 금융 상품, 증권 발행, 자산 유동화 혁신

• 사고의 변환: 주식 -> 코인

• 영화관은 의자, 환경을 기준으로 마케팅하지만 OTT는 컨텐츠를 기준으로 마케팅하는 것 처럼,

토큰증권 동향 분석

• 22년 토큰증권 발행 체계 정비 방향을 발표했다. 금융위원회는 2024년 본격적 제도 시행을 목표로 관련 법안을 정비 중
• 토큰증권 정책의 핵심 방향은
  • 발행은 발행인 또는 계좌관리자가,
  • 유통은 KSD의 심사와 관리를 거쳐 KRX에서 하는 것임
• 증권사들은 신규 사업기회로 토큰증권을 선정하여 관련 사업 준비에 박차를 가하고 있음
• 토큰증권 시장 선점에 대한 금융권 니즈가 커져, 대형 증권사를 중심으로 은행, 통신사 등 유관 기업들이 모여 다양한 ‘토큰증권 협의체’가 구성되고 있음

토큰증권 추진 고려사항

• 토큰증권 사업은 전통 자산 시장에서 디지털 자산 시장으로 진입하는 기반을 확보할 마중물이다.
• 기존 주식 업무와 비슷하지만, 토큰증권은 사진, 미디어 등 다양한 대상으로 발행되기에 그러한 특성을 고려해야함

• STO 사업모델은 어떻게 가져가야하는가?

  • 발행형: 자체/발행대행에 의한 상품발행 모델
    • 초기 시장선점을 위하여 고객 니즈에 맞는 상품 선점 및 발국ㄹ 역량이 필수적
  • 유통형: 타사상품 유통(매매) 모델
    • 초기 시장 형성에 따라 유통 시장 규모를 고려해야함
    • 각 사별 다양한 블록체인 표준에 유통
    • 플랫폼의 기술적 인터페이스 방안 수립 및 실제 구현 필요
  • 혼합형: 상품 발행 및 타사 상품 유통 매매 혼합 모델
    • 초기 사업투자비용이 가장 많이 투자됨에 따라 모델 준비 필요

• 아키텍처 구현 방향은?

  • 기존 Lagacy와의 호환 위해 Middleware로 처리
  • 공동망 노드 구성하는 경우도 있음
    • 공동 분산원장 설치/운영을 위한 별도의 전산센터 또는 클라우드 환경 도입 필요
  • 클라우드 도입 시 노트간 연결 위한 전용선 설치 수량 감소로 인한 비용 절감
  • 동일 환경 내 설치로 합의 알고리즘 소요 시간 감소 예상

• 토큰증권 플랫폼 사업 추진 방식은?

  • 토큰증권은 기존과 다르게 새로운 생태계를 만들어 각자 마케팅 요소, 차별점을 만들어야 한다.
  • 시스템 관점의 MVP 설계 필요
  • 토큰증권은 Calu-chain 모델이 아닌 앞으로 확대된 디지털 시장으로의 진출을 위한 교두보
  • 예측이 어려운 장외거래시장 수요 대비 및 블체 기술의 성능적인 한계에 대한 대비 필요
  • 클라우드 도입을 통한 성능 안정성 및 비용 효율성 확보 필요
  • AWS는 금융평가원 안전기준을 통과하였기 때문에, 토큰증권 플랫폼 구축시 사용하면 좋다.

그립의 클라우드 거버넌스와 로그 분석 혁신

비즈니스 성장과 다중 계정 관리의 중요성

• AWS Control Tower: 다중 계정 설정을 자동화 하는 서비스
  • 다중 계정을 관리해야할 때 아래와 같은 어려움이 있다.
    • 소수의 인프라 인력으로 많은 계정 및 자원 관리를 수행해야함
    • 효율적인 서비스 통제 및 운영 환경 보안 유지가 어려움
    • 클라우드 운영 및 관리가 어려움
  • Control Tower를 사용하면 다중 계정 환경의 설정을 자동화한다.
  • 제공 기능:
    • 자동 계정 생성
    • 보안 가드레인
    • 통합 사용자/권한 관리
    • 규정 준수 상태 모니터링을 위한 대시보드

• AWS Solution Library:
  • 즉시 배포 가능한 소프트웨어 패키지, 사용자 지정 가능한 아키텍처를 제공
  • 비즈니즈 요구사항 충족을 위해 적은 시간만 들여도 됨.

그립 컴퍼니 소개

• 이커머스 라이브 플랫폼
• 작년 5월에 AWS 마이그레이션을 했다.
  • AWS Native 솔루션을 사용하여 거버넌스 및 모니터링 체계를 구성하기로 결정

ISMS 도전과제 및 해결방안

• 매출액이 100억 이상인 경우 ISMS-P 심사 대상
• AWS 기반의 거버넌스 및 모니터링 방안 마련 필요

거버넌스 체계 구성

• Control Tower 활용

  • 계정 분리
  • AWS IAM Identity Center
  • 중앙 집중적 네트워크 관리 체계
  • Guardrail
  • ISMS 심사 대비에 유용함

• 계정을 용도별로 나눠서 쓰고 있다.

• IAM Identity Center

  • 용도별 그룹 생성
    • 그룹에 권한 및 계정 매핑
    • 개인은 용도에 맞는 그룹에 할당
    • 그룹 생성은 팀/사용 용도/권한을 고려하여 생성
  • 부득이한 경우에 (EKS 사용 권한 부여 또는 특정 서비스 사용하는 경우에) 인라인으로 추가하기도 함

• Network 계정에 Transit Gateway를 띄우고 라우팅 테이블을 세세하게 설정해놓았음

• CfCT를 활용한 K-ISMS 팩 적용

• Service Catalog
  • 템플릿처럼 저장, 프로비저닝할 수 있었다.

로그 모니터링 여정

• WAF, Confg, CLoudTrail 등 AWS native 보안 서비스에 대한 통합 모니터링 부재

• 다중 계정 체계 적용으로 보안 현황을 계정 별로 봐야되는 불편함 발생

• Centralized Logging with Open Search:

  • 다중 계정을 지원하는 로그 시스템, 계정간 로그 수집 기능 제공
  • OpenSearch 기반
  • 대시보드가 제공됨
  • 쉬운 보안 서비스 로그 Pipeline 설치
  • AWS 서비스 로그 뿐만 아니라 애플리케이션 로그까지 자동 수집 가능

야놀자의 글로벌 신규 사업 진출 및 확장 노하우

야놀자와 AWS의 글로벌 협업

• 파트너 유형 5개

  • 서비스 파트너
  • 디스트리뷰션 파트너
  • 하트웨어 파드너
  • 트레이닝 파트너
  • 소프트웨어 파트너 <- 야놀자는 여기에 해당함

• 아놀자의 B2B

  • 숙박 업소의 광고, 숙박업소 관리 등을 도와주는 SaaS 서비스를 하고 있음

• AWS가 글로벌 진출을 어떻게 도움?

  • 기술을 검증해줌 (AWS Solutio Architect)
  • 전문성을 인증해줌 (Trabel & Hospitality Software)
  • AWS 세일즈 네트워크를 활용한 글로벌 시장 진출 가속화 (오..?)

글로벌 여행 산업을 주도하는 야놀자

• 현지 서비스 인수를 통한 성장
• 하지만 현지 서비스는 가격 구조, 정책이 각각 다 다르다.
• 그걸 통합해서 제공하는 솔루션을 만들자는 아이디어로 사업을 확장했음
• 현재는 해외에서 발생하는 거래의 비율이 많이 높아졌다.

야놀자의 글로벌 사업

• 온 프레미스는 힘들더라.
  • EC2, S3, Aurora, ECS, SES를 쓰고 있다.

글로벌 확장을 위한 야놀자의 전략 방향성

• 여행을 더 쉽고 빠르게 만들자
• pre-trip이 아닌 in-trip과 post-trip을 모두 관리하는 서비스로 나아갈 것이다.