Java

지난 포스팅에서는 통합 모니터링 시스템인 APM(Application Performance Management)의 4대 핵심 지표를 해석하는 방법을 알아보았습니다. APM은 애플리케이션 내부의 흐름을 시각적으로 보여주는 훌륭한 도구이지만, 가끔은 APM 에이전트 자체가 멈추거나 네트워크 문제로 데이터를 전송하지 못하는 블랙아웃 상황이 발생하기도 합니다. 이럴 때 서버 관리자와 시니어 백엔드 개발자의 진가가 발휘되는 곳이 바로 리눅스(Linux) 터미널 화면입니다. 운영체제(OS) 레벨에서 시스템 리소스가 어떻게 … 더 읽기

지난 포스팅에서는 메모리 누수(OOM)가 발생했을 때 서버를 부검하여 원인을 찾는 힙 덤프(Heap Dump)와 MAT 도구에 대해 알아보았습니다. 하지만 훌륭한 시스템 운영자라면 장애가 터진 후 수습하는 것이 아니라, 실시간으로 서비스의 건강 상태를 파악하고 병목을 사전에 차단해야 합니다. 과거에는 JConsole이나 VisualVM 같은 도구로 서버 한 대씩 상태를 확인했지만, 수십~수백 대의 서버가 얽혀 있는 현대의 마이크로서비스 아키텍처(MSA)에서는 한계가 … 더 읽기

지난 포스팅에서는 VisualVM과 JConsole을 이용해 실시간으로 서버의 건강 상태를 점검하는 방법을 알아보았습니다. 하지만 서버가 이미 OutOfMemoryError(OOM)를 뱉으며 장렬하게 전사해 버렸다면, 실시간 모니터링 도구는 더 이상 소용이 없습니다. 이때 개발자가 서버의 사망 원인(메모리 누수)을 부검하기 위해 반드시 확보해야 하는 결정적 증거가 바로 힙 덤프(Heap Dump)입니다. 이번 글에서는 운영 서버에서 안전하게 힙 덤프를 추출하는 방법과, 추출한 대용량 … 더 읽기

지난 포스팅에서는 서버의 내부 상태를 외부로 노출해 주는 기술인 JMX(Java Management Extensions)의 원리와 원격 접속 설정 방법에 대해 알아보았습니다. 문을 열어두었으니 이제 그 안을 훤히 들여다볼 수 있는 ‘망원경’이 필요합니다. 개발 환경이나 QA(테스트) 환경에서 Java 애플리케이션의 성능 병목을 추적할 때, 비싼 상용 APM 도구 없이도 훌륭하게 분석을 수행할 수 있는 무료 내장 도구들이 있습니다. 바로 … 더 읽기

지금까지의 시리즈를 통해 JVM의 메모리 구조부터 가비지 컬렉션(GC), 그리고 멀티 스레드 제어와 비동기 프로그래밍까지 ‘어떻게 성능을 최적화할 것인가’에 대한 내부 이론을 탄탄하게 다졌습니다. 하지만 실제 서비스가 라이브로 배포(Production)되고 나면, 이론만으로는 해결할 수 없는 수많은 변수와 병목 현상이 발생합니다. 서버가 다운되기 전에 미리 메모리 누수를 감지하고, 현재 몇 개의 스레드가 활성화되어 있는지 실시간으로 관찰하려면 애플리케이션의 상태를 … 더 읽기

지난 포스팅에서는 여러 스레드가 공유 자원에 접근할 때 발생하는 병목을 해결하는 ConcurrentHashMap에 대해 알아보았습니다. 동시성 제어를 통해 스레드 간의 충돌을 막았다면, 이제는 ‘스레드가 아무 일도 하지 않고 버려지는 시간’을 최소화하여 서버의 전체 응답 속도를 극대화할 차례입니다. 엔터프라이즈 Java 애플리케이션 성능 저하의 가장 큰 주범은 외부 시스템(데이터베이스, 외부 API 등)과의 통신 시 발생하는 대기 시간입니다. 이번 … 더 읽기

지난 포스팅에서는 시스템 자원 낭비를 막고 서버의 안정성을 지키는 스레드 풀(Thread Pool)의 적정 사이즈 산정법에 대해 알아보았습니다. 여러 개의 스레드를 효율적으로 띄우는 것까지 성공했다면, 그다음 직면하게 되는 문제는 ‘여러 스레드가 동시에 동일한 데이터(공유 자원)에 접근할 때 어떻게 안전하게 처리할 것인가’입니다. Java에서 Key-Value 형태로 데이터를 저장할 때 가장 많이 사용하는 자료구조는 HashMap입니다. 하지만 HashMap은 스레드 안전성(Thread-safe)을 … 더 읽기

지난 포스팅에서는 무분별한 락(Lock) 사용이 불러오는 참사인 교착 상태(Deadlock)에 대해 알아보았습니다. 동시성 제어의 또 다른 핵심은 ‘스레드를 얼마나 많이 만들 것인가’입니다. 사용자의 요청이 들어올 때마다 새로운 스레드를 무한정 생성한다면 어떻게 될까요? 스레드 생성과 소멸에 드는 CPU 오버헤드는 엄청나며, 결국 메모리 고갈(OutOfMemory)이나 잦은 컨텍스트 스위칭(Context Switching)으로 인해 서버는 완전히 뻗어버리고 맙니다. 이를 방지하기 위해 미리 일정 … 더 읽기

지난 포스팅에서는 서버의 상태를 엑스레이처럼 들여다볼 수 있는 ‘스레드 덤프(Thread Dump)’의 생성 방법과 주요 상태(State)에 대해 알아보았습니다. 이번 글에서는 멀티 스레드 프로그래밍 환경에서 개발자들이 겪을 수 있는 최악의 악몽이자, 스레드 덤프 분석을 통해 반드시 찾아내야 하는 치명적인 오류인 교착 상태(Deadlock, 데드락)에 대해 완벽하게 해부해 보겠습니다. 서버가 다운된 것도 아니고 CPU 사용량이 치솟지도 않았는데 애플리케이션이 먹통이 … 더 읽기

서버를 운영하다 보면 OutOfMemoryError처럼 명확한 에러 로그를 남기며 서버가 죽는 경우도 있지만, 에러도 없이 CPU 사용률이 100%로 치솟거나 사용자의 요청에 서버가 먹통(Timeout)이 되는 현상이 더 자주 발생합니다. 이럴 때 개발자가 서버의 내부 상황을 들여다보기 위해 촬영하는 ‘X-ray 사진’이 바로 스레드 덤프(Thread Dump)입니다. 엔터프라이즈 환경에서 성능 튜닝과 장애 분석을 마스터하려면 스레드 덤프를 추출하고 해석하는 능력이 필수적입니다. … 더 읽기