관련링크

안녕하세요! 새롭게 개편된 뉴스레터로 인사드립니다. 지난 설문조사에서 뉴스레터 방향성에 대한 많은 의견을 남겨주셨고, 의견을 취합한 결과 앞으로 매월 1개의 주제를 선정해 심도 있게 다루는 콘텐츠로 뉴스레터를 구성하게 되었습니다. (와탭 뉴스레터 구독하기(링크))

그리고 11월 그 첫번째 주제로 "쿠버네티스"를 선정했는데요. 정확히는 "쿠버네티스 옵저버빌리티(Observability)"라는 주제를 다뤄보려고 합니다.

왜 "쿠버네티스 옵저버빌리티"로 선정했나요? 라고 물으신다면, 가장 큰 이유는 바로 쿠버네티스라는 플랫폼이 가진 높은 관심도와 중요성 때문입니다. 최근 많은 기업이 클라우드 환경으로 전환하면서 쿠버네티스 도입이 증가하고 있는데요. 네이버, 카카오, 토스와 같은 국내 주요 IT 기업들도 쿠버네티스 기반 인프라를 적극적으로 구축하며 주목을 받고 있죠. 

와탭랩스 역시 이 화제에 동참하고자 이번주 금요일(11/29) 쿠버네티스 오프라인 행사(WhaTap Kubernetes Day 2024)를 코엑스에서 개최합니다!

이번 행사는 무료로 진행되며, 쿠버네티스의 복잡성을 극복하고 운영의 해법을 모색할 수 있는 다양한 인사이트를 제공할 예정입니다. 행사에 관한 내용은 뉴스레터 하단에서 한 번 더 소개해드릴게요. 
 

오늘 글에서는 다음 3가지 인사이트를 얻어가실 수 있어요!

• 쿠버네티스가 등장하게 된 배경과 그 복잡성의 원인을 이해할 수 있어요.
• 쿠버네티스 옵저버빌리티를 위한 핵심 지표를 확인할 수 있어요.
• 쿠버네티스 환경에서 옵저버빌리티가 왜 중요한지 그 이유를 알 수 있어요.

쿠버네티스가 IT 환경의 표준으로 자리 잡은 요즘, 많은 기업이 쿠버네티스를 도입하면서도 그 복잡성에 대해 많은 우려를 표하고 있습니다. 쿠버네티스는 2015년 구글이 오픈소스로 공개한 이후 오랜 시간 시장 지배력을 높이며 컨테이너화된 애플리케이션의 관리와 오케스트레이션을 위한 업계 표준으로 자리 잡았으나, 여전히 내부 구조의 이해와 운영의 어려움이 존재하기 때문이죠. 

2022년 Spectro Cloud의 리서치(링크)에 따르면, 쿠버네티스를 사용하는 기업 중 56%가 장애 대응 시 운영자의 경험과 기술에 크게 의존하고 있는 것으로 나타났습니다. 이는 즉, 시스템 장애 발생 시 상태를 빠르게 파악하고 문제를 해결하기 위해 지속적인 기술적 투자가 필요하다는 점을 시사하는데요. 

그렇다면 쿠버네티스는 왜 복잡한걸까요? 그 원인을 쿠버네티스의 등장 배경에서부터 함께 살펴보겠습니다.

쿠버네티스의 등장 배경과 복잡성의 원인! 

디지털 트랜스포메이션 시대의 도래와 함께 기업들은 급변하는 사용자 요구와 치열한 경쟁에서 살아남기 위해 더욱 빠른 소프트웨어 개발과 유연한 배포 방식을 모색하게 되었습니다. 그래서 등장한 개념이 바로 마이크로서비스 아키텍처(MSA)입니다. 

MSA는 거대한 단일 애플리케이션을 여러 마이크로 애플리케이션으로 쪼개는 방식으로, 더욱 속도감 있는 개발과 배포에 큰 기여를 하게 되는데요. 또한 마이크로화된 애플리케이션들은 주로 컨테이너 기술을 통해 배포되기 시작합니다. 

하지만, 기술의 확산과 함께 폭발적으로 증가하는 마이크로서비스와 컨테이너는 관리의 어려움이라는 또 다른 숙제를 안겨주게 되었는데요. 이 문제를 해결하기 위해 탄생한 도구가 바로 쿠버네티스입니다! 

쉽게 비유하자면 컨테이너화된 마이크로 애플리케이션은 각각의 레고 블록이고, 쿠버네티스는 레고 블록들로 만들어진 도시를 관리하는 관리자라고 할 수 있습니다. 관리자는 레고 도시에서 수많은 블록들을 관리, 조율, 최적화하는 역할을 맡게 되죠. 

쿠버네티스의 복잡성은 크게 두 가지 주요 원인에서 비롯됩니다. 바로 동적 특성과 마이크로서비스의 증가인데요.

먼저, 쿠버네티스 상에서 실행되는 컨테이너는 수량과 위치가 고정되어 있지 않습니다. 운영 중 여러 상황에 따라 안정적으로 운영하기 위해 새로운 컨테이너가 생성되거나 기존 컨테이너가 종료되곤 하는데요. 이 과정에서 컨테이너가 실행되는 노드(Node)의 위치가 변경되는 경우가 발생합니다. 

