자바 개발자와 시스템 운영자를 위한 트러블 슈팅 이야기

자바 개발자와 시스템 운영자를 위한 트러블 슈팅 이야기
이상민 저

예스24 | 애드온2

1월 북리뷰 도입부에 출판사 대해 나름 불만을 제기했는데, 2월 선정도서가... 또! 같은 출판사에 같은 저자이다.

이미 지정된거 마음을 비우고 무슨 내용인지 천천히 살펴보는데, 몇장 읽지 않은 상태에서 19-21페이지까지 책 절단이 잘못되어 있어서

가뜩이나 안 좋은 이미지가 더 안좋아졌다. 인터넷으로 주문한거라 교환하기에는 너무 번거롭고 내용 읽는데는 지장이 없어서

그냥 놔두기로 했다.

Part 01. 장애에 대하여

Story 01

자바 기반 시스템에서 발생할 수 있는 문제점들

이 책의 저자는 연극을 좋아하는것 같다. 왕잘난팀장, 이추장선배, 나불안대리라는 인물을 배치시켜 트러블슈팅에 대한 상황극을 연출한다. 장애가 발생하는 상황에 대해 저자가 생각나는대로 적어놓은 내용이다.

장애상황은, 시스템이 느려짐, 응답이 없음, 예외발생, 프로세스의 강제종료라는 4가지 상황을 더 세부적인 몇가지 유형으로 나열하고,

장애가 발생하는 원인을 애플리케이션관점과 서버 구성 요소 관점으로 나누어 정리하였다.

<장애상황>

장애상황	유형
시스템이 느림	전체적인 시스템이 항상 느린경우 특정 기능(화면)이 느린경우 특정시간대(기간)에 전체 애플리케이션이 느린 경우 특정시간대(기간)에 특정 애플리케이션이 느린 경우 특정 기능(화면)이 점점 느려질 경우 특정 사용자에게만 애플리케이션이 느린 경우
시스템 응답없음	모든 애플리케이션이 응답하지 않는 경우 특정 기능(화면)이 응답하지 않는 경우
예외가 계속 발생	모든 사용자가 특정 기능을 수행하면 예외가 발생하는 경우 특정 사용자의 특정 기능에서만 예외가 발생하는 경우 특정 시간대에만 전체 애플리케이션에 예외가 발생하는 경우 특정 시간대에 특정 애플리케이션에 예외가 발생하는 경우
시스템이 죽음(?)	실마리가 있는 경우 아무 실마리도 없이 죽는 경우

<장애원인>


애플리케이션관점	웹 서버 웹 애플리케이션 서버(이하 WAS) DB 서버 데몬 프로그램 Legacy 시스템(이하 레거시) 기타 생각지도 못한 서버
서버구성요소 관점	CPU 네트워크 메모리 디스크 및 파일 서버 OS 커널

Part 02. 자바에서 발생할 수 잇는 쓰레드 관련 문제

Story 02

쓰레드에서 발생하는 문제점들에는...

『High-Performance Java Platform Computing』을 인용하여 자바에서 쓰레드로 인해 발생할 수 있는 대표적인 문제를 5가지 나열하고 각각에 대해 설명하고, Lock을 피할 수 있는 10가지 방법에 대한 해외 블로거의 포스팅 내용을 소개한다.

레이스 컨디션(Race condition)

멀티 쓰레드 환경에서 락을 걸지 않고 하나 이상의 공유 데이터를 처리할 때, 여러 쓰레드가 동시에 데이터를 수정할 수 있게된다. 이때 공유 데이터의 값을 조건절로 사용하는 일부 쓰레드가 무한 루프에 빠지는 상황이 일어 나기도 하는데 이러한 문제를 레이스 컨디션이라고 한다. 자바에서 쓰레드 우선순위를 조정할 수도 있지만 반드시 레이스 컨디션이 없어진다는 보장은 없다.

데드락(Dead lock)

대학에서 전공으로 배웠다면, 운영체제 시간에 들어봤을테지만 수업시간에 졸았다던가 교수님이 설명을 부실하게 해서 이해를 못했다면 다시 한번 살펴보자. 데드락은 두개 이상의 쓰레드에서 다른 쓰레드가 선점한 자원에 대해 락이 풀리기를 기다려 무한 루프와 같은 상태에 빠지는 것을 말한다. 간단한 예제로 Thread1, Thread2 가 각각 Data1, Data2에 접근하여 락을 걸어둔 상태에서 Thread1이 Data2에 접근하려 하고, Thread2 가 Data1에 접근하려 할때 서로 락이 풀리기를 대기하는 상황이 데드락이다.

스터베이션(Starvation)

데드락이 데이터에 대한 접근을 기다리는 것이라면, 스터베이션은 프로세싱에 필요한 자원(CPU)에 대한 사용을 기다리는 것이다. 쓰레드 우선순위가 다른 쓰레드보다 낮을때 해당 쓰레드는 프로세싱을 수행하기 위한 자원을 할당받지 못해스터베이션에 빠진다.

