효율적인 모니터링과 신속한 장애 대응이 곧 퍼포먼스다

A41의 이더리움 인프라 전환 기술 포스트는 총 5편으로 구성되어 있습니다. 각 글은 빠르게 증가하는 이더리움 검증인의 수에 대응하며 2024년 상반기에 A41이 마주한 문제들과 이를 해결한 전략들에 대해 소개합니다.

이번 글은 세번째 편으로, 우리가 구축한 모니터링 시스템에 대해 소개합니다. 우리의 글에서 소개하는 아키텍쳐가 범용적인 상황을 아우르는 답이 될수 없음을 미리 밝힙니다.

Author: Snow Park (@sinabro2dev)

확장 가능한 블록체인 인프라를 위한 A41 테크팀의 고민과 선택들에 대한 기술 포스트 목록입니다. 다른 편을 읽고 싶으시다면 아래의 리스트를 확인해주세요.

1. 쿠버네티스로 확장 가능한 이더리움 밸리데이터 인프라 구축하기
2. 이더리움 밸리데이터 유연하고 안전하게 배포하기
3. 효율적인 모니터링과 신속한 장애 대응이 곧 퍼포먼스다
4. 밸리데이터 인프라의 외부 모니터링 시스템 구축하기
5. 이더리움 밸리데이터 키, 리워드와 패널티 추적하기

효율적인 모니터링과 신속한 장애 대응이 곧 퍼포먼스다

안녕하세요! A41 블록체인 엔지니어 Snow입니다. 저희 팀은 다양한 블록체인의 밸리데이터로서 체인을 운영하며, 자연스레 시도때도 없는 장애 상황을 마주하곤 합니다. 신속한 대응을 위해서는 운영 중인 모든 서비스를 타깃으로 상태를 지속적으로 탐지하고 상황을 알리는 시스템이 필요합니다. 따라서 이번 글에서는 밸리데이터에게 장애가 구체적으로 무엇인지를 정의하고 서비스의 운영에 대한 긍정적인 지표와 신뢰 향상을 위해 구축한 효율적인 서비스 모니터링 방안을 공유합니다.

1. 밸리데이터에게 장애란

서비스 회사에게 새로운 프로덕트 개발만큼 중요한 것은 서비스를 안정적으로 운영하는 것입니다. 장애로 인해 금전적인 손해가 발생하기 때문이기도 합니다만, 그보다 중요한 것은 서비스 신뢰를 구축하고 지키는 것입니다. 장애는 서비스 운영 중에 발생하는 성장통 중 하나이기 때문에 원천적으로 막는 것은 불가능에 가깝습니다. 그러나 지속되는 문제 상황은 서비스와 운영 능력에 대한 의문을 키울 수 있고, 장기적으로는 저희의 평판을 하락시킬 수 있습니다. 그렇기에 서비스 운영 중에 맞닥뜨릴 수 있는 여러 장애들을 얼마나 신속하게 반응하고 유연하게 대응할 수 있는지가 중요합니다. 저희는 블록체인 인프라를 다루는 팀이므로, 도메인의 특징을 살려 어떻게 신뢰를 지켜나가고 있는지 설명해보려 합니다.

1.1. 블록체인이라는 도메인

블록체인은 종류에 따라 다양한 합의 메커니즘을 가집니다. 비트코인은 작업 증명으로 합의하는 대표적인 체인이고 이더리움은 지분 증명을, 코스모스는 위임 지분 증명을 활용합니다. 오늘날, 일부의 경우를 제외한 대부분의 블록체인은 지분 증명을 기반으로 하는 합의 메커니즘을 토대로 동작하고 있습니다.

지분 증명이란, 블록체인 밸리데이터를 운영 중인 주체가 보유한 지분만큼 의사결정 권한을 갖는 합의 방식입니다. 이때 블록체인 프로토콜에는 밸리데이터가 올바르게 행동하도록 동기부여하기 위해 여러 규칙이 있습니다. 대표적으로 체인 운영에 보탬이 될 때 지급하는 리워드 체계와 악의적인 행동을 취할시 적용하는 패널티 체계가 존재합니다. 대부분의 밸리데이터는 고객의 자산을 위임받아 운영되기 때문에 지속적으로 패널티를 받게 된다면 고객의 자산에 금전적인 손해를 끼칠 뿐만 아니라, 대외적으로 운영 능력에 대한 신뢰와 평판까지 떨어집니다. 따라서 저희에게 서비스 장애는 운영 중인 밸리데이터가 패널티를 받는 상황이라고 할 수 있으며, 이를 해결하는 것이 중요한 목표 중 하나입니다.