이러한 쿠버네티스의 동적 특성 때문에 운영자는 컨테이너의 현재 위치와 상태를 지속적으로 추적해야 합니다. 

또한, 앞서 언급했듯 쿠버네티스의 등장은 마이크로서비스의 확산과 무관하지 않습니다. 기업이 마이크로서비스 아키텍처를 도입하고 애플리케이션을 마이크로화하면 할수록 관리해야 할 컨테이너와 *파드(Pod)의 수가 선형적으로 증가할 수밖에 없죠. 

결국, 쿠버네티스의 복잡성은 많은 수의 동적 컨테이너를 관리해야 한다는 점에서 기인합니다. 

* 파드(Pod)는 쿠버네티스에서 하나 이상의 컨테이너가 함께 실행되며, 네트워크와 스토리지를 공유하는 가장 작은 배포 단위를 말합니다.

쿠버네티스 환경에서 옵저버빌리티가 필요한 이유

이와 같은 쿠버네티스의 특성들은 운영자에게 한 차원 높은 수준의 모니터링 능력을 요구합니다. 그리고 이를 충족하기 위해 옵저버빌리티가(=한 차원 높은 수준의 모니터링 능력) 등장한 거죠. 

쿠버네티스의 복잡성을 효과적으로 관리하기 위해선 단순히 시스템의 상태를 확인하는 모니터링에서 넘어서, "왜" 문제가 발생했는지 이해하고, 이를 추적하여 해결하는 옵저버빌리티가 필수적입니다. 

모니터링과 옵저버빌리티: 상태 확인에서 문제 해결로! 

모니터링과 옵저버빌리티의 차이를 좀 더 자세히 살펴보겠습니다. 모니터링(Monitoring)은 우리가 일반적으로 알고 있는 시스템 관리의 첫 단계입니다. "CPU 사용량이 얼마나 되나요?", "어제 네트워크 트래픽이 얼마나 발생했나요?"처럼 상태를 파악하고, 이상 여부를 확인하는 데에 초점을 맞추죠. 

하지만, 이런 질문들만으로는 부족할 때가 많아요! "CPU 사용량이 왜 갑자기 늘었지?", "트래픽이 왜 증가한거지?"와 같은 근본적인 질문을 던지기 시작하면 단순히 데이터를 확인하는 것 그 이상이 필요합니다. 그리고 이에 대한 해답을 주는 것이 바로 옵저버빌리티(Observability)입니다. 

옵저버빌리티는는 수집된 데이터를 바탕으로 Why와 How라는 질문에 답을 찾는 능력입니다. 쉽게 말해, 모니터링이 무언가 잘못됐음을 알려 주는 교통신호라면, 옵저버빌리티는 그 신호를 분석해 교통 체증의 원인을 찾는 것이라고 할 수 있습니다.
 

📌 요약:

모니터링

• 시스템 상태 확인, 이상 징후 탐지
• What, When 질문에 답변이 가능
• 예: CPU 사용량, 네트워크 트래픽 확인

옵저버빌리티 

• 데이터 분석을 통한 문제 원인 및 해결방법 도출
• Why, How 질문에 답변이 가능 
• 예: CPU 사용량 급증 이유, 트래픽 증가 원인 분석

옵저버빌리티를 이해하기 위해서는 반드시 알아야 할 3가지 핵심 요소가 있습니다. 바로 메트릭스(Metrics), 트레이스(Traces), 로그(Logs) 입니다. 

첫째, 메트릭스(Metrics)
메트릭스는 시스템의 성능을 정량적으로 표현한 데이터로, CPU 사용량, 메모리 사용량, 네트워크 트래픽 등이 이에 해당합니다. 예를 들어, “어제보다 CPU 사용량이 20% 증가했네?”와 같은 트렌드를 파악할 때 유용합니다. 

둘째, 트레이스(Traces)
트레이스는 하나의 요청이 시스템 내부에서 처리되는 과정을 추적합니다. 이는 마이크로서비스 간의 상호작용을 분석하고, 병목 지점을 식별하며, 문제의 원인을 파악하는 데 필수적인 요소입니다.

셋째, 로그(Logs)
로그는 시스템이나 애플리케이션이 기록한 다양한 데이터입니다. 주로 특정 시점에 어떤 일이 일어났는지 세부적으로 알려주는 정보가 포함되어 있는데, 특히 메트릭스나 트레이스만으로 보이지 않는 현상이나 원인을 제공하는 경우가 많기 때문에 반드시 확인해야 하죠.

정리하자면, 메트릭스는 “언제, 어디에 문제가 있는지”, 트레이스는 "문제가 어떤 식으로 발생하여 진행되었는지", 로그는 "문제 시점에 어떤 일들이 벌어진 것인지"를 세부적으로 보여줍니다. 

