디딤나우(DidimNow) 모니터링을 활용한 서비스 개선사례

2020. 06. 30 | 블로그

안녕하세요 디딤365입니다.

인프라 및 서버 관리를 진행하기 위해서는 모니터링 업무가 매우 중요합니다. 저희 디딤365에서는 자체 개발한 디딤나우를 통해 실시간 모니터링을 진행하고 있는데요, 디딤나우는 디딤365 서비스를 이용하는 고객들에게 무료로 제공하는 클라우드 관리 플랫폼(CMP)입니다.

그 중 디딤나우 모니터링을 활용한 대표적인 서비스 개선사례들을 선정했습니다.

CPU

user : 사용자가 사용중인 사용률

system : 시스템이 사용중인 사용률

nice : nice는 프로세스의 우선순위가 기본값보다 낮은 우선순위로 사용자 공간에서 실행된 시간

idle(유휴) : 어떠한 프로그램에 의해서도 사용되지 않는 상태

– 유휴 상태 : CPU가 휴식 중인 상태

리눅스 시스템을 운영하다 보면 서버 로드에 대한 척도를 가늠하기 위해 uptime 또는 top과 같은 명령어를 이용해 CPU Load를 확인하게 됩니다. 이때 나타나는 CPU Load 수치는 아래와 같이 1Min, 5Min 15Min 단위의 평균 값을 나타내게 되는데 이 값이 적게는 0.00에서 크게는 400.0 까지 올라가는 경우도 있습니다.

load average: 0.00, 0.01, 0.00

윈도우의 경우에는 CPU Core 별로 퍼센테이지(%)로 사용량을 보여주기 때문에 이해하기가 쉽지만, 리눅스의 경우에는 얼마나 CPU 자원을 사용하는지 이해하기 어려운 경우가 발생합니다.

이에 CPU Load에 대해 간단히 설명을 하고자 합니다.

① Single CPU를 사용하고 있는 경우

예를 들자면 CPU 하나의 사용량을 도로 위의 차량통행량으로 비교하겠습니다.

하나의 CPU라는 것은 자동차가 지나갈 수 있는 도로가 1개라는 이야기이며, 하나의 도로에 지나가는 차량의 대수가 많을수록 CPU의 로드가 올라간다고 보면 됩니다.

• CPU Load가 0.00 일 경우

CPU라는 도로를 달리는 자동차(Work)가 없다는 것을 의미

• CPU Load가 0.50 일 경우

CPU라는 도로를 달리는 자동차(Work)가 있지만, CPU에서 처리 가능한 통행량의 50% 정도 수준이라 볼 수 있음

• CPU Load가 1.00 일 경우

CPU라는 도로를 달리는 자동차(Work)가 CPU에서 처리가능한 통행량의 100%를 차지하고 있다는 내용으로 볼 수 있음

• CPU Load가 1.70 일 경우

CPU 라는 도로를 달리는 자동차(Work)가 CPU에서 처리가능한 통행량의 170%를 차지 하고 있음. 당연히 허용가능 수준인 100%를 넘었으므로, 교통체증(Load)이 발생할 수 밖에 없음

하나의 CPU에서 처리가능한 100%의 기준은 CPU Load의 1.00을 바탕으로 합니다. Single CPU인 상태에서 서버의 Load 값이 1.00을 넘어선다면 현재 CPU에 부하가 걸려 실제 처리 가능한 속도보다 느리게 처리되고 있는 상태입니다.

② Multicore CPU를 사용하고 있는 경우

만약 Single CPU가 아니라 Multicore CPU를 사용하고 있는 경우라면 어떨까요? Multicore CPU라고 하더라도 CPU 사용률 100%에 대한 지수가 1.00인 것에는 변함이 없습니다.

다만, MultiCore일 경우 Core 개수 X 1.00 지수로 계산이 되며, Quad core CPU일 경우에는 4.00을 CPU 100% 사용에 대한 지표로 볼 수 있습니다. 즉, QuadCore CPU를 2CPU로 장착한 경우에는 8.00이 100%의 지표가 되는 것 입니다.

정리하자면, Core 1개의 100% 지표는 1.00이며, 시스템상에서 인식되는 Core 개수(HT 포함)를 곱하면 최종적으로 해당 서버의 MAX CPU Load 값을 알 수 있습니다.

다만, 주의해야 할 것은 MAX CPU Load를 넘어선다고 하여 Server가 동작하지 않는 것은 아니지만, 일부 프로세서 처리에 Load가 걸릴 수 있다는 것이며, 원활한 서버 운영을 위해서는 15Min의 CPU Load가 꾸준히 MAX CPU Load의 80~90% 정도 이하 수준에 머무르는 것이 안정적이라고 볼 수 있습니다.

