개요

Altibase를 사용하여 프로젝트를 수행하기 전에, 서버의 구성이 결정되어야 한다. 이 문서에서는 서버 구성에 필요한 CPU, 메모리, 디스크, 네트워크의 용량을 어떻게 산정할 수 있는가에 대해 설명한다.

이 문서는 아래 버전을 기준으로 작성되었다.

• Altibase 5.5.1 이상

CPU 용량산정

CPU 용량 산정은 일반적으로 TPC-C를 기준으로 하여 수행한다. 그에 필요한 항목들과 Altibase에 적용해 할 보정 계수에 대해 설명하고 산출하는 예제를 제시한다.

TPC-C

http://www.tpc.org 웹사이트에 방문하면 각 장비 별로 제공되는 tpmC라는 측정 결과가 있다. 다양한 트랜잭션이 발생하는 환경에서 특정 트랜잭션(New_Order)의 처리량을 기준으로 측정하는 수치인데 이를 기준으로 CPU 용량을 산정한다.

본 문서도 이를 기반으로 산정되는 CPU 용량임을 전제한다. TPC-C에 대한 자세한 내용은 웹사이트를 방문하여 참고하기 바란다.

CPU 용량 산정 기준

TPC-C 수행 환경을 구축하기 어려운 경우 아래 보정 계수를 적용하여 TPC-C 결과를 대신하여 CPU 용량을 산정할 수 있다.

보정 계수의 적용은 요구되는 tpmC 수치에 상황별로 예상되는 가중치를 적용하는 것을 의미한다.

각각의 보정 계수 항목은 아래의 표를 참고한다.

• Altibase 이중화를 사용하지 않는 경우, "이중화 대비 보정" 항목을 적용하지 않는다.
• 메모리 DB만 사용하는 경우가 아니라면, "메모리 DB 보정" 항목을 적용하지 않는다.

분당 트랜잭션 수

분당 트랜잭션 수는 아래와 같이 동시 사용자 수를 먼저 산출한 후 계산해야 한다.

기본 tpmC 보정

TPC 홈페이지에서 제공하는 tpmC는 최적의 환경에서 측정하는 것으로 실제 운영 환경과 차이가 있다.

따라서 실험 환경에서 측정한 tpmC 수치를 복잡한 실제 환경에 맞게 적용하기 위한 보정을 해야 한다. 이를 "기본 tpmC 보정"이라고 하며 고정 값 5를 적용한다.

피크타임 부하 보정

시스템은 일반적으로 평상시보다 피크타임에 약 20% ~ 50% 정도의 과중한 부하를 받게 되므로 이를 고려하여 1.2 ~ 1.5의 가중치를 적용한다.

데이터베이스 크기 보정

전체 데이터베이스 크기와 레코드가 가장 많은 테이블을 고려하여 적용한다.

정확한 값을 도출하기 어려운 경우, 가중치 적용이 불가능하므로 일반값 1.7을 적용한다.

애플리케이션 구조 보정

애플리케이션 구조 보정은 애플리케이션 응답시간에 따른 성능 차이를 감안한 보정이다.

적용값은 아래와 같으며, 기대하는 응답 시간이 5초 이상인 경우에는 적용하지 않는다.

애플리케이션 부하 보정

애플리케이션 부하 보정은 온라인 작업을 수행하는 Peak-Time에 배치작업 등이 동시에 이루어지는 경우를 감안한 보정이다.

정해진 작업 외에 부가적인 작업 (백업, 리포팅, 통계 등)의 처리가 요구되는 경우, 그에 따라 필요한 처리 능력을 보정해야 한다.

적용값은 아래와 같으며, 일반적으로 1.7을 적용한다.

시스템 여유율 보정

예상하지 못한 업무 증가를 대비하여 시스템 안정성을 보장하기 위한 보정이다. 1.3으로 고정되어 있다.

시스템 목표 활용률 보정

일반적으로 데이터베이스 시스템을 설계할 때 CPU 사용률 100% 활용을 목표로 설계하지만, 안정적인 운영을 위해 실 운영 환경에서 CPU를 100% 활용하지 않는다.

