이 게시글에서는 "천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기"를 보면서 얻은 것들을 기록하려고 한다. 나중에 성장한 후에 현재의 나를 되돌아볼 수 있도록, 다른 글과는 다르게 두서없이 지금의 생각을 그대로 담아 작성할 예정이다.
1. 영상을 보게 된 이유
평소에 AWS Builders 온라인 시리즈를 통해 AWS의 서비스들에 대한 정보를 자주 얻고는 했지만, "천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기" 시리즈는 다소 난해하게 느껴졌다. 특히, 과거 영상들은 서버 기반이나 서버리스 아키텍처에 다양한 서비스들을 결합하여 설명했기 때문에 복잡하게 느껴졌었다. 하지만 최근에는 컨테이너 서비스에 대한 소개가 많아졌고, 나 역시 최근 AWS ECS를 통해 배포를 경험하면서 이제는 이해할 수 있을 것 같다는 생각에 영상을 보게 되었다. 이번 기회를 통해 AWS 아키텍처에 대한 이해를 더욱 깊게 다지고, 나의 클라우드 인프라 설계 역량을 강화할 수 있을 것이라고 기대했다.
2. 후기
이번 영상을 보면서 과거에 비해 클라우드 지식이 많이 늘었다는 것을 실감했다. 과거에는 단순히 AWS의 다양한 서비스를 개별적으로 이해하려고 했던 것에 비해, 이제는 전체적인 아키텍처 구성과 그에 따른 최적화를 고민하게 된 나 자신을 발견할 수 있었다. 이번 후기는 다른 글들과 다르게, 영상을 통해 배운 내용을 정리하면서 현재의 나의 생각을 정리해보려고 한다.
2-1. 100명 이하의 사용자
100명 이하의 사용자에서는 기본적인 아키텍처만을 소개한다. 이 시점에서는 ELB조차 사용하지 않고, Elastic IP를 통해 고정 IP를 사용하며, Public subnet과 Private subnet을 이용해 외부 사용자가 접근하는 네트워크와 내부 데이터를 저장하는 네트워크를 구분했다. 또한, Security group을 사용해 필요한 포트와 IP만 접근할 수 있도록 설정했다. 참고로 AWS Shield는 DDoS 공격을 방어하는 서비스로, AWS를 사용하면 기본적으로 제공된다.
이 단계에서는 비용 효율적인 구성이 가장 중요하다. 작은 사용자 규모에서는 복잡한 아키텍처보다 간단하고 관리하기 쉬운 구조가 적합하며, 이 점에서 이러한 아키텍처는 매우 합리적이라고 생각한다. 실제로 소규모 프로젝트나 스타트업에서는 이런 식으로 최소한의 자원으로 최대한의 성능을 이끌어내는 것이 필요하다. 비용 절감을 위해 최적화된 리소스 활용이 중요하며, 이 시점에서는 클라우드 비용을 신중하게 관리하는 것이 필수적이다.
2-2. 1,000명 이상의 사용자
1,000명 이상의 사용자가 되면, 가용성을 높이기 위해 ELB를 도입해 다중 가용 영역을 지원하는 구성을 도입한다. 또한, AWS RDS를 사용하여 데이터베이스 관리가 자동화되도록 하여, DBA들이 애플리케이션 성능 최적화에 더 집중할 수 있게 했다. 읽기, 쓰기 인스턴스를 이중화하여 성능을 더욱 강화했다.
이 단계부터는 사용자 경험을 개선하기 위해 시스템의 안정성을 중시하게 된다. ELB를 도입하여 다중 가용 영역을 지원하는 것은 이러한 목적에 적합한 선택이며, 더 많은 사용자를 수용할 수 있는 준비된 아키텍처라 할 수 있다. 이 시점에서는 장애 발생 시에도 빠르게 복구할 수 있는 능력이 중요해지며, 이중화와 자동화된 복구 시스템을 통해 사용자가 느끼는 불편을 최소화할 필요가 있다. 이를 통해 서비스 가용성을 극대화하고, 예기치 않은 장애 상황에도 대비할 수 있다.
2-3. 10,000명 이상의 사용자
10,000명 이상의 사용자가 되면, 트래픽 변화에 능동적으로 대응하기 위해 Auto Scaling Group을 도입해 컴퓨팅 리소스를 자동으로 조절하도록 설정했다. 웹 성능을 개선하기 위해 CloudFront를 사용해 HTML, CSS, JS와 같은 정적 콘텐츠뿐만 아니라 이미지와 동영상 등의 콘텐츠를 S3에서 캐싱하도록 했다. 동적인 요청에 대해서는 CloudFront와 VPC 간의 내부 전용선을 통해 더 빠르게 전송되도록 하였고, 앞서 설정한 ELB를 통해 각 인스턴스와 DB에 접근하도록 구성했다.
이 단계에서는 트래픽의 급격한 변동에 대응할 수 있는 유연한 아키텍처가 필수적이다. Auto Scaling Group과 CloudFront를 도입하여 성능과 비용을 동시에 고려한 구성이 매우 적절하다고 생각한다. 이 시점에서는 사용자 수의 증가에 따라 리소스 사용량도 급격히 증가하므로, 자동화된 리소스 관리와 성능 최적화가 필수적이다. 또한, 콘텐츠 배포 네트워크(CDN)를 통해 전 세계 사용자에게 빠른 응답 시간을 제공할 수 있다는 점에서 CloudFront의 도입이 큰 역할을 한다.
2-4. 100,000명 이상의 사용자
100,000명 이상의 사용자가 되면, 컨테이너 환경의 아키텍처를 도입해 운영의 효율성을 높이는 것이 중요해진다. AWS ECS 또는 EKS를 추천하며, 영상에서는 EKS를 주로 언급했다. 또한 성능을 더욱 높이기 위해 ElasticCache를 사용해 읽기 캐시를 적용했다.
이 단계에서는 컨테이너 환경을 통해 운영 효율성을 극대화하는 것이 중요하다. 영상에서도 언급한 내용이지만, 컨테이너 환경의 러닝 커브 문제를 제외하면 장기적인 안정성과 성능 향상을 위해서 초기부터 도입을 고려하는 것도 좋다고 한다. 또한, ElasticCache와 같은 캐시를 사용하여 데이터베이스 부하를 줄이는 것을 추천한다. 이 시점에서는 대규모 사용자 트래픽에 대응하기 위해 고성능의 데이터 처리 및 응답 속도를 유지하는 것이 필수적이며, 이를 위해 효율적인 자원 관리와 최적화된 성능 튜닝이 필요하다.
2-5. 1,000,000명 이상의 사용자
1,000,000명 이상의 사용자가 되면, 용도에 맞는 데이터베이스를 사용해 성능을 최적화하는 것이 필수적이다. 이를 위해 NoSQL 데이터베이스인 DynamoDB를 사용했으며, 데이터의 안정성을 위해 멀티 리전 서비스를 도입했다.
이 단계에서는 데이터베이스의 성능 최적화와 안정성이 매우 중요하다. 다양한 리전에서 데이터를 관리하고, 재해 발생 시 신속하게 다른 리전으로 전환할 수 있는 멀티 리전 구성이 매우 적합하다. 이 단계에 도달하면 글로벌 서비스로서의 성격이 강해지기 때문에, 여러 리전에 분산된 데이터를 일관되게 관리하는 것이 핵심 과제가 된다. 이를 통해 각 지역의 사용자에게 최적의 응답 시간을 제공하고, 서비스의 안정성을 높일 수 있다.
2-6. 10,000,000명 이상의 사용자
10,000,000명 이상의 사용자가 되면, 단순히 재해 복구를 넘어 다중 리전 서비스를 고려해야 한다. 또한, 글로벌 데이터베이스 서비스를 도입해 여러 리전에 걸쳐 데이터베이스를 운영하는 구성을 택했다.
이 단계에 도달한 서비스는 이미 국내에서 20위권 안에 들어가는 수준의 대규모 서비스다. 이런 수준의 서비스라면, 다중 리전 아키텍처를 통해 전 세계 사용자를 대상으로 안정적인 서비스를 제공해야 하며, 데이터의 일관성과 가용성을 보장하기 위한 추가적인 고민이 필요하다. 글로벌 서비스를 운영하기 위해서는 각 리전의 특성과 규제에 맞는 데이터 관리 전략을 세우는 것이 중요하며, 이에 맞는 아키텍처 설계가 필수적이다.
2-7. 마무리
사실, 앞에서 다룬 내용들은 일반적인 Best Practice에 가깝다. 완전한 정답은 없으며, 상황에 따라 순서가 바뀌거나 추가적인 고려사항이 필요할 수도 있다. 하지만 위에 언급된 원칙들은 반드시 고려해야 할 요소들이다.
2-8. 생각 정리
이일구님의 "천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기"를 보며 많은 것을 배우고 느낄 수 있었다. 일반적인 Best Practice를 보면서 생각보다 오버 엔지니어링 측면이 많다는 생각이 들었고, 앞으로 아키텍처를 구성할 때 비용, 성능, 안전성을 더 깊이 고민해야겠다고 생각했다.
특히, 마지막에 언급된 원칙들을 보며 이중화의 중요성을 다시 한번 깨달았다. 과거에는 비용 때문에 이중화를 고려하지 않았지만, 이제는 안정성을 위해 필수적으로 고려해야 할 부분임을 알게 되었다.
사실 100,000명 이상의 사용자부터는 EKS로 소개되어 이해하기 쉽지 않았지만, 과거 처음 영상을 접했을 때와 비교하면 훨씬 많이 이해하고 공감할 수 있었다. 앞으로도 열심히 공부해서 100,000명 이상의 사용자 규모에서도 이해하고 공감할 수 있는 수준으로 성장하고 싶다.
