[컨퍼런스] AWS Summit Seoul 2024 - 1일 차 후기

 

2024 AWS Summit 발표자료가 공개되었습니다.

 

2024.05.19 - [일상] - AWS Summit Seoul 2024 - 2일 차 후기

 

다행히 회사에서 여유가 있는 상태라 1, 2일차를 모두 참석할 수 있었다.

 

참가 신청이 뜨자마자 신청해서 참석 이메일도 받은 상태였는데... 코엑스는 생각보다 멀었다.

 

아래는 강연인데 나는 표시한 순서대로 들었다. 

 

세션들은 아무래도 LLM이 이슈다보니 LLM과 빅데이터 처리를 위한 방법에 대한 세션이 많았다.

 

그러다보니 개발자가 들을만한 세션이 생각보다 많이 없었다.

 

 

같은 시간에 두 개가 있는 건 처음에는 KT DS의 세션을 듣다가 중간에 나왔다.

 

이유는 나중에 설명하기로 하고, 들었던 세션들을 하나씩 정리해보려고 한다.

 

중간 중간 나오는 파란색 글들은 내 생각을 넣은 것이다.

 

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

첫 번째 세션.. 입장 대기에서부터 사람이 너무너무 많았다.

 

 

우아한 형제들은 EKS와 AWS 관리형 서비스의 조합으로 데이터 플랫폼 구축해서 잘 쓰고 있다고 한다.

 

추천 서비스, 배달 예상 시간, 고객 안 내시간, 뚝딱이 등 데이터를 많은 곳에서 많이 사용함

 

생성형 AI에도 많이 활용 중인데, 오용 탐지 리뷰 관리 업무 생산성 향상을 위한 자동화 등등에 사용한다고 한다.

 

 

하루에도 약 10억개의 데이터가 쌓인다고 한다. 

 

월별 주문건수가 수천만에서 수억건으로 늘어남에 따라 EC2에서 운영하는데 문제가 발생함... 

 

그리고 주문의 패턴에 대응하기 어려움 : 식사시단 트래픽 향상, 선착순 이벤트 같은경우 100배정도의 트래픽이 들어옴

 

 

다양한 데이터 종류에 따른 EC2 개수의 증가, EMR 버전에 따라 증가되는 클러스터 개수 등 비용 문제가 발생함

 

EC2가 프로비저닝하는 시간 부트스트랩하는 시간이 길어서 민첩성한 대응이 너무 어려움

 

자원경합 문제는 JVM의 힙 할당 때문에 자주 발생

 

특히 의존성 문제와 에어플로우 관리 문제가 가장 심각했었다.

 

 

에어플로우 이관 후 많은 장점을 얻게 됨  > 여기서부터 내용이 조금 추상화 되서 잘 이해하기 어려웠음

 

현재는 EKS로 이관해서 데이터플랫폼을 운영 중이라고 한다.

 

 

변경 후 상시 노드가 불필요해서 비용 개선, 통합적 자원 활용, 강력한 자원 격리 효과를 얻음

 

지속적으로 고도화를 노력하고 있음

 

아파치 유니콘 적용,  에어플로우 기반 셀프 서비스, 온디맨드 개인 전용 완전 격리 환경 제공, CI/CD를 이용한 지속적 통합 관리 등등.. > 모든 세션을 듣고나서 느낀 거지만 이쪽도 플랫폼 엔지니어링을 준비하고 있다는 의미였다.

 

미래 전략도 있었지만 생략..

 

 

우아한 형제들 세션이라 제법 기대를 했는데

 

AWS에서 제공하는 기능이 워낙 강력해서인지, 듣는 사람들을 생각해서인지

 

추상화를 많이 하고 설명하셔서 생각보다 재밌진 않았다.

 

그리고 EMR과 에어플로우 문제를 많이 언급했었는데, 데이터 처리 쪽으로는 배경 지식이 없다보니 더 그랬던 것 같다.

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

 

Apache Airflow란?
배치 중심 워크플로를 개발, 예약 및 모니터링하기 위한 오픈 소스 플랫폼입니다. Airflow의 확장 가능한 Python 프레임워크를 사용하면 거의 모든 기술과 연결되는 워크플로를 구축할 수 있습니다. 웹 인터페이스는 작업 흐름 상태를 관리하는 데 도움이 됩니다.

 

나중에서야 알게된건 AWS EMR은 별게 아니고, 매니지드 맵 리듀스였다.

 

에어플로우는 데이터를 배치 처리하기 위한 플랫폼인데,

 

서비스가 급속도로 커짐에 따라 한번에 처리해야하는 데이터가 너무 많아진게 문제였던 것 같다.

 

