- 넷플릭스가 CPU-Heavy한 Java Microservice를 m5.4xl(16 vCPU)에서 m5.12xl(48 vCPU)로 이관
- vCPU가 3배이므로 대략 3배의 성능 향상을 기대했지만, 처리량이 25%만 증가하는 상황이 발생
- 심지어 레이턴시가 50% 감소하고, CPU와 레이턴시 패턴 모두 '끊김'이 심해져버림(Choppy)
- 이를 해결하기 위한 여정들을 저수준 레벨까지 정리한 글
해결 과정
- 빠른 노드와 느린 노드를 비교해 보기로 함
- Flame Graph 와 JVM 프로파일링(JFR-Java Flight Recorder 활용) 으로는 차이를 알수가 없었음
- 앱/OS/JVM 수준에서는 이상한게 없어서 m5.12xl 인스턴스가 제공하는 PMC(Performance Monitoring Counters, PMU Counter)를 살펴봄
- 문제 중 하나는 "False Sharing" - 2개의 코어가 동일한 L1캐시 라인을 공유하는 관련없는 변수를 읽거나 쓸때 생기는 패턴
- JDK 코드에서 기능은 바꾸지 않고, 데이터 레이아웃만 변경하는 패딩 바이트를 삽입하여 요 문제를 해결
- 또 다른 문제는 "True Sharing" - 동일한 변수를 여러 쓰레드/코어에서 읽고 쓰는 것
- 이를 해결하기 위해 공유 변수에 쓰지 않고 JVM의 세컨더리 슈퍼 클래스 캐시를 우회
- 두가지 모두 패치하자 처음보다 3.5배 속도가 향상
- 이 문제를 해결하는 동안 5년동안 휴면상태로 있던 버그인 JDK-8180450에 대해서 알게 됨
결론
- JVM이 C++ 같은 성능지향 언어와 경쟁하는 고도로 최적화된 런타임 환경이라고 생각하는 경향이 있음
- 대부분의 워크로드에는 그렇지만, 특정 워크로드에 있어서는 애플리케이션의 구현 뿐만 아니라, JVM자체의 구현에 의해서도 영향 받을 수 있음
- 이번 경우는 JVM의 네이티브 코드에서 병목 현상을 찾아 패치하여, 해당 워크로드의 처리량을 3배 이상 향상 시키기 위해 PMC를 활용 했음
- 이런 종류의 성능 문제에 관해서는 CPU 마이크로아키텍처 수준에서 실행을 검사하는 능력이 유일한 해결책임
- Intel vTune은 m5.12xl 같은 인스턴스에서 노출되는 핵심 PMC 만으로도 귀중한 통찰력을 제공
- 클라우드의 모든 인스턴스들이 PEBS(Processor Event-Based Sampling)와 함께 포괄적인 PMC 세트를 제공한다면 더 심층적인 분석을 통해서 훨씬 더 큰 성능 향상을 할 수 있을 것