PaaS가 애플리케이션 성능 모니터링(APM)을 형성하는 방식 – 핵심 고려사항

PaaS 플랫폼이 표준화된 도구와 공통 언어를 약속하지만, 그것이 자동으로 손쉬운 모니터링으로 이어지지는 않습니다. Chris Talbot이 2018년 Talkin' Cloud 기사 "연구: PaaS 시장 2018년까지 69.4억 달러 돌파"에서 지적했듯, 조직은 APM 솔루션이 PaaS 환경에서 진정으로 번창하는지 면밀히 조사해야 합니다. 핵심 이유는 다음과 같습니다.

1. 언어 전문화: 많은 PaaS 제공물은 단일 프로그래밍 언어에 집중합니다. APM 도구가 해당 언어에 대한 강력한 지원이 부족하면 해당 플랫폼 내 개발자에게 의미 있는 통찰을 제공할 수 없습니다. 반대로 관련 언어에서 뛰어난 솔루션은 중요한 플랫폼별 메트릭을 제공할 수 있습니다.

2. 추상화와 숨겨진 계층: PaaS 인프라는 기본 아키텍처의 많은 부분을 숨겨 표준 모니터링에 불투명하게 만듭니다. 주요 구성 요소는 종종 접근 불가능한 상태로 남습니다:

• 라우팅: 예를 들어 Heroku의 라우팅 계층은 모니터링이 필수적이지만 많은 APM 도구가 그 성능을 포착하지 못합니다.
• 머신 구성: 파일 동기화 및 기타 호스트 수준 설정은 런타임 언어만 보는 에이전트에는 보이지 않을 수 있습니다.
• 독점 확장: 공급업체가 비공개로 유지하는 맞춤형 서버 빌드나 언어 조정은 파트너십이 없는 한 서드파티 가시성을 제한합니다.
• 멀티테넌트 서비스: 공유 데이터베이스나 캐시는 직접 데이터베이스 액세스가 필요한 에이전트, 특히 테넌트 격리가 시행될 때 문제를 야기합니다.
• 외부 API: PaaS 호스팅 앱은 자주 작업을 서드파티 API에 오프로드합니다. API 수준 텔레메트리 없이는 성능 병목이 눈에 띄지 않을 수 있습니다.

PaaS 모니터링의 필요성

PaaS 공급업체가 확장과 인프라를 관리하지만, 애플리케이션 자체는 여전히 귀하의 책임입니다. 코드, 구성, 플랫폼과의 상호작용 등에서 성능 문제가 여전히 발생합니다. 전용 모니터링 전략은 이러한 문제를 신속하게 감지하고 해결하도록 보장합니다.

PaaS 생태계 내부에는 수많은 서비스가 공존합니다: 청구 GUI, 애드온 관리 콘솔, 구성 관리자 등. 각 구성 요소는 전체 성능에 영향을 미칠 수 있습니다. 이러한 내부 서비스 모니터링은 최적의 가동 시간과 리소스 활용을 유지하며 플랫폼이 약속한 단순성을 강화합니다.

차세대 PaaS

현대 PaaS 배포는 몇 분만 존재할 수 있는 초소형, 일시적 서버로 추세입니다. 오래 지속되는 인스턴스를 가정하는 전통적 APM 도구는 따라잡기 어렵습니다. 효과적인 솔루션은 경량화되어야 하며, 단명 노드를 신속하게 발견하고 추적할 수 있어야 하며, 규모에 맞게 비용 효율적이어야 합니다.

궁극적으로 애플리케이션이 진화함에 따라 지속적이고 적응적인 모니터링이 필요합니다. PaaS 공급업체는 강력한 추상화를 제공하지만, 경계심이 강하고 맥락 인식적인 성능 통찰의 필요성을 없애지는 않습니다.