[대규모서비스] [책] 12 장 확장성 확보에 필요한 사고방식

목차

• 계층과 확장성
• 부하파악, 튜닝
  • 부하파악 : 가시화
  • 부하를 측정하기 위한 항목 : Load Average, 메모리 관련, CPU 관련
  • 용도에 맞는 튜닝 - 사용자용 서버, 봇용 서버
  • 튜닝 및 확장성 확보

계층과 확장성

확장성에대한 요구

• 서버 1대로 작동하는 서비스가 다수
  • 하테나 표준 서버 (4 core CPU, 8 GB 메모리) 예시
    • 피크 시 성능은 수천 요청/ 분 → 월 100 만 page view 처리 가능
  • 고성능 서버 (4 core CPU 2개, 32 GB 메모리)
    • 피크 시 : 월 200 만 page view 처리가능
• 하테나에서 수억 page view / 월
  • 대규모 서비스는 서버 1대로는 동작할 수 없다.

계층별 확장성

• AP 서버 ▶ 비교적 간단하게 확장가능
  • 구성이 동일하고 상태를 갖지 않기 때문
• DB / 파일 서버 ▶ 분산, 확장성 확보가 어려움
  • read 분산 : 비교적 용이  ▶ 메모리를 많이 탑재, 기타
  • write 분산 : 매우 어려움

→ AP 서버 와  데이터 소스를(DB / 파일 서버) 구분해서 확장을 고려해야 한다.

부하 파악,  튜닝

부하파악 - 가시화

어떻게 서버를 확장할 것인지를 검토하기 위해서는 먼저 서버 부하를 파악할 수 있어야 한다.

 

서버군을 관리하고 각각의 부하를 적절하게 그래프화하는 것이 중요

 

하테나 북마크 예시

서버의 역할을 나열하여 관리하는 화면

 

부하를 측정하기 위한 항목 - Load Average,  CPU 관련, 메모리 관련

 

가장먼저 Load Average 확인

*Load Average ?
     프로세스가 언제든지 동작할 수 있는 상태이지만, 아직 실제 CPU가 할당되지 않아서 대기상태에 있는 프로세스의 수의 평균치
    (ex) 5분 동안 Load Average가 1이면 => 5분동안 평균 1개의 프로세스가 대기상태로 되어 있다는 의미, 이때 CPU의 코어 수 이하이면 부하가 양호한 편 (보통 CPU의 코어 수 이하에서 절반 정도로 맞춰지도록 제어함)

 

메모리 사용처 확인

 사용자 공간이 소비되고 있는 메모리나 공유되고 있는 메모리, 그리고 커널이 사용하고 있는 버퍼의 메모리

이런 항목을 통해 ▶ " 이런 거동을 하고 있으니 이런 동작을 보이고 있어" 와 같이 파악 ▶ 서버의 성능을 더 끌어내 고성능 시스템을 실현

 

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

 

서버 분리

• 봇용 : 응답시간이 중요하지 않음 → 요청 처리 수를 최대화시키는 방향으로 튜닝 가능
• 사용자용 : 응답시간 중요 → 처리대기 프로세스를 쌓아두지 않고 양호한 응답을 유지하는 방향으로 튜닝 가능

봇과 사용자를 분리하여 AP 서버의 튜닝 정책을 변경해서

• 효율을 중시할지
• 응답시간을 중시할지
• 리소스를 최대한 사용하는 것을 중시할지

결정하여 운영방향을 나눌 수 있다.

 

DB 도 사용자용과 봇용으로 나눠서 응답을 중요시할지, 리소스를 소진하는 것을 중요시할지 나누어서 운영할 수 있다.

 

튜닝 및 확장성 확보

 

튜닝

• 부하파악, 상태 감시 : 서버관리툴
• 부하를 가시화해서 병목이나 이상현상을 파악할 수 있도록 한다.
  • 여러 서버의 그래프를 겹쳐봄으로써 병목이나 이상현상 파악가능
• OS의 동작원리를 알고 서버 성능을 올바르게 끌어내기 

확장성 확보

• 로드밸랜서이용
• 파티셔닝(DB분할)