캐싱 (Caching)은 무조건 성능이 좋다?

"캐시를 켜야 성능이 좋다.", "캐싱으로 성능이 좋아진다."

 

이 주제 역시 아주 많은 사람들이 이렇게 알고 있다.

맞다.

Caching은 성능 향상을 위해 나온 기술이니까.

 

---

 

시스템에는 다양한 입출력 방식이 있다.

 

* Source : 실무로 배우는 시스템 성능 최적화 by 권문수

 

일반 파일시스템은, 데이터 읽기를 요청받으면 파일 버퍼 캐시에 그 데이터가 존재하는지 확인한 후, 캐싱되어 있지 않으면 디스크에서 읽어와 캐시에 올리고 애플리케이션에 데이터를 넘겨준다.

 

직접 입출력 (Direct IO)은, 파일 버퍼 캐시 영역을 거치지 않고, 디스크로부터 애플리케이션으로 바로 파일 데이터가 전달되게 한다. 그래서 DIO는 항상 디스크로부터 sync read가 발생하기 때문에 성능이 나쁠 수 있다. 그러나 DB의 경우, DB엔진에 캐시가 구현돼 있어 파일시스템이 제공하는 파일 캐시를 사용하지 않는 편이 성능 측면에서 유리하다. DB에 파일 캐시를 사용하면, 파일 캐시와 DB 데이터 캐시에 두 번 캐시되어 메모리 사용의 비효율성과 처리 오버헤드가 발생한다. 그래서 DB가 파일시스템을 사용할 때는 DIO를 설정해서 사용하는 것이 성능 측면에서 우수하다.

 

파일시스템은 데이터 완전성을 유지하기 위해, inode lock을 통해 쓰기 직렬화해서 한 시점에 한 파일에 대한 쓰기 작업은 한 스레드만 가능하게 한다.

동시 입출력 (Concurrent IO)은 이러한 inode lock을 처리하지 않음으로써 공유된 파일에 대해 여러 개의 스레드가 동시에 읽고 쓸 수 있게 한다. 그리고, CIO는 DIO에서 파일 캐시를 사용하지 않는 특성도 함께 포함하고 있다.

오라클 DB의 경우 DB엔진 내부에 쓰기 직렬화 알고리즘이 내장돼 있어, 파일시스템에서 그 기능을 제공하지 않아도 데이터 완전성이 깨지지 않으므로 CIO를 사용하는 것이 성능 측면에서 유리하다. 실제로, 오라클에서 CIO를 사용하는 것은 Raw device를 사용하는 것과 유사한 성능 효과를 보인다. 참고로, ASM은 Raw device 입출력보다 하위 수준으로 디스크 (물리 볼륨)를 직접 제어한다. 즉, ASM 내부에 볼륨 매니저가 구현돼 있다고 볼 수 있으며, 스트라이핑과 미러링까지 지원한다.

 

  * 과거 튜닝 사례 : CIO 적용하여 CPU util 90% -> 20~30%로 감소, App 성능 90% 향상

 

그런데, 많은 사람들이 이미 캐시를 거치지 않고 물리 디스크를 바로 액세스하는 것이 빠르다는 것을 직간접 경험으로 알고 있는 경우가 있다. 바로 Raw device 사용. 오라클에서 Raw device를 쓰는 이유는 한가지 뿐이다. 바로 성능이다. (관리하기 불편해도..) 파일시스템을 버리고 Raw device를 사용하면 성능이 대략 30%는 올라가니까.

일례로, 스토리지 부하 테스트 시, 파일시스템에 부하를 주면 성능이 나오던가?

대부분 Raw device로 부하를 준다.

이미 다 알고 있던 사실인데, 왜 Cache를 타야 성능이 좋아진다고 생각할까?

---

 

아마도, 이런 고정관념은 캐시 중심 구조 (Cache Centric Architecture)의 스토리지를 자주 접했기 때문이 아닐까 생각해본다. 전통적으로 (미디어가 스핀들일 때부터), 대부분의 스토리지가 캐시 메모리를 통해 느린 성능을 보완하는 역할을 당당히 수행해왔었다. 그리고 플래시 미디어를 사용하는 지금까지도 그 역할을 충실히 잘 수행하고 있다.

