출처
제목: "알람에 관하여"
작성자: techblog.woowahan.com(이재웅)
작성자 수정일: 2020년7월
링크: https://techblog.woowahan.com/2669
작성일: 2022년7월5일글을 쓰게 된 계기
- 작은 프로젝트이지만, 플레이스토어에 올라가는 어플을 제작 중이다. 즉, 실제 트래픽이 발생한다. 그렇기 때문에 알람을 도입하지 않으면 나는 안심할수가없다..
- 메트릭 지표나 query 문제나 DB connection 등등 여러 문제가 발생할 수 있기 때문이다.
- 그래서 문제 발생 시 최대한 빨리 문제상황을 인지해야하고 해결해야 하기 때문에 AWS 알람에 대해 서칭하던중 우아한 형제들 기술블로그를 보고 아래와 같은 구성도를 만들게되었다.
이 글을 보고 만든 AWS DB 알람 구성도
출처 글(작성자 분이 작성한 2020년 기준의 글)을 보고 작성하였습니다.
2020년 기준으로 우아한형제들의 DB에는 운영환경 기준으로만 약 3000개의 알람이 설정되어있다.
RDS 인스턴스 하나 당 보통 16개 정도의 알람이 설정되어있다
CPU 사용량,메모리 잔여량,DB 커넥션,각종 Latency 등의 메트릭에 알람 설정을 한다.
각각의 경고, 심각에 대한 임계치도 설정되어 있고, 메트릭에 따라 알람 주기도 살짝 다르다.
그러면 이 3000개는 어떻게 유지보수할까?
당연히 어느정도는 자동화는 되어 있다. 그리고 당연히 관리가 안되는 부분도 있다.
DBA가 새로운 RDS 인스턴스를 생성할 때 일련의 배치를 통해 알람을 생성한다.
이렇게 일괄적으로 생성하다 보니 서비스 별로 알람 임계치를 일일히 맞추기 어렵다.
단순히 인스턴스 타입 클래스에 맞게 계산해서 생성하는 정도이다.
클라우드 환경이다보니 인스턴스가 삭제되거나 변경되는 경우가 많은데, 이런 이벤트에 따라 알람 관리가 적절히 이루어지고 있지 않고 있다.
일반적으로 알람이 많으면 알람이 발생하는 비율이 높을 것이고 그래서 스트레스를 많이 받을 걸로 생각할텐데 반은 맞고 반은 틀리다.
알람이 밤낮 안가리고 올 수도 있는데 밤에 잠을 편하게 잘 수 있을까?
알람에 대한 긍정적인 면도 있고 부정적인 면도 있는건 사실이다.
만약 해안가에 살고 있는데 태풍이나 해일 경보가 없다면 잠을 편하게 잘 수 있을까?
알람의 사전적 의미는 ‘불안, 공포, 경보, 경보기, 불안하게 만들다, 경보장치를 달다’ 등 이다.
핸드폰 알람을 생각해보자 우리가 핸드폰 알람을 설정하는 목적이 뭘까?
잠에서 깨어나기 위한 알람, 약속시간에 늦지 않기 위한 알람, 라면 익히는 시간을 위한 알람 등 어떤 일을 하기 위한 타이밍을 알고 싶어서 설정한다.
이렇게만 생각하면 알람이란건 우리의 생황을 편하게 하기 위한 좋은 도구인데 실제로는 부정적인 이미지도 있다.
수업시간을 알리는 종, 단 잠을 깨우는 모닝콜 등 위에 나열된 것만 해도 이 알람들을 반기는 사람들은 많이 없을 것이다.
알람은 왜 부정적인 이미지를 갖게 되는가?
앞에서 알람은 어떤 일을 하기 위한 타이밍이다 라고 했는데 앞에 전제(지금 하고 있는 일을 중단하고)가 하나 필요하다.
물론 단순히 새로운 일을 하기보다 시간 인지를 위해서 알람을 걸기도 한다.
그럼에도 알람 때문에 진행 중인 일에 흐름이 끊길 순 있다.
위에 전제처럼 중단점을 설정하면 완전히 앞에 일에 몰두할 수 있다.
이건 알람의 좋은 점이다.
그럼에도 불구하고 부정적인 이미지는 하고 있던 일이 중단됨에 따라 그 시간의 무한한 가치와 고유성이 깨졌기 때문이 아닐까?
오늘의 점심과 내일의 점심이 다르고, 오늘의 단 꿈을 내일 다시 꿀 수 없고,가족과의 나들이를 내년에 또 간다 한 들 같지 않을 것이다.
신생아의 경우 유일한 의사표현 방식은 울음이다
언어를 모르고 손발이 자유롭지 않기 때문에 의사소통이랄게 없다
그나마 다행인건 태생적으로 생존에 대한 알람이 걸려있다.
- 수면
- 식사
- 배변활동
주로 이렇게 3가지이다
따라서 알람이 울리면(아기가 울면)
- 수면 => 입 주변을 두드려 배고픈지 확인
- 식사 => 재운다.
- 배변활동 => 기저귀 확인
각각의 상황에 대한 대응 방법이 어느정도 정해져있다
아쉬운건 알람이 울음 하나 밖에 없다. 따라서 초반엔 아기가 울면 3가지 대응 방법을 모두 시도한다
불편해 보이지만 케이스가 3개라 할만 하다.
익숙해지면 아기 울음도 상황에 따라 다르다는 것도 알게 된다.
그러면 아기 보는건 크게 어렵지 않겠네요 라고 할 수 도 있지만 이렇게 3가지 다 정상인 상황인데 계속 알람이 울리면 난감할 것이다
애가 우는데 왜 우는지 모르겠어 문제가 있는거 같은데 어떤 문제인지 모르겠어 가 된다.
아기는 점점 커 나가면서 하고 싶은 것이 많아지고 변화도 생긴다
유치가 나면서 이앓이에 울기도 하고, 누워만 있으니 답답해서 울기도 하고
좀 크면 배변에도 전혀 울지 않기도 한다.
따라서 알람에 대한 대응은 지속적으로 변화해야 되며 관심이 필요하다
아기의 알람의 목적은 아기의 상태를 안정적으로 유지하고 건강을 지키기 위함이다.
만약 아기가 위의 3가지 증상이 있어도 울지 않는다면 어떻게 될까?
배고파도 가만히 있고, 배변에도 울지 않는다면?
부모는 주기적으로 계속 배고픈지 분유를 먹여보고, 기저귀를 확인해볼 수 밖에 없다
그렇지 않다면 아기는 영양이 부족할 수 도 있고 건강에 문제가 생길 것이다.
데이터베이스의 알람도 다르지 않다.
DB가 안정적으로 동작할 수 있도록 유지하는 것이 알람의 목적이다.
데이터베이스에 알람이 발생하면 아래와 같은 프로세스로 대응한다.
- CPU,Latency 등 부하 -> 메트릭 확인 -> 서비스가 가능한 상태인지 확인 -> 슬로쿼리,DDL 등 원인 파악 -> 스케일 아웃 또는 튜닝
- Failure 등 인스턴스 이상 -> 서비스가 가능한 상태인지 확인 -> 에러,이벤트 로그 확인 -> 주요 메트릭 확인 -> 장비업체 확인
서비스를 안정적으로 운영하는데 이러한 인프라 알람만 필요할까?
서비스 장애를 데이터베이스 같은 인프라에서 먼저 아는 경우가 있고 고객센터 또는 외부에서 서비스 장애에 대한 소식을 받고 인프라를 확인하는 경우도 있다.
문제가 있는데 우리가 알람을 받지 않느다면 서비스가 정상인지 주기적으로 확인하는 방법 밖에 업ㅎ고 이러한 방식은 큰 장애가 나기 전엔 알기 쉽지 않다.
안정적인 서비스를 위한 알람은 논리적(서비스 관점)인 알람과 물리적(인프라 관점) 알람이 모두 필요하다.
우아한 형제들 DB 알람 시스템
알람은 단순히 문제의 인식을 떠나 생활의 편리함도 목적이다
아기가 몇시간 동안 울지 않고 잘 지낸다면 지금 모든 상황이 만족스러운 것이다.
알람이 설정되어 있는데 밤새 울리지 않았다면 그건 밤새 데이터베이스가 안정적이었다는 증거이다.
그럼에도 데이터베이스에 문제가 있었다면 누락된 메트릭이 있는지 알람 임계치가 적절히 설정되어 있는지 찾아봐야 된다.
알람은 이처럼 신뢰의 수단이 될 수도 있다.
그럼에도 불구하고 알람에 대한 부정적인 이미지가 있다면 알람이 정확한가를 따져봐야 된다.
아침에 8시에 일어나야 되는데, 알람을 잘못 설정하여 7시에 알람이 울렸다면 1시간이나 더 잘 수 있는데 아침 컨디션을 망칠수도있고 반대로 9시에 알람을 설정해서 지각을 했다면?
흔하게 양치기 소년의 거짓말이 있다.
잘못된 알람이 계속되면 알람을 믿지 않아 정말 중요한 알림이 왔을때 무시하게 된다.
우리도, 알람도 아주 정교하진 않다
문제가 있는데도 알람을 전혀 받지 못하는 경우도 있고 낮은 임계치가 설정되어 너무 자주오는 경우도 있다.
그때그때 확인하면서 조정을 하곤 있지만 쉽지 않다.
특히 불필요한 알람을 계속 받는다면 정리도 필요하다
알람은 다음 할일을 알려주는 기준점이기 때문에 알람을 받고도 아무런 액션을 할 수 없다면 사실상 그알람은 제거하던지 보완점을 찾아야 된다
알람 시스템이 잘 구축되어 있더라도 알람을 받고 아무런 액션을 취하지 않는다면 피로도는 쌓이고 알람 시스템에 대한 신뢰도가 떨어지게 된다
무의미하게 반복되는 알람에 지쳐 알람을 꺼둘 것이다. 이런 경우 정작 중요한 알람을 놓치는 일도 생기게 된다
알람에 대한 문제를 인지했고 해결하는 스케쥴과 작업 내용이 잡혔다면 그 스케쥴까진 알람을 빼도 된다.
이렇게 알람에 대한 관리도 어렵고 중요하다 보니 최근에는 기계학습을 통한 이상 탐지 알람들이 나왔다.
AWS 환경에서는 Anomlay detection 이라는 알람을 사용할 수 있다. Using CloudWatch Anomaly Detection 메토릭에 대한 범위를 정해주면 시간의 흐름에 따라 패턴을 인지하고 그 패턴의 범위를 벗어날 경우 이상 증상이라고 판단하고 알람을 보내준다
서비스의 트래픽이 증가하면 증가하는데로 임계치가 같이 변동하기 때문에 이상적일 수 있다
다만 이러한 이상 탐지 알람들도 완벽하진 않고 오류를 내재하고 있다.
아래의 그래프는 10/31 전후 일주일 간의 특정 DB 인스턴스 CPU 사용률과 Anomlay detection 밴드지표이다.
10/31 트래픽이 급증하였고 DB 인스턴스에도 부하가 심해 스케일아웃을 실시하였다.
트래픽 급증으로 인하여 CPU 사용률리 평소 패턴보다 늘었고 이를 이상 탐지하였다
그러나 스케일 아웃을 실시하면서 인스턴스 당 트래픽이 줄었고 CPU 사용 은 평소대로 급하락 하였다
이렇게 하락한 상태는 다른 날짜의 지표와 큰 차이가 없지만 앞서 급상승한 지표를 학습하여 밴드에 반영함으로써 Anomaly detction 밴드는 하락한 CPU 사용률을 비정상으로 판단하였다
이와 같이 Anomaly detection 탐지도 오탐이 발생할 소지가 있다. 어느 것이 정답이라는 건 없고 여러 알람 설정들을 상황에 맞게 사용해야 한다.
알람은 이처럼 우리가 편하게 살기위한 수단이지 스트레스를 받기 위한 도구가 아니다
지속적으로 알람환경을 개선하고자 노력해야 한다
알람 설정 및 임계치 조정을 자동화하려고 개발해야 하고 새로운 알람 메트릭 및 탐지 기능을 꾸준히 테스트 해야 한다
알람 자체가 문제의 해결책은 아니다 알람을 통해 증상을 확인했으면 그에 대한 대응을 해야 알람의 목적이 이루어진다
알람은 서비스의 신뢰와 안전을 위해 또 인프라 담당자들의 편의를 위한 중요한 도구 이다.
