Chapter 01. 대규모 웹 서비스 개발 오리엔테이션

Chapter 01. 대규모 웹 서비스 개발 오리엔테이션

1-1. 소규모 서비스와 대규모 서비스의 차이점

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

1) 스케일 아웃으로 서버 1대가 처리할 수 없는 부하를 처리한다. 단, 스케일 아웃 전략은 스케일 업 전략에 비해서 비용이 절감되지만 서버가 1대인 경우와는 다른 문제가 발생한다. 문제의 유형은 다음과 같다. (1) 사용자의 요청을 어떻게 분배할 것인가? (2) 데이터 동기화는 어떻게 할 것인가? (3) 네트워크 통신의 지연시간(latency)을 어떻게 생각해볼 수 있을까?

이에 대한 해답은 앞으로 책의 내용을 통해서 해결해보자.

스케일 아웃, 서버를 횡으로 전개하여 서버의 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인 처리능력을 높여서 부하를 분산하는 방법이다.

스케일 업, 하드웨어의 성능을 높여 처리능력을 끌어올리는 방법이다.

1. 다중성 확보 시스템은 특정 서버가 고장 나거나 성능이 저하되더라도 서비스를 계속할 수 있어야 한다. 스케일 아웃 전략으로 인해 서버 대수가 늘어나면 서버의 고장률도 올라가므로 24시간 돌아갈 수 있도록 설계해야 한다.
2. 효율적 운용 필요 서버의 대수가 많아지면 모니터링 소프트웨어를 사용하고 정보관리를 위한 툴을 사용하여 자동화를 하게 된다.
3. 개발자 수, 개발방법의 변화 프로그래밍 언어 통일, 라이브러리나 프레임워크를 통일, 코딩 규약을 정해서 표준화, 버전 관리 등 실행하며 팀 매니지먼트 등이 이루어져야 한다.

대규모 데이터량에 대한 대처

Disk 데이터 로드 -> memory 저장 -> 캐시 메모리 -> CPU를 통해 처리 각 단계 간에 속도차가 매우 크게 나며 이 속도차를 흡수하기 위해 OS는 다양한 방법을 사용한다. 1. Disk로부터 읽어들인 데이터를 메모리에 캐싱 단, 데이터량이 많아지면 캐시 미스가 발생하여 저속의 disk로 많은 I/O가 발생하여 전체적인 시스템 속도저하를 초래한다.

1-2. 계속 성장하는 서비스와 대규모화의 벽

하테나 사례로 대규모 서비스에 대응 방식 확인 1. 지속적인 사용자 증가로 트래픽이 감당할 수 없게 되었으며 서버 1대를 부하분산, 시스템 규모를 확장하고 있었으나 계획적 대응이 불가능하였다. 따라서 조직체제를 재점검하고 시스템 운용 전담팀을 구성하여 대응했다.
1) 서버룸에서 데이터 센터로 서버 이전
2) 기존 시스템의 부하상황 정리, 각 서비스 병목 지점 측정
(1) I/O 부하가 높은 서버는 메모리를 중요시, CPU 부하가 높은 서버는 CPU를 중요시하여 용도에 맞게 최적 구성
3) 다중화 해결을 위하여 로드밸런서와 가동감시 기능을 하는 오픈소스(LVS, keepalived) 도입
4) 서버 교체는 OS 가상화
5) 서버 정보관리를 위한 독자적인 웹 기반 서버 정보 관리 시스템 개발
6) 서버/인프라 측면에서 시스템 구성 외 애플리케이션의 각종 로직이나 DB스키마 등 재검토

시스템의 성장전략 - 미니멈 스타트, 변화를 내다본 관리와 설계
소규모의 서비스가 반드시 대규모가 될 수 없으며 대규모가 될 것을 가정하여 완벽한 대응을 하려고 한다면 비용이 너무 많이 들게 된다.
하지만 아무 생각 없이 불완전하게 서비스를 시작하는 것은 하테나의 역사를 통해 바람직한 방법은 아니라는 것을 알 수 있다. 
따라서 서비스를 시작할 때 수용능력 관리나 서비스 성장을 예측한 구성으로 요소요소 서비스 구성을 한다면 필요 이상의 비용을 들이지 않고 미니멈 스타트(Minimum start)할 수 있다.