ECS multiple target groups 설정으로 ALB response time 측정 개선

들어가며

안녕하세요. 노머스에서 백엔드 서비스를 개발하고 있는 유근수라고 합니다.

fromm 메시지 앱은 아티스트와 프라이빗 메시지를 주고받을 수 있는 서비스입니다.
서비스의 특성상 평소에는 잠잠하다가도 아티스트가 메시지를 보내면 순식간에 트래픽이 몰려들게 됩니다.
서비스가 점점 더 커지고, 트래픽이 늘어나면서 ECS/ALB 관련 지표 확인이 점점 더 중요해지기 시작했습니다.

몰려오는 트래픽

fromm 서비스 초창기에는 AWS console을 통해 ECS/ALB를 직접 생성하고, 주요 지표는 CloudWatch 대시보드에 ECS CPU/Memory 사용률, ALB request count / response time 등을 설정해서 모니터링에 활용하고 있었습니다.

트래픽이 점차 늘어나고, 대형 아티스트의 입주로 인해 스파이크 성으로 몰려올 트래픽에 대한 대응이 좀 더 중요해졌습니다.
관련해서 부하테스트를 진행하고, ECS/RDS 등의 스펙을 조정할 수 있었습니다.
(부하테스트를 진행한 과정은 저희 기술 블로그의 이전 글에서 확인하실 수 있습니다.)

어떤 지표를 봐야 할까요?

트래픽에 대비해서 ECS 서버를 늘려놓긴 했지만, 실제로 사용자들의 사용성에 문제가 없는지, 서버의 규모가 적정한 수준인지 판별할 지표가 필요했습니다.
ECS CPU/Memory 사용률을 1차로 판단할 수 있는 지표로 사용할 수 있었습니다만,
실제 사용자들에게 원활하게 서비스되고 있는지를 보려면 ALB의 response time을 추적할 필요가 보였습니다.

ALB의 response time은 그동안 크게 참고하고 있지 못했었는데,
그 이유는 이미지나 동영상 등 업로드 api나 번역 혹은 App 마켓 등 외부 서비스를 호출하는 api 들이 response time 지표에 섞여 있기 때문이었습니다.

실제 사용자의 요청이 느리게 응답이 간 것인지, 업로드 api 등으로 인해 response time이 높게 나온 것인지가 구분이 안 되었기 때문에, endpoint 별로 response time을 분리해서 봐야 할 필요가 있었습니다.

ECS의 multiple target groups 설정

CloudWatch 대시보드의 ALB response time을 endpoint 별로 각각 보기 위해서는, ALB의 target group을 나누는 것이 제일 적합해 보였습니다. ALB의 target group을 나누기 위해서는 ECS에 multiple target groups 설정이 필요합니다.

앞에서 초반에 ECS를 console로 직접 생성했었다고 말씀을 드렸는데요. console 상에서는 multiple target groups 을 설정할 수 없었습니다.
초반에는 console로 관리를 하고 있었지만, 얼마 전부터는 terraform을 도입해서 ECS를 관리해 오고 있었습니다.

terraform에서는 쉽게 multiple target groups 설정이 가능합니다.

# target group 설정
resource "aws_lb_target_group" "tg1" {
  name        = "tg1"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = data.aws_vpc.env.id
  target_type = "ip"
}

resource "aws_lb_target_group" "tg2" {
  name        = "tg2"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = data.aws_vpc.env.id
  target_type = "ip"
}

# listener 설정
resource "aws_lb_listener" "lb_listener" {
  ...

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.tg1.arn
  }
}

resource "aws_lb_listener_rule" "listener_rule" {
  listener_arn = aws_lb_listener.lb_listener.arn
  priority     = 100

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.tg2.arn
  }

  condition {
    path_pattern {
      values = ["/upload", "/translation", "/market"]
    }
  }
}

# ecs service 설정
resource "aws_ecs_service" "ecs_service" {
  ...

  load_balancer {
    target_group_arn = aws_lb_target_group.tg1.arn
    container_name   = "fromm_container"
    container_port   = 80
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.tg2.arn
    container_name   = "fromm_container"
    container_port   = 80
  }
}

업로드 api / 외부 요청 api 등의 endpoint를 별도의 target group으로 설정하고, 나머지 서비스의 주요 api endpoint 들은 또 다른 target group으로 묶어서, target group별 response time을 추적할 수 있게 되었습니다.

이제는 ALB의 request count 추이를 보면서, 트래픽이 몰렸을 때 ECS CPU 사용률 / ALB response time 등을 확인하면서 관리하고 있습니다.
부하테스트를 통해 조금 과하게 적용했던 서버 규모도 적정 수준으로 내릴 수 있게 되었고, 그에 따른 비용 절감에도 도움이 되었습니다.

마무리

모니터링은 아직 걸음마 수준이지만, 점점 더 좋은 방향을 찾아가고 있는 것 같습니다.
서비스를 만들고 운용하면서 많은 도움을 주고 계신 개발팀 동료들에게 이 글을 빌어 감사의 마음을 전하고 싶습니다.
끝까지 읽어주셔서 감사합니다~ 😆