관측 가능성의 세 가지 핵심 요소: 로그, 지표, 추적

많은 거버넌스 구조와 기관은 성공을 보장하기 위해 세 가지 핵심 요소에 의존합니다.기업의 책임 관행은 환경적, 사회적, 재무적 지속가능성에 중점을 두어 비즈니스 관행을 이끌어갑니다. 

디지털 혁신을 모색하는 기업은 전환 과정을 안내하기 위해 사람, 프로세스, 기술이라는 세 가지 요소를 사용하는 경우가 많습니다. 이 프레임워크는 의사 결정자가 창의적이고 협업적인 기술 전문가(사람)를 유지하고, 체계적이고 정교한 데이터 관리 및 보안 관행(프로세스)을 활용하며, 진보를 추진하는 고급 툴과 플랫폼(기술)에 의존하도록 독려합니다. 

그리고 애자일 프로젝트 관리를 가능하게 하는 일련의 프레임워크와 원칙인 스크럼을 뒷받침하는 세 가지 요소는 투명성, 검사 및 적응입니다. 이러한 모든 사례에서 각 요소는 서로 다르고 필수적이지만, 단독으로는 완전하지 않습니다.각각은 고유한 역할과 우선순위를 가지고 있지만, 진정한 힘은 이들이 어떻게 협력하고 상호작용하여 더 큰 목표를 뒷받침하느냐에 있습니다. 관측 가능성도 다르지 않습니다.

IT 환경에서 관측 가능성은 지표, 로그, 트레이스라는 세 가지 텔레메트리 데이터 축을 활용하여 방대한 컴퓨팅 네트워크를 더 쉽게 시각화하고 이해할 수 있도록 합니다. 이는 개발자가 시스템의 외부 출력을 기반으로 내부 상태를 이해할 수 있게 해줍니다. 네트워크가 관측 가능하면, IT 담당자는 추가적인 테스트나 코딩 없이도 생성된 데이터를 통해 성능 문제의 근본 원인을 식별할 수 있습니다.

관측 가능성 솔루션은 시스템의 원시 출력 데이터를 분석에 활용하여, 팀에 효과적인 문제 해결과 디버깅을 위한 엔드투엔드 네트워크 가시성과 실행 가능한 인사이트를 제공합니다.

관측 가능한 아키텍처는 엔지니어링 팀과 네트워크 관리자들이 현대 컴퓨팅 네트워크의 복잡성을 관리할 수 있도록 돕습니다. 그리고 오늘날 이는 하이브리드 클라우드 및 멀티 클라우드 구성, 다양한 클라우드 네이티브 애플리케이션, 마이크로서비스, Kubernetes 컨테이너를 포함하는 방대하고 매우 동적인 컴퓨팅 네트워크를 유지하는 것을 의미합니다.

관측 가능성 툴(예: 오픈 소스 솔루션인 OpenTelemetry)은 기업에 상황에 대한 포괄적이고 상황에 맞는 뷰를 제공합니다. 풀 스택 가시성을 통해 팀은 최종 사용자에게 영향을 미치기 전에 비정상적인 데이터 패턴과 성능 병목 현상을 식별할 수 있습니다. 따라서 관측 가능성은 기업이 네트워크 가동 중단을 최소화하고 다양한 사용 사례에서 서비스 안정성을 유지하는 데 도움이 될 수 있습니다.

하지만 네트워크 복잡성에 관계없이 관측 가능성은 시스템 '이벤트'와 세 가지 기본 핵심 요소에 따라 달라집니다. 이 핵심 요소를 통해 관측 가능성 플랫폼은 분산 시스템에서 작동하는 프론트엔드 애플리케이션, 백엔드 서비스, CI/CD 파이프라인, 스트리밍 데이터 파이프라인에서 데이터를 수집하고 분석할 수 있습니다.

관측 가능성을 사용하려면 네트워크의 모든 구성 요소에서 세심한 데이터 수집을 통해 시스템 이벤트의 '무엇', '어디서', '왜'를 파악하고 이벤트가 전체 아키텍처의 성능에 어떤 영향을 미칠 수 있는지 명확히 해야 합니다. 따라서 이벤트는 모니터링 및 원격 측정의 기반이 됩니다.

