Chapter 02. 대규모 데이터 처리 입문 (강의4 ~ 7)

강의4는 별 내용없어서 생략

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

대규모 데이터는 어떤 점이 어려운가?

1. 메모리 내에서 계산할 수 없다는 점

-> 디스크에 있는 데이터를 검색한다.

-> 디스크는 느리므로 I/O에 시간이 걸린다.

-> 어떻게 해결?

 

메모리와 디스크는 10~100만배의 속도차이가 난다고 생각하자. (2009년 + HDD사용하는 것, 2021년에 SDD사용하는거랑은 차이가 있지 않을까?)

HDD는 기본적으로 헤드의 이동, 원반의 회전이라는 두가지 물리적인 이동이 필요하다. 그리고 전송속도의 차이도 있다.

따라서 현대의 컴퓨터에서는 메모리와 디스크 속도차를 생각하고 애플리케이션을 만들어야 한다. 확장성을 생각할 때 매우 본질적이면서 어려운 부분.

책에서는 디스크와 메모리 전송속도 차이가 100배가 넘었는데

Cache reads: 7525.03 MB/sec

Disk reads: 58.37 MB/sec

직접 해보니  8 배정도 차이가 발생했다 . ( 하지만 이것도 큰 차이가 아닐까 )

Linux 단일 호스트의 부하.

아무리 분산부하를 하더라도 단일 서버의 성능을 충분히 끌어낼 수 있는 것으로 시작해야 분산부하에서의 의미를 갖는다.

1. 추측대신 계측하라

부하가 어느정도 걸리고 있는지를 정확히 조사할 필요가 있다. 가장 중요한 작업. 계측함으로써 시스템의 병목을 규명하고, 이를 집중적으로 제거함으로써 성능을 끌어낼 수 있다.

 

2. Load Average 확인

top이나 uptime 등의 명령으로 Load Average를 확인한다. 하지만 이것 만으로 병목의 원인이 어딘 지를 판단할 수 없다. 이걸 시초로 해서 병목지점에 대한 조사를 시작한다. Load Average는 낮은데 시스템의 전송량이 오르지 않는 경우는 SW 설정이나 오류, 네트워크, 원격 호스트 측에 원인이 없는지 등을 살펴본다.

3. CPU, I/O 중 병목 원인 조사

Load average가 높은 경우, CPU와 I/O중 어느 쪽에 원인이 있는지 조사.

CPU부하가 높은 경우

3-1. 사용자 프로그램의 처리가 병목인지, 시스템 프로그램이 원인인지를 확인한다.

3-2. 프로세스의 상태나 PCU 사용시간 등을 보면서 원인이 되고 있는 프로세스를 찾는다.

3-3. 프로세스를 찾은 후 보다 상세하게 조사할 경우는 strace로 추적하거나 oprofile로 프로파일링을 해서 병목지점을 좁혀간다.

 

이상적인 상태인데 부하가 걸리고 있으면 로직이나 알고리즘의 개선을 통해서 대응

프로그램의 폭주의 경우는 오류를 제거해서 대응한다.

Swap이 많이 발생하는 경우.

3-4. 특정 프로세스가 극단적으로 메모리를 소비하고 있지 않은지를 확인

3-5. 프로그램의 오류로 메모리를 사용하고 있는 경우에는 개선

3-6. 메모리가 부족한 경우 증설, 분산을 검토

 

디스크 입출력이 빈번한 경우에는 캐시에 필요한 메모리가 부족한 경우를 생각.

3-7. 메모리 증설로 캐시영역을 확대시킬 수 있는 경우

3-8. 증설 못하면, 데이터 분산이나 캐시서버 도입 등을 검토

 

4. OS 튜닝이란 부하의 원인을 알고 이것을 제거하는 것.

