그동안 코로나때문에 오프라인으로 운영되지 않았다가 2023년에 드디어 오프라인 행사로 진행된 AWS Summit Seoul 2023에 다녀왔다!
이번 AWS Summit Seoul 2023은 코엑스 몰에서 5월 3일(수), 5월 4일(목) 이틀동안 진행됐다.
나이, 직종을 불문하고 정말 많은 사람들이 왔다. IT 소프트웨어, 제조업, 빅데이터 등등 AWS 클라우드 서버와 조금이라도 연관있는 직업에 종사하시는 분들 대부분이 온 듯했다.
나는 학교 수업들과 겹치는 시간대였기 때문에, 오전 세션에는 참여하지 못했고 3~4일 모두 오후 1시 이후 세션들로 참여했다.
5월 3일 수요일에는 산업 업종별 강연이 진행되어, 수많은 회사에서 AWS를 어떻게 다루고 있는지 소개하는 세션이 주가 됐다. 급격한 트래픽을 AWS를 이용하여 대처한 사례부터, 모니터링 툴을 어떻게 관리하고 있는지에 대한 얘기까지 다양한 사례들이 존재했다.
5월 4일 목요일에는 기술 업종별 강연이 진행되어, 입문 기술부터 심화 기술까지 다양한 분야의 클라우드 전문가분들께서 강연을 진행해주셨다.
자세한 강연 내용은 아래 홈페이지에서 확인할 수 있다.
https://aws.amazon.com/ko/events/summits/seoul/agenda/
참고로 결론부터 말하자면 정말 재밌었다!
부스 및 기념품에 대해 먼저 작성하고, 기술적인 세션 내용에 대해 이후에 작성하도록 하겠다.
다양한 부스
세션들도 정말 많이 진행이 됐을 뿐 아니라, 다양한 부스들이 있어서 체험 및 이벤트 응모를 할 수 있는 기회가 많았다.
이곳저곳 둘러보면서 기념품을 받는 재미가 있어서 갠적으로는 이틀동안 정말 재밌게 즐겼다.
오른쪽 사진처럼 키링(?)도 받았고, 이벤트 응모에도 진행해보았다!
이벤트 응모를 위해서는 MongoDB, CISCO, Datadog, Megazone Cloud 부스의 설문조사를 한 후, 도장을 받아야 했다. 그래서 그런지 해당 부스 줄이 상당히 길었다. 가장 긴 줄은 10분 이상 기다렸던 것으로 기억한다.
한두명 정도 추첨해서 아이패드, 공기청정기 등 다양한 상품을 주는 이벤트가 진행됐었는데, 운이 좋지 않았던 나는 아쉽게도 당첨되지 못했다. (당첨된 분들 진짜 부럽습니다...)
그리고 이벤트 당첨자 발표하는 공간에 사람이 정말 많이 몰렸어서 발표 목소리가 잘 들리지 않았었다. 정말 가까운 거리인데도 진짜 아무 소리도 안들릴 수 있다는 것을 이 때 처음 느껴봤다. 마이크의 필요성을 절실하게 느끼는 순간...
레드햇이랑 메가존에서 쇼핑백도 받았다.
개발 관련 쇼핑백이 두 개나 생긴 셈 ㅎㅎ
커피랑 팝콘을 주는 곳도 있었고, 스티커를 주는 곳도 있었다!
처음에는 콜라인줄 알았는데, 뚜껑 따고 마셔보니 커피였다ㅋㅋ
그 외에도 우산을 주는 곳, aws 키캡을 주는 곳, 무선충전거치대 등등.
다양한 기념품들을 정말 많이 받아갈 수 있었다.
엑스포 부스에 있는 건 아니었지만, 밸런스 게임도 있었다.
Cloud에 대한 당신의 생각, 재택근무 vs 출근, 점심시간에 회의 vs 퇴근 직전에 회의 등등 다양한 밸런스 게임 목록이 존재했다!
개인적으로 내 생각을 적어보자면 아래와 같다.
(내 의견: 굵은색, 사람들이 많이 투표한 의견: 밑줄)
- 지옥철로 30분 출퇴근 vs 텅빈 버스로 60분 출퇴근
- 7시 출근 4시 퇴근 vs 11시 출근 8시 퇴근
- 월요일 연차 vs 금요일 연차
- 점심시간 회의 vs 퇴근 직전 회의
- 클라우드는 대세, 이미 사용 중 vs 관심있게 지켜보는 중, 신중하게 도입 고려
- Day 1 관심 뿜뿜! vs Day 2 관심 뿜뿜!
- 자타공인 준 프로급 vs 마음먹고 시작해볼까? 이제 시작하는 클린이
- 어디서부터 어떻게 시작할지 모르겠다 vs 마음만 먹으면 검색박사, 독학 가능
- 맛집 배달료 2만원 vs 걸어서 40분 포장 픽업
- 내맘대로 해외여행 100번 가기 vs 원하는 집 1채 갖기
- 가족/친구들과 한강 봄소풍 vs 이불 밖은 위험해!
- 영원히 재택근무 vs 에어컨 쐬러 출근
아니, 7시 출근 4시 퇴근이 더 좋다고...?? 난 당연히 대부분 11시 출근 8시 퇴근 좋아할줄...
다양한 세션
다양한 부스도 좋지만, AWS Summit 2023에 온 가장 큰 목적은 AWS의 많은 서비스들을 익히기 위해서였다. 그렇기 때문에 기술적인 내용이 주가 되는 세션들이 사실상 나의 가장 큰 목적이었던 것.
코엑스의 오디토리움은 진짜 예쁘고 웅장한 듯하다.
모든 트랙이 이런 곳에서 진행됐으면 정말 좋았을 거 같지만 그건 너무 큰 욕심이겠지 ㅎㅎ 다른 트랙이 진행된 곳들도 나쁘지 않았고 꽤 괜찮았다. 다만, 트랙3~5가 진행됐던 1층 그랜드볼룸은 데이터가 잘 안터지는 것이 조금 아쉬웠다.
5/3에 내가 들은 세션 목록은 아래와 같다.
- [Track 5] 마이크로서비스로 이커머스 성장을 이끈 AWS 매니지드 서비스와 마켓플레이스의 활용 사례
- [Track 4] 클라우드 환경에서 두 마리 토끼잡기 : 비즈니스 서비스 품질 향상 & 모니터링 비용 최적화
- [Track 3] 투자를 모두에게, 토스증권의 MTS 구축 사례
- [Track 2] Observability를 넘어선 클라우드 운영관리의 미래
- [Track 1] SOCAR는 어떻게 2만대의 차량을 운영할까?: IoT Data의 수집부터 분석까지
개인적으로 3일에 진행된 세션은 aws 아키텍처를 회사 규모에서 어떻게 적용하는지 다루는 위주라, 4일에 비해 훨씬 어려운 난이도로 진행됐다고 생각한다.
모든 세션을 다 적기에는 너무 글이 길어질 수 있어서, 몇 가지만 적어보려 한다.
트랙 5에서는 29cm에서 MSA로 전환하면서 aws 아키텍처를 어떻게 가져갔는지 얘기를 들을 수 있었다. 29cm가 성장하면서 트래픽이 많아졌고, 이에 따라 기존의 모놀로틱 구조에서는 배포 주기가 느려지고 장애 빈도가 늘어났다고 한다.
MSA 환경은 트랜잭션 관리 및 디버깅, 모니터링이 어렵다는 단점이 존재하지만, 확장성과 유연한 설계를 챙기기 위해 마이크로서비스로 전환했다고 한다. 이를 위해 택한 방법은 스트랭글러 패턴! Spring Camp 2023에도 나온 패턴이다. 기존 기능을 유지하며 트래픽을 점진적으로 MSA로 이관하여 레거시를 점점 말려죽이는(?) 패턴을 의미한다.
이를 위해 Amazon EKS, Amazon Aurora, Confluent Kafka with AWS Marketplace (해당 세션의 제목에 괜히 marketplace가 있는 게 아니었다 ㅋㅋ)를 새로 도입했다고 한다. 자체 k8s 사용할 때에는 버전 업그레이드 및 운영이슈가 존재했었는데 EKS를 도입함으로써 이를 해결하고, Aurora DB를 사용함으로써 관리 용이성을 챙겼다고 한다. (Aurora DB의 장점은 5월 4일 세션의 입문 기술 1 - RDS에서 자세히 다뤄주었다.)
그리고 apache kafka와 유사하며 29cm의 아키텍처와 호환성이 좋은 confluent kafka를 aws marketplace에서 구입했다고 한다. aws msk(Managed Streaming for apache Kafka)를 도입하지 않은 이유가 조금 궁금하긴 한데, 호환성 이슈 및 마켓플레이스 홍보를 위해 confluent kafka로 발표한 게 아닐까 싶다.
많은 컨테이너들을 다루어야 하는 회사 규모의 아키텍처는, 취준생 및 대학생은 쉽게 접할 수 있는 환경이 아니라고 생각한다. 그렇기 때문에 이런 세션 자체가 나한테는 정말 귀한 경험이었다. 나도 빨리 쿠버네티스로 컨테이너 관리하면서 모니터링 해보고 싶다!!
해당 세션이 끝나고, 어쩌다보니 연로그도 aws summit seoul에 와있는 것을 알게 됐다.
그렇게 오랜만에 우아한테크코스 동기이자, 우아한형제들 6개월 선배님(연로그는 1월 입사, 나는 7월 입사 예정)인 연로그를 만났다 ㅎㅎ 거의 반년만이라 정말 반가웠다. 그렇게 2시 이후부터 5시까지는 쭉 같이 세션을 들었다!
Track 3 에서는 토스증권에서 급격한 트래픽을 버틸 수 있었던 네트워크 구성과 MTS 구축 사례에 대한 얘기가 나왔다.
토스증권은 멀티클라우드 환경에서 운영될 수밖에 없는 구조였으며, 토스 계좌 증설 시 1주 주식 선물 이벤트 시에 하루만에 계좌가 100만 개 넘게 새로 생기면서 엄청난 트래픽이 몰렸다고 한다. 그렇기 때문에 온프레미스와 VPC 클라우드와의 통신을 위해 AWS Direct Connect 방식을 선택하고 AWS Transit Gateway를 이용하여 멀티캐스트 방식을 선택했다고 한다.
AWS Transit Gateway는 이번 세션에서 처음 존재를 알게 됐다. 조금 검색해보니 네트워크 규모가 정말 커지면 라우터를 관리하기가 까다로울테고, 그런 경우에 AWS Transit Gateway 이주를 고민해볼수 있다고 한다.
그리고 온프레미스 환경의 라우터와 클라우드 환경의 라우터 사이의 통신으로 PIM over GRE를 놓는다고 한다. 이 역시 처음 들어보았고, 강연이 끝나고 chatgpt한테 검색을 해보았다.
Q. aws direct connect에서 pim over gre를 놓는 이유는?
AWS Direct Connect는 온프레미스 데이터 센터와 AWS 클라우드 사이의 전용 연결을 제공하는 서비스입니다. PIM(Protocol Independent Multicast) over GRE(Generic Routing Encapsulation)는 멀티캐스트 트래픽을 AWS Direct Connect 연결을 통해 전송하기 위한 기술입니다. PIM over GRE을 사용하면 멀티캐스트 트래픽을 AWS Direct Connect 연결을 통해 전송할 수 있으며, 이는 여러 가지 이점을 제공합니다.
첫째, PIM over GRE은 AWS Direct Connect 연결을 통해 멀티캐스트 트래픽을 전송할 수 있도록 해주므로, 멀티캐스트 기능이 필요한 응용 프로그램을 AWS 클라우드로 이전하는 데 매우 유용합니다.
둘째, PIM over GRE은 AWS Direct Connect 연결을 통해 멀티캐스트 트래픽을 안전하게 전송할 수 있도록 해줍니다. 이를 위해 GRE 터널링을 사용하여 멀티캐스트 트래픽을 암호화하고 보호할 수 있습니다.
셋째, PIM over GRE은 다양한 클라우드 환경에서 멀티캐스트 기능을 지원하며, AWS Direct Connect와 같은 전용 연결을 통해 이러한 멀티캐스트 트래픽을 안전하고 신뢰성 있게 전송할 수 있습니다.
따라서 PIM over GRE을 AWS Direct Connect에 구성하는 것은 멀티캐스트 트래픽을 전송해야 하는 경우에 매우 유용합니다. 그러나 PIM over GRE을 사용할 때는 GRE 오버헤드, 라우팅 복잡성 등의 고려 사항이 있으므로 적절한 네트워크 설계와 관리가 필요합니다.
출처: chatgpt
물론 chatgpt의 말을 100% 맹신해서는 안되지만, 대략적인 감을 잡기에는 정말 좋다고 생각한다.
추가로 검색해보니 PIM은 멀티캐스트 통신을 위한 프로토콜이라고 한다. 그리고 GRE는 IP 패킷에 다른 프로토콜 패킷을 캡슐화하는 터널링 프로토콜이며, AWS Direct Connect에서 PIM over GRE를 사용하는 경우, PIM 데이터를 캡슐화하여 GRE 패킷으로 전송하고, 수신 측에서는 GRE 패킷에서 원래의 PIM 데이터를 복원한다고 한다.
토스증권에서는 주식 차트를 고객들에게 보여줘야 하기 때문에 사실상 멀티캐스트 방식으로 동시 송신(MTS) 환경이 필수일 것이고, 이 때문에 위와 같은 네트워크 구성을 만든 것이 아닐까 싶다. 이번 세션은 정말 어려웠지만, 그만큼 많은 공부가 됐다.
Track 1의 쏘카 세션도 꽤 재밌었다. 많은 트래픽을 감당하기 위해 amazon MSK(Managed Streaming for apache Kafka)와 커넥터용으로 amazon EKS(Elastic Kubernetes Service)을 도입한 사례에 대해 얘기해주었다. 처음에는 멀티스레드 방식으로 진행했다가 Kafka consumer group을 늘려 병렬처리 도입까지 같이 진행했다고 소개해주었다.
그리고 Go 언어 도입을 통한 Gorutine 도입 및 pod를 이용한 쉬운 scale-up, scale-out을 위한 k8s (amazon eks) 도입, 그에 따라 Topic, DB 별 Connector 배포 도입을 쭉 설명해주었다.
사실 쏘카는 IoT 쪽 위주라 생각돼서 들으면서 과연 내가 재미를 느낄 수 있을까 하는 걱정도 좀 있었다. 나는 IT 소프트웨어 백엔드 분야이고, IoT는 큰 흥미가 없었기 때문이다. 그렇지만 네트워크 및 데이터 아키텍처 구조에 대해 깊게 설명해준 덕분인지 후반부에는 정말 재미있게 들을 수 있었다.
당연히 이번 세션도 난이도는 꽤나 있었다. 하지만 역시 대학생 수준의 사이드 프로젝트에서 경험하기 쉽지 않은 환경들을 들을 수 있어서 정말 재미있게 들었다.
5/4에 내가 들은 세션 목록은 아래와 같다.
- [입문 기술 1] 스마트한 클라우드 스토리지 비용 관리 전략
- [입문 기술 1] 성공적인 AWS RDS 마이그레이션을 위한 여정과 필수 고려사항
- [중급 기술 2] 서버리스, 이제는 데이터 분석에서 활용해요!
- [심화 기술 1] SaaS와 모니터링 플랫폼
- [입문 기술 1] 지능화되는 랜섬웨어 위협으로부터 지킬 것인가? 당할 것인가?
5월 4일은 입문, 중급, 심화로 난이도가 나뉘어져 있어서 3일에 비해 난이도가 높거나 헤비한 느낌은 적었다. (근데 그래도 어려운 세션들은 정말 어려웠다.)
모든 세션을 다 적기에는 너무 글이 길어질 수 있어서, 몇 가지만 적어보려 한다.
aws에서 s3를 쓰고 있었지만, 제대로 알고 쓰고 싶어서 해당 세션을 들었다. 그리고 결과는 정말 만족스러웠다! 오브젝트 스토리지가 전부가 아니었다. EC2와 마운트하여 애플리케이션 데이터를 저장하기에 적절한 EBS, 그리고 생전 처음 들어보는 EFS와 FSx에 대해서도 알게 되었다. 그리고 aws S3에서도 나는 S3 Standard만 사용하고 있었는데, S3 Glacier, S3 One Zone-infrequent access(IA) 등 정말 다양한 S3 클래스들이 존재했다. 자주 엑세스하지 않지만 보관이 필요한 데이터는 Glacier에 저장하면 비용을 훨씬 아낄 수 있다. 그리고 Glacier 내에서도 Instant Retrieval(거의 엑세스하지 않는 데이터 용도, $0.005/GB month), Flexible Retrieval(아카이브 용도, $0.0045/GB month), Deep Archive(장기 아카이브 용도, $0.002/GB month)로 나뉘어지기 때문에 용도에 따라 잘 선택하면 비용을 많이 아낄 수 있을 듯!
사실 대학생 위주의 사이드 프로젝트에서는 S3 Standard 외에 거의 쓸 일이 없다고 생각한다. 안쓰는 데이터를 바로바로 지우는 것이 비용 및 관리 면에서 좋기 때문이다. S3 Standard 외에 굳이 아카이브 용도로 추가 스토리지 서버를 둘 필요가 없는 케이스가 대부분이다. 하지만 데이터 보관이 중요한 큰 규모의 프로젝트라면 이러한 정보들은 큰 꿀팁이 될 듯하다. 그리고 EC2 업데이트 및 마이그레이션할 일이 없다보니 EBS도 쓸 일이 없고, 여러 인스턴스끼리 데이터를 공유할 일이 없다보니 EFS도 사실상 쓸 일이 없다고 생각한다. 그런 의미에서 나 포함, 대학생들이 해당 세션을 들으면 얻는 것이 많지 않을까 생각한다.
이어서 RDS 마이그레이션 세션도 참가해보았다. 사실 DB 마이그레이션 과정이 궁금해서 참여해보았는데, 뜻하지 않게 그동안 궁금했던 RDS vs Aurora 차이를 알 수 있었다! RDS에 비해 Aurora가 성능 및 안정성이 좋지만, 비용이 비싸고 버전 지원이 적다는 점이다. 내가 참여하고 있는 사이드 프로젝트에서도 Aurora는 프리티어 지원이 안되고 비교적 비싼 것으로 알고 있었기 때문에 RDS를 사용하고 있었다. 역시... 돈이 문제다. 나중에 입사하고 나서 Aurora 마음껏 사용해보든지 해야지.
그리고 DB 마이그레이션을 위해 백업, 호환성, 라이선스 변화 등에 대한 충분한 이해 및 시간이 확보돼야 한다고 한다. 그리고 원래 DB에서 트랜잭션 처리량이 어느 정도였는지, Read/Write 비율이나 OLTP/배치 비율이 어느 정도인지, 리소스 사용량이 어떤지 분석 과정이 진짜 꼼꼼하게 이루어져야 이관하는데에 문제가 생길 확률이 적다고 한다. 또, 규모가 작은 경우 OS 명령어(scp, sftp 등)로 충분히 마이그레이션이 가능하지만 규모가 크다면 AWS DMS(Database Migration Service) 등의 CDC 도구를 이용하는 방법도 있다고 한다. 당연히 후자의 경우 비용이 꽤 많이 든다고. 그리고 마이그레이션 시에 프로시저나 트리거는 사실상 다시 생성해야된다고 생각하는게 편할듯하다. 마이그레이션 시에 지워지는 경우가 많다고 한다. 그동안 프로시저나 트리거를 많이 만들지 않았기 때문에, 그리고 마이그레이션할 일이 없었기 때문에 크게 고민하지 않았던 부분인데 프로시저나 트리거 관리 필요성을 느끼는 순간이었다.
온프레미스의 오라클 RAC(Real Application Clusters) DB를 AWS RDS로 이관하는 사례에 대해서도 얘기가 나왔다. AWS RDS에서는 RAC 기능이 지원되지 않기 때문에 HA 구성을 어떻게 할지, 기존 RAC 환경의 모든 기능을 처리할 수 있게 하도록 설정이 필수적이라 한다. 진짜 마이그레이션은 정말 고통스럽지만 어쩔 수 없는 과정인 것 같다. (어떻게 보면 성장의 기회이기도 하지만 말이다.)
단순히 multi-AZ 방법 (참고: https://support.bespinglobal.com/ko/support/solutions/articles/73000544793--aws-rds-%EC%9D%B4%EC%A4%91%ED%99%94-%EA%B5%AC%EC%84%B1-multi-az-)으로 RAC 환경을 모두 처리할 수 없으니 사례로 나온 게 아닐까 싶다. (여담으로, 참고링크가 베스핀글로벌 글인데 베스핀글로벌에서 오신 분의 세션도 이번 aws summit seoul 2023에서 재밌게 들었다. 아는 만큼 보인다는 게 여기서도 쓰일 수 있을듯 ㅋㅋ)
또, CDC 도구가 만능이 아니기 때문에 별도 수작업이 필요할 수 있다고 한다. 마찬가지로 해당 사례에서 CDC로 완전히 마이그레이션되지 않았으니 이 얘기가 나온 거겠지..? 마이그레이션 담당자 분의 곡소리가 여기까지 느껴지는 것 같다...
첫째날에는 연로그를 만났는데, 둘째날에는 제로를 만났다!
제로는 우아한테크코스 과정에서 레벨3~4 기간동안 프로젝트도 같이 진행했고 정말 친하게 지냈던 우테코 동기였어서 정말 반가웠다. 겹치는 세션이 없어서 같이 듣진 못했지만, 오랜만에 이런저런 얘기도 하면서 쉬는시간 동안 재밌게 수다떨 수 있었다.
스마트한 클라우드 스토리지 비용 관리 전략
마지막으로, 랜섬웨어 관련 보안 세션을 들었다. 랜섬웨어 및 악의적 공격을 대비하기 위해선 크게 세 가지 측면에서 생각해볼 수 있다. 네트워크를 타고 공격하는 케이스 대비, 내부에서 실수 또는 악의적인 공격 대비, 그리고 실시간 모니터링.
네트워크 쪽 방어에 대해서는 private subnet 및 NACL(네트워크 접근제어 리스트), SG(보안그룹) 세팅 정도만 알고 있었는데, aws에서 제공해주는 Route 53 firewall, AWS WAF(Web Application Firewall) & Shield 기능도 있었다! 그리고 내부 실수 및 공격을 방지하기 위한 AWS Systems Manager, AWS backup 등. 마지막으로 모니터링을 위한 AWS Cloudwatch, AWS Config, AWS GuardDuty. AWS GuardDuty로 악의적 공격을 탐지하고 깊게 파기 위해 AWS Detective를 이용한다고 한다. AWS GuardDuty와 AWS Detective는 우리 사이드 프로젝트에도 있으면 좋겠다 싶어서 세션이 끝나고 이용해보려 했으나... 프리티어가 아닌 유료 범위였다. (30일 동안은 무료)
그리고 AWS WAF에 대해서도 알아봤는데, 보안 쪽 공부가 부족해서 그런지 생각보다 꽤나 복잡했다. 그래서 섣불리 도입하기보단, 관련 공부를 진행해보고 기회가 되면 도입해보려 한다.
틈틈이 관련 내용을 포스팅한 기술블로그들을 쭉 읽어봐야겠다.
https://techblog.woowahan.com/2699/
나중에 내가 읽기 위해 첨부!
AWS Summit Seoul은 처음 참가해보는데, 세션이 정말 다양해서 정말 재밌게 들었다.
부스도 되게 다양하고 즐길 거리가 매우 많았다. 오전부터 참석했다면 점심도 무료로 먹을 수 있었는데... 내년에는 오전부터 풀타임으로 한 번 참석해보고 싶다.
그리고 개발자 컨퍼런스이다보니 오랜만에 보는 얼굴들이 많았어서 정말 반가웠다. aws 지식을 채워갈 뿐 아니라, 다양한 사람들을 만나고 오랜 친구들을 만나는 기회가 되어준 aws summit seoul 2023. 내년에도 꼭 참가하고 싶다!
스마트한 클라우드 스토리지 비용 관리 전
트한 클라우드 스토리지 비용 관리 전략
'Infra > Aws' 카테고리의 다른 글
[Infra] AWS SNS+Chatbot로 슬랙 알림받기(Feat. AWS Budgets) (0) | 2023.05.22 |
---|---|
[Infra] 와이어샤크로 tcpdump 파일 분석하여 AWS ALB idle timeout 설정하기 (4) | 2023.05.15 |
[AWS] SES를 이용한 메일 전송 기능 구현 (0) | 2023.04.25 |
[AWS] CloudWatch + Lambda로 slow query 발생 시 Slack 알림 보내기 (0) | 2023.04.21 |
[AWS] S3 연동 후 Spring Boot 파일 업로드 구현 일지 (0) | 2023.04.09 |