- 이 기사를 대화식 디지털 에디션 형식으로 읽어보자!
- IBM Data Management 잡지 구독하기

독자가 업계 기사와 보도자료를 읽어봤다면 SSD(Solid-State Drive)가 이제 선도하는 엔터프라이즈 스토리지 어레이에 사용 가능하다는 내용이 눈에 띌 수 밖에 없다. 디스크 스토리지 회사들은 이러한 드라이브를 엔터프라이즈 스토리지 성능의 비약적인 발전으로 부각시키고 있으며, 실제로도 그렇다. 영업용 인쇄물은 주로 하드 디스크를 능가하는 SSD 성능 장점을 시연하지만, 전원 및 냉각 절약, 신뢰성, I/O당 비용 및 기타 등등의 추가 혜택에 대한 정보도 들어있다.

독자가 시장의 선전을 제거한다고 해도 무수한 성능 이점으로 인해 SSD가 고급 스토리지 시스템에서 주요 스토리지 전략으로 FC(Fibre Channel) 드라이브를 완전히 대체할 것이라고 강력히 주장한다. 가격은 한동안 문제가 될 가능성이 있지만, 궁극적으로 FC 드라이브의 끝은 시야에 들어있다. (누가 CD의 도입을 기억하는가? 이는 레코드 판의 몰락의 시작이었지만 실제로 레코드 판이 주류를 떠나기까지 수 년이 걸렸다.) FC 드라이브의 끝은 매우 일반적인 기술 전이와 같이 보일 수 있지만, 매우 일반적이지 않은 것이 나타나고 있다. 돌아가는 디스크에서 고체 상태 기술로의 움직임이 원칙을 변화시킬 것이므로 SSD로 인해 데이터베이스로 처리하는 일부 방법들을 재평가하게 될 수 있다.

I/O 비용 및 느리게 돌아가는 디스크

클러스터링. 조각 모으기. 재구성. 버퍼링. 방대한 일반적인 데이터베이스 태스크와 전략은 디스크 I/O를 최소화하는 것이라는 하나의 일만 하도록 제작되었다. 왜냐하면 HDD I/O가 대개 어느 데이터베이스 트랜잭션보다도 가장 시간이 많이 드는 부분이기 때문이다. 총 시간 비용의 측면에서 보면, HDD I/O는 엄청나게 비용이 많이 든다.

SSD로 이동할 때, I/O 연산은 훨씬 더 빨라지지만 대부분의 사람들은 그 차이가 얼마나 큰지 인식하지 못한다. 예를 들어, 단일 랜덤 4K 페이지 읽기를 생각해보자. 15,000rpm FC HDD로부터 평균 응답 시간은 약 6.5밀리초이다. 엔터프라이즈급 스토리지 어레이에서 SSD를 사용할 때 동일한 읽기에 1밀리초가 걸릴 것을 예측해야 한다. 다시 말해서, FC HDD를 취하여 하나의 I/O를 완료하는 시간에 SSD가 여섯 개의 I/O를 완료하도록 예상할 수 있다.

하지만 언급할 내용이 더 있다. SSD는 동시적으로 연산을 수행할 수 있지만, HDD는 그럴 수 없다. 하나의 FC 15,000rpm HDD에서부터 예상할 수 있는 최고치는 초당 약 200 랜덤 4K 페이지 읽기이다. SSD를 사용하면 읽기 요청은 겹쳐질 수 있으며, 이는 초당 5000 랜덤 4K 페이지 읽기 정도이다. 하나의 I/O는 HDD보다 SSD에서 비용이 25배 적게 든다.

SSD를 사용하면 디스크 I/O는 비용이 약간 적게 드는 것이 아니라 비용이 훨씬 적게 든다. 하지만 데이터베이스를 빌드하고 관리하는 방법을 변경하기에 충분히 줄어들었는가? 일부의 경우에는 그렇다. (참고: 이 기사는 온라인 트랜잭션 처리[OLTP] 액세스를 주로 다룬다. 데이터 웨어하우스 활동으로 표시되는 순차적 액세스는 임의 액세스가 하는 것처럼 SSD를 통해 위대한 성능 개선을 이루지 않는다.)

