기술이야기

기술이야기 [Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지? 기술이야기 [Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지? 평온한 오후 퇴근 준비가 한창인데 불길한 전화가 걸려 옵니다. “서비스가 먹통이어서 확인 좀 해야 하는데 서버가 엄청 버벅거리고 반응이 느려요!! 이거 왜 이러죠??” 왜!! 도대체 왜!! 한 번쯤은 겪어보았을 급작스러운 Linux 서버의 상태 이슈! 불행하게도 무척이나 다양한 원인으로 인해 발생하게 됩니다. 우리의 목표는 이 다양한 원인 중 실제 발생 원인을 빠르게 특정하는 것! 기본적인 항목들의 체크리스트를 통해 빠르게 원인을 파악 해 봅시다. Linux 서버 상태 이슈 체크리스트 1. 서버의 CPU 부하 확인하기 2. BUFFER, CACHE, SWAP 상태 확인하기 3. 디스크 상태 확인하기 Zenius를 통한 데이터 추이 분석!! 장애의 발생은 순식간에 일어나지만, 장애 발생 시점의 데이터만을 확인해서는 원인을 파악하기가 쉽지 않은 경우가 많습니다. Zenius를 활용하여 앞서 정한 체크리스트를 빠르게 확인해 봅시다. 1. 서버의 CPU 부하 확인하기 - CPU 부하 확인의 Point는 Load Average Load Average는 CPU 사용 대기 중인 프로세스와 I/O 완료를 대기하고 있는 프로세스의 수를 의미합니다. 따라서, Load Average가 높다는 것은 CPU가 바쁘며 시스템에 걸리는 부하가 있다는 뜻입니다. 화면과 같이 1분, 5분, 15분의 로드 평균을 확인 해 보도록 합시다. 1분 로드 평균은 순간적으로 증가하는 경우가 있지만, 5분 15분 데이터상에도 이전과 비교하였을 때 높은 수치를 보인다면, CPU의 부하가 의심스러운 상황입니다. 그렇다면 CPU의 사용률과 I/O 대기율은 어떨까요? user가 사용한 CPU 사용률은 일정하지만, Iowait 수치가 올라간 것을 볼 수 있습니다. 이 경우 CPU의 리소스 부족이기보다는 I/O로 인한 부하로 판단할 수 있고, 자세히는 메모리나 프로세스의 현황 확인이 필요한 경우입니다. 반대로 user 수치가 높은 경우에는 물리적인 CPU 자체의 리소스 부족이라 볼 수 있습니다. 2. BUFFER, CACHE, SWAP 상태 확인하기 - 메모리 사용률과 Swap, Buffer, Cache 메모리 사용률이 높다 = 서버에 부하가 있다?? 답은 No !! Linux 서버의 메모리 사용률은 Buffer/Cache의 사용량이 포함되어 표현되게 됩니다. 따라서, 우리는 그 추이를 통하여 이슈를 확인하는 것이 중요합니다. 위의 검은 바탕의 그래프는 메모리 사용률이 높지만, 일정한 수치를 유지하고 있습니다. 이런 경우 서버의 메모리 사용은 안정적인 영역에서 이루어진다고 판단이 가능합니다. 그 이유는 실제 메모리 사용량과 Buffer/Cache에 할당량의 수치가 할당 가능한 수치 내에서 이루어지기 때문에 사용률이 유지된다고 볼 수 있기 때문입니다. 반면 흰 바탕의 그래프는 메모리 사용률이 점차 증가하며 결국 100%까지 도달한 것을 확인할 수 있는데요, 이경우에는 프로세스가 연산에 필요한 공간을 할당받지 못하여 프로세스 행이 발생하게 됩니다. 그렇다면 Buffer Cache Swap은 어떨까요? 먼저 Buffer Cache에 관해 확인 해 보도록 하겠습니다. *Buffer – 메타데이터를 메모리에 저장. *Cache – Page Cache, Slab을 메모리에 저장. 쉽게 말해, 둘 다 용도에 맞는 정보를 저장하여 수행 속도에 도움을 주는 영역입니다. 메모리 사용량이 늘어나면 이 Buffer, Cache 영역이 줄어들게 되고, 저장 영역이 줄어든다는 것은 속도가 떨어져 성능 저하로 이어지게 됩니다. 아래 그래프는 메모리 사용률이 올라가고 있는 상태의 서버 데이터입니다. 다음으로 이 시점의 Buffer, Cache의 영역을 확인해 보겠습니다. 추이 그래프를 통해 메모리 사용률이 올라갈수록 Buffer, Cache 영역이 줄어드는 것을 확인할 수 있습니다. 그렇다면 이 시점의 I/O는 어떨까요? 보시는 바와 같이 Iowait 수치가 급격히 올라갔음을 확인 할 수 있으므로, “메모리 사용률의 상승은 Buffer, Cache 영역을 줄어들게 하여 속도 저하를 발생시킨다.” 라는 결론을 도출할 수 있습니다. 또한, 메모리 사용률의 상승은 Swap에도 영향을 끼치게 됩니다. *Swap – 디스크 공간에 할당하여 메모리 역할로 사용하는 공간. 따라서, Swap 영역의 사용은 실제 메모리가 아닌 디스크를 사용하기 때문에 속도 저하가 발생 됩니다. 위 그래프는 Swap 사용률이 증가하고 있는 서버의 데이터입니다. 이 시점의 디스크의 상태를 보면 Read와 Write가 점차 Swap과 동일하게 상승하는 것을 볼 수 있습니다. 이렇게 메모리 대신 디스크 영역을 사용하면서 속도가 저하하게 되는 것입니다. 3. 디스크, 확인하기 - Mount Point 별 디스크 사용량, 작업량 추이 확인 디스크의 여유 공간이 없으면 시스템이 파일 생성을 못 하게 되고 결국엔 서버의 운영에 영향을 끼치게 됩니다. 각각의 마운트 지점의 사용률을 체크하여 여유 공간을 확보하는 것이 필요합니다. 디스크의 사용량이 급작스럽게 늘어난 경우는 신규 파일이 업로드되었다거나, 로그파일이 급작스럽게 많이 쌓이는 경우가 있습니다. 그렇기에 각 Mount Point의 사용률을 확인하고 해당 지점의 이슈 사항을 파악하는 것이 가장 좋습니다. 위 그래프와 같이 1시간 이내에 /data 지점의 사용률이 급등하였다면, 해당 지점에 쌓이는 데이터나 로그파일이 급격하게 증가한 것이므로 확인이 필요합니다. 다음으로는 디스크 사용 추이를 확인 해 보도록 하겠습니다. 서버에서 사용하는 물리 디스크는 각각의 성능의 한계가 있습니다. 이 한계를 직관적으로 확인할 수 있는 데이터로는 Disk Busy Rate(작업률)와 Disk Wait Rate(대기율)이 있는데요, Read 및 Write의 양이 한계치까지 치솟게 된다면 Busy Rate 값이 증가하게 되고, 이에 따른 Wait Rate 가 늘어나면서 서버의 성능 저하를 불러오게 됩니다. 어떻게 관리해야 할까? 앞서 확인한 서버의 상태 이슈들, 물론 급작스럽게 발생하는 경우는 어쩔 수 없지만 미리 대비가 가능한 것들은 Zenius-EMS를 이용하여 임계치 기반의 사전 모니터링과, 모니터링 페이지를 통한 직관적인 관리가 가능합니다. 각각의 항목들에 세부적으로 단계별 임계치를 걸어서 서버의 상태 이슈를 사전에 인지하고, 요약 페이지를 통해 빠르게 상태를 파악하여 우리의 퇴근 시간을 사수해 보는 건 어떨까요? 2023.08.08

기술이야기 서버 모니터링, 서버 관리, 서버 관리자 기술이야기 서버 모니터링, 서버 관리, 서버 관리자 서버는 기업의 IT 인프라를 구성하는 필수 요소입니다. 서버는 클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 컴퓨터 시스템으로, ▲파일 저장 및 공유 ▲웹사이트 및 애플리케이션 호스팅 ▲프린터 및 스캐너와 같은 네트워크 리소스 관리 ▲이메일 서비스 제공 등 다양한 기능을 수행합니다. 일반적으로 Microsoft Windows Server, Linux 또는 Unix와 같은 다양한 운영 체제를 실행하며, 가동 중지 시간을 최소화하면서 지속적으로 실행되도록 설계됐습니다. 오늘날과 같이 급변하는 비즈니스 환경에서의 서버 중단은 상당한 수익 손실과 평판 손상으로 이어질 수 있습니다. 이에 따라 기업은 서버 모니터링 및 관리를 위해 문제를 신속하게 식별하고 해결할 수 있는 강력한 서버 모니터링 시스템을 필수적으로 갖춰야합니다. 서버 모니터링과 서버 관리는 서버의 성능을 최적화하고 가용성을 보장하는데 중요한 관련이 있습니다. 이 블로그에서는 서버 모니터링과 서버 관리에 대해서 알아보고, 마지막으로 서버관리자가 어떤 일을 하는지 논의해 보고자 합니다. 먼저, 서버 모니터링과 서버 관리의 차이점은 다음과 같습니다. ------------------------------------------ 서버 모니터링이란? 서버 모니터링에는 도구와 소프트웨어를 사용해 서버의 성능, 상태 및 가용성을 추적하는 작업이 포함됩니다. 여기에는 CPU 사용량, 메모리 사용량, 디스크 공간, 네트워크 트래픽 및 애플리케이션 성능과 같은 모니터링 지표가 포함됩니다. 서버 모니터링의 목표는 문제가 발생하기 전에 잠재적인 문제를 감지하고, 문제가 발생할 때 문제 해결을 위한 데이터를 제공하는 것입니다. 서버 모니터링은 일반적으로 특수 도구를 사용해 자동화되는 프로세스입니다. 서버 관리란? 서버 관리는 서버가 최적으로 작동하도록 서버를 능동적으로 유지∙관리하고 구성하는 프로세스입니다. 여기에는 운영 체제, 소프트웨어 및 응용 프로그램의 설치 및 구성, 사용자 계정 및 사용 권한 관리, 백업 및 복원 수행, 서버 환경의 보안 및 규정 준수 보장 등의 작업이 포함됩니다. 서버 관리의 목표는 서버가 최고의 효율성으로 실행되고 안전하며, 사용자에게 필요한 서비스를 제공할 수 있도록 하는 것입니다. 요약하면, 서버 모니터링은 관찰 및 경고에 중점을 두는 반면, 서버 관리는 성능을 최적화하고 가용성을 보장하기 위해 서버를 능동적으로 구성하고 유지∙관리하는데 중점을 둡니다. 서버 모니터링은기업의 서버 관리자가 담당합니다. 서버 관리자는 기업의 비전과 전략을 달성하기 위해 서버를 비롯한 IT 시스템의 방향을 수립하는 IT 전문가입니다. 서버 관리자는 높은 수준의 가동 시간과 가용성을 보장하고 서버, 시스템 및 애플리케이션의 소프트웨어 및 하드웨어 기능과 같은 구성 요소를 평가합니다. 서버 관리자의 주요 업무는 조직의 규모와 특정 요구 사항에 따라 다를 수 있지만, 일반적으로 아래와 같습니다. 서버 관리자의 주요 업무 1. 서버 설치 및 구성 서버 설치 및 구성은 서버 관리자의 필수 업무로, 서버 하드웨어, 소프트웨어 및 네트워크 인프라에 대한 기술적 전문 지식, 세부 사항에 대한 주의 및 철저한 이해가 필요한 복잡한 작업입니다. 서버 관리자는 최적의 성능, 보안 및 안정성을 제공하는 동시에 서버가 조직의 요구사항을 충족하도록 올바르게 설치 및 구성됐는지 확인해야 합니다. 2. 서버 모니터링 및 유지보수 서버의 안정성과 성능을 유지하기 위한 핵심 업무입니다. 서버 관리자는 서버 하드웨어 및 소프트웨어를 유지∙관리해, 서버가 효율적이고 안전하게 실행되도록 하고 시스템 성능을 모니터링해 잠재적인 문제를 식별합니다. 3. 서버 보안 서버 보안 관리는 서버에 저장된 데이터의 기밀성, 무결성 및 가용성을 손상시킬 수 있는 잠재적인 보안 위협으로부터 서버를 보호하는 것과 관련된 업무입니다. 서버 관리자는 서버가 잠재적인 보안 위협으로부터 보호되고 서버가 관련 규정 및 표준을 준수하는지 확인하기 위해 적극적으로 노력합니다. 4. 서비스 제공 및 지원 서비스 제공 및 지원은 서버 서비스 및 응용 프로그램의 배포, 유지 및 지원 관리와 관련 있습니다. 이 업무는 서버 가용성을 유지하고 사용자 요구 사항을 충족하는데 중요하며, 서버 관리자는 사용자가 필요할 때 시기 적절하고 효과적인 지원을 받을 수 있도록 합니다. ------------------------------------------ 이처럼 서버 관리자는 서버가 원활하고 안전하며 효율적으로 실행되도록 하는데 중요한 역할을 합니다. 서버 관리자는 복잡한 기술적 지식을 보유해야 하고 빠른 대처 능력을 요구받으며, 보안 대응 및 최적화 작업 등에서 많은 어려움을 겪습니다. 더욱이 서버가 기능에 따라 세분화돼 일반 서버, 웹 어플리케이션 서버, 데이터베이스 서버 등으로 나뉘게 되면 각 기능별로 웹 애플리케이션 서버관리자나 데이터베이스 서버관리자 등으로 관리자의 역할이 세분화되기도 합니다. 서버의 수나 종류가 많아지고 구성이 복잡해지면 모니터링과 관리가 어려워집니다. 이를 돕기 위해 브레인즈컴퍼니의 Zenius(제니우스)와 같은 통합 서버 모니터링 및 관리 소프트웨어가 필요하게 됩니다. 2023.05.09

기술이야기 IT 인프라 모니터링 트렌드 기술이야기 IT 인프라 모니터링 트렌드 EMS란? EMS는 Enterprise Management System의 약자로, 여러 기업과 기관의 IT서비스를 이루는 다양한 IT Infrastructure를 통합적으로 모니터링하는 시스템을 의미합니다. 해외에서는 일반적으로 ITIM(IT Infra Management)이라는 용어로 많이 사용되고 있지만, 국내에서는 EMS라는 용어로 통용되고 있습니다. EMS는 IT인프라의 데이터를 실시간으로 수집 및 분석할 뿐만 아니라, 수집된 데이터를 활용해 비즈니스의 가치를 창출할 수 있습니다. 글로벌 IT분야 연구자문 기업인 “가트너(Gartner)”에서는 ITIM, 즉 EMS를 데이터센터, Edge, IaaS(Infrastructure as a Service), PaaS(Platform as a Service) 등에 존재하는 IT인프라 구성요소의 상태와 리소스 사용률을 수집하는 도구로 정의하며, 컨테이너, 가상화시스템, 서버, 스토리지, 데이터베이스, 라우터, 네트워크 스위치 등에 대한 실시간 모니터링이 가능해야 한다고 서술합니다. <사진 설명: 가트너의 ITIM 정의를 도식화한 그림> 이러한 EMS는 초기에는 기업 전산실에 물리적인 형태로 존재하는 서버, 네트워크의 리소스관리를 중심으로 모니터링해 왔습니다. 서버의 CPU, Memory 등의 리소스 정보를 수집하거나, 네트워크 장비의 트래픽 정보를 모니터링하고 임계치를 기반으로 이벤트 감지하는 역할이 대부분이었으며, 이 정도 수준에서도 충분한 IT 인프라 관리가 이뤄질 수 있었습니다. 그러나 가상화(Virtualization)라는 개념이 생겨나고 다양한 IT 인프라들이 기업 전산실에서 클라우드(Cloud) 환경으로 전환됨에 따라, EMS의 모니터링 분야도 조금씩 바뀌어 가고 있습니다. 많은 기업들이 효율적인 리소스 사용과 비용 절감을 목표로 VMware와 같은 가상화 시스템을 도입해 운영하게 됐으며, 모니터링 부문도 이에 대응하기 위해 가상화 리소스에 대한 관리 영역으로 확장됐습니다. 가상화 환경을 이루는 하이퍼바이저(Hypervisor)와 가상머신(Virtual Machine)의 연관성을 추적하고, 각 가상머신들이 사용하고 있는 리소스를 실시간으로 분석해 효율적인 자원 배분, 즉 프로비저닝(Provisioning)을 위한 근거 데이터를 제공할 수 있도록 하고 있습니다. 더 나아가 VMware, Hyper-V 등의 다양한 가상화 플랫폼에서 가상머신을 생성하고 삭제하고, 실제로 가상머신에 CPU, Memory 등과 같은 리소스를 할당해 줄 수 있는 컨트롤 영역까지 제공하는 제품을 개발하는 벤더사들이 많아지고 있습니다. 이러한 가상화 기술을 기반으로 현대에는 IT 인프라들이 대부분 클라우드 환경으로 전환하고 있는 추세입니다. 클라우드 환경으로의 전환 클라우드(Cloud)란, 언제 어디서나 필요한 컴퓨팅 자원을 필요한 시간만큼 인터넷을 통해 활용할 수 있는 컴퓨팅 방식으로, 최근 기업들은 각자의 목적과 상황에 맞게 AWS, MS Azure와 같은 Public Cloud 및 OpenStack, Nutanix 등을 활용한 Private Cloud 등의 환경으로 기업의 전산설비들을 마이그레이션 하고 있습니다. 클라우드로의 전환과 기술의 발전에 따라, EMS의 IT 인프라 모니터링은 더 이상 *On-Premise 환경에서의 접근이 아닌, Cloud 환경, 특히 MSA(Micro Service Architecture)를 기반으로 하는 클라우드 네이티브(Cloud Native) 관점에서의 IT 운영 관리라는 새로운 접근이 필요하게 됐습니다. (*On-Premise : 기업이 서버를 클라우드 환경이 아닌 자체 설비로 보유하고 운영하는 형태) 클라우드 네이티브란, 클라우드 기반 구성요소를 클라우드 환경에 최적화된 방식으로 조립하기 위한 아키텍처로서, 마이크로서비스 기반의 개발환경, 그리고 컨테이너 중심의 애플리케이션 구동환경 위주의 클라우드를 의미합니다. 클라우드 네이티브는 IT비즈니스의 신속성을 위해 도커(Docker)와 같은 컨테이너를 기반으로 애플리케이션이 운영되므로, EMS는 컨테이너의 성능, 로그, 프로세스 및 파일시스템 등 세부적인 관찰과 이상징후를 판단할 수 있는 기능들이 요구되고 있습니다. 자사 제품인 Zenius SMS에서는 이러한 변화에 따라 Docker에 대한 모니터링 기능을 기본적으로 제공하고 있습니다. Docker 컨테이너가 생성되면 자동으로 관리대상으로 등록되며, Up/Down 뿐만 아니라, CPU, Memory, Network 및 Process의 정보를 실시간으로 모니터링하고 발생되는 로그들을 통합관리 할 수 있도록 합니다. <사진 설명: Zenius-SMS에서 제공하고 있는 Docker 컨테이너 모니터링 기능> 또, 복원력과 탄력성을 위해 쿠버네티스와 같은 오케스트레이션 도구를 활용해 컨테이너를 스핀업하고, 예상되는 성능에 맞게 효율적으로 리소스를 맵핑하고 있으며, 이러한 기술에 대응하기 위해 EMS는 쿠버네티스(Kubernetes), 도커스웜(Docker Swarm) 등의 오케스트레이터들의 동작여부를 직관적으로 관찰하는 제품들이 지속적으로 출시되고 있는 상황입니다. 이와 더불어 컨테이너, 오케스트레이터의 동적 연결관계를 실시간으로 모니터링하고, 파드(POD), 클러스터, 호스트 및 애플리케이션의 관계를 표현하는 역할의 중요성이 점차 커져가고 있습니다. 통합 모니터링(Monitoring) EMS 모니터링의 또 다른 변화로는 통합(Integration)의 역할이 더더욱 강해지고 있다는 것입니다. IT 서비스가 복잡해지고 다양해짐에 따라 IT 인프라의 관리 범위도 점차 증가하면서, 다양한 IT 인프라들을 융합하고 관리하기 위한 노력들이 관찰되고 있습니다. 데이터독(Datadog), 스플렁크(SPLUNK)와 같은 장비 관점의 모니터링 벤더들은 APM과 같은 애플리케이션 모니터링 시장으로, 앱다이나믹스(AppDynamics), 다이나트레이스(Dynatrace), 뉴렐릭(NewRelic)과 같은 애플리케이션 모니터링 시장의 강자들은 인프라 장비 관점의 모니터링 시장으로의 융합이 확인되고 있습니다. 자사 제품인 Zenius 역시 서버, 네트워크 중심의 관리에서 애플리케이션, 데이터베이스 등의 시장으로 관리 범위를 확장해 나가고 있는 추세입니다. IT 서비스의 영속성을 유지하기 위해서는 IT 서비스를 구성하는 다양한 요소들을 실시간으로 모니터링하고 연관관계를 추적해 문제 원인을 찾아내는 것이 중요하기 때문에 다양한 IT 요소들을 통합적으로 모니터링하는 것 뿐만 아니라, 상호 연관관계를 표현하고 추적할 수 있는 기능들이 지속적으로 요구되고 있습니다. 모니터링의 트렌드는 서버, 네트워크 등의 독립적인 개체에 대한 모니터링 아닌 IT 서비스를 중심으로 기반 요소들을 모두 통합적으로 모니터링하고, 각 상호간의 의존성과 영향도를 파악해 RCA(Root Cause Analysis) 분석을 가능하게 하고 이를 통해 IT 서비스의 연속성을 보장할 수 있는 통찰력을 확보하게끔 하는 방향으로 흘러가고 있습니다. Zenius는 서버, 네트워크, 애플리케이션, 데이터베이스 및 각종 로그들의 정보를 시각적으로 통합 모니터링할 수 있는 오버뷰(Overview) 도구와 IT 서비스 레벨에서 인프라들의 연관관계를 정의하고 다양한 조건(Rule)에 따라 서비스 이상유무와 원인분석이 가능한 서비스 맵(Service Map) 도구를 기본적으로 제공하고 있습니다. <사진 설명: Zenius 오버뷰 화면> <사진 설명: Zenius 서비스맵 화면> 앞서 언급했듯이, 클라우드 환경으로 전환함에 따라 통합적 관리 요구는 더욱 높아지고 있습니다. IT 인프라에 대한 통합 뿐만 아니라, AD(Active Directory), SAP 및 AWS, Azure, GCP 등의 다양한 서비스의 주요 지표까지 연계하고 하나의 시스템으로 통합 모니터링하기 위한 노력들이 관찰되고 있습니다. 데이터독(Datadog)의 경우, 500개 이상의 시스템, 애플리케이션 및 서비스들의 지표들을 손쉽게 통합 관리할 수 있다고 돼있습니다. <사진 설명: 데이터독 홈페이지 캡처> 이처럼 IT 서비스의 복잡성과 다양화에 따라 관리해야 될 서비스와 지표들은 점점 늘어나고 있으며, 기업의 현황에 맞게 컴포넌트 기반으로 손쉽게 지표들을 통합할 수 있는 기능과 도구들이 요구되고 있습니다. AI 기반의 예측&자동화 모니터링의 세번째 변화로는 ’AI 기반의 예측과 자동화’입니다. IT 인프라 및 서비스의 주요 지표를 모니터링하는 것도 중요하지만, 축적된 데이터를 기반으로 미래의 상황을 예측 및 이상탐지해 사전에 대비할 수 있는 체계를 갖추는 일은 모니터링 시장에서 중요한 이슈로 자리잡고 있습니다. 현재의 AIOps(AI for IT Operations)를 표방하는 모니터링 기술들은 서버, 네트워크, 애플리케이션, 데이터베이스 등의 주요 지표들을 실시간으로 수집하고, 저장된 데이터를 기반으로 AI 알고리즘 또는 통계기법을 통해 미래데이터를 예측하며 장애 발생가능성을 제공하고 있습니다. 이와 같은 기술을 통해 미래 성능 값을 예측해 IT 인프라의 증설 필요성 등을 판단하고, 장애 예측으로 크리티컬한 문제가 발생되기 전에 미리 조치를 취할 수 있도록 해 효율적인 의사결정을 할 수 있도록 합니다. Zenius도 4차 산업혁명 및 디지털 뉴딜시대가 도래함에 따라 미래예측 기능을 최신 버전에 탑재했으며, 이를 통해 IT운영자가 미래 상황에 유연하고 선제적으로 대응할 수 있도록 합니다. Zenius에서는 서버, 네트워크, 애플리케이션 등 다양한 IT 인프라의 미래 성능 값, 패턴 범위, 이상 범위 등을 예측해 IT 운영자에게 제시합니다. <사진 설명: 인공지능(AI) 기반 미래데이터 예측 화면> 다만, 인공지능 기술을 통해 장애 발생 가능성을 탐지하는 기능 외에, 어디에 문제가 발생됐는지 알려주는 기능은 모니터링 시장에 과제로 남아있고, 이를 제공하기 위한 여러 업체들의 노력이 보이고 있습니다. 이제는 EMS에서 보편적인 것이 됐지만, 모바일 기기를 통해 시∙공간적 제약 없는 모니터링이 이뤄지고 있습니다. 다양한 기종의 스마트폰, 태블릿PC 등을 이용해 운영콘솔(Console) 뿐만 아니라, 회의 등 시간을 잠시 비우더라도 IT 인프라에 대한 연속적인 모니터링이 모바일기기를 통해 가능해졌습니다. <사진 설명: 다양한 기기를 통한 모니터링> 2022.09.05

기술이야기 [Zenius Case#1] 내일까지 서버관리 현황 부탁할게요! 기술이야기 [Zenius Case#1] 내일까지 서버관리 현황 부탁할게요! 퇴근을 준비하는 어느 날, 부장님이 갑자기 요청합니다. “내일까지 서버관리 전반 현황 보고해야 되니 준비 부탁할게! 그럼 고생하고 낼 보자고” 어떤 내용들로 자료를 준비해야 하는 걸까요? 이번에는 Zenius SMS를 활용한 서버관리현황 파악에 대해 살펴보겠습니다. 서버관리 현황 파악의 포인트 1. 얼마나 많은 대상을 관리하고 있으며 종류는 어떤 것이 있는가? 2. 관리가 필요한 주요 성능지표 항목은 어떤 것이 있는가? 3. 주요 성능지표 관련해 현재 상태는 어떠한가? 4. 이슈가 존재하는 서버의 현황과 어떤 이슈를 가지고 있는가? 5. 어떻게 필요한 자료를 쉽고 빨리 확보해 보고할 것인가? 6. 향후 지속적으로 제공 가능한 범위인가?(내일까지 해야 하는데….) 7. 추가적인 요청사항에 대한 대응이 가능한가? 상기 사항들 모두 중요하지만, 그 중에서도 “지속적으로 제공 및 관리가 가능한가?”라는 부분에 집중해야 합니다. 아무리 훌륭한 자료라도 자료구성을 위해 과도한 공수가 발생하는 자료는 사실상 향후 지속적인 관리측면에서 실효성을 상실하게 돼 1회성 보고자료로 끝나게 되는게 현실입니다. 실제 업무에 필요한 자료는 지속적인 관리가 가능해야만 합니다. Zenius로 1분 만에 서버현황 보고자료 정리하기 Step 1. 기본 데이터 취득(10초) Step 2. 현황정보 정리(10초) 저희가 운영하는 대상은Total 12대입니다. OS 별로 Linux 6, Solaris 1, AIX 1, HPUX 1, Window 3 관리 운영 중에 있습니다. Step 3. 주요 성능지표의 상태정리(20초) 먼저 서버(OS) 측면의 주요 성능지표에 대해 알아보도록 하겠습니다. 정보시스템 성능관리 지침에서는 서버 성능관리의 목적을 아래와 같이 정의하고 있습니다. 서버 성능관리의 목적 “서버 성능관리 업무는 최적의 용량을 적시에 확보하기 위한 용량계획의 시점을 제공하고 성능 관련 문제를 사전에 예방함으로써, 사용자의 시스템 활용도 및 만족도를 향상시키기 위하여 수행된다.” 또한 정보시스템 성능관리 지침에서 서버의 주요 성능관리 구성요소는 아래와 같이 정의하고 있습니다. 구성요소 내용 CPU 총 CPU사용률, 시스템 모드 사용률, 사용자 모드 사용률, Run Queue, Pri Queue, 사용자수 등 메모리 총 메모리 사용률, 시스템 및 버퍼 캐쉬, Page In/Out, Swap 공간 사용률 등 디스크 Disk 사용률, Disk I/O Busy, Disk Queue 프로세스 CPU를 집중적으로 사용하는 프로세스, Zombie 프로세스 커널 커널 파라미터 설정을 통한 자원의 적절한 분배 파일시스템 파일시스템 IO Rate, 파일시스템 공간 사용률 네트워크 I/O In 패킷률, Out 패킷률, Collision률, Error률 해당 성능관리 구성요소 중 실제 시스템운영 시 체크가 필요한 몇 개 항목에 대해 간단히 정의하고 넘어가겠습니다. CPU 사용률(%) 서버의 성능을 의미하는 척도로 사용되는 항목으로 CPU의 사용률이 일정 이상을 넘어가면 서비스에 영향을 주기 시작합니다. 순간적으로 급격히 높아질 수 있기 때문에 일반적으로 임계값과 지속시간을 함께 지정해 감시합니다. *여기서 CPU란? Central Processing Unit의 약자로 명령을 해독하고 산술논리연산이나 데이터 처리를 실행하는 장치입니다. Memory 사용률(%) 메모리의 사용량이 너무 빨리 소모되거나 또는 지속적으로 사용량이 떨어지지 않는다면 조치가 필요한 부분입니다. *여기서 Memory란? 기억소자를 지칭하는 것으로 보다 빠른 처리를 위한 프로그램 또는 데이터를 저장하거나 계산된 결과를 임시 또는 반영구적으로 보관하는 기억장치입니다. Disk I/O Busy Rate(%) Disk의 경우 데이터 처리 속도가 메모리나 CPU에 비해 너무 느리기 때문에 Disk I/O Busy Rate의 경우 일정 임계치 이상 지속되는 경우 과다한 입출력이 발생시킴을 의미하며 시스템 성능에 영향을 줄 수 있습니다. *여기서 Disk I/O란? Disk의 입출력 양을 의미합니다. 이제 기본 취득 데이터 기준 주요 성능지표를 정리해 보겠습니다. CPU 사용률(%) 저희가 운영하는 서버 중 CPU 사용률은 다음과 같으며, CPU 사용률이 가장 높은 대상은 Cent7x64 장비입니다. 전일 기준 Peak 치가 59% 정도이며 현재 36%정도의 사용률을 보입니다. Memory 사용률(%) Memory 사용률 현황은 다음과 같으며, Memory 사용률이 가장 높은 대상은 Solaris11 장비 입니다. 전일 기준 Peak 치가 97% 정도이며 현재도 96%정도의 사용률을 보입니다. 해당 장비의 경우 상세분석 진행 예정입니다. Disk I/O Busy Rate(%) Disk I/O Busy Rate 기준으로 모니터링이 필요한 대상은 다음과 같으며 현재 전반 양호한 상태입니다. 가장 높은 대상은 Zenius6.1 장비입니다. 현재 37% 정도를 보이고 있으며 한시적 증가로 요소가 존재하는 상태입니다. 저장장치 사용률(%) 저장장치 사용률의 경우 시스템 전체의 사용률보다는 파티션 별 사용률 관점에서 정리가 필요합니다. 95% 이상 사용중인 파티션 영역이 존재하고, AIX72-ORA, Suse11-x64, Solaris11 장비의 경우 현재 조치 진행 중이며 용량증설 계획도 함께 고려하고 있습니다. Step 4. 이슈사항 정리(20초) 전체관리대상 중 긴급 1건, 위험 4건, 주위 4건의 이슈가 발생해 있는 상태이며 등급 별 상세내역은 다음과 같습니다. 이슈 발생 후 지속시간 2일 이상 지속중인 항목들은 단기 조치 불가 항목으로 조치방안에 대해 논의중인 항목입니다. 이상으로 Zenius를 활용해 1분만에 서버현황 보고자료를 구성해봤습니다. 그럼 이제 다음과 같이 보고를 진행했을 때 추가적으로 유입될 수 있는 요청사항을 Zenius SMS를 활용해 대응해보겠습니다. Zenius SMS를 활용해 추가 요청사항 대응하기 Q. CPU 사용률 높은 장비의 CPU 추이는 어떤가요? 전반 추이와 전일 대비 사용률을 확인해볼 필요가 있습니다. A. 해당장비의 CPU 사용률 추이는 다음과 같으며 전일대비 비교 했을 때 거의 유사한 범위내에 사용률 추이를 보여주고 있습니다. 3단계의 임계라인 기준으로 감시를 수행하고 있습니다. Q. 특정 파티션의 파일시스템 사용률이 높은 장비의 타 파티션의 사용률은 얼마나 되나요? 저장장치 사용률 추이도 함께 검토가 필요해보입니다. A. /nshome40 96% 이외 /home 파티션도 사용률이 90% 이상인 상태입니다. 사용률 추이를 확인했을 때 급격한 증가는 발생하지 않는 상태입니다. 2022.09.02