OPENMARU APM 을 통한 컨테이너 환경 모니터링
안녕하세요.
오픈마루 클라우드 서비스 팀 김석영입니다.
이번 포스팅 주제는 “컨테이너 환경에서의 모니터링” 입니다.
쿠버네티스 환경에서 애플리케이션 성능과 장애 대응 데모
데모 요약 : OPENMARU APM을 통한 Application 모니터링 및 장애 대응 방법 소개
데모 내용 : 흩어져 있고 쉽게 사라지는 모든 컨테이너를 모니터링 하여 장애 발생 시 원인을 정확히 파악할 수 있는 데모영상입니다.
OPENMARU APM 솔루션으로 장애 발생 원인과 Troubleshooting으로 어플리케이션을 안정적으로 운영할 수 있습니다.
컨테이너, 핵심 개념 먼저(컨테이너 환경의 개요)
쿠버네티스를 처음 접했을 때의 난관은 컨테이너란 무엇인가? 를 이해하는 것이었습니다.
컨테이너라고 검색하면 Docker라고 검색이 되고, Docker 하면 컨테이너라고 나오는데…
그렇다면 컨테이너? 컨테이너는 도커인가?
컨테이너, 시작부터 혼란의 연속이였습니다.
“그래서 컨테이너가 뭔데?”
컨테이너는 리눅스의 네임스페이스라는 개념에서 출발하였고, 점점 발전하면서 보시는 것과 역사도 같이 오래되었죠.
네임스페이스(Namespace)란?
리눅스 Kernel의 다양한 Features 중 한 가지 입니다. 처음 출발은 Linux 명령어 중 Chroot()에서 시작되었습니다.
“/” 를 루트(뿌리) 디렉토리라고 부르고, 최상위 디렉토리이죠.
간단한 예시로, FTP를 통해 파일을 업로드하는 것을 설명드리겠습니다.
일반적으로 파일을 업로드/다운로드를 하기위해 다음과 같은 절차를 거쳐야 할 것입니다.
FTP 클라이언트를 접속 → 사용자 로그인 → 원하는 경로 지정 → 파일 업로드
헌데, 추가적인 조치를 취하지 않는 이상, 기본적으로는 일반 계정임에도 “/” 최상위 경로에 접근이 가능하죠
이렇게 되면 불필요한 접근까지 허용하는 상황입니다.
따라서, 운영상 보안에 취약하다라고 판단이 되어
사용자가 접근하는 경로 상단은 접근하지 못하게 조치를 하는게 일반적입니다.
여기서 chroot가 활용하여 아래 그림처럼 /home/joe 라는 경로가 “/”가 되게 하여 더이상 상단으로 접근할 수가 없게끔 해주었죠.
위와 같이, 네임스페이스는 같은 OS 안에서 별개의 독립적인 공간을 만들고 싶다! 하여 나온 Kernel의 기능입니다.
같은 Host OS 안에서도 별개의 독립된 공간을 갖고자 하는 기술인 것이죠.
여기에 cgroup(Control Group)이라는 개념이 더해지면서 각 프로세스가 독립된 공간을 가지고, 호스트의 자원을 나눠서 사용할 수 있게 된 것이죠.
이렇게 컨테이너의 기본 형태가 갖춰지게 된 것입니다.
앞서 설명이 길었지만…
한 줄 요약하면, 컨테이너란 같은 Host OS의 자원을 분리하여 독립적인 공간을 만들고 그 독립된 공간에 애플리케이션(서비스)를 담는 기술이라고 이해할 수 있었습니다.
도커는 이러한 컨테이너라는 개념을 도입하고 사용자들이 사용할 수 있게끔 인터페이스를 제공해준 기술이였던 것이죠.
네임스페이스라는 기술만 가지고는 사용자가 사용할 수 없었으니까요.
이제…컨테이너는 이해가 된 것 같습니다.
그런데, 이제는 컨테이너 오케스트레이션이라는 용어가 나오네요.
오케스트레이션? 그게 뭐지?
오케스트레이션…잘 모르겠습니다. 하지만 오케스트라는 익숙한 단어로 알고 있었죠.
Orchestra + 명사 접미사 = Orchestration
오케스트라의 지휘자를 생각하니 그 뜻을 이해할 수 있었습니다.
오케스트라는 여러 악기 집단으로 구성되고
지휘자는 어떤 악기가 언제, 어떻게 연주할지를 지휘하죠.
또한 첼로, 바이올린, 트럼펫… 등등 여러 악기 그룹에서 바이올린 하나가 고장났다고 가정을 해보면,
굉장히 급박한 상황입니다. 재빨리 새로운 바이올린으로 교체해서 다시 연주를 이어나갈 수 있게 해주어야 합니다.
지휘자는 이렇게 모든 악기, 흐름을 지휘 감독합니다.
이러한 일련의 과정을 오케스트레이션이라고 보는 것이죠.
그래서 그 지휘자 역할을 해줄 대표적인 녀석이 Kubernetes 라고 생각하니 이해가 되었습니다.
한 줄 요약하면, 컨테이너 오케스트레이션이란 컨테이너의 생성, 삭제, 배포, 스케일링 등 컨테이너의 모든 라이프사이클을 관리, 감독하는 도구라고 볼 수 있습니다.
(추가로, Kubernetes를 Red Hat이 엔터프라이즈 버전으로 커스터마이징한 제품이 OpenShift라고 보시면 되겠습니다.)
오케스트레이션? 그게 뭐지?
IT 인프라 환경을 들여다보면,
“우리가 개발한 좋은 애플리케이션을 원활하게, 문제 없이 사용자에게 서비스” 한다는 궁극적인 목표는 변함이 없을 것입니다.
자원을 효율적으로 쓰고자 했던 목표 + 안정적인 서비스에 대한 목표
이 두 가지 목표를 계속하여 고민하면서 연구해나가다보니 컨테이너라는 개념이 도입이 된 것이고, 이제는 컨테이너가 곧 새로운 트렌드가 되어 가는 과정입니다.
그렇다면, 원활하고 문제가 없는 서비스를 위해서는 예기치 못한 문제에 대한 대비를 하여야 합니다.
또한, 문제를 직면했을 때 최대한 빠르게 처리를 할 수 있어야 할 것입니다.
그래서 모니터링이 필요한 것이겠죠.
컨테이너 환경에서의 모니터링
그렇다면, 오픈소스 모니터링 도구를 이용하여 간단하게 모니터링을 해볼까요?
시스템의 자원을 모니터링 하고나서 보니, 애플리케이션의 동작을 확인할 수가 없었습니다.
정작 중요한 애플리케이션이 정상적으로 서비스되고 있는지를 보고 싶은데 아쉬운 부분이죠.
컨테이너 환경에서 APM을 통한 모니터링
OPENMARU APM를 이용하여 컨테이너 환경에서 애플리케이션에 대한 모니터링은 어떻게 진행되는지 보고자 합니다.
자원 모니터링 현황은?
APM 에서 확인하는 애플리케이션 현황은?
어떤 트랜잭션이 발생하고, 어떤 트랜잭션이 느린지 바로 알아볼 수 있습니다.
총 8초가 걸린 요청 중 selectEntrprsMberList() 메소드 혼자 6초를 사용했음을 확인 할 수 있네요!
APM 에서 컨테이너 모니터링 항목에 대한 커스터마이징 ?
내가 보고싶은 것만 골라서 한눈에 볼 수도 있습니다.
저는 오픈소스 모니터링 툴에서 본 자원 모니터링에 더해서 애플리케이션의 성능이 어떻게 나오는지에 대한 지표들만 골라봤습니다.
APM 을 이용한 컨테이너 환경에서 문제 원인 찾기
예시로 두 가지 문제 상황을 보여드리겠습니다.
DB Fetch 건수가 많아서 문제가 발생한 컨테이너
첫 번째, DB Fetch 수가 많은 경우 입니다.
OPENMARU APM의 [이벤트 목록] 탭만 봤는데도 DB Fetch에 대한 Alert을 받을 수 있었습니다.
또한, Heap 메모리 사용량을 봤을 때, 비정상적인 패턴을 보이고 있네요.
APM 에서 지연이 발생하는 애플리케이션 부분 찾기
두 번째, 굉장히 빈번하게 발생하는 이슈로
HTTP Request에 대한 처리가 늦어지다보니 쌓이는 Pending Transaction 이슈 입니다.
메인 화면만 봐도 불이 나고 있네요.
이런 경우는 확실하게 문제임을 알면서도, 너무나도 다양한 요인에 의해 문제가 발생할 수 있기 때문에 명확한 원인을 찾기가 어려운데요.
OPENMARU APM에서는 쉽고, 빠르게 Thread Dump를 떠볼 수 있네요.
마무리
현재 IT 인프라는 Kubernetes가 주 축이 되었습니다.
특히 기존 클라우드에 주저하던 엔터프라이즈 기업들마저도 PaaS기반의 클라우드로 넘어갈 것으로 예상되고 있습니다.
OPENMARU APM 은 발빠르게 PaaS 환경 모니터링을 준비하였고, 트러블슈팅에 최적화된 다양한 분석 도구들도 제공하고 있습니다.
Kubernetes 클라우드로의 전환, OPENMARU APM 과 함께 시작해보시는 것이 어떨까요?
어떠신가요? 도움이 되셨나요?
이외 다양한 패턴의 문제 상황들이 궁금하시다면?
아래 다른 게시글을 토대로 확인해보시면 더욱 많은 정보를 얻으실 수 있습니다.
이 글은 오픈마루 클라우드 서비스팀 김석영 님이 작성해 주셨습니다.
Written by Seokyoung Kim ( sykim@opennaru.com )
오픈마루
APM 을 이용한 컨테이너 환경에서의 모니터링
/in APM/by 실장 님Like this: