기술이야기 | 브레인즈컴퍼니

주메뉴 바로가기 본문 바로가기

메인 페이지로 이동
블로그
기술이야기

블로그

기술이야기

기술이야기 Zenius GPM으로 범정부 예방점검 WAS 일상점검 체계 구성하는 방법 기술이야기 Zenius GPM으로 범정부 예방점검 WAS 일상점검 체계 구성하는 방법 공공기관 정보시스템 운영에서 예방점검은 정해진 항목을 확인하는 데 그치지 않고, 시스템 상태를 지속적으로 점검하고 그 결과를 체계적으로 관리하기 위한 기본 운영 절차입니다. 특히 WAS(Web Application Server)는 웹 애플리케이션의 로직과 요청 처리를 담당하는 주요 구성요소인 만큼 CPU·메모리 사용률, JVM Heap Memory, Thread, DB Connection Pool 등 다양한 상태를 정기적으로 확인할 필요가 있습니다. 다만 점검해야 할 항목이 많고 시스템마다 확인 방식도 다르기 때문에, 담당자가 매번 항목별 상태를 직접 확인하고 결과를 기록하는 방식은 반복 업무를 늘리고 점검 결과 관리의 부담으로 이어질 수 있습니다. 따라서 예방점검 업무를 보다 일관되고 체계적으로 운영하려면, 점검 항목 설정부터 실행 결과 확인, 이력 관리, 보고까지 하나의 흐름으로 관리할 수 있는 전문 솔루션을 활용하는 것이 효과적입니다. Zenius GPM은 행정안전부의 범정부 정보시스템 예방점검 매뉴얼을 기반으로 WAS를 포함한 주요 IT 자원의 예방점검을 자동·수동 방식으로 수행하고, 점검 결과와 이력, 보고서를 함께 관리할 수 있도록 지원합니다. Zenius GPM을 활용해 예방점검 체계를 구성하기 위해서는 먼저 WAS 영역에서 어떤 항목을 점검하고, 각 항목이 어떤 상태를 확인하기 위한 것인지 살펴볼 필요가 있습니다. 범정부 예방점검의 WAS 점검 항목부터 확인해보겠습니다. WAS 예방점검에서는 어떤 항목을 확인할까? 범정부 정보시스템 예방점검체계에서는 WAS 영역에 대해 프로세스 CPU·메모리 사용률, JVM Heap Memory, Thread Pool, DB Connection Pool, Dump 파일 등 다양한 점검 항목을 제시하고 있습니다. 범정부 정보시스템 예방점검체계 WAS 영역 점검 항목 이처럼 WAS 예방점검은 단순히 애플리케이션의 동작 여부만 확인하는 것이 아니라, WAS 프로세스와 JVM 자원, Thread, DB Connection 등 서비스 운영에 영향을 줄 수 있는 여러 항목을 함께 살펴보는 것이 중요합니다. 또한 각 점검 항목마다 확인해야 하는 정보와 점검 방식이 다를 수 있기 때문에, 실제 운영 환경에서는 점검 대상과 항목을 먼저 구성하고 각 항목에 맞는 점검 방법과 판정 기준을 설정해야 합니다. Zenius GPM에서는 이러한 과정을 예방점검 기능 활성화부터 대상 및 항목 등록, 세부 설정, 결과 확인, 보고서 관리까지 단계적으로 구성할 수 있습니다. 이제 실제 화면을 통해 WAS 일상점검을 어떻게 설정하는지 살펴보겠습니다. Zenius GPM으로 WAS 일상점검 구성하기 WAS 일상점검은 대상 및 항목 등록, 세부 설정, 결과 확인, 보고서 관리 순으로 구성할 수 있습니다. 먼저 예방점검 기능을 활성화하는 단계부터 살펴보겠습니다. Step 1. WAS 일상점검 대상과 항목을 등록합니다: [예방점검 > 설정 > 일상점검] 일상점검 설정 화면에서 WAS에 적용할 점검 항목을 선택하고 대상 시스템을 지정합니다. - 분류: WAS - 대상: SMS 및 APM 인스턴스 선택 WAS 점검 항목 중에는 APM 정보뿐 아니라 OS단 정보가 필요한 항목도 포함되어 있기 때문에, 어떤 대상을 선택하느냐에 따라 일부 점검 항목의 처리 방식이 달라집니다. WAS 일상점검 대상 등록 화면 여기서 확인해야 할 부분은 APM만 선택한 경우와 SMS·APM을 함께 선택한 경우 OS단 점검 항목의 상태가 서로 다르게 표시된다는 점입니다. APM만 선택하면 OS단 점검 항목은 수동점검으로 전환됩니다 APM 인스턴스만 선택하면 OS단 점검 항목은 수동점검으로 전환됩니다. 해당 항목은 운영자가 점검 결과를 직접 확인하고 정상 여부를 판단하는 방식으로 운영됩니다. APM만 선택했을 때 수동점검으로 전환된 항목 SMS와 APM을 함께 선택하면 추가 설정이 필요한 항목을 확인할 수 있습니다 SMS와 APM 인스턴스를 함께 선택하면 OS단 점검 항목은 미완성(정보 확인 모드) 상태로 표시됩니다. 미완성으로 표시된 항목은 실제 운영 환경에 맞게 세부 설정을 진행해야 합니다. 첨부 원고 기준으로 이러한 항목은 SMS를 통해 점검하는 항목으로, 추가적인 수동 설정이 필요합니다. SMS·APM 동시 선택 시 점검 항목 상태 대상과 항목을 등록했다면, 다음으로 미완성 상태의 점검 항목을 실제 환경에 맞게 설정합니다. Step 2. 미완성 점검 항목을 운영 환경에 맞게 설정합니다: [예방점검 > 설정 > 일상점검] 미완성 상태로 표시된 항목은 실제 운영 환경에 맞게 점검 방식과 결과 판정 방식을 설정합니다. 점검 방법 - Zenius: Zenius에서 수집하는 데이터를 기반으로 점검합니다. - 전체 데이터 실행: 입력한 전체 명령어를 실행하여 점검합니다. 점검 결과 판정 방식 - 자동: 설정된 점검 기준에 따라 Zenius 시스템이 실행 결과의 정상 여부를 자동으로 판단합니다. - 수동: 운영자가 점검 결과를 직접 확인하고 정상 여부를 판단합니다. 또한 점검 결과에 포함할 내용도 항목별로 설정할 수 있습니다. 필요한 결과만 지정하거나 해당 점검에서 수집된 전체 내용을 결과로 활용하도록 구성할 수 있습니다. WAS 예방점검 항목 상세 설정 화면 이처럼 항목별 점검 방식과 판정 기준을 설정하면 실제 운영 환경에 맞는 WAS 일상점검 구성을 완료할 수 있습니다.설정이 끝났다면 이제 실제 예방점검 결과를 확인할 차례입니다. Step 3. WAS 일상점검 결과를 확인합니다: [예방점검 > 모니터링] 점검 항목 설정이 완료되면 예방점검을 실행한 뒤 결과를 확인합니다. Zenius GPM에서는 전체 점검 결과를 한눈에 확인하는 요약 화면과 항목별 결과를 상세하게 조회하는 화면을 함께 제공합니다. 따라서 전체 현황 확인 → 대상별 이력 확인 → 항목별 결과 확인 → 상세 내용 확인의 순서로 결과를 살펴볼 수 있습니다. 일상점검 요약에서 전체 결과를 확인합니다: [예방점검 > 모니터링 > 일상점검 요약] 일상점검 요약 화면에서는 WAS를 포함한 분류별 점검 결과와 점검 실행 현황을 한눈에 확인할 수 있습니다. 운영자는 먼저 전체 결과를 확인해 정상·이상 여부와 추가 확인이 필요한 대상이 있는지 파악할 수 있습니다. 일상점검 요약 화면 전체 현황에서 확인이 필요한 대상을 찾았다면 해당 대상의 실행 이력을 좀 더 구체적으로 살펴볼 수 있습니다. 대상별 점검 실행 이력을 확인합니다: [예방점검 > 모니터링 > 일상점검 요약] 요약 화면에서 특정 점검 또는 대상 항목을 클릭하면 해당 대상의 점검 실행 이력을 상세하게 확인할 수 있습니다. 이를 통해 대상별로 어떤 점검이 언제 수행되었는지와 해당 점검의 실행 이력을 확인할 수 있습니다. 점검 실행 이력 상세 화면 점검 실행 이력을 확인했다면 다음으로 개별 항목의 정상·이상 여부와 과거 결과를 확인합니다. 항목별 정상·이상 여부와 과거 이력을 확인합니다: [예방점검 > 모니터링 > 일상점검 현황] 일상점검 현황에서는 점검 항목별 정상·이상 여부를 확인할 수 있습니다. 또한 점검일을 선택하면 과거에 수행했던 예방점검 결과도 조회할 수 있습니다. 이를 통해 현재 결과뿐 아니라 과거 점검 이력도 함께 확인할 수 있어 시점별 상태를 비교하는 데 활용할 수 있습니다. 일상점검 항목별 결과 및 과거 이력 화면 특정 항목의 결과를 더 자세히 확인해야 한다면 개별 점검 결과 상세 화면으로 이동합니다. 개별 점검 결과의 상세 내용을 확인합니다: [예방점검 > 모니터링 > 일상점검 현황] 특정 점검 항목을 클릭하면 해당 항목의 점검 결과를 상세하게 확인할 수 있습니다. 단순히 정상·이상 여부만 확인하는 것이 아니라 실제 점검 결과와 세부 내용을 함께 확인할 수 있어 해당 항목의 상태를 보다 구체적으로 살펴볼 수 있습니다. 개별 예방점검 결과 상세 화면 이처럼 전체 결과에서 시작해 대상, 항목, 상세 결과까지 단계적으로 확인하면 필요한 점검 정보를 보다 체계적으로 살펴볼 수 있습니다. 점검 결과를 확인했다면 마지막으로 필요한 결과를 보고서로 정리하고 이력으로 관리할 수 있습니다. Step 4. 예방점검 보고서를 등록합니다: [예방점검 > 보고서 > 설정] 점검 결과를 정기적으로 관리하거나 공유해야 하는 경우 보고서 설정 기능을 활용할 수 있습니다. 보고서 설정 화면에서는 필요한 보고서 유형과 대상 등을 지정해 다양한 종류의 보고서를 등록할 수 있습니다. 이를 통해 일상점검 결과를 화면에서 확인하는 데 그치지 않고 이후 보고서 생성과 이력 관리로 이어질 수 있도록 사전에 보고서 유형을 구성할 수 있습니다. 예방점검 보고서 등록 화면 보고서 설정이 완료되면 등록한 내용을 기준으로 실제 보고서를 생성합니다. Step 5. 등록한 설정을 바탕으로 보고서를 생성합니다: [예방점검 > 보고서 > 설정] 등록한 보고서를 선택해 실제 보고서를 생성할 수 있습니다. 반복적인 예방점검 업무에서는 점검 결과를 확인하는 것뿐 아니라 결과를 일정한 형태로 정리하고 관리하는 과정도 중요합니다. Zenius GPM에서는 등록한 보고서를 기준으로 필요한 보고서를 생성할 수 있습니다. 예방점검 보고서 생성 화면 생성된 보고서는 이후 다시 확인할 수 있도록 생성 이력으로 관리됩니다. Step 6. 생성한 보고서와 과거 이력을 확인합니다: [예방점검 > 보고서 > 생성이력] 생성된 보고서는 생성이력 화면에서 확인할 수 있습니다. 운영자는 과거에 생성한 보고서의 이력을 조회하고 필요한 보고서 파일을 다시 확인할 수 있습니다. 이를 통해 예방점검 결과를 당일 확인하는 데 그치지 않고 시점별 보고서 이력을 지속적으로 관리할 수 있습니다. 예방점검 보고서 생성 이력 화면 여기까지가 Zenius GPM에서 WAS 일상점검을 구성하고, 결과를 확인한 뒤 보고서로 관리하는 기본 흐름입니다. 그렇다면 이러한 기능은 실제 운영 환경에서 어떤 경우에 활용할 수 있을까요? Zenius GPM의 WAS 예방점검 활용 케이스 Case 1. 범정부 예방점검 일상점검을 지속적으로 수행해야 하는 경우 범정부 정보시스템 예방점검 기준에 따라 일상점검을 수행해야 하는 환경에서는 반복적으로 여러 점검 항목을 확인하고 결과를 기록해야 합니다. Zenius GPM을 활용하면 설정한 예방점검 항목을 기준으로 자동·수동 점검을 수행하고, 일상점검 현황에서 결과를 한눈에 확인할 수 있습니다. 운영자가 매일 개별 항목을 직접 찾아 확인하는 부담을 줄이고, 필요한 항목을 중심으로 점검할 수 있어 예방점검 업무를 보다 체계적으로 수행할 수 있습니다. WAS 일상점검 결과 예시 Case 2. WAS의 주요 상태를 지속적으로 점검해야 하는 경우 WAS는 실제 웹 서비스 요청을 처리하는 주요 구성요소이기 때문에 장애 발생 이후 대응하는 것뿐 아니라 주요 상태를 지속적으로 점검하는 것이 중요합니다. Zenius GPM에서는 CPU·메모리, JVM Heap Memory, Thread, DB Connection Pool 등 WAS 운영과 관련된 주요 항목을 예방점검 항목으로 구성할 수 있습니다. 점검 결과의 정상·이상 여부와 과거 이력을 함께 확인할 수 있어 현재 상태뿐 아니라 이전 점검 결과도 함께 살펴볼 수 있습니다. 이를 통해 WAS 운영자는 일상점검 절차를 일정한 기준에 따라 수행하고, 필요한 항목을 중심으로 결과를 확인할 수 있습니다. 고객사 적용 사례 ○○원 예방점검 구축을 통한 범정부 예방점검 체계 구성 해당 기관은 범정부 정보시스템 예방점검 기준에 따라 WAS를 포함한 주요 IT 자원의 일상점검을 지속적으로 수행하고 관리할 수 있는 체계가 필요했습니다. Zenius GPM을 통해 예방점검 항목과 실행 방식을 구성하고, 점검 결과를 요약 화면과 상세 화면에서 확인할 수 있도록 운영 환경을 구축했습니다. 또한 과거 점검 이력과 보고서를 함께 관리함으로써 예방점검 결과 확인부터 이력 관리, 보고까지 하나의 흐름으로 수행할 수 있게 되었습니다. 반복 점검에서 체계적인 예방점검 운영으로 예방점검은 단순히 점검 항목을 확인하는 것보다 정해진 기준에 따라 지속적으로 실행하고, 결과와 이력을 체계적으로 관리하는 것이 중요합니다. Zenius GPM을 활용하면 범정부 예방점검 기준에 맞춰 WAS 일상점검을 구성하고, 점검 실행부터 결과 확인, 이력 관리, 보고서 생성까지 하나의 흐름으로 운영할 수 있습니다. 이를 통해 반복적인 점검 업무의 부담을 줄이고, 보다 체계적인 예방점검 환경을 구축할 수 있습니다. 2026.09.28
기술이야기 [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

1