2018.03.14

마이크로서비스 모니터링의 5가지 원칙

Loris Degioanni | InfoWorld
필자는 7살때부터 프로그래밍을 시작했다(컴퓨터가 없어 종이에 썼다는 점은 논외로 하고). 필자가 초기에 배운 한 가지는 소프트웨어 개발은 (인생과 마찬가지로) 타협의 연속이란 점이다. 기업과 개발자는 늘 성능 또는 간소함, 혁신 또는 관리 용이성 중에서 하나를 선택한다.

그러나 컨테이너와 도커가 인기를 얻고 마이크로서비스가 부상하면서 애플리케이션 개발은 각각 자체 프로세스에서 실행되면서 API와 같은 메커니즘으로 소통하는 작은 서비스의 집합으로 바뀌었다. 마이크로서비스의 장점은 명확하다. 소프트웨어 개발과 배포 속도의 비약적 향상이다. 이를 통해 비용을 절감하고 주변 조건만 맞춰준다면 기업에 경쟁 우위를 제공한다.

Image Credit : GettyImagesBank

필자는 지난 몇 년 동안 많은 데브옵스 전문가들과 대화를 나누면서 이들이 직면한 여러 가지 과제를 알게 됐다. 이러한 대화를 통해 확실히 드러난 것은 기업은 마이크로서비스를 도입할 때 성능 및 보안 위생 측면에서 소프트웨어 관리 방식에 대한 사고의 전환이 필요하다는 점이다. 마이크로서비스를 사용한다는 것은 소프트웨어 관리, 구체적으로 기업에서 인프라, 애플리케이션 및 데이터 모니터링을 다루는 방식의 변화를 의미한다. 변화하지 않는 기업은 문제 해결은 말할 필요도 없고 마이크로서비스의 성능을 파악하기도 어렵게 된다. 마이크로서비스 모니터링을 더 현명하고 기민하게, 무엇보다 더 효과적으로 하기 위한 5가지 방법을 소개한다.

컨테이너와 컨테이너 내부에서 실행되는 요소 모니터링
컨테이너는 마이크로서비스의 빌딩 블록으로, 개발자 노트북부터 클라우드에 이르기까지 넓은 범위를 포괄하는 블랙 박스다. 그러나 컨테이너 내부에 대한 시야를 확보하지 않으면 서비스 모니터링이나 문제 해결 같은 기본적인 기능을 수행하기 어렵다. 컨테이너 안에서 무엇이 실행되는지, 애플리케이션과 코드의 성능이 어느 정도인지, 중요한 맞춤형 측정값을 생성하고 있는지 여부 등을 알아야 한다.

또한 기업의 규모가 커지고 수천 개의 호스트를 수천 수만의 컨테이너와 함께 실행하게 되면 배포에 많은 비용이 들고 오케스트레이션은 악몽이 될 수 있다. 컨테이너 모니터링을 제대로 하기 위해서는 몇 가지 선택안이 있다.

개발자에게 코드에 직접 기능을 넣도록 요청하거나 사이드카 컨테이너를 실행하거나 범용 커널 수준 계측을 활용해서 모든 애플리케이션 및 컨테이너 활동을 보는 것이다. 각각의 방법에는 장단점이 있으므로 가장 중요한 목표를 달성할 수 있는 방법이 무엇인지 잘 살펴봐야 한다. 가장 중요한 점은 VM의 정적 워크로드에서 작동했던 예전의 방법은 더 이상 통하지 않는다는 것이다.

오케스트레이션 시스템 활용
가장 중요한 프로세스 중 하나는 예를 들어 각 서비스의 응답 시간과 같이 기능 또는 서비스와 연결된 모든 컨테이너에서 오는 집계된 정보를 추적하는 것이다. 이러한 종류의 즉석 집계는 예를 들어 어느 서비스의 컨테이너가 할당된 CPU 몫 이상의 리소스를 사용하고 있는지를 파악하기 위한 인프라 수준 모니터링에도 적용된다.

개발팀의 일원이라면 쿠버네티스, 메소스피어(Mesosphere) DC/OS 또는 도커 스웜(Docker Swarm)과 같은 오케스트레이션 시스템을 활용해서 마이크로서비스를 정의하고 배포된 각 서비스의 현재 상태를 파악할 수 있다. 데브옵스팀의 일원이라면 시스템 알림을 재정의해서 서비스 경험 모니터링에 최대한 근접해야 한다. 알림은 애플리케이션 상태 평가의 제1 방어선이기 때문이다. 모니터링 시스템이 오케스트레이션 메타데이터를 사용하고 컨테이너와 애플리케이션 데이터를 동적으로 집계하고 서비스별로 모니터링 메트릭을 계산하는 컨테이너 네이티브 시스템이라면 이 프로세스가 좀더 쉬워진다.

