TIL

Chapter 14. 고성능 로깅 및 메시징

• 로깅은 모든 자바 개발자가 당연히 관심을 가져야 할 문제
• 관리/운영이 잘 되는 자바 시스템은 대부분 상당량의 로그 메시지를 지니고 있다.
• 메시징 시스템은 수년간 가장 성공적으로 정착한 아키텍처 패턴
  • 저지연 시스템의 최전방에 위치해 초 단위로 처리된 메시지 개수로 성능을 측정

14.1 로깅

• 제품급 로깅 시스템 선정 시 바람직하지 않은 안티패턴
  • 10년짜리 로거 - 누군가 이미 설정해 놓은 로거를 계속 다시 사용
  • 프로젝트 전체 로거 - 프로젝트 각 파트마다 따로 로거를 재구성하지 않도록 로거를 감싸 놓음
  • 전사 로거 - 누군가 전사적으로 사용 가능한 로거를 만들어 놓음
• 업무적으로 그리 중요하지 않다 생각하는 로깅 시스템을 유지 보수할 때 기술 부채로 이어지기도 한다.
• 대부분 고성능 환경에선 처리 정확도와 리포팅(보고)이 속도만큼 중요

14.1.1 로깅 벤치마크

• 가장 많이 쓰는 세 로거의 성능을 공정하게 비교하는 벤치마크를 살펴보자.
  • Logback, Log4j, java.util.logging
• 스티븐 콘놀리의 오픈 소스 프로젝트에서 인용할 자료로 소개할 것
• 로깅 없음
  • 무동작 로그의 비용을 측정하는 벤치마크 테스트
  • 즉 실험 결과를 비교할 대조군

• Logback 포맷

    14:18:17.635 [Name of Thread] INFO c.e.NameOfLogger - Log message
  

  • Logback 1.2.1 버전을 사용한 벤치마크

• java.util.logging 포맷

    Feb 08, 2017 2:09:19 PM com.example.NameOfLogger nameOfMethod
    INFO: Log message
  

• Log4j 포맷

    2017-02-08 14:16:29,651 [Name Of Thread] INFO com.example.NameOfLogger - message
  

• 로거 결과
  • 어떤 로깅 포켓, 어떤 로깅 프레임워크를 사용했는지, 그리고 설정값에 따라 결과는 다양하다.
  • 실행 시간 측면에선 대체로 Logback 성능이 가장 좋고 자바 유틸 로거가 제일 나빳다.
  • Log4j 포맷은 일반적으로 가장 일관된 결과를 보임
• 마이크로벤치마크는 문제를 작은 통 안에 넣고 보기 때문에 시스템 전체에 미치는 영향도는 가려지는 위험성이 있다.
• 로깅 프레임워크가 생성하는 가비지도 잘 따져봐야 한다.
  • 로깅하는 데 소비한 CPU 시간만큼 핵심 업무를 병렬 처리할 기회를 잃어버리기 때문

14.2 성능에 영향이 적은 로거 설계하기

• 로깅은 필수 컴포넌트지만 저지연 애플리케이션에서 로거가 성능 병목을 초래해서는 안 된다.
• Log4j 2.6 버전은 가비지-프리한 로거로 해결하는 것을 목표로 출시되었다.
  • 각 로그 메시지마다 임시 객체를 생성했던 로직을 객체를 재사용하는 방향으로 수정
  • 객체 풀 패턴을 실천한 전형적 사례
  • ThreadLocal 필드를 이용해 스트링 → 바이트 변환 시 버퍼를 재사용하며 객체를 재사용한다.
• Log4j를 SLF4J로 감싸면 퍼사드가 매개변수를 2개만 지원한다.
  • 가비지-프리 방식을 응용하거나 라이브러리를 직접 사용해서 리팩터링할 필요가 없다.

14.3 리얼 로직 라이브러리를 이용해 지연 줄이기

• 리얼 로직
  • 마틴 톰슨이 설립한 영국 회사
  • 저수준 세부 이해가 고성능 설계에 영향을 미친다는 기계 공감 접근 방식 추구
  • 디스럽터 패턴은 그가 자바 세계에 기여한 가장 유명한 작픔
