클라우드 환경에서 애플리케이션 성능을 모니터링 방법_1편_제니퍼

클라우드, Cloud

클라우드라는 말을 들으면 어떤 생각이 드시나요? 🧐

저에게 클라우드는 단어의 의미대로 “구름”, “실제로 존재하지만 만질 수는 없는 어떤 것” 과 같은 느낌으로 다가왔습니다. 그래서일까요? 저는 항상 클라우드 환경이 국내에서 본격적으로 대중화 될 수 있을까 라는 의문을 계속 갖고 있었습니다.

쿠버네티스가 등장하기 전까지는 말이죠.

사용자의 민감한 정보를 외부에 보관해야 하는 퍼블릭 클라우드의 경우 국내의 금융권과 같은 기업에서의 도입은 매우 어렵고 사실상 불가능에 가까웠습니다.

하이브리드 클라우드 개념의 등장

하지만 쿠버네티스의 등장으로 기업 스스로가 구축한 프라이빗 클라우드와 퍼블릭 클라우드를 혼용하는 하이브리드 클라우드 개념이 등장하면서 선택적인 데이터 격리가 가능하게 되었습니다. 이에 따라 대다수의 기업들은 쿠버네티스를 이용한 클라우드 환경으로의 점진적인 이전을 시도하고 있습니다.

개별 인스턴스의 실시간 모니터링에 강점을 갖고 있는 제니퍼 역시 이러한 변화에 따라 새로운 관점의 모니터링 방법을 고민 해왔습니다.

기존 모니터링 방법의 한계

클라우드 환경에서도 모니터링의 핵심은 개별 인스턴스, 트랜잭션의 실시간 모니터링임에는 변함이 없습니다. 제니퍼는 클라우드 환경에서도 간편하게 설치할 수 있는 방법을 제공하고 있으며 기존과 동일한 모니터링 경험을 제공합니다.

그럼에도 불구하고 새로운 모니터링 방법이 필요한 이유는 무엇일까요?

저는 가끔씩 고객사에 방문할 일이 있습니다. 사용자마다 갖고 있는 다양한 사용 패턴과 애로 사항을 파악하는데 많은 도움이 되고는 합니다.

하루는 고객사의 대시보드에서 이상한 부분을 발견했습니다.

숫자로만 꽉 채워진 형태를 띄고 있는 숨 막히는 이 차트, 도대체 정체가 무엇일까요? (제목을 보니 분명 액티브서비스 차트인데.. 😅)

네! 이 차트는 액티브서비스 차트가 맞습니다.

해당 고객사 애플리케이션은 대량의 인스턴스로 구성 되어 있었으며 각 업무를 나타내는 많은 도메인들을 도메인 그룹으로 설정하여 운영되고 있었습니다. 도메인 그룹을 선택하여 모니터링 하는 과정에서 하나의 차트에 많은 개수의 인스턴스가 모니터링 대상이 되어 나타내고자 하는 데이터를 적절히 표현하지 못하게 된 것이죠.

제니퍼는 실시간 정보를 원활히 파악하기 위한 목적에서 도메인 당 인스턴스의 개수를 100 이하로 유지할 것을 권장하고 있습니다. 하지만 여러 도메인을 묶은 도메인 그룹 관점에서 모니터링 할 경우 위 사례와 같이 대량의 인스턴스가 하나의 차트에 나열될 가능성이 있습니다.

쿠버네티스 도입에 따라 애플리케이션의 오토 스케일링이 자연스러워지면서 이러한 상황은 점점 빈번해지고 있음을 느낍니다.

개선 방법은 없을까?

앞서 보여드린 예와 같이 하나의 대시보드에서 수많은 인스턴스를 개별 모니터링 한다는 것은 현실적으로 불가능에 가깝다고 할 수 있습니다.

물론 특정 조건을 만족하는 특정 인스턴스들만을 선별적으로 보여주는 필터링 기반의 모니터링을 제공하는 대안이 있습니다.

하지만 이러한 방법 역시 다음과 같은 한계가 있습니다.

