SRE에서의 Elastic Observability와 사고 대응
서비스 신뢰성 사례
디지털 시대에 소프트웨어 서비스는 현대 비즈니스의 중심에 있습니다. 스마트폰의 앱만 봐도 알 수 있습니다. 쇼핑, 뱅킹, 스트리밍, 게임, 독서, 메시지, 승차 공유, 일정 관리, 검색...그 밖에도 수많은 일들을 처리하고 있습니다. 사회는 소프트웨어 서비스를 기반으로 움직입니다. 산업은 그 수요를 충족하기 위해 폭발적으로 성장해왔고, 사람들은 어디에 돈을 쓰고 주의를 기울여야 할지 수많은 것들 중에 선택합니다. 기업들은 손가락으로 한 번 밀어서 다른 서비스로 옮겨갈 수 있는 고객을 유치하고 계속 유지하기 위해 경쟁해야 합니다.
서비스 신뢰성은 가장 보편적인 기대 사항입니다. 사용자는 모든 서비스가 빠르고 제대로 잘 작동하기를 기대합니다. 그렇지 않다면, “왼쪽으로 밀어서” 좀더 빠르고 원활하게 작동하는 서비스를 선택할 것입니다. Amazon은 잘 알려진 대로 2018년 Amazon Prime Day에 발생한 가동 중단 시간 동안 대략 분당 120만 달러의 손실을 보았습니다. 그러나 서비스 신뢰성을 입증하기 위해 ‘테크 자이언트’가 될 필요는 없습니다. 가동 중단 시간과 성능 저하는 즉각적인 매출 손실이 발생하고 나서 오랜 시간이 지난 후에 사업체의 평판에 해를 끼칠 수 있습니다. 사업체들이 2018년에 DevOps 소프트웨어에 대략 52억 달러를 지출하며 운영에 막대하게 투자하는 이유도 바로 이것입니다.
이 블로그에서는 사이트 신뢰성 엔지니어링의 실제, 사고 대응 수명주기, 신뢰성을 최대화하는 데 있어 Elastic Observability의 역할을 탐색해 보려고 합니다. 여기서 다루는 내용은 소프트웨어가 그 사용자의 기대치를 충족하도록 하는 책임을 맡고 있는 기술 리더 및 엔지니어와 관련된 것입니다. 끝까지 읽고 나면, 운영 팀이 사이트 신뢰성 엔지니어링과 사고 대응을 어떻게 수행하는지, 그리고 Elastic Observability와 같은 기술 솔루션을 사용해 어떻게 그 목표를 달성하는지에 대해 기본적으로 확실히 이해할 수 있게 될 것입니다.
SRE란 무엇인가?
사이트 신뢰성 엔지니어링(SRE)은 소프트웨어 서비스가 그 사용자의 성능 기대치를 충족하도록 하는 작업입니다. 간단히 말해, SRE는 서비스를 계속 신뢰할 수 있도록 만듭니다. SRE가 담당하는 책임은 “서비스형 소프트웨어” 그 자체만큼이나 오래된 것입니다. 최근에 Google의 엔지니어가 “사이트 신뢰성 엔지니어링”이라는 용어를 만들어냈고 널리 영향력 있는 책이 된 사이트 신뢰성 엔지니어링에서 그 프레임워크를 성문화했습니다. 이 블로그에서는 그 책의 개념을 차용하고 있습니다.
사이트 신뢰성 엔지니어(SRE)는 가용성, 대기 시간, 품질, 포화도 등과 같은 지표를 사용해 서비스 수준 목표를 달성하는 책임을 담당합니다. 이러한 유형의 변수는 사용자의 서비스 경험에 직접적으로 영향을 미칩니다. 그러므로 SRE에 대한 비즈니스 사례에서 만족도가 높은 서비스는 수익을 창출하고 효율적인 운영은 비용을 억제합니다. 이를 위해, SRE는 두 가지 작업을 하는 경우가 많습니다. 첫째, 서비스 신뢰성을 보호하기 위한 사고 대응 관리와 둘째, 개발 및 운영 팀들이 서비스 신뢰성을 최적화하고 수고 비용을 줄일 수 있는 솔루션과 모범 사례를 마련하는 것입니다.
SRE는 다음과 같이 SLA, SLO, SLI의 견지에서 서비스의 바람직한 상태를 표현하는 경우가 많습니다.
- 서비스 수준 계약(SLA) - "사용자가 기대하는 것은 무엇인가?" SLA는 서비스 제공자가 그 서비스의 작동에 대해 그 사용자에게 하는 약속입니다. 일부 SLA는 계약을 구성하며, 서비스 제공자가 SLA의 위반으로 피해를 입은 고객에게 보상을 할 것을 요구합니다. 다른 것들은 함축적이며 관찰된 사용자 행동을 기반으로 합니다.
- 서비스 수준 목표(SLO) - "우리는 언제 조치를 취하는가?" SLO는 내부 한도이며 서비스 제공자는 SLA의 위반을 방지하기 위해 이 한도 이상을 유지하기 위해 조치를 취합니다. 예를 들어, 서비스 제공자가 99%의 가용성을 약속하는 경우, 99.9%의 가용성이라는 더 엄격한 SLO는 SLA의 위반을 방지할 수 있는 충분한 시간을 확보하도록 할 수 있습니다.
- 서비스 수준 지표(SLI) - "우리는 무엇을 측정하는가?" SLI는 SLA나 SLO의 상태를 설명하는 관찰할 수 있는 메트릭입니다. 예를 들어, 서비스 제공자가 99%의 SLA를 약속하는 경우, 서비스에 대한 성공적인 핑의 비율 같은 메트릭이 그 SLI로 기능할 수 있습니다.
SRE가 모니터링하는 가장 일반적인 SLI 몇 가지는 다음과 같습니다.
- 가용성은 서비스의 가동 시간을 측정합니다. 사용자는 서비스가 요청에 응답할 것을 기대합니다. 이것은 모니터링하는 가장 기본적이며 중요한 메트릭 중 하나입니다.
- 대기 시간은 서비스의 성능을 측정합니다. 사용자는 서비스가 요청에 시의적절하게 응답할 것을 기대합니다. 사용자가 “시의적절하다”고 인지하는 것은 제출하는 요청 유형에 따라 다릅니다.
- 오류는 서비스의 품질과 정확성을 측정합니다. 사용자는 서비스가 요청에 성공적인 방식으로 응답할 것을 기대합니다. 사용자가 “성공적”이라고 인지하는 것은 제출하는 요청 유형에 따라 다릅니다.
- 포화도는 서비스의 리소스 활용을 측정합니다. 이것은 서비스의 수요를 충족하기 위해 리소스를 확장해야 할 필요가 있음을 나타낼 수 있습니다.
사이트 신뢰성 엔지니어라는 직책을 달고 있지 않더라도, 서비스를 개발하고 운영하는 모두가 그 신뢰성에 책임을 집니다. 일반적으로 여기에는 다음이 포함됩니다.
- 서비스를 주도하는 제품 팀.
- 서비스를 구축하는 개발 팀.
- 인프라를 실행하는 운영 팀.
- 사용자를 위해 사고를 에스컬레이션하는 지원 팀.
- 사고를 해결하는 비상 대기 팀.
복잡한 서비스를 제공하는 조직은 실행을 주도하고 다른 팀들을 중재하는 SRE 전담 팀을 갖추고 있을 수 있습니다. 이 경우, SRE는 “개발(Dev)”과 “운영(Ops)” 간의 다리 역할을 합니다. 궁극적으로는, 구현과 상관 없이 사이트 신뢰성은 DevOps 주기에서 공동 책임입니다.
사고 대응이란 무엇인가?
사고 대응은 SRE의 맥락에서 배포를 바람직하지 않은 상태에서 바람직한 상태로 다시 돌리기 위해 기울이는 노력입니다. SRE는 바람직한 상태를 이해하며, 종종 그러한 바람직한 상태를 유지관리하기 위해 사고 대응 수명주기를 관리합니다. 일반적으로 수명주기에는 예방, 발견, 해결이 관련되며, 궁극적인 목표는 가능한 한 최대로 자동화하는 것입니다. 그럼 구체적으로 살펴보겠습니다.
예방은 사고 대응의 첫 단계이자 마지막 단계입니다. 이상적으로 사고는 CI/CD 파이프라인에서 테스트에 기반한 개발로 예방됩니다. 그러나 상황이 언제나 프로덕션에서 계획된 대로 흘러가지는 않습니다. SRE는 계획, 자동화, 피드백을 통해 예방을 최적화합니다. 사고 이전에는 바람직한 상태에 대한 기준을 정의하고, 바람직하지 않은 상태를 발견하고 해결하기 위해 필요한 도구를 구현합니다. 사고 이후에는 발생한 사항을 검토하고 어떻게 적응해야 하는지를 논의하면서 사후 분석을 합니다. 장기적으로 SRE는 KPI를 분석하고 그러한 인사이트를 사용해 제품, 개발, 운영 팀에게 개선 요청을 제출할 수 있습니다.
발견은 언제 사고가 발생했을 수도 있는지를 알고, 그 후에 대응할 적절한 채널에 경보를 보냅니다. 발견은 사고 대응 범위를 최대화하고, 평균 발견 시간(MTTD)을 최소화하고, SLO를 보호하기 위해 자동화되어야 합니다. 자동화는 전체 배포의 상태에 대한 연속적 통합 가시성, 바람직한 상태의 연속적 모니터링, 바람직하지 않은 상태가 발생하는 경우 즉각적인 경보가 필요합니다. 머신 러닝이 사고를 나타내거나 설명할 수도 있는 예기치 못한 상태 변화를 발견하는 데 도움이 될 수도 있지만 사고 발견의 범위와 정확성은 바람직한 상태의 정의에 크게 달려 있습니다.
해결은 배포를 바람직한 상태로 돌리는 것입니다. 일부 사고에는 용량이 거의 포화 상태가 되면 서비스를 자동 확장하는 등 자동화된 솔루션이 있습니다. 그러나 수많은 사고의 경우 사람이 주의를 기울여야 합니다. 특히 징후가 인식되지 않거나 원인이 불명인 경우에는 그렇습니다. 해결에는 근본 원인을 조사하고, 솔루션을 처방하기 위해 문제를 재현하며, 배포의 바람직한 상태를 복구하는 적절한 전문가가 필요합니다. 이것은 수많은 전문가, 조사, 실패한 시도를 통해 순환할 수 있는 반복적인 프로세스입니다. 검색과 소통은 그 성공에 있어 핵심적인 것입니다. 정보는 주기를 단축시키고, 평균 해결 시간(MTTR)을 최소화하고, SLO를 보호합니다.
SRE에서의 Elastic과 사고 대응
Elastic Observability는 가시성, 모니터링, 경보, 검색으로 사고 대응 수명주기를 주도합니다. 이 블로그에서는 풀 스택 배포 상태의 연속적 통합 가시성, SLO의 위반에 대한 SLI의 연속적 모니터링, 사고 대응 팀에게 자동화된 위반 경보, 그리고 대응자가 신속한 해결에 이르도록 하는 직관적인 검색 환경을 제공하는 기능을 소개합니다. 종합적으로 솔루션은 서비스 신뢰성과 고객 충성도를 보호하기 위해 평균 해결 시간(MTTR)을 최소화합니다.
통합 가시성과 데이터
관찰할 수 없으면 문제를 해결할 수 없습니다. 사고 대응에는 시간이 지남에 따라 영향을 받은 배포의 풀 스택에 대한 가시성이 필요합니다. 그러나 분산형 서비스는 아래 그림에서 볼 수 있듯이 단일한 논리 이벤트에 대해서도 너무나 복잡합니다. 스택의 각 구성 요소는 모든 다운스트림에 대한 성능 저하 또는 고장의 잠재적인 원인입니다. 제어되고 재현되지 않으면, 사고 대응자는 해결 단계에서 각 구성 요소의 상태를 고려해야 합니다. 복잡성은 생산성을 저하시킵니다. 시간이 지남에 따라 모든 것의 상태를 관찰할 수 있는 단 하나의 장소가 없다면 엄격한 SLA의 한도 내에서 사고를 해결하는 것은 불가능합니다.
복잡성 문제에 대한 우리의 답은 Elastic Common Schema(ECS)입니다. ECS는 통합 가시성에 대한 오픈 소스 데이터 모델 사양입니다. 이것은 현대적인 분산형 서비스와 인프라의 명명 규칙, 데이터 유형 및 관계를 표준화합니다. 스키마는 전통적으로 사일로에 존재했던 데이터를 사용하여 시간이 지남에 따라 전체 배포 스택에 대한 통합된 보기를 제시합니다. 이 하나의 스키마에는 스택의 각 계층에 있는 추적, 메트릭 및 로그가 공존하여 사고 대응 중에 원활한 검색 환경을 구현합니다.
ECS 표준화는 거의 노력을 들이지 않고 통합 가시성을 유지할 수 있게 해줍니다. Elastic의 APM과 Beats 에이전트는 배포에서 자동으로 추적, 메트릭, 로그를 캡처하고 데이터를 공통 스키마에 맞게 조정하며 향후 조사를 위해 중앙 검색 플랫폼으로 데이터를 전송합니다. 클라우드 플랫폼, 콘테이너, 시스템, 애플리케이션 프레임워크와 같은 널리 사용되는 데이터 소스와 통합되어 배포가 더욱 복잡해짐에 따라 데이터를 손쉽게 온보드하고 관리할 수 있습니다.
모든 배포 스택은 비즈니스마다 고유합니다. 따라서 ECS를 확장하여 사고 대응 워크플로우를 최적화할 수 있습니다. 서비스의 프로젝트 이름과 인프라는 대응자가 자신이 찾고 있는 것을 찾거나 무엇을 찾고 있는지를 알도록 도와줍니다. 애플리케이션의 커밋 ID는 빌드 시에 버전 제어 시스템에 존재했기 때문에 개발자가 버그의 기원을 찾는 데 도움이 됩니다. 기능 플래그는 카나리아 배포 상태나 A/B 테스트의 결과에 대한 인사이트를 제공합니다. 배포를 설명하고, 워크플로우를 실행하거나 사업상의 요건을 충족하는 데 도움이 되는 모든 것을 스키마에 임베드할 수 있습니다.
모니터링, 경보, 조치
Elastic Observability는 필수 SLI와 SLO에 대해 모니터링하고, 발견하고, 경보을 보냄으로써 사고 대응 수명주기를 자동화합니다. 솔루션은 Uptime, APM, Metrics, Logs, 이렇게 4개의 모니터링 영역을 대상으로 합니다. Uptime은 외부 Heartbeat를 서비스 엔드포인트로 보냄으로써 가용성을 모니터링합니다. APM은 애플리케이션 내에서 직접 이벤트를 측정하고 캡처링함으로써 대기 시간과 품질을 모니터링합니다. Metrics는 인프라 리소스 활용을 측정함으로써 포화도를 모니터링합니다. Logs는 시스템과 서비스로부터 메시지를 캡처링함으로써 정확성을 모니터링합니다.
일단 SLI와 SLO를 알면, 이를 경보와 조치로 정의하여 SLO가 위반될 때마다 적절한 데이터를 적절한 사람들과 공유할 수 있습니다. Elastic 경보는 결과가 일부 조건을 충족할 때 조치를 트리거하는 예약된 쿼리입니다. 이러한 조건은 메트릭(SLI)과 임계값(SLO)의 표현입니다. 조치는 페이징 시스템 또는 문제 추적 시스템과 같은 하나 이상의 채널에 전달되어 사고 대응 프로세스의 시작을 알리는 메시지입니다.
간결하고 실행 가능한 경보는 대응자에게 신속한 해결을 안내해 줍니다. 대응자에게는 환경의 상태와 관찰된 문제를 재현할 수 있는 충분한 정보가 있어야 합니다. 대응자에게 이러한 세부 정보를 제공하는 메시지 템플릿을 만들어야 합니다. 다음은 고려해야 할 몇 가지 세부 사항입니다.
- 제목 - "어떤 사고인가?"
- 심각도 - "사고의 우선순위는 무엇인가?"
- 근거 - "이 사고가 비즈니스에 미치는 영향은?"
- 관찰된 상태 - "무슨 일이 일어났는가?"
- 바람직한 상태 - "어떤 일이 일어났어야 하는가?"
- 컨텍스트 - "환경의 상태는 어떠했는가?" 경보의 데이터를 사용해 시간, 클라우드, 네트워크, 운영 체제, 컨테이너, 프로세스 및 사고의 기타 컨텍스트를 설명합니다.
- 링크 - "이 다음에 어디로 가야 하는가?" 경보의 데이터를 사용해 대응자를 대시보드, 오류 보고서 또는 기타 유용한 대상으로 이동시키는 링크를 생성합니다.
즉각적인 인적 주의가 필요한 보다 심각한 사고는 PagerDuty 또는 Slack 같은 실시간 채널을 통해 비상 대기 사고 대응 팀에게 알려야 합니다. 99% 이상의 가용성을 요구하는 서비스의 가동 중단 시간이 그 예일 것입니다. 이 SLA는 하루에 15분 미만의 가동 중단 시간을 허용하는데, 이는 이미 사고 대응 팀이 문제를 해결하는 데 필요한 시간보다 적은 시간입니다. 궁극적인 인적 주의가 필요한 낮은 심각도의 사고는 JIRA와 같은 문제 추적 시스템에서 티켓을 생성할 수 있습니다. 수익에 직접적인 영향을 미치지 않는 서비스의 대기 시간 또는 오류율 증가를 예로 들 수 있습니다. 기록 보관 또는 과전송을 위해 각 수신처에 대해 자체 메시지 내용을 한 번에 경보로 알리도록 선택할 수 있습니다.
조사와 검색
경보로 비상 대기 팀을 호출한 후에는 어떻게 될까요? 사고마다 해결의 길은 다르겠지만 확실한 것도 있습니다. 불같은 데이터를 다루면서 불분명한 문제를 신속하고 정확하게 해결하라는 압박감 속에서 일하고 있는 서로 다른 기술과 경험을 가진 사람들이 있을 것입니다. 이들은 보고된 증상을 찾아내고, 문제를 재현하고, 근본 원인을 조사하고, 해결책을 적용하고, 그것이 문제를 해결하는지 살펴봐야 할 것입니다. 몇 가지 시도를 해야 할지도 모릅니다. 엄청난 시간과 노력이 필요한 상황에 빠졌다고 느끼게 될 수도 있습니다. 모든 노력에는 카페인 답이 필요합니다. 정보는 사고 대응을 불확실성에서 해결로 이끄는 것입니다.
사고 대응은 검색 문제입니다. 검색은 질문에 대한 신속하고 정확한 답변을 제공합니다. 좋은 검색 환경은 그냥 “검색창” 이상입니다. 전체적인 사용자 인터페이스가 사용자의 질문을 예측하고 적절한 답변에 대해 안내해 줍니다. 가장 최근의 온라인 쇼핑에 대해 돌아보세요. 카탈로그를 훑어볼 때, 애플리케이션은 클릭과 검색 의도를 예상하고 최상의 추천과 필터를 제공하므로 더 많은 비용을 지출하고 더 빨리 지출하는 데 영향을 미치게 됩니다. 구조화된 쿼리를 작성하는 게 아니고, 무엇을 찾고 있는지도 모를 수 있지만, 그것을 빨리 찾을 수 있습니다. 동일한 원리가 사고 대응에 적용됩니다. 검색 경험의 설계는 사고 해결 시간에 큰 영향을 미칩니다.
검색은 단지 기술이 빨라서가 아니라 경험이 직관적이기 때문에 신속한 사고 대응에 핵심적입니다. 아무도 쿼리 언어의 구문을 배울 필요가 없습니다. 아무도 스키마를 참조할 필요가 없습니다. 아무도 기계처럼 완벽할 필요가 없습니다. 그냥 검색하면, 몇 초 만에 찾고 있는 것을 찾게 됩니다. 다른 것을 검색하려고 하셨나요? 검색은 안내를 제공할 수 있습니다. 특정 필드별로 검색하려고 하시나요? 입력을 시작하면 검색창이 필드를 제안하게 됩니다. 차트의 스파이크에 대해 궁금하신가요? 스파이크를 클릭하면 나머지 대시보드에 스파이크 도중 발생한 일이 표시됩니다. 검색은 빠르고 포용적이며, 적절하게 수행되면 사고 대응자에게 인간의 불완전함에도 불구하고 신속하고 정확하게 행동할 수 있는 힘을 제공합니다.
Elastic Observability는 사고 대응자의 질문, 기대, 목표를 예상하는 사고 대응을 위한 검색 환경을 제공합니다. 이 설계는 기존의 각 데이터 사일로 — Uptime, APM, Metrics, Logs — 에 익숙한 환경을 제공하고 대응자가 배포의 풀 스택을 볼 수 있도록 안내합니다. 이는 데이터 자체가 사일로가 아닌 공통 스키마에 존재하기 때문에 가능합니다. 설계는 가용성, 대기 시간, 오류 및 포화도에 대한 초기 질문에 효과적으로 답한 다음, 그에 적합한 경험을 사용하여 근본 원인을 탐색합니다.
이제 이 환경의 몇 가지 예를 들어 보겠습니다.
Elastic Uptime은 "어느 서비스가 중단되었는가? 언제 서비스가 중단되었는가? 가동 시간 모니터링 에이전트가 중단되었는가?"와 같은 서비스 가용성에 대한 기본적인 질문에 대답합니다. 가용성 SLO에 대한 경보는 사고 대응자를 이 페이지로 이동시킬 수 있습니다. 대응자는 사용할 수 없는 서비스의 증상을 발견한 후 링크를 따라 장애 발생 시 영향을 받는 서비스 및 해당 배포 인프라의 추적, 메트릭 또는 로그를 탐색할 수 있습니다. 대응자가 탐색할 때, 조사의 컨텍스트는 영향을 받은 서비스에서 필터링된 상태로 남아 있습니다. 이것은 대응자가 해당 서비스에 대한 가동 중단 시간의 근본 원인을 파악하는 데 도움이 됩니다.
Elastic APM은 "어느 엔드포인트가 사용자 환경에 가장 부정적인 영향을 미치는가? 어느 스팬이 트랜잭션을 느리게 만들고 있는가? 나는 분산형 서비스의 트랜잭션을 어떻게 추적하는가? 소스 코드의 어디에 오류가 있는가? 나는 프로덕션 환경에 맞는 개발 환경에서 오류를 어떻게 재현할 수 있는가?" 같은 서비스 대기 시간과 오류에 대한 질문에 대답합니다. 대기 시간과 오류 SLO에 대한 경보는 사고 대응자를 이 페이지로 이동시킬 수도 있습니다. APM 환경은 애플리케이션 개발자에게 버그를 찾고 재현하고 수정하는 데 필요한 정보를 제공합니다. 대응자는 영향을 받는 서비스의 배포 인프라에 대한 메트릭을 보기 위해 스택을 더 낮게 탐색하여 대기 시간의 원인을 조사할 수 있습니다.
Elastic Metrics는 "어떤 호스트, 포드 또는 컨테이너의 메모리 소비량이 높거나 낮은가? 저장 공간? 컴퓨팅? 네트워크 트래픽? 클라우드 제공자, 지리적 지역, 가용성 영역 또는 기타 가치별로 그룹화하면 어떻게 되는가?"와 같은 리소스 포화도에 대한 질문에 대답합니다. 포화도 SLO에 대한 경보는 사고 대응자를 이 페이지로 이동시킬 수 있습니다. 대응자는 정체, 핫 스팟 또는 브라운 아웃의 증상을 발견한 후, 영향을 받는 인프라의 과거 측정 기준과 로그를 확장하거나, 해당 인프라에서 실행 중인 서비스의 동작을 조사하기 위해 드릴다운할 수 있습니다.
Elastic Logs는 시스템과 응용프로그램에서 발생하는 이벤트에 대한 진실 출처에 대한 질문에 대답합니다. 품질이나 정확성 SLO에 대한 경보는 사고 대응자를 이 페이지로 이동시킬 수 있습니다. Logs는 실패의 근본 원인을 설명하고 조사의 최종 목적지가 될 수도 있습니다. 또는 궁극적으로 대응자를 근본 원인으로 이끄는 다른 증상의 원인을 설명할 수도 있습니다. 이 기술은 뒤에서 로그를 분류하고 텍스트의 동향을 탐색하여 사고 대응자에게 배포 상태의 변화를 설명할 수 있는 신호를 제공할 수 있습니다.
Elastic의 엔지니어는 수천 명의 고객과 커뮤니티 구성원이 제공해준 의견 덕분에 통합 가시성을 위해 광범위하게 적용할 수 있는 검색 환경을 설계했습니다. 궁극적으로, SRE는 자체 배포의 전문가로서 운영의 고유한 요구에 가장 적합한 다른 경험을 구상할 수 있습니다. 따라서 Elastic의 데이터를 사용하여 사용자 정의 대시보드와 시각화를 직접 작성하고 이를 사용해야 하는 모든 사용자와 공유할 수 있습니다. 간단히 끌어서 놓기만 하면 됩니다.
Canvas는 일상적인 노력을 넘어 KPI를 팀이나 리더십 체인에 걸쳐 표현할 수 있는 창의적인 매체입니다. 이를 기술적 문제를 해결하는 대시보드가 아니라 비즈니스 이야기를 전달하는 인포그래픽으로 생각해 보세요. 행복하고 슬픈 얼굴로 위장한 일련의 SLO보다 오늘날의 사용자 경험을 보여줄 수 있는 더 좋은 방법은 무엇일까요? “프로덕션에서 코드를 테스트할 시간이 12분 남았어요(이러지 마세요.)!”라고 말하는 배너보다 오늘날의 남은 오류 예산을 어떻게 더 잘 설명할 수 있을까요? 여러분이 청중들을 알게 되면, Canvas는 복잡한 상황을 그들이 이해할 수 있는 의미 있는 이야기로 만들어 줄 수 있습니다.
예
Elastic Observability의 몇 가지 실제 사례를 살펴봅시다. 각 시나리오는 다른 SLI를 위한 경보로 시작되며, 각 시나리오에는 서로 다른 팀의 사람들이 참여할 수 있는 고유한 해결 경로가 있습니다. Elastic은 다양한 상황에서 사고 대응팀이 신속한 해결을 향해 나아갈 수 있도록 돕습니다.
가용성: 서비스가 중단된 이유는?
Elastic은 99%의 가용성을 요구하는 응답하지 않는 서비스를 탐색한 후 비상 대기 팀을 호출합니다. 운영 팀 소속의 Ramesh가 지휘를 맡습니다. 그는 가동 시간 기록을 보기 위해 링크를 클릭합니다. 모니터링 에이전트가 정상 상태라는 것을 확인하므로 경보가 오탐일 가능성은 낮습니다. 그는 영향을 받은 서비스에서 탐색하여 해당 호스트의 메트릭을 확인한 다음 호스트와 컨테이너별로 메트릭을 그룹화합니다. 호스트의 어느 컨테이너도 메트릭을 보고하지 않습니다. "스택에서 문제가 더 높아야 합니다." 그는 가용성 영역과 호스트별로 데이터를 다시 그룹화합니다. 다른 호스트는 영향을 받는 영역에서 정상입니다. 그러나 영향을 받는 서비스의 복제본을 실행하며 호스트를 기준으로 필터링할 때, 호스트는 아무 것도 보고하지 않습니다. "호스트들은 왜 이 하나의 서비스에 대해서만 장애가 발생하는가?" 그는 Slack에서 #ops 채널에 대시보드 링크를 공유합니다. 한 엔지니어가 최근에 그 서비스를 실행하는 호스트를 구성하는 플레이북을 업데이트했다고 말합니다. 그녀가 변경 사항을 롤백하고, 그 다음 메트릭스가 보기로 스트리밍됩니다. 문제가 해결되고 다시 정상으로 작동합니다. 이들은 12분 만에 문제를 해결했으며, 여전히 99%의 SLA 이내입니다. 나중에 엔지니어는 호스트 로그를 검토하여 호스트 변경으로 인해 호스트가 다운된 이유를 해결한 후 적절하게 변경하게 됩니다.
대기 시간: 서비스가 느린 이유는?
Elastic은 여러 서비스에서 비정상적인 대기 시간을 탐색한 후 문제 추적 시스템에서 티켓을 생성합니다. 애플리케이션 개발자들은 대기 시간에 가장 큰 기여를 하는 스팬을 찾기 위해 샘플 추적을 검토하는 미팅을 갖습니다. 데이터 검증 서비스와 인터페이스하는 서비스의 대기 시간 패턴을 봅니다. 그 서비스를 선도하는 개발자인 Sandeep은 스팬을 더 깊이 조사합니다. 스팬은 장기간 실행되는 쿼리를 데이터베이스에 보고하고 있으며, 이 쿼리는 느린 로그의 비정상적인 로그 속도에 의해 입증됩니다. 그는 쿼리를 조사하고 로컬 환경에서 이를 재현합니다. 그 진술들은 최근 대량으로 삽입된 자료들이 둔화를 야기할 때까지 눈에 띄지 않은 채 색인화되지 않은 열들에 합류하고 있었습니다다. 그의 표 최적화는 서비스 대기 시간을 개선하지만 필수 SLO 수준까지 개선하지는 않습니다. 그는 문맥 필터를 사용하여 샘플 추적을 서비스의 이전 버전과 비교함으로써 조사를 전환합니다. 쿼리 결과를 처리하는 새로운 스팬이 있습니다. 그는 자신의 로컬 환경에서 스택 추적을 각 쿼리 결과에 대해 일련의 정규식을 평가하는 방법으로 추적합니다. 그는 코드를 조정하여 루프 전의 패턴을 사전 컴파일합니다. 변경 사항을 적용한 후, 서비스의 대기 시간은 SLO로 돌아갑니다. Sandeep은 이 문제를 해결된 것으로 표시합니다.
오류: 서비스 오류가 발생하는 이유는?
Esther는 온라인 소매업체를 위해 계정 등록 서비스를 이끄는 소프트웨어 개발자입니다. 그녀는 팀의 문제 추적 시스템으로부터 알림을 받습니다. 문제는 Elastic이 싱가포르 지역의 생산등록 서비스에서 과도한 에러율을 감지해 신규 사업을 위태롭게 할 수 있다는 것입니다. Esther는 문제 설명에서 링크를 클릭하여 양식 제출 엔드포인트에서 처리되지 않은 "유니코드 디코드 오류"에 대한 오류 그룹으로 이동합니다. 그녀는 샘플을 열고 파일 이름, 오류가 던져진 코드 줄, 스택 추적, 환경에 대한 컨텍스트, 심지어 애플리케이션이 구축되었을 때 소스 코드의 커밋 해시 등 문제의 원인에 대한 세부 정보를 찾아냅니다. 개인정보 보호 규정을 준수하기 위해 수정된 일부 데이터가 있는 등록 양식 입력을 봅니다. 입력에 베트남어 유니코드 문자가 포함되어 있는 것을 알아차립니다. 그녀는 이 모든 정보를 사용해 로컬 컴퓨터에서 문제를 재현합니다. 유니코드 핸들러를 수정한 후, 변경 사항을 커밋합니다. CI/CD 파이프라인은 테스트를 실행하는데, 이 테스트를 통과한 후 업데이트된 애플리케이션을 프로덕션에서 배포합니다. Esther는 이 문제가 해결된 것으로 표시하고 정상적인 업무를 계속합니다.
포화도: 용량이 가득 찰 곳은 어디인가?
Elastic은 클라우드 영역을 인플루언서로 나열하는 메모리 사용의 이상을 탐색한 후 문제 추적 시스템에서 티켓을 생성합니다. 운영자가 링크를 클릭하면 시간 경과에 따른 지역 메모리 사용량을 볼 수 있습니다. 베를린 지역에는 붉은 점으로 표시된 급상승이 나타나고, 그 후에는 시간이 지남에 따라 사용량이 천천히 상승합니다. 그녀는 이것이 지속되면 곧 메모리가 부족해질 것이라고 예측합니다. 그녀는 전 세계 모든 포드의 최근 메모리 메트릭을 봅니다. 베를린의 포드는 분명히 다른 지역보다 포화도가 높은 것이 분명합니다. 서비스 이름별로 포드를 그룹화하고 베를린에 의해 필터링하여 검색 범위를 좁힙니다. 제품 추천 서비스인 한 가지 서비스가 눈에 띕니다. 이 서비스의 복제본을 전 세계적으로 보기 위해 검색을 확장합니다. 베를린은 가장 많은 메모리 사용량과 가장 많은 수의 복제본 포드 숫자를 보여줍니다. 베를린에서 이 서비스의 트랜잭션을 철저히 조사합니다. 그녀는 이 대시보드에 대한 링크를 서비스를 주도하는 애플리케이션 개발자와 공유합니다. 개발자는 트랜잭션의 컨텍스트를 읽습니다. 그는 A/B 테스트를 위해 베를린에 대해서만 롤아웃된 기능 플래그의 사용자 정의 라벨을 봅니다. 그는 시간이 지남에 따라 증가하는 데이터 세트를 빠르게 로드하는 대신 느리게 로드하도록 서비스를 최적화합니다. CI/CD 파이프라인은 그의 업데이트된 서비스를 배포하며, 메모리 사용은 정상으로 돌아가고, 운영자는 이 문제를 해결된 것으로 표시합니다. 이 문제가 비즈니스에 영향을 미쳤다는 징후는 없지만 예상에 따르면 급증세를 감지하지 않았다면 그랬을 것이라고 합니다.
사례 연구
Elastic Observability의 가치를 증명하는 성공담은 부족함이 없습니다. 미국의 통신 대기업이자 다우존스산업평균지수(DJIA)의 구성원인 Verizon Communications가 대표적인 사례입니다. Verizon은 SEC에 대한 2019년 연례 보고서에서 자사의 비즈니스에 대한 최고 경쟁 리스크 중 "네트워크 품질, 용량 및 커버리지"와 "고객 서비스의 품질"을 열거했습니다. 그해 전체 매출 1,309억 달러의 69.3%가 Verizon Wireless 사업을 하는 무선 부문에서 발생했습니다. Verizon Wireless의 인프라 운영 팀은 기존 모니터링 솔루션을 Elastic으로 교체함으로써 "고객을 위한 뛰어난 서비스 제공으로 직접 전환하는 MTTR을 20~30분에서 2~3분으로 단축"했다고 밝혔습니다. 서비스 신뢰성, 사고 대응, 그리고 Elastic Stack은 이 비즈니스와 신뢰할 수 있는 서비스를 제공해야 하는 다른 비즈니스에 있어 경쟁 우위의 위치를 점하기 위한 토대입니다.
이제 그 다음은?
신뢰성을 극대화하고 소프트웨어 서비스에 대한 자신감을 고취하기 위해 취할 수 있는 다음 단계는 다음과 같습니다.