네이버 D2 - 대용량 트래픽 처리

네이버D2의 네이버 메인 페이지의 트래픽 처리 를 읽고 쓰는 글입니다.

중간에 나오는 이미지의 출처 역시 네이버 메인 페이지의 트래픽 처리임을 밝힙니다.

들어가기 앞서

• 대용량 트래픽 처리는 서버 개발자에게 필수적인 업무이며 상당히 중요한 부분으로 알려져 있습니다.
• 하지만 기업의 업무를 경험해보지 않고서는 (스스로 트래픽이 엄청 몰리는 웹사이트를 개발하고 관리해보는 경우를 제외하면) 이를 겪어볼 수 없습니다.
• 이러한 측면에서 이번 포스팅은 실무를 간접적으로 경험해보자는 테크블로그 포스팅의 취지에 가장 부합하는 주제가 아닐까라는 생각이 듭니다.

서론

기본적으로 많은 트래픽이 들어오고, 특별한 경우에는 더 많은 트래픽의 변동이 발생하는 네이버 메인 페이지에서는 분산처리와 모니터링 체계를 통해 서버의 안정화를 도모하고 있다고 합니다.

1. 분산 처리

일반적인 분산 처리 모델

• 위 사진은 Load Balancer를 통해 일반적인 3계층 분산 처리 모델입니다.
  • 만약 로드 밸런서에 문제가 생기면?
    • 로드 밸런서를 다중화해 문제를 처리할 수 있습니다.
      • 다중화는 쉽게 말해 예비장치를 구비해 두었다가 문제가 발생했을 때 예비장치로 갈아끼우는 작업을 말합니다.
  • 만약 WAS에 문제가 생기면?
    • 다중화로 문제를 해결하기가 쉽지 않습니다.
      • 서버가 다른 WAS를 찾도록 다시 설정해야 하며
      • 사용자가 로그인한 상태라면 이러한 정보들까지 새로운 WAS에 알려줘야 하기 때문입니다.
  • 만약 DB에 문제가 생기면?
    • 다중화로 문제를 해결하기가 쉽지 않습니다.
      • RDB라면 어떤 방식을 선택할지 신중한 결정이 필요합니다.
      • NoSQL이라면 데이터의 정합성, 동기화, 장애 복구 시 다수결에 의한 오염 가능성 등을 고려해야 하기 때문입니다.

기본적인 3계층 분산 처리 모델은 장애가 발생했을 때 문제를 해결하기가 어렵기 때문에 네이버는 네이버 메인 페이지의 특성에 맞는 분산 처리 모델을 구축했습니다.

네이버의 분산 처리 모델

네이버의 분산 처리 기술

GCDN(Global CDN)

• CDN은 Content Delivery Network(콘텐츠 전송 네트워크)의 약자로, 각 지역에 캐시 서버를 분산 배치해 사용자에게 웹 콘텐츠를 효율적으로 제공하는 기술입니다.
• CSS와 JS, 이미지는 한 번 업로드되면 잘 변하지 않는 리소스 입니다. 이들을 네이버 서버에서 직접 제공하는 게 아니라 사용자 주변의 가까운 CDN에서 받아가도록 함으로써 서버의 부하를 줄였습니다.

SSI(Server Side Includes)

• SSI는 웹 서버에서 지원하는 서버사이드 스크립트 언어입니다.
• 서버에 있는 특정 파일을 읽어오거나 특정 쿠키의 유무를 판별하는 등의 비교적 간단한 기능은 WAS가 아닌 SSI가 처리함으로써 WAS의 부담을 줄여줄 수 있습니다.

Apache 커스텀 모듈

• 네이버의 메인 페이지는 Apache HTTP를 APR기반의 커스텀 모듈로 확장한 서버로 서비스하고 있습니다.
  • APR은 운영체제에 독립적으로 HTTP기반 통신을 처리할 수 있는 라이브러리라고 합니다.
