모니터링, 알람 그리고 장애들 😊

Team json delivery는 각자 다른 회사를 다니는 팀원들로 구성되어 있어요.

게임, IT, 금융, 제조업 까지 없는곳이 없어요!

어쩌면 도메인 별로 차이가 있을까요?

모여서 각 회사에서는 어떻게 모니터링을 하고 장애를 관리하는지에 대해

이야기를 나누고 설계를 진행해 보았어요.

1. 🤔 장애가 뭔가요?

장애란, 우리가 쓰는 시스템이나 서비스가 제대로 작동하지 않는 상태를 말해요.

이런 문제는 네트워크가 느리거나 서버에 문제가 생기거나

데이터베이스가 이상한 등 다양한 이유로 생길 수 있어요.

DEVOPS와 microservice로 인한 모듈 파편화에 따라 이러한 모니터링, 또는 관측성이 더욱 중시되고 있어요!

2. 🏢 각 회사들은 장애를 어떻게 다루나요?

각 회사마다 장애에 대처하는 자신만의 방식이 있어요.

어떤 곳은 문제가 터지면 바로 알려줄 수 있는 시스템을 갖추고,

빨리 해결할 수 있도록 준비하는 곳도 있고요.

또, 장애에 어떻게 대응할지 프로세스를 확실하게 해두고,

모든 사람이 뭘 해야 할지 바로 알 수 있게 교육시키는 곳도 있어요 📚.

어느것이 더 낫다고 할수는 없지만 시스템 규모나 중요도에 따라 적절하게 구성해야 하겠죠.

장애에 대한 다양한 반응과 대처법

• 장애에 대한 반응은 사람마다 천차만별이에요. 일부는 담담하게 대응하는 반면, 다른 이들은 긴장하고 불안해할 수도 있어요. 중요한 건, 이런 상황에서 서로를 지지하고 격려하는 것이죠.
• 긴장하는 이들에게는 특히나 조심스러운 접근이 필요해요. 패닉 상태에 빠지지 않도록 옆에서 함께 문제를 풀어나가며, 마음을 진정시켜주는 게 중요해요.
• 금융권처럼 높은 스트레스를 받는 환경에서는, 배포 때마다 긴장감이 고조되곤 해요. 여기서는 더욱더 철저한 사전 준비와 서로를 위한 지지가 필요하겠죠.
• 전사적인 장애 상황이 발생하면, 더 큰 문제로 이어질 수 있어요. 이런 경우에는 전체 팀이 함께 힘을 모아 대응해야 해요. 서비스 회사뿐만 아니라 다른 분야에서도 마찬가지예요.
• 장애는 언제든 발생할 수 있어요. 하지만 서로를 믿고, 잘 대비하며, 상황을 함께 헤쳐나간다면 어떤 어려움도 극복할 수 있어요.

📖팀원들이 겪었던 실제 장애 사례들을 살펴볼까요?

안돼

현장에서 실제로 발생했던 장애 사례를 통해, 우리는 중요한 교훈을 얻을 수 있어요.

이런 사례들을 통해 앞으로 비슷한 상황을 방지하기 위한 대책을 세울 수도 있죠. 몇 가지 사례를 들어볼게요:

• 데이터베이스 마이그레이션 사고

  • 한 회사에서 데이터베이스를 새로운 시스템으로 옮기는 작업 중에, 엄청난 준비에도 불구하고 휴먼에러로 큰 장애가 발생했어요.

• 알림 시스템 실패

  • 배송 알림을 보내는 시스템에서, 개발 환경에서는 발견되지 않았던 문제 때문에 운영 환경에서 큰 혼란이 생겼어요.

• 의도치 않은 직배송 문제

  • 주문 시스템에서 작은 코드 오류로 인해 모든 주문이 직배송으로 처리되는 큰 문제가 발생했어요.

• 결제 시스템 오류

  • 결제 시스템에 문제가 생겨 결제 실패율이 급증했고, 이는 매출 손실과 고객 신뢰도 저하로 이어졌어요.

이런 사례들을 통해, 우리는 장애 발생 시 신속하게 대응하고, 문제의 근본 원인을 파악하며, 비슷한 상황을 미리 방지하기 위한 대책을 마련할 수 있어요.

