올해로 13회를 맞이한 AWS re:Invent 행사에, 에스티씨랩은 과학기술정보통신부와 NIPA(정보통신산업진흥원)의 지원사업을 통해 K-SaaS 기업 공동관 부스 전시에 참여했습니다.
관련 글)
AWS re:Invent(리인벤트) K-SaaS 부스 전시 참여... [링크]
이와 함께, 다른 솔루션 기업들의 최신 트렌드와 솔루션 방향성을 살펴보고, 경쟁사 제품과의 차별화 포인트를 확립하기 위한 인사이트를 도출하고자 다양한 세션과 부스에 참여했습니다. 그 중 인상깊었던 AWS 키노트 내용을, CTO인 헨리의 글로 확해보겠습니다.
AWS re:Invent(리인벤트) 2024 참관기(1) - CEO KeyNote... [링크 클릭]
AWS re:Invent(리인벤트) 2024 참관기(2) - AI & Data VP KeyNote... [링크 클릭]
AWS CTO Dr. Werner Vogels는 '복잡성'이라는 키워드로 키노트를 시작했습니다. Vogels 박사가 AWS 입사 후 20년 동안 끊임 없이 배움을 이어가면서 얻게된 복잡성에 대한 인사이트와, 조직 운영을 통해 혁신을 이룬 경험을 공유했습니다.
복잡성은 생성되거나 사라지는 것이 아니라, 단지 다른 곳으로 이동할 뿐인 필연적인 요소라고 합니다. 복잡성에는 의도된 복잡성과 의도되지 않은 복잡성이 존재하며, 이 중 의도된 복잡성은 시스템 확장, 새로운 기능 적응, 고객 요구 변화에 대응하기 위해 필요한 것이며 명확한 목적을 가지고 있다고 설명합니다.
반면, 의도되지 않은 복잡성은 아래의 7가지가 있으며, 피할 수 없는 이들 복잡성을 적절하게 관리하는 중요하다고 말해줍니다.
- 기능 속도 감속
- 잦은 문제
- 오래 걸리는 디버깅
- 과도한 코드 증가
- 일관되지 않은 패턴
- 종석성 증가
- 차별화되지 않은 업무
잠시, Canva CTO인 Brendan Humphreys의 강연이 이어졌습니다.
Canva는 전 세계 누구나 손쉽게 디자인할 수 있도록 돕기 위해 설립된 서비스 플랫폼입니다. 현재 약 190개국의 2억 2천만명 이상의 사용자가 초당 약 120만 건의 요청을 발생시키고 있으며, 매일 약 230TB에 달하는 데이터를 새롭게 추가하고 있습니다.
사업 초기 Canva는 소규모 팀으로 모놀리식 아키텍처를 구축하고, 하나의 MySQL 인스턴스에서 시작해 필요에 따라 여러 인스턴스로 확장해 나갔다고 합니다. 그러나 서비스 규모가 커지면서 MySQL 데이터베이스의 한계에 직면하게 되었고, 이를 해결하기 위해 쉽지 않은 과정을 거쳐 DynamoDB로의 전환을 성공적으로 마쳤습니다. 현재는 약 930억 개의 항목을 관리하고 있으며, 매일 약 9천만개의 항목이 추가되고 있다고 합니다.
만약 MySQL 인스턴스만 고집했다면 서비스 확장은 멈췄을 것이라고 생각됩니다. Canva는 전환을 시도해 확장성을 확보했으며, API와 SDK를 제공함으로써 개발자들이 Canva 플랫폼 위에 다양한 기능을 구축할 수 있도록 지원하고 있습니다.
진화 가능성은 필수 요건
Vogels 박사가 발표를 이어갔습니다. 그는, 변화는 끊임없이 일어나며, 소프트웨어에 새로운 기능을 계속 추가하지 않으면 결국 품질이 떨어질 수 있다고 이야기합니다. 그리고 AWS는 이를 대비하기 위하 다음과 같은 가이드를 제시한다고 하네요.
- 진화 가능성을 필수 요건으로 설정
- 아키텍처 선택을 주기적으로 검토
S3를 예를 들어 설명해주었습니다. S3는 초기 약 6개의 마이크로 서비스로 시작했으나, 현재는 300개 이상의 서비스로 확장되었습니다. 이러한 변화에도 불구하고 고객에게 영향을 주지 않고 안정적으로 운영되는 것은 아래와 같은 변화 과정을 거쳤기 때문이라고 합니다.
- 프론트엔드 단순화
- 시스템 구성 원칙 정립
- CloudWatch를 통한 새로운 기능 추가
- 프로그래밍 언어의 변화(C언어에서 Rust로 변경)
- 서비스 크기 결정
AWS의 대표 서비스인 S3는 오랜 역사를 가지고 있으며, 안정적인 서비스로 고객에게 사랑받고 있습니다. 이는 끊임없는 진화를 통해 지속적으로 서비스를 개선하고 발전해 온 결과라고 생각합니다.
조직의 복잡성을 해결하는 방법
Vogels 박사는 18년 간 혁신을 이끌어 온 S3도 조직의 복잡성을 완전히 해결하지는 못했다고 합니다. 다만, 아래 두 가지 중요한 교훈을 얻었다고 합니다.
1) 복잡성과 두려움: 성공적인 팀은 항상 "무엇이 잘못될 수 있을까?"라는 약간의 두려움을 가지고 있다고 말합니다.
2) 주인의식: 훌륭한 리더는 팀원들이 주인의식을 갖고 동기부여를 느낄 수 있도록, 팀에게 문제를 해결할 수 있는 권한과 책임을 부여한다고 말합니다.
복잡성에 대응하기 위해서는, 시스템을 분해하고 독립적으로 작동하는 블록을 만들어야 합니다. 복잡한 시스템일수록 각 서비스 간 영향을 최소화하는 것이 중요합니다. 이를 위해 분산된 서비스 처리를 지원하는 라우터가 필요하며, 전체 셀의 가용성으 ㄹ관리할 수 있는 컨트롤 플레인도 필수적입니다.
자동화를 통한 불확실성 대응
Vogles는 불확실성을 또 다른 주요 문제로 언급했습니다. 불확실성을 해결하기 위해 예측 가능한 시스템을 설계하는 것이 중요하며, 이벤트 기반의 아키텍처가 이러한 문제를 처리하는 데 매우 유용할 수 있다고 강조했습니다.
복잡성을 자동화하는 것은, 무엇을 자동화할 것인가에 대한 판단이 우선 중요합니다. 판단력이 요구되는 기능에는 인간의 개입이 필요하지만, 그렇지 않은 대부분의 지능은 자동화되어야 한다고 주장했습니다. '종종 실수를 저지르는 것은 인간이지, 자동화가 아니다'라고 강조하며, 특히 보안 분야에서 자동화가 아마존의 핵심 전략 중 하나임을 언급했습니다.
AWS는 하루에 1조개 이상의 DNS 요청을 처리하며, 매일 124,000개 이상의 악성 도메인을 탐지하고 있습니다. 이 모든 작업은 사람이 처리할 수 없는 규모로, 자동화된 프로세스를 통해 이루어지고 있습니다. '자동화는 복잡성을 관리 가능하게 만든다'고 강조하며, 높은 판단력이 필요하지 않은 모든 작업은 자동화해야 한다고 주장합니다.
Vogles가 전하는 핵심은 이렇습니다.
시스템은 단순성을 유지하면서도 안전하고 복잡하게 확장할 수 있는 '진화성'을 가져야 하며, 이를 위해 복잡성을 관리 가능한 조각으로 나누고, 그 아키텍처에 맞게 조직을 개편해야 합니다. 또한, 예측 가능한 시스템을 설계하고 복잡성을 자동화하는 것이 중요합니다.
복잡성 해결을 위한 AWS가 한 일
AWS는 기존 데이터베이스가 거대한 단일체로 구축되어 있다는 한계를 인식하고, 더 혁신적인 접근이 필요하다고 판단했습니다. 이에 따라 Aurora를 통해 데이터베이스 엔진과 스토리지를 분리해 더 유연하고 원활한 확장이 가능하도록 했으며, Aurora Serverless를 통해 사실상 무제한 확장이 가능한 환경을 제공하게 되었습니다.
1) Amazon Aurora DSQL: 아키텍처
AWS가 출시한 Aurora DSQL은, 멀티리전 간 낮은 지연 시간과 강력한 동시성을 제공하여 전세계적으로 분산된 애플리케이션을 구축할 수 있는 기반을 마련해줍니다. 시스템 분리, 낮은 결합성, 블록 내부의 높은 응집력, 그리고 잘 정의된 API를 통해 구성 요소를 개별적으로 확장할 수 있으며, 이를 통해 시스템을 세밀하게 제어할 수 있을 뿐 아니라 필요에 따라 구성 요소를 독립적으로 확장하거나 특정요구사항에 맞춰 보안을 조정하는 것도 가능합니다.
SQL의 상위 레벨 블록은 프론트엔드, 대다수 SQL 처리를 담당하는 쿼리 프로세서, 트랜잭션을 조정하는 어드저스티케이터(Adjusticator), 단기 스토리지를 저장하는 저널(Journal), 그리고 장기 스토리지를 관리하는 크로스바(Crossbar)로 구성됩니다. 이 블록들은 각각의 역할에 따라 개별적으로 확장할 수 있습니다. 예를 들어, 쿼리 프로세서는 세션 수에 따라, 어드저스티케이터는 트랜잭션 수에 따라, 저널은 스토리지 단위의 처리량에 따라, 크로스바는 보유 중인 저널 수와 데이터베이스 크기에 따라 확장됩니다. 만약 단일 모놀리식 구조였다면, 이러한 세분화된 확장이 불가능해졌을 것이며, 비효율적으로 대규모 확장을 해야 했을 것입니다.
클라이언트 앱에서 조회 요청이 들어오면, 프론트엔드를 거쳐 쿼리 프로세서로 전달됩니다. 이때, 읽기 요청은 트랜잭션 경로를 거칠 필요 없이 샤드 맵을 참조해 데이터가 저장된 스토리지에 직접 접근합니다. 읽기 작업만 수행하므로 처리 과정이 비교적 간단합니다.
클라이언트 앱에서 주문을 진행할 경우, 조회, 선택, 선택에 따른 추가 조회, 그리고 다시 선택하는 과정을 거칩니다. 이 모든 명령은 쿼리 프로세서에서 병합되어 하나의 트랜잭션으로 처리되며, 최종적으로 커밋을 기다리게 됩니다. 특히, 모든 명령은 지역 내에서 처리되고, 커밋 단계에서만 리전 간 통신이 이루어지기 때문에 트랜잭션 수행 속도가 빠릅니다.
쿼리 프로세서는 베어메탈 호스트에 배치된 마이크로 VM에서 실행됩니다. 고객의 결정이 지연되어 커밋이 대기 상태가 되면, 마이크로 VM은 일시적으로 중지됩니다. 이후 고객이 작업을 재개하면, 몇 밀리초 내에 마이크로 VM의 스냅샷이 복원되어 트랜잭션이 이어서 진행됩니다. 이러한 방식은 장기 트랜잭션을 효율적으로 최적화하는 데 큰 도움을 줍니다.
단기 스토리지인 저널에 기록되면 해당 작업은 커밋된 것으로 간주되며, 샤딩된 스토리지의 응답을 기다릴 필요 없이 빠르게 완료됩니다. 각 구성 요소가 독립적으로 작동하는 이러한 방식은 복잡성을 효과적으로 관리하는 아키텍처 원칙을 잘 보여주는 사례입니다.
2) Amazon Aurora DSQL: 시간 동기화
이게 전부가 아닙니다. DSQL의 성공을 위해 AWS는 분산 시스템에서 큰 걸림돌이 되는 시간 동기화 문제에도 집중했습니다.
기존 시간 동기화 방식인 NTP의 한계를 극복하기 위해, AWS는 FPGA 하드웨어, Nitro 카드와 백본, 위성을 기반으로 한 전용 인프라를 구축했습니다. 이를 통해 개발된 Amazon Time Sync는 마이크로초 단위의 정확성을 제공합니다.
이로 인해 DSQL에서도 트랜잭션의 시작 시점과 커밋 시점을 정확히 비교할 수 있게 되었으며, 이는 분산 시스템의 성능과 신뢰성을 크게 향상시켰습니다. 현재 이러한 수준의 시간 동기화 서비스를 제공할 수 있는 곳은 AWS를 제외하고 거의 없습니다.
이러한 기반 위에서 AWS는 전 세계적으로 애플리케이션을 운용할 수 있는 데이터베이스 솔루션인 Aurora DSQL과 DynamoDB Global Tables를 제공합니다. 정확히 동기화된 시계는 분산 시스템의 복잡성을 크게 줄이는 데 핵심적인 역할을 하게 됩니다.
Vogels는 동기화된 시계가 시스템의 복잡성을 얼마나 크게 줄이는지 스스로 확인해 보라고 제안합니다. 앞서 이야기했던 수많은 요소들에 더해, 가장 기본적이면서도 중요한 마지막 요소인 "시간"을 강조하며 그의 Keynote를 마무리합니다.
제품이 확장되고 고도화됨에 따라 복잡성이 필연적으로 증가하고, 그럼에도 이를 극복하기 위해 지속적인 진화가 필요하다는 점이 현재 에스티씨랩의 상황과 맞닿아 있어 크게 공감했습니다. 끓는 물 속의 개구리처럼, 천천히 뜨거워지는 물에 안주하는 서비스는 결국 퇴보하는 것이죠.
복잡성을 어떻게 구분하고 관리할 것인지에 대한 고민을 이어가던 시점에서, 이를 항목별로 세분화해 접근하고 관리하는 방안에 대해서도 큰 인사이트를 얻을 수 있었습니다. 또한, 모놀리식 아키텍처에서 마이크로서비스로의 전환은 필수적인 흐름이라는 점과, 복잡성이 증가하는 상황에서 Vogels 박사가 강조한 Simplexity(단순함과 복잡성의 조화)를 추구해야 한다는 메시지는 매우 중요하게 다가왔습니다.
새롭게 출시된 Aurora DSQL 기능은 특히 인상적이었으며, 수많은 서비스와 개발자들이 지적해온 데이터베이스 확장과 성능 문제를 AWS만의 방식으로 해결하고자 한 점이 돋보였습니다. 이 기능들이 실제 서비스에 적용될 때 성능과 효과를 얼마나 발휘할지 궁금해졌습니다. 특히 글로벌 서비스를 제공하는 자사의 SaaS 서비스(SCP)에 적용한다면 상당한 성능 향상과 효과를 기대할 수 있을 것 같습니다. 다만, 초기 제품은 높은 비용이 수반되기 때문에 성능과 서비스 검증 후 그 결과에 따라 적용 여부를 검토해보는 것이 적절하겠다는 생각이 들었습니다.
에스티씨랩도 고객의 문제를 해결하기 위해 다양한 기능과 제품을 지속적으로 확장해 나가고 있습니다. 이러한 과정에서 복잡성과 단순화에 대해 더 깊이 고민하고, 안정적으로 제품을 제공할 수 있도록 끊임없이 투자하고 노력해야겠다는 다짐을 하게 됩니다.
'People & Culture > Surfer's Daily' 카테고리의 다른 글
| [STCLab 전사 워크숍] #2. 첫 만남에도 왠지 신나 우리 (0) | 2025.02.18 |
|---|---|
| [STCLab 전사 워크숍] #1. 기회의 25년, 함께 시작합니다 (1) | 2025.02.17 |
| AWS re:Invent(리인벤트) 2024 참관기(2) - AI & Data VP KeyNote (0) | 2025.02.04 |
| AWS re:Invent(리인벤트) 2024 참관기(1) - CEO KeyNote (0) | 2025.02.03 |
| 열심히 일한 서퍼들의 Refresh Day 엿보기 (0) | 2024.12.20 |
