7. 스토리지 기술의 변천과 데이터베이스에 끼치는 영향

하드웨어 성능 개선의 역사

HDD에 의한 처리의 한계

• 인덱스와 실제 데이터는 물리적으로 인접해 있지 않기 때문에 각각 별도로 액세스할 필요가 있다 — 이러한 접근 방식을 랜덤 액세스라 함

• HDD로의 액세스가 발생하는 경우에는 랜덤 액세스하기 위해 물리적인 동작이 필요하기에(디스크 헤드가 해당 트랙에 도달하기까지 탐색 대기 시간과 원하는 위치에 올 때까지 기다리는 회전 대기 시간) 10밀리초 정도의 시간이 필요 ⇒ 한개의 SQL 문을 처리하기 위해 여러 번의 랜덤 액세스가 필요하기에 1초에 처리할 수 있는 I/O 횟수 IOPS(Input Output Per Second)가 10정도 밖에 안나올 수 있음

메모리 가격 하락에 따른 64비트 환경의 극대화

• 메모리 양이 윤택하면 할수록 캐시 가능한 데이터 양이 증가함

• 그러나 메모리는 비싼데다 탑재할 수 있는 슬롯도 한정되어 있기에 탑재할 수 있는 양에 한계가 있음

• 실제로 어느 정도의 메모리가 필요한지는 애플리케이션의 데이터 양 뿐 아니라 그 데이터에 어떻게 접근해 갈 것인가(최신 데이터에 집중하는지, 골고루 사용되는지 등)에 크게 의존

• 그러나 메모리 가격 하락과 64비트 OS의 대두로 100GB, 256GB의 메모리를 탑재할 수 있는 하드웨어가 늘고 있음. DB 서버용으로 50GB의 메모리를 사용하면 실제 데이터는 그것의 몇 배를 사용할 수 있기에 100~300GB 정도는 한 대의 서버에 할당될 것 ⇒ 한 DB 서버에서 그만큼 많은 사용자 처리가 가능함

단일 스레드 처리의 성능 문제

• DB 서버 한 대당 담당할 수 있는 데이터 양/사용자 수가 모두 몇 배가 되면, 집계 처리와 같은 단일 스레드에서 행하는 타입의 작업에는 시간이 너무 오래 걸리게 됨
• 또한 집계 처리는 때때로 한 개의 거대한 테이블에 대해 한 번 밖에 액세스하지 않기 때문에 메모리가 충분 하더라도 캐시 효율성이 낮음

• 다수 트래픽이 마스터에 전해지는 상황에서(병렬처리), 복제과정은 단일 스레드로 일어나기 때문에 해당 갱신 처리가 슬레이브에 바로바로 반영될 수 없음(직렬처리 되기 때문에) ⇒ 복제 지연 발생

SATA SSD에 의한 성능 개선

• 단일 스레드 처리의 성능 지연의 주요 이유는 디스크 I/O가 느리기 때문임 ⇒ 현실적인 해결책 - 슬레이브에 SATA SSD 를 사용하는 것
• 마스터 IOPS(1000 이상)와 슬레이브 IOPS(수백)의 차이가 복제 지연을 일으키는 원인이 됨
• 단일 스레드에서 높은 IOPS를 얻는 방법?? ⇒ SATA SSD 이용하기
• 읽기는 매우 빠른 반면(자기 디스크 대신 플래시 메모리로 되어있기에) 쓰기에는 다소 시간이 걸림

• MySQL의 경우 마스터는 RAID 구성(HDD를 여러개 사용)의 HDD를 사용하여 다중 스레드로 병렬 액세스, 슬레이브는 SATA SSD를 사용하여 단일 스레드에서도 충분한 성능이 나오도록 하는 식으로 활용하는 것이 하나의 모범 사례로 되어 있음

데이터베이스 개선의 역사

CPU 확장성 향상

• 프로그램 중에서는 동시에 하나의 스레드 밖에 액세스할 수 없도록 배타 제어를 해야 하는 처리 구간이 존재함 — 임계 영역(Critical Section)

• MySQL 은 mutex를 이용한 배타 제어를 하고 있는데 mutex의 영향이 최소화 될 수 있도록 구현상의 개선은 지속적으로 이루어져 왔음
• 예를 들어 기존에는 데이터 캐시 영역(버퍼 풀) 전체에서 한 개 밖에 없었던 mutex를 각각 16KB의 블록으로 분할함으로써 각 블록에는 병렬로 액세스 할 수 있도록 하는 등의 개선

디스크 I/O 병렬성의 개선