예를 들면, 호스트 I/O가 처음으로 스토리지의 메모리에 들어왔을 때, 디스크까지 저장하기 전에 Write I/O가 완료되었음을 Host에 전달하기도 하고, 소량의 여러 쓰기 요청을 일정량 모아서 하나의 큰 순차 쓰기 작업으로 만들기도 하며, 호스트가 특정 주소에 다시 쓸 때, 다시 써진 데이터는 캐시에서 대체되고 디스크에는 쓰지 않는 기능도 있다. 또 호스트 I/O 요청을 디스크가 아닌 캐시 메모리에서 최대한 리턴 시키기 위해 재요청될 가능성이 큰 최근 데이터를 메모리에 장시간 머물도록 하여 백엔드에 대한 물리적 액세스를 줄임으로써 데이터 액세스 속도를 높이게 한다.

이러한 여러 캐싱 알고리즘을 통해 성능 향상을 이루게 되며, 제품마다 독자적 기술로써 경합을 벌이고 있다.

 

그러나, 반대의 경우도 있다.

메모리를 통해 캐싱을 하지 않을 경우 성능이 더 좋은 아키텍처도 있다.

하드 디스크 시절에는 DRAM과 자기 디스크의 성능 차이가 매우 커서, 캐싱이 느린 장치의 성능을 보완하는 용도로는 아주 큰 효과를 거두었으나, 플래시 미디어의 성능이 높아짐으로써 캐싱 알고리즘을 사용하지 않고 디스크로부터 직접 액세스하는 아키텍처의 스토리지도 생겨나게 되었다. 또한, 메모리를 캐싱 용도로 사용하지 않고 메타 데이터 저장용으로 사용하는 스토리지도 있다.

예를 들어, 호스트 요청에 대한 데이터가 메모리에 없을 경우, 디스크로부터 읽은 데이터를 먼저 메모리에 저장한 후 호스트로 응답을 주게 되면 메모리를 거치는 것이 비효율적이다. (이런 경우, 대체로 캐시 메모리 사이즈가 크지 않다.) 또, 호스트로부터 메모리 용량을 초과하는 Bulk I/O가 내려올 경우에는 성능이 크게 출렁이게 되어 캐싱 알고리즘이 오히려 마이너스 요인으로 작용할 수 있다. (아래 Cache Off 시 더 높은 성능을 나타내는 스토리지 참조)

 

 

이렇게, 성능은 제품이나 캐싱 알고리즘에 의해 데이터를 어떻게 처리하느냐에 따라 달라질 수 있다. 그리고 스토리지의 메모리는 데이터 캐싱 뿐만 아니라 스냅샷, 복제, 중복제거, 압축 등 여러가지 기능과 연관되어 있기에 단순히 I/O 처리 성능만이 아닌, 제품별 특화된 기능에 따라 다양하게 활용될 수 있다.

그러므로, 메모리에 의한 캐싱이 무조건 좋다거나 또는 안 좋다고 할 수는 없다.

 

---

다시, 시스템의 입출력 방식으로 돌아가... 혹자는, 이렇게 물어볼 수도 있을 것 같다.

"파일시스템의 버퍼 캐시를 타는 게 더 빠른 것으로 아는데 무슨 소리냐?"

이 질문에는 반만 동의할 수 있을 것 같다.

원래 파일시스템이 캐시를 통해 I/O 성능을 빠르게 하려고 만든 거니까, 그렇다. 캐시가 빠르다.
그런데, 상황에 따라 다르다. 단순히 OS 레벨에서 파일 I/O를 일으킨다면 빠른 것이 맞는데, 시스템에 애플리케이션이 올라가면 이야기가 달라진다.

특히, DB가 운영된다고 하면, DB에는 자체 버퍼 캐시가 있는데, 파일시스템의 파일 버퍼 캐시도 있기에 오히려 역효과가 생기게 된다. (이를 Double buffering overhead라고 함)

그럼, 이 역효과는 왜 생길까?

파일 버퍼를 관리하기 위해서는 OS의 개입이 수반되어야 하는데, 이 OS가 버퍼 캐시를 핸들링하기 위해서는 커널의 여러 가지 펑션을 수행해야 한다. DB는 자체 메모리 공간을 갖고서 캐싱을 하고 있는데, 중간에 파일 시스템이 개입되어 커널 펑션 수행에 의한 시간 소모를 기다릴 수밖에 없기 때문에 오히려 전체 응답 시간이 증가하는 효과를 가져온다. 즉, 캐싱을 하지 않았으면 수행하지 않았을 일을 한번 더 한 것이다.
그러므로, 실제 대부분의 환경에서는 그 업무에 해당하는 어플리케이션이 수행되므로 반대되는 상황이 얼마든지 연출될 수 있다.