May 7, 2023 - AWS Summit 2023

*5월 7일

 

-5월2일~3일 일정으로 회사 개발팀 전체 함께 AWS Summit 2023에 참가했다. 들었던 각종 내용들과 앞으로 좀 더 대비하거나 알아봐야할 내용을 조금은 정제된 메모장과 같이 정리해보도록 하자.

 

1.기조연설

-기조 연설은 Nandini Ramani AWS 모니터링 담당 부사장님, 함기호 AWS Korea 대표이사, 오순영 KB국민은행 센터장, 이준영 야놀자 엔지니어링 수석 부대표분이 진행해주셨다. Nandini Ramani 분이 메인으로 진행하면서 중간 중간 다른 연사들이 나와 특정 주제에 대해 PT 하는 방식이었다. 확실히 서방과 한국식 PT의 차이를 느낄 수 있었고, 모두들 매끄럽게 잘 진행해주셨던 것 같다. 기조 연설 시작 전 Nandini Ramani분의 영상을 좀 찾아봤는데, 당일 옷도 그렇고 확실히 빨간옷을 좋아하시는듯 하다. 본인 퍼스널 컬러인 것 같고 잘 어울리는 듯 하다. ㅎㅎ

-야놀자 이준영 연사분께서는 야놀자의 ‘모텔 예약 앱’이라는 이미지를 지우기 위해 역시 노력하셨다. 실제 작년 인터파크 인수, 클라우드 쪽 투자 확대 등으로 영업이익이 급감 한 것도 있고, 좀 더 확장하기 위해 많은 노력을 하고 있는 것 같다. 그러나… 일반인 입장에서 빨간 로고, 그리고 yanolja라는 이름에서 오는 이미지가 도저히 쉽게 바뀔 것 같지는 않다. 메타처럼.. 사명을 바꾸는 시도라도 하는게… ㅎㅎ

-확실히 시장에서 가장 높은 점유율을 가지고 있는 AWS에서도 후발주자들과 시장 상황을 고려 했는지 차이를 만들어 내는 것은 혁신이라는 점을 많이 강조했다. 인프라 구축은 거대 자본이 있으면 후발주자라도 언제든지 따라올 수 있다고 느끼고 있는것 같고, 검색 시장에서 절대적이던 구글이 요즘 시장 점유율을 조금씩 내어 주는 상황을 지켜보면서 조금 더 긴장하고 있다는 것을 느꼈다.

 

 

2.Data lake & data warehouse

-Data Lake: raw data 그대로 저장, 별도 사용 목적 두지 않고 저장, 별도 정제 과정이 없으므로 빠른 업데이트

-Data Warehouse: 별도 정제 과정을 거쳐서 목적에 맞게 데이터 저장

-무수한 데이터들이 실시간으로 엄청나게 쌓이고, 별도 목적을 지정해두지 않았던 raw data에서 인사이트를 얻을 수 있는 경우도 있으므로 data lake식으로 저장하는 방식이 큰 기업일 수록 선호 되는 듯 하다. 데이터 분석은 별도 데이터 사이언티스트가 진행하거나 AWS의 각종 기능들을 이용하여 충분히 각종 지표를 찾아 낼 수 있어 그런듯 하다. AWS datazone과 같은 서비스를 활용하여 권한 관리를 통한 접근 설정을 통해 각 데이터 마다 레벨링을 해둘 수 있다.

 

-sendbird 또한 ec2만 수천, eks만 수백을 굴리는 규모인데 데이터를 선택적으로 수집하면 추후 활용에 문제가 될 수 있기에 전체를 저장하고 AMP, AMG등을 활용하여 매니징 하고 있다고 한다.

 

3.Monitoring과 observability의 차이

-모니터링은 단순히 어디에서 문제가 생겼는지 확인. 즉 로그 확인과 같이 심어놓은 로그를 활용하여 버그 픽스 등에 활용. observability는 무엇이 문제인지, 각종 환경, 최종 사용자에게 어떠한 영향을 미치는지 파악하는 좀 더 큰 개념.

-AWS native monitoring options, cloud watch, metrics, x-ray 및 각종 오픈소스 기반 

-삼성은 prometheus, grafana 오픈 소스 기반으로 사용하다가 보관 문제, 각종 config 값 변경 등의 문제로 Amazon-managed prometheus, grafana(AMP, AMG)등으로 갈아 탔다고 한다.

 

