대규모 서비스를 지탱하는 기술, 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초 이하로 줄어들 수 없다.
- 이것을 정체되지 않은 고속도로의 예라고 한다.
- CPU 의 계산으로 10초 걸리는 처리는 아무리 OS 설정을 만진다고 해도 10초 이하로 줄어들 수 없다.
I/O 성능 개선을 위해 규명할 것
- 메모리를 증설해서 캐시 영역을 확보함으로써 대응할 수 있는가
- 원래 데이터량이 너무 많지는 않은가
- 애플리케이션 측의 I/O 알고리즘을 변경할 필요가 있는가
규명을 하면, 원인에 대한 대응 방법은 자명해지고 이를 실천하는 것이 튜닝이다.
반응형
'인프라 > 대규모 서비스를 지탱하는 기술' 카테고리의 다른 글
대규모 서비스를 지탱하는 기술, 7강 대규모 데이터를 다루기 위한 기초 지식 요약 (0) | 2023.06.23 |
---|---|
대규모 서비스를 지탱하는 기술, 6강 규모 조정의 요소 요약 (0) | 2023.06.23 |
대규모 서비스를 지탱하는 기술, 4강 대규모 데이터란 요약 (0) | 2023.06.23 |
대규모 서비스를 지탱하는 기술, 3강 서비스 개발의 현장 요약 (0) | 2023.06.23 |
대규모 서비스를 지탱하는 기술, 2강 계속 성장하는 서비스와 대규모화의 벽 요약 (0) | 2023.06.23 |