확장성 및 안정성 있는 시스템에 관하여 (feat. 패스트캠퍼스 온라인 'THE RED : 4천만 MAU를 지탱하는 서비스 설계와 데이터 처리 기술')

이번 주제에서는 '카카오페이지 기술전략이사 윤진석' 님이 진행하신 강의에 대하여 초반부를 제외한 '확장성 및 안정성 있는 시스템', '대규모 시스템에서 발생하는 데이터 처리'와 관련해 각각 주제를 정리하며 수업 내용의 요약을 곁들여보려 합니다.

 

• 다음글: 대규모 시스템에서 발생하는 데이터 처리 (feat. 패스트캠퍼스 온라인 'THE RED : 4천만 MAU를 지탱하는 서비스 설계와 데이터 처리 기술')

 

총 2개의 페이지로 나누어 이번 글에서는 전자인 '확장성 및 안정성 있는 시스템' 부분을 살펴보겠습니다. 개인적으로 강의 내용 중 넓은 시각에 대한 공유는 존재하나, 전체적인 구조와 디테일에 있어서 정리가 잘 되어 있지 않은듯 하여 주제별로 다른 리소스를 참고하였습니다. 

 

• 웹의 확장성이란
• 웹 확장성을 이루는 요소들
• 웹의 안정성이란

---

웹의 확장성이란

먼저 웹의 확장성이란 무엇인지 살펴볼 필요가 있습니다. 여러 측면이 존재하나 크게 아래의 3가지로 나눠질 수 있습니다 [1]:

 

• 더 많은 데이터의 처리: 가장 흔한 도전과제입니다. 비지니스가 성장하면서 더 많은 사용자 계정, 상품, 위치의 데이터를 처리할 수 있어야 합니다. 

 

• 더 높은 동시성의 제공: 동시성(Concurrency)은 얼마나 많은 사용자를 동시에 처리할 수 있느냐에 관한 것입니다. 동시 사용자가 증가함에 따라 서비스는 제한된 CPU와 실행 쓰레드, 메모리로 증가하는 요청을 처리하여야 합니다. 이러한 부분은 데이터 일관성을 위해 병렬 처리를 synchronize할 필요가 발생하며 더욱 복잡해집니다.

 

• 더 높은 인터랙션 비율: 시스템과 고객이 인터랙션하는 비율로 얼핏 2번째의 동시성과 비슷해보이나 다릅니다. 예로, 만약 고객이 웹사이트를 이용하는 경우에 페이지의 이동은 평균 15 ~ 120초에 한 번 발생합니다. 하지만 만약 고객이 멀티플레이어의 모바일 게임을 사용하는 경우라면 초 당 여러 번의 메시지 교환(시스템-클라이언트 간)이 필요하게 됩니다. 

시스템의 확장성은 이러한 3가지 요구사항의 조합입니다. 살펴보면 '성능'이라는 부분과도 연관됨을 알 수 있으나, 성능은 특정 작업 수행이나 요청을 처리하는데 얼마나 오래 걸리나에 집중하는 반면 확장성은 시스템이 얼마나 확장될 수 있느냐를 다루기에 다릅니다. 

 

또 자주 언급되는 확장성의 다른 측면으로는, '서비스의 확장성'이라는 부분으로 볼 수 있는 '얼마나 요구사항에 대한 구현이 빠르게 진행될 수 있는가'라는 부분도 존재합니다. 이러한 측면은 '모노리스'와 '마이크로서비스'를 비교할 때 중점적인 관점으로 사용되나 이 글에서는 그러한 부분을 포함하지 않고 다루려고 합니다. 

 

 

웹 확장성을 이루는 요소들

이번 장에서는 웹 확장성과 관련해 고객 - 애플리케이션 상호 요청 및 응답 관점을 중심으로 탑다운 방식으로 알아보겠습니다. 

먼저, '큰 그림'에서 단일서버의 간단한 구조와 글로벌 서비스 시스템을 비교하며 기업의 전체 웹 시스템을 살펴보겠습니다. 이어 데이터 센터에 주목해 그 내부 레이어별로 살펴보고, 마지막으로 애플리케이션 내부의 구조를 살펴보도록 하겠습니다.

큰 그림

먼저 큰 그림에서의 극과 극을 살펴보도록 하겠습니다. 

 

먼저 아래와 같은 하나의 서버로 구성된 시스템이 존재할 수 있습니다:

Single Server System - Image from Author inspired by [1]

 

이어 글로벌 고객들을 서비스하기 위해 여러 부분 확장성이 극대화된 아래와 같은 시스템 구조도 존재할 수 있습니다:

 

Global Service System-  Image from Author inspired by [1]

단일 서버

