이번 장에서는 대규모 데이터란 무엇인가에 대해 생각해본다. 특히 대규모란 어느 정도인가, 소량의 데이터 처리와 무엇이 다른가에 대한 감을 잡아야 할 것이다.
대규모 데이터 처리의 어려운점
메모리 내에서 계산할 수 없다.
- 메모리 내에서 계산할 수 없게 되면 디스크에 데이터를 저장하거나, 디스크에 있는 데이터를 검색할 필요가 있다.
- 하지만 디스크는 느리므로 I/O에 시간이 오래 걸린다.
- 이에 대한 대처방안이 연구대상이다.
메모리는 디스크보다 10^5 ~ 10^6배 빠르다.(10만 ~ 100만배)
메모리 vs 디스크의 탐색 속도 차이
- 디스크 : 헤드의 이동과 원반의 회전이라는 두 가지 물리적인 이동이 필요하고, 데이터가 뿔뿔이 흩어져서 배치되어 있다면 헤드의 잦은 이동과 데이터를 찾기 위한 원반의 많은 회전 등을 이유로 탐색 속도가 메모리에 비해 느리다.
- 메모리 : 메모리에서는 물리적인 동작 없이 실제 데이터 탐색 시의 오버헤드가 거의 없다. 또한 전기적인 물품으로 물리적인 구조와는 크게 상관이 없어 속도에 크게 영향을 주진 않기에 디스크에 비해 빠름.
OS 레벨에서의 연구
디스크를 회전시킬 떄에는 OS단에서 비슷한 데이터들은 비슷한 곳에 혹은 비슷한 위치에 연속된 데이터를 쌓는다. 또한 1Byte씩 읽는게 아니라 4KB정도를 한꺼번에 읽을 때도 있다.
그러나 전기적인 물품인 메모리는 탐색시 마이크로초 단위로 걸리는 반에 이러한 노력에도 불구하고 수밀리초가 걸린다.
전송 속도, 버스의 속도차
메모리나 디스크 모두 CPU와 버스로 연결되어 있다. 여기서 주의할 건, 탐색과 전송의 차이이다. 앞서 기재한 내용들은 전부 탐색에서의 속도 차이. 그러나 이번은 전송 속도이다. 찾은 데이터를 디스크에서 메모리로 보내거나, 메모리에서 CPU로 보내는 등 컴퓨터 내부에서 전송하기 위한 속도이다.
애초에 메모리와 CPU는 7.5GB/sec 정도 나오는 빠른 버스로 연결되어 있는 반면, 디스크는 58MB/sec 정도 나오는 비교적 느린 버스로 연결되어 있다. 이에 대한 차이는 100이상 나는 차이이다.
규모조정의 요소
앞서 다룬 내용들이 시스템 전체의 확장성 전략에 어떤 영향을 줄지에 대해 살펴볼 것이다.
대규모 환경이라고 하면 서버를 여러 대 나열해놓고 그 서버로 부하를 분산한다라는 얘기를 들어봤을 것이다. 웹 서비스에서 자주 거론되는 규모조정(scaling) , 확장성(scalability)의 이야기이다.
규모조정, 확장성
웹 서비스에서는 고가의 빠른 하드웨어를 사서 성능을 높이는 스케일업(scale-up) 전략보다도 일반적인 성능의 하드웨어를 많이 나열해서 시스템 전체 성능을 올리는 스케일아웃(scale-out) 전략이 우세하다.
그 이유는 웹 서비스에 적합한 형태 + 저렴한 비용 + 유여한 시스템 구성.
규모조정의 요소 - CPU 부하와 I/O 부하
스케일아웃은 하드웨어를 나열해서 성능을 높이는, 즉 하드웨어를 횡으로 전개해 확장성을 확보한다.
이때 CPU 부하의 확정성을 확보하기는 쉽다.
그러나 DB서버 측면에서는 I/O 부하가 걸린다.
보통의 웹 애플리케이션에서는 3단구조 (프록시, AP서버, DB)가 있다. 이 때, 프록시나 AP서버에 들어온 요청은 CPU 부하만 걸리므로 분산이 간단하다. 데이터를 분산해서 갖고 있는 것이 아니므로 호스트가 동일하게 작업을 처리하기만 하면 분산가능. 이러한 요청을 균등하게 분산하는 것은 로드밸런서(load balancer) 라는 장치가 해준다. 이에 만해, DB의 요청이 들어오면 동등하거나 동일하게 복사되어있는 여러대의 DB가 있다하더라도 A라는 DB와 B라는 DB가 어떻게 동기화 할 것인가에 대한 문제가 생겨 간단히 분산할 수가 없다.
DB 확장성 확보의 어려움
