AWS 기술 블로그
우아한형제들에서 Amazon Aurora 데이터베이스를 모니터링 하는 방법
우아한형제들은 3천만 이상이 선택한 배달앱 ‘배달의민족’으로 음식 문화를 선도하고 있습니다. ‘배민1 한집배달’로 더 빠르게 배달 받을 수 있고, ‘배민 쇼핑라이브’를 보면서 판매자와 직접 소통할 수도 있습니다. ‘B마트‘로 집에서 장보기까지 할 수 있습니다.
우아한형제들은 ‘문 앞으로 배달되는 일상의 행복을’ 비전으로 삼고 있습니다. 이제 배달의민족으로 배달되는 것은 음식 뿐이 아닙니다. 당장 필요한 생필품도, 입을 옷과 신발도 문 앞으로 옵니다. 배달을 혁신하는 우아한형제들은 배달로봇 ‘딜리‘를 만들며 새로운 인프라를 만들고 있습니다. 우아한형제들은 대한민국을 넘어 세계를 향해 나아갑니다. 우아한형제들은 Delivery Hero와 함께 <우아DH아시아>를 설립하고 아시아 사업을 총괄하고 있습니다.
우아한형제들은 일하는 문화를 혁신하고 있습니다. 평범한 사람들이 모여 비범한 성과를 만들어 내는 곳이 될 수 있도록 건강한 조직문화를 만드는 일에 진심을 다합니다.
배달의민족 서비스 소개
배달의민족은 IT기술로 우리의 식문화와 생활을 바꾸고 있습니다. 음식점에 갈 수 없어도 이제 우리는 어디서든 먹고 싶은 음식을 먹을 수 있습니다. 배달 주문은 AI의 추천을 통해 최적의 라이더와 연결됩니다.
음식점을 운영하는 사장님은 배민으로 주문만 받는 것이 아닙니다. 배민상회로 식재료와 운영 소모품 등을 안정적으로 공급받을 수 있고, 배민아카데미로 가게 운영을 공부합니다. 조리된 음식뿐만 아닙니다. 고기 우유 계란 등 신선 식품을 사러 고객은 마트에 가지 않아도 됩니다. B마트가 바로 배달하니까요.
고객은 바로 문 앞에서 받아볼 수 있게 되었습니다. 배민로봇 ‘딜리’는 이미 아파트 단지를 달리고, 캠퍼스를 달리고, 엘리베이터를 타고 있습니다. 우리 일상이 조금 더 행복하도록 우아한형제들은 부지런히 달리고 있습니다.
배달의민족 서비스에서 발생하는 대부분의 트래픽은 Amazon Aurora MySQL compatibility에서 처리하고 있습니다.
Amazon Aurora란?
Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진입니다. MySQL 및 PostgreSQL은 오픈 소스 기반으로 기존 사용 데이터베이스에서 제공하던 속도와 안정성을 제공할 뿐 아니라, 비용 효율적이고 단순한 운영의 장점을 가지고 있습니다.
오늘날 기존 MySQL 및 PostgreSQL 데이터베이스에 사용되는 코드, 도구 및 애플리케이션 모두 Aurora에서도 사용할 수 있고, 일부 워크로드의 경우 Aurora는 기존 애플리케이션을 거의 변경하지 않고도 MySQL의 처리량을 최대 5배, PostgreSQL의 처리량을 최대 3배 제공할 수 있습니다.
MySQL 및 PostgreSQL과 호환되는 Aurora엔진은 고성능 분산 스토리지를 활용하고 있습니다. 아래 그림처럼 동일한 데이터를 AZ 3군데에 각 2개씩 총 6개의 데이터를 스토리지 공간에 저장하고 있기 때문에, 데이터베이스 구성 및 관리의 가장 어려운 측면 중 하나인 데이터베이스 클러스터링 및 복제를 자동화하고 표준화 합니다.
모니터링의 필요성
Amazon Aurora는 완전 관리형 데이터베이스 서비스이지만, 보다 안정적인 서비스를 제공하기 위해서는 모니터링을 적절하게 구성하는 것이 중요합니다.
특히 배달의 민족과 같이 전 국민을 대상으로 하는 대규모 서비스의 경우, 장애 발생을 미리 감지하고 최대한 빠르게 조치할 수 있도록 데이터베이스 모니터링을 구성하는 것이 더욱 중요합니다. 전 국민의의 사랑을 받고 있는 우아한 형제들의 애플리케이션인 배달의 민족은 Amazon Aurora를 서비스 데이터베이스로 사용하고 있습니다. 이 과정에서 얻은 경험을 바탕으로 어떻게 데이터베이스 모니터링을 구성했는지, 이 블로그를 통해 공유 드리겠습니다.
데이터베이스 모니터링의 3대 요소
모니터링은 위 그림과 같이 ‘로그 , ‘알람’ ,’메트릭 대시보드’ 3가지로 구분 할 수 있습니다.
- 로그는 설정 및 수집, 파싱, 분석의 단계를 거쳐 유의미한 모니터링 자료로 사용됩니다.
- 알람은 시스템의 이상 시 각 담당자에 즉각 알림으로서, 이상 상황을 빠르게 인지 할 수 있게 합니다.
- 메트릭 대시보드는 장애 발생 시, 정확한 원인 파악에 활용 하며, 상시 확인을 통해서 장애 발생의 가능성을 확인 할 수도 있습니다.
Cloudwatch 메트릭을 통한 알람 구성
먼저 Cloudwatch 메트릭을 통하여 배달의민족 모니터링 알람 을 어떻게 구성하는지 알아보겠습니다. 각 Aurora의 인스턴스들 마다 Cloudwatch 메트릭이 제공됩니다. 배달의민족 에서는 메트릭들 중 임계치가 초과 했을때 Aurora의 이상이 있다고 판단하고, 그에 대한 조치를 하기 위해 알람을 구성하고 있습니다. 이 그림은 배달의민족에서 구성한 알람 구성도 입니다.
배달의민족에서는 워닝(Warning) 채널과 크리티컬(Critical) 채널을 별도로 나눠서 알람을 구성하고 있습니다. 워닝채널은 장애까지는 아니지만 1차로 배달의민족의 데이터베이스 엔지니어가 대응을하고 개발팀과 추가로 확인이 필요할경우 개발팀에게 내용을 전달하는 용도이고, 크리티컬은 장애위험이 있는 수치로써 개발팀과 함께 알람을 대응하고 있습니다. 여러 차례의 경험을 통해서 배달의민족에서는 워닝과 크리티컬의 각 항목별 임계치를 다음과 같이 설정하여 사용하고 있습니다. 커넥션의 경우에는 인스턴스의 스펙에 따라 상이하여, 스펙별로 별도로 설정하고 있으며 공통적으로 적용된 항목은 다음과 같습니다.
모니터링 대상 |
워닝 (Warning) | 크리티컬 (Critical) |
CPU Utilization |
50% 이상 | 70% 이상 |
DML Latency |
200ms 이상 | 500ms 이상 |
Select Latency |
200ms 이상 | 500ms 이상 |
Commit Latency |
20ms 이상 | 50ms 이상 |
Buffer Cache hit Ratio |
90% 이하 | |
Blocked Transaction |
초당 0.01 개 이상 |
|
Rollback Segment History Length | 30000개 이상 | 70000개 이상 |
Aurora 에서의 Commit latency 는 데이터 변경 사항을 Aurora 의 분산 스토리지에 Write 하는데 소요되는 시간 입니다. 이 수치가 증가한다면 대량의 Long Query 또는 높은 트래픽으로 인한 지연 등의 현상이 발생하고 있을 수 있습니다. Rollback Segment history length 는 오래 실행 중인 쿼리의 여부를 확인할 수 있습니다.
MySQL에서 제공되는 Slowquery log 는 쿼리가 완료 되어야만 로그가 남는 것에 비해서, Rollback Segment 는 쿼리가 실행중에도 확인을 할 수 있습니다. 따라서 Rollback Segment 모니터링을 통해서 Slow Query 의 실행으로 서비스에 이슈를 유발하고 있는지를 보다 더 정확하게 확인 할 수 있습니다.
Performance Insight 를 통한 모니터링
AWS에서는 Performance Insight 라는 보다 더 상세한 모니터링이 가능하도록 도와주는 모니터링 도구를 제공하고 있습니다. SQL, 호스트, 데이터베이스, 대기 별로 데이터베이스에 부하를 일으키는 쿼리를 알려주고 그에 대한 비율은 어떠한지 알려주는 도구입니다.
아래 그림에서 처럼 Top Query 및 Top Wait 등 쿼리 레벨에서의 모니터링 및 분석이 가능하도록 performance Insight에서 제공 하고 있습니다. 유료 서비스 이긴 하지만 배달의민족에서도 Performance Insight 를 기본 활성화 해서 사용하고 있습니다.
Performance Insight 에는 최근에 Devops Guru 라고 하는 데이터베이스 성능 및 운영 문제를 자동으로 감지하고 진단하여 병목 현상을 몇 분 안에 해결할 수 있는 Amazon RDS용 새로운 기계 학습(ML) 기반 모니터링 기능이 추가 되었습니다
MySQL exporter 를 통한 추가 모니터링
배달의민족에서는 AWS에서 제공하는 Cloudwatch 및 Performance Insight 를 사용하여 대규모 서비스 DB를 효과적으로 모니터링 하고 있지만, 모니터링의 고도화를 위하여 show engine innodb status
커맨드를 수행한 결과등을 mysql exporter 를 이용하여 모니터링 하고 있습니다. Exporter 에서 수집한 데이터를 프로메테우스와 그라파나를 이용하여 추가 메트릭 시스템을 구성하였습니다.
Mysql Exporter 에 추가한 메트릭은 다음과 같습니다.
모니터링 대상 | 세부 사항 |
Aurora 관련 메트릭 | 버전, Aurora Max Volume Size등 |
롱 트랜잭션 | 롱 트랜잭션 갯수 롱 트랜잭션을 실행하고 있는 계정과 호스트 |
커넥션 정보 | IP(Host) 별로 붙은 갯수 계정별로 붙은 갯수 |
DB 사이즈 | 테이블 사이즈만으로 Sum 메트릭을 만들면 프로메테우스의 |
Cloudwatch Logs 를 통한 알람 구성
Cloudwatch 로그를 통해서 배달의민족에서는 위와 같은 구조로 Slow Query 로그와 에러 로그를 수집해서 ‘Grafana loki’ 로 구성된 로깅 시스템에 수집하여 알람을 발송하고 있습니다.
배달의민족에서는 다음과 같은 4가지의 경우에 이러한 로깅 시스템을 통해서 알람을 확인합니다.
- 30초 이상 실행된 쿼리
- Signal 6 발생
- Deadlock 발생
- External 복제 사용시 복제 오류 메시지
SlowQuery 통계 구성
데이터베이스 관련 성능 이슈의 대부분은 Slow Query 때문에 발생한다고 할 수 있습니다. 그래서 배달의민족에서는 장애 상황에서도 문제되는 Slow Query를 직관적으로 확인할 수 있도록 발생하고 있는 Slow Query 를 모아서 통계를 내는 작업을 자동화 하고 데이터를 시계열화 하였습니다.
Slow Query 통계를 이용하여 해당 쿼리가 어떤 인스턴스 에서 수행되었는지 , 어떤 계정에서 수행 되었는지 특정 시간에 어느정도 쌓였는지 등을 바로 확인 할 수 있도록 구성되어 있습니다.
마치며
전 국민이 이용하는 배달의민족에서 Amazon Aurora을 사용하면서, 서비스의 모니터링을 위해서 사용하는 방법에 대해서 지금까지 알아 보았습니다. 이 내용은 우아한형제들에서 진행하는 우아한테크 ‘매달 만나는 기술이야기’ 2023년 2월 편에서 좀더 자세히 확인할 수 있습니다.
아래 링크를 통해서 추가 정보를 확인 할 수 있습니다.