채널톡 스타트업 기술 성장기 : RDBMS에서 NoSQL로의 전환

개인적으로 기대를 많이한 세션이었는데, 기대에 부응했다고 생각함

 

이 세션에서는 AWS 소속 아키텍트 분이 나와서 먼저 제품을 왜 쓰는 건가에 대한 이야기를 해주고 사례를 기업에서 설명해주는 방식으로 진행됐다.

 

앞으로 이런 방식으로 많이 진행됨

 

DynamoDB를 쓰는 이유

서버리스 DB인데다가 완전관리형이라 따로 메인터넌스할 거리가 없음

 

무료로 AWS RedShift와 같은 제품으로 통합해서 사용도 가능

 

 

인프라 프로비저닝 불필요, 자동 스케일링, 사용한만큼 지불, 고가용성과 보안성 제공.

 

급격한 스파이크가 튀는 요청에 대해서는 DynamoDB만 쓰기보다는 SQS를 앞단에 두고 사용한다고 한다.

 

 

AWS DynamoDB를 사용하게 된 모티베이션은 마케팅이었다.

 

고객에게 1회성 메시지를 다량으로 보내는 기능이 있었고 이 기능이 스파이크 트래픽을 발생시킴

 

트래픽 증가에 대한 간단 대응 전략으로는 RDS 스케일 업이 있지만, 문제점이 있음

 

총 4가지 문제를 정리해줬고, 해결법은 AWS DynamoDB를 사용하면서 적용할 수 있었던 전략들이다.

 

1. 스파이크 트래픽과 비용 비효율

- 짧은 순간에 많은 데이터가 인입하고 이후에는 평균적인 수치로 돌아감

- 짧은 순간을 대비해 오버프로비저닝을 해둘 경우 비용의 비효율이 발생함

 

해결 : 온디맨드 모드와 프리 워밍, 프로비저닝 모드와 오토 스케일링으로 해결

 

2. 부하 전파

RDS에서는 특정 테이블에 부하가 들어간다면 전체 테이블에 영향이 가는 부하 전파 현상이 발생함

이런 이벤트들은 독립적으로 동작으로 동작하게 구성해야 한다.

 

해결 : 독립적인 테이블을 설계해서 테이블을 용도에 맞게 여러 개 만들어서 대응 > 엔지니어링 요소도 필요함

 

3. 오퍼레이션 호환성

원자적 연산(atomic operation)이 잘 동작해야 한다 > 데이터의 변경이 동시에 잘 반영되어야 한다는 이야기

 

해결 : DynamoDB에는 원자적 연산(atomic operation)과 집계(Count query)가 없어서 새로운 테이블 구성과 개발 전략이 필요했음

 

DynamoDB 트랜잭션을 이용함 TransactWriteItems with clientRequestToken을 활용 O(1) 시간 복잡도라는 장점을 얻을 수 있고, 낙관적 락을 이용해 충돌이 발생하면 리트라이 후 정합성을 맞춘다.

 

4. 마이그레이션

RDS는 다운 타임없이 불가능

 

해결 : 병렬 스캔에 아이디어 차용 BatchWriteItem 사용, 다운타임이 없진 않았지만 짧은 시간에 잘 반영함

 

 

DynamoDB는 변경사항을 DynamoDB Streams을 통해 람다로 가져와서 전파시킬 수 있음

 

AWS Kinesis

Amazon Kinesis는 모든 규모의 스트리밍 데이터를 비용 효율적으로 처리하고 분석하는 완전관리형 서비스입니다. Kinesis를 사용하면 기계 학습, 분석 및 기타 애플리케이션을 위해 비디오, 오디오, 애플리케이션 로그, 웹 사이트 클릭스트림 및 IoT 원격 측정 데이터와 같은 실시간 데이터를 수집할 수 있습니다.

 

 

AWS OpenSearch

Amazon OpenSearch Service는 애플리케이션 모니터링, 로그 분석, 관측성 및 웹 사이트 검색과 같은 사용 사례에서 비즈니스 및 운영 데이터의 실시간 검색, 모니터링 및 분석을 안전하게 지원합니다. 

 

이 두 가지는 잘 모르는 서비스였는데 이번에 알게 됐다. 채널톡에서는 데이터 분석을 위해서 AWS 네이티브한 기술들을 사용했나도보다. OpenSearch는 Elasticsearch가 대립했던 것 같은데 괜찮은 듯?

 

 

로컬 개발환경에서 개발 하고, 어떻게 상용 DB와 마이그레이션할까? 에 대한 전략

 

AWS에서 제공하는 aws/dynamo-local 도커가 너무 느려서 DynamoDB Embedded를 이용함