하드웨어, 소프트웨어가 본래 지닌 성능을 충분히 발휘할 수 있도록 문제가 될 만한 부분이 있다면 제거하는 것. CPU의 계산시간을 이용해서 10초 걸리는 처리는 아무리 OS로 개지랄을 해도 10초 이하로 줄어들 수는 없다.

 

강의6. 규모조정의 요소

규모조정(scaling), 확장성(scalability)

웹 서비스에서는 스케일업보다는 스케일아웃의 전략이 주류이다. 비용이 저렴하고, 시스템 구성에 유연성이 있다는 점이 포인트

규모조정의 요소

하드웨어를 횡으로 전개해서 확장성을 확보해가게 된다. 이때 CPU 부하의 확장성을 확보하기는 쉽다. 프록시나 AP서버가 담당하는 일. DB서버 측면에서는 I/O부하가 걸린다. 이거는 아님.

웹 애플리케이션과 부하의 관계

프록시, AP서버, DB로 구성 돼있다. AP서버의 경우 CPU부하만 걸리므로 분산이 간단하다. 데이터를 분산해서 갖고 있는 것이 아니고, 자신만의 작업만 수행하면 되므로, 서버의 복사본을 마련해서 추가한 후 요청을 균등하게 분산시켜주는 로드밸런서가 작업을 해주면 OK. I/O부하에는 문제가 있다. 데이터의 동기화는 어떻게 할 것인가?

DB 확장성 확보의 어려움

디스크가 느리다는 문제도 영향을 미친다. 대규모 환경에서는 I/O 부하를 부담하고 있는 서버는 애초에 분산시키기 어려운 데다가 디스크 I/O가 많이 발생하면 서버가 금세 느려지는 본질적인 문제가 생긴다. 단순히 서버를 늘려서 해결할 수 있는 문제가 아니다.

두 종류의 부하와 웹 애플리케이션

1. 부하는 CPU, I/O부하로 분류된다.

AP서버는 DB로부터 얻은 데이터를 가공해서 클라이언트로 전달하는 처리를 수행. CPU 바운드한 서버

DB서버는 디스크로부터 검색하는 것이 주된 일로, 대규모가 되면 될수록 CPU에서의계산시간보다도 I/O에 대한 영향이 커지는 I/O 바운드한 서버. 같은 서버라도 부하의 종류가 다르면 그 특성은 크게 달라진다.

2. 멀티태스킹 OS와 부하

실행할 task가 적은 상황에서 OS는 대기를 발생하지 않고 전환하지만, 실행할 태스크가 늘어나면 특정 태스크가 CPU에서 계산을 수행하고 있는 동안, 다음에 계산을 수행하고자 하는 다른 태스크가 CPU에 시간이 날 때까지 대기하게 된다. ‘처리를 실행하려고 해도 대기한다’

Load average: 0.70, 0.66, 0.59는 1분, 5분, 15분 동안에 대기 된 Task의 수

지연이 되는 = 부하가 높은 상황

3. Average가 보고하는 부하의 정체

처리를 실행하려고 해도 실행할 수 없어서 대기하고 있는 프로세스의 수

CPU의 실행권한이 부여되기를 기다리고 있는 프로세스, 디스크 I/O가 완료하기를 기다리고 있는 프로세스 -> 따라서 CPU부하가 생기는지, I/O부하가 생기는지 판단하려면 더 자세하게 조사할 필요가 있다.

 

강의7. 대규모 데이터를 다루기 위한 기초지식

1. 어떻게 하면 메모리에서 처리를 마칠 수 있을까?

디스크 seek 횟수 최소화하기, 국소성을 활용한 분산 실현

 

2. 데이터 증가에 강한 알고리즘을 사용하는 것,

선형검색 -> 이분검색

 

3. 데이터 압축이나 검색기술과 같은 테크닉을 활용

 

프로그램 개발의 전제지식

OS 캐시, 분산을 고려해서 RDBMS를 운용, 대규모 환경에서 알고리즘과 데이터 구조를 사용한다는 것