Chapter 12. 확장성 확보에 필요한 사고방식 (강의31 ~ 32)

강의31. 계층과 확장성

확장성에 대한 요구

상당수의 서비스가 서버 1대로 동작한다.

한 서비스가 수억 PV/월 정도로 트래픽이 발생하면 어떻게 해서 확장시켜 갈 것인가라는 과제가 되고, 거기에 끊임없는 다양한 기술과 노하우가 파묻혀 있다.

계층별 확장성

AP서버는 기본적으로 간단하게 확장시킬 수 있다. AP서버는 상태를 갖고 있지 않으므로 요청별로 다른 AP서버로 날려보내도 처리상 문제가 발생하지 않고, 로드밸런서에 새로운 서버를 추가해가면 점점 확장되어 간다. 대수만 늘리면 된다.

DB나 파일 서버의 경우에는 분산, 확장성 확보가 어렵다. Read, write 두 종류의 요청이 있는데 read는 비교적 확장, 분산이 쉽지만 write를 분산하는 것은 어렵다는 것을 위에서 계속 말했음.

 

(복습) 단순히 대수만 늘려서는 시간이 지나면 같은 병목현상이 발생한다.

1. 엑세스 패턴에 따른 분산(국소성을 이용한다)

2. 요청패턴을 ‘섬’으로 분할 (요청 패턴에 따라서 AP, DB를 전체로 묶어서 분산한다)

3. DB서버를 Master-slave로 나누어서 Master는 write, slave는 read를 담당하고 write후 데이터를 동기화.

강의32. 부하 파악, 튜닝

부하 파악

확장을 검토하기 위해서는 서버 부하를 파악할 수 있어야한다. 각 서버 부하를 관리하고, 적절하게 시각화 하는 것이 중요하다.

부하를 측정하기 위한 항목

먼저 Load Average를 본다. 프로세스는 언제든지 동작할 수 있지만, CPU를 할당 받지 않아서 대기하고 있는 프로세스의 평균치. 메모리 사용처에 관해서는 사용자 공간이 소비되고 있는 메모리나 공유되고 있는 메모리, 커널이 사용하고 있는 버퍼의 메모리 등이 있다.

용도에 맞는 튜닝 – 사용자용 서버, 봇용 서버

‘하테나’에서는 사용자, 봇용으로 AP서버를 나눈다. 봇용 서버는 응답시간이 그다지 중요하지 않으므로 요청 처리 수를 최대화시키는 방향으로 튜닝했으며, 실제 Load Average도 높게 나타난다. 시용자용 서버는 사용자의 활동에 따라 부하가 변동하고 트래픽에 따라 부하가 변동한다. 심야 시간대에는 떨어지고 낮에는 높고 밤에는 피크 시간대에 더 높게 나타나는 경향이 있다. 사용자용 서버는 양호한 응답을 유지하는 방향으로 튜닝을 한다.

AP서버를 분리함에 따라 튜닝 정책을 변경해서 그 효율을 중시할지, 응답시간을 중시하는 쪽으로 이끌어갈지, 리소스를 최대한 사용하는 것을 중시할지 운영방향을 나눌 수 있다.

AP 서버/DB 서버의 튜닝 정책과 서버 대수

위의 내용은 용도별로 튜닝을 변경함으로써 전체 서버 대수를 줄일 수 있게 된다는 이야기다.

DB도 같은 느낌으로 응답을 중요시할지, 리소스를 소진하는 것을 중요시할 지로 나누면 된다.

서비스 규모와 튜닝

서버 대수가 늘어났을 때 비정상적인 거동을 하고 있는 서버를 찾을 수 있는 방법을 알아내는 게 과제가 된다. “30대 중 1대에 이상이 발생했을 때 해당 서버를 어떻게 파악할 수 있을까”가 과제다.

튜닝

-> 부하 파악 -> 자체제작 서버 관리 툴

-> 상태 감시

-> 부하를 가시화해서 병목이나 이상현상을 빠르게 파악할 수 있도록 한다.

-> OS의 동작원이를 알고 서버 성능을 올바르게 이끌어낸다.

확장성 확보

확장성 확보를 위해 로드밸런서를 이용하거나 파티셔닝(DB분할)을 한다. ‘하테나’에서는 LVS라는 Linux 커널에 포함되어 잇는 로드밸런서를 사용하고 있다.