대용량 트래픽 처리 방법 - daeyonglyang teulaepig cheoli bangbeob

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

목차 Show

들어가기 앞서
1. 분산 처리
일반적인 분산 처리 모델
네이버의 분산 처리 모델
네이버의 분산 처리 기술
2. 모니터링 체계
성능 지표 수집과 모니터링
비상 대응 체계
요약정리(결론)

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

들어가기 앞서

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

서론

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

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

코리늬 2019. 3. 4. 10:41

최소한의 아키텍처 구성

API-Server 2개

실제 비즈니스 로직 처리

Load Balancer

Request를 연결된 서버들에게 나누어줌
장애 발생시 해당 LB에게 할당된 IP를 다른 LB에게 넘겨줌

DBMS 2개

primary(실제 서비스)
secondary(데이터 복사)
두대를 두고 primary의 데이터를 secondary로 계속 Replication을 통해 복제한다.
primary에서 장애 발생시 secondary가 primary로 되고, 장애가 해결되도 primary는 secondary 역할을 하게 된다.
마스터, 슬레이브

Object Storage Service (File-Server)

파일을 저장할 서버를 둘 경우 총 3개의 File-server가 필요하다.
3개를 사용할 시 Data Loss : 99.999%가 보장된다.
AWS S3, AZURE Blob, Gcp Google Storage에서 서비스를 제공한다.

하지만 데이터가 많아질 수록 DBMS의 TPS 한계가 온다.

TPS(Transaction Per Second)

초당 몇개의 명령을 처리할 수 있는가
ex) MAX 1000 TPS = 1초에 1000개의 명령을 처리
CPU, 메모리, 디스크 등 하드웨어 적인 부분이 속도에 영향을 미친다.
너무 많은 경우 오래걸리거나 장비가 고장날 수 있다.

대규모 서비스의 특성

Elastic
트래픽이나 상황에 따라서 서버의 추가/제거가 쉬워야 한다.

Resiliency
특정 장비의 장애 등은 자동으로 복구가 되어야 한다.

서버가 복구되는 건 아님
해당 장비의 장애로 인해 다른 쪽이 영향을 받으면 안됨

Scale UP
장비의 성능을 UP

Scale Out
장비의 수를 늘려 성능을 UP

SPOF (Single Point Of Failure)
장애 발생시 서비스 전체를 마비시키는 병목지점

API 서버에 부하가 물리는 작업은 ?
파일 IO가 많은 정적 파일

웹 스크래핑과 같은 디비 작업 자체보다 다른 작업이 많은 작업
독립적인 작입이 가능하지만, CPU나 다른 작업이 많이 필요한 작업 (ex lol, 배그 같은 게임서버)
이미지, 영상 인식, 전처리 작업

DB 서버에 부하가 물리는 작업은 ?
카톡방 대화, 페이스북 댓글, 대부분의 작업

Stateless - API 서버는 비즈니스 로직만 가짐
- 장점
  추가/삭제가 간단 - 주소만 추가/제거로 가능
- 단점
  결국 데이터의 저장이 필요해 뒤로 책임을 떠 넘기는 구조

DB의 경우 일반적인 서버의 부하
- 800 reads/s , 200 writes/s => Read > Write
- 읽기의 분배 - Query Off 필요 (Master, Slave 개념)
- Slave 장비를 추가해도 한계가 발생 => Database Partitioning

Database Partitioning
- Vervical Partitioning
- Horizontal Partioning
- Sarding Horizontal Partitioning

특정 key를 저장하는 방법, 특정 Key를 찾는 방법
- Consistent Hashing - 해쉬 값이 자기보다 크거나 같은 서버들 중 가장 가까운 서버로 KEY가 할당됨

Key만 보고 어떤 서버에서 찾아야 할지 알 수 있나 ?
- Unique 해야함

Key만 보고 시간 순을 알 수 있나 ?
- UUID (Universally Unique Identifier)
- 128 bit
- 36 characters
- ex) 123e4567-e89b-12d3-a456-426655440000

UUID의 단점
- 128 bit는 너무 용량이 큼, 그래서 보통 Shard Id가 들어간다.

shard
자신의 메일 리스트를 저장한 서버 번호
- Shard Id와 실제 서버의 매핑
- 시간 정보가 들어가면 ID 만으로 시간 정렬이 가능
- 변화하지 않을 특별한 정보를 넣으면 좋음
- {TimeStamp}-{ShardId}-{Type}-{seq}

ex) Twitter의 ID : timestamp + datacenter ID + worker ID + sequence

instagram의 ID : timestamp + logical shard ID + auto increment

데이터의 Scale Out
- Range - 특정 범위대역으로 나누기
- Modular - 서버 대수로 나누기 (서버가 추가될 때마다 데이터의 이동이 심해지는 단점)
- Indexed - 특정 데이터의 위치를 가리키는 서버가 존재

대용량 서비스 설계 방법
- SPOF 제거
- 오브젝트 스토어
- 데이터 샤딩
  - 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법을 의미
- 코디네이터
- Circuit Breaker
- 블루/그린 배포, 카나리 배포
- Feature Flag(Switch)

참고

https://12bme.tistory.com/100

https://www.slideshare.net/charsyam2/webservice-scaling-for-newbie