TWJUG@LINE 회의 노트: 2019년 9월 5일

Source: Dev.to

서문

안녕하세요, 저는 LINE Taiwan의 Evan Lin 기술 전도사입니다.
2019‑09‑05 저녁에 TWJUG 커뮤니티를 LINE 타이베이 사무실로 초대하여 또 다른 커뮤니티 모임을 갖게 되어 기뻤습니다.

연사

• Shinya Yoshida – LINE 도쿄 사무실
• Yuto Kawamura – Kafka Summit 2017 연사

주제

1. ZGC for Future LINE HBase
2. Kafka Broker performance degradation by mysterious JVM pause

행사 URL – KKTIX:

Source:

ZGC for Future LINE HBase – Shinya Yoshida

Slides

LINE에서 HBase 관련 처리를 담당하고 있는 Shinya Yoshida가 LINE 서비스에서 HBase가 어떻게 사용되는지 공유했습니다.
HBase는 저지연과 고가용성이 요구되는 JVM 기반의 널리 사용되는 NoSQL 스토어입니다. JVM의 STW (Stop‑The‑World) 가비지 컬렉션은 모든 스레드를 일시 중지시킬 수 있어, 고처리량·저지연 워크로드에 큰 걸림돌이 됩니다. 이번 발표에서는 성능 튜닝 기법과 관찰 결과를 다루었습니다.

GC Basics

가비지 컬렉션은 두 가지 주요 단계로 구성됩니다:

1. Finding the garbage

• Goal – 회수할 수 있는 메모리를 표시합니다.
• Algorithms
  • Reference counting – 객체에 대한 참조 수를 셉니다; 참조 수가 0이 되면 해당 객체는 수집 대상이 됩니다.
  • Tracing (Mark) – GC 루트에서 객체 그래프를 탐색합니다; 도달할 수 없는 객체는 가비지로 간주됩니다.

2. Collecting the garbage and defragmenting

• Goal – 메모리를 회수하고 힙을 압축합니다.
• Algorithms
  • Sweep / Compaction – 도달할 수 없는 객체를 회수한 뒤, 살아있는 객체를 이동시켜 단편화를 없앱니다.
  • Copying – 새로운 영역을 할당하고 살아있는 객체를 복사한 뒤, 기존 영역을 폐기합니다. 메모리 사용량이 늘어나지만 일반적으로 더 빠릅니다.

Modern GC Algorithms

위 다이어그램은 오늘날 사용되는 여러 가비지 컬렉션 알고리즘을 보여줍니다:

Choosing a GC

1. 각 컬렉터의 트레이드오프(처리량 vs. 일시 중지 지연, 메모리 오버헤드, 하드웨어 요구사항)를 이해합니다.
2. 하드웨어와 워크로드에 컬렉터를 맞춥니다(CPU 코어 수, 힙 크기, 지연 요구사항 등).

Performance Comparison (ZGC vs. G1GC)

• **대용량 메모리 구성(128 GB)**에서 ZGC가 G1GC보다 업데이트와 읽기 성능 모두에서 더 우수한 결과를 보였습니다.
• ZGC가 아직 Java 11에서 실험 단계였기 때문에, LINE에서는 내부 성능 테스트 용도로만 사용했습니다. 추후 추가 실험 결과와 공식 롤아웃 계획은 나중에 공유될 예정입니다.

Kafka 브로커 성능 저하와 미스터리한 JVM 일시정지 – Yuto Kawamura

슬라이드

개요

이 섹션은 LINE의 시니어 엔지니어 Yuto Kawamura가 실서비스에서 발생한 문제를 디버깅한 과정을 공유합니다. Kafka는 LINE 메시지 백엔드에서 매우 중요한 위치를 차지하고 있으며, 60개가 넘는 서비스가 Kafka를 사용합니다(이 슬라이드 참고). 발표자는 Kafka와 관련된 사고를 소개하고 전체 디버깅 과정을 설명했습니다.

현상 / 문제

원래 각 Kafka 메시지는 원활히 처리되었지만, 어느 순간 다음과 같은 상황이 일정 기간 동안 발생했습니다:

• 99번째 백분위수 프로듀서 지연 시간의 응답 시간 악화.
• Zookeeper 세션 타임아웃.

문제가 드러났을 때 팀이 관찰한 내용:

• 각 실행 중인 스레드의 CPU 사용량이 급증.
• **GC 일시정지 시간 (STW)**이 증가; JVM의 stop‑the‑world 일시정지가 눈에 띄게 길어짐.

범위 좁히기 시작

이 결과를 바탕으로 발표자는 디버깅 경험을 다음과 같이 공유했습니다:

1. 가정 – 일부 JVM 수준 이벤트가 시스템을 지나치게 느리게 만들고 있었다.
2. 재현 – 동일한 환경을 재현하려 시도함.

STW (Stop‑The‑World) 에 대해

GC가 실행될 때 JVM은 두 가지 작업을 수행합니다:

1. 안전 지점 설정 – JVM에 GC를 시작하도록 알림.
2. 안전 지점 동기화 – JVM이 모든 실행 중인 스레드가 일시정지될 때까지 대기.

JVM의 안전 지점 동기화가 과도한 지연을 초래하는지 테스트하기 위해 발표자는 시스템이 너무 일찍 안전 지점에 도달하지 못하도록 매우 긴 중첩 루프를 작성했습니다. 행동을 관찰함으로써 가설을 확인(또는 반증)하고 문제가 재현되는지를 확인할 수 있었습니다.

이 과정은 반복적이었습니다: 가설을 지속적으로 세우고, 테스트 도구를 작성하고, 문제를 재현하고, 최종적으로 저수준 관찰 도구로 가정을 검증합니다.

근본 원인은 무엇이었을까요? 발표자는 이를 비밀로 유지했습니다 – 전체 이야기는 슬라이드를 참고하시기 바랍니다.

참고 문헌

• Kafka 밋업 JP #3 – LINE에서 Apache Kafka 엔지니어링

이벤트 요약

이번 모임에서는 JVM 수준 디버깅과 Kafka 성능 문제에 대해 심도 있게 살펴보았습니다. 참석자들은 유용한 지식을 얻었으며, 슬라이드를 더 자세히 살펴보고 결과에 대해 논의해 보시기 바랍니다.

“LINE Developer Official Community”에 가입하면 최신 모임 소식과 개발자 프로그램에 대한 푸시 알림을 직접 받아볼 수 있습니다.

공식 계정 ID: @line_tw_dev

About the “LINE Developer Community Program”

LINE은 올해 초 대만에서 LINE Developer Community Program을 시작했습니다. 이 프로그램은 장기적인 인력과 자원을 투자해 내부·외부, 온라인·오프라인 개발자 모임, 채용 행사, 컨퍼런스 등을 주최합니다. 연간 30개 이상의 이벤트가 계획되어 있습니다.

업데이트를 기대해 주세요. 자세한 내용은 지속적으로 업데이트되는 일정표를 확인하십시오:

• 2019 LINE Developer Community Program 이벤트 일정 (지속적으로 업데이트)

TWJUG 커뮤니티가 LINE 밋업을 위해 준비, 2019‑09‑05.