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


[강의4]

어느정도가 대규모 데이터인가 ?

이때 당시의 수치임을 감안하고 보자 !!

  • 하테나의 경우
    • 레코드 건수 1500만, 5000만
    • entry 테이블이 3기가, bookmark 데이블이 5.5기가 등등
    • html 텍스트 데이터 압축 후 200 기가
    • 이정도가 중규모 ~ 대규모
    • 디비 규모가 기가바이트면 굉장히 많은 것이다.
    • 인덱스 사용 안했을 때 1건 검색시 200초 소요

[강의5]

대규모 데이터는 어떤 점이 어려운가

  • 한마디로 말하면 ‘메모리 내에서 계산할 수 없다’
  • 데이터가 너무 많으면 메모리 내에서 계산할 수 없으므로 디스크를 검색하면 읽어야하는데 디스크를 읽는 것은 계산량도 지나치게 많아지고 시간도 많이 소요된다. (I/O 시간)
  • 메모리와 디스크 속도 차이는 10만 ~ 100만배 정도

디스크는 왜 늦나

  • 디스크의 경우 헤드의 이동과 원반의 회전이라는 두 가지 물리적인 이동이 수반되며 속도가 저하된다.
  • 하지만 OS레벨에서 이것을 어느정도 커버하기 위해서 연속된 데이터를 같은 위치에 쌓고, 데이터를 여러 바이트씩 한꺼번에 읽도록 한다.
    • 이렇게 하면 한번의 디스크 회전으로 읽을 수 있는 데이터가 많으며 회전횟수를 최소화 할 수 있다.
  • 전송속도, 버스의 속도차도 있다.
    • SSD는 물리적이 회전이 아니므로 탐색이 더 빠르긴 하다. 하지만 여전히 버스 속도로 인해 메모리 만큼 빠르지는 않다.
    • 디스크와 메모리의 속도차를 생각하며 설계하는 것이 중요하다.

Linux 단일 호스트의 부하

  • 단일 서버의 성능을 충분히 끌어내는 것을 시작으로 복수 서버에서 부하분산이 의미를 갖는다

  • 추측하지 말고 계측!! 서버의 리소스를 정확히 파악하고 부하를 계측하는 것이 필요하다.

  • 병목 규명작업 기본적인 흐름

    • Load Average 확인
      • top, uptime 등의 명령어로 확인
      • 시스템 전체의 부하 상황을 나타내는 지표
      • 여기를 시초로 병목지점을 찾아나가야한다.
      • Load Average가 낮은데 전송량이 오르지 않다면 소프트웨어 설정, 오류, 네트워크, 호스트 문제 쪽일 가능성이 높음
    • CPU, I/O 중 병목 원인 조사
      • Load Average가 높다면 둘 중 어디에 원인이 있는지 규명
      • sar, vmstat으로 시간 경과에 CPU 사용률, I/O 대기율 추이 확인

  • CPU부하가 높을 경우 핸들링 루틴

    • 어플리케이션의 처리가 병목인지, 시스템 프로그램이 원인인지 top, sar로 확인
    • ps로 프로세스 상태, CPU 사용시간 보며 원인 프로세스 찾기
    • 프로세스 찾은 후 strace로 해당 프로세스 추척, oprofile로 프로파일링

  • 주로 CPU 부하가 높은 경우

    • 디스크나 메모리 용량에서 병목이 되지 않는 이상적인 상태
      • 서버 증설, 프로그램 로직, 알고리즘 개선 필요
    • 프로그램이 폭주해서 CPU에 필요이상의 부하가 걸리는 경우
      • 오류를 제거하여 프로그램 폭주를 방지

  • I/O 부하가 높은 경우

    • 프로그램 입출력이 많아서 부하가 높거나
    • 스왑이 발생해서 디스크 액세스가 발생
    • sar , vmstat으로 스왑 발생상황 확인
    • 스왑이 발생하고 있다면 다음과 같이 조사
      • 특정 프로세스가 극단적으로 메모리를 소비하고 있는지 ps로 확인
      • 프로그램의 오류로 메모리 소비시 프로그램 개선
      • 메모리 부족한 경우 메모리 증설, 또는 분산
    • 스왑이 아닌데 디스크로 입출력이 빈번하다면 캐시에 필요한 메모리 부족한 경우
      • 메모리 증설로 캐시 영역 확대
      • 또는 데이터 분산이나 캐시서버 도임

  • OS 튜닝이랑 부하의 원인을 알고 제거하는 것이다 !!!

    • 튜닝은 성능을 몇배씩 키워주는 것보다 ‘병목이 생기면 알아내고 제거하는 것’이다.
    • 본래 하드웨어가 가지고 있는 성능 이상을 내기는 어렵다. (그냥 하드웨어를 더 좋은걸 써야함)

  • I/O 성능 개선을 위해서는 다음을 고려해야한다.

    • 메모리 증설해서 캐시영역 확보할 수 있는지
    • 데이터량이 너무 많지 않은지
    • 어플리케이션의 I/O 알고리즘을 변경해야하는지