• 리얼 로직 깃허브에는 다양한 유명 오픈 소스 프로젝트가 나열돼 있다.
  • 아그로나: 자바용 고성능 자료 구조 및 유틸 메서드
  • 단순 바이너리 인코딩(SBE): 고성능 메시지 코덱
  • 에어론: 효율/안정적 UDP 유니캐스트, UDP 멀티캐스트, IPC 메시지 전송
  • 아티오: 탄력적인 고성능 FIX 게이트웨이

14.3.1 아그로나

• 저지연 애플리케이션 전용 구성 요소를 담은 라이브러리
• 표준 라이브러리만으로 유스케이스 충족이 어렵다면 아그로나를 검토해보는 수순이 합리적

아그로나 - 버퍼

• 자바엔 ByteBuffer 클래스가 존재
  • 다이렉트/논다이렉트 버퍼를 추상화
  • 다이렉트 버퍼는 자바 힙 밖에, 논 다이렉트버퍼는 JVM 힙 내부에 존재
  • 다이렉터 버퍼는 논다이렉트버퍼보다 할당/해제율은 낮은 편
  • 다이렉트 버퍼는 구조체에 명령어를 실행해 입출력 성능이 좋다. (버퍼 생성은 논다이렉트보다 느리다고 함)
• ByteBuffer의 문제
  • 버퍼 타입별로 최적화를 적용할 수 없다.
  • 아토믹 연산을 지원하지 않아 생산자/소비자 버퍼를 구축할 때 제약이 존재
  • 매번 다른 구조체를 감쌀 때마다 하부 버퍼를 새로 할당해야 한다.
• 아그로나는 복사를 지양하며 독특한 특성의 네 가지 버퍼를 지원
  • DirectBuffer 인터페이스: 버퍼에서 읽기만 가능하며 최상위 계층에 위치
  • MutableDirectBuffer 인터페이스: DirectBuffer를 상속하여 버퍼에 쓰기도 가능
  • AtomicBuffer 인터페이스: MutableDirectBuffer를 상속하여 메모리 엑세스 순서까지 보장
  • UnsafeBuffer 클래스: Unsafe를 이용해 AtomicBuffer를 구현한 클래스
• 아그로나 버퍼를 통해 다양한 get 메서드로 하부 데이터를 가져올 수 있다. (ex. getLong(int index))
• put 메서드로 버퍼 특정 위치에 값을 넣을 수도 있다.
• 경계 검사 기능 설정/해제가 가능하므로 불필요한 코드는 JIT 컴파일러로 최적화할 수 있다.

아그로나 - 리스트, 맵, 세트

• 자바 표준 컬렉션 문제
  • 자바는 배열 안에서 객체를 나란히 배치하는 장치가 따로 없어 표준 컬렉션은 항상 레퍼런스 배열이다.
  • 표준 컬렉션에선 항상 객체를 사용하도록 하기 때문에 객체 자체 크기 오버헤드도 있지만 자동박싱/언박싱도 발생
• 아그로나는 int 또는 long 형 배열에 기반한 리스트 구현체를 여러 제공한다.
• ArrayListUtil을 이용하면 리스트 순서는 안맞지만 ArrayList에서 신속하게 원소를 제거할 수 있다.
• 아그로나 맵, 세트 구현체는 키/값을 해시 테이블 자료 구조에 나란히 저장한다.
  • 키가 충돌하면 다음 값은 해시 테이블 해당 위치 바로 다음에 저장된다.
  • 동일한 캐시 라인에 있는 기본형 매핑을 빠르게 엑세스할 때 알맞는 자료 구조

아그로나 - 큐

• 아그로나 동시성 패키지에는 큐, 링 버퍼를 비롯한 동시성 유틸리티가 존재
  • 아그로나 큐는 java.util.Queue 인터페이스를 준수
  • 순차 처리용 컨테이너 지원 기능이 부가된 org.agrona.concurrent.Pipe 인터페이스도 존재
