대규모 서비스를 지탱하는 기술, 5강 대규모 데이터 처리의 어려운 점 요약

대규모 서비스를 지탱하는 기술, 5강 대규모 데이터 처리의 어려운 점 요약

디스크는 왜 메모리보다 느린가

• 물리적인 장치를 통해 데이터를 찾아나간다.
  • 원반을 돌리거나 디스크 헤드를 이동시켜서 데이터를 찾아낸다.
• 메모리는 전기적 신호를 사용한다.
  • SSD 는 이전의 디스크 역할을 하지만 전기적 신호를 이용하는 디스크이다.
• 메모리와 디스크의 전송 속도는 100배 이상 차이가 난다.
  • 메모리 7.5GB/s
  • 디스크 58MB/s
  • (2008년에 발간된 책이라 현재는 어떨지 잘 모르겠다.)

OS 레벨에서의 해결책

• 자주 같이 쓰이는 데이터를 몰아놓는다.
  • 한번 읽을 때 4KB 정도의 주변 데이터를 같이 읽는다.

단일 호스트 부하 개선 팁

• 단일 서버의 성능을 최대한 끌어내야 복수 서버에서의 부하 분산이 의미를 갖는다.

추측하지 말라, 계측하라

• You can only manage what you can measure

병목 규명 작업의 흐름

• Load Average 확인
• CPU, I/O 중 병목 원인 확인

Load Average 확인

• Load Average 가 높다면 어디선가 병목이 걸리는 것이다.
• Load Average 가 낮은데 시스템의 전송량이 오르지 않는 경우엔 소프트웨어 설정 오류, 네트워크, 원격 호스트 측에 원인이 없는지 확인해봐야 한다.

CPU, I/O 중 병목 원인 확인

• OS 별로 이용되는 CPU 사용률과 I/O 대기율의 추이를 확인할 수 있는 명령어를 이용해 병목을 확인한다.

CPU 부하가 높은 경우

• 사용자 프로그램 처리가 병목인지, 시스템 프로그램이 병목인지 확인해야 한다.
• ps 명령어 등으로 원인이 되는 프로세스를 찾는다.
• strace 로 추적하거나 oprofile 로 프로파일링해서 병목 지점을 좁혀나간다.

디스크로의 입출력이 빈번하게 발생하는 경우

• 메모리 증설로 캐시 영역을 확대할 수 있다면 메모리 증설을 고려해본다.
• 메모리 증설이 불가능하다면, 데이터 분산, 캐시 서버 도입 등을 검토한다.
  • 프로그램을 개선해서 I/O 빈도를 줄일 수도 있다.

OS 튜닝에 대해

• 튜닝은 '병목이 발견되면 이를 제거하는' 작업이다.
• 본래 하드웨어나 소프트웨어가 지니고 있는 성능 이상의 성능을 내는 것은 불가능하다.
• '하드웨어/소프트웨어가 본래 지닌 성능을 충분히 발휘할 수 있도록 문제가 될만한 부분이 있다면 제거하는 것'이다.
• 최근의 OS 들은 OS 튜닝이 필요 없는 경우가 많다.
  • CPU 의 계산으로 10초 걸리는 처리는 아무리 OS 설정을 만진다고 해도 10초 이하로 줄어들 수 없다.
    • 이것을 정체되지 않은 고속도로의 예라고 한다.

I/O 성능 개선을 위해 규명할 것

• 메모리를 증설해서 캐시 영역을 확보함으로써 대응할 수 있는가
• 원래 데이터량이 너무 많지는 않은가
• 애플리케이션 측의 I/O 알고리즘을 변경할 필요가 있는가

규명을 하면, 원인에 대한 대응 방법은 자명해지고 이를 실천하는 것이 튜닝이다.