모범 사례 개요

Observability는 범위가 넓고, 도구 생태계도 성숙한 분야입니다. 하지만 모든 도구가 모든 상황에 적합한 것은 아닙니다! Observability 요구사항을 정의하고, 구성하고, 최종 배포하기까지의 과정을 돕기 위해, Observability 전략 수립에 꼭 필요한 다섯 가지 핵심 모범 사례를 정리했습니다.

모니터링, 뭣이 중요헌디?

Observability에서 가장 중요한 것은 서버, 네트워크, 애플리케이션, 고객이 아닙니다. 가장 중요한 것은 여러분의 비즈니스, 프로젝트 그리고 이것들의 사용자 입니다.

먼저 성공 기준이 무엇인지 정의하세요. 예를 들어, 이커머스 애플리케이션을 운영한다면 지난 1시간 동안의 구매 건수가 성공 지표일 수 있습니다. 비영리단체라면 이번 달 목표 대비 기부금일 수 있고, 결제 처리 시스템이라면 트랜잭션 처리 시간, 대학이라면 학생 출석률이 될 수 있습니다.

팁

성공 지표는 모두에게 다릅니다! 여기서는 이커머스 애플리케이션을 예로 들지만, 여러분의 프로젝트는 전혀 다른 측정 기준을 가질 수 있습니다. 어떤 경우든 핵심 원칙은 같습니다: 정상 상태가 어떤 것인지 알고, 그것을 측정하세요.

어떤 애플리케이션이든, 핵심 지표를 먼저 파악해야 합니다. 그 다음 그 지표에 영향을 미치는 애플리케이션이나 인프라 요소를 역추적(Working Backwards)¹ 하세요. 예를 들어, 웹 서버의 높은 CPU가 고객 만족도를 위협하고 결국 매출에 영향을 준다면, CPU 사용률을 모니터링하는 것이 중요합니다!

목표를 정의하고 측정하세요!

중요한 최상위 KPI를 파악했다면, 다음 단계는 이를 자동으로 추적하고 측정하는 방법을 마련하는 것입니다. 여기서 핵심은 워크로드 운영을 감시하는 동일한 시스템에서 이 작업을 수행하는 것입니다. 이커머스 워크로드를 예로 들면:

• 매출 데이터를 시계열(time series)로 저장
• 사용자 등록 현황을 같은 시스템에서 추적
• 고객이 웹 페이지에 머무는 시간을 측정하고, 이 데이터도 시계열로 저장

대부분의 고객은 이미 이런 데이터를 보유하고 있지만, Observability 관점에서 적절한 위치에 있지 않은 경우가 많습니다. 매출 데이터와 사용자 등록 정보는 보통 관계형 데이터베이스나 BI 리포팅 시스템에 있고, 방문 시간 데이터는 로그나 Real User Monitoring에서 추출할 수 있습니다.

지표 데이터의 원래 위치나 형식에 관계없이, 반드시 시계열(time series)로 관리해야 합니다. 비즈니스, 개인, 학술, 또는 어떤 목적이든 가장 중요한 모든 핵심 지표는 시계열 형식이어야 다른 Observability 데이터(시그널 또는 텔레메트리라고도 함)와 상관 분석을 할 수 있습니다.

그림 1: 시계열 예시

컨텍스트 전파와 도구 선택

도구 선택은 운영 방식과 문제 해결 속도에 큰 차이를 만듭니다. 하지만 최적이 아닌 도구를 선택하는 것보다 더 나쁜 것은, 기본적인 시그널 유형 중 일부를 수집하지 않는 것입니다. 예를 들어, 워크로드에서 기본 로그만 수집하고 트랜잭션 트레이스를 놓치면 공백이 생깁니다. 그 결과 애플리케이션 전체에 대한 통합된 시각을 가질 수 없게 됩니다. 현대적인 Observability 접근 방식은 모두 애플리케이션 트레이스를 통해 "점과 점을 연결하는 것"에 기반합니다.