1.2. 지분 증명 체인 전반에 걸친 장애

블록체인 밸리데이터를 운영할 때 만날 수 있는 장애 중, 네트워크의 다수가 문제를 겪고 있는 상황이 종종 발생합니다. 프로토콜 설계의 일부가 문제되거나 구현 클라이언트에 버그가 발견되는 등, 여러 요인으로 인해 체인의 정상적인 동작이 어려운 경우입니다. 다수의 밸리데이터 운영자가 장애를 겪고 있기에, 저희가 해결책을 적용한다고 해서 문제가 사라지는 상황은 아닙니다. 그러나 저희는 적지 않은 지분을 토대로 밸리데이터를 운영하고 있기에, 체인의 정상화를 위해서 발생한 문제를 식별하고 빠르게 해결책을 적용해야 하는 의무가 있습니다.

1.3. 특정 밸리데이터에 국한된 장애

반면에 일부 밸리데이터에게만 문제 상황이 생기는 상황도 있습니다. 블록체인은 탈중앙화되어 있기 때문에 체인 네트워크가 멈추거나하는 이슈는 없지만, 운영 중인 밸리데이터가 체인 합의에 기여하지 못하고 있는 경우입니다. 그렇기에 온전히 장애 상황을 인지하는 것은 각 오퍼레이터의 몫이자 역량입니다. P2P 네트워크에 레이턴시 이슈가 있거나 체인 클라이언트 업그레이드 중 문제가 발생하는 등, 여러 요인으로 인해 밸리데이터가 패널티를 받을 수 있습니다. 오퍼레이터의 운영 환경과 설정에 의해 문제가 생긴 것이기 때문에 즉각적인 운영 개선이 필요합니다. 이를 위해 각 장애마다 어떤 문제인지 식별하고, 신속하게 해결 대안을 적용하여 지속적으로 패널티 받지 않도록 해야합니다.

2. 365일, 24시간 모니터링

앞선 파트에서는 저희에게 장애가 무엇이고 왜 신속한 대응이 중요한지 알아봤습니다. 그렇다면 이를 위해 필요한 것은 무엇일까요? 언제든지 장애를 즉시 감지하고, 이를 담당자와 팀에 신속히 알리는 시스템을 마련하는 것입니다. 이를 위해 모니터링이 다해야 하는 책임과 달성해야 하는 요건을 살펴보겠습니다.

2.1. 모니터링의 책임

모니터링은 대상을 지속적으로 바라보며 상태 변화를 관찰하고, 서비스의 로그와 매트릭 수치를 근거로 장애 여부를 확인합니다. 장애 상황 식별의 근간이 되는 시스템이기 때문에 안정성이 중요시되며, 상태 변화를 놓지지 않도록 구성되어야 합니다. 따라서 저희는 우선적으로 내부 모니터링을 통해 수집되는 정보를 바탕으로 장애를 식별합니다. 동시에 외부에서 상황을 재확인하여 오탐을 방지하고, 예기치못한 내부 모니터링 시스템의 장애에도 대응하기 위해 외부 모니터링도 병행 중입니다.

내부 모니터링에서는 주로 외부에서 수집하기 어려운 지표, 예를 들어 머신의 Swap Memory 정보 등과 블록체인 밸리데이터 운영 시 수집되는 지표를 종합하여 상태를 확인합니다. 이어서 외부 모니터링에서는 내부에서 수집되는 지표가 왜곡되거나 내부 시스템에 문제가 생긴 경우, 혹은 외부에서만 수집 가능한 경우를 고려하여 상태를 확인합니다. 이번 글에서는 내부 모니터링을 중점적으로 다루며, 이어지는 글을 통해 외부 모니터링 시스템을 소개하겠습니다.

2.2. 모니터링의 요건

모니터링의 책임을 다하기 위해 시스템은 크게 네가지 요소를 고려해야 합니다.

2.2.1. 수집