오케스트레이션 툴에 따라 다양한 세부 계층이 존재할 수 있다. 쿠버네티스는 네임스페이스, 레플리카셋(ReplicaSet), 팟(Pod) 및 일부 컨테이너를 제공한다. 서비스 컨테이너의 물리적인 배포 방식에 관계없이 논리적으로 문제를 해결하기 위해서는 이러한 계층에서의 집계가 반드시 필요하다.

탄력적인 다중 위치 서비스 준비
컨테이너 네이티브 환경은 빠르게 바뀐다. 이와 같은 종류의 역동성은 모든 모니터링 시스템에서 약점을 노출한다. 수동으로 메트릭을 정의하고 튜닝하는 방식은 20~30개의 컨테이너에서는 통할 수 있지만, 마이크로서비스 모니터링은 탄력적인 서비스와 함께 사람의 개입 없이 확장과 축소가 가능해야 한다. 따라서 모니터링을 위한 컨테이너가 포함된 서비스를 수동으로 정의해야 한다면, 쿠버네티스 또는 메소스에 의해 하루 중에 가동되는 신규 컨테이너를 놓칠 가능성이 높다. 같은 맥락에서, 현재 조직에서 신규 코드를 구축해 배포할 때 맞춤형 통계 엔드포인트를 설치하는 경우 개발자가 도커 레지스트리에서 기본 이미지를 가져오므로 모니터링이 복잡해진다.

또한 현재 조직에서 마이크로서비스를 사용 중이라면 여러 데이터센터 또는 여러 클라우드를 포괄하는 모니터링이 필요하다. 예를 들어 AWS 클라우드워치(CloudWatch)는 마이크로서비스가 AWS로 제한될 때만 유용하다.

API 모니터링
마이크로서비스 환경의 국제 공통어인 API는 다른 팀에 노출되는 유일한 서비스 요소다. 공식적인 SLA가 정의되지 않은 경우 API의 응답 및 일관성이 내부 서비스 수준 협약이 될 수도 있다. 이는 API 모니터링이 표준적인 2진 양방향 검사 이상의 기능을 해야 함을 의미한다.

마이크로서비스 사용자는 시간의 함수로 가장 빈번하게 사용되는 엔드포인트를 파악해 두는 것이 좋다. 이를 통해 서비스 사용에서 무엇이 변경되었는지, 그 이유가 설계 변경인지 사용자 변경인지를 알 수 있다. 가장 느린 서비스 엔드포인트를 찾으면 최적화가 필요한 영역을 파악할 수 있다. 일반적으로 개발자만 사용하는, 시스템 전반의 서비스 호출을 추적할 수 있는 기능은 조직에서 전체적인 사용자 경험을 이해하는 데 도움이 된다. 또한 이러한 형태의 API 모니터링을 통해 마이크로서비스 환경에 대한 인프라 및 애플리케이션 기반의 시야로 정보를 세분화할 수 있다.

모니터링을 조직 구조에 매핑
마이크로서비스는 개발자와 기업 조직이 소프트웨어 인프라를 모니터링하고 보호하는 방식의 포괄적인 변화를 예고하는 신호지만, 소프트웨어 모니터링에서 인적 측면을 간과해서는 안 된다. 조직이 이 새로운 소프트웨어 아키텍처 접근 방법에서 이점을 취하고자 한다면 팀 스스로 마이크로서비스의 특징을 모방해야 한다. 즉, 높은 자율성을 갖되 전략적 목표에 집중하는, 더 작고 더 느슨하게 연결된 팀이 되어야 한다.

각 팀은 사용하는 언어, 버그 해결 또는 운영 책임에 대해 과거보다 더 높은 통제력을 갖는다. 그렇게 되면 각 마이크로서비스팀이 알림과 메트릭, 대시보드를 격리할 수 있도록 하면서도 운영 팀에는 시스템 전반에 대한 전역적 시야를 제공하는 모니터링 플랫폼을 만들 수 있다.

소프트웨어 모니터링에서의 몇 가지 기본적인 변경을 통해 마이크로서비스의 속도와 효율성, 잠재적인 비용 절감 효과를 더 높일 수 있다. 마이크로서비스에 대한 향상된 모니터링은 견실한 성능과 더 높은 최종 사용자 만족도로 이어진다. 제대로 보정된 마이크로서비스는 더 짧은 시간 내에 더 많은 기능을 제공하는 서비스 제공의 선순환을 실현한다.  editor@itworld.co.kr


