[대규모 서비스를 지탱하는 기술] I/O 부하를 줄이는 방법

 

1) 캐시를 전제로 한 I/O 줄이는 방법

- 캐시에 의한 I/O 경감 효과는 매우 크다. 

  캐시를 전제로 I/O를 줄이기 위한 대책을 세워가는 것이 유효하다는 것을 알 수 있다.

  이것이 I/O 대책의 기본이다.

  이 기본으로부터 도출할 수 있는 포인트를 두 가지 소개한다.

 

- 첫 번째 포인트는 데이터 규모에 비해 물리 메모리가 크면 전부 캐싱할 수 있으므로 이 점을 생각할 것.

  다루고자 하는 데이터의 크기에 주목하자는 것이다.

 

- 또한, 대규모 데이터 처리에는 데이터 압축이 중요하다고 했는데,

  압축해서 저장해두면 디스크 내용을 전부 그대로 캐싱해둘 수 있는 경우가 많다.

  예를 들어, LZ법 등 일반적인 압축 알고리즘의 경우, 

  압축률은 보통이더라도 텍스트 파일을 대략 절반 정도로 압축할 수 있다. 

  

- 4GB의 텍스트 파일이라면 메모리 2GB인 머신으로 뒷부분 절반 정도는 거의 캐싱할 수 없었던 것이

  압축해서 저장해두면 2GB로 캐싱할 수 있는 비율이 상당히 늘어나게 된다. 

 

- 또 하나는 경제적인 비용과의 밸런스를 고려하고자 한다는 점이다.

  최근에는 메모리가 8GB~16GB 정도가 일반적인 서버 한 대의 메모리 구성이다.

  최근의 서버는 납품될 때, 대체적으로 메모리가 8GB~16GB 정도 탑재되어 있다.

  AP 서버는 메모리가 그렇게 많이 필요하지는 않으므로 4GB 정도지만,  

  DB 서버는 그 정도의 메모리가 탑재되어 있다.

 

2) 복수 서버로 확장시키기 - 캐시로 해결될 수 없는 규모일 경우

- 메모리를 늘려서 전부 캐싱할 수 있다면 좋겠지만,

  당연히 데이터를 전부 캐싱할 수 없는 규모가 될 수가 있다.

  그렇게 되면 어떻게 할 것인가? 

  여기서 먼저 복수 서버로 확장시키는 방안을 생각해볼 필요가 있다. 

 

- AP 서버를 늘려야 하는 이유는 기본적으로 CPU 부하를 낮추고 분산시키기 위해서다.

  한편, DB 서버를 늘려야 할 때는 반드시 부하 때문만은 아니고

  오히려 캐시 용량을 늘리고자 할 때 혹은 효율을 높이고자 할 때인 경우가 많다. 

 

- 따라서 AP 서버를 늘리는 것과 DB 서버를 늘리는 것은 

  둘 다 서버를 늘리는 것이지만, 필요한 리소스, 요구되는 리소스가 전혀 다르다.

  DB 서버는 '늘리면 좋다'라는 논리가 들어맞지 않는다.