시스템 목표 활용률 보정은 실 운영 환경을 기준으로 설정한다. 보통 최대 CPU 사용률 70% 수준이므로  0.7을 적용한다.

이중화 대비 보정

Altibase 이중화를 사용하는 경우에 적용한다.

Altibase 이중화 부하를 처리하기 위한 보정으로 기본값 1.1을 적용한다.

메모리 DB 보정 

디스크 DB와 메모리 DB를 모두 사용하거나 디스크 DB만 사용하는 경우는 적용하지 않는다.

메모리 DB만 사용하는 경우 디스크 DB에 비해 3배의 성능 우위를 가지므로 1/3 = 0.3를 적용한다.

CPU 용량 산정 예시

위와 같은 보정 계수 항목들을 적용하여 아래와 같이 CPU 용량을 산정할 수 있다.

메모리 용량 산정

메모리 용량 산정은 다음의 3가지 항목을 고려해야 한다. 

1. 메모리 DB의 용량 산정
2. 디스크 DB를 위한 버퍼 영역의 크기
3. 세션의 질의문 수행을 위한 메모리

메모리 DB 저장 공간

메모리 테이블스페이스에 생성된 테이블은 32KB 단위의 페이지를 할당받는다. 한 페이지는 다시 해당 테이블의 레코드의 길이에 따라 슬롯(Slot)이라는 단위로 나누어진다. 

따라서, 32KB 단위의 한 페이지는 생성된 테이블이 갖는 레코드의 길이에 따라 여러 개의 슬롯(Slot)으로 나누어진다. 

한 페이지 내의 정확한 슬롯(Slot) 크기나 개수는 Altibase 성능뷰 V$MEMTBL_INFO에서 확인할 수 있다.

메모리 DB 용량 산정

Altibase의 메모리 DB는 모든 데이터와 인덱스를 메모리에 상주시키는 형태이다.

따라서 운영 환경에서 실제 생성할 메모리 테이블 스키마와 예상 레코드 수를 기준으로 산정한다.

다음과 같이 산정할 수 있다. 레코드 헤더 길이는 Altibase 버전에 따라 다르므로 계산에 주의를 요한다.

• 메모리 테이블의 인덱스는 실제 메모리 상의 위치를 가리키는 포인터 정보만 관리하기 때문에 (레코드 건수 * 8byte) 형태로 계산한다. 
  메모리 인덱스 수에 따라 '8byte * 레코드 수 * 인덱스 수' 수식으로 계산할 수 있다.
• 위와 같은 계산식으로 산출된 테이블의 각 예상 크기의 총 합이 메모리 DB의 용량으로 산정될 수 있다. 또한, 이와 같이 산출된 용량에서 30%~50%의 여유율을 고려하여 메모리 DB의 용량을 산정하면 된다.
  (필요한 여유율이 무엇인지는, 아래 "여유율 고려" 부분에서 추가적으로 설명한다.)
• 정확한 레코드의 길이를 파악하려면 테이블을 생성한 후, V$MEMTBL_INFO에서 해당하는 테이블의 MEM_SLOT_SIZE를 조회하면 명확하게 알 수 있다.
• Volitile 테이블스페이스의 경우도, 실제 데이터가 존재하게 되면 메모리 영역을 사용하기 때문에 위와 같은 기준으로 용량 산정에 포함시켜야 한다.
  (Volatile 테이블스페이스에 생성된 테이블의 데이터는, Altibase 서버를 재구동하면 모두 유실된다. Volatile 테이블스페이스의 테이블에 대한 트랜잭션은 
  물리적인 트랜잭션 로그를 기록하지 않고 빠른 임시 처리를 위해 사용되는 테이블스페이스 개념으로 제공되고 있다.)

디스크 DB의 버퍼 크기

디스크 DB의 버퍼 크기 산정에 대해서는 고정된 계산식이 존재하지 않는다. 

다만, 전체 디스크 DB 중에서 자주 접근될 것으로 예상되는 디스크 DB 크기 대비 10% 이상을 권장한다.

예를 들어, 디스크 DB 중에서 자주 접근되는 데이터의 크기를 100GB라고 산정한다면, 10%인 10GB 이상을 버퍼 크기로 설정하도록 한다.

메모리의 여유율 고려

