[Oracle Exadata] Oracle Exadata 핵심 기술요소 Summary 4

[Oracle Exadata] Oracle Exadata 핵심 기술요소 Summary 1편 - 보기

[Oracle Exadata] Oracle Exadata 핵심 기술요소 Summary 2편 - 보기

[Oracle Exadata] Oracle Exadata 핵심 기술요소 Summary 3편 - 보기

|  Exadata Smart Flash Cache  |

Disk에서 데이터 블록을 검색하는 것은 메모리에서 검색하는 것에 비해 성능이 느리다. 따라서 Oracle은 데이터 검색의 성능 향상을 위해 자주 Access되는 블록을 DB Buffer Cache라는 메모리 영역에 캐시 시키고, 데이터 검색 시 먼저 DB Buffer Cache에서 해당 블록을 찾는다. 하지만 DB Buffer Cache는 크기는 한정적이어서 모든 데이터 블록을 캐시 시킬 수 없기 때문에 검색하고자 하는 블록이 DB Buffer Cache에 없다면, Disk에서 블록을 검색하기 때문에 성능 저하가 발생하게 된다. Oracle은 이러한 Disk I/O의 성능 저하를 해소하기 위해 2차 Cache 영역인 Flash Cache를 제공한다. 

Flash Cache는 Flash Storage 영역으로 Disk Storage에 비하여 I/O 성능이 약 5배 이상 빠른 성능을 제공하기 때문에 Flash Cache에서 데이터를 검색하는 것이 Disk에서 직접 데이터를 검색하는 것보다 훨씬 빠르다. 표준 Oracle은 Flash Storage에 자주 Access되는 블록을 캐싱하여 Disk I/O 성능을 향상시키고 있다. 표준 Oracle과 Exadata는 각각 다른 방법의 Flash Cache를 제공한다. 표준 Oracle의 Database Smart Flash Cache(DSFC)는 DB Buffer Cache의 블록이 Aging-out 될 때 해당 블록을 캐싱하여 Disk I/O에 대한 횟수를 줄임으로 Disk I/O 비용을 감소시키는 목적으로 제공된다. 반면에 Exadata에서 제공하는 Exadata Smart Flash Cache(ESFC)는 Disk I/O가 수행될 때 Storage 서버에서 해당 블록을 빨리 검색하여 Disk I/O에 대한 효율을 향상시키기 위해 사용된다. 이번 장에서는 표준 Oracle의 DSFC와 Exadata의 ESFC에 대해 알아보고, Oracle이 어떤 Step으로 메모리와 디스크에서 데이터를 검색하는지 알아보도록 한다.

Database Smart Flash Cache (DSFC)

Database Smart Flash Cache(DSFC)는 표준 Oracle에서 사용하는 Flash Cache 기법으로 SSD와 같은 Flash Storage에 Disk의 블록을 캐싱함으로써 I/O의 성능을 향상시킨다. DSFC를 이용한 블록 검색 과정을 살펴보면, 먼저 DB Buffer Cache에서 해당 블록을 검색하고 DB Buffer Cache에 블록이 없을 경우 다음으로 DSFC에서 블록을 검색한다. 만약에 DSFC에서도 해당 블록을 검색하지 못한다면 마지막으로 Disk에서 블록을 검색하게 된다.

[그림4-1] Database Smart Flash Cache

DSFC에 블록이 저장되는 시점은 DB Buffer Cache에서 LRU 알고리즘에 의해 특정 블록이 Aging-out되는 시점이다. DB 서버는 DB Buffer Cache의 블록을 교체하기 전에 해당 블록을 먼저 DSFC에 저장하고, 이 후 동일한 블록이 다시 검색될 때 DSFC에서 블록을 검색하게 된다. DSFC의 성능이 Disk보다 빠르기는 하지만, 아쉽게도 DSFC는 Write의 성능 향상을 위해서는 사용되지는 않는다. DBWR이 Dirty 블록을 Write할 때 만약 DSFC에 Write한다면 Disk에 Write하는 것보다 더 빠를 것으로 예상되지만, Oracle은 Dirty 블록 Write 시 DSFC를 사용하지 않고 Disk에 바로 Write를 한다. 이 방법은 뒤에서 살펴볼 Exadata의 ESFC 와 구별되는 특징 중 하나이다. 

