[개발지식] 대용량 데이터(트래픽) 처리 관련 추가 방안 (네이버 D2 블로그)

Hyo Kyun Lee·2024년 12월 1일

개발지식

목록 보기

61/66

1. 개요

트래픽 처리 관련한 성능 개선 작업을 진행하면서 근본적으로 처리할 수 있는 방안을 알아보았다. DB, Java에서 제어할 수 있는 방안은 한계가 있을 것이고, 더 큰 트래픽을
처리하기 위한 개념이나 여러 방안들이 더 존재할 것이라 생각하였다.

이 과정에서 네이버 블로그에 기재되어있는 내용들이 많은 참고가 될 것 같아서 기록한다.

현재 프로젝트에 바로 적용하기에는 쉽지는 않겠으나, 일단 안목을 넓힌다는 방향으로 읽었다.

2. 네이버 분산처리 모델

기본적으로 로드 밸런싱은 과도한 트래픽 요청이 올때 이를 각기 다른 서버로 분산시켜 응답에 대한 부담을 분산처리, 즉 완화해주는 것이다.

로드밸런싱에 문제가 생긴다면 로드밸런싱을 다중화하여 대응할 수 있다.
그러나 DB와 1:1대응이 되는 WAS에 문제가 생기면 대응하는 DB를 다시 바인딩해주거나, DB 자체도 다중화 및 데이터 분산화 등의 조치를 해주어야 하는데 쉽지 않다.

이에 대한 대응으로, 증가하는 트래픽에 유동적으로 서버와 WAS의 효율성을 확보하면서
대응할 수 있는 방안을 하기와 같이 정리한다.

핵심 : 정적 리소스의 웹서버 분산 처리

2-1. GCDN

Global CDN, 전 세계 캐시서버 거점을 위치하여 HTML/CSS와 같은 정적 페이지(리소스)를 호출해주는 서비스를 제공한다.

네이버라는 웹서버가 제공해주는 정적 페이지가 아닌, GCDN 서비스에서 분담하여 정적페이지를 처리해주므로 빠르고 트래픽 대응에 탄력적이다.

이는 결국 정적 리소스를 웹서버가 아닌 다른 서비스를 통해서도 처리할 수 있다는 의미이고, 트래픽 분산 처리의 한 방안으로 생각할 수 있다는 점이므로 기억해두자.

2-2. SSI

WAS와 함께, 웹서버에서도 지원하는 서버사이드 언어를 일컫는다. WAS뿐만 아니라, 웹서버를 이용한 처리를 사용하여, 요청/응답의 부담을 분산하여 처리할 수 있다면 그만큼 트래픽 제어를 효율적으로 할 수 있다.

2-3. Apache 커스텀 모듈

Apache는 WAS의 일종인데, APR(Apache Portable Runtime) 기반 커스텀 모듈 확장을 통하여 자체적인 HTTP 기반 통신을 처리할 수 있는 라이브러리로 기능을 확장해 사용할 수 있다.

SSI와 마찬가지로 WAS에 향하는 요청을 웹서버 단에서 처리할 수 있고, C언어 기반이므로 실행성능도 좋아 분산처리의 효과를 기대할 수 있다.

핵심 : 아키텍처의 부분적 도입

3-1. 부분적 MSA

다른 시스템과 연관성이 적은 독립적인 기능들은 별도 서비스로 구축하고, MSA 아키텍칭에 따라 자체적인 DB 바인딩을 구축한다.

핵심 : 트래픽 제어가 힘들때 외부 서비스 강제 차단 및 연쇄장애 방지

4-1. 서킷 브레이커

트래픽 제어가 힘들고, 이로 인한 연쇄 장애가 예상될 경우 외부 서비스를 아예 차단하고(요청 받아오는 것을 포기 및 데이터 재요청을 하지 않고) 미리 준비한 응답을 전달하는 방법이다.

델파이, 프로시저와 같은 로직으로 제어를 하는 것처럼 보였다.

핵심 : 서버의 추가/삭제에 대한 유동적 관리

5-1. 서비스 디스커버리

서로 다른 기능을 하는 서버군이 두 그룹으로 나뉘어져 있을때, 서버간 1:1 대응이 아닌 그룹으로 목록화하여 관리하는 방법으로 서버의 추가/삭제에 대한 재기동 리스크를 최소화하여 항상 최신의 서버 상태, 즉 트래픽에 대응할 수 있는 상태로 최신화할 수 있는 방법이다.

나의 경우 자체적인 서버를 구축하여 사용하는 온프레미스를 하였고, 서버의 환경이나 대수가 상당히 통제된(정해진) 환경에서 개발을 하였으므로 "서버 자체의 추가/삭제에 대한 유동적 대응"을 생각하지 못하였다. 추후 클라우드 환경에서 개발을 진행할 경우, 이 대안이 좋은 방안이 될 수 있다는 것을 알게 되었다.