데브옵스 팀이 분산된 환경에서 가시성을 확보하지 못하는 이유

변화하는 환경에서는 context가 핵심입니다. 

팀이 소프트웨어를 배포하고 운영하는 방식은 지난 10년간 빠르게 발전해 왔습니다. 그 결과로 IT 운영자가 관리해야 하는 영역은 크기와 복잡성의 측면에서 급격히 증가하고 있습니다. 

인프라의 세계에서, 변화는 한 때 부담으로 여겨졌지만 이젠 경쟁 우위를 위한 기반이 되었습니다. 

기업은 인프라와 애플리케이션을 더 빠르고 자주 출시하기 위해 데브옵스 관행을 도입합니다. 속도, 확장성 및 성능을 향상시키기 위해 애플리케이션을 현대화합니다. 클라우드로 이동을 합니다. 마이크로서비스를 도입합니다. 쿠버네티스 같은 컨테이너 오케스트레이션 시스템을 실행합니다. 

거기에다 이제 신속하고 끊임없는 변화가 인프라 관리 체계에 추가되었습니다. 

소프트웨어 변경, 설정, 알림, 기타 모든 사항이 증가됩니다. 이와 동시에 문제를 보다 빠르게 감지하고 해결하며 운영 시스템의 안정성과 신뢰성을 보장해야만 하는 부담도 커집니다. 

가속화와 확장으로 야기된 복잡성으로 인해 모니터링 전략을 수정해야 할 필요성이 생겼습니다. 대부분의 경우 시스템이 운영 단계에 돌입하기 전까지 어떻게 작동할지 알 수 없기 때문에, 운영 환경을 관찰할 수 있는 시스템이 필요합니다. 

접근 방식을 바꾸면, 팀이 동적인 시스템들을 효과적으로 관리하는 데 도움이 됩니다.

문제는 개발자용 tool, IT 운영자용 tool, 비즈니스 관리자용 tool, 로그용 tool, 메트릭용 tool, 트레이스용 tool, 온프레미스용 tool, 클라우드용 tool 등, 여러 팀들이 다른 tool을 사용해 스택의 각 부분을 모니터링하고 있다는 것입니다.

물론 각 팀마다 필요에 가장 적합한 tool을 선택했을 것입니다.

하지만 이는 모든 팀들이 더 많은 알림과 텔레메트리 데이터를 처리하고 있으며, 무엇보다도 운영 데이터가 단편적이라는 것을 의미합니다. 

무질서한 tool 확산의 문제 : 단편적인 관찰성은 관찰성이 아닙니다. 

각 tool은 전체 그림의 일부만 보여줍니다. 그러나 그림은 동적이며, 스택의 부분들 간에 경계는 분명하지 않습니다. 애플리케이션이 충돌하면 피해가 확산되기 전에 코드나 인프라에서 무슨 일이 발생했는지 알아내야 하지만, 각 시스템의 구성 요소에 서로 다른 포인트 솔루션을 사용하고 있기 때문에 시간과 비용이 낭비됩니다.

결국 데이터는 사일로에 갇히게 됩니다. 모든 tool이 다른 어휘를 사용해 다른 팀들은 이해할 수 없습니다. 그래서 평균진단시간(MTTD)과 평균장애복구시간(MTTR)이 길어집니다. 

비용에는 단순히 금전적인 것만 포함되지는 않습니다. 비즈니스 전체에 폭포 효과를 일으킬 수 있습니다. IT 팀과 운영 팀은 문제 해결에 너무 많은 시간을 소비하다 보니 정작 혁신에 매진할 시간은 없습니다. 팀 간의 연계와 협업이 저하되고, 직원들의 사기가 떨어지며 비즈니스에 차질이 생깁니다.

이 가이드에서는 tool의 무질서한 확산이 비즈니스에 어떤 방식으로 피해를 주는지 자세히 알아보겠습니다. 또한 이를 극복하면 어떤 가능성이 열리는지에 대해서도 살펴보겠습니다. 

수치만으로는 그 사실을 알 수 없습니다. 그러나 451 Research의 설문조사에 따르면, 응답자의 39%가 애플리케이션, 인프라 및 클라우드 환경을 모니터링하기 위해 11~30개의 모니터링 tool을 사용하고 있었으며, 8%는 21~30개의 tool을 사용하고 있었습니다.

