네이버 메인 페이지의 트래픽 처리 - 본편 1

서비스 특성상 네이버 메인 페이지가 실행하는 역할의 대부분은 데이터를 사용자에게 보여주는 역할 - view이다. 데이터를 받아서 저장하는 동작이 거의 없기 때문에 분산 처리나 다중화에서 트랜잭션을 고민할 필요도 없다. 이런 서비스 특성을 고려해 네이버 서버 개발팀이 도출한 요구사항은 다음과 같다.

🔔 서비스 요구사항 🔔
❗어떤 서버로 접속해도 동일한 내용을 보여 주어야 하며, 특정 상탯값(사용자의 로그인 여부 등)에 의존하지 말아야 한다.
❗ 무슨 일이 있어도 사용자에게 서비스가 제공되어져야 한다.
      => 브라우저에 빈 페이지가 나타나선 안된다.
      => 메인 페이지에서 연동하는 외부 시스템은 늘 접속 불안정을 가정하고 빠른 실패 전략을 실행한다.
❗ 트래픽 증가에 탄력적으로 대처할 수 있어야 한다.
      => 트래픽이 폭주할 때 서버 증설만으로도 대응할 수 있어야 한다.
      => 각 컴포넌트(Web server, WAS)의 효율성을 극대화할 수 있어야 한다. 

이런 요구사항을 바탕으로 구축한 서비스 분산 처리 모델은 아래 그림과 같다.

네이버 메인 페이지의 분산 처리 모델(IDC 이중화와 서버, 네트워크 장비 등은 표현하지 않음)

지금부터 네이버 메인 페이지에서 사용한 분산 처리 기술을 하나하나 짚어가며 위 모델의 전반적인 구조를 훑어 볼 것이다.

 

네이버 메인 페이지의 분산 처리 기술

아래 서술한 기술들은 네이버 메인 페이지의 분산 처리에 활용된 기술들이다.

1. GCDN(Global CDN)
2. SSI(Server Side Includes)
3. Apache 커스텀 모듈
4. 마이크로 서비스(부분 도입)
    => 서킷 브레이커(circuit breaker)
    => 서비스 디스커버리(service discovery)

1. GCDN(Global CDN)

 콘텐츠 전송 네트워크(CDN)는 데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크이다. CDN은 콘텐츠 전송 네트워크 또는 콘텐츠 배포 네트워크를 의미할 수 있다. 사용자가 웹 사이트를 방문할 당시 해당 웹 사이트 서버의 데이터는 사용자의 컴퓨터에 도달하기 위해 인터넷을 통해 이동해야 한다. 사용자가 해당 서버에서 멀리 떨어져 있는 경우 동영상 같은 대용량 파일을 로드하는 데 시간이 오래 걸린다. 대신 웹 사이트 콘텐츠는 지리적으로 사용자와 가가운 CDN 서버에 저장되며 컴퓨터에 훨씬 빨리 도달하게 될 것이다. CDN을 사용한다면 페이지 로드 시간 단축, 대역폭 비용 저감, 콘텐츠 가용성 제고, 웹 사이트 보안 강화 등의 이점을 누릴 수 있다.

 

Global CDN은 전 세계 거점에 위치한 캐시 서버를 통해 사용자에게 빠르고 안전하게 콘텐츠를 전송하는 서비스이다. CSS나 Java Script, 이미지와 같이 공통으로 호출되는 리소스는 한 번 업로드되면 잘 변하지 않는다. 이런 리소스를 네이버 메인 페이지의 웹 서버에서 직접 제공하면 트래픽 부하가 엄청나게 가중된다. 100KB 용량의 이미지를 10만 명이 조회한다고 가정하면 단순 계산으로 10GB의 트래픽이 발생한다. 따라서 공통적으로 호출되는 리소스의 부하 분산을 위해 GCDN을 사용한다. 리소스를 GCDN으로 분산하면 네이버 메인 페이지의 트래픽을 상당히 절감할 수 있다. 또한, GCDN에서 지원하는 GSLB(Global Server LB) 기능은 접속한 IP 주소에서 가장 가까운 CDN 서버를 자동으로 선정해 연결하기 때문에 사용자가 빠른 서비스 속도를 체감할 수 있다.

 