메모리 용량 산정은 데이터 외에도 다음 3가지 영역의 메모리 사이즈를 고려해야 한다.

1. 질의 정보 및 질의 실행계획
2. 연산을 위한 임시성 메모리 공간
3. MVCC 기법에 의한 별도의 메모리 여유율

질의 정보 및 질의 실행계획

질의 수행 시, Altibase는 내부적으로 최적화된 실행계획으로 질의가 처리될 수 있도록 실행계획 수립 절차를 거치게 된다. 이 실행계획의 수립 및 판단 부분은 질의 처리의 성능에 있어서 매우 비중이 크다.

하지만, Altibase는 동일한 질의에 대해서 매번 실행계획을 수립하는 비용을 줄이기 위해, 내부적으로 이미 수행된 질의에 대한 질의 정보 및 실행계획을 저장하여 관리하고 있다. 그리고 이를 위해서는 세션 메모리 영역이 필요하다.

Altibase에는 크게 2가지 영역의 세션 메모리 영역이 존재하는데, 모든 세션에 공통적으로 활용되는 SQL_CACHE 영역과 세션별로 할당되는 메모리 영역이 그것이다.

SQL_CACHE의 크기는 동적으로 크기가 늘어나지 않기 때문에 질의에 대한 실행계획을 모두 저장할 수 없을 경우, 세션에 할당된 메모리 영역에 저장하는 구조로 동작하고 있다. 

따라서, 메모리 용량을 산정할 때 세션에 할당될 메모리 공간도 함께 고려되어야 한다.

임시성 메모리 공간

메모리 DB에서 group by, aggregation 등이 포함된 질의가 수행될 경우, 원천 데이터에서 사용자가 요구한 질의 결과로 가공하기 위해서는

중간 결과셋을 저장하는 별도의 저장 공간을 필요로 한다. 임시성 메모리 공간이란, 이때 사용되는 별도의 저장 공간을 의미한다.

(디스크 DB의 경우는, 기본적으로 디스크용 Temp 테이블스페이스를 사용하나, 성능 개선을 위해 힌트 등을 사용하여 메모리 영역을 사용하게 할 수 있다.)

결과적으로, 이 영역은 명확하게 산술적으로 계산하는 것이 불가능하다. 사용하게 될 임시성 메모리 공간의 증가 정도는 질의의 유형에 따라, 데이터의 크기에 따라, 동시에 수행되는 질의에 따라 매우 유동적이기 때문이다.

단, 할당된 이후에는 지속적으로 재사용이 되기 때문에 적절하게 산정하면 전체 메모리 산정에 있어 크게 영향을 주지는 않는다.

MVCC 기법에 의한 별도의 여유율

Altibase는 변경 트랜잭션 진행 중에 조회 트랜잭션이 발생할 경우, 두 트랜잭션 간의 경합을 최소화하여 성능을 극대화하기 위해 MVCC라는 동시성 제어 기법을 사용한다.

그리고 이 MVCC 기법을 사용하기 위해, 테이블 내에 버저닝(Versioning)된 데이터의 이전 이미지를 임시적으로 저장한다. (MVCC에 관한 자세한 설명은 "MVCC 가이드" 문서를 참고한다.)

따라서, 메모리 용량을 산정할 때 MVCC를 위한 여유율도 함께 고려되어야 한다.

메모리 용량 산정의 예

메모리 테이블을 1년에 100만 건씩 증가되는 형태로 10년을 보관한다고 전제하면, 다음과 같이 용량 산정을 할 수 있다.

위 테이블은 다음의 SQL문을 통해 레코드의 길이를 확인할 수 있다.

Altibase는 메모리 자원에 대한 관리 차원으로 8byte align을 한다. 즉, 8의 배수로 나누어지지 않는 크기는 그보다 큰 8의 배수로 관리된다.

따라서, 레코드의 길이가 282byte라면 align 규칙에 의해 288byte를 하나의 레코드 길이로 산정해야 한다.

위와 같이 레코드의 길이를 파악하였다면, 다음과 같은 표로 계산이 가능하다. Altibase 5, Altibase 6과 Altibase 7을 분리하여 계산한다.

