Chapter 02. 대규모 데이터 처리 입문

메모리와 디스크, 웹 애플리케이션과 부하

대규모 데이터 처리의 어려운 점

1. 메모리와 디스크 속도 차

데이터가 커질수록 메모리 내에서 계산할 수 없으며 계산이 불가능하므로 디스크에 두고 데이터를 검색한다. 하지만 메모리는 디스크보다 10^5 ~ 10^6 배 이상 빠르다. 디스크에서 검색하는 것은 메모리에 비해 상당히 느리다.

1. OS 레벨에서의 연구 >디스크는 느리지만 OS는 연속된 데이터를 같은 위치에 쌓아 1번의 회전으로 읽는 데이터의 수를 많게 한다. 그 결과로 디스크의 회전횟수를 최소화할 수 있게 된다. 하지만 여전히 디스크는 메모리보다 상당히 느리다.

2. 전송속도, 버스의 속도차 >탐색속도 측면에서는 메모리가 디스크에 비해 10^5~10^6배 이상 빠르다. 이유는 디스크의 동작원리에서 찾을 수 있다. 하지만 메모리나 디스크 모두 CPU와 버스로 연결이 되어 있다.

메모리 : 7.5GB/초 , 디스크 : 58MB/초

Linux 단일 호스트의 부하 

Load Average 확인 후 CPU, I/O 병목 원인 조사 

CPU 문제 시 : top, sar

ps로 보는 CPU 사용 시간으로 원인 프로세스 찾기

원인 프로세스를 strace, oprofile로 상세 조사 

I/O부하가 높은 경우 

sar, vmstat 

스왑 발생 시 메모리 증설, 부하분산 검토 , 프로그램 부하 해결

스왑 발생아니고 입출력 빈번한 경우 캐시 메모리 부족하다고 생각 가능, 데이터 용량, 메모리 증설 캐시서버 도입 검토 

규모조정의 요소

"대규모 환경이라고 하면 서버를 여러 대 나열해놓고 그 서버로 부하를 분산한다." 웹 서비스에서 규모조정(scaling), 확장성(scalability)과 관련된 이야기이다.

1. 규모조정의 요소 (CPU 부하와 I/O 부하) >스케일아웃은 하드웨어를 횡으로 전개해서 확장성을 확보하는 것이다. 이는 CPU부하의 확정성을 확보하기 쉽다. HTTP 요청을 받아 DB에 질의하고 DB의 응답을 HTML로 클라이언트에 반환할 때 기본적으로 CPU부하만 소요되며 추 후 서버 구성 중에 프록시나 AP서버가 담당할 일이다. 한편 DB서버 측면에서는 I/O부하가 걸린다.

대규모 데이터 및 DB라는 두 가지 관점

1. 웹 애플리케이션과 부하의 관계 > AP서버는 CPU 부하만 걸리므로 분산은 간단하다. 이유는 AP서버가 데이터를 분산해서 갖고 있는 것이 아니므로 대수를 늘리기만 하면 간단히 확장할 수 있다. 프록시에서 AP서버에 요청하여 균등하게 요청을 나누어 분산하는 것은 로드밸런서(load balancer)라는 장치가 해준다.

2. I/O 부하 > I/O부하는 AP 서버에서 DB로 자료를 요청하는 과정에서 발생하며 DB를 늘린다고 하더라도 동기화의 문제가 발생한다. 이와 같이 데이터를 쓰는 것은 간단히 분산할 수 없다.

3. DB 확장성 확보의 어려움 > DB에서 디스크를 많이 사용하여 I/O를 많이 발생시키는 구성으로 되어 있다면 디스크와 메모리의 속도차 문제로 인해서 문제가 생긴다. 이와 같은 상황에서는 '서비스가 무거우니 서버를 늘리자'는 의견을 제안하여 기술적인 배경이 훤히 드러나 민망한 상황이 발생할 수 있다.

Load Average 로 우선 부하 걸리는 것 확인 후 I/O 또는 CPU 부하를 구체적으로 확인

대규모 데이터를 다루기 위한 기초지식

데이터를 메모리에서 처리하여 디스크 Seek 횟수를 최소화 + 디스크 seek 횟수 최소화 + 국소성을 활용한 분산 실현 + 데이터량 증가에 강한 알고리즘을 사용 + 데이터 압축, 검색기술 테크닉 사용

대규모 데이터를 다루기 전 3대 전제지식

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