2. SSI(Server sie Includes)

SSI는 웹 서버(Apache, NGINX 등)에서 지원하는 서버사이드 스크립트 언어이다. 서버에 있는 특정 파일을 읽어오거나 특정 쿠키 유무의 판별 등 간단한 기능을 실행할 수 있다. 이런 기능을 WAS에서만 실행할 수 있다고 생각하고 WAS에 요청을 보내는 경우가 많지만 SSI를 사용해 웹 서버에서 기능을 처리하면 WAS의 부담을 줄여 WAS의 성능에 여유를 줄 수 있게 되고, 웹 서버의 활용도도 높여 서버의 자원을 더 효율적으로 사용할 수 있다.

SSI 적용 예시

3. Apache 커스텀 모듈

네이버의 메인 페이지는 Apache HTTP 서버로 서비스된다. 다만 Apache HTTP 서버를 그대로 사용하지 않고 APR(Apache Portable Runtime) 기반의 커스텀 모듈로 기능을 확장해 사용하고 있다.

APR(Apache Portable Runtime)
APR은 프레임워크와 비슷하게 운영체제와 독립적으로 HTTP 기반 통신을 처리할 수 있도록 하는 라이브러리이다. 메모리 할당, 메모리 풀링, 파일 입출력, 멀티스레드 관련 처리 등에 필요하 기능이 포함되어 있다. Apache HTTP 서버도 APR 기반으로 작성되어 있다. APR에 관한 더 자세한 내용은 Apache Portable Runtime 프로젝트 사이트를 참고한다.

 커스텀 모듈을 사용하면 SSI를 사용할 때와 마찬가지로 WAS에서 처리할 기능을 웹 서버에서 처리할 수 있어 WAS의 부담을 줄일 수 있다. 또한 SSI에서는 불가능한 고급 기능을 사용할 수 있어 활용도가 높다. C 기반으로 구현되어 있기 때문에 실행 성능 또한 뛰어나다.

 

네이버에서 사용하는 대표적인 커스텀 기능은 다음과 같다.

• 간단한 외부 시스템 연동 : 단순한 API를 호출하거나 결과값을 그대로 사용할 수 있을 때에는 WAS를 거치지 않고 커스텀 모듈을 통해 외부 시스템을 호출한다.
• WAS 연동 시 AJP(Apache JServ Protocol), 리버스 프록시(reverse Proxy) 대신 커스텀 모듈을 사용한다. 이로써 모든 WAS가 다운되더라도 웹 서버만 정상이라면 서비스를 제공할 수 있게 커스텀 모듈을 사용해 WAS와 통신한다.
  • AJP나 HTTP를 사용해 WAS와 통신하면 WAS와 통신이 실패했을 때 오류로 처리된다.
  • 커스텀 모듈을 사용하면 WAS와 통신이 실패했을 때 동일한 IDC에 있는 다른 WAS와 통신을 시도한다.
  • 다른 WAS와 통신도 실패한다면 오류로 처리하는 대신 특정한 경로에 있는 파일을 읽어서 반환한다. 반환할 파일은 정적 파일을 배포하는 Data Publisher가 특정 시간 주기에 따라 웹 서버에 생성해 놓은 파일이다.

AJP(Apache JServ Protocol)
AJP는 웹서버(Apache)에서 받은 요청을 WAS로 전달해주는 프로토콜이다. 웹 WAS를 구축하는 개발자들은 AJP를 통해 웹서버로부터 오는 요청들을 로드밸런싱하는 역할로 이용한다.

리버스 프록시(reverse Proxy)
프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다. 이를 활용한 다면 보안성, 성능, 안정성을 크게 향상 시킬 수 있다. 프록시 서버는 두가지로 나뉘는데 우리가 흔히 말하는 프록시 서버인 포워드 프록시 서버와 로드 밸런싱에 사용되는 리버스 프록시 서버가 그것이다.

포워드 프록시 서버(주로 사내 방화벽이나 익명성 보장에 활용된다.)

리버스 프록시 서버(주로 로드 밸런싱과 보안에 활용된다.)