이벤트는 네트워크에서 특정 시간에 발생하는 고유한 발생으로 일반적으로 로그, 지표 및 추적에 대한 귀중한 데이터를 생성하므로 세 가지 핵심 요소와 마찬가지로 관측 가능성에 필수적인 요소입니다. 이벤트는 더 넓은 맥락에서 존재합니다.

예를 들어, 클라이언트가 엔터프라이즈 서버에 리소스를 요청하는 경우 클라이언트는 엔드포인트의 URL을 사용하여 해당 요청을 적절한 API 엔드포인트로 전달합니다. 서버는 요청을 수신하여 인증 자격 증명(예: API 키) 및 클라이언트 권한을 확인하고, 유효한 것으로 가정하고 API 사양에 따라 요청을 처리합니다(예: 응답 형식이 올바른지 확인). 그런 다음, 서버는 요청된 데이터와 함께 클라이언트에 응답을 다시 보냅니다.

이벤트는 정확한 순간에 고유한 작업을 트리거합니다. 따라서 관측 가능성 툴은 DevOps 팀이 IT 환경을 시각화하고 네트워크를 최적화하는 데 도움이 되는 추적, 분석 및 상관관계 프로세스를 시작하기 위해 이를 활용합니다.

지표는 다양한 네트워크 매개변수를 측정하여 시스템 성능에 대한 정량적 인사이트를 제공합니다. 이는 팀이 시스템 문제의 '대상'을 이해하는 데 도움이 됩니다. 지표 유형은 다음과 같습니다.

• 호스트 지표: 메모리,디스크 및 CPU 사용량
• 네트워크 성능 지표: 가동 시간, 지연 시간, 처리량
• 앱 지표: 응답 시간, 요청 및 오류율
• 서버 풀 지표: 총 인스턴스, 실행 중인 인스턴스 수
• 외부 종속성 지표: 가용성, 서비스 상태

메모리 사용량 및 지연 시간과 같은 일반적인 지표는 시스템 상황과 직관적으로 일치합니다. 그러나 다른 많은 지표와 핵심 성과 지표(KPI)를 통해 시스템 문제를 파악할 수 있습니다. 예를 들어, 운영 체제(OS) 핸들 고갈은 시스템 속도를 저하시킬 수 있으며 기능을 복원하기 위해 재부팅해야 하는 경우가 많습니다.

지표는 대시보드 및 기타 시각화(시계열 그래프 등)를 사용하여 개발자가 시스템의 상황을 신속하게 평가하고 데이터 추세를 분석하며 네트워크 문제에 대응하는 데 도움이 되는 요약 보기를 제공하기 위해 집계되는 경우가 많습니다. 또한 확장 및 리소스 할당에 대한 결정에 정보를 제공하므로 효과적인 용량 계획 및 부하 관리에 필수적인 지표가 됩니다.

팀이 추적할 지표를 신중하게 선택하고 지속적으로 분석하는 것이 중요하며, 일부 지표는 잠재적인 문제가 발생하기 전에 예측하는 데 도움이 될 수 있습니다.

팀은 위반 시 경고를 트리거하여 IT 직원에게 현재 또는 임박한 문제를 알리는 지표 임계값을 설정할 수 있습니다. 또한 지표는 관측 가능성 툴이 시간이 지남에 따라 누적되는 문제(예: OS 핸들 누수)가 고객 경험을 방해하기 훨씬 전에 탐지할 수 있도록 합니다.

그러나 지표는 종종 제한된 컨텍스트를 제공하므로, 일반적으로 개발자가 시스템 이벤트에 대한 포괄적인 이해를 제공하기 위해 로그 및 추적과의 상관관계가 필요합니다. 또한 고해상도 지표는 효율적으로 저장하고 관리하기 어려울 수 있는 엄청난 양의 데이터를 생성합니다. 따라서 관측 가능성을 위해서는 지표 데이터를 처리하고 분석에 계속 사용할 수 있도록 보장하는 고품질의 장기 스토리지 솔루션이 필요한 경우가 많습니다.

로그는 시스템 내에서 발생하는 개별 이벤트에 대한 변경할 수 없는 완전한 기록입니다. 팀이 시스템 문제의 '이유'를 이해하는 데 도움이 됩니다.