그리고 무엇보다, 팀으로서 함께 문제를 해결해 나가는 과정에서 서로를 더 잘 이해하고 협력할 수 있는 기회가 될 수 있어요.

하지만 가장 중요한 것은 문제를 빨리 알아챌 수 있냐는 것이죠!

3. 📊 팀원들의 회사에서는 실제로 어떻게 모니터링하죠?

장애 모니터링은 문제를 바로 찾아내고, 왜 그런 일이 벌어졌는지 알아내고,

빨리 해결할 수 있는 방법을 찾는 중요한 단계예요. 실제로 여러 방법을 써요.

• 인프라와 서비스 모니터링 도구

  • Prometheus, InfluxDB database에 저장한 시스템 상태를 실시간으로 지켜보고, 문제가 생기면 바로 알림을 받을 수 있어요.

• 응답 시간 체크

  • 서비스가 얼마나 빨리 응답하는지 계속 체크해서, 만약 느려지면 바로 알아챌 수 있어요. 이렇게 하면 사용자 경험에 나쁜 영향을 최소화할 수 있죠.

• 이벤트 로깅과 분석

  • ELK 스택 같은 로깅 시스템으로 일어나는 모든 일을 기록하고 분석해요. 이를 통해 문제의 원인을 파악하고, 어떻게 대처할지 방법을 찾을 수 있어요.

• 비즈니스 지표 모니터링

  • Datadog, Grafana 같은 도구로 비즈니스 지표도 눈에 띄게 지켜봐요. 시스템은 멀쩡한데 갑자기 지표가 떨어지면, 뭔가 문제가 있을 수도 있으니까요.

이러한 동작들을 처리하는 시스템을 통합 모니터링 시스템이라고 불러요.

이런 식으로 장애 모니터링 시스템을 잘 꾸려놓고 운영하면,

문제가 생겼을 때 바로 대응할 수 있고, 시스템을 더 안정적으로 만들 수 있어요.

우리가 이제 곧 설계해볼거예요!

4. 💻 팀원들의 회사에서 쓰는 모니터링 시스템은 어떤 스펙을 가지고 있고, 개발자에게 어떻게 알림을 줄까요?

현업에서 쓰는 모니터링 시스템은 정말 다양한 기능과 스펙을 가지고 있어서,

시스템 상태를 실시간으로 지켜보고, 문제가 생기면 개발자한테 바로 알려줄 수 있어요.

각 회사에서 쓰는 시스템은 작은 차이가 있었지만 큰 틀에서는 아래와 같은 특징을 지니고 있었어요.

• 높은 가용성과 확장성
  • 어떤 상황에서든 모니터링이 멈추지 않도록 하고, 서비스가 커질 때 쉽게 늘릴 수 있어야 해요.
• 다양한 데이터 소스
  • 로그, 메트릭, 트레이스 등 여러 데이터 소스에서 정보를 모을 수 있어야 하고, Prometheus나 InfluxDB, ELK 스택 같은 다양한 도구와 잘 맞물려 돌아가야 해요.
• 실시간 데이터 처리
  • 모아진 데이터는 바로바로 처리되어야 하고, 이를 통해 문제를 즉시 알아차리고 대응할 수 있어야 해요.
• 알림 설정 유연성
  • 문제의 심각도나 어디서 생겼는지, 누가 담당하는지에 따라 알림 우선순위나 받는 사람을 다르게 설정할 수 있어야 해요.

📢 알림 방식은 어떻게 되나요?

모니터링 시스템은 여러 방식으로 개발자에게 알림을 줘요:

• 이메일과 SMS: 가장 기본적인 방법으로, 문제가 생기면 바로 이메일이나 SMS를 보내요.
• 모바일 앱 푸시 알림: 특정 모니터링 앱을 통해 실시간으로 푸시 알림을 받을 수 있어요.
• 채팅 툴 연동: Slack이나 Microsoft Teams 같은 채팅 툴과 연동해서, 문제가 생기면 바로 채팅방에 알림을 보내요.
• 자동화된 전화 호출: 문제가 크면 Opsgenie 같은 서비스를 통해 담당자에게 자동으로 전화를 걸어서 알려주기도 해요.