Exadata Smart Flash Cache (ESFC)

Exadata의 Smart Scan은 데이터 전송량을 줄여 I/O 성능을 향상시키는 기법이다. 하지만 Smart Scan은 Full Scan 질의에 대해서만 수행되기 때문에 Index Scan과 같은 Random Access에서는 Smart Scan이 수행되지 않는다. Exadata의 Index Scan은 표준 Oracle과 마찬가지로 블록 단위로 데이터를 전송하기 때문에 여전히 I/O 성능 저하가 발생할 수 있다. Exadata는 X2버전부터 Index Scan의 성능 향상을 위한 Exadata Smart Flash Cache(ESFC)를 제공한다. Exadata Smart Flash Cache는 고성능 Flash FCI Card를 Storage 서버에 장착해 디스크 컨트롤러의 병목현상을 감소시킴으로써 Disk I/O의 성능을 향상시킨다. 일반적으로 Flash Cache에서 블록을 검색하는 것이 Disk에서 검색하는 것보다 5배 이상 성능이 빠르다. ESFC를 통한 블록 검색은 Cell 서버에서 이루어진다. DB 서버가 Cell 서버로 블록을 요청하면 cellsrv 프로세스가 Disk와 ESFC 양쪽에 I/O를 요청한다. 이 중 한 쪽이라도 먼저 블록이 검색되는 시점에 DB 서버로 해당 블록을 전송한다. 만약 ESFC에 없는 블록이 Disk에서 검색되었다면, cellsrv는 우선 블록을 DB 서버로 전송하고 이후 해당 블록을 ESFC에 캐싱하게 된다. 먼저 검색한 블록을 DB 서버로 전송하기 때문에 데이터 검색 시 빠른 응답 속도를 제공할 수 있는 것이다.

[그림4-2] Exadata Smart Flash Cache

ESFC를 통해 데이터 읽기

ESFC에 캐시된 블록을 읽는 과정을 살펴보면, cellsrv가 Disk와 ESFC에서 동시에 해당 블록을 검색하고 그 중 먼저 찾은 블록을 DB 서버로 전송하게 된다. 이렇게 Disk와 ESFC 양쪽 모두에서 블록을 검색하고, 먼저 검색한 블록을 DB 서버로 전송하게 되면 빠른 응답처리가 가능해진다. 

[그림4-3] ESFC에 캐싱된 데이터 읽기

만약 검색한 블록이 ESFC에 존재하지 않는다면, cellsrv는 Disk에서 검색한 블록을 DB 서버로 전송한 후 해당 블록을 ESFC에 캐싱한다. 다음 그림은 ESFC에 캐싱하는 단계를 설명한다.

[그림4-4] ESFC에 캐싱되지 않은 데이터 읽기

ESFC를 통해 데이터 쓰기

Exadata는 DSFC와 다르게 DBWR이 Dirty 블록을 Write하는 경우에도 사용된다. Exadata X2까지는 Disk에 먼저 Write한 후, ESFC에 해당 블록을 저장하는 Write-through 방식을 사용했다. 

[그림4-5] ESFC의 Write-through 방식

Write-through가 단순히 Disk에 Write한 블록을 이후에 ESFC에 캐싱하는 것이라면, Exadata X3부터 제공하는 Write-back 기능은 Disk와 ESFC에 동시에 Dirty 블록을 Write하고 이 중 하나라도 먼저 작업이 완료되면 DB 서버로 Ack를 전송하는 방식이다.

[그림4-6] ESFC의 Write-back 방식