워크로드의 건강 상태와 운영을 완전하게 파악하려면 로그, 메트릭, 트레이스를 수집하고, 상관 분석, 이상 탐지, 대시보드, 알람 등을 수행하는 도구가 필요합니다.

정보

일부 Observability 솔루션은 위의 모든 기능을 포함하지 않을 수 있으며, 기존 시스템을 보완, 확장하거나 부가 가치를 제공하는 것이 목적일 수 있습니다. 어떤 경우든, Observability 프로젝트를 시작할 때 도구 간 상호 운용성과 확장성은 중요한 고려 사항입니다.

워크로드마다 다르지만, 공통 도구를 사용하면 더 빠른 결과를 얻을 수 있습니다

모든 워크로드에 공통 도구 세트를 사용하면 운영 마찰과 교육 비용을 줄일 수 있으며, 일반적으로 도구나 벤더 수를 줄이는 것이 바람직합니다. 이렇게 하면 기존 Observability 솔루션을 새로운 환경이나 워크로드에 빠르게 배포할 수 있고, 문제 발생 시 해결 시간도 단축됩니다.

도구는 인프라, 애플리케이션, 웹사이트 등 워크로드의 모든 계층을 관찰할 수 있을 만큼 폭넓어야 합니다. 단일 도구로 불가능한 영역에서는, 개방형 표준을 따르고, 오픈 소스이며, 따라서 크로스 플랫폼 통합 가능성이 가장 넓은 도구를 사용하는 것이 모범 사례입니다.

기존 도구 및 프로세스와 통합하세요

이미 좋은 도구가 있는데 굳이 새로 만들 필요 없습니다. 중요한 건 데이터를 가두지 않고, 조직 전체가 함께 볼 수 있는 열린 Observability 체계를 만드는 것입니다.

• 기존 ID 공급자와 통합 (예: Active Directory, SAML 기반 IdP)
• 기존 IT 이슈 추적 시스템이 있다면 (예: JIRA, ServiceNow) 연동하여 문제 발생 시 빠르게 관리
• 기존 워크로드 관리 및 에스컬레이션 도구 (예: PagerDuty, OpsGenie)가 있다면 활용
• Ansible, SaltStack, CloudFormation, Terraform, CDK 같은 IaC(Infrastructure as Code) 도구로 Observability도 관리하세요. 이미 사용 중인 IaC 도구로 Observability 솔루션을 구축하세요 (초기부터 Observability 포함하기 참고).

자동화와 머신러닝을 활용하세요

컴퓨터는 패턴을 찾고, 데이터가 패턴을 따르지 않을 때를 감지하는 데 뛰어납니다! 수백, 수천, 수백만 개의 데이터 포인트를 모니터링해야 한다면, 모든 항목에 대해 정상 임계값을 일일이 파악하는 것은 불가능합니다. 하지만 많은 Observability 솔루션은 데이터 베이스라인 설정이라는 차별화되지 않는 무거운 작업을 대신 처리해주는 이상 탐지와 머신러닝 기능을 제공합니다.

이를 "정상이 어떤 모습인지 아는 것"이라고 부릅니다. 워크로드를 충분히 부하 테스트했다면 정상적인 성능 지표를 이미 알 수 있지만, 복잡한 분산 애플리케이션에서는 모든 메트릭에 대해 베이스라인을 수동으로 설정하기가 어렵습니다. 바로 여기서 이상 탐지, 자동화, 머신러닝이 큰 가치를 발휘합니다.

여러분을 대신해 애플리케이션 상태의 베이스라인 설정과 알림을 관리해주는 도구를 활용하세요. 그래야 여러분은 목표에 집중하고, 뭣이 중요헌디?를 실천할 수 있습니다.

워크로드의 모든 계층에서 발생하는 측정가능한 데이터를 빠짐없이 원격으로 수집하세요.