먼저 최대한 구체적이고 풍부한 정보를 수집할 수 있어야 합니다. 저희는 수십 개가 넘는 종류의 블록체인에서 밸리데이터를 운영 중이고, 베어메탈과 클라우드 등 다양한 환경에서 구동 중입니다. 그렇기에 정확한 상태 식별을 위해서는, 이곳저곳에서 수집되는 정보에 구체적인 맥락이 포함되어야 합니다. 또한 블록체인 정보 뿐만 아니라 머신의 CPU, Memory, Storage, Network 상태 정보도 수집해야 합니다.

2.2.2. 전달

그리고 수집된 정보를 토대로 장애를 식별하고, 파악하기 쉽게 시각화할 수 있어야 합니다. 많은 정보가 쏟아지는 상황에서 일일이 장애 상황을 직접 확인하는 것은 비용이 큽니다. 초단위로 쏟아지는 매트릭을 하나하나 질의하여 문제를 식별하는 것은 불가능에 가깝습니다. 따라서 문제 상황을 정의하는 기준을 만들고, 기준에 도달하면 관련 필요 정보만을 알려야 합니다. 또한 수집된 여러 정보를 종합적으로 고려하기 위해 지표를 일관성있게 시각화하여 전달해야 합니다.

2.2.3. 구성

다음으로, 다양한 요구 조건에 따라 운영 환경이 변할 수 있기 때문에 시스템은 확장 가능해야 합니다. 타깃이 점차 많아지고 수집하는 정보가 점점 많아짐에 따라 요구되는 시스템의 하드웨어 사양과 트래픽 처리 수준이 높아질 수 있습니다. 이러한 환경에서도 정보를 수집할 수 있는 모니터링 시스템으로 구성되어야 하며, 수직적 혹은 수평적 확장이 유연하게 가능해야 합니다.

2.2.4. 관리

마지막으로 모니터링 시스템은 팀 누구나 접근하여 개선할 수 있어야 하기 때문에 변경 사항에 대한 관리와 권한 설정이 가능해야 합니다. 수집되는 정보의 형태, 장애 상황을 정의하는 기준, 그리고 정보 시각화 등 구성 요소의 변경에 대한 기록이 남겨져야 합니다. 또한 형상 관리를 통해 일관성 있는 프로세스와 결과물을 보장해야 합니다.

3. 우리의 등대, 내부 모니터링 시스템

저희는 안정적인 블록체인 밸리데이터 운영을 위해, 앞서 정의한 목적과 요구 조건을 달성하는 내부 모니터링 시스템을 구축했습니다. 먼저 시스템의 구성을 간략하게 살펴보고, 시스템 구현에 있어서 고려했던 여러 요인들을 그 배경과 함께 공유하겠습니다.

3.1. 시스템 아키텍처

A41 내부 모니터링 시스템 아키텍처

모니터링 시스템을 구성하는 주요 컴포넌트들은 확장성과 안정성을 고려하여 모두 쿠버네티스 클러스터에 배포되어 있습니다. 언제든지 컴포넌트를 이루는 파드의 수를 조절해서 부하를 조절하거나 새로운 컴포넌트 혹은 리소스를 추가 및 변경하는 등의 작업을 자유롭게 할 수 있습니다. 각 컴포넌트의 역할과 동작은 아래에서 소개하겠습니다.

3.2. 매트릭 수집

시스템의 매트릭 수집 컴포넌트

수집 대상이 되는 매트릭은 크게 두 종류, 운영하고자 하는 서비스 지표를 나타내는 매트릭과 머신의 상태를 나타내는 매트릭으로 구분됩니다. 블록체인 밸리데이터를 운영할 때의 주요 지표는 결국 밸리데이터 의무를 다하고 있는지 확인하는 것입니다. 일례로 블록 생성을 잘 하고 있는지 혹은 블록 생성을 위한 투표에 잘 참여하고 있는지 등이 있을 수 있습니다. 더불어 머신의 상태 확인을 위해서 CPU Busy, Network I/O, Storage R/W 등의 사용량 추이를 확인합니다.

지난 2달 동안 증가한 매트릭 수집 추세, 최근에는 7천만개의 매트릭을 수집하고 있음

수천만개의 정보를 효과적으로 파악하기 위해서는 전략이 필요합니다. 저희는 USE 방법론과 RED 방법론을 토대로 유효한 매트릭을 선별합니다. USE 방법론은 머신의 상태에 대한 기준이고 RED 방법론은 서비스의 상태에 대한 기준으로, 각각 다음 항목으로 구성됩니다.

모니터링 매트릭 USE 방법론

모니터링 매트릭 RED 방법론