• 대시보드에 나타나는 대상이 빈번하게 바뀌어 사용자에게 혼동을 줄 수 있음
• 문제가 있던 인스턴스는 다른 문제가 있는 인스턴스에 우선 순위가 낮아져 노출되지 않게 될 가능성 존재

제니퍼는 한계를 갖고 있는 대안을 제안하는 대신 모니터링의 관점을 달리해보기로 했습니다.

Back to the Basic.

제니퍼의 거의 모든 대시보드와 분석 기능은 최소 모니터링 단위가 인스턴스로 구성되어 있습니다.

정해진 수의 인스턴스로 업무가 운영되는 경우 실질적으로 문제의 원인이 되는 인스턴스를 빠르게 식별하여 문제를 해결하는 것이 가장 중요하기 때문에 제니퍼의 강점이 가장 두드러지는 부분입니다.

개별 인스턴스 단위의 문제 파악은 필수

이러한 개별 인스턴스의 모니터링의 중요성은 수평 확장이 자연스러워진 현 시점에도 유효합니다. 인스턴스가 많아졌다 할지라도 결국 문제 해결을 위해서는 개별 인스턴스 단위의 문제 파악이 필수라고 할 수 있습니다.

클라우드 환경에서 모니터링시 어려움을 겪을 가능성이 있는 부분은 문제 인지의 영역이며 그 원인은 기존과 달라진 모니터링 대상의 수 입니다.

적절히 제한된 인스턴스의 수 → 가변적이고 제한이 없는 인스턴스의 수

가까스로 대량의 인스턴스를 기존 방법으로 모니터링 할 수 있도록 대시보드의 성능을 개선한다 할지라도 표현되는 결과물은 사용자가 기대한 모습이 아닐 가능성이 높습니다. (앞서 첨부한 [그림 1] 참조)

문제가 있는 인스턴스를 확인하고나면 해당 인스턴스가 실행한 애플리케이션, 느린 트랜잭션을 찾게 됩니다. 즉, 문제 파악의 최종 대상은 “애플리케이션” 인 것이죠.

그렇다면 개별 인스턴스의 상태를 보여주는 틀을 깨고 문제 파악의 핵심 대상인 애플리케이션 중점의 모니터링을 해보면 어떨까요?

새로운 대시보드의 필요성 대두

애플리케이션 중심의 모니터링을 위해서는 기존 제니퍼 대시보드의 재구성만으로는 충족시키기 어려운 부분이 있습니다.

예를 들어, 인스턴스 단위 모니터링 요소를 제거하면 실시간 모니터링에서 중요한 액티브 서비스 정보를 표시하지 못하는 문제가 발생할 수 있습니다. 또한, 문제가 있는 트랜잭션을 인지하여 조치를 취하기 위해 설정 관리 화면에서 해당 인스턴스를 찾아야 하는 번거로움이 생깁니다.

이러한 문제점들을 해결하기 위한 고민은 문제의 인지와 분석 뿐 아니라 해결을 위한 조치까지 할 수 있는 대시보드가 있다면 어떨까? 라는 생각에 이르게 됩니다.

문득 얼마전 실시간으로 애플리케이션의 문제를 인지하여 조치할 수 있는 기능인 애플리케이션 인사이트 가 떠올랐습니다.

💡 자세한 내용은 제니퍼 AI, 애플리케이션 인사이트로 실시간 문제 분석 아티클을 참고해주세요.

수 많은 인스턴스로 구성된 업무를 애플리케이션 중점의 차트로 구성한 뒤 애플리케이션 인사이트 와 통합하면 어떤 효과를 기대할 수 있을까요?

• 오토 스케일링에 따른 인스턴스 수 변화에 구애받지 않는 문제 인지
• 문제 현상 인지 후 분석 화면 이동없이 문제의 원인 파악
• 원인 파악 후 사후 대비를 위한 조치

위와 같이 모니터링의 전반적인 과정을 처리할 수 있는 올인원 형태의 대시보드를 상상 했습니다.

자, 그럼 이제 제니퍼의 CTO, 개발자, 디자이너가 치열하게 고민하여 개발한 새로운 대시보드에 대해 알아볼까요?

