12. 확장성 확보에 필요한 사고방식
31강. 계층과 확장성
확장성에 대한 요구
하테나의 경우는 한 서비스에 수억 PV/월 정도의 트래픽이 발생합니다. 백만과 억이라는 단위는 두 자릿수 차이가 나므로 이를 어떻게 해서 확장시켜 갈 것인가라는 과제가 되고, 바로 거기에 끊임없이 다양한 기술과 노하우가 파묻혀 있습니다.
계층별 확장성
계층별 확장성 을 살펴보도록 하겠습니다. AP 서버는 기본적으로 그다지 깊은 부분까지 생각하지 않아도 비교적 간단하게 확장시킬 수 있습니다. 그 이유는 AP 서버는 상태를 갖고 있지 않으므로 요청별로 다른 AP 서버로 날려보내도 처리상 문제가 발생하지 않고, 로드밸런서에 새로운 서버를 추가해가면 점점 확장되어 가기 때문입니다. 즉 AP 서버는 대수만 늘리면 얼마든지 확장되는 구성으로 되어 있는 것입니다.
또한 DB나 파일 서버의 경우에는 앞에서 말한 분산, 확장성 확보가 매우 어렵습니다. 데이터 소스로의 요청은 read(읽기)와 write(쓰기), 두 종류로 나뉘는데, read를 분산하는 것은 비교적 용이한 반면, write를 분산하는 것은 매우 어렵게 되어 있습니다.
32강. 부하 파악, 튜닝
부하 파악
어떻게 확장해갈 것인지를 검토하기 위해서는 먼저 서버 부하를 파악할 수 있어야 합니다. 각 서버 부하를 파악하기 위해서는 서버군을 관리하고 각각의 부하를 적절하게 그래프화하는 것이 중요합니다.
부하를 측정하기 위한 항목
부하를 볼 때는 먼저 Load Average부터 봅니다. 앞에서 언급한 대로 Load Average는 중요한 수치입니다. Linux 커널 내에는 프로세스가 다수 동작하고 있습니다. Load Average란 이러한 프로세스가 언제든지 동작할 수 있는 상태이지만, 아직 실제 CPU가 할당되지 않아서 대기상태에 있는 프로세스 수의 평균치입니다.
예를 들면 5분간 Load Average가 1이라고 하면, 5분 동안에 평균 1개의 프로세스가 대기상태로 되어 있다는 것을 의미합니다. CPU가 깔끔하게 할당되면 이 값이 0에 가까워지고, CPU 코어 수 이하이면 양호한 편입니다.
하테나에서는 CPU 코어 수 이하 또는 그 절반과 같이 용도에 따라 임계값은 약간 조정되지만, 대체로 CPU 코어 수 이하에서 절반 정도로 맞춰지도록 제어하고 있습니다.
부하를 측정하기 위한 항목은 Load Average 이외에도 많이 있습니다. 예를 들면 메모리 사용처에 관해서는 사용자 공간이 소비되고 있는 메모리나 공유되고 있는 메모리, 그리고 커널이 사용하고 있는 버퍼의 메모리 등이 있습니다. 이러한 항목을 통해 이런 거동을 하고 있으니 이런 동작을 보이고 있어와 같이 파악함으로써 서버의 성능을 더 끌어내 고성능 시스템을 실현할 수 있게 되는 것입니다.
서비스 규모와 튜닝
서버 용도나 계층에 입각한 튜닝은 서비스별로 수행되고 있습니다. 하테나 다이어리가 현재 서버 대수가 가장 많은데, 다이어리에는 AP 서버가 종류별로 더 세세하게 나뉘어 있습 니다. DB도 북마크보다 더 세세하게 많은 종류로 나뉘어 있으며, 주변에 다른 서버도 그 나름의 서버 대수가 있습니다.
튜닝 작업을 반복하다 보면 서버 대수가 늘어났을 때 비정상적인 거동을 하고 있는 서버를 찾을 수 있는 방법을 알아내는 것이 과제가 됩니다. 그래프를 겹쳐서 1대만 비정상적인 값이 나타났을 경우에 파악하기 쉽도록 하고 있습니다.
확장성 확보
확장성 확보를 위해 로드밸런서를 이용하거나 파티셔닝(DB분할)을 하고 있습니다. 파티셔닝에 대해서는 제4장에서 언급했으므로 다시 떠올려보기 바랍니다.
Wrap Up
대규모 서비스의 확장성은 단순히 서버를 추가하는 문제가 아니라, 계층별로 무엇이 쉽게 늘어나고 무엇이 어려운지를 정확히 구분하는 데서 시작합니다. 특히 AP 서버와 달리 DB나 파일 서버는 write 분산이 어렵기 때문에, 부하를 수치로 파악하고 로드밸런서와 파티셔닝 같은 수단을 적절히 조합해야 합니다.
Summary
대규모 서비스에서는 수억 PV/월 수준의 트래픽을 감당하기 위해 계층별 확장성을 이해해야 합니다. AP 서버는 상태를 갖지 않으므로 로드밸런서 뒤에 서버를 추가하는 방식으로 비교적 쉽게 확장할 수 있지만, DB나 파일 서버는 read와 write의 성격 차이 때문에 확장이 훨씬 어렵습니다. 이런 환경에서 확장 전략을 세우려면 우선 Load Average, 메모리 사용량, 커널 버퍼 같은 지표를 통해 서버 부하를 정확히 파악해야 합니다. 또한 서비스 규모가 커질수록 비정상적인 서버를 그래프에서 빠르게 찾아내는 운영 감각과 튜닝 능력도 중요해집니다. 결국 확장성 확보는 부하를 보면서 로드밸런서와 파티셔닝 같은 기법을 계층별 특성에 맞게 적용하는 과정입니다.