위 전략을 토대로 장애 상황과 원인을 파악하기 위해서는 종합적인 매트릭 파악이 필요합니다. 장애의 원인은 어느 한 요인 때문이 아니라 복합적인 이유일 가능성이 매우 높기 때문에 해당 클라이언트가 동작 중인 머신의 상태도 함께 살펴봐야 합니다. 클라이언트 운영을 위한 설정값이 잘못 되었을 수도 있고 머신의 디스크 여유 공간이 부족한 상황일 수도 있습니다. 심지어는 머신이 속한 데이터 센터의 네트워크 대역폭 제한이 문제가 되는 상황까지 고려해야 합니다. 이렇듯 모니터링 시스템은 특정 머신의 어느 한 매트릭을 보고 판단하기보다, 여러 매트릭을 다양한 머신으로부터 수집해서 종합적으로 상태 변화를 확인합니다.

지난 2달 동안 데이터센터별 네트워크 다운로드 트래픽 추이

대상이 될 매트릭을 확보했다면, 이들을 어떻게 수집하고 관리할지 정해야 합니다. 저희가 운영하고 있는 블록체인의 종류는 매우 다양하고 앞으로 그 수는 더욱 늘어날 수 있습니다. 더불어 매트릭을 제공해주는 블록체인 클라이언트는 저희가 마음대로 수정하기 어려운 상황이기도 합니다. 그리고 확장성 높은 블록체인 인프라를 위해 클러스터와도 궁합이 잘 맞아야 합니다. 이러한 상황을 고려했을 때, Poll 방식으로 매트릭을 수집하고 관리하는 프로메테우스가 가장 적합한 기술 스택입니다. 모든 매트릭 수집 구성을 프로메테우스 서버가 관리하기 때문에 새로운 서비스를 추가하거나 변경할 때의 운영 복잡성을 크게 줄일 수 있습니다. 그리고 프로메테우스의 서비스 디스커버리 지원 덕분에 쿠버네티스 클러스터 환경과도 궁합이 좋습니다.

3.3. 지표 시각화

시스템의 시각화 컴포넌트

매트릭은 Key-Value 쌍으로 표현되고 매우 많은 데이터가 주기적으로 쌓이기 때문에 한눈에 파악하기 어렵습니다. 따라서 시계열 매트릭 수집은 프로메테우스가 담당하고, 이를 시각화해서 서비스 상태 변화를 확인해주는 그라파나를 함께 사용합니다. 그라파나에는 하나의 서비스에 대해 여러 지표를 보여주는 대시보드가 존재하고, 각 대시보드에는 각 지표를 나타내는 패널로 이루어져 있습니다. 공식 문서의 Best Practice를 참고하여 대시보드를 구성하는 것을 권장하며, 저희는 블록체인 도메인의 특성을 고려하여 지표를 구분했습니다.

Config는 블록체인과 밸리데이터 운영에 필요한 설정 정보를 나타냅니다. 이더리움의 경우에는 활성화된 밸리데이터 키의 수, Execution Layer와 Consensus Layer의 클라이언트 구성, 구동 중인 머신의 메타데이터 등을 포함합니다.

이더리움 EtherFi 밸리데이터의 대시보드 중 일부

Reliability는 블록체인 운영 중 밸리데이터의 의무를 다하고 있는지 알 수 있는 정보입니다. Block Proposal와 Attestation을 얼마나 놓쳤는지, Sync Committee에는 잘 참여하고 있는지, 에러 로그는 얼마나 기록되고 있는지 등이 포함됩니다.

이더리움 Lido 밸리데이터의 대시보드 중 일부

Traffic은 블록체인 네트워크와 관련된 지표를 의미합니다. 현재 블록 높이는 얼마이고, 최근 수분동안의 평균 블록 생성 시간은 몇초 정도이고, 멤풀의 사이즈, 초당 트랜잭션 처리 속도 등이 포함됩니다.

Cosmoshub 블록체인 밸리데이터의 대시보드 중 일부

Saturation은 머신 상태에 대한 정보입니다. CPU Busy 수준은 어느정도이고, Memory는 얼마나 사용중이며, Disk Latency, 초당 Network Receive/Transmit 등을 포함합니다.

데이터센터에 위치한 머신의 대시보드 중 일부

