|
어느 정도 규모 있는 시스템을 운영하게 되면 필연적으로 문제를 만나게 됩니다.
특히 책에 소개된 기본 모니터링 명령어들은 실제로 자주 사용하고 있긴 하지만 자바 어플리케이션 트러블 슈팅 부분은 보다 전문적입니다.
|
|
저자가 다양한 시스템 문제를 겪어 본 후 발간된 책 답게 각종 장애 상황에 대해 현상부터 결론까지 잘 정리되어있다. |
|
프로젝트 진행 중에도 그렇지만, 막바지 테스트 기간이나 완료 후 유지보수 기간에는 특히나 시스템의 안정성이 가장 신경이 쓰인다. 사람 몸에 이상 증세가 생겼을 때처럼 일부 프로그램 영역이나 전반적인 시스템에 예상치 못한 문제가 발생했을 경우 해결을 위해서 빠르게 원인을 찾는 것이 중요하다. 이를 위해서 실무자는 효율적이고 효과적인 진단법을 알고 있어야한다. 문제가 발생했을 경우 다양한 진단툴의 효과적인 사용과 시스템을 다루는 스킬이 복합적으로 필요하지만, 다양한 변수가 많다보니 생각보다 쉽지가 않다. 그런 면에서 이 책은 자바 개발자와 관련 시스템 운영자에게 실용적인 가이드가 되어줄 수 있는 책이다.
|
|
"자바 개발자와 시스템 운영자를 위한 트러블 슈팅 이야기" |
|
지금까지 여러 프로젝트를 참여해 봤지만 실력 있는 개발자들은 프로그램 실력뿐만 아니라 대부분 OS, WAS, 네트워크 등에도 뛰어난 지식과 실력을 보유하고 있었다. 하지만 의외로 개발경력이 몇 년 정도 되었음에도 리눅스(유닉스) 명령어 ls조차 모르고 있는 자바개발자도 있었다. 과연 그러한 개발자가 시스템에 대한 이해 없이 성공할 수 있을까?
개인적으로 이 책은 시스템 운영자 보다는 자바 개발자가 시스템을 이해하고 자신의 능력을 키우는데 필요한 서적이 아닐까 생각한다.
제목에서 알 수 있듯이 일단 이 책은 초보자를 위한 책이라고 보기에는 무리가 있다. 하지만 이 책은 초보자들도 이 책을 통해서 지식을 축척해 놓는다면 피가 되고 살이 되는 필독서라고 봐도 무방하다. 또한, 이 책의 저자도 최대한 이해하기 쉽게 책을 쓴 노력이 엿보인다.
이 책의 구성을 보면 문제점을 제시하는 나불안, 나불안에게 해결을 독촉하는 직속상관 왕잘난, 나불안의 문제점의 해결책을 제시해주는 고수 이추장으로 나눠 이야기 식으로 풀어간다. 물론 뒤 이어 자세한 내용에 대하여 관련 내용을 언급하고 있다.
주로 자바와 관련하여 시스템운영상의 문제점과 그 해결책을 제시해주고, 자바 프로그램을 많이 운영하고 있는 유닉스와 리눅스의 모니터링 명령어에 대한 설명으로 이루어져 있다.
개발자라면 책의 처음부터 읽어도 되고, 필요한 부분을 그때그때 참조할 수 있는 레퍼런스 서적으로도 사용할 수 있을 것 같다. 약간의 단점이라면 시스템 운영자라면 아마 관련 내용에서 부족함을 느끼지 않을까 생각해본다.
이 책이 뛰어난 개발자, 운영자가 되는데 분명 도움이 될 것이다. |
|
개인 PC에서 사용하는 프로그램이 아니라, 엔터프라이즈 애플리케이션을 개발하려는 경우에는, UNIX, Java, 미들웨어(WAS, TP-Monitor), DBMS, Framework에 대한 최소한의 지식이 요구되고 있는 실정이다.
시스템을 어떻게 개발하느냐의 정책에 따라, 화면 전문개발, 서버 업무로직 전문개발, 배치(Batch) 프로그램 전문개발 등으로 나뉘어 작업할 수도 있지만, 클라이언트와 서버 간의 인터페이스의 이슈가 자주 발생하여, 최근에는 하나의 모듈에 대한 클라이언트에서 서버까지, 단일 개발자가 개발하는 경향이 강해지고 있는 것 같다.
따라서, 개발자들은 자신의 컴퓨터에 이클립스, UI개발툴(X-internet 제품이나 RIA(Rich Internet Application) 제품), WAS, Framework 등을 설치해서 개발 후 단위테스트가 종료되면, 형상관리 서버로 소스를 올리는 형태로 개발되는 사례가 많아지고 있다.
이렇게 복잡한 환경에서, 개발자들은 자신이 개발한 프로그램에 문제가 발생하면, 문제를 해결하기 위해서는 자신이 작성한 프로그램이 어떻게 동작되는 지 이해가 필요하다.
전통적으로 운영체제가 Windows인지 UNIX인지에 따라, 해당 환경에서 프로그램을 실행시킨 상태인 프로세스(Process)의 상태 정보(CPU 사용량, 메모리의 상태)를 추적할 수 있는, 다양한 툴들이 운영체제 레벨이나 별도의 프로그램으로 제공되어 왔다.
하지만, Java 기반인 경우, 그냥 Java 애플리케이션이 아닌 WAS(Web Application Server)기반, 거기에 Framework까지 고려해야 한다면, 개발자는 운영체제 레벨이 아닌 JVM(Java Virtual Machine)에 대해서 보다 심도있는 이해가 필요하다.
예를 들어, WAS에서 기동되는 JSP(Java Sever Page)를 작성했는데 속도가 느리다는 문제가 있던지, CPU의 특정 코어의 사용량이 100%에 이르렀다면, 이 문제를 운영체제가 제공하는 기본 명령이나 툴로만 해결하기에는 많은 제약이 따른다.
이는 운영체제가 관리의 단위를 프로세스(Process)에서 출발했기 때문이라고 생각한다. 최근에는 Java 애플리케이션이나 MultiThread 애플리케이션이 지속적으로 증가되고 있다보니, 운영체제에서도 쓰레드를 제어할 수 있는 기능들이 지속적으로 보강되었다.
하지만, 아직도 kill 명령으로 특정 프로세스를 강제로 종료시킬 수 있는 것과 같이 특정한 명령으로 특정한 쓰레드를 강제로 종료할 수 있는 운영체제의 명령은 존재하지 않는다. (일부 APM(Application Process Monitoring) 툴 업체에서 말하는 쓰레드 강제종료는, 실행코드 중간에 강제로 종료할 수 있는 코드를 집어 넣는 방식이 대부분이기 때문에, 해당 쓰레드에서 이 강제종료 코드를 시행시켜야지만 빠져 나갈 수 있다. 실제로는 강제종료 코드에 도달하지 못한 채, 무한 루프를 도는 경우도 많기 때문에, 항상 쓰레드가 종료된다고 볼 수 없다. 이런 경우에는 어쩔 수 없이 JVM 프로세스를 운영체제레벨 kill 명령으로 종료시켜야 한다.)
이와같이 운영체제가 JVM을 하나의 프로세스로 다루고, JVM위에서 운영되고 있는 자신의 애플리케이션을 쓰레드로 취급하고, 있는 상황에서, 자신의 애플리케이션 쓰레드가 어떤 작업을 하고 있고, 어떤 문제를 발생시키고 있는지, 확인할 수 있는 방법은 무엇인가?
더구나 상용 Framework 기반이라, 핵심 코어 소스에는 접근이 불가능한 상황이라면, 자신의 작성한 코드에 문제가 있다고 보아야 하는가? Framework 문제인지 자신의 코드가 문제인지 어떻게 확인할 것인가? 이러한 다양한 이슈들은 문제해결 접근방법을 모르면 상당한 시간이 소요되는 내용들이다. 이런 문제점들에 대해서, 이 책은 문제 유형이 어떤 것이 있고, 쓰레드 상황을 파악하고 분석하는 방법, 메모리의 장애시 어떻게 접근할 것인지, JVM을 모니터링하는 방법에 대해서 설명하고 있다.
책의 후반부에는 Linux나 UNIX에서 시스템 모니터링하기 위한 방법을 설명하고 있다. 유명하고 필수적인 명령들이나 시간에 쫓겨 대충 보고 넘기기 쉬운 내용들에 대해서 상세히 설명하고 있다.
책의 마지막 부분에서는 장애진단 절차와 보고서를 작성하는 방법까지 설명하고 있다.
Java 기반으로 엔터프라이즈 애플리케이션 개발 프로젝트에 참여했었던 개발자나 시스템 운영자의 입장에서 꼭 필요한 책이라고 생각된다. 기존에는 문제해결을 위한 내용들이 여기 저기 흩어져서 여러 책을 읽어야 했었는데, 하나의 책으로 잘 정리되어 있다.
다만, 책을 읽으면서 쓰레드 단면, 메모리 단면이라는 새로운 용어를 사용하였는데... 기존에 이쪽 분야에 있었던 사람들과 의사소통하기에는 쉽지 않을 것 같다. 자기보다 직급도 높고 경혐이 많은 사람들이 쓰레드 덤프, 메모리 덤프라고 하고 각종 원서에도 thread dump, memory dump라고 이야기하고 있기 때문에, 저자의 의도는 충분히 이해되나, 전파는 쉽지 않을 것으로 보인다.
또한, 책의 후반부에서 자주 사용되는 명령어의 full name을 적어 주었더라면 하는 아쉬움이 남는다. 예를 들어 11장의 BTrace는... 도대체 B가 무엇을 의미할까 생각할 수도 있을 것 같다. 간단한 배경을 설명해 주면 독자가 기억하기 쉽지 않을까 하는 생각이 들었다. (Bytecode Trace를 의미하는 것으로 알고 있음) 또한, vmstat(Virtual Memoty Statistics), sar(System Acivity Reporter), mpstat(Multiprocess Statistics??), apt-get(Advanced Package Tool -get), yum(Yellowdog Updater, Modified), pstree(Process Status Tree), pmap(Process Memory Map) 등도 처음 용어가 나왔을 때 풀어주면, 독자들이 쉽게 기억할 수 있지 않을까 생각해 본다.
이 분야는 기본적으로 알아야 할 내용들이 너무 많기 때문에, 저자가 어떤 기준으로 설명할 것인지 기준설정이 어려웠을 것이라고 생각한다. 이러한 어려움 속에서도, 자바 개발자와 시스템 운영자에게 도움을 줄 수 있는 책을 출판한 저자는 대단히 고마운 사람이다. |
|
기술서적이든, 일반 문학서적이든, 또는 경영서적이든, 꾸준히 책을 내시는 분들 또는 그 사람의 브랜드만 봐도, 아, 이 책은 읽을만 하겠구나 하면서 신뢰를 주는 분들이 있다. 이 책을 쓰신 이상민님이 그런 분이 아닐까 싶다. Blog@Book 이라는 책 카테고리에서, 자바 관련 내용에 대해서만 일관되게 책을 쓰고 계셔서 그 신뢰감이 더 높다는 생각이 든다. 사실 나는 자바 기술에 대해서는 그렇게 많이 아는 편이 아니라, 학습에 대한 목적으로 이 책을 보게되었는데, 내 지론 중에 하나가, 하나의 언어를 깊게 알기 위해서는 그 언어에서 디버깅을 완벽하게 할 줄 알아야 한다는 것이다. 이 디버깅이라는 것은, 언어자체의 문법을 디버거로 따라가는 수준을 의미하는 것만은 아니다. 예를 들어, 프로그램이 문제를 일으켜 Core 를 생성하게 한다면, 이 Core를 생성하는 방법부터, 시작해서, Core에서 문제 위치를 파악하는 방법, Multi-Thread 에서는 각각의 위치를 어떻게 찾을 것이며, 왜 이런 문제가 발생하는지, 또, 어떻게 해결해야 하는지를 알아야 하는지에 대한 것이다. |
|
한빛미디어의 블로그2블로그 시리즈는
|
|
본인은 학생으로 이런 문제에 대해 겪어본 적도 없거니와 문제가 생길거라는 생각을 해본적도 없고 |
|
1월 북리뷰 도입부에 출판사 대해 나름 불만을 제기했는데, 2월 선정도서가... 또! 같은 출판사에 같은 저자이다. 이미 지정된거 마음을 비우고 무슨 내용인지 천천히 살펴보는데, 몇장 읽지 않은 상태에서 19-21페이지까지 책 절단이 잘못되어 있어서 가뜩이나 안 좋은 이미지가 더 안좋아졌다. 인터넷으로 주문한거라 교환하기에는 너무 번거롭고 내용 읽는데는 지장이 없어서 그냥 놔두기로 했다. Part 01. 장애에 대하여 Story 01 자바 기반 시스템에서 발생할 수 있는 문제점들 이 책의 저자는 연극을 좋아하는것 같다. 왕잘난팀장, 이추장선배, 나불안대리라는 인물을 배치시켜 트러블슈팅에 대한 상황극을 연출한다. 장애가 발생하는 상황에 대해 저자가 생각나는대로 적어놓은 내용이다. 장애상황은, 시스템이 느려짐, 응답이 없음, 예외발생, 프로세스의 강제종료라는 4가지 상황을 더 세부적인 몇가지 유형으로 나열하고, 장애가 발생하는 원인을 애플리케이션관점과 서버 구성 요소 관점으로 나누어 정리하였다. ＜장애상황＞
＜장애원인＞
Part 02. 자바에서 발생할 수 잇는 쓰레드 관련 문제 Story 02 쓰레드에서 발생하는 문제점들에는... 『High-Performance Java Platform Computing』을 인용하여 자바에서 쓰레드로 인해 발생할 수 있는 대표적인 문제를 5가지 나열하고 각각에 대해 설명하고, Lock을 피할 수 있는 10가지 방법에 대한 해외 블로거의 포스팅 내용을 소개한다.
멀티 쓰레드 환경에서 락을 걸지 않고 하나 이상의 공유 데이터를 처리할 때, 여러 쓰레드가 동시에 데이터를 수정할 수 있게된다. 이때 공유 데이터의 값을 조건절로 사용하는 일부 쓰레드가 무한 루프에 빠지는 상황이 일어 나기도 하는데 이러한 문제를 레이스 컨디션이라고 한다. 자바에서 쓰레드 우선순위를 조정할 수도 있지만 반드시 레이스 컨디션이 없어진다는 보장은 없다.
대학에서 전공으로 배웠다면, 운영체제 시간에 들어봤을테지만 수업시간에 졸았다던가 교수님이 설명을 부실하게 해서 이해를 못했다면 다시 한번 살펴보자. 데드락은 두개 이상의 쓰레드에서 다른 쓰레드가 선점한 자원에 대해 락이 풀리기를 기다려 무한 루프와 같은 상태에 빠지는 것을 말한다. 간단한 예제로 Thread1, Thread2 가 각각 Data1, Data2에 접근하여 락을 걸어둔 상태에서 Thread1이 Data2에 접근하려 하고, Thread2 가 Data1에 접근하려 할때 서로 락이 풀리기를 대기하는 상황이 데드락이다.
데드락이 데이터에 대한 접근을 기다리는 것이라면, 스터베이션은 프로세싱에 필요한 자원(CPU)에 대한 사용을 기다리는 것이다. 쓰레드 우선순위가 다른 쓰레드보다 낮을때 해당 쓰레드는 프로세싱을 수행하기 위한 자원을 할당받지 못해스터베이션에 빠진다.
두개의 쓰레드가 서로 요청/응답을 주고 받는 작업이 계속 반복되어 무한루프와 같이 동작하는 것을 라이브락이라고 한다. 데드락은 CPU 자원을 점유하지 않고 대기 상태에 빠져들지만 라이브락은 CPU자원을 차지하면서 지속적으로 동작한다.
앞서 말한 레이스 컨디션은 일종의 예측 불가능한 오류이다. 이러한 예측 불가능한 오류는 일반적으로 트랜잭션을 처리하는 부분에서 발생한다... 락을 피할 수 있는 10가지 방법
자세한 내용은 아래 원문 주소를 참조 http://www.thinkingparallel.com/2007/07/31/10-ways-to-reduce-lock-contention-in-threaded-programs/ Story 03 쓰레드 단면 잘라 놓기 무한 루프를 수행하는 쓰레드 예제 코드를 하나 작성하여 수행하고, 쓰레드 덤프를 생성하는 것과 덤프 내용에 대해 설명한다. 쓰레드 덤프에 포함되는 정보는 다음 항목들이다.
각 쓰레드에 대한 정보중 문제가 될만한 항목은 상태가 RUNNABLE 과 BLOCKED 이다. 경우에 따라서는 WAITING 도 문제가 될 수 있다. 쓰레드 상태는 다음 6가지로 구분된다.
쓰레드 덤프를 생성할 때 Lock의 상태를 출력하려면 -XX:+PrintConcurrentLocks 옵션을 클래스별 점유 메모리 히스토그램을 출력하려면 -XX:+PrintClassHistogram 옵션을 추가로 사용한다. 쓰레드 덤프 생성은 유닉스나 리눅스 계열의 OS의 kill 명령을 이용한 방법, JDK 에 포함된 jstack 을 수행하는 방법, 윈도우 OS의 커맨드 창으로 프로그램을 실행하고 Ctrl + break 를 눌러 생성하는 방법등이 있다. kill 명령의 사용은 kill -3 [수행중인 Java 프로세스의 PID] 로 사용할 수 있으며, -3 은 보통 QUIT 시그널을 발생시키는 옵션이다. OS 에 따라 QUIT 시그널 정의가 다를 수 있으므로 확인하고 사용한다. jstack 을 이용하는 방법은 단순히 jstack [수행중인 Java 프로세스의 PID] 형태로 사용하면 되며 저자는 jstack 이 kill 명령어보다 수행속도도 느리고 불안정하다고 kill 사용을 권장한다. 쓰레드 덤프를 파일로 남기는 방법은 OS 가 윈도우인경우 java [수행할 Java 프로그램] ＞ 파일명 ex ) java MakeThreads ＞ MakeThreadResult.txt 유닉스/리눅스 OS인 경우 nohup java [수행할 Java 프로그램] ＞ 파일명 & ex ) nohup java MakeThreads ＞ MakeThreadResult.txt & 형태로 사용한다. Story 04 잘라 놓은 쓰레드 단면 분석하기 쓰레드 덤프를 분석하는 무료 툴 TDA(Thread Dump Analyzer)를 소개하고 사용법에 대해 설명한다. TDA 를 다운 받을수 있는 홈페이지 주소는 아래와 같다. 이외에 웹에서 쓰레드 상태를 모니터링 하는 툴인 ThreadChecker 를 소개하고 구조를 설명한다. ThreadChecker는 JSP 하나로 이루어져 있으며 자바의 Thread 클래스에서 기본적으로 제공하는 쓰레드 정보를 수집하여 출력하는 간단한 예제를 가지고 ThreadChecker의 동작 방식을 설명한다. Story 05 쓰레드 문제 Case Study 쓰레드 덤프를 생성할 수 없는 상황(프로세스가 갑자기 죽는경우)에서 -XX:OnError="명령어" 또는 -XX:ErrorFile=파일이름 옵션으로 특정 명령이나 수행할 파일(스크립트)를 지정할 수 있는 방법을 소개하고, 몇가지 이상현상과 발생한 이상 현상을 해결하기 위한 접근방법을 제시한다. -XX:OnError 옵션은 -XX:OnError="kill -3 %p" 형태로 지정하여 오류가 발생하였을때 쓰레드 덤프를 수행하도록 할 수 있다. 사례1 - CPU 사용량이 갑자기 늘어나는 경우 장애가 발생한 장비에서 쓰레드 덤프를 30초나 1분 간격으로 5-10회 생성, 동시에 각 쓰레드별 사용 시간에 대한 덤프도 생성 kill -3 PID ps -Lf -p pid 이와 같은 방법으로 접근하였을 때 저자는 무한루프인 로직이 문제임을 발견했다고 한다. 그런데, 조금 이해가 안되는 상황이... 개발팀은 운영 시스템이나 통합 시스템에 테스트 해보지도 않은 코드를 올려서 컴파일 하는건가? 하는 의문이 든다. 무한 루프 로직은 테스트만 몇번 해도 발생할 확률이 높은 문제점인데, 그것도 개발자 한명이 작성한 코드일 확률이 더 높다고 보여진다. 여러 개발자들이 작성한 코드 사이에서 무한 루프와 같은 상황이 발생하려면, 잘못된 공유 데이터 선언이 문제가 되지 않을까? 그게아니라면 데드락이나 스터베이션이 발생해야 하는 것이 이치에 맞아 보이는데 어쨋든 내용이 좀 공감되지 않는다. 사례2 - 쓰레드 풀의 쓰레드 개수가 계속 늘어난다. 쓰레드 풀 이야기를 하면서 DB연결 풀을 예를 들었는데, 쓰레드 생성시간이 어마어마 하다는 부연 설명은 조금 과장된 면이 있다. 쓰레드 생성 시간이 어마어마 한게 아니라, DB 연결을 초기화 하는 과정에 걸리는 시간이 길다는게 정확한 표현일 것이다. 사례2에서는 Lock 이 걸려 있는 4개의 Thread 스택 정보를 함께 게재 하여 두었는데 첫번째 쓰레드를 제외하면 모두다 I/O 패키지의 File 클래스와 관련이 있다는 점을 보여준다. 사례3 - 시스템의 응답없음 쓰레드 사용시간에 대해 덤프를 생성하고 오랜시간 사용한 쓰레드를 TDA 를 통해 Native ID를 확인한다. 해당 쓰레드가 GC관련 쓰레드인점을 확인하고 가장 유력한 문제 발생 원인으로 메모리 누수(Leak)가 원인임을 이야기한다. 이번장에서 저자는 쓰레드 덤프를 생성하고 분석하는 것으로 많은 부분에 대해 트러블 슈팅이 가능하지만 모든 장애에 대해 대처할 수 없다는 것을 강조한다. Part 03. 자바에서 발생할 수 있는 메모리 관련 문제 Story 06 메모리 떄문에 이런 문제들이 발생할 수 있다 이번 파트는 쓰레드 이외에 자바 기반 애플리케이션에서 장애를 일으키는 원인중 하나인 메모리 문제에 대해 설명한다. 이번장에서는 자바의 메모리 영역 구조를 설명하고, 관련된 장애 유형에 대해 나열한다. 자바의 메모리 영역(Runtime data area)는 다음과 같다.
이 영역들 중에서 Heap 영역을 자세히 살펴보면
로 구성되어 있다. 저자는 메모리 관련 에러중에서 OutOfMemoryError 에 대해 몇가지 유형을 자세히 설명하고, 메모리 누수에 관한 3가지 유형을 Unveiling tha java.lang.OutOfMemoryError(And dissecting Java heap dumps, http://java.sys-con.com/node/1229281)라는 글을 참고하여 3가지로 분류한다.
Story 07 메모리 단면 잘라 놓기 메모리 덤프 생성은 시스템의 동작(서비스 수행)에 문제발생, 오랜시간 소요, 생성되는 덤프 파일의 대용량, JDK 버전에 따른 제약이 있으므로 생성에 주의를 기울여야 한다고 설명하면서 hprof 와 jmap명령어를 이용하여 메모리 덤프를 생성하는 방법을 소개한다. hprof 는 JDK 에 포함되어 있는 도구로, 자바 애플리케이션실행시 agent library 옵션으로 설정하여 사용한다. java -agentlib:hprof [자바프로그램] java -agentlib:hprof=heap=dump,format=b,file=heapdump.hprof,doe=n [자바프로그램] jmap 도 JDK 에 포함된 도구로 수행중인 자바 애플리케이션의 PID를 입력하는 방법으로 사용한다. jmap [PID] jmap -dump:덤프옵션 [PID] Story 08 잘라 놓은 메모리 단면 분석하기 메모리 덤프에 대한 분석 툴 몇가지(MAT, IBM Heap Analyzer, jhat)를 추천하고, MAT에 대해 자세한 사용방법을 설명한다. 제목은 메모리 단면(dump) 분석하기 였는데 읽어보면 MAT 사용법 설명이다. Story 09 메모리 문제 Case Study 시스템이 느린경우나 응답없을 경우 메모리와 관련된 문제는 GC일 확률이 높다는 것과 이와 관련된 두가지 사례를 소개한다. 상황 1 - 성능 테스트를 수행하여보니 3분간 300건정도 처리하던 시스템이 3분이후 초당 10건밖에 처리 하지 못함 성능테스트이기 때문에 성능테스트를 위해 시스템에 부하를 주는 에이전트에 대해서 먼저 점검하고 에이전트가 사용하는 리소스양이 정상이므로 메모리 덤프를 생성하고 분석. Session 객체가 메모리를 점유하는 것을 발견하였으나 시스템이 세션을 사용하는 상황이라면 성능테스트 시 요청이 발생할때마다 새로운 사용자로 인식하지 않도록 조정하라는 제안이다. 상황 2 - 시스템의 응답이 없고, CPU 중 하나만 점유되어 사용되고 있다. 이런 경우 대부분이 메모리 누수(leak)이라고 한다. 이 유형에서는 DB Connection Pool 을 구성하여 8개의 DB에 연결하고, 성능 강화를 위해 Cache를 50-100M 로 설정하여 두어 실제 시스템의 메모리 1G 중에서 400-800M 를 캐시가 사용하는 상황이어서 Cache 사용량을 줄여 해결함 이번 파트를 마치면서 메모리 덤프로 분석하는 것으로 해결되는 문제는 많지 않으며 대부분이 메모리 누수(leak) 상황에서 발생 원인을 찾을 때 사용한다고 한다. Part 04. 장애 진달을 쉽게 할 수 있도록 도와주는 툴 Story 10 모니터링 툴의 사용 앞서 살펴본 덤프 생성 및 분석 방법은 시간상으로 지나간 상태를 살펴보는 것이었으나 실시간으로 분석하는 방법을 소개한다. Java VisualVM 이라는 툴을 소개하는데, JVM 전체 현황, 리소스 관련 모니터링, 쓰레드 관련 모니터링, 프로파일링 기능, 플러그인을 통한 기능추가, 덤프 파일 확인 기능이 있다. 이외에 JMX 로 원격 모니터링을 수행하는 것에 대해서도 설명하는데 프로파일링을 제외한 나머지 정보를 모니터링 할 수 있다. Story 11 실시간 JVM 모니터링이 가능한 BTrace 수행중인 바이트코드 상태의 자바 프로그램을 변경하여 추적 코드를 심어 놓고 대체하여 애플리케이션을 진단할 수 있는 BTrace를 소개한다. 제약사항은 173p 에 한페이지 가득 써놨는데 생각보다 제약사약이 많아 읽다가 도대체 뭘 수행할 수 있는건지 혼란스러웠다. Btrace 는 어노테이션으로 정의한 추적/진단 스크립트를 작성하고, 실행중인 PID 와 진단 스크립트를 매개변수로 실행시키면 된다. JStack 샘플 스크립트로 gc를 호출한 시점의 스택정보를 출력하는 예제와 예외 발생시 스택정보를 출력하는 간단한 예제를 포함한다. Part 05. 리눅스 유닉스 기반의 시스템을 모니터링 하기 위한 각종 명령어 Story 12 CPU 모니터링하기 이번 파트부터는 Virtual BOX를 이용하여 설치한 리눅스(우분투)에서 사용가능한 명령어와 유틸리티 패키지를 소개한다. 먼저 CPU 사용량을 모니터링 하는 mpstat 사용법에 대해 설명한다. mpstat 를 사용하기 위해서는 syssyay 패키지를 설치하여야 한다. 저자는 CPU 모니터링에서는 User CPU, System CPU, IO Wait CPU, 기타 CPU 사용량을 먼저 확인하라고 말한다. Story 13 전반적인 상황 모니터링하기-vmstat와 sar CPU 외에 디스크, 메모리, 프로세스 사용량을 모니터링 하는데 사용 가능한 vmstat 와 vmstat 보다 상세한 정보를 제공하는 sar 을 소개하고 각 옵션에 대한 설명한다. Story 14 프로세스 상황 모니터링하기 프로세스간의 관계를 알아보는 pstree 와 프로세스를 살펴볼때 가장많이 사용하는 ps 명령어에 대해 자주 사용하는 옵션에 대해서 설명하고 있다. 다음으로 프로세스가 점유한 CPU 사용량을 모니터링 하는 pidstat 와 프로세스 메모리 구성을 확인하는 pmap을 소개한다. Story 15 I/O 상황 모니터링하기 장애의 대표적인 원인 중 하나인 I/O 문제에 대해 파악하기 위한, I/O 모니터링 명령어를 소개한다. 디스크 사용량을 확인할 수 있는 명령어 df 와 파일과 디렉토리가 점유하는 상황을 볼 수 있는 du 명령어 그리고 I/O 통계정보를 보여주는 iostat 와 프로세스가 어떤 파일을 사용하는지 확인하는 lsof 에 대해 설명한다. Story 16 네트워크 상황 모니터링하기 앞서 살펴보았던 sar 와 lsof 를 이용하여 네트워크 상황을 모니터링 하는 방법과 대부분의 운영체제에서 지원하는 netstat 를 이용하여 네트워크 정보를 확인하는 방법에 대해 설명한다. Story 17 실시간으로 시스템 모니터링하기 이전까지는 명령어나 툴 실행시 옵션을 변경하여 모니터링을 수행했지만, 모니터링 하는 도중 단축키를 이용하여 실시간으로 원하는 통계정보를 출력할 수 있는 명령어 top 에 대해 설명하고 단축키에 대한 정보를 제공한다. 또 top 과 비슷하지만 펑션키를 이용하여 단축키를 몰라도 쉽게 사용할 수 있는 htop 이라는 도구도 소개한다. Story 18 리소스 모니터링은 이거 하나면 된다. 통합 모니터링 도구인 collectl 와 cellectd 를 소개하고 설치하는 방법과 사용하는 방법에 대해 설명한다. 이번장에서 RRD 라는 용어도 등장하며 RRD 는 Round Robin DataBase를 의미한다. 이번 장을 보면서 회사에서 현재 사용하는 프레임워크에 모니터링 기능을 추가해보고 싶은 욕심과 의욕이 마구마구 생겨났지만 게으른 나로써는 잠시 의욕만 생겨났을뿐! 절.대.로 뭔가 만들지는 않을것이다. Part 06. 장애 진단 절차 Story 19 장애 진단은 이렇게 한다. 장애가 발생하면 수행하는 프로세스에 대해 설명하고 일부 예시를 들어 설명하고 있다. 저자가 장애에 대처하는 방법은 다음과 같다. 1) 장애유형확인(인터뷰나 이메일을 통한 증상 확인) 2) 시스템 기본 정보 확인 3) 각종 데이터를 통한 원인 진단 4) 원인이 발견되면 제거 후 확인 5) 진단 결과 보고서 작성(필요한 경우) Story 20 문제점에 따른 진단은 이렇게 한다. 책 도입부에 분류해두었던 장애 유형중에서 시스템이 느려지는 경우 대처방법을, 심리테스트 블록처럼 꾸며놓고 설명한 것과 단계별 수행 작업으로 도식화 하여 설명한다. 이로써, 길고 긴 책의 내용이 끝나고 상당히 많은 분량의 부록이 덧붙여져 있다. 메모리 덤프 분석의 경우 앞에서 다루지 않았던 stack overflow 도 잠깐 나오고 부록이라고 하기엔 책 본문에 들어가도 될만한 내용들이 많이 있었다. 책이 100% 만족스럽지는 않지만 Dump 분석이라던가 모니터링에 대한 내용을 좀 더 알 수 있는 좋은 기회였다. 다른 사람(책의 저자)은 어떻게 장애에 대해 대처하고 어떤 툴을 사용하고 있는지 살펴보는 것은 그동안 내가 알고 있던 방법이나 접근법을 좀 더 보강시켜주는데 도움이 될 듯 하다. 이 책의 내용중 표로 정리한 부분은 나중에 태블릿에 담아 두었다가 인터넷이 되지 않는 금융 사이트에서 트러블 슈팅할 때 사용하면 좋을 것이란 생각이 든다. |
