OS 캐시와 분산

대규모 데이터를 효율적으로 처리하는 원리

「대규모 서비스를 지탱하는 기술」 Chapter 03

---

메모리, 디스크, OS 캐시 구조

• 디스크와 메모리 간 속도차는 10^5~10^6배 이상
• 메모리를 이용해서 디스크 액세스를 줄이고자 함 → OS는 캐시 구조를 갖추고 있음

 

OS의 가상 메모리 구조

• 논리적인 선형 어드레스를 물리적인 물리 어드레스로 변환하는 것
• 페이지
  • OS가 물리 메모리를 확보/관리하는 단위
  • 가상 메모리의 최소단위

 

Linux의 페이지 캐시

• 디스크의 내용을 일단 메모리에 읽어들임 → 페이지가 작성됨
• 작성된 페이지는 파기되지 않고 남음 → 페이지 캐시
• 예외의 경우를 제외하고 모든 I/O에 투과적으로 작용 → VFS(Virtual File System)가 담당

 

캐싱 방법: Linux의 파일 식별

• i노트 번호 → “어떤 파일의”
• 어느 위치부터 시작할지를 나타내는 오프셋 → “어느 위치”
• 라는 쌍으로 캐시의 키를 관리할 수 있으므로 결과적으로 파일 전체가 아닌 파일의 일부를 캐싱 가능
• 이 키로부터 해당 페이지를 찾을 때의 데이터 구조는 파일이 아무리 커지더라도 캐시 탐색속도가 떨어지지 않도록 개발된 데이터 구조인 Radix Tree임

 

Linux는 메모리가 비어 있으면 전부 캐싱

• 비어 있는 메모리 공간에 제한 없이 디스크 내용을 캐싱해감
• sar -r로 확인

 

💡 → 메모리를 늘리면 캐시에 사용할 수 있는 용량이 늘어남 → 보다 많은 데이터를 캐싱 가능 → 디스크 읽는 횟수가 줄어듦 → I/O 부하 줄일 수 있음!?

 

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

• 다루고자 하는 데이터 크기에 주목 (압축 중요) → 데이터 규모 < 물리 메모리면 전부 캐싱 가능
• 경제적 비용과의 밸런스 고려 → 현재 일반적인 서버 메모리 8~16GB

전부 캐싱할 수 없는 구조가 되면 → 복수 서버로 확장시키기

• CPU 부하분산: 단순히 늘림
• I/O 분산: 국소성을 고려

but 단순히 대수를 늘리는 것은 캐싱할 수 없는 비율은 변함없이 그대로기 때문에 곧 다시 병목이 됨

 

국소성을 고려한 분산

• 액세스 패턴을 고려하여 더 이상 액세스되지 않는 데이터 영역은 그만큼 캐시영역을 다른 곳으로 돌릴 수 있음 → 시스템 전체로서는 메모리에 올라간 데이터량이 늘어나게 됨
• 파티셔닝: 한 대였던 DB 서버를 여러 대의 서버로 분할하는 방법
  • e.g. RDBMS의 테이블 단위 분할 → 테이블A는 서버1 / 테이블B는 서버2 / …
  • e.g. 테이블 데이터 분할 → a~c까지는 서버1 / d~f까지는 서버2 / …
  • e.g. 용도별로 시스템을 ‘섬’으로 나눔 → HTTP 요청의 User-Agen나 URL 등을 보고 통상의 사용자면 섬1 / 봇이면 섬2 / 일부 API 요청이면 섬3 / …

 

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

• OS 기동 후에 서버를 곧바로 투입 X
  • OS를 시작해서 기동하면 자주 사용하는 DB의 파일을 한 번 cat해줌 → 전부 메모리에 올라간 후 로드밸런서에 편입시킴
• 성능평가는 캐시가 최적화되었을 때