이렇게 구조를 잡아놓더라도, 그라파나 UI를 통해 수정을 하다보면 대시보드들은 일관성을 잃고 결국 레거시화가 진행되기 마련입니다. 각 대시보드가 제각기 다른 구성을 갖게 되고, 팀원은 대시보드가 무엇을 표현하고자 하는지 파악이 어려워집니다. 이는 사용하는 사람만 대시보드를 관리하게 되며, 악순환이 반복됩니다. 이를 방지하기 위해 UI 상에서의 수정 권한을 제한하고, 네이밍과 대시보드 구성에 대한 규칙을 정한 후 리뷰하는 팀 프로세스를 도입했습니다.

시스템의 그라파나 대시보드 IaC 컴포넌트

apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
  name: kubernetes-ethereum-lido
  namespace: monitoring
spec:
  instanceSelector:
    matchLabels:
      dashboards: "external-grafana"
  folder: "Validator"
  json: >
    ...

또한 인프라 구성을 코드로 관리하기 위해 개인이 아닌 그라파나 오퍼레이터를 통해 대시보드와 패널을 형상관리합니다. 오퍼레이터가 주기적으로 코드화된 대시보드를 기준으로 싱크를 맞추며 코드화되지 않은 부분은 덮어씌워집니다.

3.4. 장애 상황 정의

모니터링 시스템은 수집한 매트릭을 토대로, 사전에 정의한 기준에 도달했는지와 장애 상황인지를 감지해야 합니다. 프로메테우스의 알러트 룰이라는 규칙을 정의하여 블록체인 서비스가 문제 상황인지 확인할 수 있습니다. PromQL로 매트릭을 조회하고 그 결과와 매트릭의 라벨을 활용하여 장애 상황에 대한 문맥을 확인합니다.

이때 자주 사용되는 쿼리문은 재사용을 높이기 위해 Recording Rule으로 정의하고 Alerting Rule에서 이를 가져다 사용할 수 있습니다. Recording Rule은 기존 매트릭을 가공하여 새로운 매트릭을 생성하는 것이며, 공식 문서의 Best Practice를 참고해서 정의하는 것을 권장합니다.

또한 장애 상황의 심각성은 매번 다릅니다. 블록체인 밸리데이터가 PoS 합의에 지속적으로 참여하지 못한 상황과 순간적으로 높은 TPS를 보이는 상황은 서로 다른 성격을 가집니다. 무분별하게 장애 상황을 감지하지 않도록 이런 경우들을 구분하여 우선순위별로 나누는 것이 중요합니다.

장애 심각도 정의 그래프

장애 심각도 Severity 단계별 정의

장애 심각도 Priority 단계별 정의

Severity는 발생한 장애로 인해 서비스 혹은 시스템이 어느 정도 영향을 받는가를 기준으로 구분하며, 이때 장애 해결을 위해 드는 노력과 관계 없이 설정하도록 주의합니다. Priority는 장애 대응을 위해 해야하는 업무의 우선 순위가 어느 정도로 높은가를 기준으로 구분합니다. 저희 팀은 두 기준을 종합하여 네 가지 수준으로 장애 상황을 나누어 장애 상황을 정의합니다.

1. Red Signal: Fatal 수준으로, 즉각적인 대응이 필요한 장애입니다.
2. Orange Signal: Critical 수준으로, 당장 조치를 취하지 않아도 되지만 지속적인 관찰이 필요한 장애입니다.
3. Yellow Signal: Warning 수준으로, 서비스 운영에 잠재적인 영향이 있으나 참고 수준의 정보인 장애입니다.
4. Green Signal: Information 수준으로, 서비스 운영에 직접적인 관련이 없고 참고 수준의 정보인 장애입니다.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
     resourceType: monitoring
  name: ethereum-cc.rules
  namespace: monitoring
spec:
  groups:
  - name: EthereumCC
    rules:
    - record: ':validator_performance_attestations:ratio'
      expr: |
        (
          validator_performance_included_attestations
        ) / on(namespace, job, endpoint, network) group_left() (
          validator_performance_expected_attestations
        ) >= 0

    - alert: TekuMainnetValidatorAttestaionRatioDropRapidly
      annotations:
        value: '{{ humanizePercentage $value }}'
        summary: 'Attestation ratio on mainnet dropped rapidly'
        description: 'Teku validator on mainnet failed attestation ratio is under 80%'
        dashboard_url: '...'
      labels:
        severity: critical
        namespace: '{{ $labels.namespace }}'
        job: '{{ $labels.job }}'
        endpoint: '{{ $labels.endpoint }}'
      for: 0s
      expr: |
        :validator_performance_attestations:ratio{network=~"mainnet"} <= 0.8

