[reinvent 2024] Dr. Werner Vogels Keynote_Part2
Summary
Dr. Werner Vogels는 리인벤트 2024의 Keynote Session에서 무슨 이야기를 했을까요?
AWS의 기본이지만 주요 서비스인 S3의 복잡성 관리할 수 있는 새로운 방향과 내용에 대해 메가존클라우드의 테크 블로그를 통해 함께 살펴보실까요?
리인벤트 2024 테크 블로그의 더 많은 글이 보고 싶다면?
Overview
복잡성에 대응하는 방법
서비스의 성장에 따라 시스템의 부하를 감당하기 위해 시스템을 분해하여 독립적으로 작동하는 블록을 만들어야 합니다. 복잡한 시스템에 영향의 범위를 줄이는 것이 중요해 집니다. 작은 블럭들에 정확한 고객요청의 전달을 위해 라우터도 필요하고, 전체 셀의 가용성을 관리하기 위한 콘트롤 플레인이 필요합니다.
시스템의 구축에 드는 시간은 실행하는 시간에 비해 매우 짧기 때문에 관리가능성에 대한 사전투자, 보안, 비용통제에 신경을 써야합니다.
시스템의 구축에 드는 시간은 실행하는 시간에 비해 매우 짧기 때문에 관리가능성에 대한 사전투자, 보안, 비용통제에 신경을 써야합니다.
불확실성에 대응하는 방법 – 자동화
Vogels는, 불확실성은 또 다른 주요 문제라고 언급하며, 예측 가능한 시스템을 설계하여 이를 상쇄해야 한다고 말했습니다. 이벤트 기반 아키텍처는 이를 처리하는 데 매우 유용할 수 있고, 아마존은 변경 및 업데이트를 수행하는 간단한 접근 방식을 취했다고 합니다.
복잡성을 자동화하는 것은 또 다른 중요한 교훈이 될 수 있다고 Vogels는 말합니다. 하지만 정확히 무엇을 자동화해야 할까요? 판단력이 필요한 기능에 사람이 있어야하지만, 그렇지않은 대부분의 기능은 자동화가 되어야한다고 주장합니다.
종종 실수를 하는 것은 인간이지 자동화가 아니라고 그는 언급합니다. 특히 보안 분야는 아마존의 자동화에 있어 핵심입니다.
AWS는 하루에 1조 개 이상의 DNS 요청을 처리하고, 매일 124,000개 이상의 악성 도메인을 발견합니다. 이는 모두 인간이 따라할 수 없는, 자동화된 프로세스를 통해 이루어집니다. “자동화는 복잡성을 관리 가능하게 만든다”고 Vogels는 선언합니다. 높은 판단력이 필요하지않은 것은 모두 자동화해야한다고 합니다.
AWS는 하루에 1조 개 이상의 DNS 요청을 처리하고, 매일 124,000개 이상의 악성 도메인을 발견합니다. 이는 모두 인간이 따라할 수 없는, 자동화된 프로세스를 통해 이루어집니다. “자동화는 복잡성을 관리 가능하게 만든다”고 Vogels는 선언합니다. 높은 판단력이 필요하지않은 것은 모두 자동화해야한다고 합니다.
단순성을 가지고 시스템을 안전하며, 복잡하게 확장할 수 있는 “진화성”을 가져야합니다. 복잡성을 관리하기 위해 조각으로 나누고, 그 아키텍처에 맞게 조직을 재편해야합니다. 예측가능한 시스템을 설계하고, 복잡성을 자동화해야합니다. 이것이 Vogels가 전하는 교훈입니다.
지속가능한 성장을 위한 단순성의 유지
전 세계에서 생산되는 음식의 40%가 낭비된다는 질문으로부터 로버트 크리스텐슨(이하 로버트)의 이야기는 시작됩니다. 음식물쓰레기는 전 세계 온실가스 배출량의 10%를 차지하며, 전체 항공산업이 배출하는 양보다 4배 많습니다. 팔리지않고 버려지는 음식 – 이 잉여식품에 대한 문제를 해결하기위해 2015년 덴마크 코펜하겐에서 “TOO GOOD TO GO”가 설립되었습니다.
잉여식품 아이디어는 출시 몇 주만에 세계 최대규모의 잉여식량 앱으로 성장했습니다. 수많은 사용자가 잉여식품을 팔고사며 서로에게 윈윈 하는 선순환이 이루어지고 있습니다.
좋은 신념과 똑똑한 아이디어로 무장한 사업가는 사업이 성장하게 되자 기술적 한계에 봉착했습니다.
좋은 신념과 똑똑한 아이디어로 무장한 사업가는 사업이 성장하게 되자 기술적 한계에 봉착했습니다.
2018년에 등록사용자가 100만명에 도달하자 플랫폼에 문제가 생겼습니다. 시스템은 단일 MySQL과 구식 PHP로 구현된 애플리케이션이었고, 매일 과부하가 발생했습니다. 10명의 엔지니어는 단순함을 유지한 상태에서 확장을 하고 싶어 했고, 기술 투자를 진행했습니다.
지금은 최대 15개 읽기노드를 지원하는 관리형 Amazon Aurora 를 사용하고 있으며, 구식 PHP에서 Java기반 Spring프레임웍으로 순차적으로 재작성 했습니다. 커넥션풀링, 캐시 메시지 – 큐 통합 등의 이점도 누리면서, 단순함을 유지하며 위기를 극복해 냈습니다.
개선을 통해 출시 4년만에 등록사용자는 1,000만명에 달했고, 사용자증가는 가속화되어 새로운 기능을 요구하기에 이르렀습니다.
개선을 통해 출시 4년만에 등록사용자는 1,000만명에 달했고, 사용자증가는 가속화되어 새로운 기능을 요구하기에 이르렀습니다.
단순함을 유지하기 싶었기 때문에 언어와 프레임웍은 고정하되, 트랜잭션, 캐싱, 메시징, 보안 및 백그라운드 프로세스를 패턴화하여 모든 서비스에 적용했습니다.
또한, 캐시와 Amazon OpenSearch가 트랜잭션 데이터베이스를 보호하는 구조를 취하게 되었습니다. 그 결과, 2020년에 2400만명의 등록사용자를 보유하게 되었습니다.
이 후, 북미지역으로 사업을 확장할 때도 기존의 구조를 유지하며, 그대로 복제하되 로컬에서 업데이트된 데이터는 Amazon SNS와 SQS를 사용하여 연결했습니다. 이러한 방식으로 북미지역 전역으로 확장할 수 있었습니다.
호주 지역으로 사업을 확장할 때도 최소한의 노력으로 복제하여 확장할 수 있었습니다.
결과적으로, 현재 1억명이상의 등록사용자 175,000 명 이상의 파트너를 갖춘 커뮤니티로 성장할 수 있었습니다.
결과적으로, 현재 1억명이상의 등록사용자 175,000 명 이상의 파트너를 갖춘 커뮤니티로 성장할 수 있었습니다.
고객이 직면하는 복잡성의 해결을 위해 AWS가 해온 일
클라우드서비스로 고객이 이동하면서 자체보유하던 데이터베이스의 복잡성을 해결하기 위해, Amazon RDS를 이용하여 업그레이드 및 패치는 물론 백업, 복구, 확장을 손쉽게 할 수 있도록 AWS는 지원했습니다.
그럼에도 여전히 혁신이 더 필요하다고 생각한 이유는 기존의 데이터베이스는 거대한 단일체로 구축되어 있었기 때문입니다. Aurora를 통해 DB엔진과 스토리지를 분리하여 더 원활한 확장을 할 수 있게되었고, Aurora Serverless를 통해 더 한계없이 확장할 수도 있습니다.
그럼에도 여전히 혁신이 더 필요하다고 생각한 이유는 기존의 데이터베이스는 거대한 단일체로 구축되어 있었기 때문입니다. Aurora를 통해 DB엔진과 스토리지를 분리하여 더 원활한 확장을 할 수 있게되었고, Aurora Serverless를 통해 더 한계없이 확장할 수도 있습니다.
Amazon DSQL
그리고, AWS는 더 혁신적인 Aurora DSQL이 출시합니다. 멀티리전 간에 낮은 지연으로 강한 동시성을 제공합니다. 이를 통해 전 세계적으로 분산된 애플리케이션을 구축할 수 있는 기반이 마련됐습니다. (아직 N. Virginia, Ohio 리전만 제공합니다.)
시스템 분리, 낮은 결합성, 블록 내부의 높은 응집력, 잘 정의된 API로 구성요소로 개별적인 확장을 할 수 있습니다.
이를 통해 시스템의 세밀한 제어가 가능하며, 필요에 따라 구성요소를 개별적으로 확장할 수 도, 특정요구사항에 따라 보안을 조정할 수도 있습니다.
이를 통해 시스템의 세밀한 제어가 가능하며, 필요에 따라 구성요소를 개별적으로 확장할 수 도, 특정요구사항에 따라 보안을 조정할 수도 있습니다.
SQL의 상위레벨 블록은 프론트엔드, 대분의 SQL처리를 하는 쿼리프로세서, 트랜잭션을 조정하는 Adjusticator, 단기스토리지를 저장하는 저널(Journal), 딘기항목을 장기스토리지에 저장하는 크로스바가 있습니다. 쿼리프로세서는 세션 수에 따라, Adjustcator는 트랜잭션 수에 따라, 저널은 스토리지단위가 보유한 처리량에 따라, 크로스바는 보유중인 저널 수 및 데이터베이스의 크기에 따라 개별적으로 확장됩니다. 단일 모노리스구조라면 아마 엄청나게 비효율적인 확장을 해야했을 것입니다.
클라이언트 앱이 조회를 할 경우, 프론트엔드를 거쳐 쿼리프로세서로 들어온 읽기요청의 수행을 위해 트랜잭션경로를 거칠 필요없이, 샤드맵을 참조하여 데이터가 저장된 스토리지로 접근해야합니다.
읽기만 수행하므로, 다소 복잡하진 않습니다.
읽기만 수행하므로, 다소 복잡하진 않습니다.
클라이언트 앱이 주문을 하게되는 경우, 조회하고, 선택하고, 선택에 따른 조회, 선택하는 과정을 거치는데, 모든 명령을 쿼리프로세서에서 병합하여 트랜잭션을 수행하며 커밋을 기다리게 됩니다. 모든 명령은 지역 내에서만 발생하며, 커밋단계에서만 리전간 통신이 발생하는 만큼 트랜잭션 수행이 빠르다는 의미입니다.
쿼리프로세서는 베어메탈 호스트에 마이크로VM에 배치되어 고객의 결정이 내려지지않아 커밋이 지연될때 마이크로VM의 일시중지하고, 고객으로부터의 작업이 재개되면 몇밀리초 내에 마이크로VM의 스냅샷이 복원되어 트랜잭션이 진행됩니다. 이러한 방식으로 장기 트랜잭션을 최적화할 수 있습니다.
단기스토리지인 저널에 기록되면 커밋된 것으로 간주하며, 샤딩된 스토리지의 댭변을 기다릴 필요없이 빠르게 완료됩니다. 각 부분들은 독립적으로 작동하여, 복잡성 원칙을 따르는 아키텍처의 예시입니다.
이게 다가 아닙니다. DSQL을 성공시키기 위해 AWS는 분산시스템의 걸림돌인 시간동기화 문제에도 관심을 기울였습니다.
이게 다가 아닙니다. DSQL을 성공시키기 위해 AWS는 분산시스템의 걸림돌인 시간동기화 문제에도 관심을 기울였습니다.
Amazon Time Sync
AWS가 기존의 시간동기화의 중심이었던 NTP의 한계를 극복하고, 정확도가 높은 동기화된 시계를 갖기위해 FPGA하드웨어, Nitro카드와 백본, 위성으로 구성된 전용인프라를 구성하여 얻어낸 Amazon Time Sync는 마이크로 초 단위의 정확성을 보유합니다. 이로써 DSQL에서도 트랜잭션이 시작된 시기와 커밋된 시기를 정확하게 비교할 수 있습니다. 이 시점에 AWS를 제외하고 시간동기화 서비스를 이러한 수준으로 받을 수 있는 곳은 거의 없습니다.
실세계에서 벌어질 수 밖에 없는 오차에 대한 해결을 위해 Clock Bound라는 시스템을 활용하여 사용자에게는 결과적으로 나노초단위의 정확성을 가지는 시계를 제공한다고 합니다.
이러한 토대 위에 전 세계에 애플리케이션을 운용할 수 있는 DB기반인 Aurora DSQL, DynamoDB global tables이 제공되고 있습니다. 정확히 동기화된 시계는 분산시스템의 복잡성을 크게 줄일 수 있기 때문입니다.
이러한 토대 위에 전 세계에 애플리케이션을 운용할 수 있는 DB기반인 Aurora DSQL, DynamoDB global tables이 제공되고 있습니다. 정확히 동기화된 시계는 분산시스템의 복잡성을 크게 줄일 수 있기 때문입니다.
동기화된 시계가 시스템의 복잡성을 크게 줄이는데 도움이 되는지 스스로 확인해 보라는 요청을 합니다.
앞서 이야기했던 수많은 요소들에 더해 가장 기본적인 마지막 요소인 시간을 마지막으로 Vogels의 교훈은 끝이 납니다.
앞서 이야기했던 수많은 요소들에 더해 가장 기본적인 마지막 요소인 시간을 마지막으로 Vogels의 교훈은 끝이 납니다.
결론
2024 Re:Invent에 참여하면서 수많은 Amazon사용자들이 Vogels 박사에 대해 열광하는 이유를 알 수 있는 Keynote였습니다. 특히, DynamoDB를 SQL로 핸들링할 수 있는 DSQL의 트랜잭션 보장을 통하여, 전 세계를 대상으로 한 애플리케이션의 손쉬운 운용이 가능해졌고, NTP의 지연한계를 극복하는 Time Sync서비스의 향후 영향이 궁금해 졌습니다.
AWS가 DB를 완전히 새롭게 썼고, 아카데믹한 내용을 크게 벗어나는 내용이라 경이롭게 까지 합니다.
라스베가스의 열기를 기술로 승화하는 멋진 이벤트였네요.
이벤트 마지막 밤을 아쉽게 보내는 지금입니다.
감사합니다.
AWS가 DB를 완전히 새롭게 썼고, 아카데믹한 내용을 크게 벗어나는 내용이라 경이롭게 까지 합니다.
라스베가스의 열기를 기술로 승화하는 멋진 이벤트였네요.
이벤트 마지막 밤을 아쉽게 보내는 지금입니다.
감사합니다.
글 │메가존클라우드 , Strategic Tech Centerr, Cloud Architect 1팀, 이태훈 매니저
게시물 주소가 복사되었습니다.