엔지니어링

Elasticsearch와 Elastic APM을 이용한 애플리케이션 모니터링

By
Jamie Smith

애플리케이션 성능 모니터링(Application Performance Monitoring, APM)이란?

APM을 설명할 때, "관측"을 더 쉽게 할 수 있게 해주는 로그와 메트릭과 같은 요소들과 함께 다루는 것이 좋습니다. 로그, APM, 인프라 메트릭은 다음과 같이 관측을 도와주는 3가지 요소라고 할 수 있습니다.

이 세 요소는 서로 겹치는 부분이 있지만 서로 연계하여 지원할 정도로만 적당히 겹칩니다. 로그는 오류가 발생했다는 것을 표시할 수는 있지만 그 이유는 나타낼 수 없을 것입니다. 메트릭은 서버의 CPU 사용량이 급증했다는 것을 보여줄 수는 있지만 그 원인이 무엇인지는 표시할 수 없습니다. 따라서 이 세 가지를 함께 사용하면 훨씬 더 광범위한 문제들을 해결할 수 있습니다.

로그

먼저, 몇 가지 정의를 알아보겠습니다. 로그와 메트릭 간에는 사실상 아주 미묘한 차이가 있습니다. 일반적으로 로그는 요청이 수신 및 응답되고, 파일이 열리고, 코드에서 printf가 발생하는 등 무슨 일이 생길 때 내보내는 이벤트입니다.