로그 파일은 다음을 포함하여 시스템 동작 및 애플리케이션 프로세스에 대한 자세한 정보를 저장합니다.

• 이벤트 타임스탬프
• 트랜잭션 ID
• IP 주소 및 사용자 ID
• 이벤트 및 프로세스 세부 정보
• 오류 메시지
• 연결 시도
• 구성 변경

이벤트 로그는 바이너리, 비정형(일반 텍스트) 또는 정형(JSON 형식)일 수 있습니다. 모든 로그 파일은 적절한 컨텍스트에서 유용하지만, 구조적 로깅은 생성된 텍스트와 메타데이터를 구조화하므로 분석 및 분석이 더 간편합니다.

관측 가능성 툴의 로깅 기능은 운영 체제, 네트워크 디바이스, 내부 및 서드파티 애플리케이션, 사물인터넷(IoT) 디바이스의 로그 파일을 집계하여 개발 팀이 오류를 진단하고 시스템 장애를 이해하는 데 도움을 줍니다. 오류, 보안 위반 또는 규정 준수 문제가 발생하면 로그는 근본 원인을 추적하고 무엇이 잘못되었는지 이해하는 데 필요한 세부 정보를 제공합니다.

로그는 시스템 이벤트 및 문제에 대한 귀중한 인사이트를 제공하지만, 그것만으로는 전체 상황을 파악할 수 없습니다. 지표의 경우와 마찬가지로 관측 가능성 툴은 로그 데이터를 분석하고 지표 및 추적과 상호 연관시켜 그 가치를 극대화해야 합니다. 또한 지표와 마찬가지로, 로그는 데이터 볼륨을 크게 증가시키므로 기업은 데이터 로드를 처리하기 위해 정교한 로그 관리 툴에 투자해야 하는 경우가 많습니다.

또한 포괄적인 이벤트 로깅은 관련성이 낮은 데이터 아래에 중요한 정보를 묻어 IT 담당자의 문제 식별을 복잡하게 만드는 '노이즈'를 생성할 수 있습니다. 이러하 이유로 현대의 관측 가능성 솔루션은 AI및 머신 러닝 (ML) 기반 자동화를 통한 워크플로를 사용하여 경고 관행을 개선하고 중요한 경고와 노이즈를 구분합니다.

지표와 로그의 일부 기능을 결합하는 추적은 네트워크 구성 요소 전반에 걸쳐 데이터를 매핑하여 요청의 워크플로를 표시합니다. 이는 네트워크를 통한 요청의 엔드투엔드 여정을 나타내며 요청 처리와 관련된 각 구성 요소의 경로와 수명을 캡처합니다. 요컨대, 추적은 사이트 신뢰성 엔지니어(SRE) 팀과 소프트웨어 엔지니어링 팀이 시스템 이벤트 및 문제의 '위치'와 '방법'을 이해하는 데 도움이 됩니다.

추적 데이터에는 다음이 포함될 수 있습니다.

• 네트워크 이벤트 및 운영 기간
• 아키텍처를 통한 데이터 패킷의 흐름
• 요청이 네트워크 서비스를 통과하는 순서
• 시스템 오류의 근본 원인

추적, 즉 분산 추적은 요청이 목적지에 도달하기 전에 지리적으로 분산된 여러 서비스를 통과할 수 있는 마이크로서비스 아키텍처에 유용합니다. 다양한 구성 요소와 서비스 간의 종속성 및 상호 작용에 대한 인사이트를 제공하고 IT 팀이 사용자가 특정 작업을 완료하는 데 걸리는 시간을 이해하는 데 도움이 될 수 있습니다.

관측 가능성 툴의 추적 기능은 지연 시간 분석에 필수적이며, 이는 엔지니어가 사용자에게 성능 병목 현상을 일으킬 수 있는 구성 요소와 성능이 저하된 서비스를 식별하는 데 도움이 됩니다.

또한 요청-응답 흐름과 네트워크 요소 간의 인과 관계를 설명하여 디버깅 프로세스를 용이하게 합니다. 또한 근본 원인 분석 동안 팀은 추적을 통해 복잡한 워크플로에서 네트워크 문제의 원인을 정확히 파악하여 더 빠르고 정확하게 문제를 해결할 수 있습니다.