위와 같이 테이블 별로 입력 데이터가 만들어지면 데이터와 인덱스에 대한 용량을 산정하는 것이 가능하다.

그리고, 데이터와 인덱스에 대한 용량이 산정되면 아래와 같이 전체 필요 메모리 용량을 계산할 수 있게 된다.

이러한 메모리 용량 산정은 순수하게 Altibase의 용량만 산정한 것이다. 만약, 동일한 서버 내에 사용자 응용프로그램까지 운영할 계획이라면, 그 부분에 대한 별도의 용량 산정도 반드시 진행되어야 한다.

디스크 용량 산정

디스크 용량은 다음의 4가지 항목을 고려해야 한다. 

1. 메모리 DB의 예상 공간
2. 트랜잭션의 로그파일 공간
3. 디스크 DB의 예상 공간
4. 디스크 DB의 백업 공간

메모리 DB의 예상 공간

Altibase는 갑작스러운 장애가 발생할 경우라도 메모리 상에 변경된 데이터를 다시 복구할 수 있도록 주기적으로 메모리 DB의 내용을 물리적인 데이터파일로 저장한다.

이러한 과정을 체크포인트라고 하며, 이 과정에서 생성되는 데이터파일의 용량은 메모리 DB의 크기로 생성이 된다. (체크포인트의 자세한 과정은 "Altibase 체크포인트 가이드" 문서를 참고한다.)

이때 생성되는 파일은 각각 1벌씩 2개의 파일로 생성되기 때문에 디스크 용량에 있어서는 메모리 DB 용량의 2배수를 필요로 한다. 

트랜잭션의 로그파일 공간

Altibase는 WAL(Write-Ahead Logging) 프로토콜에 의한 회복 기법을 수행하기 위해 트랜잭션에 대한 로깅을 수행한다. 

이때 수행되는, 로그의 기록 과정에서 물리적 파일에 저장 공간을 요구하게 되며 이렇게 기록되는 파일들을 온라인 로그파일이라고 부른다.

온라인 로그파일들은 체크포인트가 발생하면 자동적으로 삭제가 되지만, 경우에 따라서는 삭제가 되지 않고 유지될 수 있다. 다음과 같은 경우가 그에 해당한다.

• 이중화 환경에서 Sender가 보내야 할 로그를 보내지 못하고 유지하는 경우
• 대량의 변경 작업의 발생으로 트랜잭션이 장시간 유지되는 경우

어떠한 이유로든, 온라인 로그파일의 지속적인 유지로 인한 디스크 용량 부족 장애가 발생하는 것은 방지해야 하므로 가능한 안정적인 공간을 확보하는 것을 권장한다.

하지만, 온라인 로그파일을 위한 디스크 공간은 일반적으로 계산식에 의해 권장하기 어렵다.

시스템의 규모에 따라 유동적이기 때문에, 성능 부하 테스트 등을 통해서 생성되는 로그파일 양의 수치와 같은 자료를 기반으로 산정하는 것이 바람직하다.

만일, 이와 같은 테스트를 진행하기 어려운 경우라면 최소한 20GB 이상의 디스크 공간을 권장한다.

디스크 DB의 예상 공간

디스크 DB는 메모리 DB의 용량 산정 방법과 달리, 페이지 단위의 산정을 권장한다. 각 페이지당 PCTFREE와 PCTUSED의 속성에 따라서, 저장 가능한 공간의 제약이 발생하기 때문이다.

Altibase의 한 페이지 크기는 8,192byte이다. 여기서 각 페이지마다 PCTFREE의 설정을 계산한 페이지의 공간을, 레코드를 위해 사용 가능한 공간으로 계산한다.

레코드 및 인덱스의 헤더 길이는 아래와 같다. 메모리 DB와 다르게 디스크 DB는, 인덱스에 구성된 컬럼의 길이가 용량 산정에 고려되어야 한다.

• 각 컬럼 별로 길이 정보를 위한 1byte를 지닌다. 만약 250byte 이상의 컬럼이면 3byte의 길이 정보를 위한 헤더를 지닌다.
• 페이지 내에서 정확한 Offset 정보를 빠르게 알기 위한 Slot Directory 영역을 저장될 공간에 포함하여 계산한다.