2018.03.14

마이크로서비스 모니터링의 5가지 원칙

Loris Degioanni | InfoWorld
필자는 7살때부터 프로그래밍을 시작했다(컴퓨터가 없어 종이에 썼다는 점은 논외로 하고). 필자가 초기에 배운 한 가지는 소프트웨어 개발은 (인생과 마찬가지로) 타협의 연속이란 점이다. 기업과 개발자는 늘 성능 또는 간소함, 혁신 또는 관리 용이성 중에서 하나를 선택한다.

그러나 컨테이너와 도커가 인기를 얻고 마이크로서비스가 부상하면서 애플리케이션 개발은 각각 자체 프로세스에서 실행되면서 API와 같은 메커니즘으로 소통하는 작은 서비스의 집합으로 바뀌었다. 마이크로서비스의 장점은 명확하다. 소프트웨어 개발과 배포 속도의 비약적 향상이다. 이를 통해 비용을 절감하고 주변 조건만 맞춰준다면 기업에 경쟁 우위를 제공한다.

Image Credit : GettyImagesBank

필자는 지난 몇 년 동안 많은 데브옵스 전문가들과 대화를 나누면서 이들이 직면한 여러 가지 과제를 알게 됐다. 이러한 대화를 통해 확실히 드러난 것은 기업은 마이크로서비스를 도입할 때 성능 및 보안 위생 측면에서 소프트웨어 관리 방식에 대한 사고의 전환이 필요하다는 점이다. 마이크로서비스를 사용한다는 것은 소프트웨어 관리, 구체적으로 기업에서 인프라, 애플리케이션 및 데이터 모니터링을 다루는 방식의 변화를 의미한다. 변화하지 않는 기업은 문제 해결은 말할 필요도 없고 마이크로서비스의 성능을 파악하기도 어렵게 된다. 마이크로서비스 모니터링을 더 현명하고 기민하게, 무엇보다 더 효과적으로 하기 위한 5가지 방법을 소개한다.

컨테이너와 컨테이너 내부에서 실행되는 요소 모니터링
컨테이너는 마이크로서비스의 빌딩 블록으로, 개발자 노트북부터 클라우드에 이르기까지 넓은 범위를 포괄하는 블랙 박스다. 그러나 컨테이너 내부에 대한 시야를 확보하지 않으면 서비스 모니터링이나 문제 해결 같은 기본적인 기능을 수행하기 어렵다. 컨테이너 안에서 무엇이 실행되는지, 애플리케이션과 코드의 성능이 어느 정도인지, 중요한 맞춤형 측정값을 생성하고 있는지 여부 등을 알아야 한다.

또한 기업의 규모가 커지고 수천 개의 호스트를 수천 수만의 컨테이너와 함께 실행하게 되면 배포에 많은 비용이 들고 오케스트레이션은 악몽이 될 수 있다. 컨테이너 모니터링을 제대로 하기 위해서는 몇 가지 선택안이 있다.

개발자에게 코드에 직접 기능을 넣도록 요청하거나 사이드카 컨테이너를 실행하거나 범용 커널 수준 계측을 활용해서 모든 애플리케이션 및 컨테이너 활동을 보는 것이다. 각각의 방법에는 장단점이 있으므로 가장 중요한 목표를 달성할 수 있는 방법이 무엇인지 잘 살펴봐야 한다. 가장 중요한 점은 VM의 정적 워크로드에서 작동했던 예전의 방법은 더 이상 통하지 않는다는 것이다.

오케스트레이션 시스템 활용
가장 중요한 프로세스 중 하나는 예를 들어 각 서비스의 응답 시간과 같이 기능 또는 서비스와 연결된 모든 컨테이너에서 오는 집계된 정보를 추적하는 것이다. 이러한 종류의 즉석 집계는 예를 들어 어느 서비스의 컨테이너가 할당된 CPU 몫 이상의 리소스를 사용하고 있는지를 파악하기 위한 인프라 수준 모니터링에도 적용된다.

개발팀의 일원이라면 쿠버네티스, 메소스피어(Mesosphere) DC/OS 또는 도커 스웜(Docker Swarm)과 같은 오케스트레이션 시스템을 활용해서 마이크로서비스를 정의하고 배포된 각 서비스의 현재 상태를 파악할 수 있다. 데브옵스팀의 일원이라면 시스템 알림을 재정의해서 서비스 경험 모니터링에 최대한 근접해야 한다. 알림은 애플리케이션 상태 평가의 제1 방어선이기 때문이다. 모니터링 시스템이 오케스트레이션 메타데이터를 사용하고 컨테이너와 애플리케이션 데이터를 동적으로 집계하고 서비스별로 모니터링 메트릭을 계산하는 컨테이너 네이티브 시스템이라면 이 프로세스가 좀더 쉬워진다.