이렇게 알림 시스템을 잘 갖춰놓으면, 개발자가 문제를 바로 알아차리고 필요한 조치를 취할 수 있게 돼요. 게다가, 장애 대응 프로세스를 더 빠르고 효율적으로 만들 수 있죠 🏃‍♂️💨.

5. 만들어 볼까요?

위에서 이해한 내용을 바탕으로 설계를 진행해 볼거예요.

도메인

• 일반적으로 필요한 컴포넌트(도메인)을 예상해볼까요?
  • 데이터 수집 : 지표 데이터를 수집
  • 데이터 전송 : 지표 데이터를 모니터링 시스템으로 전송
  • 데이터 저장소 : 전송되어 오는 데이터를 정리하고 저장
  • 경보 : 데이터를 분석하고 이상 징후를 감지하고 경보를 발생 시킴
    • 다양한 채널로 경보를 발송할 수 있어야 하겠죠?
  • 시각화 : 데이터를 차트나 그래프 등으로 제공

데이터 모델

• 지표는 통상 시계열 데이터 형태로 기록해요

• 예시 1 : cpu load에 대한 데이터와 레이블

• 예시 2 : 지난 10분의 cpu load 평균값을 얻기 위해서는 어떻게 해야 할까요?

CPU.load host=webserver01,region=us-west 1613707265 50
CPU.load host=webserver01,region=us-west 1613707265 62
CPU.load host=webserver02,region=us-west 1613707265 43
CPU.load host=webserver02,region=us-west 1613707265 53
...
CPU.load host=webserver01,region=us-west 1613707265 76
CPU.load host=webserver01,region=us-west 1613707265 83

• 각 행의 마지막에 기록된 cpu 부하 수치의 평균을 구하면 되겠네요!
  • 50+62+43+…83 / n

데이터 접근 패턴에 대해 알아보기

• 쓰기 부하: 시간이 지날수록 쓰기 작업이 꾸준히 많아져요. 우리 시스템은 시시각각 변하는 데이터를 다루기 때문에, 쓰기 작업이 정말 많이 발생한답니다.
• 읽기 패턴: 읽기 작업은 좀 특이해요. 갑자기 많아졌다가, 어느 순간 아예 요청이 없을 수도 있어요. 마치 봄비처럼 갑자기 쏟아지다 그치는 것 같죠?
• 데이터 저장소 시스템 고민
  • 데이터 저장소를 어떻게 구축할지 고민이 많으시죠? 일반적인 데이터베이스를 쓰는 것보다는, 우리 데이터의 특성에 맞는 솔루션을 찾는 게 좋아요.
  • 특히 시계열 데이터를 다루는 우리 시스템에는 InfluxDB나 Prometheus 같은 전문 도구가 훨씬 잘 맞아요. 이미 시장에 좋은 도구들이 많으니, 굳이 처음부터 새로 만들려고 하지 않아도 돼요.

도메인 바탕의 설계안

• 지금까지 얘기한걸 바탕으로 대략적인 설계를 진행해볼께요.
• 
• 우리 시스템의 주요 도메인을 소개할게요
  • Metrics Source: 여기서 우리의 모든 지표들이 시작되죠.
  • Metrics Collector: 이 친구들은 지표들을 모아서 시계열의 기록으로 변환해주는 역할을 해요.
  • Time-Series Database: 여기는 모든 지표들이 시간의 흐름에 따라 안전하게 보관되는 곳이에요.
  • Query Service: 궁금한 게 있을 때 이 친구에게 물어보면 돼요. 좋은 DB가 있다면, 이 친구가 할 일이 훨씬 적어져요.
  • Alerting System: 중요한 일이 생기면 바로 알려줘야 하죠. 다양한 방법으로 경보를 전달해줘요.
  • Visualization System: 숫자와 데이터로 가득 찬 세상을 알아보기 쉽고 이해하기 쉬운 그래프와 차트로 변환해줘요.

상세 설계로 가볼까요?

• 지표 수집
  • 지표 수집에는 크게 두 가지 방식이 있어요: Pull / Push
  • Pull 모델에서는 수집기가 모든 지표를 직접 가져와요. 변화가 많은 환경에서는 조금 까다로울 수 있지만, etcd나 zookeeper 같은 도구로 해결할 수 있어요. 하지만 주의해야 할 점은, 지표 수집기가 여러 개일 때 중복된 지표를 가져올 수도 있다는 거예요. 이를 해결하기 위해 각 서버를 분배하는 방법을 써요.
  • Push 모델에서는 지표를 만드는 곳에서 직접 보내줘요. 일반적으로는 모듈에 작은 에이전트를 설치해서 지표를 전송하죠. 이 방법의 좋은 점은 데이터를 사전에 처리할 수 있다는 거예요.

