로드 밸런서를 사용하는 일반적인 3계층(3-Tier) 분산 처리 모델은 구성 요소에 문제가 생겼을 때 문제를 해결하기에 어려움이 있다. 그래서 네이버 메인 페이지의 서비스 특성과 요구 사항에 맞는 분산 처리 모델을 구축해 적용하고 있다.
일반적인 분산 처리 모델
다음은 로드 밸런서로 구성한 일반적인 3계층(3-Tier) 분산 처리 모델을 표현한 도식이다.
클라이언트의 트래픽이 로드 밸런서를 통해 각 웹 서버로 분산된다. WAS는 동일한 데이터베이스를 참조한다.
이런 분산 처리 환경에서 각 구성 요소에 문제가 생긴다면 어떻게 처리해야 할까?
LB에 문제 발생시
로드 밸런서에 문제가 생기면 로드 밸런서를 다중화한 다음 DNS 라운드로빈 방식 등을 적용해 문제를 처리할 수 있다.
WAS에 문제 발생시
하지만 WAS에 문제가 생기면 다음과 같은 점을 고려해야 하기 때문에 다중화로 문제를 해결하기가 쉽지 않다.
•
WAS에 문제가 생겼을 때 웹 서버가 다른 WAS를 찾도록 해야 한다.
•
사용자가 로그인한 상태라면 WAS에 세션 클러스터링을 설정해야 한다.
•
세션 클러스터링 설정을 위한 추가 작업이 필요하고 관리 지점이 증가한다.
DB에 문제 발생시
데이터베이스에서는 다음과 같은 점을 고려해야 하기 때문에 역시 다중화로 문제를 해결하기가 쉽지 않다.
•
데이터 동기화 등의 문제 때문에 데이터 스토리지 레이어는 다중화가 특히 어려운 부분에 속한다.
•
사용하는 데이터베이스가 RDB라면 다중화를 어떻게 할 것인지, 데이터를 어떻게 분산할 것인지에 관해 깊이 고민해야 한다. 예를 들어 샤딩 등을 도입했을 때 데이터가 늘어나 샤드를 추가해야 한다면 기존 데이터의 마이그레이션은 어떻게 할지 고민해야 한다.
•
사용하는 데이터베이스가 NoSQL이라면 데이터 정합성, 동기화, 장애 복구 시 다수결에 의한 데이터 오염 가능성 등을 고려해야 한다.
네이버 메인 페이지의 분산 처리 모델
서비스 특성상 네이버 메인 페이지가 실행하는 역할의 대부분이 데이터를 사용자에게 보여 주는 역할(View)이다. 데이터를 받아서 저장하는 동작이 거의 없기 때문에 분산 처리나 다중화에서 트랜잭션을 고려할 필요도 거의 없다.
이러한 서비스 특성을 고려해 도출한 요구 사항은 다음과 같다.
•
어떤 서버로 접속해도 동일한 내용을 보여 주어야 하며, 특정 상탯값(사용자의 로그인 여부 등)에 의존하지 말아야 한다.
•
무슨 일이 있더라도 사용자에게 서비스가 제공되어야 한다.
◦
브라우저에 빈 페이지가 나타나지 않아야 한다.
◦
네이버 메인 페이지에서 연동하는 외부 시스템은 언제든 접속이 불안해질 가능성이 있다고 가정하고 빠른 실패 전략을 실행해야 한다.
•
트래픽 증가에 탄력적으로 대처할 수 있어야 한다.
◦
트래픽이 폭주할 때 서버 증설만으로도 대응할 수 있어야 한다.
◦
각 컴포넌트(웹 서버, WAS)의 효율성을 극대화할 수 있어야 한다.
네이버 메인 페이지의 서비스 특성과 요구 사항을 반영한 네이버 메인 페이지의 분산 처리 모델을 간략하게 표현하면 다음과 같다(IDC 이중화와 서버, 네트워크 장비 등은 표현하지 않았음).
네이버 메인 페이지의 분산 처리 기술
네이버 메인 페이지의 분산 처리에는 다음과 같은 기술이 사용된다.
•
GCDN(Global CDN)
•
SSI(Server Side Includes)
•
Apache 커스텀 모듈
•
마이크로서비스(부분 도입)
◦
서킷 브레이커(circuit breaker)
◦
서비스 디스커버리(service discovery)
GCDN
CSS와 JavaScript, 이미지와 같이 공통으로 호출되는 리소스는 한 번 업로드되면 잘 변하지 않는다. 이런 리소스를 네이버 메인 페이지의 웹 서버에서 직접 제공하면 트래픽 부하가 엄청나게 가중된다. 예를 들어 100KB 용량의 이미지를 10만 명이 조회하면 대략 10GB의 트래픽이 발생한다. 그래서 공통적으로 호출되는 리소스의 부하 분산을 위해 GCDN을 사용한다. 리소스를 GCDN으로 분산하면 네이버 메인 페이지의 트래픽을 상당히 절감할 수 있다.
또한, GCDN에서 지원하는 GSLB(Global Server LB) 기능은 접속한 IP 주소에서 가장 가까운 CDN 서버를 자동으로 선정해 연결하기 때문에 사용자가 빠른 서비스 속도를 체감할 수 있다.
SSI
SSI는 웹 서버(Apache, NGINX 등)에서 지원하는 서버사이드 스크립트 언어다. 서버에 있는 특정 파일을 읽어오거나 특정 쿠키 유무의 판별 등 간단한 기능을 실행할 수 있다. 이런 기능을 WAS에서만 실행할 수 있다고 생각하고 WAS에 요청을 보내는 경우가 많다. 하지만 SSI를 사용해 웹 서버에서 기능을 처리하면 WAS의 부담을 줄여 WAS의 성능에 여유를 줄 수 있게 되고, 웹 서버의 활용도도 높여 서버의 자원을 더 효율적으로 사용할 수 있다.
•
SSI 적용 예시
Apache 커스텀 모듈
네이버 메인 페이지는 Apache HTTP 서버로 서비스된다. 다만 Apache HTTP 서버를 그대로 사용하지 않고 APR(Apache Portable Runtime) 기반의 커스텀 모듈로 기능을 확장해 사용하고 있다.
APR(Apache Portable Runtime)
•
APR은 프레임워크와 비슷하게 운영체제에 독립적으로 HTTP 기반 통신을 처리할 수 있도록 하는 라이브러리다. 메모리 할당, 메모리 풀링, 파일 입출력, 멀티스레드 관련 처리 등에 필요한 기능이 포함되어 있다. Apache HTTP 서버도 APR 기반으로 작성되어 있다.
커스텀 모듈을 사용하면 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가 특정 시간 주기에 따라 웹 서버에 생성해 놓은 파일이다.
마이크로서비스의 부분 도입
네이버 메인 페이지에서는 다른 시스템과 연관성이 적은 독립적인 기능을 별도 서비스로 분리해 구축했다.
외부 시스템과 API 연동을 담당하는 부분은 특히 Node.js로 구축했다. 네이버 메인 페이지에서는 동시에 여러 대의 외부 시스템과 API 연동을 실행해야 하는 경우가 많다. Node.js를 사용하면 병렬 처리 시 스레드 문제 등을 고려할 필요가 없고, 비동기식으로 외부 시스템 연동 시 병렬로 여러 개의 요청을 한 번에 처리할 수 있다. 그래서 이러한 기능을 구현하기에는 기존에 사용하던 Java보다는 Node.js로 구현하는 것이 더 유리하다고 판단했다. 또한 부서 내 언어적 다양성을 확보해 용도에 맞는 적절한 기술을 사용할 수 있고, 부서원의 기술 역량 향상에 도움을 주는 장점도 있다.
API 서버에는 또한 서킷 브레이커를 적용했다. WAS에는 서버의 모니터링과 관리를 위해 서비스 디스커버리를 적용했다.
서킷 브레이커
서킷 브레이커는 외부 서비스의 장애로 인한 연쇄적 장애 전파를 막기 위해 자동으로 외부 서비스와 연결을 차단 및 복구하는 역할을 한다. 서킷 브레이커를 사용하는 목적은 애플리케이션의 안정성과 장애 저항력을 높이는 데 있다. 분산 환경에서는 네트워크 일시 단절 또는 트래픽 폭증으로 인한 간헐적 시간 초과 등의 상황이 종종 발생한다. 이로 인해 다음과 같은 연쇄 장애가 발생할 가능성이 있다.
1.
트래픽 폭증으로 인해 API 서버 등 외부 서비스의 응답이 느려진다.
2.
외부 서비스의 응답이 타임아웃 시간을 초과하면 데이터를 받아오기 위해 외부 서비스를 다시 호출한다.
3.
이전에 들어온 트래픽을 다 처리하지 못한 상태에서 재시도 트래픽이 추가로 적체되어 외부 서비스에 장애가 발생한다.
4.
외부 서비스의 장애로 인하여 데이터를 수신하지 못해 네이버 메인 서비스에도 장애가 발생한다.
일시적인 경우라면 2, 3회 재시도로 정상 데이터를 수신할 수 있다. 하지만 장애 상황이라면 계속 재시도하는 것이 의미도 없을 뿐 아니라 외부 서비스의 장애 복구에 악영향을 미칠 수 있다. 이럴 때는 외부 서비스에서 데이터를 받아오는 것을 포기하고 미리 준비된 응답을 사용자에게 전달하는 것이 시스템 안정성 및 사용 편의성 측면에서 옳다고 할 수 있다.
•
서킷 브레이커에서 서킷의 상태 변화 그림
서킷은 다음과 같은 세 가지 상태를 가진다(회로이므로 닫힌 것이 정상, 열린 것이 비정상).
•
Closed 상태: 메서드가 정상적으로 작동해 서킷이 닫힌 상태
•
Open 상태: 메서드에 문제가 생겨서 서킷이 열린 상태
•
Half-Open 상태: Open 상태와 Closed 상태의 중간 상태. 메서드를 주기적으로 확인해 정상이라고 판단되면 Closed 상태로 상태를 전환하고, 정상이 아니라면 Open 상태를 유지한다.
서킷이 Closed 상태에서 잘 작동하고 있다가 오류가 발생하기 시작해서 일정 횟수에 도달하면 일단 서킷을 Open 상태로 전환한다. 이때에는 메서드를 호출해도 실제로 메서드가 실행되는 대신 서킷 브레이커가 개입해 미리 지정된 응답(단순 실패를 반환할 수도 있고 특정한 값을 반환할 수도 있음)을 반환한다.
특정 주기 동안 Open 상태로 유지하고 있다가 서킷이 자체적으로 메서드가 정상으로 작동하는지 확인하는데, 이 상태가 Half-Open 상태다. Half-Open 상태에서 메서드를 몇 번 호출해서 정상 응답이 돌아온다면 서킷은 다시 Closed 상태로 전환되어 요청을 처리한다. 몇 번 호출했는데 계속 실패가 반환된다면 서킷은 Open 상태로 유지된다.
기존에는 이런 로직을 구현하기 위해 개발자가 수많은 if-else 구문을 작성해야 했다. 하지만 Netflix OSS의 서킷 브레이커 라이브러리인 Netflix OSS Hystrix가 등장한 이후 많은 개발자가 Netflix OSS Hystrix를 적극적으로 사용하고 있다. 또한 Netflix OSS를 Spring Cloud 프로젝트에서 사용할 수 있도록 래핑한 Spring Cloud Netflix를 활용하면 Spring 개발자는 자신의 애플리케이션에서 서킷 브레이커를 손쉽게 활용할 수 있다. 네이버 메인 개발팀은 Node.js에서 서킷 브레이커를 사용해야 해서 HystrixJS를 사용했다.
네이버 메인 페이지에서는 서킷 브레이커를 다음과 같이 활용한다.
•
정적 파일을 배포하는 Data Publisher를 통해 사전에 정상 응답 결괏값을 주기적으로 저장해 둔다.
•
외부 시스템에 이상이 있다고 판단되면(Open 상태) 서킷 브레이커가 개입해 바로 연결 시도를 포기하고 미리 준비해 둔 정상 응답 결괏값을 사용해 HTML 화면을 렌더링한다.
•
이후 계속 상태를 지켜보다(Half-Open 상태) 외부 시스템이 정상으로 돌아오면 서킷 브레이커가 다시 연결을 시도한다.
서비스 디스커버리
서비스 디스커버리는 동적으로 생성, 삭제되는 서버 인스턴스에 대한 IP 주소와 포트를 자동으로 찾아 설정할 수 있게 하는 기능이다.
다음은 서비스 디스커버리를 사용하지 않는 서버군의 환경을 나타낸 그림이다. 서버군 1과 서버군 2가 서로 다른 기능을 실행하는 서버군이라고 가정한다.
•
서비스 디스커버리를 사용하지 않는 환경
서버군 2에서 10.0.0.5 서버가 신규로 생성됐지만, 서버군 1에서는 10.0.0.5 서버로 연결을 맺을 수 없다. 서버군 1이 최초에 실행됐을 때에는 10.0.0.5 서버가 없었기 때문에 서버 목록에 10.0.0.5 서버가 없기 때문이다. 서버 목록을 갱신하려면 서버군 1에 있는 서버를 다시 실행해야 한다. 하지만 롤링 리스타트를 한다고 해도 서비스를 운영하는 도중에 서버를 다시 실행하는 것은 매우 위험하다.
•
다음은 서비스 디스커버리를 도입한 환경을 나타내는 그림이다.
서비스 디스커버리 서버는 각 서버군의 서버 목록을 관리한다. 서버는 시작할 때 자신의 정보(IP 주소, 포트)를 서비스 디스커버리 서버로 보내고, 서비스 디스커버리 서버는 이 정보를 받아 서버군의 서버 목록을 최신으로 갱신한다. 각 서버군에 있는 서버는 주기적으로 서비스 디스커버리 서버로 목록을 요청해 서버 목록을 최신으로 유지한다. 이러한 방법으로 서버는 재시작 등 외부의 개입이 없어도 자동으로 항상 최신 서버 목록을 확보할 수 있다.
예를 들어 10.0.0.5 서버가 추가되면 서버군 2의 서버 목록이 갱신되고 이 목록을 받아서 서버군 1의 서버가 자신의 서버 목록을 갱신하면 외부의 개입 없이 10.0.0.5 서버에 연결할 수 있게 된다.
서비스 디스커버리는 특히 클라우드 환경에서 빛을 발한다. 기존 온프레미스(on-premises) 환경에서는 서버를 추가, 삭제하는 일이 많지 않았다. 서버를 추가, 삭제하는 경우에도 통제된 환경에서 주로 작업하므로 갱신 문제가 크지 않다. 하지만 클라우드 환경에서는 수시로 서버가 추가, 삭제된다(특히 오토스케일링 등의 기능을 사용한다면 더욱 더). 이를 사람이 일일이 확인해 서버를 다시 실행하는 것은 불가능에 가깝다. 서비스 디스커버리는 이런 상황에서 아주 유용하게 사용할 수 있는 기술이다.
네이버 메인 페이지의 모니터링 체계
플랫폼 구축 후에는 모니터링과 유지 보수 등 끊임없는 보살핌이 필요하다. 아무런 보살핌이 없다면 시스템에 이상이 없더라도 외부 시스템의 변경 등 외부 환경의 영향으로 문제가 생길 수 있다.
시스템의 한계치를 명확히 설정하고 이를 기준으로 지속적으로 모니터링하는 일도 필요하다. 한계치를 명확히 설정하지 않으면 트래픽 급증과 같은 상황이 일어났을 때 대처를 제대로 못해 장애를 맞이할 수가 있다.
네이버 메인 개발팀은 Spring Boot Actuator로 성능 지표를 수집해 지속적으로 네이버 메인 페이지의 서비스 상태를 모니터링한다. 또한 갑작스러운 트래픽 증가 등에도 서비스가 중단되지 않도록 비상 대응 체제를 구축해 놓았다.
성능 지표 수집과 모니터링
네이버 메인 개발팀은 성능 지표를 수집해 시각화해서 보여 주는 NPOT으로 네이버 메인 페이지의 상태를 모니터링한다. NPOT은 네이버의 사내 시스템으로 Grafana 기반의 데이터 시각화 지원 시스템이다.
NPOT을 위한 성능 지표는 Spring Boot 기반의 애플리케이션인 Spring Boot Actuator의 MetricWriter를 활용해 수집한다.
•
성능 지표 수집 워크플로우
비상 대응 체계
네이버 메인 페이지에는 갑작스러운 트래픽 증가가 종종 나타난다. 그때마다 사람이 개입해서 조치해야 한다면 네이버 메인 페이지 개발자가 24시간 당번을 서야 할 것이다. 하지만 이는 물리적으로도 어려운 일이다. 네이버 메인 개발팀은 MEERCAT이라는 애플리케이션을 개발해서 애플리케이션이 스스로 트래픽을 예측해 갑작스러운 트래픽 증가를 방어하게 했다.
MEERCAT은 다음과 같은 두 가지 상황이 발생하면 자동으로 모든 외부 시스템과 연결을 끊고 자체 서버로만 서비스를 제공하는 방어 동작을 실행한다.
•
실시간으로 트래픽을 수집하고 그 양상을 예측한 다음 트래픽 폭증이 예측되는 경우
•
기상청의 지진 발생 신호 등 외부 신호가 수신되는 경우
방어 동작은 네이버 메인 페이지의 순간 성능 및 가용량을 향상시킴과 더불어 외부 시스템을 보호한다는 의미를 가진다. 만약 네이버 메인 페이지에 들어오는 트래픽이 아무런 제한 없이 외부 시스템으로 모두 흘러간다면 외부 시스템의 연쇄적 장애로 이어질 수도 있기 때문이다.
다음은 MEERCAT이 트래픽 이상을 감지해 처리하는 과정을 나타낸 흐름도다. 평소에는 이동평균을 이용해 트래픽을 실시간으로 모니터링한다. 만약 일정 시간 이후에 트래픽 한계치에 도달할 것으로 예측될 때는 방어 동작을 실행한다.
글을 읽고
나의 기존 지식과의 연결
Kubernetes에서의 서비스 디스커버리 (Headless Service)
서비스는 접근을 위해서 Cluster IP 또는 External IP 를 지정받는다.
즉 서비스를 통해서 제공되는 기능들에 대한 엔드포인트를 쿠버네티스 서비스를 통해서 통제하는 개념인데, 마이크로 서비스 아키텍쳐에서는 기능 컴포넌트에 대한 엔드포인트 (IP 주소)를 찾는 기능을 서비스 디스커버리 (Service Discovery) 라고 하고, 서비스의 위치를 등록해놓는 서비스 디스커버리 솔루션을 제공한다. Etcd 나 hashcorp의 consul (https://www.consul.io/)과 같은 솔루션이 대표적인 사례인데, 이 경우 쿠버네티스 서비스를 통해서 마이크로 서비스 컴포넌트를 관리하는 것이 아니라, 서비스 디스커버리 솔루션을 이용하기 때문에, 서비스에 대한 IP 주소가 필요없다.
이런 시나리오를 지원하기 위한 쿠버네티스의 서비스를 헤드리스 서비스 (Headless service) 라고 하는데, 이러한 헤드리스 서비스는 Cluster IP등의 주소를 가지지 않는다. 단 DNS이름을 가지게 되는데, 이 DNS 이름을 lookup 해보면, 서비스 (로드밸런서)의 IP 를 리턴하지 않고, 이 서비스에 연결된 Pod 들의 IP 주소들을 리턴하게 된다.
위와 같이 ClusterIP가 할당되지 않음을 확인할 수 있다.
다음 쿠버네티스 클러스터내의 다른 Pod에서 nslookup으로 해당 서비스의 dns 이름을 조회해보면 다음과 같이 서비스에 의해 제공되는 pod 들의 IP 주소 목록이 나오는 것을 확인할 수 있다.
AWS의 GCDN, AWS CloudFront
CloudFront는 AWS에서 제공하는 CDN(Content Delivery Network) 서비스이다. CDN 서비스를 이용하면 서비스 대기 시간과 성능이 개선되어 이미지, 오디오, 비디오 및 일반 웹 페이지 등을 최종 사용자에게 빠르게 제공할 수 있다. CDN에 대한 추가적인 설명은 이곳에서 확인할 수 있다.
일반적으로 멀리 떨어진 서버보다는 가까운 서버에서 데이터를 제공 받는 것이 더 빠르기 때문에 AWS는 전세계 다양한 곳에 에지 로케이션을 두고 서비스를 제공하고 있다. 서울에도 인터넷 액세스 포인트가 구축되어 전 세계 엣지 로케이션으로 구성된 글로벌 네트워크와 연결된다. 엣지 로케이션 위치에 대한 자세한 정보는 이곳에서 확인할 수 있다.
EC2나 S3의 데이터에 접근을 했을 때 CloudFront 서비스를 사용하지 않는다면 해당 리전에서 데이터를 직접 가져오므로 해당 리전이 멀리 떨어져 있다면 아무래도 비교적 지연 시간이 있을 수 밖에 없다. CloudFront는 오리진 서버에 위치한 원본 파일을 전세계에 위치한 에지 로케이션으로 배포하고 에지 로케이션은 이 데이터를 캐싱하며 사용자는 자신의 위치와 가까운 에지 로케이션에서 캐싱된 데이터를 제공 받으므로 이런 문제를 어느 정도 해결할 수 있다. 오리진 서버는 S3 버킷, EC2 혹은 ELB(Elastic Load Balancer)와 같은 다른 AWS이거나 자체 오리진 서버일 수 있다.
기억해두어야겠다
GCDN (Global Content Delivery Network)
동작
CSS와 JavaScript, 이미지와 같이 공통으로 호출되는 리소스를 저장해두어 웹 서버가 제공하는 것이 아닌 CDN에서 제공하도록 하여 트래픽을 줄인다.
기존 방식의 문제점
CSS와 JavaScript, 이미지와 같이 공통으로 호출되는 리소스는 한 번 업로드되면 잘 변하지 않는다. 이런 리소스를 웹 서버에서 직접 제공하면 트래픽 부하가 엄청나게 가중된다. 예를 들어 100KB 용량의 이미지를 10만 명이 조회하면 대략 10GB의 트래픽이 발생한다.
적용 위치
Web Server의 앞단
장점
1.
공통적으로 호출되는 리소스의 부하 분산을 위해 GCDN을 사용한다. 리소스를 GCDN으로 분산하면 트래픽을 상당히 절감할 수 있다.
2.
GCDN에서 지원하는 GSLB(Global Server LB) 기능은 접속한 IP 주소에서 가장 가까운 CDN 서버를 자동으로 선정해 연결하기 때문에 사용자가 빠른 서비스 속도를 체감할 수 있다.
서킷 브레이커 (Circuit Breaker)
동작
서킷 브레이커는 아래의 3가지 상태를 가지면서 오류가 발생한 경우에 외부 서비스의 장애로 인한 연쇄적 장애 전파를 막기 위해 자동으로 외부 서비스와 연결을 차단 및 복구한다.
•
Closed 상태: 메서드가 정상적으로 작동해 서킷이 닫힌 상태
•
Open 상태: 메서드에 문제가 생겨서 서킷이 열린 상태
•
Half-Open 상태: Open 상태와 Closed 상태의 중간 상태. 메서드를 주기적으로 확인해 정상이라고 판단되면 Closed 상태로 상태를 전환하고, 정상이 아니라면 Open 상태를 유지한다.
기존 방식의 문제점
분산 환경에서는 네트워크 일시 단절 또는 트래픽 폭증으로 인한 간헐적 시간 초과 등의 상황이 종종 발생한다. 이로 인해 다음과 같은 연쇄 장애가 발생할 가능성이 있다.
1.
트래픽 폭증으로 인해 API 서버 등 외부 서비스의 응답이 느려진다.
2.
외부 서비스의 응답이 타임아웃 시간을 초과하면 데이터를 받아오기 위해 외부 서비스를 다시 호출한다.
3.
이전에 들어온 트래픽을 다 처리하지 못한 상태에서 재시도 트래픽이 추가로 적체되어 외부 서비스에 장애가 발생한다.
4.
외부 서비스의 장애로 인하여 데이터를 수신하지 못해 네이버 메인 서비스에도 장애가 발생한다.
일시적인 경우라면 2, 3회 재시도로 정상 데이터를 수신할 수 있다. 하지만 장애 상황이라면 계속 재시도하는 것이 의미도 없을 뿐 아니라 외부 서비스의 장애 복구에 악영향을 미칠 수 있다.
적용 위치
WAS 단
장점
애플리케이션의 안정성과 장애 저항력을 높이는 데 있다.
장애 상황에서 외부 서비스에서 데이터를 받아오는 것을 포기하고 미리 준비된 응답을 사용자에게 전달하는 것이 시스템 안정성 및 사용 편의성 측면에서 옳다고 할 수 있다.
서비스 디스커버리
동작
서비스 디스커버리 서버는 각 서버군의 서버 목록을 관리한다.
서버는 시작할 때 자신의 정보(IP 주소, 포트)를 서비스 디스커버리 서버로 보내고, 서비스 디스커버리 서버는 이 정보를 받아 서버군의 서버 목록을 최신으로 갱신한다. 각 서버군에 있는 서버는 주기적으로 서비스 디스커버리 서버로 목록을 요청해 서버 목록을 최신으로 유지한다.
이러한 방법으로 서버는 재시작 등 외부의 개입이 없어도 자동으로 항상 최신 서버 목록을 확보할 수 있다.
기존 방식의 문제점
다른 서버군(서버군 2)에 새로운 서버를 생성하는 경우, 서버 목록을 갱신하려면 서버군 1에 있는 서버를 다시 실행해야 한다.
롤링 리스타트를 한다고 해도 서비스를 운영하는 도중에 서버를 다시 실행하는 것은 매우 위험하다.
장점
서비스 디스커버리는 특히 클라우드 환경에서 빛을 발한다.
클라우드 환경에서는 수시로 서버가 추가, 삭제된다(특히 오토스케일링 등의 기능을 사용한다면 더욱 더). 이를 사람이 일일이 확인해 서버를 다시 실행하는 것은 불가능에 가깝다. 서비스 디스커버리는 이런 상황에서 아주 유용하게 사용할 수 있는 기술이다.
참고
