대규모 서비스와 서비스의 규모 확장 전략

 

대규모 서비스

대규모 서비스는 거대한 데이터를 처리할 수 있는 서비스를 의미한다.

거대한 데이터는 여러 상황들( 1. 다수의 등록된 사용자로 인한 대용량 데이터 처리가 필요한 경우 2. 특정 시간대에 사용자 접근이 집중되어 트래픽이 폭증하는 경우 3. 실시간 데이터 처리량이 매우 큰 경우 등)으로 해석된다. 즉, 거대한 데이터는 단순히 저장된 데이터의 크기뿐만 아니라, 처리해야 하는 데이터의 특성과 패턴에 따라 다양한 형태로 나타날 수 있다. 따라서, 이러한 데이터의 특성을 고려하지 않은 개발이 이루어질 경우, 시스템이 비효율적으로 구성되어 서비스 제공속도가 느려지거나 심각한 경우 전체 서비스의 장애로 이어질 수 있다.

 

소규모 서비스와 대규모 서비스의 차이

목표한 기능의 구현에 초점을 맞추는 소규모 서비스와 비교했을 때 대규모 서비스는 어떤 차이점을 갖는지 다음을 통해 살펴본다.

1. 확장성 확보, 부하분산 필요

대량의 액세스가 발생하는 서비스에서는 단일 서버로 처리할 수 없는 부하가 가장 큰 문제점으로 대두된다. 이러한 문제를 해결하기 위한 방안으로 ‘스케일 업(scale-up)’과 ‘스케일 아웃(scale-out)’ 전략을 고려할 수 있다. 스케일아웃은 서버를 횡적으로 전개하는 방식으로, 서버의 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인 처리능력을 높여서 부하를 분산하는 방법이다. 반면, 스케일 업은 하드웨어의 성능을 높여 처리능력을 끌어올리는 방법이다. 하드웨어의 성능이 높아질 수록 추가적 성능 개선에 필요한 비용이 천문학적으로 올라가기 때문에 저렴한 하드웨어를 나열하는 확장성을 통해 부하를 분산시키는 ‘스케일 아웃’ 전략이 대규모 서비스 환경에 더 적합하다. 

**‘스케일 아웃’ 전략을 채택하면 서버가 1대일 때 생각하지 못한 다양한 문제가 발생 가능하다.**

Q: 사용자 요청을 어떻게 분배할 것인가?
    ‘로드 밸런서’를 사용한다. ex) AWS Load Balancer, Nginx, etc
    
Q: 데이터 동기화는 어떻게 할 것인가?
    
    레플리케이션(마스터-슬레이브), 분산 트랜잭션 처리 등을 적용한다.
    (DB 서버 분산 시 한쪽 서버의 변경 내용을 다른 DB가 알지 못한다면 애플리케이션의 비정상 사태가 발생한다.) 
    

2. 다중성 확보

다중성이란 시스템의 가용성과 신뢰성을 높이기 위해 동일한 기능을 하는 컴포넌트를 여러 개 두는 것을 의미한다. 대규모 서비스에서는 특정 서버의 장애나 성능 저하가 발생하더라도 서비스를 지속적으로 제공할 수 있는 구성이 필수적이다. 서비스의 규모가 커질수록 시스템 중단으로 인한 사회적 영향이 증가하기 때문에 다중성 확보의 중요성은 더욱 커진다. 2022년 10월 15일에 판교 데이터 센터 화재로 인한 카카오 서비스 중단 사태는 이러한 다중성 확보의 중요성을 보여주는 대표적 사례다.

3. 효율적 운용 필요

운영 서버가 1대라면 주기적으로 상태를 확인하는 정도로 서버의 정상 동작 유무를 간단히 파악할 수 있다. 하지만 서버 대수가 100대를 넘어서면 어떤 서버가 무슨 역할을 하고 있는지 등에 대한 관리가 어려워 진다. 부하는 괜찮은지, 고장난 부분은 없는지, 디스크 용량은 아직 충분한지, 보안 설정에 미비한 점은 없는 지, … 등 여러 가지 항목을 모든 서버에 대해 잘 살펴봐야한다. 다수의 서버에 대한 사람의 모니터링은 불가능에 가깝기 때문에 정보관리 툴을 사용하듯이 소프트웨어를 통한 자동화가 필수다. 이러한 감시 소프트웨어를 관리하는 주체 역시 사람이지만, 관리해야 하는 항목을 최소화 하여 대규모 시스템을 건강한 상태로 유지하기 위한 효율적인 운영을 할 수 있다.

