아키텍처 관점에서 늘어나는 트래픽 대응하기

개요

아키텍처의 관점에서 늘어나는 트래픽을 어떻게 대응하면 좋을지에 대해 흐름에 따라 작성했습니다. 피드백은 언제든 환영이며 댓글 남겨주시면 감사하겠습니다.

 

한대의 인스턴스

먼저 가장 간단한 구성입니다. 모든 트래픽이 한 대의 서버를 통해 관리되고 있습니다. 그리고 EC2의 IP가 유동적으로 변경되는 것을 방지하기 위해 Elastic IP를 연결시켜 놓았습니다.

그러나 시간이 지나면서 사용자 수가 증가하고, 이에 따라 서버로의 트래픽도 늘어나기 시작했습니다. 이로 인해 EC2 인스턴스의 CPU 사용률이 증가하여 단일 EC2 인스턴스로는 증가하는 트래픽을 처리하는데 한계가 생기기 시작했습니다. 이 시점에서 고려할 수 있는 가장 기본적인 해결 방안은 EC2의 인스턴스 사양을 업그레이드하는 Scale-Up입니다.

 

Scale-Up

위와 같이 T2 사양의 인스턴스를 T3로 업그레이드하여 처리 능력을 향상시킬 수 있습니다. 가장 간단한 방법이지만 T2에서 T3로 스케일 업하는 동안 서비스가 일시적으로 중단되어 해당 시간 동안 사용자의 요청을 처리할 수 없게 되는 인스턴스의 다운타임의 문제도 존재합니다.

 

Scale-Out

스케일 업을 통해 처리 능력을 증가시켰음에도 서비스 사용자 수가 계속해서 증가하면서 트래픽을 더 이상 감당할 수 없는 수준에 도달했습니다. 물리적 리소스의 한계에 부딪혀 더 이상의 스케일 업이 불가능해지고, 비용적인 부담도 계속해서 증가하게 되는 상황입니다. 이 상황에서는 여러 대의 인스턴스를 추가하여 트래픽을 분산시키는 Scale-Out 방식을 적용할 수 있습니다.

위와 같이 스케일 아웃을 통해 여러 대의 EC2 인스턴스를 추가함으로써, 기존의 트래픽을 여러 인스턴스에 분산시켜 처리할 수 있게 됩니다. 그러나 이 방식을 사용하면 Elastic IP는 고정 IP주소로 한 번에 하나의 인스턴스에만 연결할 수 있기 때문에 사용자가 각 인스턴스에 접근하기 위해 해당 인스턴스의 Elastic IP를 모두 알아야 한다는 단점이 존재합니다. 따라서 N개의 인스턴스가 존재하는데 사용자들이 기존의 IP만 알고 있어서 해당 IP에만 접근한다면 부하가 분산되지 않을 것입니다.

 

DNS

사용자가 여러 인스턴스에 접근하기 위해 각각의 IP 주소를 알아야 하는 번거로움을 해결하기 위해 도메인 네임 시스템(DNS)을 활용할 수 있습니다. 이를 통해 사용자는 IP 주소 대신 dkswnkk.com과 같은 기억하기 쉬운 도메인 이름을 통해 서비스에 요청을 보낼 수 있게 됩니다. AWS에서는 Route 53이라는 서비스를 통해 이러한 도메인 관리 기능을 제공합니다.

Route 53을 활용하면 단일 도메인 이름에 여러 IP 주소를 연결하는 것이 가능하며, 이를 통해 사용자의 요청을 다양한 정책에 따라 적절한 서버로 전송할 수 있습니다. 이 과정에서 Route 53은 아래와 같이 다양한 라우팅 정책을 제공하며, 요구 사항에 맞게 선택하면 됩니다.

• 단순 라우팅(Simple routing policy): 가장 기본적인 라우팅 방식으로, 하나의 도메인에 하나의 리소스(서버 또는 IP 주소)를 연결합니다.
• 가중치 기반 라우팅(Weighted routing policy): 트래픽을 여러 리소스에 분산시키되, 각 리소스에 가중치를 할당하여 트래픽의 분배 비율을 조정할 수 있습니다. A/B 테스팅 또는 점직전인 배포와 같은 상황에서 유용하게 사용됩니다.
• 지역 기반 라우팅(Geolocation routing policy): 사용자의 지리적 위치에 따라 트래픽을 다르게 라우팅 합니다. 이를 통해 사용자에게 더 빠른 응답 시간을 제공하거나 지역적 제한을 적용할 수 있습니다.
• 헬스 체크 기반 라우팅(Health Checks): 서버의 상태를 주기적으로 확인하고, 문제가 발생한 서버에 대한 요청을 정상적인 서버로 자동으로 전환합니다.
• 레이턴시 기반 라우팅(Latency-based Routing): 사용자와 가장 낮은 지연 시간을 가진 서버로 트래픽을 라우팅 하여, 사용자에게 최적의 성능을 제공합니다.

더 자세하고 많은 정책은 공식 문서에서 확인 가능합니다.

 

DNS 문제점

그러나 특정 상황에서 문제가 생길 수 있는데, 바로 EC2 인스턴스 중 하나가 제거되었거나 서버가 다운된 상황입니다. DNS의 TTL(Time-to-Live) 설정 때문에, DNS 정보가 일정 시간 동안 캐싱되어 유지됩니다. 이 TTL 기간 동안에는 사용자들이 DNS를 통해 서비스에 접근하더라도 이미 다운되거나 제거된 인스턴스로의 요청을 시도할 수 있으며, 이 경우 사용자는 TTL이 만료되기 전까지는 DNS Query로 새로운 IP를 얻어오지 못해 요청에 대한 응답을 받지 못하게 됩니다.

 

