메모리 부족 문제 해결
우리는 최근 Linux 커널 4.8 이상을 실행하는 모든 Linux 머신에서 비정상적인 프로세스 종료를 자동으로 감지하고 보고하는 IBM Instana Crash Detector를 도입했습니다. IBM Instana 플랫폼은 Linux 커널의 eBPF(확장 버클리 패킷 필터) 기능을 활용하여 커널 자체에 연결하고 프로세스 종료를 수신 대기하기 시작합니다. 비정상적으로 종료된 경우 호스트 에이전트에 신호가 전달되고, 호스트 에이전트는 관련 없는 프로세스에 대한 노이즈를 피하기 위해 모니터링하는 프로세스와 해당 종료를 비교한 후 해당 정보를 IBM Instana 백엔드로 전송합니다. 이 기능은 고객들이 인시던트 문제를 해결하려고 할 때 획기적인 역할을 하는 것으로 나타났습니다.
Crash Detector를 통해 IBM Instana 소프트웨어는 고객 애플리케이션의 성능에 영향을 미치는 많은 문제에 대한 중요한 데이터를 제공합니다. 현재 Crash Detector에 메모리 부족 킬러(OOM 킬러) 이벤트를 추가하여 이 기능을 개선하고 있으며, 이는 컨테이너화된 애플리케이션과의 관련성으로 인해 매우 유용한 추가 기능입니다.
클라우드는 예산만 충분하다면 무한한 컴퓨팅 성능을 마음대로 사용할 수 있는 것처럼 보일 수 있습니다. 하지만 이러한 컴퓨팅 성능은 여러 조각으로 나뉩니다. 호스트(물리적 및 가상 모두), 컨테이너 및 기능 등, 모두 할당할 수 있는 메모리 양에 제한이 있습니다.
Linux에서 메모리 부족(OOM) 킬러는 다른 프로세스가 호스트의 메모리를 일괄적으로 소모하지 못하도록 하는 프로세스입니다. 프로세스가 사용 가능한 것보다 더 많은 메모리를 할당하려고 하면 전체적으로 불량도 점수가 가장 높은 프로세스(예: 허용된 메모리 이상으로 할당하는 메모리 양에 따라)가 OOM 신호를 수신합니다. 이 말은 근본적으로 다음과 같은 의미입니다. "허용된 양을 초과했습니다. 종료하거나 하위 프로세스 중 일부를 종료하도록 하세요. 그렇지 않으면 전원이 꺼집니다."
OOM을 트리거하는 프로세스가 OOM 신호를 수신하는 프로세스가 아닐 수도 있다는 점에 유의하세요. 최근에 메모리 사용량을 늘리지 않은 애플리케이션이 갑자기 OOM 신호를 받을 수 있는 이유는 동일한 호스트에서 너무 많은 다른 애플리케이션이 시작되었기 때문입니다.
OOM 신호의 메커니즘은 가혹하게 들리지만, 실제로는 특히 애플리케이션의 크기가 올바르게 조정되지 않았거나 병렬로 실행되는 애플리케이션이 너무 많은 경우(즉, 호스트의 크기가 워크로드에 맞게 올바르게 조정되지 않음) 호스트의 메모리 고갈을 방지하는 매우 효과적인 메커니즘입니다.
Kubernetes, Cloud Foundry, Nomad와 같은 컨테이너화된 플랫폼의 경우, 애플리케이션의 적절한 크기와 호스트에서 한 번에 실행할 애플리케이션의 수 측면에서 메모리 사용이 훨씬 더 중요해집니다. 일반적으로 어느 노드에서 어떤 애플리케이션이 실행되는지 세부적으로 계획하지 않습니다. 많은 설정에서 컨테이너는 오케스트레이터의 특정 논리에 따라 할당됩니다. 최대 메모리 소비를 강제하는 것은 Linux의 거의 모든 컨테이너 기술의 기반인 컨테이너 및 제어 그룹(cgroup)에 매우 중요합니다. 또한 OOM 킬러 시스템을 사용하여 동일한 그룹(예: 컨테이너)에서 실행 중인 프로세스가 허용된 것보다 더 많은 메모리를 할당하지 않도록 합니다. 컨테이너의 프로세스가 허용된 것보다 더 많은 메모리를 할당하려고 하면 일부 프로세스가 종료되어 해당 컨테이너가 함께 종료되는 경우가 많습니다.
규모가 크면 크기 조정을 포함하여 모든 것이 더 어렵습니다. 환경에서 실행하는 컨테이너가 많을수록 일부 컨테이너가 언제, 어떻게, 왜 중단되는지 이해하기가 더 어려워집니다. OOM 킬러는 애플리케이션이 항상 어딘가에서 충돌했다가 다시 시작되는 비정상적인 상황을 만들어 최종 사용자에게 서비스 수준 목표(SLO)를 왜곡하고 문제를 해결하기가 정말 어려운 오류를 지속적으로 생성할 수 있습니다.
OOM 킬러에 의해 단일 프로세스가 폐기된 이유를 찾는 것은 사용하는 기술에 따라 크게 달라집니다. 일부 소프트웨어 패키지는 자체 로그에 이를 기록합니다. 또는 호스트에서 다음과 같은 명령을 각 호스트에서 실행할 수도 있습니다.
#CentOS
grep -i "메모리 부족" /var/log/messages
#Debian / Ubuntu
grep -i "메모리 부족" /var/log/kern.log순조로워 보이지만, MySQL이 새벽 3시에 다시 시작하는 이유를 이해하기 위해 프로덕션 플릿 전체에서 실행하고 싶은 작업은 확실히 아닙니다. 특히 데이터베이스 프로세스가 더 이상 존재하지 않는 이유를 설명할 수 있는 다른 방법이 없어서 직감에 의존하는 경우 더욱 그렇습니다.
다시 말해, OOM 킬러는 신뢰성 측면에서 부인할 수 없을 만큼 중요하고 효과적인 시스템이지만, 충분한 관측 가능성을 제공하지 못합니다. 하지만 IBM Instana 플랫폼이 이 문제를 해결해 드립니다.
Crash Detector를 제공한 eBPF 기반을 더욱 강화한 IBM Instana 소프트웨어는 이제 즉시 사용 가능한 OOM 킬러 감지기와 함께 제공됩니다. IBM Instana 소프트웨어로 프로세스를 모니터링하면 실시간으로 OOM 신호를 수신합니다. 문제가 발생했다는 사실뿐만 아니라 상황이 어떻게 해결되었는지(즉, 어떤 프로세스가 종료되었는지)도 확인할 수 있습니다.
대부분의 IBM Instana 기능과 마찬가지로, IBM Instana 호스트 에이전트를 설치하고 OOM 킬러가 암울한 비즈니스를 수행하는 것을 지켜보기만 하면 됩니다. 또한 이벤트 발생 시 종료된 프로세스가 할당된 메모리의 양을 보여 주므로 OOM 킬러가 해당 프로세스를 "불량"으로 표시한 이유를 이해할 수 있습니다.
적절한 도구가 없으면 프로세스가 종료된 방법과 이유 또는 OOM 킬러로 프로세스가 종료된 이유를 파악하는 데 며칠은 아니더라도 몇 시간이 걸릴 수 있습니다. IBM Instana Crash Detector를 사용하면 이제 모든 비정상적인 프로세스 종료와 모든 OOM 킬러 성공 프로세스의 근본 원인을 즉시 파악할 수 있습니다.
컨테이너가 중단된 이유를 알아야 하나요? 문제 없습니다. IBM Instana Crash Detector OOM 킬러를 사용하면 매우 중요한 배치 작업을 실행하는 Java Virtual Machine(JVM)이 허용된 것보다 더 많은 리소스를 할당했다는 사실을 알 수 있습니다. 또는 하이퍼텍스트 전처리기(PHP) 요청 실패가 너무 많이 발생하는 이유나 데이터베이스가 사라진 이유를 파악해야 할 수도 있습니다. 다시 말하지만, IBM Instana Crash Detector OOM 킬러를 사용하면 이러한 문제의 근본 원인에 즉시 액세스할 수 있습니다.
지금 바로 Linux OS에 IBM Instana 에이전트를 설치하여 여러분과 DevOps 팀이 OOM 킬러 이벤트를 해결하는 데 걸리는 시간을 절약하세요. 아직 IBM Instana 인스턴스가 없는 경우 무료 평가판을 통해 OOM 킬러 감지 기능을 갖춘 IBM Instana Crash Detector가 어떻게 작동하는지 확인할 수 있습니다.