• 큐는 모두 락-프리하고 Unsafe를 사용하므로 저지연 시스템에 적합
• 서로 다른 생산자/소비자 모델을 제공하는 일련의 큐를 1차적으로 지원하는 추상 클래스 제공
  • org.agrona.concurrent.AbstractConcurrentArrayQueue
  • 생산자, 소비자를 각자 별개의 캐시 라인에 놓아두어 저지연, 고처리율 상황에서 성능을 기대하도록 함
  • OneToOneConcurrentArrayQueue
    • 하나의 생산자, 하나의 소비자
    • ‘유일한 동시 엑세스는 생산자, 소비자rk 자료구조에 동시 엑세스할 때만 발생한다’는 정책을 선택하는 것과 같다.
    • 한 번에 하나의 스레드에 의해서만 업데이트되는 헤드, 테일의 위치가 중요
    • 부수적인 조정 체크를 할 필요가 없어 성능 누수가 없다.
  • ManyToManyConcurrentArrayQueue
    • 생산자가 다수인 경우엔 테일 위치를 업데이트할 때 부가적인 제어 로직이 필요
    • while 루프에서 Unsafe.compareAndSwapLong을 사용해 락-프리하게 업데이트할 수 있다.
  • ManyToOneConcurrentArrayQueue
    • 생산자, 소비자 모두 다수일 경우
    • comapreAndSwap을 감싼 while 루프가 필요
    • 조정 과정이 가장 복잡하다.

아그로나 - 링 버퍼

• org.agrona.concurrent.RingBuffer
  • 프로세스 간 통신용 바이너리 인코딩 메시지를 교환하는 인터페이스
  • DirectBuffer를 이용해 메시지 오프-힙 저장소를 관리
  • 링 버퍼 구현체는 OneToOneRingBuffer, ManyToOneRingBufer
  • 쓰기 작업은 소스 버퍼를 전달 받아 메시지를 별도의 버퍼에 쓴다.
  • 읽기 작업은 메시지 핸들러의 onMessage() 메서드로 콜백된다.1

14.3.2 단순 바이너리 인코딩

• 단순 바이너리 인코딩(SBE)는 저지연 성능에 알맞게 개발된 바이너리 인코딩 방식
  • 금융 시스템에 쓰이는 FIX 프로토콜에 특화되어 있다.
• SBE는 메시지를 인코딩/디코딩하는 애플리케이션 계층의 관심사
  • 버퍼는 아그로나에서 빌려 사용
• SBE는 효율적인 자료 구조를 통해 저지연 메시지 전달이 가능하다.
  • GC를 유발하지 않는다.
  • 메모리 엑세스 문제를 최적화하지 않음에도 가능
• 수 밀리초, 수 나노초 이내로 반응해야 하는 고빈도 거래 환경에 맞춤 설계되었다.

SBE 설계 결정

• 카피-프리, 네이티브 타입 매핑
  • 자바에선 메모리가 자동 관리되어 객체를 복사하는 실수를 저지르는 일은 없다
  • SBE의 카피-프리 기술은 중간 버퍼를 쓰지 않고 메시지를 인코딩/디코딩하도록 설계되었다.
  • 단, 하부 버퍼에 직접 쓰는 작업은 설계 비용이 드는데 버퍼에 못넣을 정도의 큰 메시지는 조각조각 나누어 다시 조립하는 프로토콜을 구축해야 한다.
  • 어셈블리 명령어에 네이티브하게 매핑되는 타입도 카피-프리하게 작업하는 게 좋다.
• 정상 상태 할당
  • 저지연 애플리케이션에서 객체 할당은 당연히 비용이다.
  • TLAB에서 할당 비용이 거의 없다 해도 CPU 사이클을 소모하는 건 사실이고 GC STW도 문제다.
  • SBE는 하부 버퍼 플라이트웨이트 패턴을 사용해 할당-프리하다.
  • 플라이트웨이트 패턴: 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 메모리 사용량을 최소화하는 디자인 패턴
• 스트리밍/단어 정렬 엑세스
  • 자바 배열은 보통 레퍼런스 배열 형태라 메모리 순차 읽기가 불가능
  • SBE는 메시지를 진행 방향으로 인코딩/디코딩하도록 설계되어 있어 단어를 정확하게 정렬 가능
  • 정렬이 엉망인 상태에선 프로세서 수준에서 성능 문제가 발생할 수도 있다.

SBE 써보기

• 메시지 작업에 관한 튜토리얼은 SBE 자바 유저 가이드에 잘 정리되어 있다.