위로

클러스터의 마지막 표준?

데이터베이스 클러스터링은 동일한 페이지에서 자주 액세스되는 DB2 행과 디스크에서 서로 긴밀한 자주 액세스되는 페이지를 위치 지정한다. 성공적인 클러스터링 전략은 특히, 많은 순차적 스캔이 클러스터링 인덱스를 사용하는 경우에 DB2 GETPAGE(및 또한 I/O)의 수를 줄일 수 있다. DB2 서브시스템이 이를 처리해야 하는 순서대로 데이터를 읽기 때문에 클러스터링은 값비싼 SORT를 줄이는 데 도움을 준다. 순차적 스캔은 의사결정 지원 시스템(DSS) 애플리케이션에서 일반적이지만 OLTP 액세스 패턴을 사용하는 것은 드물다.

디스크 헤드 또는 암(arm) 이동을 줄여서 I/O 도중에 지연을 줄이기 위한 페이지의 근접성에 대한 개념은 물론 SSD에 적용되지 않는다. 데이터가 DB2에서 실제로 인접하게 나타날 때(즉, 테이블스페이스에서 연속적 페이지), SSD에서 연속적 셀에 있을 가능성은 매우 낮다. 데이터는 웨어리빙 알고리즘을 사용하여 SSD 용량에 걸쳐서 동일하게 분배된다. 실제로 SSD에서 정확한 위치는 다소 연관성이 없다. 왜냐하면, 데이터를 검색하기 위한 지연이 돌아가는 디스크에서 랜덤 읽기 기능 도중에 발생한 지연보다 적은 개략 산정(그리고 일부 경우에 두 가지 개략 산정)이기 때문이다.

SSD를 사용할 때 클러스터링(또는 해당 문제에 대해 불량 클러스터링)이 실제로 문제가 되는가? 연속적 데이터 페이지는 웨어리빙 알고리즘으로 인해 인접한 셀에 있을 가능성이 낮으므로 매체에서 데이터를 그룹화해야 하는가? 이는 흥미로운 질문이다. DB2가 함께 클러스터링된 두 개의 행이 동일한 페이지에 있다고 이해하면, 이에 대한 요청은 요청이 시간에 맞게 서로 인접한 경우 하나의 I/O가 나타날 수 있다. 이러한 하나의 I/O는 데이터가 클러스터링되지 않으면 발생할 수 없다. 다시 말해서, 이러한 두 가지 행 둘 다 별도의 페이지에 있을 수 있으며, 두 개의 별도의 GETPAGE 및 두 개의 별도의 동기 I/O가 나타난다. 이로 인해 발생하는 질문은 SSD를 사용할 때 추가 GETPAGE(또는 GETPAGE) 및 관련된 동기 I/O의 비용이 처벌적인가이다.

순수주의자들은 CPU 및 채널 자원의 비용을 들여 추가 GETPAGE를 수행한다고 논박할 수 있으며, 그들의 말이 맞다. 하지만, 수행되어야 하는 REORG의 수와 SSD의 속도를 줄이려는 맥락에서 이 추가 비용은 간단하게 정당화된다.

위로

여유 공간 임베드하기

테이블스페이스를 작성할 때 여유 공간을 자주 임베드하므로 애플리케이션은 클러스터링 순서에 행을 삽입할 수 있고 행은 업데이트되는 대로 크기가 늘어날 수 있다. 추가 공간은 오버플로우와 인덱스 페이지 분리를 줄일 수 있다. 대부분의 사람들은 대개 여유 공간으로서 총 테이블스페이스의 10퍼센트를 예약하지만, 보통 고도로 휘발성 애플리케이션에서는 더 많이 할 것이다.

하지만, 여유 공간을 예약하는 것은 디스크 공간을 시간으로 교환하여, 잠재적으로 REORG 사이에 더 길게 갈 수 있다. 따라서, 클러스터링 순서가 매우 중요하지 않을 수 있기 때문에 SSD를 사용할 때 여유 공간을 적게 임베드하는 것을 고려한다.