4.FLO와 netFUNNEL

-FLO(음악 스트리밍 서비스)에서 On-premises -> AWS로 전체 마이그레이션을 진행하며 일어난 일들에 대해 발표했다.

-마이그레이션 진행 시 아주 세세한 플래닝을 준비했고, 부하테스트, 외부 연동 방화벽 처리, 데이터 동기화, 리허설, 각 작업자 별 태스크 정리 등을 어떻게 했는지 상세히 말씀해주셨다. 단순한 데이터 테이블 하나 마이그레이션 하는 것도 상당히 신경 쓸 부분이 많은데, 서비스 전체를 옮길 때 얼마나 고생하셨을지 상상이 가지 않는다.

-아마존 스케일링 서비스를 통해 피크타임 서버 대수 유연한 대응을 한다고 하고, 새벽 시간대를 활용하여 cron을 돌려 개인화된 추천을 처리한다고 한다. (스포티파이는 거의 실시간으로 내 취향의 노래를 추천 하는 것 같은데.. 이걸 어떻게 하는지 궁금하긴 하다.)

-앱은.. 스포티파이 느낌이 너무 많이 났고, 별로 갈아 타고 싶은 매력은 느끼지 못했다..

 

-netFUNNEL이 명절 기차 예약 서비스 트래픽을 담당하는 것을 처음 알게 되었다… 수강 신청 등 그동안 이러한 서비스들이 각자 트래픽을 관리한다고 생각했는데 나의 착각이었다.

 

-netFUNNEL은 서버와 앱 사이에서 동작하고, 서버가 처리 가능한 트래픽만 보내주는 역할을 한다고 한다. 기존 구축형으로만 제공하다가 AWS와 협업하여 현재는 SaaS 형태로 제공 중이라고 한다. 곧 AWS market place에도 나올 예정이라고 하신다.

-현재 netFUNNEL을 포함해 다양한 기능을 더 넣은 surffy라는 서비스를 개발 중이시라고 한다.

 

5.재해복구 관련 세션

-자연재해, 기술이슈, 휴먼에러, 해킹 등 다양한 사유로 재해 복구가 필요한 상황이 발생.

-RPO recovery point objective, RTO recovery time objective와 같은 관련 용어

-AWS backup, pilot light, warm standby, multi-site active와 같은 활용 가능한 기능들이 있으며, backup은 수시간의 비용이 소요되나 비용이 저렴한 장점이 있고, multi-site active의 경우 실시간에 가까운 복구이고 무중단, 데이터 손실도 없지만 당연히 비용이 비싸다는 단점이 있었다. 당연하게도 사용목적에 맞는 재해 복구 시스템을 구축하는게 맞을 듯 하다. 앱이 잘게 잘게 구분되어 있으면 각 목적 별로 구분하여 재해 복구 시스템을 구축하기에 좋을 듯 하다. 데이터 손실에 따른, 서비스 중단에 따른 비용을 따져보고 적용이 필요!

-백업의 경우 정적의존성, 동적의존성을 분리 후 백업이 필요하다. AMI 정보, region 정보, DB snapshot 등 별도 관리가 필요한 부분이 있을 듯 하다.

-마지막으로 세션 연사님께서는 재해복구는 최초 구축 후 끝인게 아니라 계속해서 상황에 따라 검증하고 보완이 필요한 부분이라고 하셨다.

 

6.SOCAR IOT & 압도적인 쿠팡 데이터 사이즈

-나도 몇번 써본 쏘카, 실시간 데이터 기반으로 예약시간, 장소 및 실시간 수요 반영하여 가격 적용 그리고 선별적 쿠폰 발행(아.. 그래서 나에게 쏘카 쿠폰이 그렇게 안왔던 거구나..)

-세차 주기 최적화, 운전자 숙련도 식별한 가격 차등 책정, 약 2만대 자체 차량 운영

-자체 종합 차량 관제 시스템 OKSTRA 운영 중, 주유량, 엔진오일, 공기압 등 다 관리

-Fleet management system 차량 데이터 기반으로 차량 관리 및 운영을 효율화하는 차량 관제 플랫폼. 유지보수, 알림, 유류비, 사고, 동선, 자동화, 배차, 실시간 위치, 알림, 주행데이터, 심지어 실시간 블랙 박스까지..