이 세 가지 요소는 서로 상호보완적인 관계를 이루며, 단독으로 사용되기 보다는 함께 활용되어 시스템의 상태를 정확히 파악하고 문제를 해결하는 데 필요한 인사이트를 제공합니다.

옵저버빌리티는 바로 이 메트릭스, 트레이스, 로그라는 핵심 데이터를 기반으로 시스템의 문제를 해결하는 능력입니다. 옵저버빌리티의 핵심은 단순히 "무엇이 잘못됐는지"를 파악하는 데 그치지 않고, "왜 잘못됐는지"와 "어떻게 해결할 수 있는지"까지 답을 찾는 데 있습니다. 

추가적으로, 쿠버네티스에서는 메트릭스, 트레이스, 로그에 이벤트(Event) 데이터까지 추가하여 더욱 높은 수준의 옵저버빌리티를 확보하기도 합니다. 쿠버네티스 이벤트는 클러스터가 직접 제공하는 정보로 여러 리소스들의 상태와 에러 정보를 담고 있습니다.

쿠버네티스 옵저버빌리티 확보를 위한 기업들의 과제

앞서 설명한 것처럼 복잡한 쿠버네티스 환경에서 문제의 원인을 정확히 파악하고 안정적인 운영을 하기 위해서는 옵저버빌리티가 필수적입니다. 그렇다면, 기업들이 쿠버네티스 옵저버빌리티를 확보하기 위한 핵심 과제는 무엇일까요? 

먼저 1️⃣쿠버네티스 자체에 대한 깊은 이해와 모니터링 데이터를 수집, 저장, 관리할 체계적인 절차가 필요합니다. 단순히 모니터링 소프트웨어를 설치하는 것으로 끝나는 것이 아니라, 수집할 지표를 선별하고 이를 시각화할 대시보드를 구성해야 하죠.

또한, 2️⃣각 지점의 로그를 수집하고 검색할 수 있는 기능, 알림 환경과 보고서 생성 기능 등이 포함된 완성도 높은 시스템을 설계해야 하며, 3️⃣이를 지속적이고 안정적으로 관리할 인프라 운영 역량도 필수적입니다.

그러나 이러한 시스템이 구축되더라도 옵저버빌리티는 또 다른 영역입니다.

옵저버빌리티는 단순히 데이터를 나열하는 것으로 끝나는 것이 아니라, 수집된 데이터 간의 연관성을 분석하고 문제의 원인을 정확히 추론하는 과정이 동반되어야 합니다. 만약 이러한 작업이 실패한다면 방대한 데이터는 그저 혼란스러운 정보로 전락할 뿐이죠.

따라서, 4️⃣데이터를 중앙화하고 데이터간 상관 관계를 분석할 수 있는 시스템을 구축하는 것이 옵저버빌리티를 확보하기 위한 마지막 주요 과제라고 할 수 있습니다.

위 글은 와탭랩스와 토크아이티가 콜라보하여 진행한 <복잡한 쿠버네티스, 옵저버빌리티는 어떻게 하지?> 웨비나의 내용을 재구성 및 일부 편집하여 제작했습니다.

마무리 

와탭의 쿠버네티스 옵저버빌리티(현재 제품 이름은 '쿠버네티스 모니터링'으로 명명하고 있습니다)는 쿠버네티스 환경에서 발생하는 복잡한 문제를 해결하는 데 적합한 선택지 중 하나입니다.

와탭을 도입하면 복잡한 옵저버빌리티 구축 및 관리에 소요되는 시간과 노력이 획기적으로 줄어들기 때문에, 기업은 핵심 비즈니스에 더욱 집중, 투자할 수 있습니다. 와탭의 쿠버네티스 옵저버빌리티에 대한 자세한 내용은 아래 영상을 통해 확인하실 수 있습니다.

이번 레터에서는 쿠버네티스의 등장 배경, 복잡성의 원인, 옵저버빌리티의 필요성, 그리고 기업들이 직면한 과제에 대해 다뤄봤는데요. 짧지 않은 내용이었지만, 쿠버네티스와 옵저버빌리티를 깊이 있게 다루기에는 여전히 부족한 부분이 많다고 느껴집니다.

저처럼 쿠버네티스와 옵저버빌리티 학습에 대한 열망(?)을 가지고 계신 분들께는 이번 주 금요일(11/29) 코엑스(COEX)에서 열리는 "와탭 쿠버네티스데이" 오프라인 행사를 추천드립니다. 오후 반일 동안 진행되는 이번 행사에서는 와탭 쿠버네티스 그룹 개발자들이 실질적이고 유익한 인사이트를 제공할 예정입니다.

오늘 다룬 주제에 대한 여러분의 의견이나 궁금한 점이 있으시면 여기에 남겨주세요. 다가오는 12월에는 새로운 주제로 다시 찾아뵙겠습니다. 긴 글 끝까지 읽어주셔서 감사합니다. 

와탭 뉴스레터를 지금 구독하세요!(링크)
매월 IT 모니터링과 옵저버빌리티(Observability)에 대한 인사이트가 담긴 레터를 메일함에 넣어드립니다.