테이블스페이스에서 여유 공간을 버리도록 결정한다면, 테이블 공간에서 테이블에 대해 APPEND YES를 사용하는 것을 고려하려 할 수 있다. 이 옵션은 DB2가 삽입된 행에 대해 위치를 찾도록 횡단해야 하는 코드 경로를 줄이고 INSERT에서 페이지 오버플로우도 방지한다. 불리한 면은 동시성을 고려해야 한다. INSERT를 실행하고 동일한 페이지에서 잠금과 래치에 대해 경쟁하는 여러 스레드는 비용이 많이 들 수 있다. 특히, 데이터 공유 환경에서 그렇다(비록 MC00가 이 문제를 풀 수 있지만).

위로

버퍼 풀

DBA는 버퍼 풀을 사용하여 메모리에서 가장 최근에 사용된 DB2 페이지를 유지하여, 해당 페이지가 재사용되기를 바라고 I/O를 방지한다. 그리고, 소위 최고의 I/O는 발생하지 않는 I/O이다. SSD가 I/O의 성능 비용을 낮추면 버퍼 풀의 사용이 그렇게 중대한 것은 아니다.

여기에서 잠재적인 조치의 과정은 SSD에서 테이블스페이스 상주자를 지원하는 버퍼 풀의 크기를 줄이는 것이다. HDD와 SSD의 혼합을 보유할 가능성이 있기 때문에, 더 필요한 경우 HDD에서 테이블스페이스로 저장된 버퍼 풀 공간을 지정할 수 있다.

위로

REORG

오늘날 DBA가 데이터와 인덱스를 정리된 상태로 유지하기 위해 하는 일이 무엇인가? 몇 가지가 있지만 실제로 REORGs가 가장 중요한 활동이 될 수 있다. REORGs는 다음과 같이 어느 정도의 목표를 완수하며, 이 중 많은 수가 디스크 I/O와 관련된다.

• 클러스터링 순서에 데이터 위치 지정하기
• 행 삭제로 인해 손실된 공간 다시 캡처하기
• 여유 공간을 테이블스페이스로 다시 삽입하기
• 인덱스에서 리프(leaf) 레벨 또는 페이지 줄이기
• 인덱스에서 단편화 줄이기
• 테이블 또는 인덱스 공간의 범위의 수 줄이기

DB2는 클러스터링 순서에서 행을 최적 위치에 가깝게 유지하기 위해 최선을 다한다. 하지만 이는 항상 가능한 것은 아니다. 해당 페이지는 INSERT에서 행의 최적 위치에 공간이 부재할 수 있거나 행은 UPDATE에서 이에 대해 할당된 공간을 넘어 성장할 수 있으므로 제거되어야 한다. 그리고 많은 다른 이유도 있다. 궁극적으로 시간이 흐르면서 데이터의 CLUSTERRATIO는 100퍼센트에서 더 낮은 레벨로 줄어든다. 얼마나 빨리 줄어드는가는 데이터의 휘발성에 따라 다르다.

REORG가 실행되어야 할 시점을 판별하기 위해 시스템을 모니터해야 한다(이상적으로는 자동화된 방식으로). DB2 카탈로그 통계의 모든 종류는 테이블스페이스 조건을 설명하고, IBM은 REORG가 발생해야 할 시점으로 임계값을 제안한다. 다음과 같이 REORG의 불리한 점이 많다.

• 이는 스케줄되어 모니터되어야 한다.
• 이는 많은 양의 I/O 및 CPU 자원을 소모한다.
• 활성 테이블 또는 인덱스 공간에 대해 실행될 때 동시성과 가용성을 낮출 수 있다.
• 이는 REORG 프로세스 도중에 로깅을 늘릴 수 있다.
• 재해 복구 복제가 사용될 때 변경된 데이터 트래픽으로 광역 네트워크(WAN)가 넘쳐난다.

재해 복구를 위해 장거리에 걸쳐 데이터베이스를 복제하는 중이면 마지막 요점이 가장 중요한 것이 될 수 있다. REORG로 생성된 쓰기가 트랜잭션형 쓰기가 아니라면 링크에 걸쳐 전송된 "실제" 쓰기 워크로드에 추가되어야 하는 여전한 필요악이다. 원격 통신 회선의 비용이 매우 높기 때문에, 피할 수 있거나 적어도 줄일 수 있는 이러한 바쁘기만 하고 성과없는 일로 파이프를 채우는 것이 싫을 것이다.

