대규모 데이터 처리의 어려운 점

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

• 확장성 확보, 부하분산 필요
• scale-out : 서버 역할을 분담 or 대수를 늘림 → 부하분산
  • 하드웨어를 횡으로 나열해 확장성 확보(하드웨어의 성능 가격에 비례 X)
  • 웹 서비스에 적합한 형태 + 비용 저렴 + 시스템 구성에 유연성
  • 요청을 어떻게 분배할 지? 데이터 동기화는 어떻게 할 지?
  • 다중성 확보, 고장에 견고해야 : 특정 서버가 고장나거나 성능이 저하되어도 서비스를 계속할 수 있도록
  • 단점
    • 서버 대수가 늘어나면 서버의 고장률도 필연적으로 올라감
    • 어떤 서버가 무슨 역할을 하고 있는지 파악하기 어려움 → 감시용 소프트웨어/정보관리 툴 사용(효율적 운용 필요)
    • 대규모 서비스가 되면 여러 기술자가 역할 분담해야함 → 표준화하가 쉽지 않음(팀 매니지먼트가 필요해짐)
• scale-up : 하드웨어의 성능을 높임 → 처리능력 끌어올림

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

• 컴퓨터는 데이터를 디스크 → 메모리 → 캐시 → CPU 의 단계를 경유해서 처리
• 이때 각 단계 간 속도차가 매우 크게 나는 것이 현대 컴퓨터의 특징 ex) 하드디스크는 데이터를 읽어들일 때 헤드 이동/디스크 원반의 회전이라는 물리적 동작 수반 → 캐시메모리의 $10^6$~ $10^9$배 속도차
• 속도차를 흡수하기 위해 OS가 여러 방법 사용 ex) 데이터를 메모리에 caching
• 데이터량이 많아지면 cache miss가 많이 발생 → 디스크로의 I/O 발생(해당 작업 완료될 때까지 다음 처리 수행 X)

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

• 메모리 내에서 계산할 수 없다!
• 메모리 내에서 계산이 할 수 없게 되면, 디스크에 있는 데이터를 검색할 필요 있음
• 디스크는 속도가 느리기 때문에 I/O에 시간이 걸림 → 이를 어떻게 대처할 것인가?

메모리와 디스크의 속도차

메모리는 디스크보다 10만~100만 배 이상 빠름

그렇다면 디스크는 왜 늦을까?

• memory는 전기적 부품 → 물리적 구조가 속도와 그다지 관계 없음
• 디스크의 경우 헤드의 이동과 원반의 회전이라는 두가지 물리적인 이동이 필요
• 메모리의 경우 물리적인 동작이 없어 오버헤드 거의 X

OS 레벨에서의 연구

데이터를 1바이트씩 읽는게 아니라 4KB 정도를 한꺼번에 읽어 디스크의 회전횟수를 최소화

전송속도, 버스의 속도차

메모리와 디스크 모두 CPU와 버스로 연결되어 있음

전송 속도? 메모리/디스크→CPU 와 같이 컴퓨터 내부에서 전송하기 위한 속도

→ 메모리-CPU는 상당히 빠른 버스로 연결되어 있어 7.5GB/s 정도 나옴

→ 디스크-CPU는 58MB/s로 느린 편

최근 SSD가 나와 물리적인 회전이 아닌 방식을 사용하기도 하지만, 탐색 속도는 빠르지만 버스 속도가 병목되거나, 그 밖에 구조에 기인하는 면이 있음

병목 규명작업의 기본적 흐름

1. Load Average 확인
   • 시스템 전체의 부하상황을 나타내는 지표
   • top 나 uptime 등의 명령으로 확인 가능
   • 병목의 원인이 어딘지를 판단할 수는 없음
   • Load Average는 낮은데 시스템 전송량이 낮은 경우? 소프트웨어의 설정이나 오류, 네트워크, 원격 호스트 측 확인해봐야함
2. CPU, I/O 중 병목 원인 조사
   • sar 혹은 vmstat 명령어를 통해 시간 경과에 따른 I/O 대기율이나 CPU 사용률 추이 확인
   • CPU 부하가 높은 경우?
     1. 사용자 프로그램의 처리가 병목인지, 시스템 프로그램이 원인인지 확인(sar or top 사용)
     2. 원인이 되는 프로세스 찾음(ps 사용)
     3. 추적 및 프로파일링을 해서 병목 지점 좁혀감(strace or oprofile 사용)
   • 일반적으로 CPU 부하가 걸리는 경우는,
     1. 메모리/디스크 용량 이외에는 병목되지 않은 이상적인 경우 : 시스템 전송량에 문제가 있을 경우 서버 증설이나, 프로그램 로직/알고리즘 개선해 대응
     2. 프로그램이 폭주해 CPU에 필요 이상의 부하가 걸리는 경우 : 오류 제거해 프로그램 폭주하지 않도록 대처
   • I/O 부하가 높은 경우는,
     1. 프로그램으로부터 입출력이 많아 부하가 많거나 스왑이 발생해 디스크 액세스가 발생하고 있는 경우가 대부분 → sar or vmstat 로 스왑의 발생상황 확인해 문제 가려냄
        • 특정 프로세스가 극단적으로 메모리 소비하고 있지 않은지 ps 명령어로 확인
        • 프로그램 오류로 메모리를 많이 사용하고 있는 경우 프로그램 개선
        • 탑재된 메모리가 부족한 경우에는 메모리 증설(증설이 어려운 경우 분산 검토)
     2. 캐시에 필요한 메모리가 부족한 경우
        • 메모리 증설로 캐시 영역 확대할 수 있는 경우 메모리 증설
        • 메모리 증설로 대응할 수 없는 경우, 데이터 분산이나 캐시 서버 도입 등 검토 (+ 프로그램 개선해 I/O 빈도 줄이기도 검토)
   • I/O 성능을 개선하기 위해서는 아래의 것들을 규명해야 함
     1. 메모리 증설해 캐시 영역을 확보함으로써 대응할 수 있는가
     2. 원래 데이터량이 너무 많지 않은가
     3. 어플리케이션 측의 I/O 알고리즘을 변경할 필요가 있는가

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

 

 

 

** '대규모 서비스를 지탱하는 기술' 책을 읽고 작성한 글 입니다.