-실시간 저장 필요 데이터와 히스토리용 데이터를 구분하여 목적에 맞는 저장소에 저장 중이었다. 실시간 데이터는 elastic cache 사용, 히스토리용 데이터는 dynamoDB 활용

-IOT에서 실시간으로 들어오는 데이터를 특정 시간 단위로 벌크화하여 전송하고, 접수한 데이터를 초당 데이터로 풀어서 elastic cache에 저장

-우버와 그랩은 어떻게 하고 있을까.....??

 

-쿠팡의 데이터 관련 세션이 있었다. 소개하는 바에 따르면 cron job이 하루 120k, 쿼리가 하루 500k, 분당 7.1m의 로그가 쌓인다고 한다. 규모에 일단 압도를 당했다.

-AWS EMR을 활용한다고 하고, 모니터링은 슬랙, 그라파나, 프로메테우스, 스케쥴러는 airflow, processing engine은 하이브, 스파크, 쿼리엔진은 presto, 저장소는 s3…

 

7.토스증권

-토스증권이 어떻게 단기간 내에 사용자 친화적인 해외주식 거래 서비스를 만들었는지 할 수 있었다. 일명 Blitz Scaling을 통해 개발해옴. Speed, user acceptance, maker and culture, enough resources를 강조. 

-multi-cast로 한국거래소에서 받아온 증권 시세 정보가 각 증권사에 전달되고 각 증권사 별로 그 정보를 가공해서 처리한다고 함. 시세 정보는 web socket, 종목 정보는 restAPI, DB는 redis, 실시간 정보는 kafka 통해서 web-socket.. (과거에는 DB에 넣고 restAPI로 땡겼는데 너무 속도 느림..)

-직원 이탈률은 정확히 알 수 없지만, 정말 엄청나게 갈아가며 서비스를 뽑아 내는 것 같다. 물론 그것을 가능하게 해주는 적절한 직원 보상과 서비스 성장에 따른 구성원의 성취감이 있을 듯 하다. 내가 만든 서비스가 하루만에 100만 사용자가 증가한다면, 줄야근을 해도 뿌듯할듯 하다. 다만 1년 365일은 불가.. 하지 않을까..

 

*블리츠스케일링(Blitzscaling)은 불확실한 상황에서 위험을 감수하더라도 엄청난 속도로 회사를 키워 압도적인 경쟁우위를 선점하는 기업의 고도성장 전략을 말한다. 기습 공격을 의미하는 ‘블리츠크리그(Blitzkrieg)’와 규모 확장을 의미하는 ‘스케일업(scale up)’의 합성어로, 링크드인 설립자 리드 호프먼이 스탠퍼드대 스타트업 특강을 계기로 미국 전역에 화제가 되면서 널리 알려지게 된 공격적 비즈니스 개념이다. 이미 아마존, 구글, 에어비앤비 등에 의해 검증된 전략으로, 경쟁자를 빠른 속도로 제압함으로써 시장의 우수한 인적·물적 자원을 흡수하고 브랜드 인지도를 각인하며, 결국 시장을 독점하는 것이 전략의 골자다

 

8.그 외 용어

 

-보안 관련 가장 기본은 AWS shield advanced, aws firewall, aws WAF는 좀 상급 개념으로 확인.

-멀티모달: 시각, 청각을 비롯한 여러 인터페이스를 통해서 정보를 주고 받는 것을 말하는 개념

-데이터 관련 각 담당자의 역할

-데이터 생산자: 오너십, 품질, 메타데이터 관리 / redshift, s3

-데이터 관리자:  데이터 정리, 플랫폼 구축 운영, 권한 통제, / data zone

-데이터 소비자: 비즈니스 우선순위 결정, 새로운 인사이트 개발.. // redShift

 

9. 부족한 점

-네트워킹 관련 지식 부족...어떻게 각 서비스를 고립 시키는지..  

-대용량 데이터 처리...

-elastic cache

-AMP, AMG

-보안 처리

 

*지금까지 부족한점을 알아보지 않은 이유라면,, 필요 해야 더 열정적으로 알아 볼 텐데, 대규모 서비스를 운영해보지 않아 필요성이 없었던게 가장 큰 듯하다. 네트워킹, 대용량 데이터, 각종 시각 모니터링 기능, 보안 등.. 어떻게 하면 더 잘 알아 볼 수 있을지 고민 좀 해보자.