이 글은 절판도서 "웹 개발자를 위한 대규모 서비스를 지탱하는 기술" 을 개인적인 용도로 정리한 글입니다. 모든 내용을 정리한 것이 아니라 필요한 부분만 정리했다는 점 양해 부탁드립니다
문제/오류가 있을 시 댓글로 알려주면 감사하겠습니다
| 확장성 확보에 필요한 사고방식
규모 증대와 시스템 확장
- 부하에 따른 확장 -> 대규모 서비스는 수십 대의 서버로
확장성에 대한 요구
서버 1대에서 처리할 수 있는 트래픽 한계
- 하테나 최근 서비스 중 상당수는 서버 1대로 작동한다
- 하테나 표준 사양은 4core CPU, 8GB 메모리 정도의 서버이며 피크 시 성능이 수천 요청/분 정도 나온다
-> 월 100만 PV(page view)정도 처리 가능하고, 요청이 조금 더 늘어나도 DB 분리 정도로 대응할 수 있다는 것이다 - 하지만 하테나의 경우 한 서비스에서 수억 PV/월 정도의 트래픽이 발생하므로 확장이 필요하다
| 계층과 확장성
계층별 확장성을 살펴본다
- AP 서버는 상태를 갖고 있지 않으므로 요청별로 다른 AP 서버로 날려보내도 처리상 문제가 발생하지 않고, 로드밸런서에 새로운 서버를 추가해가면 점점 확장되어간다
-> 대수만 늘리면 확장이 가능하다 - DB, 파일 서버는 read 분산은 쉽지만 write 분산은 어렵다
부하 파악, 튜닝
| 부하 파악 - 가시화한 관리 화면
- 확장을 위해서는 서버 부하를 파악해야하고, 서버 부하 파악을 위해서는 각각의 부하를 적절하게 그래프화 하는 것이 중요하다
- 하테나에서는 서버관리툴을 이용해 이를 관리한다
| 부하를 관리하기 위한 항목들
- 먼저 Load Average를 본다
- Linux 커널 내에는 프로세스가 다수 동작하고 있고, 이러한 프로세스가 언제든지 동작할 수 있는 상태이지만 아직 실제 CPU가 할당되지 않아 대기상태에 있는 프로세스 수의 평균치가 Load Average이다
- CPU가 깔끔하게 할당되면 이 값이 0에 가까워지고 CPU 코어 수 이하이면 양호한 편이다
- 메모리 사용처
- 사용자 공간이 소비되고 있는 메모리
- 공유되는 메모리
- 커널이 사용하고 있는 버퍼의 메모리 등이 있다
| 용도에 맞는 튜닝 - 사용자용 서버
- 봇은 응답시간이 중요치 않으므로 요청 처리 수를 최대화시키는 방향으로 튜닝한다(Load Average 높음, 6)
- 사용자는 트래픽 부하 변동이 크며, 양호한 응답을 위해 리소스를 소진하기 보다는 처리대기 프로세스를 쌓아두지 않고 양호한 응답을 유지하도록 한다 (Load Average 1~3으로 낮게 유지)
- 봇과 사용자를 분리함에 따라 AP 서버의 튜닝 정책을 변경해서 그 효율을 중시할지, 응답시간을 중시할지, 리소스를 최대한 사용하는 것을 중시하는 쪽으로 운영할 지로 운영방향을 바꿀 수 있다
| AP 서버/DB 서버의 튜닝 정책과 서버 대수
- 용도별로 나눠서 튜닝을 변경함으로써 전체 서버 대수를 줄일 수 있다(DB도 마찬가지)
- 봇용은 부학 높은 것에 비해 사용자용은 부하가 낮게 억제했다
- 사용자용 DB는 전체적으로 부하를 낮게 함으로써 해당 DB 서버로도 질의가 가능한 한 빠르게 반환하도록 한다
- DB도 봇용, 사용자용으로 나눠서 응답을 중요시할지, 리소스를 소진하는 것을 중요시할지로 나눈다
| 서비스 규모와 튜닝
- 서버 용도나 계층에 입각한 튜닝은 서비스별로 수행된다
- 하테나 다이어리에서는 AP 서버를 종류별로 세세하게 나눠놓았다(DB 도 마찬가지)
- 튜닝작업을 반복하다 보면 서버 대수가 늘어났을 때 비정상적인 거동을 하고 있는 서버를 찾을 수 있는 방법을 알아내는 게 과제가 된다
- 부하를 가시화하고 여러 서버의 그래프를 겹쳐봄으로써 병목과 같은 이상현상을 파악할 수 있도록 하고 있다
- OS의 동작원리를 이해하고 적절한 튜닝을 함으로써 서버 성능을 올바르게 끌어낸다
| 확장성 확보
- 로드밸런스를 이용하거나 파티셔닝(DB 분할)을 한다
- 하테나에서는 LVS(Linux Virtual Server)라는 Linux 커널에 포함되어 있는 로드밸런서를 사용하고 있다
나는야 누워있는 개발머신