여러분의 애플리케이션은 고립되어 존재하지 않습니다. 네트워크 인프라, 클라우드 공급자, 인터넷 서비스 공급자, SaaS 파트너, 그리고 여러분이 통제할 수 있는 것과 없는 것 모두를 포함한 다른 구성 요소와의 상호작용이 결과에 영향을 줄 수 있습니다. 전체 워크로드에 대한 통합된 시각을 갖는 것이 중요합니다.

통합(Integration)에 집중하세요

하나의 영역만 계측해야 한다면, 그것은 분명히 구성 요소 간의 통합 지점입니다. 이곳에서 Observability의 힘이 가장 분명하게 드러납니다. 원칙적으로, 한 구성 요소나 서비스가 다른 것을 호출할 때마다 최소한 다음 데이터 포인트를 측정해야 합니다:

1. 요청과 응답의 소요 시간
2. 응답의 상태

그리고 Observability가 요구하는 통합된 전체 그림을 만들려면, 전체 요청 체인에 대한 고유한 단일 식별자가 수집되는 시그널에 포함되어야 합니다.

최종 사용자 경험을 잊지 마세요

워크로드의 완전한 시각이란 최종 사용자가 어떻게 경험하는지를 포함하여 모든 계층에서 이해하는 것을 의미합니다. 사용자 경험 저하로 인해 목표가 위험에 처하는 시점을 측정하고 정량화하는 것은, 디스크 여유 공간이나 CPU 사용률을 감시하는 것만큼 — 아니, 어쩌면 더 — 중요합니다!

최종 사용자와 직접 상호작용하는 워크로드(웹사이트나 모바일 앱으로 제공되는 애플리케이션 등)라면, Real User Monitoring이 사용자에게 전달되는 "마지막 구간"뿐만 아니라 사용자가 실제로 애플리케이션을 어떻게 경험했는지를 모니터링합니다. 궁극적으로, 사용자가 실제로 서비스를 이용할 수 없다면 Observability의 모든 여정은 의미가 없습니다.

데이터는 힘이지만, 사소한 것에 매달리지 마세요

애플리케이션의 규모에 따라 시그널을 수집해야 하는 구성 요소가 매우 많을 수 있습니다. 이 작업은 중요하고 강력하지만, 노력 대비 수확이 줄어드는 지점이 있을 수 있습니다. 그래서 뭣이 중요헌디?부터 시작하고, 이를 기반으로 중요한 통합 지점과 핵심 구성 요소를 매핑한 뒤, 올바른 세부 사항에 집중하는 것이 모범 사례입니다.

초기부터 Observability를 포함하세요

보안과 마찬가지로, Observability는 개발이나 운영에서 나중에 생각할 것이 아닙니다. 보안처럼 계획 초기 단계에 Observability를 배치하는 것이 모범 사례이며, 이를 통해 팀이 활용할 수 있는 모델을 만들고 애플리케이션의 불투명한 영역을 줄일 수 있습니다. 주요 개발 작업이 완료된 후에 트랜잭션 트레이싱을 추가하는 것은, 자동 계측을 사용하더라도 시간이 걸립니다. 물론 그 노력은 훨씬 큰 성과로 돌아옵니다! 하지만 개발 주기 후반에 하면 일부 재작업이 발생할 수 있습니다.

워크로드에 나중에 Observability를 덧붙이는 대신, Observability를 활용하여 작업을 가속화하세요. 적절한 로깅, 메트릭, 트레이스 수집은 애플리케이션 개발을 더 빠르게 하고, 좋은 관행을 촉진하며, 향후 빠른 문제 해결의 기반을 마련합니다.

Footnotes

1. Amazon은 고객과 그 성과에 집착하는 방법으로 Working Backwards 프로세스를 광범위하게 사용하며, Observability 솔루션을 구축하는 모든 분들이 동일한 방식으로 자신의 목표에서 역추적하기를 강력히 권장합니다. Working Backwards에 대한 자세한 내용은 Werner Vogels의 블로그에서 확인할 수 있습니다. ↩