케이타운포유의 순간적인 스파이크 트래픽 대응을 위한 Amazon Aurora 오토스케일링 전략

케이타운포유는 급성장 중인 K-Pop 및 한류 상품을 글로벌 판매하는 이커머스 서비스를 제공하는 회사로 2002년 서비스를 시작한 이래 200개국, 6개 언어로 500만 회원, 5,000여 개 팬클럽을 대상으로 서비스하고 있습니다. 케이타운포유는 B2B에서 B2C로 전환 후 2021년 매출액 2,000억을 돌파하며 짧은 기간에 15배에 달하는 성장을 하였습니다.

케이타운포유는 사용자서비스, 운영시스템, 물류시스템(WMS) 등의 시스템을 개발, 운영하고 있으며, 이를 위해 모든 시스템을 AWS 클라우드에서 구축/운영하고 있습니다. 2022년에 많은 버그를 해결함과 동시에 트래픽 수용을 위한 개선을 이뤘고, 2023년에는 상품구조 개선, 물류시스템 개선 및 고도화, 거대 모놀리식 레거시 시스템을 MSA 구조로 변경 진행 중에 있습니다.

순간적인 스파이크 트래픽에 따른 Aurora Auto Scaling 기능의 한계

케이타운포유는 이벤트 발생시 평소의 수배에서 수십배의 트래픽을 처리하고 있습니다. 어플리케이션에서 Amazon Elasticache를 적극 활용하여 서비스 안정성과 지연을 최소화하고 있지만 실시간 데이터베이스 쿼리를 요구하는 많은 API들로 인하여 급격한 데이터베이스 부하가 발생하고 있습니다. 예측 불가능한 이벤트로 발생한 데이터베이스 부하를 해소하기 위해 케이타운포유는 Aurora Cluster의 오토스케일링을 적극 활용하고 있습니다.

이벤트 발생시 Aurora 오토스케일링을 활용한 자동 Scale-out 또는 다수의 읽기 전용 인스턴스를 사전 증설을 하고 있음에도 아래와 같은 상황에 한계가 있습니다.

예측 불가능한 순간적인 스파이크 트래픽 부하로 인한 서비스 장애 현상
Scale-out 발생시, 평균 15분 소요되는 읽기 전용 인스턴스 준비 시간
비즈니스 특성상 최소 수 시간 전 읽기 전용 인스턴스 증설 비용
예측 불가능한 이벤트 규모로 인한 과도한 대응과 리소스 낭비

이러한 비즈니스 요구사항과 예측 불가능한 트래픽의 대응 및 Aurora 오토스케일링 소요시간과 비용 문제를 해결하기 위해 개선된 오토스케일링 전략이 필요했습니다.

개선 아이디어

Aurora의 읽기 전용 인스턴스가 생성되는 약 15분 동안 트래픽을 여분의 인스턴스가 처리할 수 있다면 서비스 장애 문제를 해결할 수 있습니다. 읽기 전용 인스턴스가 생성되는 시간 동안에만 트래픽을 받고 평소에는 트래픽을 처리하지 않으며 트래픽을 처리한만큼만 요금을 지불하는 인스턴스가 있으면 이 문제를 효과적으로 개선할 수 있습니다. 그리고 이 구조는 이벤트 대응을 위해 사전에 증설하는 읽기 전용 인스턴스를 줄여 비용 최적화적으로도 도움이 될 것입니다. Cloudwatch에서 제공하는 Aurora RDS 메트릭의 해상도는 1분입니다. 순간적인 트래픽으로 인한 읽기 전용 인스턴스 부하의 빠른 감지와 빠른 오토스케일링을 위해 고해상도의 메트릭을 필요합니다.

이 아이디어를 정리해보면 필요한 인프라 변경요소는 다음과 같습니다.

데이터베이스 부하 대응을 위한 고해상도 메트릭
사용한 만큼 지불하는 여분의 인스턴스
특정 임계치를 넘는 트래픽 발생시 여분의 인스턴스로 트래픽 분배하는 구조
자동화된 운영 아키텍처

Amazon Aurora Hybrid(Mixed-Configuration) Cluster

Amazon Aurora DB Cluster는 다음과 같이 두 가지 유형의 DB 인스턴스로 구성됩니다.