https://github.com/PlaytikaOSS/testcontainers-spring-boot/tree/develop/embedded-dynamodb 이건가? 잘 모르겠음

 

DynamoDB 로컬 설정 기능이 있는지는 처음 알았음

 

 

하지만 초 대규모 기업에서 동시에 이벤트 발송 요청이 들어오는 경우 문제가 생김

 

수십만건의 write가 발생하기 때문

 

 

스파이크 트래픽에 대한 유연성이 증가했지만, 스파이크 트래픽이 이중 삼중으로 오면 여전히 부담스러움

 

DynamoDB 단독으로 처리하기 위해 프로비저닝과 오토스케일링이 민첩하지 않다. > SQS를 사용하기로 함

 

SQS의 특장점은 완전 관리형과 고가용성 > 아무리 많은 요청을 보내도 큐는 버팀

 

But 스탠다드 큐는 처리 용량에 제한이 없지만, FIFO 큐는 처리 용량에 제한이 있음

 

메시지 그룹 내에서만 순서가 있고 제한이 있다. 그러나 메시지 그룹의 수에는 제한이 없기 때문에 메시지 그룹을 늘리면 된다.

> 어떻게 늘리면 되는지에 대한 설명과 메시지 그룹간의 순서 보장은 어떻게 해야할까에 대한 내용이 없어서 다음에 필요하다면 조사를 해봐야할지도

https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html

 

 

람다가 빠르게 소비해줄 거라는 보장이 없기 때문에, 람다를 그냥 없애는 C안을 선택했다.

(Amazon SQS에서 람다 사용)

 

SQS와 메시지그룹을 활용하면 분산 락에 대한 우려를 할 필요가 없어진다. 메시지그룹은 순서도 보장해준다.

 

 

굉장히 배울게 많았던 세션.

 

언제나 과한 트래픽, 스파이크 트래픽을 대응하기 위한 노력은 경험해보기 쉽지 않기 때문에 배울 점이 많다.

 

디지털 혁신 가속화를 위한 kt ds의 AWS 생성형 AI 서비스 활용 사례, 한샘 하이브리드 플랫폼 구현 속 데브옵스의 역할

사실 듣고 싶었던 세션은 "옵저버빌리티 + 보안 + BI 통합 : 디지털 회복 탄력성 제고와 비용 최적화 달성 제안" 였다.

 

그런데, 여유시간없이 도착하긴 했지만 꽉차서 못 들어갔다.... 사람이 진짜 많기도 했고 사람들 생각이 다 똑같은 것 같다.

 

전에 하이브리드 플랫폼 세션을 들었다가 크게 데여서 kt ds 세션을 갔는데, 개인적으로는 매우 실망스러웠다.

 

간단한 아키텍처와 제품에 관한 설명이었는데, 새로울 게 없었고 무엇보다 발표자가 제품의 내부 구성까지는 잘 모르는 것 같았다.

 

그래서 중간에 나와서 이동했는데 차라리 한샘 세션을 듣는게 100배는 이로웠을 것 같다.

 

좋다고 느낀 이유가 아마도 온프레미스와 연동 부분이 끝나고 AWS 클라우드로 구성된 인프라 부분만 들어서 일지도?

 

GS리테일 Amazon EKS의 모든 것: 무중단 운영부터 배포 자동화까지

오늘 꼭 챙겨들어야지했던 3개 중 마지막. 기대만큼 좋은 세션이었다. 

 

 

EKS 운영에 어려운 점이 뭘까? 클러스터 관리, 애드온 관리, 팀관리 설정 관리 등등 다 어렵다.

 

 

웬만하면 EKS blueprint를 사용하자.

나는 테라폼을 쓰고 있어서 이걸 많이 참고함 : https://github.com/aws-ia/terraform-aws-eks-blueprints 

 

원하는 상태를 선언적으로 표현 > 비즈니스 위험 감소

원하는 상태를 불변 버전 관리 > 이력 추적

원하는 상태로 자동배포 > 보안 강화

지속적 관찰 동기화 > 일관성 유지

 

 

팀 관리와 설정관리도 ArgoCD에서 가능한데, GitHub과 같은 Git Repository에 변경 사항을 저장하고

 

ArgoCD로 배포하거나 반영하게 일반적인 방법인 것 같음

 

GS 리테일 클라우드 여정 - 인프라 챌린지

캡쳐가 많이 없어졌다...ㅠ

 

서비스 별로 클러스터를 구성하고자 했음

 

비즈니스 테넌트 분리에 따른 클러스터 증가에 따른 새로운 요구 사항이 발생

 

클러스터 관리가 어렵고, CI/CD 관리도 어러움

 

쿠버네티스는 진입장벽이 있고 대규모 매니패스트 관리의 문제가 발생

 