4. 개발자 수, 개발 방법의 변화

개발 표준화가 필요하다. 대규모 서비스가 되면 당연히 혼자서는 개발과 운영이 어렵기 때문에 여러 개발자가 역할 분담을 해야 한다. 애플리케이션에 여러 개발자가 각자 제멋대로 기능을 추가 및 수정한다면 해당 시스템의 유지보수는 장기적으로 어려워질 것이다. 따라서, 프로그래밍 언어, 라이브러리 혹은 프레임워크를 통일하고 코딩 규약을 정해서 개발 시스템을 표준화한다면 마치 한명이 작업한 것과 같은 통일성을 가질 수 있다. 이는 다른 개발자의 프로젝트에 대한 이해도와 생산성 및 유지보수성을 높이는 결과를 가져온다. 즉, 효율적인 개발을 할 수 있다.

 

 

서비스 규모의 확장

 지금까지 데이터 관점에서 대규모 서비스를 살펴보았다. 대규모 서비스는 거대한 데이터를 처리할 수 있는 서비스를 의미한다. 이때, 소규모로 시작한 서비스가 거대한 데이터를 처리할 수 있게 개선 및 확장되면서 서비스 자체의 규모도 거대해 질 수 있다. 이러한 상황에서, 단일 애플리케이션으로 되어있는 서비스의 구조(모놀리식 아키텍처, Monolithic Architecture)를 여러 개의 작은 애플리케이션으로 이루어진 구조(MSA, Microservices Architecture)로 변경하는 것을 고려할 수 있다. 이제 애플리케이션 관점에서 대규모 서비스를 살펴보도록 한다.

 

대규모 서비스에서 나 타나는 Monolitic Architecture의 단점

모놀리식 아키텍처는 모든 비즈니스 로직이 하나의 애플리케이션 형태로 패키지되어 서비스되는 소프트웨어 아키텍처를 의미한다. 서비스가 소규모일 때 장점이었던 모놀리식 아키텍처의 특징은 서비스가 확장되면서 큰 단점이 될 수 있다. 

1. 확장성 문제

특정 기능에 대한 부하가 높아도 전체 시스템을 확장해야 한다. 수평적 확장 시 서버 운영을 위한 최소 스펙이 올라가기 때문에 불필요한 리소스 낭비와 비용이 증가할 수 있다.

2. 개발 및 배포의 어려움

개발 측면에서 코드 베이스가 거대해지기 때문에 개발자의 애플리케이션 이해도가 떨어진다. 작은 수정사항을 반영할 때도 전체 애플리케이션을 다시 빌드 및 배포해야 하는 데, 애플리케이션이 거대해지면 배포시간이 길어지는 단점이 존재한다.

3. 기술 스택의 제약

애플리케이션에서 기존에 사용한 기술 스택으로 모든 기능을 구현해야 한다. 서비스가 거대해지면서 사용자 경험 향상을 위해 여러 기능의 성능 개선을 위한 최적화가 필요해지는 데, 각 기능에 최적화된 기술을 선택하는데 어려움이 존재한다. 또한, 새로운 기술 도입이나 라이브러리 버전 업그레이드가 어렵다.

4. 장애의 전파

한 부분의 문제가 전체 서비스 장애로 이어질 수 있다는 큰 단점이 존재한다.  예시로 특정 기능의 잘못된 설계로 인해 메모리 누수나 성능 저하가 발생하면 전체 시스템에 영향을 미친다.

5. 팀 협업의 어려움

여러 팀이 동시에 작업할 때 코드 충돌 발생 가능성이 높아진다. 또한, 코드에 대한 책임 영역의 구분이 모호해지며 코드의 품질 관리가 어려워진다.

 

 

 

 

Referces

- [도서] 대규모 서비스를 지탱하는 기술, 이토나오야

- 대규모 웹 서비스란?

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