이러한 tool 중 대다수는 오픈소스 (‛무료')일 확률이 높지만, 다운타임 비용을 차치하더라도 관련 비용은 빠르게 늘어날 수 있습니다. 

• 이는 직원들의 속도를 저하시킵니다. 무질서한 tool 확산으로 인한 첫 번째 문제는, 하나의 tool에서 다른 tool로 문맥을 전환하는 데 엄청난 시간이 소모된다는 것입니다. 특정 상황에서 몇 초 또는 몇 분 정도로 보이는 문제들이 조직 전체에 분산되어 있다면 훨씬 더 큰 문제가 될 수 밖에 없습니다.

• 데이터 해상도가 떨어집니다. IT 스택의 여러 부분을 모니터링하기 위해 다른 tool들을 사용하는 경우, 모든 구성 요소에서 애플리케이션 성능과 시스템 상태 간의 상관 관계를 파악할 수 없기 때문에 환경에 대한 가시성이 부족해 집니다. 

• 관리자 부담이 늘어납니다. tool 자체는 초기 비용이 없을 수도 있지만, 소프트웨어 라이선스, 내부 리소스, 애드온 모듈, 스토리지, 하드웨어, API 액세스와 관리를 하려면 tool을 설정하고 지속적으로 유지 관리해야 합니다. 단일한 팀 내에서도 많은 문제를 처리해야 하는데 이러한 문제들이 분산된 환경 전체로 확장된다면, 갑자기 비효율성이 뚜렷하게 드러납니다. 

이 모든 것으로 인해 문제를 해결하는 데 시간이 더 오래 걸립니다. 일부 문제의 경우, 데이터가 너무 분산되어 근본 원인을 파악할 수 없으므로, 엔드유저 경험에 부정적인 영향을 줄 수 있는 문제들이 드러나기 시작합니다. 무엇보다도 사용자들이 먼저 이러한 문제를 경험하고 보고를 합니다. 

다운타임과 비즈니스 비용 간에는 직접적인 연관성이 존재하며, 그 비용은 상당할 수 있습니다. 

Gartner에 따르면, 다운타임 1시간의 평균 비용은 3억 달러이며, 33%의 기업은 다운타임 1시간으로 인해 실제로 1~5백만 달러의 비용이 발생했다고 밝혔습니다.

무엇이 잘못되었는지를 명확하게 파악해야 문제를 방지할 수 있습니다.

그리고 이는 문맥, 즉 context가 있어야 가능합니다. 

고객의 구매 전환에 대한 이해

양방향 인터페이스를 통해 구매자의 여정 단계를 분석하고 맞춤화할 수 있습니다. 페이지 뷰, 오류율, 오류 수 등 각 단계의 표준 데이터를 볼 수 있습니다. 마케팅 퍼널의 각 단계에 대한 지표를 보다 자세히 확인할 수 있습니다.

새로운 인프라의 원활한 통합

운영팀이 사용하는 엔드포인트는 기하급수적으로 증가하고 있습니다. 전문 지식이 필요하지 않은 올인원 통합 기능을 활용해 타사 소스의 데이터를 쉽게 수집할 수 있기 때문에 팀들은 특정 인프라 환경과 관련된 문제를 해결하는데 필요한 문맥, 즉 context를 확보할 수 있습니다. 

관찰성과 마찬가지로 인프라는 그 자체만으로는 존재 할 수 없습니다. 인프라는 더 광범위한 스택이라는 문맥으로 존재합니다. 비즈니스가 성공하려면 고객 경험이라는 광범위한 맥락에서 존재하는 인프라를 제대로 구축해야 합니다. 

현대의 인프라 관리는 지속적으로 변화하기 때문에 애플리케이션 문제를 빠르게 감지하고 해결하기가 쉽지 않지만, 이를 올바르게 수행하는 것이 그 어느 때보다 중요해졌습니다. 로깅이나 Linux 인프라 같이 스택의 한 부분만을 모니터링하고 고립된 데이터에 의존하는 포인트 솔루션이 모순이 될 수 밖에 없는 이유도 이 때문입니다. 이러한 솔루션은 사용하는 팀을 위해 필요한 역할을 수행하지만, 특정 구성 요소를 벗어나는 즉시 큰 혼란을 야기합니다.

MTTR을 개선하고 다운타임을 줄이며 끊김 없는 엔드유저 경험을 제공하려고 노력하는 과정에서 충돌이 발생하면, 두 가지 질문에 즉시 대답할 수 있어야 합니다. "무엇이 고장났고, 그 이유는 무엇인가?"

옵저버빌리티, 즉 관찰 플랫폼이 제공하는 전체적인 문맥이 있어야 ‛무엇' 의 단계에서 신속하게 ‛이유'의 단계로 이동할 수 있으므로, 이러한 질문에 빠르게 답변하고 다운타임이나 엔드유저의 경험 저하를 최소화할 수 있도록 팀들에게 역량을 제공해야 합니다.

최신 인프라스트럭처와 관찰 플랫폼은 인프라스트럭처, 로그, 설정 변경, 애플리케이션 및 프런트엔드 서비스의 다양한 데이터를 한 곳에 수집해 상호연관시켜 적절한 문맥으로 표시해줍니다. 

이는 운영 팀이 인프라스트럭처가 애플리케이션에 미치는 영향이나 그 반대의 경우도 정확히 파악할 수 있다는 뜻입니다. 

데이터에서 더 의미있는 인사이트를 얻기를 원한다면, 

New Relic One을 고려해 보십시오. 개발 및 운영 팀이 단일 플랫폼에서 동일한 데이터에 액세스하고, 애플리케이션과 인프라에 대해 신속하게 상관관계를 수립해 문제를 보다 빠르게 파악하고 해결할 수 있도록 지원해야 합니다.

그래야 소프트웨어에서 어떤 일이 일어나도 엔드유저 경험에 영향을 미치기 전에 문제를 찾아 해결할 수 있습니다.