티스토리 뷰
대규모 트래픽을 처리하기 위한 방법으로 고려해 볼 수 있는 물리적인 방법으로는
Scale Up과 Scale Out이 있다.
Scale Up은 고성능 CPU, 메모리 확장, SSD 등 서버의 스펙을 높이는 수직 확장 방식이고
Scale Out은 비슷한 스펙의 서버를 여러대로 증설하여 로드밸런싱을 통한 병렬처리가 가능한 수평 스케일업 아키텍처다.
하지만 나는 실무에서 이런 물리적인 방법만으로는 한계가 명확할 것이라고 생각했다.
그래서 실무에서는 어떻게 대규모 트래픽을 처리하였는 지 찾아보기로 했고 네이버와 쿠팡의 경우를 확인할 수 있었다.
※ 혼자 공부를 하기 위해 정리한 글이며 참고 자료에 있는 글들을 인용했습니다.
네이버의 경우
네이버의 메인 페이지의 트래픽은 평소에도 많은 편이지만
사회적으로 주목 받는 일이 생길 때 더욱 트래픽이 발생한다고 한다.
예를 들면 2017년 포항에서의 지진 발생, 2018 러시아 월드컵에서의 손흥민 득점과 같은 일이 생겼을 때의 경우이다.
따라서 로드 밸런서를 사용하는 일반적인 3 계층 분산 처리 모델보다는
네이버 메인 페이지의 서비스 특성과 요구 사항에 맞는 분산 처리 모델을 구축해 적용했다고 한다.
Load balance?
사용자에게 콘텐츠 전송 요청을 받았을 때 최적의 네트워크 환경을 찾아 연결하는 기술이다.
물리적으로 가장 가깝거나 여유 트래픽이 남아 있는 곳으로 접속을 유도한다.
네이버 메인 페이지의 분산 처리 모델
네이버는 서비스 특성 상 메인 페이지가 실행하는 역할의 대부분이 데이터를 사용자에게 보여주는 역할이다.
데이터를 받아서 저장하는 동작의 거의 없어 분산 처리나 다중화에서 트랜잭션을 고려할 필요도 거의 없다고 한다.
이러한 특성을 고려하여 도출한 요구 사항이다.
● 어떤 서버로 접속해도 동일한 내용을 보여 줘야 하며 특정 상탯값(사용자의 로그인 여부 등)에 의존하지 말아야 한다.
● 브라우저에 빈 페이지가 나타나지 않아야 하며, 메인 페이지에서 연동하는 외부 시스템은 언제든 접속이 불안해질 가능성이 있다고 가정하고 빠른 실패 전략을 실행해야 한다.
● 트래픽이 폭주할 때 서버 증설만으로도 대응할 수 있어야 하고 각 컴포넌트(웹 서버, WAS)의 효율성을 극대화할 수 있어야 한다.
분산 처리 기술
GCDN
이미지와 같이 공통으로 호출되는 리소스(css, javaScript)는 한 번 업로드되면 잘 변하지 않는다.
이런 리소스를 네이버 메인 페이지의 웹 서버에서 직접 제공하면 트래픽 부하가 엄청나게 가중된다.
(100KB 용량의 이미지 10만 명이 조회 → 대략 10GB의 트래픽이 발생)
따라서 공통적으로 호출되는 리소스의 부하 분산을 위해 GCDN을 사용하면 트래픽을 상당히 절감시킬 수 있다고 한다.
+ GCDN에서 지원하는 GSLB(Global Server LB)기능은 접속한 IP 주소에서 가장 가까운 CDN 서버를 자동으로 선정해
연결하기 때문에 사용자가 빠른 서비스 속도를 체감할 수 있다.
CDN이란 지리, 물리적으로 떨어져 있는 사용자에게 컨텐츠를 더 빠르게 제공하기 위해,
느린 응답속도와 다운로딩 타임을 극복하기 위한 기술이다.
CDN을 사용하지 않는 경우 콘텐츠를 담고 있는 서버는 모든 사용자의 요청에 일일이 응답해야 하게 되므로
막대한 트래픽에 대응해야 하는데,
CDN을 사용하면 CDN캐싱장비를 통해 서버의 트래픽 부하 및 비용을 줄일 수 있게 된다.
SSI
웹 서버(Apache, NGINX 등)에서 지원하는 서버사이드 스크립트 언어다.
서버에 있는 특정 파일을 읽어오거나 특정 쿠키 유무의 판별 등 간단한 기능을 실행할 수 있다.
SSI를 이용해 웹 서버에서 기능을 처리하면서 WAS의 부담을 줄여 WAS의 성능에 여유를 줄 수 있고
웹 서버의 활용도도 높여 서버의 자원을 효율적으로 사용할 수 있다고 한다.
WAS?
JSP, ASP, PHP등 사용자의 입력을 받아 서버에서 무언가를 처리하고
그 결과를 보여주는 동적인 데이터를 처리하는 웹 서버.
Apache 커스텀 모듈
네이버 메인 페이지는 Apache HTTP 서버로 서비스되지만, 그대로 사용하는 것이 아닌
APR(Apache Portable Runtime) 기반의 커스텀 모듈로 기능을 확장해 사용한다.
APR?
프레임워크와 비슷하게 운영체제에 독립적으로 HTTP기반 통신을 처리할 수 있도록 하는 라이브러리다.
메모리 할당, 메모리 풀링, 파일 입출력, 멀티스레드 관련 처리 등에 필요한 기능이 포함되어 있다.
커스텀 모듈을 사용함으로써 SSI 마찬가지로 WAS에서 처리할 기능을
웹 서버에서 처리할 수 있어 WAS의 부담을 줄일 수 있으며
SSI에서는 불가능한 고급 기능을 사용할 수 있어 활용도가 높고, C 언어 기반이라 실행 성능도 좋다고 한다.
대표 기능
● 간단한 외부 시스템 연동 - 단순히 API를 호출하거나 결괏값을 그대로 사용할 수 있을 때에는 WAS를 거치지 않고 커스텀 모듈을 통해 외부 시스템을 호출한다.
● WAS 연동 시 AJP(Apache JServ Protocol), 리버스 프락시(reverse proxy) 대신 커스텀 모듈을 사용하여
모든 WAS가 작동을 하지 않더라도 웹 서버만 정상이라면 서비스를 제공할 수 있도록 한다.
→ AJP나 HTTP를 사용해 WAS와 통신하면 WAS와 통신이 실패했을 때 오류로 처리되지만,
커스텀 모듈을 사용하면 WAS와 통신이 실패했을 때 동일한 IDC에 있는 다른 WAS와 통신을 시도한다.
다른 WAS와의 통신도 실패한다면 오류로 처리하는 대신 특정한 경로에 있는 파일을 읽어서 반환한다.
반환할 파일은 정적 파일을 배포하는 Data Publisher가 특정 시간 주기에 따라 웹 서버에 생성해 놓은 파일이라고 한다.
마이크로서비스의 부분 도입
네이버 메인 페이지의 경우 다른 시스템과 연관성이 적은 독립적인 기능을 별도 서비스로 분리해 구축했다.
외부 시스템과 API연동을 담당하는 부분은 특히 Node.js로 구축했다고 한다.
네이버 메인 페이지의 경우 동시에 여러 대의 외부 시스템과 API 연동을 실행해야 하는 경우가 많다 보니
기존에 사용하던 Java 보다 Node.js를 사용하면서 병렬 처리 시 스레드 문제 등을 고려할 필요가 없게 하고,
비동기식으로 외부 시스템 연동 시 병렬로 여러 개의 요청을 한 번에 처리할 수 있도록 하였다.
또한 부서 내 언어적 다양성을 확보해 용도에 맞는 적절한 기술을 사용할 수 있고, 부서원의 기술 역량 향상에 도움을 주는 장점도 있다고 한다.
마이크로서비스(MSA)?
작고 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크이다.
https://www.youtube.com/watch?v=ZRpsB3ODr6M 해당 링크에서 한 번에 개념을 파악할 수 있다.
서킷 브레이커
외부 서비스의 장애로 인한 연쇄적 장애를 막기 위해 자동으로 외부 서비스와 연결을 차단 및 복구하는 역할을 한다.
분산 환경에서는 네트워크 일시 단절 또는 트래픽 폭증으로 인한 간헐적 시간 초과 등의 상황이 종종 발생하는데,
이로 인해서
1. 트래픽 폭증으로 인해 API 서버 등 외부 서비스의 응답이 느려짐
2. 외부 서비스의 응답이 타임아웃 시간을 초과하면 데이터를 받아오기 위해 외부 서비스를 다시 호출하게 된다.
3. 이전에 들어온 트래픽을 다 처리하지 못한 상태에서 재시도 트래픽이 추가로 적제 되어 외부 서비스에 장애가 발생
4. 외부 서비스의 장애로 인해 데이터를 수신하지 못한 메인 서비스에서도 장애가 발생
와 같은 연쇄적인 장애가 발생할 수 있다.
이럴 때 외부 서비스에서 데이터를 받아오는 것을 포기하고 미리 준비된 응답을 사용자에게 전달하는 것이 시스템 안정성 및 사용 편의성 측면에서 옳다고 판단,
이러한 이유로 서킷 브레이커를 사용하게 되었다고 한다.
서킷은 세 가지 상태를 갖는다. - 회로이므로 닫힌 것이 정상이다.
closed = 메서드가 정상적으로 작동해 서킷이 닫힌 상태
open = 메서드에 문제가 생겨 서킷이 열린 상태
Half-Open = Open상태와 Closed상태의 중간, 메서드를 주기적으로 확인해 정상이라고 판단되면 Closed로 상태를 전환하고, 정상이 아니라면 Open상태를 유지한다.
오류가 발생하기 시작해서 일정 횟수에 도달하면 서킷은 Open상태로 전환된다.
이때에는 메서드를 호출해도 서킷 브레이커가 개입해 미리 지정된 응답(단순 실패, 특정한 값 등)을 반환한다.
특정 주기 동안 Open상태로 유지하다가 서킷 자체적으로 메서드가 정상적으로 작동되는지 확인하는데,
이 상태가 Half-Open상태이며, 메서드를 몇 번 호출하여 정상 응답이 돌아온다면 서킷은 다시 Closed상태로
그렇지 않다면 Open상태를 유지한다.
기존에는 이런 로직을 구현하기 위해 개발자가 수많은 if-else구문을 작성해야 했지만,
Netflix OSS의 서킷 브레이커 라이브러리 Netflix OSS Hystrix가 등장하여 적극적으로 해당 기능을 사용하고 있다고 한다.
Netflix OSS를 Spring Cloud 프로젝트에서 사용할 수 있도록 래핑 한 Spring Cloud Netflix를 활용하면 Spring 개발자는
애플리케이션에 서킷 브레이커를 쉽게 사용할 수 있으며, 네이버 메인 개발팀은 Node.js에서 서킷 브레이커를 사용해야
했으므로 Hystrix.JS를 사용했다고 한다.
네이버 메인 페이지에서 서킷 브레이커를 활용하는 방법
1. 정적 파일을 배포하는 Data Publisher를 통해 사전에 정상 응답 결괏값을 주기적으로 저장한다.
2. 외부 시스템에 이상이 있다고 판단(Open), 서킷 브레이커가 개입해 바로 연결 시도를 포기하고 미리 준비해 둔
정상 응답 결과값을 사용해 HTML화면으로 렌더링 한다.
3. 이후 계속 상태를 지켜보다(Half-Open) 외부 시스템이 정상으로 돌아오면 서킷 브레이커가 다시 연결을 시도한다.
서비스 디스커버리
동적으로 생성, 삭제되는 서버 인스턴스에 대한 IP주소와 포트를 자동으로 찾아 설정할 수 있게 해주는 기능이다.
서비스 디스커버리를 사용하지 않는다면, 서버 목록을 갱신하기 위해서 서버군에 있는 서버를 다시 실행해야 한다.
롤링 리스타트를 한다고 해도 서비스를 운영하는 도중에 서버를 다시 실행하는 것은 매우 위험할 수 있다.
하지만 서비스 디스커버리를 사용하게 되면,
서버는 시작할 때 자신의 정보(IP, 포트)를 서비스 디스커버리 서버로 보내고, 서비스 디스커버리 서버는 이 정보를 받아
서버군의 서버 목록을 최신으로 갱신한다.
각 서버군에 있는 서버는 주기적으로 서비스 디스커버리 서버로 목록을 요청해 서버 목록을 최신화할 수 있게 된다.
따라서 서버는 재시작 등 외부 개입 없이 자동으로 항상 최신 서버 목록을 확보할 수 있다.
서비스 디스커버리는 클라우드 환경에서 빛을 발한다고 한다.
기존 온프레미스(on-premises) 환경에서는 서버를 추가, 삭제하는 일이 많지 않았는데,
클라우드 환경(특히 오토스케일링 등의 기능을 사용한다면 더욱)에서는 수시로 서버가 추가, 삭제되므로
이를 사람이 확인하여 서버를 다시 실행하는 것은 불가능에 가깝다.
서비스 디스커버리는 이런 상황에서 유용하게 사용할 수 있다고 한다.
모니터링 체계
네이버 메인 개발팀은 Spirng Boot Actuator로 성능 지표를 수집해 지속적으로 네이버 메인 페이지의 서비스 상태를 모니터링한다.
NPOT을 이용하는데, 이는 네이버의 사내 시스템으로 Grafana 기반의 데이터 시각화 지원 시스템이다.
성능 지표는 Spring Boot Actuator의 MetircWriter를 활용해 수집하고,
수집된 성능 지표는 로그 파일 형태로 저장되고, 로그 파일을 읽어 NPOT에 전송해 성능 지표를
시각화하는 것이라고 한다.
비상 대응 체계
갑작스러운 트래픽 증가가 종종 나타날 때마다 사람이 개입하여 조치해야 한다면,
개발자의 24시간 당번이 필요하게 될 것이다.
그것은 물리적으로 어려운 일이므로 네이버 메인 개발팀은 MEERCAT이라는 애플리케이션을 개발하여
애플리케이션 스스로가 트래픽을 예측해 갑작스러운 트래픽 증가를 방어하게 했다고 한다.
두 가지 상황
1. 실시간으로 트래픽을 수집하고 그 양상을 예측한 다음 트래픽 폭증이 예측되는 경우
2. 기상청의 지진 발생 신호 등 외부 신호가 수신되는 경우
발생 시 자동으로 모든 외부 시스템과 연결을 끊고 자체 서버로만 서비스를 제공하는 방어 동작을 실행한다.
방어 동작은 네이버 메인페이지의 순간 성능 및 가용량을 향상하고 외부 시스템을 보호한다.
(메인 페이지에 들어오는 트래픽이 아무런 제한 없이 외부시스템으로 흘러간다면 외부시스템 또한 연쇄적 장애)
MEERCAT이 트래픽 이상을 감지해 처리하는 과정을 나타낸 흐름도이다.
실제로 방어 동작이 실행된 예이다.
MEERCAT이 자동으로 외부 시스템과 연결을 끊을 때의 트래픽을 나타내는 그래프다.
빨간 네모가 지정되어 있는 곳의 그래프를 보면 트래픽이 급증하다 MEERCAT의 자동 방어로 연결이 끊어지고,
이후 다시 안정화가 된 모습을 볼 수 있다.
참고자료
초보 개발자가 대규모트래픽에 대응하는 과정
네이버 메인 페이지의 트래픽 처리
https://d2.naver.com/helloworld/6070967
'CS' 카테고리의 다른 글
| 대규모 트래픽 처리 (2) (0) | 2023.03.07 |
|---|---|
| index, B tree, B+ tree (0) | 2023.02.15 |
| CPU-프로세스와 스레드 (0) | 2023.02.07 |