• APR기반의 커스텀 모듈은 SSI와 마찬가지로 WAS의 업무를 일부 담당해 WAS의 부담을 줄여줄 수 있습니다.

마이크로서비스의 부분 도입

• 다른 시스템과의 연관성이 적은 독립적인 기능을 별도의 서비스로 구축해 서버의 부담을 줄여주고 있습니다.
• 외부 시스템과 API 연동을 담당하는 부분은 Node.js를 사용했고 그 이유는 "Node.js를 사용하면 병렬 처리 시 스레드 문제 등을 고려할 필요가 없고, 비동기식으로 외부 시스템 연동 시 병렬로 여러 개의 요청을 한 번에 처리할 수 있기 때문에"라고 합니다.
• API 서버에는 또한 서킷 브레이커를 적용하고 있습니다.
  • 서킷 브레이커란 서버로의 요청을 관리하며 서버가 해당 요청을 처리하지 못하면 재빨리 나머지 요청을 종료하고 에러를 발생시키는 방법입니다.
  • 서킷 브레이커를 활용하면 외부 서비스의 장애로 인해 연쇄적으로 장애가 전파되는 걸 막을 수 있습니다.
• WAS에는 서버의 모니터링과 관리를 위해 서비스 디스커버리를 적용하고 있습니다.
  • 서비스 디스커버리는 MSA로 구성된 서비스에서 서로 다른 서버의 IP와 Port정보를 저장하고 관리하는 걸 얘기합니다.
  • 서비스 디스커버리가 없다면 서버1이 새롭게 추가된 서버2를 인지하지 못해(서버1이 실행되는 시점에 서버2가 없는 경우) 이를 활용하지 않는 비효율이 발생할 수 있습니다.

2. 모니터링 체계

• 시스템의 한계치를 명확히 인지하고 있는 건 서버관리 측면에서 굉장히 중요한 일입니다.
• 네이버는 Spring Boot Actuator로 성능 지표를 수집하고 있습니다.

성능 지표 수집과 모니터링

• 조금 더 구체적으로는 Grafana 기반의 데이터 시각화 지원 시스템인 NPOT이라는 사내 시스템을 활용하고 있습니다.
  • 이 NPOT의 성능지표를 Spring Boot Actuator의 MetricWriter로 수집하고 있습니다.

비상 대응 체계

• 네이버는 트래픽이 급증할 때 사람의 개입이 아니라 시스템이 이를 판단하고 조치하도록 설계했습니다.
• MEERCAT이라 불리는 이 사내 시스템은 다음의 두 가지 상황이 발생하면 자동으로 모든 외부 시스템과 연결을 끊고 자체 서비스로만 서비스를 제공하는 방어 동작을 실행합니다.
  • 실시간으로 트래픽을 수집하고 그 양상을 예측했을 때 다음 트래픽이 폭증할 것으로 예상되는 경우
  • 기상청의 지진 발생 신호 등 외부 신호가 수신되는 경우
  • 이러한 방어체계는 네이버 시스템의 보호뿐만 아니라 외부 시스템의 연쇄적 장애를 방지한다는 의미도 지니고 있습니다.

MEERCAT이 트래픽 이상을 감지하고 처리하는 과정

MEERCAT에 외부 신호가 수신됐을 때 방어 동작을 실행하는 과정

요약정리(결론)

• 1. 네이버는 Load Balancer를 활용한 일반적인 3계층 분산 처리 모델을 사용하고 있지 않다.
• 2. 네이버는 분산 처리 기술로 GCDN, SSI, Apache 커스텀 모듈, 서킷 브레이커, 서비스 디스커버리 기술을 사용하고 있다.
• 3. 서버관리를 위해 성능지표를 수집하고 꾸준히 모니터링 하고 있다.
• 4. 비상 대응 체계를 구축해 트래픽 폭증이 예상되면 외부 API와의 연결을 끊고 방어 동작을 실행한다.