Chapter 03. OS 캐시와 분산 (강의8 ~ 10)

강의8. OS의 캐시 구조

OS에서는 디스크 내의 데이터에 빠르게 액세스할 수 있도록 구조가 갖춰져 있고, 메모리를 이용해서 디스크 액세스를 줄여준다. 그래서 이를 전제로 application을 작성할 때 OS에 상당부분을 맡길 수 있는 것이다.

Linux에서는 page cache라고 하는데 이 특성을 알아야한다.

일단 가상메모리라는 것을 알아야 하는데 이 책 볼 정도면 기본적인 운영체제에 대해서 알고 있을 것 같다.

OS는 가상메모리 구조를 가지고 있고, 이거는 논리적인 선형 주소를 물리적인 주소로 변환해주는 것.

1. 프로세스에서 메모리를 다루기 쉽게 하는 이점을 제공한다.

2. OS가 커널 내에서 메모리를 추상화하고 있다.

3. OS가 물리 메모리를 확보/관리하는 단위는 page.

Linux의 페이지 캐시

데이터 읽기를 마친 프로세스가 데이터 전부 처리 후 더 이상 불필요 하게 됐 어도 OS는 해제하지 않고 남겨둔다. 이러면 다른 프로세스가 같은 자리를 이용할 수 있기 때문. 즉 커널이 한 번 할당한 메모리를 해제하지 않고 계속 남겨두는 것이 페이지 캐시의 기본.

예외인 경우를 제외하고 모든 I/O에 작용한다.

1. 디스크의 내용을 일단 메모리에 읽어 들인다. -> 페이지가 작성된다.

2. 작성된 페이지는 파기되지 않고 남는다. -> 페이지 캐시

3. 예외의 경우를 제외하고 모든 I/O에 투과적으로 작용한다. -> 디스크의 캐시를 담당하는 곳(VFS)

VFS(Virtual File System)

다양한 파일시스템의 함수에 대해서 그 인터페이스를 통일하는 것이 VFS의 역할이다. 페이지 캐시의 구조를 지니고 있어서, 반드시 동일한 구조로 caching된다.

Linux는 페이지 단위로 디스크를 캐싱한다.

Linux는 파일을 i-노드 번호로 식별하며, 해당 파일의 번호와 offset, 두 가지 값으로 캐싱한다.

결과적으로 파일 전체가 아닌 파일의 일부를 캐싱해갈 수 있다. 그리고 파일이 아무리 커도 이 두개의 키로 해당 페이지를 찾을 때의 데이터 구조는 최적화되어 있다. OS내부에서 사용하는 데이터 구조는 Radix Tree(Window는 다른가?) 파일이 아무리 커지더라도 캐시 탐색속도가 떨어지지 않도록 개발된 데이터 구조. 커다란 파일의 일부분을 캐싱하거나 작은 파일의 일부분을 캐싱하더라도 동일한 속도로 캐시를 찾을 수 있도록 되어 있다.

LRU

가장 오래된 것을 파기하고 가장 새로운 것을 남겨놓는 구조. 최근에 읽은 부분이 캐시에 남고 과거에 읽은 부분이 파기되어 간다. 서버를 가동시킨 이후에 I/O가 내려가는 특성

메모리가 비어 있으면 캐싱

리눅스는 메모리가 비어 있으면 전부 캐싱한다. 캐시 이외에 메모리가 필요해지면 오래된 캐시가 파기(LRU)

Sar -r 1 10000명령어

Sar -u: CPU 이용률 확인

Sar -q: load average 확인

Sar -r: 메모리 사용 현황 확인

Sar -q: 스왑 발생상황 확인

 

강의9. I/O 부하를 줄이는 방법

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

캐시를 전제로 I/O를 줄이는 것이 기본. 여기서 두가지 방법이 있다.

 

1. 데이터 규모에 비해 물리 메모리가 크면 전부 캐싱할 수 있으므로 이 점을 생각할 것.

-> 다루고자 하는 데이터의 크기에 주목하자. 또한 데이터 압축해서 저장을 하면 디스크 내용을 전부 그대로 캐싱해둘 수 있는 경우가 생긴다.

데이터 규모 <물리 메모리 면 전부 캐싱가능, 경제적 비용과의 밸런스 고려

 

2. 복수의 서버로 확장시키는 방안을 생각한다.

그런데 앞의 강의에서 말한 것처럼 CPU부하가 많은 AP서버에서는 상관없지만 I/O부하가 많은 DB서버의 경우 단순히 ‘늘리면 좋다’라는 논리가 들어맞지 않는다.

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

단순히 데이터를 복사해서 대수를 늘리게 되면 캐싱할 수 없는 비율은 변함없이 그대로 -> 다시 병목이 생긴다.

페이지 캐시는 한 번의 read에서 시작된다. -> 서버를 재부팅 하면 캐싱 해 두었던 것들이 다 사라져서 모든 데이터에 대해서 I/O를 해야 하는 상황이 발생한다. -> DB Lock이 걸리는 경우가 생긴다.

강의10. 국소성을 살리는 분산

데이터에 대한 액세스 패턴을 고려해서 분산시키는 것을 국소성을 고려한 분산이라고 한다. DB서버에 액세스 패턴들이 있고 서로 다른 데이터에 액세스를 한다면 이를 분산시킬 수 있다.

A패턴은 user에 관한 정보에 접근, B패턴은 북마크에 관한 정보에 접근한다면 이를 나누자.

그러면 메모리에 캐싱할 수 있는 부분이 많아지게 된다.

파티셔닝

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

1. 테이블 단위 분할(테이블 그 자체)

2. 테이블 데이터 분할(ID, 지역, 날짜)

요청 패턴을 ‘섬’으로 분할

용도별로 시스템을 섬으로 나누는 방법도 있다. AP서버와 DB서버를 묶어서 하나의 패턴으로만 사용하는 방법

사용자 요청을 처리하는, 봇 요청을 처리하는, API요청을 처리하는 AP서버 + DB서버 로 나눈다. 이러면 국소성으로 인해 안정되고 높은 캐시 적중률을 낼 수 있게 된다.

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

1. OS 기동 직후에 서버를 투입하지 않는다는 것. -> 캐시가 쌓여 있지 않아서 오직 디스크 액세스만 발생하게 된다. OS를 시작해서 기동하면 자주 사용하는 DB의 파일을 한 번 cat해준다. 그러면 전부 메모리에 올라간다. 그렇게 한 후에 로드밸런서에 편입시키는 방법을 이용한다.

2. 성능평가나 부하시험을 할 때는 초기값을 버려야 한다. -> 캐시가 올라가 있지 않았을 때와 올라가 있을 때 낼 수 있는 속도는 완전히 다르므로 캐시가 최적화된 후에 실시할 필요가 있다.

 

결과적으로 OS 동작원리를 안다는 것이 부하분산의 학습에 중요하다. OS캐시, 멀티 스레드, 멀티 프로세스, 가상메모리구조, 파일시스템 등 다양한 장치가 하드웨어를 효율적으로 사용하기 위해 어떤 원리를 갖추고 있는지를 비롯해 장단점을 확실히 알 수 있게 되면 시스템 전체를 최적화할 수 있다.