관측 가능성을 둘러싼 오해 바로잡기 – 2부: 관측 가능성이 SRE뿐만 아니라 모든 사람에게 중요한 이유

블로그 시리즈를 통해 지금까지 다음과 같은 관측 가능성을 둘러싼 오해를 바로잡았습니다.

• 1부: 모니터링을 건너뛰고 로그에만 의존할 수 있다
• 2부: 관측 가능성은 SRE만을 위해 구축된다
• 3부: 관측 가능성은 대규모 시스템이나 복잡한 아키텍처에만 적합하고 유익하다
• 4부: 관측 가능성은 항상 비용이 많이 든다
• 5부: 관측 가능성에 중심을 둔 자동화 없이는 관측 시스템을 만들 수 없다
• 6부: 관측 가능성은 스택의 일부와 관련된 것이다

이 게시물에서는 관측 가능성의 잠재력을 제한하는 또 다른 오류, 즉 사이트 안정성 엔지니어(SRE)만을 위해 구축되었다는 오해에 대해 다뤄보겠습니다.

관측 가능성을 둘러싼 이러한 오해는 관측 가능성이 사이트 신뢰성 엔지니어(SRE)만을 위한 것이며, 관측 가능성 솔루션을 통해 수집한 데이터를 활용할 수 있는 유일한 역할은 SRE뿐이라는 믿음에서 비롯됩니다. 실제로 관측 가능성은 조직 내의 특정한 역할이나 팀을 훨씬 뛰어넘어 활용됩니다.

클라우드 기반으로의 전환은 단순히 새로운 기술을 도입하는 것 이상을 의미합니다. 이러한 전환은 사람들의 업무 방식을 바꾸는 것 또한 의미합니다. 이러한 변화는 본질적으로 사회 기술적인 변화입니다. 마이크로서비스 툴체인 자체가 표면적으로는 새로운 사회적 관행을 명시적으로 요구하지 않을 수도 있지만, 이 기술의 이점을 최대한 활용하려면 업무 습관의 변화가 필요합니다. 이러한 필요성은 팀이 프로세스의 여러 단계를 진행하면서, 이전 접근 방식이 새로운 기술로 인해 발생하는 관리 비용을 효과적으로 해결할 수 없다는 사실을 알게될 때 분명해집니다.

시스템, 애플리케이션, 마이크로서비스가 더욱 얽히고 복잡해짐에 따라 인시던트를 식별하고 해결하는 것도 더욱 어려워지고 있습니다. 과거에는 조직이 인시던트를 해결하고 수정하기 위해 SRE에 의존했을 수도 있습니다. 그러나 이제 IT는 훨씬 더 팀 스포츠에 가깝고, 이전의 접근 방식이 항상 효과적이거나 비용 효율적이지는 않습니다. 그러나 결론은 클라우드 네이티브 디자인 패턴을 채택하면 관측 가능한 시스템이 필요하다는 것입니다.

사실 DevOps, SRE, 플랫폼, ITOps, 개발 등 모든 팀은 모바일, 웹, 애플리케이션, 인프라 전반에 걸친 논리적 및 물리적 종속성의 컨텍스트에서 원하는 데이터에 액세스할 수 있어야 하며, 액세스할 자격이 있습니다.

관측 가능성 솔루션은 소프트웨어 개발 및 운영에 참여하는 여러 이해관계자에게 귀중한 인사이트를 제공하며 개발자, 운영 팀, 제품 관리자, 비즈니스 이해관계자에게까지 그 이점이 확장됩니다. 이러한 포괄적인 접근 방식을 통해 더 빈번한 신규 배포에 대한 신속한 피드백이 가능하므로 신속한 문제 해결과 소프트웨어 품질 향상을 보장할 수 있습니다.

조직 내에서 이러한 다른 역할에 대한 몇 가지 주요 사용 사례를 살펴보겠습니다.

• 개발자:
  • 분산 추적과 같은 관측 가능성 도구는 개발자가 애플리케이션을 통해 요청의 흐름을 이해하고 성능 병목 현상을 식별하는 데 도움을 줄 수 있습니다. 예를 들어, 추적을 분석하여 애플리케이션의 각 구성 요소가 요청을 처리하고, 그에 따라 최적화하는 데 걸리는 시간을 확인할 수 있습니다.
  • 개발자는 적절한 모니터링 및 관측 메커니즘을 통합하여 코드를 계측할 수 있습니다. 여기에는 애플리케이션 전체에 걸쳐 전략적으로 코드 수준의 계측 지점과 로깅 문을 배치하는 작업이 포함됩니다. 개발자는 이렇게 하면서 소프트웨어 실행 중에 귀중한 데이터와 인사이트를 수집할 수 있습니다.
  • 개발자는 애플리케이션 로그를 모니터링하여 코드의 오류나 예외를 확인하고 수정할 수 있습니다. 로그 집계 및 분석 도구를 사용하여 특정 로그 항목을 검색하고 문제의 근본 원인에 대한 인사이트를 얻을 수 있습니다.
