#3 대규모 서비스를 다루기 전 기초 지식

트래픽이 증가하게되면서 우리는 장비의 성능을 끌어올리거나 개수를 늘릴 수 있고, application의 캐시 등 성능개선, DB서버의 I/O 최소화 등 작업을 진행하면서 기본적으로 알아야할 사항들이 상당히 많다.

 

일전에 언급했던 스케일업과 스케일아웃이 많이 볼 수 있는 대응 방법인데, 보통은 스케일아웃을 많이 채택한다. 그 이유는 많은 것들이 있을 수 있지만 웹 서비스에 적합하고 비용이 저렴하며 시스템 구성에 유연성이 있다는 점이 높게 평가되고 있다. 스케일아웃의 특징은 하드웨어를 횡으로 전개해서 CPU 부하의 확장성을 확보하기 쉽다.

하지만 DB 서버 측면에서는 I/O 부하가 잦게 일어난다.

[그림 1] 웹 애플리케이션 부하

[그림 1]을 보면 알 수 있듯이 프록시의 요청이 AP 서버를 거처 DB에 도달해서 DB측에 I/O가 발생한다. AP 서버는 CPU 부하만 걸리고 데이터를 분산해서 갖고 있는것이 아니기 때문에 분산이 가능하다.

DB의 I/O 부하에는 "데이터를 어떻게 동기화시키는가?"에 대한 문제가 있다. 심지어 DB에서는 디스크를 많이 사용하무로 디스크 I/O를 자주 발생시키는 구성이라면 속도차 문제도 발생할 수 있다.

 

우리는 시스템에 부하가 생겼을 때 Load Average를 체크한다. 그렇다면 이 값은 대체 어떻게 측정되는 것일까?

 

하드웨어는 CPU로 일정 주기마다 '타이머 인터셉트'라고하는 신호를 보낸다. 이 인터럽트마다 CPU는 시간을 진행시키거나 실행 중인 프로세스가 CPU를 얼마나 사용했는지를 계산하는 등 시간과 관련된 처리를 수행한다. 이 타이머 인터럽트마다 Load Average값이 계산된다.

커널은 타이머 인터럽트가 발생했을 때 실행 가능 상태은 task와 I/O 대기인 task의 개수를 count한다. 그 값을 단위 시간으로 나눈 것이 Load Average 값으로 측정된다.

 

우리가 대규모 서비스를 다룰 때 어떤 고려사항이 있는지 크게 세 가지로 알아보자.

1. 어떻게 디스크가 아닌 메모리에서 처리를 다 할 수 있는지에 대한 고민
   1. 디스크 seek 횟수 최소회
   2. 국소성을 활용한 분산
2. 데이터량 증가에 강한 알고리즘 사용
   1. 선형탐색 보다는 Log Order 알고리즘 사용 등
3. 데이터 압축 혹은 검색기술(ES 등)과 같은 테크닉 활용

프로그램 개발을 하다보면 많은 알고리즘뿐만 아니라 데이터 저장 혹은 세션 등 문제에 부딛치기 마련이다. 평소 개발 할 때 아래와 같은 사항을 고민하면 좋다.

• OS캐시
• 분산을 고려한 RDBMS 운용
• 알맞은 알고리즘과 데이터 구조 사용