[강의6] 규모조정의 요소

규모조정, 확장성

  • 앞에서 이야기한 대규모 데이터가 시스템 전체의 확장성 전략에 어떠한 영향을 주나
  • 웹 서비스에서는 스케일업 보다 스케일아웃 전략이 주류이다.
    • 웹 서비스에 적합하고 비용이 저렴, 시스템 구성에 유연함

규모조정의 요소 - CPU 부하와 I/O 부하

  • 스케일아웃으로 CPU 부하분산의 확장성 확보는 쉬움
  • DB 서버에서는 I/O 부하가 걸린다.

웹 어플리케이션과 부하의 관계

  • WAS는 CPU부하만 걸린다.
    • 서버를 늘리면 확장이 가능
    • 로드밸런서 장치 활용
  • DB에서 I/O 부하 문제 발생
    • 여러 DB 서버를 두었을 때 동기화가 이슈가 됨

DB 확장성 확보 어려움

  • 디스크 속도 저하의 문제가 여기에 영향을 미침
  • DB에서 디스크 많이 사용 → 데이터가 커지면 메모리에서 처리하지 못하고 디스크에서 처리할 수밖에 없음
  • 서버를 늘려서 해결할 수 없는 문제다.

+ 두 종류의 부하와 웹 어플리케이션

  • CPU 부하
  • I/O 부하

WAS는 CPU 바운드한 서버, DB는 I/O 바운드한 서버이다.

멀티태스킹 OS와 부하

  • 멀티태스킹으로 태스크를 처리하면서 태스크가 대기하게 된다.
  • top 명령어의 load average에 단위 시간당 대기된 태스크의 수, 즉, 평균 어느정도 태스크가 대기상태로 있었는지 보여준다.
    • 높은 숫자는 태스크 실행에 대기가 발생한다는 표시 → 부하가 높은 상황

위 부하의 정체

  • 하드웨어는 CPU 인터럽트로 주기적 신호를 보내서 실행 중인 프로세스가 CPU를 얼마나 사용했는지 계산한다. 이 타이머 인터럽트마다 Load Average 값이 계산된다.
  • 타이머 인터럽트 때 실행 가능 상태인 태스크(가용 가능한 CPU가 없어서 대기중인 프로세스)와 I/O 대기인 태스크의 개수를 세어서 단위시간으로 나눈 값으로 load avarage를 측정한다.
    • 처리를 실행하려고 해도 실행할 수 없어서 대기하는 프로세스의 수
  • 이 값으로 부하 정도를 알 수 있고 CPU 부하인지 I/O 부하인지 판단하기는 어려워서 더 자세히 규명해야 한다.

[강의7]

대규모 데이터를 다루는 두가지 관점

  1. 프로그램을 작성할 때의 요령
  2. 프로그램 개발의 근간이 되는 기초라는 점에서 전제로 알아두면 좋은 것

대규모 데이터 3가지 중요점 - 프로그램 작성시 중요

  • 어떻게 메모리에서 처리를 마칠 수 있을까
  • 데이터량 증가에 강한 알고리즘 (효율적인 탐색 알고리즘)
  • 데이터 압축이나 검색기술과 같은 테크닉 활용
    • 압축하면 메모리에 캐싱하기 쉬움
    • 확장성 면에서 DB에 맡겨서 해결될 수 없을 때 검색엔진을 만들어서 속도를 확보할 수 있음

대규모 데이터 다루기 3대 전제지식 - 프로그램 개발 기초

  • OS 캐시
  • 분산 고려 RDBMS
  • 대규모 환경에서 알고리즘과 데이터구조 사용

+ Load Average 다음에 CPU 사용률과 I/O 대기율

  • sar(System Activity Reporter) 명령어로 CPU 대기율, I/O 대기율 확인
    • Load average가 높고 sar의 %user, %system CPU 사용률 수치가 높으면 부하 원인이 CPU 리소스 부족
    • Load average가 높고 sar의 %iowait CPU 사용률 수치가 높으면 부하 원인이 I/O
  • 여기까지 알았다면 더 자세히 보기 위해 메모리 사용률, 스왑 발생 상황을 들여다본다.
  • 멀티 CPU 인 경우 더 자세히 볼 필요가 있다.
    • sar -p 옵션으로 여러 CPU 사용시 각 CPU의 지표를 볼 수 있다.
    • I/O의 경우 전체 CPU의 %iowait의 지표는 높지 않을 수 있으나 각 CPU의 지표를 보았을 때 특정 CPU의 지표가 높을 수 있다.
    • 이는 멀티 CPU 이더라도 디스크는 하나밖에 없는 경우 I/O 부하가 분산되지 않기 때문이다.