14.3.3 에어론

• 에어론은 애플리케이션이 같은 머신에서, 또는 네트워크를 넘나들며 IPC를 통해 서로 소통할 수 있게 해주는 것들을 망라한 일반적인 프로토콜
  • SBE와 아그로나에 기반한 툴
  • UDP, 유니캐스트, 멀티캐스트, IPC 메시지를 전송하는 수단

에어론 구성 컴포넌트

• 미디어 - 에어론이 통신하는 매개체 (UDP, IPC 등)
  • 요는 에어론이 클라이언트로서 이 매체들을 모두 추상화했다는 점
• 미디어 드라이버 - 미디어와 에어론 사이 연결 통로로 원하는 전송 구성을 세팅해 통신할 수 있다.
• 감독자 - 전체 흐름을 관장.
  • 버퍼 설정
  • 새 구독자/발행자 요청을 리스닝.
  • NAK를 감지해 재전송 준비를 하기도 한다.
• 송신자 - 생산자로부터 데이터를 읽어 소켓으로 전송
• 수신자 - 소켓에서 데이터를 읽고 해당 체널/세션으로 내보냄

// 발행자
final MediaDriver driver = MediaDriver.lanunch();
final Aeron.Context ctx = new Aeron.Context();
try (Publication publication = aeron.addPublication(CHANNEL, STREAM_ID)) {
    // ...
    final long result = pulication.offer(BUFFER, 0, messageBytes.length);
}

// 구독자
final FragmentHandler fragmentHandler = 
    SamplesUtil.printStringMessage(STREAM_ID);
try (Aeron aeron = Aeron.connect(ctx);
    Subscription subscription = aeron.addSubscription(CHANNEL, STREAM_ID)) {
    SamplesUtil.subscriberLoop(
        fragment, FRAGMENT_COUNT_LIMIT, running
    ).accept(subscription);
}

14.3.4 에어론 설계 개념

• 전송 요건
  • 에어론은 OSI 4 전송 계층에서 메시징을 수행하기에 준수해야할 요건이 있다.
  • 저수준에서 무작위 순서로 오는 패킷을 다시 정렬해야 한다.
  • 유실된 데이터에 대해 재전송을 요청해야 한다.
  • 부하가 높아지면 흐름 제어 및 배압 측정 서비스가 지원되어야 한다.
  • 혼잡 제어 기능을 옵션으로 제공한다.
  • 단일 채널에서 다중 정보 스트림을 처리하여 전체 성능을 떨어뜨리면 안 된다.
• 지연 및 애플리케이션 원칙
  • 정상 상태에서의 가비지-프리 실현
  • 메시지 경로에 스마트 배칭 적용
    • 수신 메시지가 폭주하는 상황을 감안해야 한다.
    • 적절한 자료 구조를 이용해 생산자가 공유 리소스에 쓰는 걸 지연시키지 않고 배칭을 수행
  • 메시지 경로의 락-프리 알고리즘
  • 메시지 경로의 논블로킹 I/O
  • 메시지 경로의 비예외 케이스
    • 애플리케이션 대부분은 기본 시나리오를 처리하는데 대부분 시간을 소비
    • 특이 케이스도 잘 처리해야 겠지만 기본 시나리오 실행 속도를 제물로 삼아서는 안 된다.
  • 단일 출력기 원칙을 적용
    • 단일 출력기를 쓰면 큐 엑세스를 고도로 제어/조정할 필요가 없다.
    • 에어론 발행 객체는 스레드-안전하며 다중 출력기를 지원하지만 구독자 객체는 스레드-안전하지 않다.
  • 공유 안 하는 상태가 더 좋다.
    • 단일 출력기는 큐 경합을 해결하지만 가변 데이터를 공유해야 하는 문제를 유발한다.
  • 쓸데없이 데이터를 복사하지 말라
• 내부 작동 원리
  • 스킵 리스트 같은 복잡한 자료구조를 쓰는 기존 프로토콜은 시스템 지연 양상을 예측하기 힘들게 한다.
  • 에어론은 기본적으로 복제된 영구 로그 메시지를 생성
  • 자료 구조에 메시지 시퀸스를 생성