그리고 정의한 알러트 룰은 프로메테우스 오퍼레이터에 의해 형상관리 됩니다. 오퍼레이터는 PrometheusRule CRD로 작성된 오브젝트를 감지하여 프로메테우스 서버에 알러트 룰을 반영합니다. 이를 통해 장애 상황에 대한 정의를 IaC (Infrastructure as Code)로 관리할 수 있으며, 추후의 GitOps 환경 구성을 위한 초석이 됩니다.

3.5. 상황 전달

시스템의 장애 알림 컴포넌트

수집한 매트릭과 정의한 기준을 토대로 모니터링 시스템이 장애를 감지했다면 이 상황을 담당자와 팀에게 알려야 합니다. 이때 장애 수준을 고려하여 알림의 중요도를 매기고, 중요도와 더불어 알림이 갖는 문맥을 토대로 알림의 효과적으로 전달되어야 합니다. 또한 장애 상황을 식별할 수 있는 정보를 추상화하여 알림 내용이 일관성을 갖도록 하는 것이 좋습니다.

시스템이 식별하는 모든 상황이 심각한 장애 상황은 아니기에 각 상황을 동일하게 전파한다면 담당자는 심한 피로감을 느낄 수 있습니다. 장애 상황을 정의할 때 구분한 우선순위를 기준으로 알림 정책을 설정합니다. 더 높은 우선순위의 장애 상황은 보다 즉각적으로 담당자가 인지하도록 알림을 보내고, 그렇지 않은 장애는 비동기적으로 확인하도록 알림을 전송합니다. 예를 들어 Warning 수준의 상황은 슬랙 #infra-alert 채널에 메시지가 전송되며 담당자의 확인을 강제하지 않습니다. 그러나 Fatal 수준의 상황은 담당자 태그와 함께 슬랙 #infra-urgent 채널에 메시지가 전송되며, 동시에 페이져듀티를 통해 온콜 알림도 이뤄집니다. 즉각적인 대응이 필요하기에 담당자를 포함한 팀은 수분내로 장애 상황을 인지할 수 있도록 정책을 구성했습니다.

지난 1달 동안 알러트매니저의 알림 증가 추이

그리고 동시에 많은 장애가 발생하는 상황도 고려해야 합니다. 예를 들어 데이터센터의 일부 머신들이 물리적으로 다운된 경우에는 머신의 수와 설정된 알러트 룰에 비례하여 수많은 알림이 전송될 수 있습니다. 이런 상황은 알림 시스템에 과부하를 걸 수 있고 알림의 가독성도 떨어지기에 알림을 적절히 그룹핑하여 전달하는 정책도 필요합니다. 위 예시처럼 머신에 문제가 생긴다면, 매트릭의 머신을 가리키는 라벨로 그룹핑해서 여러 서비스의 장애 상황을 하나의 알림으로 전송할 수 있습니다. 혹은 서비스에 문제가 생긴 경우라면, 장애 상황을 정의한 알러트 룰로 장애를 묶어서 여러 머신의 장애 상황을 하나의 알림으로 전송할 수도 있습니다. 저희 팀은 머신이 물리적으로 다운되는 경우보다 서비스에 문제가 생기는 경우가 확률적으로 더 잦을 가능성이 높다는 판단 하에 후자의 방법으로 알림을 그룹핑합니다.

Information 수준의 알림 예시

Warning 수준의 알림 예시

Fatal 수준의 알림 예시

장애 상황 식별에 필요한 정보를 일관성있는 구조로 템플릿화하여 알리는 것도 중요한 요소입니다. 모든 알러트 룰은 name, description, job, namespace, endpoint 등과 같이 상황을 식별하고 문맥을 전달하는 필드를 가져야 합니다. 이 정보들을 담는 템플릿를 정의하고 시스템이 해당 템플릿으로 알림을 보냄으로써 담당자가 장애 상황을 빠르게 파악할 수 있도록 도와줍니다.

4. 장애를 알아채다

구축한 내부 모니터링 시스템 덕분에 보다 효율적으로 상황을 탐지하고 신속하게 장애에 대응할 수 있게 되었습니다. 여러 사례 중 한 상황을 시간 순으로 살펴보며 팀이 시스템을 통해 장애를 인지하는 과정을 알아보겠습니다.

