보통 대량의 엑세스가 있는 서비스에서는 서버 1대로 처리할 수 없는 부하를 어떻게 처리할 것인가가 중요. 최근 10년트렌드는 스케일아웃. 스케일 아웃은 서버를 횡으로 전개, 즉 서버의 역할을 분담하거나 대수를 늘림으로써 전체적인 처리능력을 높여서 부하를 분산시키는 방식.
값이 싸고 대량생산되고 있는 일용품 성격의 하드웨어를 횡으로 나열해서 확장성을 확보하는 것이 스케일 아웃.
이러한 스케일 아웃(scale out) 전략에는 비용이 절감되는 반면 다양한 문제 발생.
데이터 동기화
- DB를 분산시켰을 때 한쪽에 저장된 갱신 내용을 다른 한쪽 DB가 알지 못하는 경우
사용자 요청 어떻게 분배 ?
- 로드밸런서 사용, 그러나 로드밸런서는 서버 1대일 때에는 애초에 도입할 필요 x
네트워크 통신의 지연시간을 어떻게 생각 ?
- 작은 데이터라도 이더넷을 경유해서 통신한 경우는 지연시간이 생기고 통신의 오버헤드 생기기 마련.
시스템은 다중성을 지닌 구성, 즉 특정 서버가 고장나거나 성능이 저하되더라도 서비스를 계속할 수 있는 구성을 할 필요.
스케일 아웃을 해서 서버 대수가 늘어나면 고장률도 필연적으로 올라감. 365일 24시간 가동되어야하는 웹 서비스 특성상 고장률이 높고 서비스가 정지되는건 용납할 수 없음. 서버가 고장날 가능성이 높아지거나 부하가 좊아지면 이에 따른 견딜 수 있는 시스템을 구성할 필요가 있음.
웹 서비스는 언제 어떠한 경우라도 고장에 대해 견고해야 한다. 고장나더라도 다른 시스템이 자동적으로 처리를 인계받는 시스템 구축 간에는 기술적으로나 비용면에서 상당히 큰 차이가 있다.
서버가 1대라면 때때로 상태를 확인하는 정도로 서버가 정상적으로 동작하고 있는지를 간단하게 파악 가능. 반면 서버 대수가 100대가 넘어가면 어떤 서버가 무슨 역할을 하고 있는지 기억해두는 것조차 어려움.
각각의 서버에 대해서, 부하는 괜찮은지 고장난 점은 없는지, 디스크 용량은 충분한지 등등 모든 서버를 살피기란 어렵다. 당연히 이쯤에서 감시용 소프트웨어를 사용하고 정보관리 툴을 사용하는 등 자동화를 하게 된다. 그러나 이 감시 소프트웨어를 설치하거나 정보를 보는 것은 결국 인간이다. 일손을 거치지 않고 대규모 시스템을 건강한 상태로 어떻게 유지할 것인가도 중요한 문제이다.
대규모 서비스가 되면 당연히 혼자서는 개발이나 운용이 어려워지므로 여러 기술자가 역할을 분담하게 됨. 개발자 수가 늘어나면 역시나 고려해야할 사항이 많아짐. 라이브러리나 프레임워크를 통일하고, 코딩 규약을 정하고, 소스코드 관리를 버전관리 시스템으로 제대로 하기 등등 여러 사람이 있을 때는 효율이 떨어지는 것이 당연한 것이다. 그리고 개인 혹은 팀의 편차에 따라 잘 지켜지는 개인/팀이 있는 반면 그렇지 않은 팀도 당연히 존재. 이에 따른 팀 매니지먼트가 중요.
이 책에서 가장 중요한 테마인 데이터링이다. (책 제목에서 유추 가능)
컴퓨터는 디스크(HDD)에서 데이터를 로드해서 메모리에 저장, 메모리에 저장된 데이터를 CPU가 패치(fetch)해서 특정 처리 수행. 또한 메모리에서 패치된 명령은 보다 빠른 캐시(cache) 메모리에 캐싱된다. 이처럼 데이터는
디스크 -> 메모리 -> 캐시 메모리 -> CPU
와 같은 몇 단계를 경유해서 처리
각 단계 간에는 속도차가 매우 크게 나는 것이 현대 컴퓨터의 특징. 하드디스크에서 데이터를 읽어들이는 데에는 그 특성상 헤드 이동이나 디스크 원반의 회전이라는 물리적 동작이 수반됨. 따라서 전기적으로 읽어들이기만 하면 되는 메모리나 캐시 메모리와 비교하면 10^6 ~ 10^9배나 되는 속도차 발생.
이 속도차를 흡수하기 위해 OS는 데이터를 메모리에 캐싱해둠으로써 전반적으로 디바이스 간 속도차가 영향을 주지 않도록 하고 있다.
그러나 당연히 한계는 존재한다. 데이터량이 많아지면 처음부터 캐시미스가 많이 발생하게 되고, 그 결과로 저속의 디스크로 I/O가 많이 발생하게 된다. 또한 대규모 웹 애플리케이션을 운용할때 대부분의 어려움은 이러한 대규모 데이터 처리에 집중된다.
데이터가 적을 때에는 특별히 고민하지 않아도 모두 메모리에서 처리할 수 있으며, 복잡한 알고리즘을 사용하기 보다 간단한 알고리즘을 사용하는 편이 오버헤드가 적기 때문에 더 빠른 경우도 종종 있다.
그러나 서비스가 어느 정도 이상이 되면 데이터가 대량으로 증가하고, 이 데이터량이 분수령을 넘어서면 문제가 복잡해짐.
머리속으로 소규모 서비스와 대규모 서비스의 차이점이 흐릿하게만 그려졌던 이전과 달리, 챕터1을 읽고나서 이 둘의 차이가 명확히 선명해졌다. 또한 차이가 발생하는 원인이 무엇이고, 이 원인은 또 다른 결과의 원인이 되거나 새로운 문제의 결과가 되기도 하는 것을 알게 되었다.