다음은 Apache HTTP 서버 프로젝트에서 가져온 일반 로그 형식의 예입니다. (길이를 줄인 가짜 데이터입니다.) 

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "GET /ESProductDetailView HTTP/1.1" 200 6291
264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "POST /intro.m4v HTTP/1.1" 404 7352
264.242.88.10 - - [22/Jan/2018:16:38:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253

로그는 애플리케이션을 전체적으로 보기보다는 여전히 구성 요소 수준에 머무는 경향이 있습니다. 로그는 일반적으로 사람이 읽을 수 있다는 면에서는 좋습니다. 위의 예에서는, IP 주소, 명백히 설정되지 않은 필드, 날짜, 사용자가 액세스한 페이지(와 방법), 그리고 숫자 몇 개를 볼 수 있습니다. 경험상, 저는 이 숫자들이 응답 코드(200은 좋음, 404는 그보다는 못하지만 500보다는 좋음)와 반환되는 데이터의 양이라는 것을 알고 있습니다.

로그는 보통 해당 애플리케이션이나 서비스를 실행하는 호스트/컴퓨터/컨테이너 인스턴스에서 사용 가능하기 때문에 간편합니다. 그리고 위에서 보는 것처럼, 어느 정도는 사람이 읽을 수 있습니다. 로그의 취약점은 바로 그 자체의 속성과 결부되어 있습니다. 즉, 사용자가 코딩을 하지 않으면, 출력할 수가 없습니다. Ruby의 puts나 자바의 system.out.println에 해당하는 것을 확실하게 해주어야 합니다. 그렇게 한다고 하더라도, 서식이 중요합니다. 위의 Apache 로그에는 이상해 보이는 날짜 형식이 있습니다. 예를 들어, "01/02/2019"라는 날짜를 봅시다. 미국에 있는 저에게는 2019년 1월 2일이지만, 수많은 분이 이것을 2월 1일로 읽으실 것입니다. 로깅 문 서식에서는 이런 점을 염두에 두어야 합니다.

메트릭

반면에 메트릭은 주기적인 요약이나 통계인 경향이 있습니다. 지난 10초 동안에 평균 CPU는 12%였고, 애플리케이션이 사용하는 메모리 양은 27MB였으며, 기본 디스크 용량의 71%가 사용되었습니다(최소한 저의 경우에는 방금 확인해 보니 그렇습니다).

위는 맥에서 실행되는 iostat의 스크린샷입니다. 수많은 메트릭이 있죠. 메트릭은 추세와 내역을 보여주고 싶을 때 유용합니다. 문제와 이상 징후를 파악하기 위한 간단하고 예측 가능하며 믿을 수 있는 규칙을 만들려고 할 때는 아주 뛰어납니다. 메트릭에 있어 한 가지 문제는 인프라 레이어를 모니터링하여 사용자 정의 애플리케이션 수준에서보다는 호스트, 컨테이너, 네트워크 등과 같은 구성 요소 인스턴스 수준에 대한 데이터를 포착하는 경향이 있다는 것입니다. 메트릭은 일정 기간에 걸쳐 샘플링되는 경향이 있기 때문에, 간단한 이상값이 “결국 평균이 되는” 위험을 감수합니다.

APM

애플리케이션 성능 모니터링은 메트릭과 로그 사이의 간격을 이어줍니다. 로그와 메트릭이 인프라와 구성 요소를 처리하면서 보다 교차적인 경향이 있는 반면, APM은 애플리케이션에 중점을 둠으로써 IT와 개발자가 최종 사용자 경험을 포함해 스택의 애플리케이션 레이어를 모니터링할 수 있게 해줍니다.

모니터링에 APM을 추가하면,

  • 서비스가 어떤 작업에 시간을 사용하는지, 왜 작동이 중단되는지를 이해할 수 있습니다.
  • 서비스들이 어떻게 서로 상호작용하는지를 알게 되고, 병목 현상을 시각화할 수 있습니다.
  • 성능 병목 현상과 오류를 사전에 발견하고 수정할 수 있습니다.
    • 너무 많은 고객들에게 영향을 미치기 전에 이렇게 할 수 있으면 좋겠죠.
  • 개발팀의 생산성을 높일 수 있습니다.
  • 브라우저에서 최종 사용자 경험을 추적할 수 있습니다.

주목해야 할 한 가지 중요한 사실은 APM이 코드를 말한다는 것입니다(곧 좀더 자세히 알아보겠습니다).

APM이 우리가 로그에서 얻는 것과 어떻게 비교되는지 살펴보겠습니다. 이런 로그 항목이 있습니다. 

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "GET /ESProductDetailView HTTP/1.1" 200 6291

이 항목을 처음 보면, 다 괜찮은 것 같습니다. 성공적으로 응답했고(200), 6291바이트를 반환했는데, 여기서는 다음 APM 스크린샷에서 볼 수 있는 것과는 달리 16.6초 걸렸다는 것은 나타나 있지 않습니다.

이런 약간의 추가 정보는 꽤 유용합니다. 또한 위의 로그에는 오류 정보가 있습니다. 

264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253

APM도 다음과 같이 오류를 포착해줍니다.

이것은 오류가 언제 마지막으로 발생했는지, 얼마나 자주 발생했는지, 애플리케이션이 이를 처리했는지 아닌지를 보여줍니다. 한 예로 NumberParseException을 이용해 예외로 드릴다운하면, 다음 창에서 오류가 발생한 횟수 분포의 시각화를 보게 됩니다.

시기별로 몇 번씩, 그러나 거의 하루 종일 내내 발생하는 것을 즉시 알 수 있습니다. 로그 파일 중 하나에서 해당 스택 추적을 찾을 수 있을 것 같지만, 다음과 같이 APM을 사용할 때 얻을 수 있는 컨텍스트와 메타데이터가 없을 공산이 큽니다.

빨간색 사각형은 예외를 발생시킨 코드 줄을 보여주며, APM이 제공한 메타데이터는 문제가 정확히 무엇인지를 보여줍니다. 저처럼 파이썬 프로그래머가 아닌 사람조차도 정확히 문제가 무엇인지 알 수 있으며, 티켓을 열기에 충분한 정보를 갖게 됩니다.

APM 기능 소개(스크린샷 포함)

Elastic APM에 대해 하루 종일 말씀드릴 수도 있지만(트위터에서 저를 찾아주시면 증명해 드리겠습니다) 그보다는 Elastic APM이 무엇을 할 수 있는지를 보고 싶어하실 것 같습니다. 한 번 볼까요?

APM 열기

Kibana에서 APM 애플리케이션을 입력하면, 다음과 같이 Elastic APM으로 계측한 모든 서비스를 보게 됩니다.

서비스 자세히 살펴보기

각 개별 서비스로 드릴다운할 수 있습니다. "petclinic-spring" 서비스로 들어가 보겠습니다. 각 서비스는 다음과 같이 비슷한 레이아웃을 갖습니다.

왼쪽 상단에는 응답 시간이 표시되며, 평균, 상위 95%, 상위 99% 등 내 이상값이 어디에 있는지를 보여줍니다. 또한 이상값이 전체 차트에 어떻게 영향을 미치는지 좀더 잘 느낄 수 있도록 다양한 선 요소를 표시하거나 숨길 수도 있습니다. 오른쪽 상단에는 응답 코드가 표시되며, 시간별 분당 요청(RPM)으로 분할되어 있습니다. 차트에서 볼 수 있듯이, 마우스를 어느 한 쪽 차트 위에서 움직이면 해당 시점의 요약을 보여주는 팝업이 뜹니다. 깊이 들어가 보기도 전에 첫 번째 인사이트를 얻을 수 있는데, 대기 시간의 엄청난 급증이 500번대 응답(서버 오류)을 갖지 않는다는 점입니다.

트랜잭션 응답 시간 자세히 살펴보기

계속해서 트랜잭션 요약을 살펴보면, 하단에 요청 분석 결과가 나와 있습니다. (다양한 에이전트 API를 사용하여 기본값을 확대할 수 있더라도) 각 요청은 애플리케이션에서 기본적으로 다른 끝점입니다. 열 머리글로 정렬할 수 있지만 개인적으로는 “영향” 열을 좋아합니다. 해당 요청의 대기 시간과 인기도를 고려하기 때문입니다. 이 경우에는 "getOwners"가 제일 큰 문제 같지만 96ms라는 꽤 괜찮은 평균 대기 시간을 보여줍니다. 트랜잭션의 세부사항으로 들어가면, 다음과 같이 앞서 보았던 것과 동일한 레이아웃을 보게 됩니다.

운영 폭포

그러나 가장 느린 요청도 여전히 1초 미만입니다. 아래로 스크롤하면 다음과 같이 트랜잭션의 운영 폭포 보기가 나옵니다.

쿼리 세부 정보 뷰어

분명히 수많은 SELECT 문이 실행되고 있습니다. APM을 이용하면 다음과 같이 실행되는 실제 쿼리를 볼 수 있습니다.

분산 추적

이 애플리케이션 스택에서는 다중 계층 마이크로 서비스 아키텍처를 처리합니다. Elastic APM으로 계측한 모든 계층을 가지고 있으므로, 이 호출과 관련된 모든 것을 보기 위해 "전체 추적 보기" 버튼을 눌러 약간 확대하면 이 트랜잭션에 참여한 모든 구성 요소의 분산 추적을 볼 수 있습니다.

추적 레이어

이 경우에는, 우리가 시작한 레이어인 Spring 레이어가 다른 레이어들이 호출하는 서비스입니다. 이제 우리는 "petclinic-node"가 "petclinic-spring" 레이어를 호출한 것을 볼 수 있습니다. 두 레이어 뿐이지만, 우리는 훨씬 더 많은 레이어를 볼 수 있으며, 이 예에서는 브라우저(반응) 레이어에서 시작된 요청이 있습니다.

실제 사용자 모니터링

분산 추적에서 최대한의 가치를 얻어내려면, 실제 사용자 모니터링(즉, RUM)을 활용하는 등 가능한 한 많은 구성 요소와 서비스를 계측하는 것이 중요합니다. 빠른 서비스 응답 시간을 갖는다는 것이 브라우저에서 빨리 실행된다는 것을 의미하지는 않기 때문입니다. 브라우저에서 최종 사용자의 경험을 측정하는 것이 중요합니다. 이 분산 추적은 서로 협력하는 네 개의 다른 서비스를 보여줍니다. 여기에는 여러 서비스와 더불어 웹 브라우저(클라이언트)가 포함됩니다. 53ms에서 domInteractive였고, 67ms에서는 domComplete된 것을 볼 수 있습니다.

단순한 외양을 넘어서는 가치

Elastic APM은 애플리케이션 개발자를 위해 설계된 턴키 APM UI에 대한 것만이 아닙니다. 그것을 지원하는 데이터도 그 UI를 처리하는 것이 유일한 존재 이유는 아닙니다. 사실상, Elastic APM 데이터의 가장 좋은 점 중 하나는 그것이 또 다른 인덱스라는 것입니다. 로그, 메트릭, 심지어 비즈니스 데이터와 함께 정보가 바로 거기 있으며, 서버의 속도 저하가 수익에 어떤 영향을 미치는지 볼 수 있게 해줍니다. 또는 APM 데이터를 활용하여 다음 코드 개선 시에 무엇을 해야 할지 계획을 세울 수도 있습니다(힌트: 가장 영향력이 큰 요청을 살펴보세요).

APM은 기본 시각화 및 대시보드와 함께 제공되어, 이것을 로그, 메트릭, 심지어 비즈니스 데이터의 시각화와 조합하여 사용할 수 있습니다.

Elastic APM 시작하기

Elastic APM은 다음과 같이 비슷한 배포 토폴로지로 Logstash 및 Beats와 더불어 실행할 수 있습니다.

APM 서버는 데이터 프로세서로 기능하며, APM 데이터를 APM 에이전트에서 Elasticsearch로 전달합니다. 설치는 상당히 간단하며, 설명서의 "설치 및 실행" 페이지에서 볼 수 있습니다. 또는 Kibana에서 "K" 로고를 클릭하기만 하면 Kibana 홈 화면으로 이동할 수 있고, 거기에 "APM 추가" 옵션이 있습니다.

거기서 APM 서버 실행을 자세히 안내해 드릴 것입니다.

일단 서버를 실행하게 되면, Kibana는 각 기본 제공 에이전트 유형에 대한 자습서를 갖추고 있습니다.

코드 몇 줄 만으로도 실행할 수 있습니다.

Elastic APM 사용해 보기

새로운 것을 배우려면 직접 뛰어들어서 만져보는 것이 가장 좋습니다. 시도해 볼 만한 몇 가지 다른 방법이 있습니다. 인터페이스를 실제로 직접 보고 싶으면, APM 데모 환경에서 여기 저기를 클릭해 보세요. 그보다 로컬 컴퓨터에서 실행해보고 싶으면, APM 서버 다운로드 페이지에서 해당 단계를 따르셔도 됩니다.

가장 간단한 경로는 전체 Elasticsearch 배포를 갖출 수 있는 Elastic의 SaaS 제품인 Elastic Cloud의 Elasticsearch Service를 통하는 것입니다. 여기에는 APM 서버(현재 6.6), Kibana 인스턴스, 머신 러닝 노드 등이 포함되며 몇 분 안에 실행할 수 있습니다(그리고 2주 무료 체험판이 있습니다). 가장 좋은 부분은 사용자를 위해 저희가 배포 인프라를 유지 관리해드린다는 점입니다.

Elasticsearch Service에서 APM 활성화

APM을 갖춘 클러스터를 만들려면(또는 기존 클러스터에 APM을 추가하려면), 클러스터에서 APM 구성 섹션까지 아래로 스크롤해서 “활성화”를 클릭한 다음 “변경 사항 저장”(기존 배포를 업데이트할 때)이나 “배포 만들기”(새 배포를 만들 때)를 클릭하기만 하면 됩니다.

라이선싱

Elastic APM 서버와 모든 APM 에이전트는 모두 오픈 소스입니다. 큐레이팅된 APM UI가 무료 기본 라이선스 하에 Elastic Stack의 기본 배포에 포함되어 있습니다. 앞서 참조한 통합(알림과 머신 러닝)은 기본 기능에 대한 기본 라이선스과 제휴되며, 따라서 알림은 골드, 머신 러닝은 플래티넘과 제휴됩니다.

요약

APM은 모든 계층에서 애플리케이션의 상황을 보여줍니다. 머신 러닝 및 알림과 통합되고 강력한 검색 기능이 결합되어 Elastic APM은 애플리케이션 인프라에 완전히 또 다른 레이어의 가시성을 더해줍니다. 트랜잭션, 추적, 오류, 예외, 그리고 큐레이팅된 APM 사용자 인터페이스의 맥락에서 모든 것을 시각화하는 데 이를 이용할 수 있습니다. 문제가 없을 때도, Elastic APM의 데이터를 활용하여 수정의 우선 순위를 지정하고, 애플리케이션에서 최고의 성능을 끌어내고, 병목 현상을 해결하는 것을 도울 수 있습니다.

Elastic APM과 가관측성에 대해 더 자세히 알아보려면, 아래에 소개해드리는 지난 웨비나 몇 개를 살펴보세요.

오늘 사용해 보세요! 저희 토론 포럼에서 APM 주제를 찾아보시거나 저희 APM GitHub 리포에서 티켓 또는 기능 요청을 제출해 주세요.