오케스트레이션 툴에 따라 다양한 세부 계층이 존재할 수 있다. 쿠버네티스는 네임스페이스, 레플리카셋(ReplicaSet), 팟(Pod) 및 일부 컨테이너를 제공한다. 서비스 컨테이너의 물리적인 배포 방식에 관계없이 논리적으로 문제를 해결하기 위해서는 이러한 계층에서의 집계가 반드시 필요하다.

탄력적인 다중 위치 서비스 준비
컨테이너 네이티브 환경은 빠르게 바뀐다. 이와 같은 종류의 역동성은 모든 모니터링 시스템에서 약점을 노출한다. 수동으로 메트릭을 정의하고 튜닝하는 방식은 20~30개의 컨테이너에서는 통할 수 있지만, 마이크로서비스 모니터링은 탄력적인 서비스와 함께 사람의 개입 없이 확장과 축소가 가능해야 한다. 따라서 모니터링을 위한 컨테이너가 포함된 서비스를 수동으로 정의해야 한다면, 쿠버네티스 또는 메소스에 의해 하루 중에 가동되는 신규 컨테이너를 놓칠 가능성이 높다. 같은 맥락에서, 현재 조직에서 신규 코드를 구축해 배포할 때 맞춤형 통계 엔드포인트를 설치하는 경우 개발자가 도커 레지스트리에서 기본 이미지를 가져오므로 모니터링이 복잡해진다.

또한 현재 조직에서 마이크로서비스를 사용 중이라면 여러 데이터센터 또는 여러 클라우드를 포괄하는 모니터링이 필요하다. 예를 들어 AWS 클라우드워치(CloudWatch)는 마이크로서비스가 AWS로 제한될 때만 유용하다.

API 모니터링
마이크로서비스 환경의 국제 공통어인 API는 다른 팀에 노출되는 유일한 서비스 요소다. 공식적인 SLA가 정의되지 않은 경우 API의 응답 및 일관성이 내부 서비스 수준 협약이 될 수도 있다. 이는 API 모니터링이 표준적인 2진 양방향 검사 이상의 기능을 해야 함을 의미한다.

마이크로서비스 사용자는 시간의 함수로 가장 빈번하게 사용되는 엔드포인트를 파악해 두는 것이 좋다. 이를 통해 서비스 사용에서 무엇이 변경되었는지, 그 이유가 설계 변경인지 사용자 변경인지를 알 수 있다. 가장 느린 서비스 엔드포인트를 찾으면 최적화가 필요한 영역을 파악할 수 있다. 일반적으로 개발자만 사용하는, 시스템 전반의 서비스 호출을 추적할 수 있는 기능은 조직에서 전체적인 사용자 경험을 이해하는 데 도움이 된다. 또한 이러한 형태의 API 모니터링을 통해 마이크로서비스 환경에 대한 인프라 및 애플리케이션 기반의 시야로 정보를 세분화할 수 있다.

모니터링을 조직 구조에 매핑
마이크로서비스는 개발자와 기업 조직이 소프트웨어 인프라를 모니터링하고 보호하는 방식의 포괄적인 변화를 예고하는 신호지만, 소프트웨어 모니터링에서 인적 측면을 간과해서는 안 된다. 조직이 이 새로운 소프트웨어 아키텍처 접근 방법에서 이점을 취하고자 한다면 팀 스스로 마이크로서비스의 특징을 모방해야 한다. 즉, 높은 자율성을 갖되 전략적 목표에 집중하는, 더 작고 더 느슨하게 연결된 팀이 되어야 한다.

각 팀은 사용하는 언어, 버그 해결 또는 운영 책임에 대해 과거보다 더 높은 통제력을 갖는다. 그렇게 되면 각 마이크로서비스팀이 알림과 메트릭, 대시보드를 격리할 수 있도록 하면서도 운영 팀에는 시스템 전반에 대한 전역적 시야를 제공하는 모니터링 플랫폼을 만들 수 있다.

소프트웨어 모니터링에서의 몇 가지 기본적인 변경을 통해 마이크로서비스의 속도와 효율성, 잠재적인 비용 절감 효과를 더 높일 수 있다. 마이크로서비스에 대한 향상된 모니터링은 견실한 성능과 더 높은 최종 사용자 만족도로 이어진다. 제대로 보정된 마이크로서비스는 더 짧은 시간 내에 더 많은 기능을 제공하는 서비스 제공의 선순환을 실현한다.  editor@itworld.co.kr


X