라이브락(live lock)

두개의 쓰레드가 서로 요청/응답을 주고 받는 작업이 계속 반복되어 무한루프와 같이 동작하는 것을 라이브락이라고 한다. 데드락은 CPU 자원을 점유하지 않고 대기 상태에 빠져들지만 라이브락은 CPU자원을 차지하면서 지속적으로 동작한다.

다른 형태의 예측 불가능한 오류(non-determinism)

앞서 말한 레이스 컨디션은 일종의 예측 불가능한 오류이다. 이러한 예측 불가능한 오류는 일반적으로 트랜잭션을 처리하는 부분에서 발생한다...

락을 피할 수 있는 10가지 방법

코드가 아닌 데이터를 보호하라(Protect data, not code)
락을 사용한 부분에서는 비싼 계산을 하지 말아라(Get rid of expensive calculations while in locks)
락을 분리하라(Use lock striping)
내부적인 락이나 atomic 작업을 사용하라(Employ interlocked/atomic operations)
동기화된 데이터 구조를 사용하라(Use synchronized data structures)
가능하다면 읽기-쓰기 락을 사용하라(Use Reader-Writer Locks where applicable)
가능하다면 읽기 전용 데이터를 사용하라(Use Read-Only data whenever possible)
객체 풀링을 피하라(Avoid Object Pooling)
지역 변수나 쓰레드 로컬 저장소를 사용하라(Use local variables or thread-local storage)
핫스팟을 피하라(Avoid hot-spots)

자세한 내용은 아래 원문 주소를 참조

http://www.thinkingparallel.com/2007/07/31/10-ways-to-reduce-lock-contention-in-threaded-programs/

Story 03

쓰레드 단면 잘라 놓기

무한 루프를 수행하는 쓰레드 예제 코드를 하나 작성하여 수행하고, 쓰레드 덤프를 생성하는 것과 덤프 내용에 대해 설명한다.

쓰레드 덤프에 포함되는 정보는 다음 항목들이다.

쓰레드 덤프 생성시간정보
JVM에 대한정보
각 쓰레드 스택을 포함한 다양한 정보
Deadlock 정보(Deadlock 이 발생한 경우에만)
힙영역 사용현황

각 쓰레드에 대한 정보중 문제가 될만한 항목은 상태가 RUNNABLE 과 BLOCKED 이다. 경우에 따라서는 WAITING 도 문제가 될 수 있다.

쓰레드 상태는 다음 6가지로 구분된다.

쓰레드 상태	설명
NEW	쓰레드가 아직 시작 되지 않은 상태
RUNNABLE	쓰레드가 수행 중인 상태
BLOCKED	쓰레드가 잠겨 있어 풀리기를 기다리는 상태
WAITING	다른 쓰레드가 특정 작업을 수행하여 깨울 때까지 무한정 기다리는 상태
TIMED_WAITING	다른 쓰레드가 특정 작업을 수행하여 깨울 때까지 지정된 시간만큼 기다리고 있는 상태
TERMINATED	쓰레드가 종료된 상태

쓰레드 덤프를 생성할 때 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 를 다운 받을수 있는 홈페이지 주소는 아래와 같다.

http://java.net/project/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)는 다음과 같다.

PC(Program counter)레이스터 : 쓰레드별 보유
JVM Stack : 쓰레드별 보유
Heap : 대부분의 데이터가 저장되는 일반적인 저장소
Method area
Runtime Constant Pool : 메소스 영역에 할당되어 있음
Native Method Stack

이 영역들 중에서 Heap 영역을 자세히 살펴보면

eden
survivor
tenured
permanent

로 구성되어 있다.

저자는 메모리 관련 에러중에서 OutOfMemoryError 에 대해 몇가지 유형을 자세히 설명하고,

메모리 누수에 관한 3가지 유형을 Unveiling tha java.lang.OutOfMemoryError(And dissecting Java heap dumps, http://java.sys-con.com/node/1229281)라는 글을 참고하여 3가지로 분류한다.

수평적 메모리 누수(Horizontal memory leak)
수직적 메모리 누수(Vertical memory leak)
대각선 형태의 메모리 누수(Diagonal memory leak)

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 분석이라던가 모니터링에 대한 내용을 좀 더 알 수 있는 좋은 기회였다. 다른 사람(책의 저자)은 어떻게 장애에 대해 대처하고 어떤 툴을 사용하고 있는지 살펴보는 것은 그동안 내가 알고 있던 방법이나 접근법을 좀 더 보강시켜주는데 도움이 될 듯 하다. 이 책의 내용중 표로 정리한 부분은 나중에 태블릿에 담아 두었다가 인터넷이 되지 않는 금융 사이트에서 트러블 슈팅할 때 사용하면 좋을 것이란 생각이 든다.

자바 개발자와 시스템 운영자를 위한 트러블 슈팅 이야기

댓글 0

아직 댓글이 없어요.

사락 인기글