Memory & Swap

Memory : CPU에 처리할 데이터를 보관하는 저장소(물리적인 RAM)

total : Memory 총 용량

used (+buffer/cache) : 시스템에서 사용하고 있는 메모리 총량(버퍼와 캐시된 데이터의 크기까지 포함)

used (-buffer/cache) : 시스템에서 사용하고 있는 메모리 총량(버퍼와 캐시된 데이터 크기를 제외한 크기)

Swap : Memory 용량이 가득 차게 될 경우 사용되는 여유 공간(하드 디스크의 공간을 사용)

total : Swap 총 용량

used : Swap 사용량

free : Swap 잔여량

① Memory 증설 여부 판단

Memory증설 판단은 Memory 사용량과 Swap 사용량을 확인하여 판단이 가능합니다.

위 Memory 그래프와 Swap 그래프를 보시면 Memory를 모두 사용하고 Swap까지 사용 중이므로 Memory 용량

이 부족하다고 판단할 수 있습니다. Swap공간을 확장하여 해결이 가능할 수 있지만 Swap은 하드 디스크의 공간을 사용하여 Memory에 비해 속도가 매우 느리기 때문에 임시적으로 사용은 가능하나 시스템 퍼포먼스를 생각했을 때 결코 권장드리는 방법은 아닙니다. 또 Memory사용량이 순간적인 것이 아닌 장시간 유지되고 있기 때문에 Memory 증설이 필요한 사유가 되었습니다.

TCP Connections

TCP Connections 그래프는 TCP 접속 상태를 모니터링 합니다.

Established : 연결이 완료된 상태

TIME_WAIT : 연결 종료 후 일정 시간 동안 유지

CLOSE_WAIT : 종료 대기 중

Total : Established + TIME_WAIT + CLOSE_WAIT

TCP Connections 그래프의 Total값을 통해 서버에 사용자 접속량을 확인할 수 있으며 웹 사이트를 운영하는 웹 서버는 웹 페이지 접속량으로도 볼 수 있습니다. 위 그래프는 웹 쇼핑몰을 운영 중인 서버에서 이벤트를 진행한 날의 그래프입니다. 이 쇼핑몰은 오전 11시부터 오후 2시까지 이벤트를 진행하였으며 그래프를 보시면 해당 시간 때에 접속량이 급증한 것을 확인 가능합니다.

이렇게 접속량이 급증할 경우 서버에 많은 부하가 걸리며 사이트 속도가 느려지다가 마지막에는 사이트가 열리지 않는 현상까지 발생을 하게 됩니다. 이 쇼핑몰을 운영 중인 고객님은 이벤트 진행 전 서버 사양을 최대로 확장 요청을 주셨으며 서버 사양을 최대로 확장한 결과 이벤트 시간 동안 어떠한 장애 없이 이벤트를 무사히 마칠 수 있었습니다. 서버 사양은 이벤트 종료 후 기존에 사용하시던 사양으로 축소를 진행해드렸습니다.

Mail Queue Length

Mail Queue Length 그래프는 서버에서 메일 발송을 위해 대기 중인 메일 수를 확인이 가능합니다.

메일 서비스는 대부분 Sendmail을 사용하여 폼 메일을 발송하고 있으며 폼 메일을 사용하지 않거나 문제가 없는 서버는 위 그래프에 사용량이 그래프 상에 표시되지 않습니다.

위 그래프처럼 Mail Queue 그래프 상 확인되는 경우는 발송하려는 메일이 차단이 되어 발송하지 못할 때 발생합니다. 대표적으로 스팸 메일로 인해 차단되는 경우가 있으며 차단을 해제 후 순차적으로 메일 발송이 되신 것을 모니터링상 확인 가능합니다.

Disk Inode Utilization

inode는 각 파티션에 파일 및 폴더를 최대로 생성 가능한 수를 의미합니다.

디스크 용량이 남아 있더라도 inode 개수를 최대치를 넘게 되면 디스크 Full과 마찬가지로 사용할 공간이 없다고 오류가 발생합니다.

지금까지 디딤나우 모니터링을 활용한 서비스 개선사례들을 알아봤습니다. 저희 디딤365는 고객들이 안전하게 디딤나우를 사용하실 수 있도록 무중단 모니터링과 함께 고객지원을 아끼지 않겠습니다. 감사합니다.

<작성>

시스템통합운영센터 정지훈 팀장

시스템통합운영센터 류아린 주임

시스템통합운영센터 이승준

<편집>

전략사업본부 조항준 주임