하이브리드 및 멀티클라우드 모범 사례
소개
멀티클라우드란 둘 이상의 클라우드 서비스 제공자를 동시에 사용하여 워크로드를 운영하는 것을 의미하며, 하이브리드란 온프레미스와 클라우드 환경 모두에 걸쳐 워크로드를 확장하는 것을 말합니다. 하이브리드 및 멀티클라우드 환경에서의 Observability는 도구의 다양성, 지연 시간, 이질적인 워크로드로 인해 상당한 복잡성을 추가할 수 있습니다. 그럼에도 불구하고, 이는 개발자와 비즈니스 사용자 모두에게 공통적인 목표로 남아 있습니다. 이를 해결하기 위한 풍부한 제품 및 서비스 생태계가 존재합니다.
다만, 클라우드 네이티브 워크로드를 위한 Observability 도구의 유용성은 크게 달라질 수 있습니다. 컨테이너화된 배치 처리 워크로드를 모니터링하는 요구사항과 서버리스 프레임워크를 사용하는 실시간 뱅킹 애플리케이션의 요구사항이 어떻게 다른지 생각해 보세요. 둘 다 logs, metrics, traces를 가지고 있지만, 이를 관측하기 위한 도구 체인은 클라우드 네이티브, 오픈소스, ISV 제품 등 다양한 선택지가 있어 워크로드마다 달라집니다. Prometheus 같은 오픈소스 도구가 한쪽에 적합할 수 있지만, 관리형 서비스로 제공되는 클라우드 네이티브 도구가 다른 쪽의 요구사항을 더 잘 충족할 수도 있습니다.
여기에 멀티클라우드와 하이브리드의 복잡성이 더해지면, 애플리케이션에서 인사이트를 얻는 것은 상당히 더 어려 워집니다.
이러한 추가적인 차원에 대응하고 Observability에 대한 접근 방식을 용이하게 하기 위해, 고객들은 통합된 인터페이스를 가진 단일 도구 체인에 투자하는 경향이 있습니다. 결국 신호 대 잡음비를 줄이는 것은 일반적으로 좋은 일이니까요! 하지만 단일 접근 방식이 모든 사용 사례에 적합한 것은 아니며, 다양한 플랫폼의 운영 모델이 혼란을 가중시킬 수 있습니다. 우리의 목표는 여러분의 요구를 보완하고, 문제 발생 시 평균 해결 시간을 줄일 수 있는 정보에 기반한 결정을 내리도록 돕는 것입니다. 다음은 모든 규모와 산업의 고객들과 함께 일하면서 배운 모범 사례입니다.
이 모범 사례는 엔터프라이즈 아키텍트, 개발자, DevOps 등 폭넓은 역할을 대상으로 합니다. 조직의 비즈니스 요구사항과 분산 환경에서의 Observability가 어떻게 최대한의 가치를 제공할 수 있는지의 관점에서 평가하시기를 권장합니다.
도구에 맞춰 결정하지 말고, 목적에 맞는 도구를 선택 하세요
애플리케이션, 도구, 프로세스는 매출 증대와 고객 만족도 향상 같은 비즈니스 성과를 달성하기 위해 존재합니다. 현명한 기술 전략은 이러한 비즈니스 목표 달성을 위해 최선을 다하는 전략입니다. 하지만 목표 달성을 돕는 것들은 단순히 도구일 뿐이며, 여러분의 전략을 지원하기 위한 것이지 전략 그 자체가 되어서는 안 됩니다. 비유하자면, 집을 지어야 한다면 도구에게 설계와 건축 방법을 물어보지 않을 것입니다. 도구는 목적을 달성하기 위한 수단입니다.
단일하고 동질적인 환경에서는 도구에 대한 결정이 더 쉽습니다. 단일 환경에서 하나의 애플리케이션을 운영한다면, 전체적으로 동일한 도구를 쉽게 사용할 수 있습니다. 하지만 하이브리드 및 멀티클라우드 환경에서는 상황이 덜 명확하며, 비즈니스 성과와 이러한 환경에서 워크로드를 관측함으로써 얻는 가치에 주목하는 것이 중요합니다. 각 클라우드 서비스 제공자(CSP)는 자체 네이티브 Observability 솔루션을 보유하고 있으며, 활용할 수 있는 풍부한 파트너 및 독립 소프트웨어 벤더(ISV)도 있습니다.
여러 환경에서 운영한다고 해서 모든 워크로드에 단일 도구를 사용하는 것이 바람직하거나 권장되는 것은 아닙니다. 이는 워크로드를 관측하기 위해 여러 서비스, 프레임워크 또는 제공자를 사용해야 할 수도 있다는 것을 의미합니다. 운영 모델이 요구사항을 어떻게 반영해야 하는지에 대한 자세한 내용은 아래의 "단일 뷰보다 워크로드의 컨텍스트가 더 중요합니다"를 참조하세요. 어떤 도구를 구현하든, 향후 Observability 솔루션을 발전시킬 수 있도록 "양방향 도어"를 만드는 것을 잊지 마세요.
다음은 피해야 할 "도구 우선" 결과의 예시입니다:
- 향후 업그레이드하거나 새로운 솔루션으로 이동할 수 있는 양방향 도어 없이 단일 도구 구현에 집중하면, 피할 수 있었던 기술 부채가 생길 수 있습니다. 도구가 솔루션이 되었다가 언젠가 해결해야 할 문제가 될 수 있습니다.
- 볼륨 할인 때문에 단일 도구를 사용하는 회사 표준이 유용한 기능을 놓치게 할 수 있습니다. 이는 "품질보다 비용"이 될 수 있으며, 의도치 않게 모놀리식 안티패턴을 만들 수 있습니다. 볼륨 임계값 이하를 유지하기 위해 텔레메트리 수집을 억제하게 되어, Observability 도구 사용의 동기를 떨어뜨릴 수 있습니다.
- 풍부한 log 및 metric 수집기가 있지만 기존 트레이스 수집 인프라가 부족하여 전체 텔레메트리 유형(보통 traces)을 수집하지 않으면, 불완전한 Observability 솔루션이 될 수 있습니다.
- 인건비와 교육 비용을 줄이려는 목적으로 지원 직원이 단일 도구 체인에 대해서만 교육을 받으면, 다른 Observability 패턴의 잠재적 가치가 감소합니다.
도구가 Observability 전략을 좌우하고 있다면, 접근 방식을 뒤집어야 합니다. 도구는 Observability를 가능하게 하고 강화하기 위한 것이지, 선택을 제한하기 위한 것이 아닙니다.
도구 남용은 기업이 겪는 매우 현실적인 문제이지만, 단일 도구 체인으로의 급격한 전환 역시 Observability 솔루션의 유용성을 감소시킬 수 있습니다. 하이브리드 및 멀티클라우드 워크로드는 각 플랫폼 고유의 기술을 가지고 있으며, 각 CSP의 고수준 서비스는 유용합니다. 하지만 단일 소스 제품을 사용할 때의 트레이드오프는 가치 기반 분석이 필요합니다. 이러한 위험을 완화하는 접근 방식은 "OpenTelemetry에 투자하세요"를 참조하세요.
(Observability) 데이터에는 중력이 있습니다
모든 데이터에는 중력이 있습니다. 즉, 데이터는 워크로드, 솔루션, 도구, 사람, 프로세스, 프로젝트를 자신에게 끌어당깁니다. 예를 들어, 고객 거래가 담긴 데이터베이스는 컴퓨팅 및 분석 워크로드를 끌어당기는 인력의 역할을 합니다. 이는 워크로드를 어디에 배치하고, 어떤 환경에서 운영하며, 향후 어떻게 운영할지에 직접적인 영향을 미칩니다. Observability 신호에도 동일한 원리가 적용되지만, 이 데이터가 만드는 중력은 워크로드와 조직의 컨텍스트에 연결됩니다("단일 뷰보다 워크로드의 컨텍스트가 더 중요합니다" 참조).
Observability 텔레메트리의 컨텍스트를 관련된 기본 워크로드와 데이터에서 완전히 분리할 수는 없습니다. 동일한 규칙이 여기에도 적용됩니다: 텔레메트리는 데이터이며, 중력을 가지고 있습니다. 이는 텔레메트리 에이전트, 컬렉터 또는 신호를 집계하고 분석하는 시스템을 어디에 배치할지에 영향을 미쳐야 합니다.
Observability 데이터의 시간에 따른 가치는 대부분의 다른 데이터 유형보다 상당히 작습니다. 이를 Observability 데이터의 "반감기"라고 할 수 있습니다. 텔레메트리를 다른 환경으로 전달할 때 발생하는 추가 지연 시간을 이 데이터가 사용되기 전에 강제로 가치가 하락하는 것으로 간주하고, 문제 발생 시 알림에 대한 요구사항과 비교하여 평가하세요.
모범 사례는 이러한 집계로부터 비즈니스 가치를 얻을 수 있을 때만 환경 간에 데이터를 전송하는 것입니다. 데이터를 조회하기 위한 단일 소스를 갖는 것만으로는 많은 비즈니스 요구를 해결하지 못하며, 원하는 것보다 더 비싼 솔루션과 더 많은 장애 포인트를 만들 수 있습니다.
단일 뷰보다 워크로드의 컨텍스트가 더 중요합니다
흔히 요구되는 것은 모든 워크로드를 관측하기 위한 "단일 뷰(single pane of glass)"입니다. 이는 가능한 한 많은 데이터를 최대한 간단하게 보고, 혼란과 진단 시간을 줄이려는 자연스러운 욕구에서 비롯됩니다. 전체 Observability 솔루션을 한 번에 볼 수 있는 단일 인터페이스를 만드는 것은 유용하지만, 텔레메트리를 원래의 컨텍스트에서 분리하는 트레이드오프가 있을 수 있습니다.
예를 들어, 100대 서버의 CPU 사용률이 표시된 대시보드가 소비의 이상 급증을 보여줄 수 있지만, 이것만으로는 왜 이런 일이 발생했는지, 기여 요인이 무엇인지 설명하지 못합니다. 그리고 이 지표의 중요성이 즉시 명확하지 않을 수 있습니다.
단일 뷰를 너무 적극적으로 추구하여 모든 비즈니스 컨텍스트가 상실되고, 모든 것을 하나의 도구에서 보려다 보면 오히려 데이터의 가치가 희석될 수 있는 경우를 목격한 바 있습니다. 대시보드와 도구는 하나의 이야기를 전달해야 합니다. 그리고 이 이야기에는 워크로드의 이벤트에 의해 영향을 받는 비즈니스 지표와 성과가 포함되어야 합니다.
또한 도구는 운영 모델에 맞춰져야 합니다. 지원 팀이 모든 환경에 접근할 수 있는 글로벌 팀이라면 단일 뷰가 가치를 더할 수 있지만, 단일 CSP 또는 하이브리드 환경의 단일 워크로드에만 접근이 제한된 경우에는 이 접근 방식을 통해 얻는 가치가 없습니다. 이런 경우에는 각 환경 내에서 네이티브하게 대시보드를 만들도록 허용하는 것이 가치 실현 시간을 앞당기고, 향후 변경에 더 유연할 수 있습니다.
Observability 데이터의 가치는 그것이 발생한 애플리케이션과 깊이 통합되어 있습니다. 텔레메트리는 환경에서 오는 컨텍스트 인식을 필요로 합니다. 하이브리드 및 멀티클라우드 환경에서는 기술 간의 차이로 인해 컨텍스트의 필요성이 더욱 커집니다(다만 Kubernetes 같은 시스템은 다른 클라우드 제공자와 온프레미스 간에 유사할 수 있습니다).
분산 시스템을 위한 단일 뷰를 구축할 때는, 비즈니스 지표와 서비스 수준 목표(SLO)를 이러한 SLO에 기여하는 다른 데이터(인프라 지표 등)와 같은 뷰에 표시하세요. 이렇게 하면 그렇지 않으면 부족할 수 있는 컨텍스트를 제공합니다.
단일 뷰는 문제를 신속하게 진단하고 탐지 시간(MTTD)과 평균 해결 시간(MTTR)을 줄이는 데 도움이 될 수 있지만, 텔레메트리 데이터의 의미가 보존될 수 있을 때만 그렇습니다. 이것이 없다면 단일 뷰 접근 방식은 가치 실현 시간을 증가시키거나, 운영 팀에게 순 마이너스가 될 수 있습니다.
단일 뷰의 가치를 판단할 수 없거나, 워크로드가 완전히 단일 CSP 또는 온프레미스 환경에 종속되어 있다면, 최상위 비즈니스 지표만 단일 뷰에 롤업하고, 원시 지표 및 기타 기여 요인은 원래 환경에 두는 것을 고려하세요.
OpenTelemetry에 투자하세요
Observability 벤더 생태계 전반에 걸쳐, OpenTelemetry(OTel)는 사실상의 표준이 되었습니다. OTel은 각 텔레메트리 유형을 하나 또는 여러 컬렉터로 전달할 수 있으며, 여기에는 클라우드 네이티브 서비스뿐만 아니라 다양한 SaaS 및 ISV 제품이 포함됩니다. OTel 에이전트와 컬렉터는 OpenTelemetry Protocol(OTLP)을 사용하여 통신하며, 이는 다양한 배포 패턴을 가능하게 하는 형식으로 신호를 캡슐화합니다.
가장 가치 있는 트랜잭션 트레이스를 수집하고, 비즈니스 및 인프라 컨텍스트를 포함하려면, 애플리케이션에 트레이스 수집을 통합해야 합니다. 일부 자동 계측 에이전트는 거의 노력 없이 이를 수행할 수 있습니다. 그러나 가장 정교한 사용 사례에서는 트랜잭션 트레이스를 지원하기 위한 코드 변경이 필요합니다. 이는 일부 기술 부채를 생성하고 워크로드를 특정 기술에 종속시킵니다.
OTel은 span이라는 개념을 사용하여 logs, metrics, traces를 캡처합니다. Span은 단일 트랜잭션에서 이러한 신호들을 함께 그룹화하여, 컨텍스트가 포함된 검색 가능한 객체로 패키징합니다. 이는 단일 애플리케이션 이벤트의 신호를 하나의 간단한 엔티티로 볼 수 있다는 것을 의미합니다. 예를 들어, 사용자가 웹 사이트에 로그인하고 이로 인해 통합된 모든 다운스트림 서비스에 생성되는 요청을 단일 span으로 표현할 수 있습니다.
OTel은 애플리케이션 트레이스에 국한되지 않으며, logs와 metrics에도 널리 사용됩니다. 그리고 많은 ISV 제품들이 현재 OTLP를 직접 지원합니다.
OTel을 사용하여 애플리케이션을 계측하면, 향후 하나의 Observability 플랫폼에서 다른 플랫폼으로 이동하더라도 애플리케이션 레이어에서 계측을 교체할 필요가 없습니다. 이는 Observability 솔루션의 일부를 양방향 도어로 만들어 줍니다.
OTel은 미래 대비가 가능하고, 확장 가능하며, 애플리케이션 코드를 변경하지 않고도 향후 수집 및 분석 시스템을 쉽게 교체할 수 있게 해주는 효율적인 시프트 레프트 방식입니다.