또 다른 문제 빠른 eks 버전 업 주기도 문제가 됨 : aws 콘솔에서 하면 쉽지만 서비스 중단 발생, 롤백 불가능

> blue green으로 구성해서 안정적으로 업데이트 대응

 

현재 서비스는 인그레스 없이 타겟 그룹으로 관리하고 있음 멀티클러스터 타겟 그룹은 API Gateway

(세부적인 구성은 찾아봐야겠다)

 

배포 템플릿를 통한 개발 생산성 향상 

사실 GS 리테일에서 최종적으로 하고 싶은건 플랫폼 엔지니어링 인 것 같다.

 

실제 한 일도 사실상 플랫폼 엔지니어링에 가까운 탬플릿화를 했다.

 

빌드와 배포가 합쳐져 있으면, 개발팀과 인프라팀의 R&R 이 애매해진다.

 

진입장벽이 높은 쿠버네티스 개발자들이 힘들어 함 > 이게 내가 생각하는 가장 큰 플랫폼 엔지니어링의 등장 이유임

 

인프라 팀이 매니페스트 템플릿을 만들어주는 API 생성함

템플릿 관리 도구 helm vs kustomize : helm은 공통부분이 아닌 부분의 관리가 어려움

> 매니페스트 파일의 정적 템플릿 정보를 테이블 형태로 관리

 

 

같이 듣던 분이 작년에도 GS 쪽 세션을 들었었는데 큰 틀에서는 비슷한 이야기를 했었다는 게 신기했다.

 

당시에는 플랫폼 엔지니어링보다는 클라우드 플랫폼으로 가고 싶어하는 것 같다고 들었다.

 

이제 클라우드화가 되고 안정화도 됐으니 개발자들의 반복적인 요구사항이 힘들어지고, 자동화를 시작한 단계같다.

 

이 세션 까지 듣고 한 세션은 건너 뛰었음.. 들을만한 게 없어보였다.

 

케이뱅크의 클라우드 도입 여정: 빅데이터, 채널, MSA, AI/ML

마지막 세션은 야놀자와 고민하다가 더 개발에 가까운 주제를 선정했는데 정말 좋은 선택이었다.

 

 

국내 최초의 인터넷 전문 은행인 케이뱅크는 앱 뱅킹을 클라우드로 확장했음

 

2021년부터 고객이 엄청나게 몰려서 고객 유입이 분산 수용되도록 노력을 시작함

 

서버 구조를 Active/Active 구조로 만들고 + 클라우드와 MSA로 넘어가기 위해서 노력함

 

유닉스를 리눅스로 전환하고, 고객 채널 시스템을 하이브리드 클라우드로 확장하기도 함

 

 

은행은 망분리가 정말 중요함... 그리고 금융감독원의 지침을 잘 지켜야한다..

 

 

모놀리식의 끝판왕 은행 시스템을 어떻게 클라우드로 옮기고 MSA로 전환할까 고민을 많이했다고 함

 

 

온프레미스 서버는 잦은 고장 + 자원 확장의 어려웠었다. 스토리지만 늘리고싶은데 서버도 따라와서 비용도 문제가 됨

 

 

S3 덕분에 고장에 대한 걱정과 스토리지의 규모확장성에 대한 고민이 없어지고, 탄력적 자원 분배가 가능해짐

(S3는 eleven-9 이라는 99.999999999% 고가용성을 자랑함) 

 

데이터 증가량만큼 클라우드 요금이 함께 우상향하지 않는데, 이렇게 하기 위해서는 엔지니어링이 필요함

 

클라우드화와 MSA를 시작할 때, 초기 작업 시작 시 절대 급하게 하지말 것을 권유함

 

다음 여정 소개로 마무리

 

 

마치며

세션을 고를 때 데이터나 LLM 쪽보다는 개발이나 인프라 관리 쪽을 고르다보니 들을 수 있는 세션이 너무 많이 줄었다.

가장 큰 문제는 사람이 많아도 진짜 너무 많았다는 것이다. 중간에 듣고 싶은 세션도 하나 못 들어감 ㅠ

 

우리나라에 개발과 관련된 사람들이 이렇게 많을 줄은 몰랐다.. 

 

그리고 세션을 하는 위치가 너무 멀리 떨어져있고, 기업 부스들도 동 떨어진 곳에 있어서 중간에 보러가기도 힘들었다.

 

그래도 나중에 올라오는 몇 시간짜리 유튜브는 집중도 안되고 다 보기도 힘들텐데, 현장감 있는 세션은 참 좋았던 것 같다.

 

지인분은 1일차만 보고 2일차는 안오셨는데, 내 입장에서는 2일 차가 조금 더 유익했다.