• HDD를 RAID 구성으로 해두면 각각의 디스크가 I/O 의 처리 요구를 취급할 수 있기 때문에 디스크가 한 개만인 경우에 비해 병렬성이 크게 향상될 것임
• SSD에서도 이는 적용됨. SSD는 드라이브가 하나라도 내부적으로는 여러 개의 플래시 메모리로 구성되어 있어 높은 동시성을 발휘할 수 있는 것이 많음

• MySQL의 경우 5.0 까지는 I/O를 담당하는 스레드가 Read/Write 각각 하나씩 밖에 없었기에 병렬성 높지 않았는데 5.1 이후에서는 I/O 스레드 수를 설정에서 늘리도록 되었기에 보다 많은 I/O를 처리하게 되었음

백그라운드 처리의 분할/병렬화

• 어플리케이션에서 실행되는 쿼리의 처리 외에도 백그라운드에서 실행해야 하는 작업이 몇 가지 존재함
• 예: 체크포인트 처리, DELETE 된 레코드를 물리적으로 제거하는 처리(퍼지 작업)
• 이러한 처리가 쌓이게 되면 애플리케이션에서의 작업을 일정 시간 블록 해야 할 필요가 있어 전체 처리량을 크게 낮추는 결과로 이어짐

• 기존에 이러한 백그라운드 처리를 모두 단일 스레드에서 담당 하였지만 MySQL 5.5부터는 제거 처리를 담당하는 스레드를 나눌 수 있게 되었음

• MySQL에서 많은 병렬화가 진행되고 있지만 아직 개선이 되지 못한 부분도 있음 → 그 중 가장 중요하다고 말할 수 있는 것이 지금까지 말해 온 복제의 병렬화

웹 서버의 실행 효율도 중시된다

• 데이터베이스 서버에서 대량의 데이터를 처리할 때 어쩔 수 없이 I/O 병목현상이 일어나 속도가 느려지게 됨

• 거기에 비교하면 웹 서버는 메모리 내부에서 처리되기 때문에 보다 효율적인 처리가 가능함
• 그러한 이유도 있어서 웹 서버보다도 데이터베이스 서버 쪽이 총 비용이 높아지는 경우가 종종 있었음

• 향후 DB 서버 I/O 효율이 극적으로 높아지면 데이터베이스 서버의 대수가 크게 감소하기 때문에 상대적으로 웹 서버 대수가 더 많게 느껴지게 됨 → 웹 서버의 실행 효율이 더 중시되게 될 것

향후 데이터베이스에 요구되는 것

네트워크 및 CPU의 이용 효율이 더 중요하게 된다

• 스토리지가 고속화되어 한 대당 처리 가능한 쿼리 양이 증가하면 당연히 CPU 사용률이 높아짐

• 지금까지는 DB 서버의 병목 현상이라고 하면 디스크 문제로 거의 정해져 있었지만, 앞으로는 그 병목 현상이 점차 네트워크나 CPU 쪽으로 이동할 것으로 생각됨
• 100Mbps 이더넷의 지연 시간은 3,000 마이크로초 정도. 이 정도 환경이면 100개의 연결 점에서 일제히 접근해도 겨우 35,000 쿼리/초 정도 [밖에] 처리할 수 없음
• HDD 병목이 있을 때는 이 정도 쿼리를 처리할 수 없었지만 PCI Express SSD와 같은 고속 스토리지라면 초당 10만 IOPS 이상을 처리할 수 있으므로 네트워크 쪽이 더 느리게 되어 병목현상이 생기게 됨

• 스토리지가 병목현상을 일으키던 시절은 CPU 이용 효율이 나쁜 처리(무거운 문자열 처리 및 계산 처리 등)가 있어도 현실적으로 문제가 되지 않았음. CPU 이용 효율이 나쁜 처리에 의해 그 부분의 처리 시간이 10 마이크로초에서 100 마이크로초가 되었다고 해도 HDD에 의해 5밀리초의 I/O 처리가 발생한다면 그 차이는 무시할 수 있는 범위 였기 때문
• 그러나 SSD의 대두로 스토리지 속도가 고속화되면 5밀리초나 걸리는 처리가 없어지기에 상대적으로 CPU 이용 효율을 무시할 수 없음
• 최근 주목을 끌고 있는 NoSQL은 이러한 CPU 이용 효율의 문제를 해결하는 것이 커다란 목적 중 하나

성능 이외의 중요성이 높아진다

• 성능이 잘 나오지 않을 때 하드웨어를 강화(메모리 증가와 SSD를 채용하는 등)하는 것 만으로 해결하는 경우도 결코 적지 않음

• 이렇게 성능면에서의 과제가 적어지게 되면 당연히 그것 이외의 요구가 상대적으로 높아지게 됨
• 다양한 기능
• 높은 복원력
• 자동화
• 마스터 오류 발생 시 자동으로 Fail Over하는 기능