사용자는 DNS(Domain Name System)에서 접속하고자 하는 도메인의 ip를 얻어 단일 서버로 구축된 서비스에 접근합니다. 서비스를 이루는 웹서버, 데이터베이스 등 모든 서비스는 하나에 존재합니다. 작은 기업의 작은 유저가 존재한다면 이러한 구조가 충분할 수도 있습니다. 또한, 서버 하나도 아닌 VPS(Virtual Private Server)와 같은 호스팅을 통해서라도 충분히 요구사항을 만족할 수도 있습니다. 

 

글로벌 서비스 시스템

세계 여러 지역 사용자의 요청을 처리하는 글로벌 서비스의 시스템은 그와 상반되게 확장성을 위해 다양한 기술과 도구들을 사용하게 됩니다. 아래와 같은 부분들이 존재하는데요:

 

• 버티컬 스케일링: 애플리케이션이 서버의 한계에 다다르며 각 서버는 점점 더 많은 스펙을 가진 서버로 대체되었습니다. 더 많은 하드 드라이브를 더해 I/O 능력을 추가, HDD에서 SSD로 변경, 메모리를 더 추가, 더 많은 코어를 가진 서버로 대체, 네트워크 인터페이스를 업그레이드와 같은 것들이 이것에 속합니다. 다른 확장방법과 비교해 비교적 간단한 편입니다. 하지만 버티컬 스케일링 역시 한계효용이 존재하여 다다르면 horizontal 스케일링의 방법을 취하게 됩니다.

Cost of scalability unit - Image from [1]

• 서비스의 분리: 초기 단계에서 취할 수 있는 확장성의 방법은 버티컬 스케일링말고도 서비스의 분리 실행을 통해 가능합니다. 한 서버에 몰려서 실행되고 있던 데이터베이스, 웹서버와 같은 서비스들을 각각 독립된 서버에 나누어 실행할 수 있습니다. 

 

• CDN: 정적 컨텐츠와 같은 경우는, 제3자 CDN을 통해서 제공하여 서버가 받는 요청을 줄일 수 있습니다. 

 

• Horizontal 스케일링: 이전의 확장방법과는 달리 조금 어려운 측에 속하며, 대부분 애플리케이션이 만들어지기 전에 고려하게 됩니다. 만약 애플리케이션이 만들어진 이후에 고려하게 된다면, 애플리케이션의 구조에 많은 변경이 필요할 수 있게됩니다. 복잡한 부분을 제외한다면 방법은 존재하는 서버에 여러 추가적인 서버를 더해서 실행하여, 각 서버가 받는 부하를 분산하는 것입니다. 아래와 같이 버티컬 스케일링과 비교한다면, 특정 시점부터 한계효용의 우위를 점하게 됩니다. 데이터 센터 내의 모든 시스템 요소에 대한 horizontal 스케일링을 이루는 것은 매우 어렵고 비싸기에, 실제로는 일부 horizontal 스케일링이 비교적 간단한 웹서버나, 캐시부터 시작해 필요할 경우 (어려운) 데이터베이스, 영속적인 스토리지 등의 순으로 진행하게 되며 일부는 적용이 안된 채로 남아있을 수도 있습니다.

Comparison of vertical and horizontal scaling costs - Image from [1]

 

• geoDNS: GeoDNS는 DNS 서비스로 고객의 위치에 기반하여 도메인에 대한 ip 매핑을 진행합니다. 유럽에서 접근하는 고객은 유럽에 존재하는 서버의 ip로, 미국에서 접근하는 고객은 미국 서버의 ip로 전달하여 네트워크 latency를 낮추고 부하도 분산할 수 있게 됩니다.

 

• Edge cache: 여러 edge-cache 서버를 세계의 각 지역에 위치시켜 추가적으로 네트워크 latency를 더 낮출 수 있습니다. Edge-cache 서버의 사용은 운영하는 애플리케이션 특성에 의존합니다. Edge-cache 서버가 전체 페이지를 캐시하는 리버스 프록시 서버로 동작할 때 가장 효과적이나, 다른 추가적인 기능도 제공할 수 있습니다.

 

데이터 센터 내부

이어서 고객의 요청이 어떻게 데이터 센터 내부의 다양한 레이어들과 연결되는지를 중심으로 살펴보겠습니다.

 

A high-level overview of the data center infrastructure - Image from Author inspired by [1]

 

Front-line

사용자의 기기가 직접적으로 연동되는 컴포넌트입니다. Front-line의 일부는 데이터 센터에 존재할 수도 있고, 외부에 존재할 수도 있습니다. 이러한 컴포넌트들은 별다른 비지니스 로직을 가지고 있지 않고 주요 목적은 수용량을 올려서 확장성있게 만드는 것입니다.  사용자의 요청은 DNS 서버를 통해 ip를 확인하고 CDN에서 응답을 얻거나 또는 데이터 센터의 로드 밸런서에 이르게 됩니다.

 