4.1. 장애 탐지

지난 2024년 3월 27일 오후 5시경 저희가 운영 중인 이더리움 밸리데이터 중 다수의 Teku Consensus Client가 Critical 과 Fatal 수준의 장애 상황을 겪고 있음을 확인했습니다. 슬랙을 통해서 알림이 왔고, 동시에 페이저듀티를 통해서도 온콜 알림이 왔습니다.

장애 상황 알림 1

장애 상황 알림 2

사전에 설정해둔 아래의 알러트 룰과 알림에서 알려준 상황 문맥 덕분에 팀은 장애를 신속하게 인지할 수 있었습니다. 위 장애들은 특정 파드 혹은 머신을 가리키는 것이 아닌 다양한 곳에서 이더리움 밸리데이터의 의무를 다하지 못하고 있음을 알려줍니다. 특히 다른 클라이언트에서는 장애가 없지만 Teku 클라이언트에서 공통으로 장애가 발생하고 있기에, 이더리움 네트워크 전체의 문제는 아니며 특정 클라이언트의 문제임을 전제로 상황에 접근할 수 있었습니다.

4.2. 장애 파악

장애 상황 알림을 받은 후, 그라파나에 접근하여 여러 지표들로 보다 상세한 상황을 파악합니다. 아래 그래프는 장애가 발생한 3월 27일과 다른 날과의 Teku 클라이언트의 합의 참여 정도를 보여줍니다. 정상적인 상황에서는 95%+ 수준을 유지하지만, 위 장애가 발생한 시기에는 무려 50% 이하로 퍼포먼스가 떨어졌음을 알 수 있습니다.

장애 발생 전후를 비교할 수 있는 대시보드

4.3. 장애 대응

이후 팀원들은 파악한 문맥을 토대로 장애 원인을 파악하고 대응했습니다. 당시 문제는 이더리움 덴쿤 업그레이드 이후 Teku 클라이언트가 안정적으로 퍼포먼스를 관리하지 못한 것이 원인이었습니다. 위 상황 이전에도 종종 장애 알림이 발생하기도 했지만, 특히 저 시기에 동시다발적으로 문제가 생겼던 이유는 이더리움에 Blob을 활용한 서비스가 등장하여 관련 트래픽이 급증했기 때문이었습니다. 따라서 클라이언트의 파라미터 일부를 조정하여 조금 더 많은 리소스를 사용하도록 일시적으로 장애에 대응하고 이후 클라이언트 업그레이드로 해결했습니다.

장애 대응을 위한 커뮤니케이션

장애 해결 알림

5. 더 나아가기

저희 팀의 모니터링 시스템은 마치 망망대해를 밝히는 등대와 같이 중요한 역할을 수행하고 있습니다. 등대가 어둠 속 바다에서의 위험을 관리하듯이, 모니터링 시스템은 구축된 인프라와 운영 중인 서비스에서 발생하는 문제를 감지하고 해결할 수 있도록 돕습니다. 밤낮으로 머신과 블록체인 서비스의 상태 변화를 감시하며 실시간으로 대상의 현황을 알리고, 문제 상황에 처할시에 이를 경고하고 조치를 취할 수 있도록 공유합니다.

확장성있는 아키텍처 상에서 수천만개 이상의 정보를 효과적인 전략으로 수집하고, 일관성있는 구조와 IaC를 통해 매트릭을 시각화하며, 장애 상황을 세밀하게 구분하고, 효율적으로 알림을 전달 받습니다. 이렇게 고도화된 시스템 덕분에 저희 팀에서 체감하는 오퍼레이션 비용은 절반 수준으로 감소할 수 있었습니다.

그런데 만약 등대의 등불에 이상이 생겨 제대로 불을 밝히지 못하면 어떨까요? 혹은 등대 자체가 무너져버려 복구하기 어려운 상황을 마주하면 어떻게 해야할까요? 꼼짝없이 위험에 노출되며 심지어는 문제 상황을 인지하기도 어려울 수 있습니다. 저희 팀은 이런 상황을 대비하여, 그리고 보다 양질의 상태 감시를 위해 외부 모니터링 시스템도 구축하여 운영 중입니다. 이어지는 글 “밸리데이터 인프라의 외부 모니터링 시스템 구축하기"에서 외부 모니터링 시스템에 대해 소개하겠습니다.