Exadata X3부터는 Write-back 기능으로 DBWR의 I/O latency가 더욱 좋아지게 되었다. 이로 인해 X2의 Write-through에 비해 약 10배 정도 향상되었고, 표준 Oracle의 한계였던 Write Intensive한 업무에서 발생하던 성능 저하도 사라지게 되었다. ESFC의 Write-back 기능은 Oracle Database 11g 11.2.0.3 Bundle Patch 9 이상부터 사용할 수 있다. 주의할 점은 Write-back 기능은 기본적으로 disable이기 때문에 이 기능을 사용하려면 반드시 Cell 서버에서 다음 명령문을 실행하여 Write-back 기능을 활성화 시켜야 한다.

Smart Flash Log

OLTP 시스템에 commit이 빈번히 수행되면 ‘log file sync’ 병목으로 인해 트랜잭션 응답 시간이 심하게 튀는 현상이 발생하게 된다. Exadata는 이러한 log file sync 병목을 해소하기 위해 Flash Cache의 일부 영역에 Redo log를 Write하게 된다. 이 기법을 Smart Flash Log라고 부른다. Smart Flash Log 기법은 Flash Cache에 Redo log를 위한 일부 영역(default: 512MB)을 할당하고 DB 서버가 Redo log Sync를 요청할 때 Storage 서버가 Flash Cache와 Disk에 동시에 Redo log를 Write하는 기법이다. Storage 서버는 Write 작업이 하나라도 완료되면 DB 서버로 Ack 신호를 전송하게 된다.

[그림4-7] Smart Flash Log

ESFC의 Write-back 기능이 DBWR의 I/O latency를 향상시키는 목적으로 사용된다면, Smart Flash Log는 LGWR의 I/O latency를 향상시키는 목적으로 사용된다. 실제로 Smart Flash Log를 사용할 경우 기존 대비 약 3배 정도 빠른 응답 속도를 제공하게 되고, 응답 시간이 튀는 현상도 사라지게 된다. Smart Flash Log는 Exadata Storage Software 11.2.2.4 이상, Oracle Database 11g 11.2.0.3 이상에서 사용할 수 있다. 

CELL_FLASH_CACHE

cell_flash_cache는 ESFC에 대한 Object Caching 정책을 지정하는 옵션이다. 다음의 옵션을 cell_flash_cache에 지정할 수 있다.

일반 테이블은 ESFC 내에서 LRU 알고리즘에 의해 관리된다. 하지만 cell_flash_cache가 keep으로 설정된 테이블은 처음 블록을 스캔할 때 해당 블록을 ESFC에 저장하고, 그 후에도 계속 ESFC에 캐싱되게 된다. Cell 서버는cell_flash_cache keep으로 설정된 테이블에 대해 ESFC에서 블록을 검색하게 되므로, Disk에서 검색하는 것에 비해 빠른 성능을 보장한다. KEEP 영역은 ESFC의 80%까지 저장된다. 만약 이 영역을 초과하게 되면 keep으로 설정된 테이블의 Storage 속성이 default로 변경되어 일반 테이블처럼 LRU 알고리즘에 의해 관리된다. cell_flash_cache 옵션은 다음과 같이 Create Table/ Alter Table 시 Storage 절에 지정한다

결론

Oracle의 Flash Cache는 Index Scan시 Single Block I/O의 성능을 향상시키기 위해 제공된다. 표준 Oracle에서 제공하는 DSFC가 Disk I/O를 회피하여 I/O의 성능을 향상시킨다면, Exadata의 ESFC는 Storage Server 내에서 수행되는 Disk I/O의 효율성을 높여 I/O 성능을 향상시킨다. Exadata는 Full Scan의 성능을 향상시키기 위해 Smart Scan을 제공할 뿐 아니라, Index Scan의 성능 향상을 위해 ESFC도 제공한다. 이로 인해 DW에서 Smart Scan을 통해 I/O 성능을 향상시킬 뿐 아니라, OLTP나 혼합 워크로드 형태의 시스템에도 ESFC를 통해 성능을 향상시킬 수 있다.