이후 요청은 옵셔널한 front cache에 이르거나 또는 직접적으로 front app에 닿습니다. 많은 부분이 서드파티를 통해서 호스팅될 수 있습니다.

 

Web Application Layer

두번째 레이어는 웹애플리케이션 레이어입니다. 실제 HTML을 생성하거나 클라이언트의 HTTP 요청을 처리하는 웹 애플리케이션 서버로 이뤄져 있습니다. 웹 애플리케이션은 간단할 수록 좋은데, 대부분의 비지니스 로직을 웹 서비스에 미룸으로써 재사용하거나 변경의 필요를 줄일 수 있게 됩니다. 

 

웹 애플리케이션 서버는 보통 상태가 없어서 확장이 쉽습니다. 

 

Web Services Layer

세번째 레이어는 웹 서비스로 구성되어 있습니다. 대부분의 애플리케이션 로직을 담고 있어서 매우 크리티컬한 레이어입니다. 웹 서비스를 생성할 때 기능적 파티션을 생성하기 쉽습니다. 특정한 기능을 담당하는 웹 서비스를 생성하여서 각 기능별로 필요에 따라 독립적으로 확장할 수 있습니다. 예로, 이커머스 웹 애플리케이션에서 상품 카탈로그 서비스와 사용자 프로파일 서비스가 있다고하면, 각각은 다른 확장성에 대한 요건이 존재하게 됩니다. 

 

front-end 애플리케이션과 웹 서비스 간의 통신은 보통 REST(Representational State Transfer)이거나 HTTP를 통한 SOAP(Simple Object Access Protocol)입니다. 구현에 따라, 웹 서비스는 비교적 horizontal 스케일링이 쉽습니다. 상태가 없이 관리하는 한에서, 단순히 풀에 더 많은 서버를 더해서 확장이 가능하게 됩니다. 

 

최근 웹 애플리케이션 간에 통합하는 방향이 많이 사용되어, 웹 서비스 레이어가 직접 서드파티나 고객과 통신하기도 합니다. 

 

Additional Components

front-end 및 웹 서비스는 상태가 없어야 하기 때문에, 웹 애플리케이션은 캐시와 메시지 큐 같은 추가적인 컴포넌트를 필요로 하게 됩니다. 

 

Data Persistent Layer

데이터 영속화 레이어는 보통 horizontal하게 확장하기 가장 어려운 부분입니다. big data 및 NoSQL과 같은 비교적 최근에 태어난 기술들이 관련있는 레이어이기도 합니다. 

 

 

애플리케이션 아키텍쳐

애플리케이션 아키텍쳐는 프레임웍이나 특정 기술을 중심으로 한 것이 아닙니다. 아키텍쳐는 Java, PHP, PostgreSQL에 관한 것도 아닙니다. 아키텍쳐는 비지니스 모델을 중심으로 발전합니다. 그렇기에 아키텍쳐의 중심에 비니지스 모델을 놓음으로써 그러한 모델을 둘러싼 다양한 컴포넌트들이 다른 것이 아니라 비지니스를 돕도록 해야 합니다.

 

A high-level overview - Image from Author inspired by [1]

 

 

웹의 안정성이란

시스템 운영에서 안정성(Reliability)의 관리는 'availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s)'라고 정의할 수 있습니다 [2]. 

 

첫번째로, 가용성(Availability)은 'characteristic of a system which aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period'로 시스템이 전체 시간 중 사용가능하게 동작하는 시간비율을 나타냅니다. 

 

가용성

가용성은 3가지 원칙인 SPOF(Single Point of Failure)를 피하기, 다중화(Redundancy), 실패 즉시 발견에 중심을 두고 있습니다. 그렇기에 많은 부분이 SPOF를 다중화를 통해 피하는 것과 관련이 있습니다.

 

• SPOF와 Redundancy: 시스템 상의 모든 단일장애지점은 다중화를 통해 좀 더 안정화될 수 있습니다. 다중화란 장애가 발생해도 예비 운용장비로 시스템의 기능을 계속할 수 있도록 하는 것을 말하는데요. 예로, 공장이나 병원 등에서는 정전에 대비해 자가발전장치를 갖추는 것과 같은 것들이 있습니다. 1) 장애를 상정하고, 2) 장애에 대비해서 예비 운용장비를 준비하고, 3) 장애 발생 시 예비 장비로 교체할 수 있는 체제를 마련하는 순으로 진행되게 됩니다 [5].

 

지연속도와 성능