지표 및 로그와 달리, 추적은 인사이트를 강화하는 데 도움이 되는 컨텍스트 정보를 제공할 수 있습니다. 그러나 추적만으로는 데이터 추세나 패턴을 파악할 수 없습니다. 또한 분산 추적을 설정하려면 서비스 배포 전반에 걸쳐 계측이 필요하므로 프로세스가 특히 복잡하고 시간이 많이 소요될 수 있습니다. 또한 적절하게 관리하지 않으면 추적, 그리고 추적에 필요한 컴퓨팅 성능으로 인해 환경에 더 많은 지연 시간이 발생할 수 있습니다.

세 가지 핵심 요소를 모두 결합하면 개발 및 운영 팀이 복잡한 시스템 동작을 전체적으로 파악하고 세부적으로 이해할 수 있습니다. 지표는 팀에 문제를 경고하는 데 사용되는 반면, 추적은 실행 경로를 표시하고 로그는 문제를 해결하는 데 필요한 컨텍스트를 제공합니다.

함께 사용하면 문제 식별 및 해결을 가속화하여 팀에 문제 해결, 네트워크 성능 최적화를 지원하는 보완 툴을 제공하고 풀 스택 관측 가능성을 가능하게 합니다.

지표, 로그 및 추적은 관측 가능성의 기본 요소로 널리 알려져 있지만, 그렇다고 해서 다른 기본 구성 요소의 존재가 배제되는 것은 아닙니다. 어떤 이들은 컨텍스트, 상관관계, 경고도 관측 가능성의 핵심 요소라고 주장합니다.

결국, 컨텍스트는 네트워크 환경(예:토폴로지, 디바이스 역할 및 애플리케이션 종속성)에 대한 추가 정보를 제공하여 지표, 로그 및 추적을 강화합니다. 컨텍스트가 없으면 관측 가능성 데이터는 실행 가능 의미가 없을 것입니다.

상관관계는 지표, 로그, 추적 및 컨텍스트 정보를 함께 연결하여 네트워크 스택의 여러 계층에서 이벤트에 대한 응집력 있는 뷰를 제공합니다. 경고가 없다면 문제가 발생할 때 관측 가능성 툴이 프롬프트 알림을 보낼 수 없을 것입니다.

그러나 프로파일링은 관측 가능성의 또 다른 주요 기능으로 떠오르고 있습니다.

프로파일링(연속 프로파일링이라고도 함)은 애플리케이션을 실행하고 특정 순간의 코드 실행 상태에 대한 자세한 데이터를 지속적으로 수집하는 프로세스입니다. 예를 들어, 프로파일은 Java 스레드가 RUNNING 또는 WAIT 상태인지 여부를 나타낼 수 있습니다. 또는 앱에 메모리 누수 문제가 있는 경우 프로필을 통해 코드의 어느 부분이 리소스를 과도하게 소비하는지 명확히 할 수 있습니다.

따라서 프로파일은 단일 시스템 구성 요소의 내부 작동에 대한 엑스레이 역할을 합니다.

프로파일링은 개별 함수 또는 코드 블록에 영향을 주는 문제와 같은 낮은 수준의 문제를 정확히 찾아내는 데 유용합니다. 이를 통해 IT 팀은 점유 중인 코드 경로를 식별하고, 사용되지 않는 경로를 찾아 더 이상 사용하지 않으며, 향후 이벤트 및 상호 작용에 대한 중요한 경로의 우선순위를 지정할 수 있습니다.

프로필이 세 가지 핵심 요소 중 하나는 아니지만, 기능은 크게 발전했습니다. Linux 커널을 위한 eBPF(Extended Berkeley Packet Filter)와 같은 프로젝트는 프로파일러 개발을 간소화하여 개발 팀의 프로파일링 프로세스를 간소화했습니다.

개발 팀은 추적, 샘플링 및 계측 프로파일을 사용하여 애플리케이션 코드를 보다 심층적이고 세부적으로 볼 수 있습니다. 또한 프로파일링을 관측 가능성의 다른 요소와 함께 사용하면 애플리케이션 성능에 대한 실시간 인사이트를 제공하고, 소프트웨어 개발 라이프사이클을 가속화하며, 기업이 DevOps 전략을 최적화하는 데 도움을 줄 수 있습니다.