Elastic Load Balancer(ELB) 사용

이러한 문제를 해결하기 위해 Elastic Load Balancer(ELB)를 사용할 수 있습니다. EC2 인스턴스들의 IP 주소 대신 ELB의 IP 주소를 DNS 설정에 사용함으로써, 인스턴스의 추가나 제거가 이루어지더라도 ELB가 지속적으로 인스턴스들의 상태를 모니터링하여 사용 가능한 인스턴스들에게만 트래픽을 분배할 수 있습니다.

ELB는 트래픽의 분산을 위해 다양한 라우팅 정책을 제공하는데, 대표적인 주요 라우팅 정책은 다음과 같습니다.

• 라운드 로빈(Round Robin): 가장 기본적인 라우팅 방식으로, 요청을 순서대로 각 인스턴스에 균등하게 분배합니다.
• 가중치 할당(Weighted): 각 인스턴스에 가중치를 할당하여, 특정 인스턴스에 더 많거나 적은 트래픽을 보낼 수 있습니다. 인스턴스의 성능이나 용량이 다를 때 유용하게 사용됩니다.
• 최소 연결(Least Connections): 가장 적은 연결을 가진 인스턴스에 우선적으로 트래픽을 할당합니다.

마찬가지로 더 자세하고 많은 정책은 공식 문서에서 확인 가능합니다.

 

Auto-Scaling 사용

만약 인스턴스를 수동으로 관리하는 과정이 복잡하고 시간을 많이 소요한다면, Auto Scaling을 사용할 수도 있습니다. Auto Scaling 그룹을 설정하면, 시스템이 자동으로 인스턴스의 수를 조절하여 트래픽 변화에 맞게 필요한 인스턴스를 추가하거나 제거합니다.

Auto Scaling은 다음과 같은 정책을 선택할 수 있습니다.

• 동적 스케일링(Dynamic Scaling Policy): 실시간으로 변화하는 수요에 따라 인스턴스의 수를 자동으로 조절합니다. 사용자는 CloudWatch 알람을 기반으로 한 정책을 설정하여 CPU 사용량, 네트워크 트래픽 등의 메트릭에 따라 인스턴스를 자동으로 추가하거나 제거할 수 있습니다.
• 예약된 스케일링(Scheduled Scaling Policy): 특정 시간에 발생하는 예상되는 트래픽 증가에 대비하여 미리 인스턴스를 추가하거나 제거할 수 있도록 합니다. 프로모션 기간이나 특정 이벤트 동안 미리 스케일링을 걸어둘 수 있습니다.
• 수요 기반 스케일링(Predictive Scaling Policy): AWS의 머신러닝 모델을 활용하여 트래픽 패턴을 예측하고, 이에 따라 자동으로 인스턴스를 스케일링합니다.

마찬가지로 공식 문서에서 자세하고 더 많은 내용을 확인할 수 있습니다.

 

가용 영역(Availability Zone, AZ) 분리

지진과 같은 자연재해가 발생할 경우, 모든 인스턴스가 동시에 영향을 받아 다운될 가능성이 있습니다. 이러한 위험을 최소화하기 위해 여러 가용 영역(Availability Zone, AZ)에 걸쳐 인스턴스를 분산 배치할 수 있습니다. 이를 통해 하나의 가용 영역에 문제가 발생하더라도 다른 가용 영역에 위치한 인스턴스들은 영향을 받지 않아 서비스를 계속해서 제공할 수 있습니다. 

 

DB가 붙어있을 경우

만약 기존의 플로우에 데이터베이스가 포함되어 있다면, 다음과 같은 모습이 될 수 있습니다.

 

DB 읽기 전용 복제본 생성

트래픽이 지속적으로 증가하여 데이터베이스의 Scale-Up이 불가능한 상황에서, 데이터베이스에 가해지는 부하를 효과적으로 관리하기 위한 방법으로 읽기 전용 복제본(Read-Replica)의 생성을 고려할 수 있습니다. 위 이미지처럼 마스터 데이터베이스는 쓰기와 읽기 작업을 모두 처리하고, 복제본은 읽기 작업 전용으로 설정함으로써 DB 요청의 부하를 분산시킬 수 있습니다.

 

DB Proxy 두기

단순히 읽기 전용 복제본을 도입하면 각 인스턴스(애플리케이션)가 RDS의 마스터와 복제본의 주소를 전부 알아야 하는 복잡성이 발생합니다. 이 문제를 해결하기 위해 RDS 앞단에 프록시를 배치하여 모든 데이터베이스 요청을 RDS Proxy를 통해 관리하고 분산시키는 방법을 사용할 수 있습니다. 이를 통해 인스턴스(애플리케이션)는 프록시의 IP 주소만을 알고 있으면 되므로 구성과 관리의 복잡성을 줄일 수 있습니다.

 

마무리

이 게시글에서는 아키텍처 관점에서 증가하는 트래픽에 대응하는 방법에 대해 아주 간략하게 살펴보았습니다. 위에 정리한 내용 만큼은 인프라를 직접적으로 만지지 않는 개발자라도 알아두면 좋을 것 같아 작성하게 되었으며, 실제 현업에서는 VPC 구성을 비롯해 정말 많은 추가적인 구성이 들어가기 때문에 더 많은 정보를 꼭 찾아보시기 바랍니다.

같이보면 좋은 글: AWS VPC를 사용한다면 알아야 할 네트워크 기초 지식