• 운영팀:
  • 운영팀은 관측 가능성을 통해 시스템 지표를 모니터링하고 비정상적인 동작에 대한 경고를 설정할 수 있습니다. 예를 들어, CPU 사용량과 메모리 사용량, 네트워크 트래픽을 모니터링하여 성능 급증이나 리소스 병목 현상을 감지할 수 있게 됩니다.
  • 운영팀은 실시간 모니터링 및 시각화 도구를 사용하여 분산 시스템의 상태를 추적하고 이상 징후나 장애를 감지할 수 있습니다. 그리고 특정 이벤트가 시스템 동작에 미치는 영향을 파악하고, 문제를 완화하고자 발 빠르게 대응할 수 있습니다.
• 제품 관리자:
  • 관측 가능성 데이터는 제품 관리자에게 중요 사용자 행동 및 애플리케이션 성능 정보를 제공할 수 있습니다. 예를 들어, 사용자 상호 작용 데이터를 분석하여 고객이 제품을 어떻게 사용하고 있는지 파악하고 개선해야 할 부분을 찾을 수 있습니다.
  • 제품 관리자는 비즈니스 지표와 시스템 성능 지표를 상호 비교하여 기술적 변화가 주요 비즈니스 결과에 미치는 영향을 평가할 수 있습니다. 가령, 응답 시간의 변화가 전환율이나 고객 만족도에 어떤 영향을 미치는지 분석할 수 있습니다.
• 비즈니스 이해관계자:
  • 관측 가능성을 통해 비즈니스 이해관계자는 실시간으로 비즈니스 지표를 모니터링하고 분석할 수 있습니다. 예를 들어, 매출이나 고객 참여, 전환율을 추적하여 시스템 성과 지표와의 연관성을 보여줄 수 있습니다.
  • 이해관계자는 시스템 성능과 비즈니스 결과 간의 관계를 파악하여 정보에 입각한 의사 결정을 내릴 수 있게 됩니다. 가령, 인프라 개선에 대한 투자의 우선순위를 정하는 데도 도움이 됩니다.

IT 시스템이 발전하고 직무 정의가 확장되면서 누구나 관측 가능 데이터를 활용할 수 있도록 하는 것이 무척 중요해졌습니다. 이를 통해 주요 이해관계자는 조직에 도움이 되는 데 필요한 데이터 인사이트를 얻을 수 있습니다. 그렇기 때문에 관측 도구를 선택할 때는 요금 모델을 파악하고 추가 사용자에 대해 별도의 요금을 부과하지 않는 모델을 고려해야 합니다.

보다 강력하고 혁신적인 IT 조직을 구성하려면 관측 가능성을 둘러싼 잘못된 믿음 중에서 사실을 찾아낼 수 있어야 합니다. 관측 가능성의 다면적인 이점을 이해하고 보다 광범위한 데이터 소스를 받아들이면 신뢰성과 비즈니스 성과를 높일 새로운 가능성을 열 수 있습니다.

IBM의 관측 가능성 솔루션인 IBM® Instana는 클라우드 네이티브용으로 특별히 제작되었으며,모바일, 웹, 애플리케이션, 인프라 전반의 논리적 및 물리적 종속성의 컨텍스트에서 충실도 높은 데이터를 지속적으로 자동 제공하도록 설계되었습니다(예: 1초 단위의 세분화 및 엔드투엔드 추적). 고객은 실시간 관측 가능성을 통해 가시적인 성과를 달성하고 있습니다.

풀스택 가시성과 클라우드 종속성을 실시간으로 모니터링하는 기능을 통해 관측 가능성 관행을 강화하고 싶으시다면 데모를 요청하시기 바랍니다.

비즈니스 성장을 위한 확장성 보장: Leaf Group Ltd의 기술 운영 담당 부사장인 Marcus Sengol은 "Instana를 구현한 후, 이전에는 볼 수 없었던 것들에 대한 가시성을 확보할 수 있게 되었습니다."라고 말합니다. "Instana를 사용하면 각 상위 KPI 및 지표를 매우 쉽게 드릴다운할 수 있으므로 스택의 여러 부분을 최적화하고 성능 문제를 찾을 수 있습니다. 우리는 이러한 지표를 기반으로 개선을 이루어 왔으며 오늘날까지도 계속 이어지고 있습니다."

최적화 추진: "우리는 매우 높은 해상도로 솔루션의 성능을 이해하는 데 도움이 될 무언가를 찾고 있었습니다. 다양한 이유로 존재할 수 있는 최고점과 최저점을 초 단위로 확인할 수 있기를 원했습니다."라고 Mayden의 운영 이사인 Chris Eldridge는 설명합니다.

다음 블로그 게시물에서 관측 가능성은 대규모 시스템이나 복잡한 아키텍처에만 유익하다라는 또 다른 일반적인 오해를 바로잡을 예정이니, 계속 지켜봐 주시기 바랍니다. 여러분을 기다리는 더 다양한 이점과 애플리케이션을 발견할 준비를 하세요.

• 읽기: '관측 가능성을 둘러싼 오해 바로잡기 – 1부: 모니터링을 건너뛰고 로그에만 의존할 수 없는 이유'
• 읽기: '관측 가능성을 둘러싼 오해 바로잡기 – 3부: 관찰 가능성이 대규모 시스템뿐 아니라 모든 환경에서 효과적인 이유'