2010 년 10월 런던에 외환거래를 위해 설립된 the LMAX Exchange 의 개발자들은 Azul Zing Java VM 을 사용하여 이미 빠른 응답 시간과 처리량을 제공하는 시스템을 개선하려는 테스트를 진행했습니다.
LMAX Exchange 는 그들의 기술적 선택에 대해서 기꺼이 공개하는 것으로 금융권 이외에서도 유명한 금융서비스 회사입니다.
이 회사는 자신의 소프트웨어 핵심 컴포넌트인 the Disruptor framework 을 2011년 3월에 QCon 이나 다른 컨퍼런스에서 발표를 하였습니다.
- MAX Disruptor : 100,000 TPS at less than 1ms latency – http://www.infoq.com/presentations/Concurrent-Programming-Using-The-Disruptor)
-
LMAX Exchange 는 성능에 대하여 자사 사이트에 공개하고 있다.
LMAX는 피크 시에는 초당 5,000 이며, 드물게 초당 20,000을 초과
위의 그림과 같이 현재 웹사이트에 공개된 성능 자료에 따르면 엔드투엔드 거래 시간은 3.14ms 이며 5초 이하이다.
LMAX는 초 당 평균 1,000에서 2,000 주문을 처리하고 있다. 피크 시에는 초당 5,000을 넘는 경우도 있으며, 드물게 초당 20,000을 초과하는 경우도 있다고 한다.
Barker (Michael Barker, Head of Software at LMAX Exchange) 에 따르면 “우리는 최대 부하를 기준으로 테스트하고 있다. 테스트를 정기적으로 실행하여 어느 시점에서 시스템이 불가능한 상태로 변화하는 지를 확인한다. 이것을 ‘레드 라인’ 테스트라고 부르고 있다”
LMAX 에서는 HotSpot 의 CMS Garbage Collector 에서 Stop-The-World 정지가 성능의 큰 문제가 되고 있었다. LMAX 는 JDK7 에서 CMS 버전을 업그레이드하였지만, GC 정지 시간이 20% 정도 증가하였다.
Barker 에 따르면 원인은 불분명하지만 GC Collector 를 다시 조정할 수 뿐이 없다고 생각했다. 하지만 Azul Zing VM 의 C4 Collector 는 그러한 튜닝 작업이 필요 없기 때문에 LMAX Exchange 가 선택하는 주된 요인이 되었다.
우리는 -XX:+UseCondCardMark이나 -XX:+ UseNUMA 같은 JDK 7 의 옵션들을 적용해야 하는 지에 대한 검토와 GC 셋팅들을 튜닝할 필요가 있었다.
이것이 바로 Azul 을 선택하게된 가장 큰 이유 중에 하나로 컬렉터를 튜닝하는 것을 감소시켜 주기 때문이다.
Azul Zing Java는 기본 설정에서도 제대로 튜닝된 Oracle JDK 보다 뛰어난 성능 제공
새로운 JDK 버전마다 처음부터 튜닝을 해야 하는 것이 일반적인 권장 사항으로 이론적으로는 괜챦은 것처럼 들리지만 현실은 이와 다르다.
Oracle JDK 에서 컬렉터를 튜닝하여 원하는 결과를 얻기 위해서는 폭넓게 공부해야만 한다. 경험과 지식 그리고 추측을 통해 넓었던 범위가 극적으로 좁혀질 수도 있지만 그래도 튜닝 작업은 몇 주 정도는 걸릴 것이다.
예를 들자면 우리의 End-to-end 성능 테스트는 1시간 (10분 빌드와 배포, 10분 준비, 40분 테스트) 걸리고 하루에 8번 테스트할 수 있다. 만약 다른 종류의 컬렉터(CMS, Pararrel, Serial,…) 들과 관련된 컬렉터들의 옵션(new와 old 사이즈, survivor spaces, suvivor ratios ..) 들을 고려해보면 얼마나 많이 테스트를 진행해야 그 많은 경우의 수에 대해 효율적인 테스트였다고 할 수 있을까?
Azul Zing Java VM은 초기 상태에서도 제대로 튜닝된 Oracle JDK 보다 뛰어난 성능을 발휘한다. Zing VM 을 튜닝하여 보다 높은 성능을 올릴 수 있는지에 대해서 검토하고 있으나 Zing 을 튜닝하는 것은 이미 충분한 성능의 시스템을 최상의 상태로 하려는 것과 같다.
Oracle JDK 와 비교해보면 초기상태에서 튜닝하는 것이 의미가 있을 수도 또는 없을 수도 있다. 하지만 이러한 튜닝을 위한 노력들은 기회비용이 소요될 수 뿐이 없다. 소프트웨어 성능에 대하여 최고의 기술들을 가져야 하는 개발자들이 GC 튜닝에 노력을 기울기 보다는 시스템의 다른 영역에서 성능 개선에 초점을 가지는 것을 원한다.
우리는 두 개의 새로운 컬렉터(IBM의 Balanced GC 와 Oracle G1) 들에 대해서도 살펴보았다. 이 두개는 서로 독립적으로 개발되고 있었지만 매우 유사하며 낮은 정지 시간을 제공하는 것에 초점을 맞추고 있었다. 그것들은 다른 영역보다 자주 참조되는 메모리 영역이 있다는 것을 전제로하는 incremental compaction 기술을 사용한다. 컬렉터는 한번에 하나의 지역에 대해서만 compaction (조각모음)을 하고, 모든 잠재적인 참조를 다시 맵핑 할 때만 그 영역의 참조를 검사한다. 대부분의 애플리케이션에서는 이러한 가정이 타당하지만 모든 어플리케이션에 적용 되는 것은 아니다. Balance GC 와 G1 모두 Cocurrent Marker를 가지고 old 영역에 incremental compaction을 수행하지만 stop-the-world 컬렉터이기 때문에 성능이 저하된다.
결국에는 Azul의 C4 컬렉터와 다른 상용 Java VM 은 이러한 점에서 차별화된다. 다른 상용 JVM 컬렉터들은 New 영역과 Old 영역에 대해서 non-concurrent stop-the-world 컬렉터를 사용한다. 반대로 Azul 의 Zing C4 컬렉터는 new 영역과 old 영역에 대하여 동시 완전한 병렬 Compacting 알고리즘을 사용하기 때문에 성능의 저하가 없다.
위와 같은 이유로 인하여 LMAX Exchange 는 IBM의 Balanced GC 와 Oracle G1 에 대해서 테스트를 진행하지 않았다.
Baker 에 따르면 ” 두개의 GC 모두가 CMS 가 본질적으로 가지고 있는 문제와 동일한 문제를 가지고 있습니다. 잠재적인 정지시간을 완전히 배제 할 수 는 없었습니다. “
성능을 저하시키는 가장 큰 문제는 GC 이며, 성능 튜닝에 있어서 가장 큰 문제
결국에는 시장에서 선택 가능하고 활용 가능해 보이는 GC 는 IBM Metronome 컬렉터와 Oracle JRockit Realtime 컬렉터이다.
IBM Metronome 는 매우 흥미롭고 많은 시간을 투자해서 살펴보았다. 그러나 몇 가지 이슈에 직면하여 테스트를 진행하지는 않았다.
IBM에 따르면 “JDK 를 극악한 상황에서 매우 힘든 테스트를 진행하는 상황이라서 대부분의 애플리케이션에서 사용하는 환경이 아니고 문제점은 빠르고 정확하게 해결되었다” 고 언급했다.
한편 Oracle JRockit Real Time은 불행하게도 JDK 1.6 이후에 버전에 대해서는 지원하지 않으며 개발을 중단하였다.
Azul Zing 만이 유일하게 잘 동작하였고 긍정적인 결과를 보여주었다.
Azul Zing 만이 유일하게 잘 동작하였고 긍정적인 결과를 보여주었다.
Azul 개발팀은 우리의 적용 사례를 위한 제품 개선에 함께 밀접하게 작업해 주었다. 그래서 우리는 Azul Zing 에 대해 구매를 결정하였다.
결과적으로는 LMAX Exchange 는 괄목할만한 성과를 거둘 수 있었다. 대기 시간은 10~20% 개선되었으며 99 백분위(지연시간 최상위 1%) 는 50% 개선되었다.
HotSpot의 경우 지연 시간의 최상위 1%와 나머지 와의 차이가 크고 Azul Zing 과 비교하기 어려운 결과였다. Hotspot 은 상황이 안 좋은 경우에 더욱 악화되었다.
성능을 저하시키는 가장 큰 문제는 GC 이며, 성능 튜닝에 있어서 가장 큰 문제
결국에는 시장에서 선택 가능하고 활용 가능해 보이는 GC 는 IBM Metronome 컬렉터와 Oracle JRockit Realtime 컬렉터이다.
IBM Metronome 는 매우 흥미롭고 많은 시간을 투자해서 살펴보았다. 그러나 몇 가지 이슈에 직면하여 테스트를 진행하지는 않았다. IBM에 따르면 “JDK 를 극악한 상황에서 매우 힘든 테스트를 진행하는 상황이라서 대부분의 애플리케이션에서 사용하는 환경이 아니고 문제점은 빠르고 정확하게 해결되었다” 고 언급했다.
한편 Oracle JRockit Real Time은 불행하게도 JDK 1.6 이후에 버전에 대해서는 지원하지 않으며 개발을 중단하였다.
Azul Zing 만이 유일하게 잘 동작하였고 긍정적인 결과를 보여주었다. Azul 개발팀은 우리의 적용 사례를 위한 제품 개선에 함께 밀접하게 작업해 주었다. 그래서 우리는 Azul Zing 에 대해 구매를 결정하였다.
결과적으로는 LMAX Exchange 는 괄목할만한 성과를 거둘 수 있었다. 대기 시간은 10~20% 개선되었으며 99 백분위(지연시간 최상위 1%) 는 50% 개선되었다.
HotSpot의 경우 지연 시간의 최상위 1%와 나머지 와의 차이가 크고 Azul Zing 과 비교하기 어려운 결과였다. Hotspot 은 상황이 안 좋은 경우에 더욱 악화되었다.
처리성능은
Zing 은 레드라인으로 불리는 기준을 높여 주었다. 레드라인은 지연 시간을 단번에 악화 시키는 성능 임계점이다. 이러한 성능의 악화는 GC 의 정지 시간으로 인하여 촉발된다. 오랜 시간 성능 저하가 발생되어 패킷이 드롭되기 시작된다. 패킷을 재전송하지만 이는 시스템의 다른 부분에 추가적인 부하를 발생시켜 클라이언트 입장에서 지연 시간은 급상승한다.
Zing 은 예측할 수 있고 정지 시간이 짧은 효율적인 컬렉터로 인하여 우리는 “레드라인” 높일 수 있었다.
Barker 는 성능의 차이를 유발하는 많은 문제들이 있다고 지적한다 – 나쁜 코드, OS Jitter, Lock 경합 그리고 LMAX Exchange와 고객 사이의 대역폭 등이며 이러한 문제들은 LMAX와 고객들의 경험을 바탕으로 한것이다.
“무엇보다도 가장 성능을 저하시키는 가장 큰 문제는 GC 였다. 또한 대부분의 성능 튜닝에 있어서 제일 큰 문제를 제일 먼저 해결해야 한다.”
Azul Zing 만이 유일하게 잘 동작하였고 긍정적인 결과를 보여주었다. Azul 개발팀은 우리의 적용 사례를 위한 제품 개선에 함께 밀접하게 작업해 주었다. 그래서 우리는 Azul Zing 에 대해 구매를 결정하였다.
결과적으로는 LMAX Exchange 는 괄목할만한 성과를 거둘 수 있었다. 대기 시간은 10~20% 개선되었으며 99 백분위(지연시간 최상위 1%) 는 50% 개선되었다.
HotSpot의 경우 지연 시간의 최상위 1%와 나머지 와의 차이가 크고 Azul Zing 과 비교하기 어려운 결과였다. Hotspot 은 상황이 안 좋은 경우에 더욱 악화되었다.
처리성능은
Zing 은 레드라인으로 불리는 기준을 높여 주었다. 레드라인은 지연 시간을 단번에 악화 시키는 성능 임계점이다. 이러한 성능의 악화는 GC 의 정지 시간으로 인하여 촉발된다. 오랜 시간 성능 저하가 발생되어 패킷이 드롭되기 시작된다. 패킷을 재전송하지만 이는 시스템의 다른 부분에 추가적인 부하를 발생시켜 클라이언트 입장에서 지연 시간은 급상승한다.
Zing 은 예측할 수 있고 정지 시간이 짧은 효율적인 컬렉터로 인하여 우리는 “레드라인” 높일 수 있었다.
Barker 는 성능의 차이를 유발하는 많은 문제들이 있다고 지적한다 – 나쁜 코드, OS Jitter, Lock 경합 그리고 LMAX Exchange와 고객 사이의 대역폭 등이며 이러한 문제들은 LMAX와 고객들의 경험을 바탕으로 한것이다.
“무엇보다도 가장 성능을 저하시키는 가장 큰 문제는 GC 였다. 또한 대부분의 성능 튜닝에 있어서 제일 큰 문제를 제일 먼저 해결해야 한다.”
Azul 은 Zing 덕분에 금융 서비스 기업들에게 좋은 평판을 얻고 있다. Azul 의 CTO 인 Gil Tene 에 따르면 Azul의 금융 서비스 고객 중 LMAX Exchange 는 우수한 기술과 뛰어난 성능으로 유명하지만, 최고의 low Latency 사례는 아니며 더 높은 low latency 를 추구하는 고객도 있다고 한다.
금융 서비스 회사에게 Azul Zing 이 매력적인 이유는 new 영역과 Old 영역에 대하여 Stop-the-world 없는 유일한 컬렉터이기 때문이다.
Tene 에 따르면
지연 또는 중단 없이 초당 수 기가의 Allocation 을 처리하는 것은 이러한 문제점을 회피하기 위해서는 노력해온 개발자에게는 매우 매력적인 것이다. Zing 을 사용하면 성능을 높이기 위하여 많은 Heap 메모리를 사용할 수 있어 더 이상 큰 힙사이즈로 인하여 고통해서 벗어날 수 있게 된다.
References & Related Links
- LMAX Exchange Getting Up To 50% Improvement in Latency From Azul’s Zing JVM – http://www.infoq.com/news/2013/05/lmax-zing
미국 Oracle이 2018 년 6 월 21 일, Java SE에 대한 유료 구독 모델인 Java SE Subscription ( 이하 자바 서브스크립션)을 발표하였습니다.
오라클의 자바 서브스크립션은 데스크톱, 서버 또는 클라우드 환경에서 사용하기 위한 Java SE 에 대한 라이선스와 기술지원을 포함한 간단하고 저렴한 월단위 서브스크립션으로 Linux 배포판에서 널리 사용하는 모델입니다.
서브스크립션을 통해 오라클은 자바에 대한 검증되고 인증된 성능, 안정성과 보안 업데이트에 대한 권한을 제공합니다.
오라클은 2019 년 1 월부터 자바 비즈니스 사용자에게 자바 서브스크립션 판매를 시작합니다. 2019년 부터는 서브스크립션을 가지고 있지 않으면 자바에 대한 업데이트를 할 수 없습니다.