디스크 DB의 용량 산정은 다음과 같이 수행한다. (인덱스는 키를 구성하는 컬럼의 길이를 합산해야 한다.)

페이지당 들어갈 수 있는 레코드의 수를 구하면 그 값으로 예상 건수에 대해 필요로 하는 페이지의 수를 구할 수 있다.

그런데, 실제 사용되는 페이지는 8,192byte 단위이므로 최종 산출에서는 8,192byte를 곱하여 용량을 산정한다.

인덱스의 경우에도 위와 같이 산정하는데, 인덱스를 구성하는 키 컬럼의 길이를 레코드의 길이로 적용해서 계산하면 된다.

헤더는 인덱스의 헤더 16byte를 이용하면 된다.

위와 같이 모든 디스크 테이블에 대한 용량을 구하게 되면, 총합을 계산한 후 30%~50%의 여유율을 고려하여 용량을 산정한다.

디스크 DB의 언두 테이블스페이스와 임시 테이블스페이스

언두 테이블스페이스

디스크 DB의 언두 테이블스페이스는 변경된 이미지의 복제 본이 트랜잭션의 종료 시점까지 임시로 저장되는 공간으로 사용된다. 

따라서, 사용자가 요구한 질의 처리에 따라 사용량이 변화하기 때문에 사용량을 예측하기 어렵다.

예를 들어, 1TB의 테이블을 한번에 Update 하는 트랜잭션이 발생하면, 1TB만큼 언두 테이블스페이스가 필요로 한다.

이와 같은 최악의 경우를 고려하지 않는다면, 일반적으로 가장 용량이 큰 테이블의 30% 정도를 언두 테이블스페이스 용량으로 산정하는 것이 바람직하다.

임시 테이블스페이스

임시 테이블스페이스 역시 질의의 유형에 따라 사용량이 변화하기 때문에 사용량을 예측하기 어렵다. 

따라서, 언두 테이블스페이스와 동일하게 가장 용량이 큰 테이블의 30% 정도를 임시 테이블스페이스 용량으로 산정하도록 한다.

언두 테이블스페이스와 임시 테이블스페이스는 충분한 공간을 산정하여, 운영에 문제가 없도록 해야 한다.

디스크 DB의 백업 공간

백업과 관련된 자세한 사항은 "Altibase 백업 및 복구 가이드" 문서를 참고하도록 하며, 여기에서는 백업과 관련된 용량을 산정하는 부분에 대해서만 설명한다.

Altibase의 백업을 위해서는 반드시 아카이브 로그 모드로 운영을 해야 하고, 그러기 위해서는 2개의 디스크 공간이 요구된다.

백업 공간의 경우는, 예측된 메모리 DB와 디스크 DB 용량의 총합으로 산정하면 된다.

매번 전체 DB를 백업하는 형태와 증분 백업 형태, 테이블스페이스 단위 백업 형태 등 백업 형태가 다양하기 때문에 각 백업에 알맞은 공간을 산정하도록 한다.

아카이브 로그파일 디렉토리의 경우, 사용자가 백업을 완료한 시점 이후에 참조되지 않는 이전 로그파일은 모두 삭제해도 무방하다. 

따라서, 백업 주기와 정책에 따라 보관되는 로그파일 용량이 다를 수 있기 때문에 백업 정책에 따라 유동적이라고 할 수 있다.

다음의 예를 통해 알아보자. 아래의 예에서 백업 정책은 1일 단위로 가정한다.

• 메모리 DB는 체크포인트 시에는 1벌(2개의 파일)로 저장이 되지만, 백업 단계에서는 안정적인 1개의 파일만 백업되기 때문에 메모리 DB 용량 만큼 백업 공간을 고려하면 된다.
• 디스크 DB는 전체 백업 정책으로 가정할 경우, 예상되는 디스크 DB의 용량 만큼 백업 공간이 필요하다.
• 아카이브 로그파일은 다음 백업 발생 때까지 보관이 되어야 이전에 백업한 백업본을 이용하여 현재 시점까지 복구가 가능하기 때문에, 백업 주기의 기간 동안 발생된 아카이브 로그파일이 모두 저장 되어 있어야 한다.
• 백업 주기 개념으로 보면 현재 백업이 성공해야 직전 백업본을 삭제할 수 있음으로, 직전 백업본까지 디스크에 유지할 경우 2배의 백업 필요 공간이 요구된다.