지연속도(latency)와 성능(performance)는 capacity planning과 관련이 있습니다. 소프트웨어 시스템은 부하가 추가되며 점점 느려지는데, 이러한 느려짐은 capacity의 소실과 같습니다. 안정성을 담당하는 SRE팀은 특정 응답 속도의 capacity를 만족하기 위해 provision을 진행합니다. 

 

 

효율성

리소스의 효율적인 사용은 모든 서비스에서 비용과 관련되어 중요합니다. 안정성에 대한 핵심 담당자가 provision을 관리하기 때문에, 사용률에 대하여 많이 연관되어 있습니다. 

 

 

변경 관리

Google의 SRE에 팀에 의하면 대략 70%의 시스템 중단은 live 시스템의 변경으로 인하여 발생한다고 합니다. 그렇기에 이러한 부분에 있어서 자동화를 통해 아래와 같은 사항을 중점으로 구축하여야 합니다:

 

• 점진적인 rollouts 구축
• 빠르고 정확하게 디버깅이 가능한 부분
• 문제 발생 시 안전하게 변경을 rolling back할 수 있는 부분

 

3가지는 변경으로 인한 시스템 중단을 효과적으로 줄일 수 있게 하고, 프로세스 상에서 사람의 개입을 제거하여 반복적인 작업에 있어서의 실수를 막을 수 있습니다.

 

모니터링

모니터링은 서비스 오너가 시스템의 건강과 가용성을 지속적으로 트래킹할 수 있는 주요한 수단입니다. 그렇기에 모니터링 전략은 매우 신중하게 설계되어야 합니다. 모니터링에서의 알람은 실제로 사람의 개입이 필요할 때만 알람을 받을 수 있도록 노이즈화 되는 것을 피하여야 합니다. 

 

유효한 모니터링은 아래와 같은 3가지 결과물을 산출합니다:

 

• 알람: 발생하고 있거나 발생하려는 일에 대한 응답으로 사람이 즉각적으로 액션을 취해야 할 때 알립니다.

 

• 티켓: 사람이 액션을 취해야 하나, 즉각적일 필요는 없을 때 알립니다. 시스템은 자동적으로 상황을 처리하지 못하며, 사람이 몇 일 내에 액션을 취하면 어떠한 데미지도 발생하지 않는 경우에 해당됩니다.

 

• 로깅: 정보를 볼 필요는 없으나, 추후의 진단이나 포렌식 목적으로 기록됩니다. 특별한 일이 발생하지 않는 한, 이러한 로그를 보지 않으리라 예상되는 경우에 해당됩니다. 

 

응급 대처

안정성은 실패까지의 평균 시간(MTTF, mean time to failure)과 교정까지의 평균 시간(MTTR, mean time to repair)의 함수입니다. 응급 대처의 효과를 측정하기 위해 가장 적절한 메트릭은 MTTR, 즉 얼마나 대처하는 팀이 빠르게 시스템을 다시 건강하게 만드느냐와 연관이 깊습니다. 

 

특정 시스템이 많은 장애를 겪는다면, 사람의 개입이 필요한 응급 상황의 경우 발생 이후의 교정이 아닌 이전의 사람의 개입을 통해 장애를 피할 수 있습니다. 사람의 개입이 필요한 경우를 위해 미리 대처의 베스트 프랙티스 대처프로세스(playbook)을 기록해두는 것은 MTTR에 있어서 3배의 개선을 가져다 준다고 합니다. 

 

그렇기에 Google의 SRE는 응급 대처에 있어서 on-call playbook과 on-call 시의 사전 모의 훈련과 같은 활동에 많이 의존한다고 합니다.

 

 

수요예측 및 수용량 계획 

수요예측과 수용량 계획은 시스템에 추정된 미래 수요와 필요한 가용성을 만족하기 위한 충분한 capacity와 다중화가 존재하도록 보장하는 활동입니다. 일부 필요한 시점에서 이를 간과하는(또는 놓치는) 팀이 존재한다는 부분 외에는 딱히 특별한 부분이 존재하지 않습니다. 

 

상품 적용 또는 고객 사용량에 따른 organic 성장과 기능 런칭, 마케팅 캠페인 등 비지니스에 의한 변경으로 인한 inorganic 성장이 존재합니다. 2가지 부분에 대한 수요 예측과 주기적인 시스템의 원천 자원에 대한 부하 테스팅이 의무적으로 필요한 부분이며 capacity는 가용성과도 연관이 깊기에 가용성을 담당하는 팀이 수용량 계획에 깊이 관여하게 됩니다.

 

 

Reference

[1] Web scalability for startup engineers : tips & techniques for scaling your Web application

[2] Site Reliability Engineering

[3] https://en.wikipedia.org/wiki/High_availability 

[4] https://en.wikipedia.org/wiki/Single_point_of_failure 

[5] 서버/인프라를 지탱하는 기술