SSD에서 테이블 공간을 배치하면 REORG의 필요를 줄일 수 있다. 이 접근방식은 관리, CPU, I/O 및 원격 복제에 대한 링크 대역폭 면에서 엄청난 절약을 야기할 수 있다. SSD에서 인덱스 또는 데이터 페이지를 검색하기 위해 DB2 서브시스템이 수행해야 하는 추가 작업이 HDD에서 REORG된 테이블스페이스에서 I/O를 수행하는 비용보다 적다는 점을 이해해야 한다.

위로

IBM 경향

IBM의 직원들과 대화를 해보면 DBA가 REORG 빈도를 낮출 수 있다는 회사 내의 시각이 드러난다. 이러한 개념은 SSD 구현 방식에 독립적이고 왜 REORG가 처음에 수행되는지에 대한 재조사에 더 가깝다. 예를 들어, 테이블스페이스에 대한 많은 범위가 실제로 측정 가능한 부정적인 성능 영향이 있는가? 게다가, DB2 10으로 DSNACCOX는 SSD에 상주하는 테이블스페이스에 대한 REORG 요구사항을 줄여주는 특정 코드가 있다.

위로

SSD와 DB2에 대해 다르게 생각하기

DB2 for z/OS OLTP 서브시스템을 지원하기 위해 SSD를 사용하는 것은 다음을 완수하는 데 도움을 줄 수 있다.

• REORG의 수를 줄인다.
• 값비싼 MIPS, 디스크 및 채널 자원 절약하기
• 원격 복제의 비용 줄이기
• REORG를 관리하는 개인적 시간 절약하기
• 여유 공간을 적게 임베드하여 공간 활용을 늘린다.
• 최소 공간을 SSD에서 테이블스페이스에 전용으로 하고 HDD 버퍼 풀로 저장된 공간을 다시 할당하여 버퍼 풀 효율성을 개선한다.

엔터프라이즈급 스토리지 어레이에 대한 SSD의 구매를 고려할 때, 속도와 피드를 넘어 생각하자. 다르게 완수하기 위해 어느 태스크가 SSD를 사용하는지에 대해 생각하자.

참고자료

• IBM Redbooks® 출판물인 Ready to access DB2 for z/OS Data on Solid-State Drives에서 DB2 for z/OS로 SSD(Solid-State Drive)를 사용하는 것에 대해 자세히 알아보자.
  
  
• Redbooks 출판물인 DB2 10 for z/OS Technical Overview에서 DB2 10 for z/OS에 대한 최신 세부사항에 대해 배워보자.
  
  
• "IBM Easy Tier Enables DS8700 and Storwize V7000 Users to Profit from Solid State Drives"(David Hill 저, Mesabi Group, 2010년 10월 1일) 기사에서 SSD(Solid-State Drive)의 혜택에 대한 개요를 살펴보자.
  
  

필자소개

Paul Pendle은 메사추세츠주 EMC Corporation의 Consulting Systems Integration Engineer이다. 그는 시스템 프로그래밍과 데이터베이스 관리 분야에서 다양한 경험을 갖춘 IT 업계의 31년 경력의 베테랑이다. Paul은 DB2 V1.2부터 DB2 on z/OS(MVS)로 작업했으며 DB2 for z/OS 및 DB2 for Linux, UNIX 및 Windows 모두에 대한 DB2 사용자 컨퍼런스의 정기적인 연사이다. Paul은 DB2로 EMC 제품의 통합에 대한 책을 출간한 저자이다.

아티클 순위

의견

위로

목차

• I/O 비용 및 느리게 돌아가는 디스크
• 클러스터의 마지막 표준?
• 여유 공간 임베드하기
• 버퍼 풀
• REORG
• IBM 경향
• SSD와 DB2에 대해 다르게 생각하기
• 참고자료
• 필자소개
• 의견