스케일 업(scale-up), 스케일 아웃(scale-out) ?
대량의 서비스를 서버 1대로 처리할 수는 없게 됩니다. 더 많은 트래픽을 처리하기 위해서 스케일 업(서버의 성능을 업그레이드하는 것)과 스케일 아웃(서버의 대수를 늘려서 연결하는 것)이 있는데, 일반적으로는 스케일 아웃을 하게 됩니다. 왜냐하면 하드웨어 성능과 가격이 비례하지 않기 때문이죠. 대량생산되는 부품이 훨씬 싸기 때문이죠.
하지만, 스케일 아웃도 단점이 있습니다. 서버의 대수를 늘릴수록 관리가 힘들어지죠. 로드 밸런서로 연결해야 하기 때문에 엔드 포인트가 더 생기고 작업이 복잡해지는 것이죠. DB 동기화도 해야하구요. 동시성 제어도 힘듭니다. 이런 점 때문에 요즘 엔지니어들의 몸값이 비싸지는 것 같아요 !
데이터 처리
데이터는 디스크 -> 메모리 -> 캐시 -> CPU 순으로 흘러가게 되는데, 각 메모리의 속도 차이가 대략 1000배라고 얘기하는 것 같습니다. 그래서 DB를 비롯한 다양한 미들웨어 및 개발 툴도 이를 의식한 데이터구조를 사용하고 있습니다.
그렇다고 하더라도, 데이터량이 엄청 많아지면, 무조건 캐시 미스가 나게 될 것이고, 그러면 속도나 performance를 몇 백만 배, 몇 억배도 손해를 볼 수 있습니다. 그래서 데이터를 어떻게 해야 빨리 찾고, 빠르게 옮길 지 고민하는 것도 대규모 처리에서 중요한 것 같습니다 ! 그래서 최근에는 간단한 알고리즘보다는 복잡하지만, 대규모 데이터를 큰 단위로 처리할 수 있는 알고리즘을 많이 사용하는 추세인 것 같습니다 !
운영, 유지보수
서버 대수가 늘어나면서, 각각의 역할이 다른 서버를 파악하는 것도 곤란해집니다. 각 서버가 처한 상황도 다를 것이고, 전체 서버들이 부하는 문제가 없는지, 고장 난 부분이 없는지, 디스크 용량은 충분한 지, 보안 설정에 미비한 점은 없는지 그런 부분들을 살펴야합니다. 페이스북, 트위터는 데이터 센터 내에서 이동도 자전거, 스쿠터를 타고 이동할 정도라고 하네요. 그래서 감시용 소프트웨어를 사용해서 효율적으로 운용을 하기 위해서 쉘 스크립트를 만드는 등의 노력이 필요합니다.