기본 DB 인스턴스 – 읽기 및 쓰기 작업을 지원하고, Cluster 볼륨의 모든 데이터 수정을 실행합니다.
Aurora 복제본(읽기 전용 인스턴스) – 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원합니다.

Amazon Aurora 데이터베이스의 아키텍처 특징 중 하나는 컴퓨팅과 스토리지의 분리입니다. Amazon Aurora 스토리지는 데이터베이스의 데이터 양이 증가함에 따라 자동으로 크기가 조절됩니다.

Aurora Serverless v2는 CPU 및 메모리 리소스를 운영 중단 없이 자동적으로 크기가 조절됩니다. Aurora Serverless v2 용량에 대한 요금은 ACU 시간으로 측정됩니다. ACU는 약 2기가바이트(GB)의 메모리로 해당 CPU 및 네트워킹의 합한 용량입니다. 정의할 수 있는 Aurora Serverless v2 용량은 최소 0.5 ACU에서 최대 128 ACU입니다.

이러한 Amazon Aurora DB Cluster의 아키텍처로 특징으로 기존 프로비저닝 된 Aurora Cluster에 Aurora Serverless v2 읽기 전용 인스턴스를 추가하여, 아래 그림과 같이 Aurora Mixed-Configuration Cluster 형태로 구성 가능합니다. 케이타운포유는 이 데이터베이스 아키텍처를 Aurora Hybrid Cluster라고 부르고 있습니다.

커스텀 Aurora 오토스케일링 아키텍처

커스텀 Aurora 오토스케일링 아키텍처에서는 다음과 같은 로직으로 데이터베이스 부하를 처리합니다.

기존 프로비저닝 된 Aurora Cluster에 추가된 Serverless v2 읽기 전용 인스턴스는 가중치가 0입니다. 가중치가 0이므로 평상시에는 트래픽이 발생하지 않아 Serverless v2 읽기 전용 인스턴스에 대한 요금이 부과되지 않습니다.
만약, 기존 프로비저닝 된 Aurora Cluster의 읽기 전용 인스턴스의 평균 CPU 부하량이 임계치를 넘으면 알람을 발생합니다.
알람이 발생되면, 가중치를 조절하여 추가된 Aurora Serverless v2 읽기 전용 인스턴스로 일부 트래픽을 전달합니다.
- 가중치를 조절한 이후에도, 알람 상태를 지속적으로 확인하여 추가적인 트래픽 전환이 필요한지 판단합니다.
- 만약, 알람이 해소되지 않고, 트래픽의 부하가 많은 상황이면, Serverless v2 읽기 전용 인스턴스가 더 많은 트래픽을 처리하도록 가중치를 추가 조절합니다.
또한, 알람이 발생하였기 때문에, 기존 프로비저닝 된 Aurora Cluster에서 스케일 아웃이 발생하고, Provisioned 읽기 전용 인스턴스를 추가합니다.
추가된 Provisioned 읽기 전용 인스턴스의 상태가 Available한 상태가 되면, 알람 상태를 확인하여 트래픽을 Provisioned 읽기 전용 인스턴스가 처리하도록 가중치를 조절합니다.
최종적으로 알람이 해소된다면, serverless v2 읽기 전용 인스턴스의 가중치를 0으로 조절하여 사용을 중지하고, 요금을 발생하지 않습니다.

이러한 아이디어를 통해 효율적이고 안정적으로 데이터베이스를 사용할 수 있도록 아래와 같이 아키텍처를 변경하였습니다.

커스텀 Aurora 오토스케일링 아키텍처는 다음과 같이 크게 4개 영역으로 구분되어 동작합니다.

Aurora Serverless v2 읽기 전용 인스턴스 추가 및 커스텀 엔드포인트 설정
Enhanced Metric 지표 수집 및 Cloudwatch 커스텀 메트릭 생성
Step Functions을 이용한 Route53 가중치 기반 레코드의 가중치 조절
Cloudwatch 커스텀 메트릭을 이용한 Aurora Cluster 오토스케일링 설정

1. Aurora Serverless v2 읽기 전용 인스턴스 추가 및 커스텀 엔드포인트 설정