애플리케이션 인사이트 대시보드

새롭게 개발된 대시보드의 이름은 애플리케이션 인사이트 입니다.

네, 앞서 언급된 제니퍼의 기능 중 하나의 이름이기도 한데요. 문제의 인지, 원인 파악에 있어 특화된 기능이기에 클라우드 환경의 모니터링을 제공하는 대시보드의 이름으로 적합하다라는 점에서 선정된 이름입니다.

기존 제니퍼 대시보드는 개별 인스턴스 단위의 애플리케이션 성능 모니터링에 초점을 맞췄다면, 애플리케이션 인사이트 대시보드는 인스턴스 수의 제약 없이 선택한 도메인(업무) 단위에서 애플리케이션 관점의 성능을 모니터링하는 대시보드입니다.

애플리케이션 인사이트 대시보드에는 제니퍼에서 처음으로 도입한 몇 가지 차트들이 포함되어 있습니다. 대시보드는 포괄적인 문제 인지로 시작하여 상세한 분석으로 이어나갈 수 있게끔 차트들이 배치되어 있습니다.

문제 인지

앞서 소개한 예처럼, 갑작스러운 부하 증가로 오토 스케일링에 의해 인스턴스 수가 늘어날 경우, 기존 액티브 서비스 차트로는 개별 인스턴스의 상태를 파악하기 어려울 수 있습니다.

아래의 예에서는 인스턴스의 개수를 인지 가능한 정도이긴 합니다. 하지만 하지만 여러 인스턴스에서 동시에 지연이 발생할 경우, 각 인스턴스별로 액티브 서비스의 상세 정보를 확인하는 과정은 번거로움으로 다가올 수 있습니다.

개별 인스턴스의 상태를 파악하는 것보다 서비스 전체 관점에서 문제를 인지하는 것이 더 중요하다면, 전체적인 액티브 서비스를 요약해 시각화하는 것이 더욱 효과적일 것입니다.

그럼, 제니퍼에서 새로운 방식의 액티브서비스 모니터링을 위해 개발한 “액티브 애플리케이션” 차트에 대해 알아보겠습니다.

제니퍼 대시보드의 모든 차트에서 붉은색은 장애나 성능 저하의 위험을 알리는 데 사용됩니다. 이 차트에서도 마찬가지로 붉은색을 중심으로 모니터링하면 됩니다. 좀 더 자세히 설명드리겠습니다.

위의 차트는 액티브 서비스 요약 정보의 평균 응답시간을 X 축으로 호출 건수의 합을 Y 축으로 설정한 뒤 각 애플리케이션을 원으로 표현합니다.

애플리케이션을 나타내는 각 원은 다음과 같은 표현 요소를 갖고 있습니다.

💡 여기서 느린 호출 건수라는 것은 애플리케이션의 평균 응답 시간이 액티브서비스의 총 4개의 구간 중 마지막 구간에 해당되는 호출 건수의 합을 의미합니다.

• 색상
  • 파란색
    • 정상 상태
  • 붉은색
    • 애플리케이션의 평균 응답시간이 액티브 서비스의 마지막 구간에 해당되는 경우 (여기서는 8초 이상)
    • 애플리케이션 별 요약 정보를 구성하는 액티브 서비스 중 하나라도 액티브 서비스의 마지막 구간에 해당되는 경우
• 크기
  • 느린 호출 건수 개수에 비례하여 커짐

이러한 색상의 크기의 조건을 이용하여 평균으로 인해 표현되지 않을 수 있는 느린 액티브서비스를 눈에 띄게 표현할 수 있습니다. 또한, 사용자는 액티브 애플리케이션 차트에 보이는 빨간 원을 클릭하거나 드래그만 하면 지연중인 애플리케이션을 빠르게 찾을 수 있습니다. 🔍

✨ 제니퍼의 클라우드 환경 애플리케이션 성능 모니터링 방법에 대한 두 번째 이야기는 다음 편에서 계속됩니다. 👧🏻

클라우드, 쿠버네티스, 그리고 제니퍼: ​애플리케이션 중점의 모니터링!!