iloader를 통한 백업 활용 시 고려 사항

온라인 백업 방법에 더해 부가적으로 테이블 별로 백업을 받는 것이 필요한 경우, iloader라는 유틸리티를 사용하여 텍스트 형태의 파일로 테이블을 백업 받을 수 있다.

이러한 경우에는 디스크 용량 산정 시에 iloader를 통해 백업된 데이터 파일의 용량을 고려해야 한다.

일반적으로 5byte 정도의 데이터 구분자를 컬럼마다 사용해야 하기 때문에 실제 예상된 디스크 DB의 용량에 추가적으로 다음과 같은 산술로 나온 공간이 필요로 한다.

즉, 최초에 산정된 디스크 DB의 용량에 추가적으로 구분자 용량이 필요로 한다는 의미이다. 

또한, 압축하여 디스크 내에 보관할 경우에도 위에서 산정한 용량 대비 압축률을 고려하여 보관될 공간의 크기도 산정해야 한다.

이 부분은 아래 디스크 용량 산정 예제에 추가하지 않음으로, 사용자가 이 방법의 백업을 선택할 경우 반드시 고려하기 바란다.

디스크 용량 산정 예제

네트워크 용량 산정

본 문서의 네트워크 용량 산정 부분은 단지 이중화만을 고려한다. 사용자는 반드시 서비스 망까지 고려하여 네트워크 용량을 산정해야 하며, 본 문서에서 다루는 이중화 네트워크 용량도 전체 네트워크 용량 부분에 추가해야 한다.

이중화에 의한 패킷 사이즈

이중화로 패킷을 보낼 경우, 트랜잭션의 유형별로 다음과 같은 계산식이 가능하다.

위와 같이 각 트랜잭션 별로 기본적인 헤더를 가지고 있으며, 전송되는 데이터에 대하여 컬럼별 길이 정보와 실 데이터의 길이를 모두 합산한 크기만큼 패킷을 전송한다.

이중화 환경에서 Insert는 모든 컬럼 데이터를 보내야 하고, Update는 변경된 컬럼 데이터의 이전 정보와 변경 정보만 보내면 된다. 그리고 Delete는 삭제 대상이 되는 데이터의 PK데이터만 전송하면 처리가 가능하다.

위의 계산식을 이용하여, 10개의 컬럼을 갖고 있는 이중화 테이블에 300byte 크기의 데이터 입력이 초당 10,000tps 성능으로 처리가 되어야 한다면 아래와 같이 계산할 수 있다.

위와 같은 환경에서, 사용자 요구사항을 충족시키기 위해서는 Insert 트랜잭션 기준으로 3.66Mbps의 네트워크 속도가 보장되는 환경을 필요로 한다.

실제 환경 구축에서는 데이터의 증가나 기타 요인에 대한 보정 계수가 적용되어야 한다. 여유율 측면에서 최소 30% 증가된 네트워크 환경 구축을 권장한다.

이중화의 네트워크 카드는 가능한 Giga-bit 카드를 권장하며, Cross-cable을 이용한 직접적인 연결 또는 Private망으로 구성하는 것을 권장한다.

단, 근거리가 아닌 경우에는 사용 가능한 네트워크 대역폭 내에서 이중화가 지연 없이 처리가 가능한지를 사전에 고려해야 한다.

요약

지금까지 Altibase에 필요한 CPU, 메모리, 디스크 및 네트워크의 용량 산정 방법을 알아보았다.

하지만 데이터베이스 시스템 용량을 산정할 때에는 각 항목별로 고려할 사항이 적지 않기 때문에, 실제 시스템을 구성할 경우에는 사전에 충분한 데이터의 검토를 통해 가장 적합한 구성 방법을 찾는 것이 바람직하다.

참고자료

• 한국정보통신기술협회(TTA) - 정보시스템 하드웨어 규모 산정 지침
• 한국정보통신기술협회(TTA) - 정보시스템 하드웨어 규모 산정 지침 자료 (TTAK.KO-10.0292/R2)