각 방식은 장단점이 있어서, 우리 시스템에 더 잘 맞는 방식을 골라야 해요.

아래 표에서 각 방식의 특징을 비교해 봤어요!

지표 전송 파이프라인 확장하기

• 
• 지표 수집은 많은 양을 감당해야 하니 서버 클러스터로 구성하는 건 어떨까요?
• 만약 데이터베이스에 문제가 생겨 전송에 실패하면 데이터가 날아갈 수도 있으니, 안전하게 큐를 하나 세워두는 게 좋겠어요.
• 이렇게 하면 수집 과정과 처리 과정 사이를 더 탄탄하게 연결할 수 있어요.

데이터 집계 어디서 할까?

• 수집 에이전트에서 하기: 여기서는 간단한 합산 같은 건 할 수 있지만, 복잡한 집계는 힘들어요. 가지고 있는 데이터만 볼 수 있으니까요.
• 데이터 수집 파이프라인에서 하기: 이 방법은 데이터 양을 줄일 수 있는 장점이 있지만, 원본 데이터를 잃어버릴 수 있고, 데이터가 늦게 도착했을 때 집계하는 데 문제가 생길 수 있어요.
• 질의할 때 하기: 가장 유연한 방법이지만, 질의 속도가 느려질 수 있어요.
• 지표가 요구하는 정확성과 데이터의 크기에 따라 적절한 지점에서 질의해야 해요!

질의 서비스는 어떻게 만들까?

• 시각화 도구나 경보 시스템과 데이터베이스 사이에서 매끄럽게 데이터를 전달해줄 질의 서비스가 있으면 좋겠어요.
• 캐시 계층을 추가하면 데이터베이스의 부하를 줄이고 더 빠른 서비스를 제공할 수 있어요.
• 

저장소 계층 디자인

• 데이터 인코딩과 압축: 데이터의 첫 값을 저장하고 이후 값들은 변화량만 저장하면 얼마나 많은 공간을 아낄 수 있는지 상상해 보세요!
• Downsampling: 시간이 지남에 따라 해상도를 낮춰서 데이터를 더 효율적으로 저장해요. 예를 들어, 최근 7일은 초 단위로, 그 다음 30일은 분 단위로, 그리고 1년 동안은 시간 단위로요.
• Cold Storage: 오래된 데이터는 비용이 적게 드는 저장 공간으로 옮겨 보관해요. AWS의 Glacier 같은 서비스를 사용하면 돼요.

경보 시스템 구성하기

1. 우선, 정책 파일을 캐싱해두고
2. 경보 관리자가 이를 확인한 후
3. 정책에 맞게 질의를 날려요.

• 경보는 중복 없이, 필요한 곳에만 정확히 전달되어야 해요.

• 경보 메시지는 키-값 저장소에 안전하게 보관되며, 이후에 카프카 같은 메시지 큐를 통해 필요한 곳으로 전달돼요.

• 

시각화 시스템 만들기

• 데이터를 아름답게 보여줄 시각화 시스템이 필요해요.
• 그라파나 같은 멋진 도구가 이미 많으니, 굳이 처음부터 만들 필요는 없어요.
• 데이터와 사용자 사이에서 멋진 다리 역할을 해줄 거예요.

완성

• 자 그럼 이제 위에서 고민한 것을 모두 더해서 완성된 아키텍처를 구성할 거예요.
• 
• 어때요? 이제 모니터링 시스템을 갖게 됐어요!

6. 정리..

현업에서 많이 사용하는 모니터링 및 알람 시스템에 대해서 설계를 해봤어요.

위에서 논의했던 내용들이 잘 반영된 설계가 나온것 같아요.

이렇게 체계적이지 않더라도 IT 서비스 회사는 모두 모니터링 시스템을 갖추고 있답니다.

혹시 면접에서 모니터링 또는 경보 시스템에 대한 설계 질문이 나오더라도 당황하지 않을 수 있겠죠? 😊