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


어느 정도가 대규모 인가 ?

이것은 이 책이 쓰여졌을 당시의 상황이다. 전혀 감이 없으니 이때 당시의 대규모 정도를 숫자로 파악해보자.

  • 등록 사용자 100만 명 이상, 1500만 UU
  • 서버 500대 이상
  • 피크시 회선 트래픽 430Mbps

[강의1]

소규모 서비스와 대규모 서비스의 차이

확장성 확보, 부하분산 필요

1대의 서버로 처리 할 수 없는 부하를 어떻게 처리할 것인가 ?

  • 스케일 아웃 → 서버 대수를 늘림으로 스스템 처리능력을 높임
  • 스케일 업 → 하드웨어 성능을 높여 처리 능력을 끌어올림

여러대의 서버를 사용했을 때 파생되는 문제

  • 데이터 동기화, 네트워크 통신 지연시간,

다중성 확보

  • 특정 서버가 고장이 나도 서비스를 계속 할 수 있어야 함
  • 스케일아웃은 서버의 고장율이 올라가고 하나가 고장났다고 전체가 정지해버릴 순 없다.
  • 시스템이 고장나면 다른 시스템이 자동으로 처리를 인계받는 시스템 설계가 필요

효율적 운용 필요

  • 서버의 상태를 확인하고, 부하, 헬스, 디스크 용량, 보안 등을 체크할 수 있어야한다.
  • 여러대의 서버일 경우 효율적으로 운용하기 어려움.

개발자 수, 개발방법의 변화

  • 여러 사람이 개발을 하게 되면서 개발 표준화는 어떻게 해야하나, 컨벤션, 언어 통일, 라이브러리, 프레임워크 통일 등등의 표준화가 필요

대규모 데이터량에 대한 대처

  • 데이터 처리 과정
    • 디스크 → 메모리 → 캐시 메모리 → CPU
  • 디스크와 CPU에서의 속도차이는 엄청나다
  • 미들웨어, 케싱등을 사용해서 데이터 처리 속도를 향상시키곤 한다.
  • 하지만 대규모 서비스에서는 한계가 있다.
    • 데이터가 많아지면 캐시 미스가 많이 발생
    • 그러므로 디스크 I/O 가 많아져서 속도가 저하됨
  • 소규모 서비스에서는 큰 문제가 아니지만 데이터량이 기하급수적으로 많으면 문제가 복잡해짐

[강의2]

웹 서비스의 어려움

  • 게속 점진적으로 성장해가기 때문에 운영 환경에 변화를 야기한다.

하테나의 예시

  • 트래픽이 많아지고 서버를 데이터 센터로 이전
  • 이전하며 부하 상황정리
    • 병목지점 측정
    • I/O 부하가 높은 서버는 메모리 중시
    • CPU 부하가 높은 서버는 CPU를 중시 등으로 최적 구성으로 하드웨어 배치
    • 로드밸런서로 다중화
  • 성급한 최적화가 좋은 건 아니다. 낮은 확률에 지나친 비용을 쏟아야 한다. 하지만 너무 불완전해서는 안된다.