다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌


[강의31] 계층과 확장성

확장성에 대한 요구 - 서버 1대에서 처리할 수 있는 트래픽 한계

(업데이트가 필요한 정보이다)

  • 이 때 당시에 서버 한대로 처리할 수 있는 트래픽은 월 100만 PV 정도, 최고사양으로 100만 ~200만 까지도 감당할 수 있었다.
  • 수천 ~1만 건/분 정도의 요청을 처리할 수 있는 정도이다.
  • 더 대규모는 서버1대로 동작할 수 없다.

계층별 확장성

  • WAS는 상태를 가지고 있지 않으므로 단순히 대수를 늘리는 것으로 요청을 확장할 수 있다.
  • 로드밸런서에 새로운 서버를 추가하면 된다.
  • DB는 다른 방법으로 (쓰기, 읽기가 나뉘어져 있으므로) 더 많은 요소들을 고려하면서 확장해야한다.

[강의32]부하 파악, 튜닝

부하 파악 - 관리화면 시각화의 중요성

  • 각각의 서버에 관해서 그래프화 하는 것이 중요하다.

부하 측정을 위한 항목

  • Load Average, 메모리, CPU
  • Load Average
    • 대기중인 프로세스의 평균수치
    • 수치가 0에 가까울 수록 좋은 것이며, CPU 코어 수보다 작으면 양호한 것이다.

용도에 맞는 튜닝

  • 책에서 나온 예시의 경우
    • 봇에게 응답하는 것은 응답시간보다 처리량이 중요하므로 처리량에 서버 리소스를 대부분을 쏟고 load average가 평균적으로 높다.
    • 사용자 응답은 응답 시간이 중요하므로 load average를 낮게 유지하고 프로세스를 쌓아두지 않고 잘 응답하는 것을 중요하게 여긴다.
  • 어떤 상황에 어떤 튜닝을 하는지가 운영을 할 때 굉장히 중요하다.

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

  • 사용자용 DB 또한 전체적으로 부하를 낮게 유지함으로 응답을 빠르게 하는 것을 중요하게 생각한다.
  • 상황마다 응답을 중요시할 지, 리소스를 소진하는 것을 중요하시 할지 결정하는 것이 중요하다.
    • 리소스 소진이 정확히 뭘까?
      • CPU utilization을 높게 유지 ?

서비스 규모와 튜닝

  • 부하를 가시화하고 그래프를 겹쳐서 병목이나 이상현상을 파악할 수 있도록 하는 것이 중요하다.

확장성 확보

  • 로드밸러선나 파티셔닝(DB 분할)을 이용한다.