Zero to Hero

I/O 부하를 줄이는 방법

1. 캐시를 전제로 한 I/O 줄이는 방법

데이터 규모 < 물리 메모리

위 조건이라면 전부 캐싱이 가능하다. (이론적으로)

 

하지만 메모리;는 매우 비싼 자원이고 현실적으로 불가능하다.

 

2. 전부 캐싱할 수 없는 구조가 되면

 

복수 서버로 확장시키기

-> CPU 부하분산은 단순히 스케일 업 하는 것으로 해결이 가능하다.

-> I/O 분산에는 국소성을 고려한다.

 

3. 단순히 대수만 늘려서는 확장성을 확보할 수 없다.

애초에 캐시 용량이 부족해서 늘렸는데 그 부족한 부분도 그대로 동일하게 늘려가게 된다. 결국 액세스 한 순간에 느려지는 것은 변함이 없다. 캐싱할 수 없는 비율은 변함없이 그대로 간다.

 

 

국소성을 고려한 분산

액세스 패턴을 고려한 분산, 캐싱할 수 없는 부분이 사라진다. (메모리는 디스크보다 10^6배 빠르기 때문)

 

1. 파티셔닝

한 대였던 DB 서버를 여러 대의 서버로 분할하는 방법

 

예. 테이블 단위 분할

자주 사용하는 테이블 묶음, 혹은 액세스 패턴이 비슷한 테이블끼리 묶어서 파티셔닝

예. 테이블 데이터 분할

 

예. 요청 패턴을 "섬"으로 분할

용도별로 시스템을 섬으로 나누는 방법, 북마크에 자주 사용하는 기능

캐싱하기 쉬운 요청, 캐싱하기 어려운 요청을 처리하는 섬을 나누게 되면, 전자는 국소성으로 인해 안정되고 높은 캐시 적중률을 낼 수 있다.

2. 페이지 캐시를 고려한 운용의 기본 규칙

1. OS 기동 후에 서버를 곧바로 투입하지 않는다.

2. 성능 평가는 캐시가 최적화되었을 때 한다.

 

대규모 서비스를 지탱하는 기술
국내도서
저자 : 이토 나오야,다나카 신지 / 진명조역
출판 : 제이펍 2011.02.28
상세보기

'Review' 카테고리의 다른 글

대규모 서비스를 지탱하는 기술 04  (0) 2021.01.12
대규모 서비스를 지탱하는 기술 03  (0) 2021.01.12
대규모 서비스를 지탱하는 기술 01  (0) 2021.01.12
친절한 SQL 튜닝 04  (0) 2020.12.30
친절한 SQL 튜닝 03  (0) 2020.12.30
profile

Zero to Hero

@Doljae

포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!