IT/모바일
컴퓨터의 등장 초기부터 프로그래머들은 ‘시스템이 내가 의도한 대로 작동하고 있는 걸까?’ 라는 질문에 대한 답을 갈구했습니다. 소프트웨어 산업에서 관찰 가능성Observability이라는 용어가 사용되기 시작한 것은 비교적 최근이지만, 관찰 가능성이 의미하는 개념과 목적은 꽤 오래전부터 통용되어 왔던거죠.
일부 사람들은 관찰 가능성이 ‘추적, 메트릭, 로그가 포함된 만능 솔루션을 구매하고 제품 통합을 구성한 후 일을 끝내는 것’이라고만 생각합니다. 실은 소프트웨어 작동 가시성을 높이기 위해 원격 측정 데이터를 생성하고 수집하는 매커니즘을 활용하는 작업을 내포하고 있는데 말입니다.
높은 품질의 원격 측정을 수행하는 건 관찰 가능성의 과제 중 일부에 불과하며, 다양한 유형의 원격 측정에서 발생하는 이벤트가 분석 중에 의미 있는 방식으로 연관되도록 보장해야 합니다. 관찰 가능성의 목표는 다음 질문에 대한 답을 찾는 것입니다.
● 1분 전까지만 해도 멀쩡했던 서비스에 과부하가 걸리는 이유는 무엇일까?
● 운영 환경에 문제가 발생했을 때 문제 식별을 위해 필요한 증거는 무엇일까?
● 클라이언트의 특정 조건이 내부 서비스의 비정상적인 작동을 유발하고 있을 때 사용자나 지원팀의 연락 없이 알아차릴 수 있을까?
답을 찾는 모험을 떠나기 이전에, 오늘은 관찰 가능성이 가장 중요한 요구 사항이 된 이유를 소프트웨어 산업의 변화로 살펴보고자 합니다. 이번 이야기에는 클라우드 네이티브 애플리케이션과 데브옵스가 등장합니다. 우선 클라우드 네이티브 애플리케이션부터 살펴볼까요?
1. 클라우드 네이티브 애플리케이션
애플리케이션을 만들고 배포하는 방법은 인터넷의 도입으로 급격히 변화했습니다. 스트리밍 미디어, SNS, 온라인 쇼핑처럼 소프트웨어를 통해 제공되는 서비스에 대한 전례 없는 수요는 이런 서비스를 쉽게 이용할 수 있을 것이라는 기대감을 높였고, 개발자는 자신의 애플리케이션이 빠르게 확장되도록 만들어야 했죠. 마이크로소프트, 구글, 아마존과 같은 클라우드 서비스 사업자는 몇 번의 클릭만으로 저렴하게 애플리케이션을 실행할 수 있도록 하여 전통적인 데이터 센터 기 반 서버를 배포하는 것의 위험을 낮췄습니다. 더불어, 관리형 데이터베이스 서비스, 네트워크 인프라, 메시지 큐와 같이 이전에는 조직 내부에서 통제해야 했던 다양한 서비스도 제공하기 시작했습니다.
클라우드 사업자의 제품을 사용하는 한 가지 이점은 조직이 비즈니스에 중요한 코드에만 집중하게 해준다는 점입니다. 이러한 제품은 비용과 시간을 투입해야만 하는 하드웨어 구현이나 전문성이 떨어질 수밖에 없는 서비스 운영을 대신 해줍니다.
클라우드 플랫폼의 이점을 최대한 활용하기 위해 개발자는 모놀리스monolith로 개발된 애플리케이션을 어떻게 재설계할지 살펴봐야 합니다. 모놀리스 애플리케이션을 클라우드 사업자 플랫폼 위에 배포하는 경우 다음과 같은 문제에 직면할 수 있기 때문입니다.
● 전통적으로 모놀리스를 확장하는 것은 모놀리스가 사용할 수 있는 리소스의 수를 증가시키는 것을 의미합니다. 이를 수직적 확장이라고 하며, 클라우드 서비스 사업자가 제공할 수 있는 리소스의 최대 크기까지만 가능합니다.
● 모놀리스의 신뢰성을 개선하는 것은 실패가 여러 번 발생하더라도 문제 없도록 여러 개의 인스턴스를 배포하는 것을 의미합니다. 이를 수평적 확장이라 하며, 이를 통해 다운타임을 회피합니다. 모놀리스의 크기에 따라 다르지만 보통은 비용의 증가로 이어집니다. 모놀리스가 제공하는 컴포넌트 전체를 필요로 하는 상황이 아니라면 리소스가 낭비될 수 있습니다.
이처럼 클라우드 플랫폼 기반으로 애플리케이션을 만들 때 생기는 문제들은 서비스 기반 아키텍처 또는 마이크로서비스 아키텍처, 즉 개발자가 제한적인 범위 내에서 느슨하게 연결된 서비스들로 애플리케이션을 구성할 수 있는 아키텍처를 채택하도록 만듭니다.
[그림 1-1]의 왼쪽 도식은 애플리케이션을 구성하는 모든 서비스가 강하게 결합되어 있고 동일한 경계 내에서 작동하는 모놀리스 아키텍처를 나타냅니다. 반면 오른쪽 도식은 서비스들이 느슨하게 결합되어 있고 각 서비스가 각자의 경계 내에서 독립적으로 작동하는 마이크로서비스 아키텍처를 나타냅니다.
마이크로서비스 아키텍처 기반의 애플리케이션은 더 높은 부하를 처리해야 할 수도 있는 컴포넌트에만 선택적으로 확장성을 제공하여 수평적 확장이 더 매력적인 옵션이 되도록 합니다. 물론 새로운 아키텍처는 도입에 따른 득실과 해결해야 하는 다음과 같은 과제를 가지고 있습니다.
●이전에는 없었던 지연이 발생할 수 있고 애플리케이션이 예상치 못한 방식으로 실패할 수 있습니다.
● 서비스 간의 의존성 때문에 오류가 발생할 수 있으므로 애플리케이션은 연쇄적인 오류를 최소화하도록 방어적으로 만들어져야 합니다.
● 서비스 전반에 걸친 설정과 비밀값의 관리가 어렵습니다.
● 서비스 오케스트레이션이 복잡해집니다.
이러한 아키텍처 관점의 변화로 각 애플리케이션이 담당하는 범위가 상당히 줄어들어 개별 컴포넌트 확장의 필요성을 쉽게 이해할 수 있게 되었습니다. 하지만 독립적으로 작동하는 서비스 수의 증가와 복잡도의 상승은 전통적인 운영팀에게 새로운 숙제가 되고 있으며 조직은 이런 변화에 적응해야만 합니다.
2. 데브옵스로의 전환
마이크로서비스로의 전환은 개발팀 구성 방식의 변화를 불러왔습니다. 하나의 대형 팀이 모놀리스 앱을 관리하던 것 대신, 여러 팀이 마이크로서비스를 관리하게 되었습니다. 전통적인 개발 방식에서는 개발과 운영이 분리되었지만, 마이크로서비스에서는 팀 간 협업이 중요해져 변화에 빠르게 대응할 수 있습니다. 이로써 규모가 커져도 효율적인 개발과 운영이 가능해졌죠.
결과적으로, 이러한 문제를 해결하기 위해 전통적인 개발 및 운영 조직을 하이브리드 형태의 데브옵스팀으로 변화시키는 추세가 나타났습니다. 데브옵스 접근 방식을 통해 개발자들은 코드 작성부터 운영까지의 모든 과정을 담당하며, 소프트웨어 수명 주기를 효율적으로 관리할 수 있게 되었습니다. 물론 이러한 접근 방식은 소프트웨어 개발을 가속화할 수 있게 해주었지만 여전히 해결해야 할 과제가 존재합니다.
● 개발 조직 전반에 걸쳐 높아진 의존성은 전체 애플리케이션을 완벽히 파악하고 있는 사람이 없다는 것을 의미합니다.
● 조직 전반에 걸친 변경 사항을 추적하는 것은 어려운 일입니다. 이것은 ‘장애의 원인이 무엇인가?’라는 질문에 대한 답을 찾는 것을 더 어렵게 만듭니다.
따라서 각 팀은 훨씬 더 많은 도구에 익숙해져야 합니다. 하지만 그러다 보면 도구를 사용하는 목적이 아니라 도구 그 자체에 매몰되어 버리는 경우도 생깁니다. 또한 데브옵스의 빠른 적용은 새로운 문제를 야기합니다. 조직이 관리하는 시스템 전반에 관한 가시성이 충분히 확보되지 않으면 개발 조직은 발생한 문제의 근본 원인을 찾는 데 어려움을 겪게 됩니다. 이것은 더 자주, 더 오랫동안 장애가 발생하는 상황을 만들 수 있고 조직 구성원의 건강과 행복에 심각한 악영향을 끼칠 수 있습니다. 이제부터 변화하는 환경에 적응하기 위해 시스템을 관찰하는 방법이 어떻게 진화했는지 살펴봅시다.
3. 관찰 가능성의 역사
컴퓨터의 역할을 이해하고 특히 소프트웨어 작업을 파악하는 것은 흥미로우면서도 도전적인 과제입니다. 시스템이 어떻게 작동하는지 이해하기 위한 여정은 2000년대 초반부터 여러 번의 시행착오를 반복하며 발전했습니다. 이 문제를 풀기 위해 시스템 모니터링, 로그 관리, 애플리케이션 성능 측정과 같은 여러 가지 시장이 생겨났죠.
늘 그렇듯 어려움에 도전하는 사람에게 기회의 문이 열립니다. 이 시기에 셀 수 없이 많은 벤더와 오픈 소스 프로젝트가 자체 시스템을 이용하여 서비스를 만들고 운영하는 사람들을 돕겠다며 출사표를 던졌습니다. 하지만 제어 이론에서 시작된 ‘관찰 가능성’이라는 용어는 근래에 들어서야 소프트웨어 산업에서 이야기되기 시작했습니다. 위키피디아에는 관찰 가능성이 다음과 같이 정의되어 있습니다.
제어 이론에서 관찰 가능성은 시스템의 외부 출력 정보로부터 시스템의 내부 상태를 얼마나 잘 추론할 수 있는지를 측정하는 척도
관찰 가능성은 수년간의 경험과 시행착오에서 얻은 교훈을 바탕으로 만들어졌으며, 이전에 사용된 관찰 모델이 진화한 결과물입니다. 따라서 현재의 관찰 가능성을 더 잘 이해하려면 클라우드 네이티브 애플리케이션 개발자가 사용하고 있는 방법이 어디서 유래했는지, 또 어떻게 변화 했는지를 이해하는 것이 중요합니다. 지금부터 세 가지 주제를 통해 살펴보고자 합니다.
1) 중앙 집중식 로깅
개발자라면 모두가 아는 "Hello World!"는 사실 관찰 가능성의 형태를 띱니다. 터미널 화면에 문자열을 출력하는 건 코드가 잘 작동하고 있다는 걸 사용자에게 전하는 가장 빠른 방법이죠
코드가 정상적으로 작동하지 않을 때 여전히 필자가 가장 즐겨 사용하는 디버깅 방법은 구문을 출력하는 것입니다. 예전에 여러 대의 서버를 사용하는 분산 애플리케이션의 트러블슈팅 troubleshooting 과정에서 이 방법을 사용한 적이 있습니다. 익숙하지 않은 코드 편집기를 사용하다 생긴 오타로 인해 서비스 중 하나가 일시적으로 중단되었던 것이라 자랑할 만한 일은 아니지만요.
구문을 출력하는 것은 단순하고 훌륭한 디버깅 방법이지만 확장성에는 한계가 있습니다. 애플리케이션이 충분히 크거나 여러 시스템에 걸쳐 분산되어 있을 때 개별 서버의 로그를 검색하는 것은 비현실적입니다. 심지어 임시로 생성된 서버에서 애플리케이션이 작동할 가능성도 있기 때문에 로그가 유실되는 상황도 발생합니다. 이런 이유들로 인해 영구 스토리지 기반으로 구성된 검색 가능한 중앙 저장소에 로그를 쌓을 필요가 생겼는데, 이것이 바로 중앙화된 로깅의 시작입니다.
2) 메트릭과 대시보드
메트릭은 관찰 가능성 세계에서 사용할 수 있는 도구 중 가장 잘 알려진 도구일 것입니다. 온도계의 온도, 자동차 주행 거리계의 속도, 시계의 시간 등이 대표적인 메트릭입니다. 인간은 무언가를 측정하거나 정량화하는 것을 좋아합니다. 컴퓨팅 초창기부터 컴퓨팅 리소스가 어떻게 활용되는지 추적하는 것은 다중 사용자 환경의 시스템이 모든 사용자에게 훌륭한 경험을 제공하는 데 있어 매우 중요한 것이었습니다.
오늘날 소프트웨어 개발에서 애플리케이션과 시스템의 성능을 일련의 메트릭을 통해 측정하는 것은 일반적인 일이 되었습니다. 이 메트릭은 시스템의 상태를 모니터링할 때 필요한 그래프로 변환되어 의미 있는 시각화를 제공합니다.
또한 오류 비율이 수용 가능한 규모를 넘어서는 것과 같이 임계치에 도달했음을 알려줄 경고를 설정할 때 메트릭이 사용됩니다. 어떤 환경에서는 애플리케이션 인스턴스의 수를 늘리거나 잘못된 배포를 롤백rollback하는 것처럼 시스템의 변화에 대한 대응으로 워크플로를 자동화하기 위해 메트릭을 사용하기도 합니다.
메트릭을 다루는 대표적 오픈 소스로는 프로메테우스, 그라파나 등이 있습니다. (이미지 출처: prometheus 공식 사이트)
3) 추적과 분석
애플리케이션을 추적한다는 것은 애플리케이션 코드를 실행하고 원하는 작업을 제대로 수행하는지 확인할 수 있는 기능을 갖는 것을 의미합니다. 항상 그런 것은 아니지만 개발 진행 과정에서 GDB나 파이썬의 PDB 같은 디버거debugger의 도움을 받아 문제를 추적하는 것이 대표적입니다. 하지만 이 방법은 네트워크를 통해 다수의 서비스가 서로 다른 서버에서 작동하는 애플리케이션을 디버깅할 때는 사용하기 어렵습니다.
구글 연구원들은 이러한 상황에서 사용할 수 있도록 내부적으로 만든 대규모 분산 추적 시스템인 Dapper에 관한 백서를 발간했습니다. 백서는 분산 시스템 디버깅의 어려움뿐만 아니라 이 문제를 다루기 위해 사용했던 여러 접근 방법을 담고 있습니다. 이 연구 내용은 오늘날 우리가 사용하는 분산 추적 시스템의 근간입니다.
이 글은 도서 『관찰 가능성 엔지니어링』 내용에서 일부를 발췌, 작성하였습니다. 관찰 가능성이 발전하며 생겨난 수많은 도구와 표준은 산업과 오픈 소스 커뮤니티의 파편화를 초래했습니다. 이로 인해 환경의 차이를 보정하고 여러 도구의 기능 차이를 관리하는 것이 어려웠죠. 이런 문제를 해결하고자 여러 개발자와 기업이 모여 오픈 텔레메트리OpenTelemetry 프로젝트를 만듭니다.
오픈 텔레메트리는 클라우드 네이티브 환경에서의 분산 추적과 모니터링을 위한 표준화된 API와 도구를 제공하여, 애플리케이션의 가시성을 향상시키고 성능을 관리하는 데 도움을 주고자 합니다. 이 프로젝트는 기존에 존재하던 OpenTracing과 OpenCensus 프로젝트의 강점을 통합하여, 모니터링과 추적을 위한 표준화된 솔루션을 제공하려는 목적에서 시작되었습니다.
관찰 가능성 엔지니어링을 돕는 오픈 텔레메트리는 무엇이며, 실시간으로 시스템의 동작을 이해하고 문제를 예방하며 효율적인 운영 하는 방법은 무엇일까요? 『관찰 가능성 엔지니어링』에서 상세히 알아볼 수 있습니다.
이전 글 : 테크니컬 라이터는 무슨 일을 하나요?
최신 콘텐츠