순간적인 스파이크 트래픽을 대응하기 위해 기존에 프로비저닝 된 Aurora Cluster에 Serverless v2 읽기 전용 인스턴스를 추가합니다. Serverless v2 읽기 전용 인스턴스를 최하위 우선순위로 설정해서 Fail-over 발생시, 쓰기 인스턴스로 승격되는 것을 방지할 수 있습니다. Serverless v2 읽기 전용 인스턴스를 여러 대 생성하면 더 급격한 스파이크 트래픽도 대응할 수 있습니다.

커스텀 엔드포인트는 아래와 같이 각각 설정합니다.

Provisioned 커스텀 엔드포인트
- 평상시 트래픽을 처리할 기존 프로비저닝 된 Aurora Cluster에 속한 Provisioned된 읽기 전용 인스턴스 그룹을 가리키는 엔드포인트
Serverless v2 커스텀 엔드포인트
- 임계치를 넘어가는 부하 트래픽을 처리하는 Serverless v2 읽기 전용 인스턴스를 가리키는 엔드포인트

이때, 오토스케일링으로 인해 추가되는 Provisioned 인스턴스는 Provisioned 커스텀 엔드포인트에만 추가되도록 설정합니다.

이렇게 생성된 각각의 커스텀 엔드포인트는 Route53에 Private Hosted Zone으로 도메인을 생성하고, 같은 서브 도메인으로 가중치 기반 라우팅 레코드((Weighted Based Record)를 각각 생성합니다. Serverless v2 커스텀 엔드포인트에 연결된 가중치 기반 레코드의 가중치 값은 0으로 설정합니다.

이 과정을 통해 설정된 DNS 주소로 감당 가능한 평상시의 트래픽은 Provisioned 커스텀 엔드포인트에 연결된 인스턴스가 처리하고, 임계치를 넘어가는 부하 트래픽은 Serverless v2 읽기 전용 인스턴스가 처리하여 최소한의 금액으로 서비스의 안정성을 높일 수 있습니다.

2. Enhanced Metric 지표 수집 및 커스텀 메트릭 생성

2.1. 고해상도 메트릭 수집

AWS Cloudwatch 통해 수집되는 Amazon Aurora의 기본 메트릭은 60초 단위로 수집됩니다. 순간적인 스파이크 트래픽에 따른 급격한 데이터베이스 CPU 사용률 변화를 감지하기위해 높은 해상도를 가진 메트릭의 수집이 필요합니다.

Enhanced Monitoring은 데이터베이스가 구동되는 OS의 메트릭을 최대 1초의 해상도로 모니터링 할 수 있습니다. Aurora Cluster의 인스턴스를 수정하여 Enhanced Monitoring을 활성화 합니다. 오토스케일링으로 생성되는 인스턴스는 기본 인스턴스의 설정을 공유하므로 기본 인스턴스의 Enhanced monitoring도 활성화 하여야 합니다.

Enhanced Monitoring 기능을 활성화 하면 RDSOSMetrics 라는 이름의 Cloudwatch Logs Groups에 해당 지표가 저장됩니다. 케이타운포유는 이 Log에서 추출한 지표를 통해 고해상도 메트릭을 구성하였습니다.

2.2 Subscription Filter를 이용한 메트릭 정제

Cloudwatch Logs Subscription Filter는 Cloudwatch에 Log로 수신되는 정보를 구독하여 Lambda, Kinesis 등의 서비스로 전송하는 기능입니다. RDSOSMetrics Log Group에는 Enhanced Monitoring 기능이 활성화된 모든 인스턴스들의 지표들이 수집되므로 subscription filter를 이용하여, 위에서 설정한 Provisioned 커스텀 엔드포인트의 대상이 되는 인스턴스 메트릭만을 정제하는 작업을 진행했습니다.

먼저, 아래 코드는 Lambda의 event로 전송된 압축된 로그를 읽을 수 있도록 처리하는 예시입니다.

import json
import base64
import gzip

def lambda_handler(event, context, metrics):
	data = event["awslogs"]["data"]
    decoded_data = base64.b64decode(data)
    decompressed_data = gzip.decompress(decoded_data)
    metric = json.loads(json.loads(decompressed_data)["logEvents"][0]["message"])

다음으로 위에서 설정한 각 커스템 엔드포인트에 해당하는 읽기 전용 인스턴스의 지표만을 추출합니다. 하지만, 메트릭에서는 커스텀 엔드포인트를 기준으로 추출할 수 없습니다. 따라서, AWS boto3에서 제공하는 RDS의 describe_db_instances, describe_db_clusters API를 이용하여 available 상태인 읽기 전용 인스턴스의 CPU 사용량 메트릭만을 추출하였습니다.

instances_with_status = rds.describe_db_instances(
        Filters=[{"Name": "db-cluster-id", "Values": ["<CLUSTER_NAME>"]}]
    )["DBInstances"]

instances_with_primary = rds.describe_db_clusters(DBClusterIdentifier="<CLUSTER_NAME>")[
    "DBClusters"
][0]["DBClusterMembers"]

instances = []
for i in instances_with_status:
    for c in instances_with_primary:
        if i["DBInstanceIdentifier"] == c["DBInstanceIdentifier"]:
            instances.append(dict(i, **c))
            break

available_provisioned_read_replicas = [
    instance["DBInstanceIdentifier"]
    for instance in instances
    if instance["DBInstanceStatus"] in available_status
    and instance["DBInstanceClass"] != "db.serverless"
    and not instance["IsClusterWriter"]

2.3 EMF를 이용한 실시간 메트릭 반영

빠른 메트릭 반영을 위해 EMF(Embedded Metric Format)을 이용합니다. EMF는 Cloudwatch에 맞춰진 구조화된 로그 포맷으로서, 메트릭 반영이 빠르다는 장점을 가지고 있으며 장애대응과 같은 실시간성 지표가 필요할때 사용할 수 있습니다.

Python을 런타임으로 사용한 Lambda의 경우 metric_scope decorator를 이용하여 쉽게 반영할 수 있습니다. 아래 코드는 Lambda에서 EMF를 이용해 Cloudwatch에 맞춰진 구조화된 로그 포맷으로 변환하는 예시입니다.

from aws_embedded_metrics import metric_scope
from aws_embedded_metrics.storage_resolution import StorageResolution

@metric_scope
def lambda_handler(event, context, metrics):
    #    ... metric data 추출 / 변환 ...
    metrics.set_dimensions("<METRIC_DIMENSION_NAME>": "<METRIC_DIMENSION_VALUE>"})
    metrics.put_metric("<METRIC_NAME>", "<METRIC_VALUE>", ageResolution.HIGH)
    metrics.set_namespace("<METRIC_NAMESPACE>")

EMF를 사용하면 정제한 커스텀 메트릭 값(대상 인스턴스의 CPU 사용량)을 1초 이내에 Cloudwatch에서 확인할 수 있습니다.

3. Step Function을 이용한 Route53 레코드 가중치 조절

데이터베이스의 높은 부하 발생을 처리하는 알람 이벤트를 생성하고 트래픽 비율(Route53의 레코드 가중치)를 조절하는 Step Functions을 트리거 하여 프로비저닝 된 읽기 전용 인스턴스와 Serverless v2 읽기 전용 인스턴스 사이의 트래픽 비율을 조절하도록 구성하였습니다.

케이타운포유는 데이터베이스 부하 증가와 감소를 처리할 Step Functions을 분리하여 관리하였습니다. 아래는 부하 증가 시 발생되는 Step Functions을 기준으로 작성하였습니다.

3.1 읽기 전용 인스턴스 부하 알람 및 이벤트 트리거 구성

위에서 생성한 커스텀 메트릭을 이용하여 Cloudwatch Alarm을 생성합니다. 높은 데이터베이스 부하 알림 데이터 포인트는 적게, 낮은 부하 알림 데이터 포인트는 높게 설정하는 것으로 시스템 안정성을 높일 수 있습니다. AWS 네임스페이스 메트릭이 아닌 커스텀 메트릭을 사용할 경우, 알람의 데이터 포인트 주기를 최대 10초 까지 높일 수 있는 장점이 있습니다.

3.2 트래픽 비율 조절 Step Function 구성

Cloudwatch 알람 이벤트는 OK 상태에서 Alarm 또는 반대의 상태로 변경되는 최초 1회에서만 발생합니다. 스파이크 트래픽 이후에도 점진적으로 트래픽이 상승하는 경우에는 한번의 Route53 가중치 조절만으로는 안정성을 확보할 수 없습니다. 가중치 조절 이후, 데이터베이스의 상태를 지속적으로 점검하여 안정성을 확보하기 위해서 Step Functions을 사용합니다.

알람에 의한 Step Functions은 다음과 같이 동작합니다.

Route53에 Serverless v2 읽기 전용 인스턴스와 연결된 레코드의 가중치를 수정합니다.
조절된 가중치가 실제 데이터베이스 사용량과 CloudWatch Alarm에 반영될 수 있도록 최소 Cloudwatch Alarm의 데이터 포인트 주기만큼 대기합니다.
Cloudwatch Alarm이 해결되었는지 확인합니다.
- Alarm이 해결된 경우, Step Functions을 종료합니다.
- Alarm이 해결되지 않은 경우, 다시 Route53 레코드의 가중치를 조절합니다.

AWS API를 사용하고 대기하는 등의 부분은 별도의 Lambda 없이 Step Function에 내장된 함수들을 사용하였습니다. 케이타운포유는 내장된 함수를 사용하여 Lambda 사용시간을 줄이고 비용을 최적화할 수 있었습니다.

4. 커스텀 메트릭을 이용한 Aurora 오토스케일링

Serverless v2 인스턴스의 CPU 사용량은 Max ACU 기준 사용중인 ACU로 계산됩니다. Aurora Cluster에서 제공하는 오토스케일링 기능은 아래와 같이 Aurora Cluster에 포함된 모든 읽기 전용 인스턴스의 평균 CPU 사용량을 기준으로 동작합니다.

이 계산방식으로 인해 Aurora Cluster에 포함된 모든 읽기 전용 인스턴스의 평균 CPU 사용량이 프로비저닝 된 읽기 전용 인스턴스들의 평균 CPU보다 낮게 계산되어, 원하는 CPU 기준에 오토스케일링이 발생하지 않는 문제가 있습니다.

따라서, 아래와 같이 프로비저닝 된 읽기 전용 인스턴스만으로 평균 CPU 사용량을 통해 실제 사용중인 리소스 기반으로 오토스케일링이 일어날 수 있도록 커스텀 메트릭에 기반한 오토스케일링을 구성하였습니다.

커스텀 메트릭을 이용하여 Aurora Cluster에 오토스케일링을 구성하기 위해 AWS 서비스 중 하나인 AWS Auto Scaling 서비스의 API를 사용하여야 합니다. AWS Auto Scaling 서비스는 DynamoDB, ECS, Aurora, EMR 등의 AWS 서비스의 오토스케일링 구현을 위한 서비스입니다. AWS Auto Scaling 서비스를 이용하면 Aurora Cluster에서 지원하는 오토스케일링 기준 지표인 “읽기 전용 인스턴스의 평균 CPU 사용량” 과 “읽기 전용 인스턴스의 평균 커넥션”이 아닌 별도의 메트릭을 통해 스케일링 정책을 구성할 수 있다는 장점이 있습니다.

AWS CLI를 사용하여 커스텀 메트릭을 사용하여 아래와 같이 각각 수행하여 Aurora Cluster에 오토스케일링을 구성하였습니다.

1. 오토스케일링에 사용할 대상을 등록합니다. 최소/최대 용량을 제어할 수 있습니다.

aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --resource-id cluster:"<CLUSTER_NAME>" \
  --min-capacity "<MIN_CAPACITY>" \
  --max-capacity "<MAX_CAPACITY>"

2. 오토스케일링에 사용할 지표와 정책을 결정합니다.

aws application-autoscaling put-scaling-policy \
  --policy-name "<POLICY_NAME>" \
  --service-namespace rds \
  --resource-id cluster:"<CLUSTER_NAME>" \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration file://metric.json

케이타운포유는 초 단위의 Custom Metric을 활용하여 오토스케일링이 빠르게 적용될 수 있도록 구성하였습니다. Policy Type은 TargetTrackingScaling 로 하여 일반적인 부하 상황 모두 처리할 수 있도록 Policy를 구성하였습니다. TargetTrackingScaling은 현재 CPU 사용량에 기반하여 적당한 수준의 Read Replica를 늘리는 정책입니다. 서비스 워크로드 특성에 따라 StepScaling을 이용하여 지정된 사이즈만큼 증가하거나 감소 하도록 정책을 설정할 수 있습니다.

metric.json은 위에서 생성한 고해상도의 커스텀 메트릭을 이용하여 구성하였습니다.

{
  "TargetValue": "<TARGET_VALUE>",
  "CustomizedMetricSpecification": {
    "MetricName": "<METRIC_NAME>",
    "Namespace": "<METRIC_NAMESPACE>",
    "Dimensions": [
      {
        "Name": "<DIMENSION_NAME>",
        "Value": "<DIMENSION_VALUE>"
      }
    ],
    "Statistic": "Average",
    "Unit": "Percent"
  },
...
}

Serverless v2 읽기 전용 인스턴스를 활용한 Aurora Hybrid Cluster 아키텍처를 사용하면 상대적으로 더 높은 트래픽도 안정적으로 서비스할 수 있게 됩니다. 케이타운포유는 이 장점을 살려 기존 프로비저닝 된 Aurora Cluster의 오토스케일링에 구성하였던 targetValue 보다 높게 구성할 수 있었습니다.

커스텀 Aurora 오토스케일링 아키텍처 검증하기

테스트 환경

Amazon Aurora Cluster : r5.4xlarge x 2 (1 write, 1 read) + Serverless x 1 (1 read/ACU 0.5~128)
Provisioned Instance Type: c5.2xlarge
Scale-out 임계치 : 40%
프로비저닝 / 서러비스 트래픽 전환 임계치 : 40% / 60%
Serverless v2 읽기 전용 인스턴스 트래픽 전환 비율 : 20% (프로비저닝 된 인스턴스 기준)

테스트 시나리오

테스트 시작 직후 급격한 트래픽을 주어 데이터베이스에 부하 발생
임계치 60%를 초과하면서 서버리스로 트래픽 전환 시작
프로비저닝 / 서버리스 엔드포인트 간의 트래픽 비율 미세 조절
Scale-out ~ traffic shifting high threshold 사이의 CPU 구간으로 수렴
Scale-out 발생
read replica 추가로 프로비저닝 된 인스턴스의 CPU 부하 감소
위 과정 반복
테스트 종료

테스트 결과

AS-IS : Aurora Cluster (Provisioned Only)

평균 CPU 사용률

기존 프로비저닝 된 Aurora 읽기 전용 인스턴스만으로 구성된 Cluster에서는 위 그림과 같이 테스트 시작 직후 발생한 다량의 트래픽으로 인해 10여분간 CPU 사용량 100% 도달 및 서비스 장애가 발생하였습니다.

TO-BE : Aurora Hybrid Cluster (Provisioned + Serverless v2)

평균 CPU 사용률

개선 전 Aurora Cluster에서 Scale-out이 일어나는 약 10여분간 100%의 CPU 사용량을 유지하는 것과 달리, Aurora Hybrid Cluster에서는 순간적인 CPU 부하 증가를 감지 후 Serverless v2 읽기 전용 인스턴스로 트래픽을 전환하여 안정적인 CPU 사용량을 유지하는 것을 확인할 수 있었습니다.

엔드포인트 별 커넥션 증가율

또한, 오토 스케일일링으로 인해 Scale-out이 일어난 후에는 Serverless v2 읽기 전용 인스턴스로 전환되는 트래픽의 비율을 점진적으로 낮추고 Scale-out이 완료된 이후에는 모든 트래픽이 Provisioned 인스턴스로 전환되는 것을 확인할 수 있습니다.

결과

기존 프로비저닝 된 Aurora Cluster와 Aurora Serverless v2 인스턴스를 동시 접목한 Aurora Hybrid Cluster 아키텍처로 인해 케이타운포유는 크게 다음과 같은 부분에서 시스템이 개선되었습니다.

서비스 안정성

Aurora Hybrid Cluster 아키텍처는 이벤트 전 예상치 못한 글로벌 스파이크 트래픽이 발생하여도 Serverless v2 인스턴스를 통해 안전하게 트래픽에 대한 대응이 가능합니다.

시스템 성능

데이터베이스의 안정적인 사용량은 어플리케이션의 성능과도 연관됩니다. 테스트 결과 초기 데이터베이스 과부하 상태에서 테스트 쿼리에 대한 응답속도는 하이브리드 구성에서 평균 80ms, 미구성일 경우 220ms 확연한 차이가 나타납니다.

오토스케일링 시간 단축

AWS namespace를 가지는 메트릭의 알람 데이터 주기는 최소 1분입니다. 하지만 별도의 커스텀 메트릭을 통하여 데이터 포인트 주기를 최대 10초로 낮출 수 있습니다. 이 고해상도 메트릭을 통해서 오토스케일링은 더욱 빠르게 반영됩니다.

비용 절감

케이타운포유는 이벤트 대응을 위해 최소 1시간 이전에 읽기 전용 인스턴스를 증설합니다. 서비스의 안정성을 최우선으로 하기때문에 읽기 전용 인스턴스는 예측되는 트래픽보다 최소 20% 이상 추가 증설합니다. 하지만 일부 이벤트는 정확한 시간을 미리 알 수 없기 때문에 수시간 전 미리 증설하기도 하며 이로 인하여 발생하는 비용 누수는 한달에 수십대*시간의 규모입니다. Aurora Hybrid Cluster 아키텍처는 사전 불필요한 인스턴스 증설이 필요없기 때문에 약 30%의 이벤트 비용을 절감할 수 있었습니다.

위 사항을 정리하면 다음과 같습니다.

	기존 클러스터	하이브리드 클러스터
서비스 장애 시간	평균 15분 내외	장애 없음
장애구간 서비스 응답 속도	평균 220ms	평균 80ms
서비스 비용	비용 추가 발생 (CloudWatch, Lambda 등)	비용 추가 발생 (CloudWatch, Lambda 등)
이벤트 대응 비용 (비율)	100%	70% (30% 절감)
오토스케일링 정밀도	최대 1분	최대 10초

이처럼 Aurora Hybrid Cluster 아키텍처 구성을 통해 예측하지 못한 순간적인 스파이트 트래픽에 대해서 신속한 트래픽 전환을 통해 서비스의 안정성을 빠르게 회복할 수 있었습니다. 그리고 시스템 성능, 빠른 대응이 가능한 오토스케일링, 그리고 비용 측면에서 크게 개선되었습니다.

마무리

기업의 64%가 1년 안에 서비스 중단을 경험했으며 평균 25시간 이상의 다운타임을 겪은 것으로 조사되었습니다. 또한 ITIC가 1,000명 이상의 직원을 보유한 기업을 대상으로 한 조사 결과에 따르면 해당 기업의 98%는 서비스 중단에 따른 손실이 시간당 1억원을 초과합니다. 서비스 중단을 최소화하여 손실을 막고 비즈니스의 성과를 달성하기 위한 노력은 중요합니다.

Aurora Serverless v2 인스턴스를 지원하는 엔진은 Aurora MySQL 3 이상, Aurora PostgreSQL 13, Aurora PostgreSQL 14, Aurora PostgreSQL 15 입니다. Aurora Cluster의 엔진 버전이 낮은 경우, Aurora Serverless v2를 사용하도록 기존 클러스터 업그레이드 또는 전환을 참조 하시거나, 새로운 Blue/Green Deployment 기능을 활용하여 DB 업그레이드 작업을 더 안전하고 빠르게 업그레이드 진행을 수행하시기를 권장 드립니다.

Aurora Hybrid(Mixed-Configuration) Cluster를 활용한 개선된 커스텀 오토스케일링 아키텍처는 AWS에서 제공하는 다양한 API 기반의 기능과 로깅을 활용하여 쉽고 빠르게 구축할 수 있었습니다. 또한, 여러 번의 아키텍처 개선 과정을 거쳐 최종적으로 AWS에서 제공하는 Cloudwatch Log를 활용하여 Cloudwatch Alarm 기반으로 동작하도록 자동화하였기 때문에 운영, 관리 부담도 크게 줄일 수 있었습니다. 특히, 이러한 아키텍처는 데이터베이스 부하 대응을 위한 용도 이외, Serverless v2 읽기 전용 인스턴스를 다양한 용도로 활용 가능한 장점이 있습니다.

케이타운포유의 Aurora Hybrid Cluster 구축 사례가 서비스 안정성 향상과 성능, 비용 등 다양한 데이터베이스 문제를 겪고 있는 분들께 훌륭한 대안이 되기를 기대합니다.

참고

aws-embedded-metrics

AWS 기술 블로그