LINE 메시징 서버가 대용량 트래픽에 대응하는 전략

Connection 관리 전략

: 매번 요청할 때마다 Connection을 맺지 않고 HTTP와 TCP Keep-Alive를 사용하여 Connection이 일정 시간 후 끊어지도록 하여 성능 향상

: Proxy와 애플리케이션의 WAS가 연결된 구조에서는 Proxy 단에서 WAS에 전달할 수 있는 MaxConnection을 제한하여 WAS에서 Connection 부족으로 처리를 하지 못하는 상황을 방지하고 Connection이 급증하여 성능이 저하되는 문제를 해결

 

 

 

 

트래픽 패턴 분석 및 서버 증설, 벤치마크 테스트

: Redis를 사용하며, 과거 데이터를 기반으로 트래픽을 분석하고 예측

: 트래픽 패턴 분석은 Redis의 IOPS (Input/Output Operations Per Second)와 Used Memory 수치를 참고

: IOPS는 초당 요청 횟수를 의미

: Used Memory는 Redis에 저장된 데이터의 크기

: PUT 요청이 많을 경우 Used Memory를 주의 깊게 살펴보아야함

: 과거 데이터를 바탕으로 필요한 메모리 크기를 산정하고 증설

: 벤치마크 테스트는 트래픽을 서서히 증가시켜보는 것과 함께 한 번에 많은 트래픽을 부여

 

 

 

 

 

Redis 클러스터의 안정적이고 효율적인 사용

- Redis 활용

: Redis를 캐시 뿐만 아니라 주요 저장소로 활용

: 주요 저장소는 데이터 수명이 긴 것들을 보관

: 영구 저장소로는 HBase를 사용

: 60개 이상의 Redis 클러스터를 사용하고 각 머신에는 10~20개의 코어와 192~256GB의 메모리 포함

: 빠른 응답 속도를 위해 Client Side Shared 된 구조로 Redis 클러스터를 사용 (프록시를 사용하지 않아 더 빠른 응답 속도를 얻을 수 있음)

 

- Shading 규칙

: Fixed Size Ring 또는 Consistent Hashing을 사용

 

- DualWrite 사용하여 쓰기 작업 지연 시간 개선

: Redis에 쓰기 작업 수행 후 응답을 받으면 HBase에 기록

: HBase에 대한 기록은 백그라운드에서 수행

: 실패할 경우 Kafka에 기록

: 이후 Kafka을 통해 비동기적으로 처리

 

- 읽기 작업에 고가용성 부여

: 먼저 Redis에 읽기 요청을 보내고 응답이 오지 않으면 HBase에 읽기 요청. 먼저 도착하는 쪽을 응답으로 사용

: Redis가 다운되는 경우를 대비

 

- Hot Key 문제를 해결하여 안정적인 운영 (일부 키에 대한 액세스 빈도가 다른 키에 비해 압도적으로 높은 경우에 대한 해결)

: Write Intensive한 Hot Key는 재설계

: Read Intensive한 Hot Key는 동일한 키를 여러 클러스터에 복제하여 서비스 (Replicated Cluster. 애플리케이션은 클러스터 중 하나를 무작위로 선택하여 응답을 받음)

 

- Timeout과 Circuit Breaker 설정

: 타임아웃을 짧게 선정하여 분산 시스템에서의 안정성을 유지

: 서킷 브레이커를 통해 Fast Failure 처리로 Redis 서버에 대한 요청을 줄임

 

- 다양한 역할을 담당하는 Redis 클러스터 분리

: 성격이 다른 데이터를 별도의 클러스터로 구축

 

- 비정상적인 호출을 하는 사용자를 파악하여 차단

: 행동 패턴을 분석해 악성 사용자를 차단하고 클러스터의 IOPS를 안정화

 

- Redis 클러스터에 TTL을 추가하고 Eviction Policy를 설정

: UsedMemory가 지속적으로 증가하는 클러스터의 경우 TTL을 설정하고 제거 정책으로 volatile-ttl로 변경 (TTL이 가장 짧게 설정된 키를 제거)

 

 

 

 

 

 

 

 

Reference

여정민_Ethan / LINE 메시징 서버가 대용량 트래픽에 대응하는 전략 | 커리어리

RedisConf18 발표 후기

LINE 메시징 서버가 새해 트래픽을 대비하는 과정