Sequence order 옵션에 따른 성능

본 포스트는 오라클이나 티베로에서 시퀀스의 cache 및 order 옵션 조합에 따른 성능 개선에 대한 글입니다.

 

운영하고 있는 시스템이 여러가지 사유들로 거래량이 제법 큰 폭으로 증가했었습니다. 증가한 범위가 어느 정도는 용량 산정 시 계산한 여분이 허용하는 범위로 큰 문제는 없어야 하지만, 거래가 집중되는 시간에  간혹 DB의 CPU가 임계치를 조금씩 초과하기 시작했습니다.

 

Maxgauge로 분석해보니 특정 Sequence를 채번하는 nextval Query의 CPU Time이 전체 CPU Time의 많은 비율을 점유하고 있었습니다. 정상적이지 않은 시그널임에는 분명했지만 거래가 몰리는 시점에만 발생하는 현상이라 우선순위를 나중으로 좀 미루어 둔 상태였습니다.

하인리히의 법칙 (1: 29: 300의 법칙)
어떤 대형 사고가 발생하기 전에는 같은 원인으로 수십 차례의 경미한 사고와 수백 번의 징후가 반드시 나타난다는 것을 뜻하는 통계적 법칙

잠시 미루어 둔 사이 여러가지 사유로 다시 제법 거래량이 증가하면서 바로 문제가 수면 위로 노출되었습니다. 거래가 몰리는 시간대에 DB CPU가 100%를 치면서 nextval의 속도가 느려지기 시작했습니다.

 

해당 Sequence는 기간 시스템과 인터페이스하는 전문의 추적번호를 채번하기 위해 사용하는 Sequence로, nextval의 성능이 저하되면서 전체 시스템의 성능이 저하되고 응답 시간이 지연되는 큰 문제로 전개되었습니다.

 

임시 조치

결국 잠시 유량 제어 (일정 비율로만 거래를 통과시킴)를 통해 시스템의 과부하를 방지 했습니다.

 

원인 분석

메타 정보인 dba_sequences의 정보를 조회해보니 해당 sequence의 옵션은 cache + order 옵션으로 구성되어 있었습니다. cache 및 order 옵션에 대한 설명은 아래를 참고합니다.

Cache
설정되어 있는 수만큼 해당 sequence의 NEXT_VAL을 증가시킨 후 cache로 가져오고, nextval 명령을 수행할 때에는 미리 채번해 둔 cache의 값을 사용합니다.

 

Order
nextval 명령의 호출 순서에 따라 채번되는 sequence의 순서를 보장합니다. 단순히 Unique 한 값을 채번하는 것이 목적이 아닌 순서를 보장해야 하는 업무의 경우 Order 옵션을 사용해야 합니다.

 

이중화 환경에서 cache와 order 옵션에 따라 sequence는 아래와 같이 동작합니다. 운영 중인 시스템은 티베로를 사용하므로 TAC 환경에서의 동작이며 Oracle RAC도 동일하게 동작합니다.

Cache + Order
전체 node에서 하나의 sequence cache를 동기화하여 사용하므로 순서가 보장됩니다. 매번 순서 보장을 위해 wait lock을 잡고 순번을 채번합니다.

 

Cache + NoOrder
각자 node에서 따로 sequence cache를 사용하므로 각 node 개별적으로 순서가 보장되지만 전체 node에서는 순서를 보장하지 않았습니다. 각 node에서 미리 채번해 둔 cache를 모두 소진하여 다시 cache로 가져올 때만 wait lock을 잡으며, 다른 경우에는 잡지 않습니다.

 

NoCache
cache를 사용하지 않습니다. 매번 메타 정보를 변경하므로 항상 순서가 보장됩니다.

문제 해결

현재는 Cache + Order 방식으로 동작하므로 매번 wait lock을 잡고 채번하므로 거래가 집중될 경우 CPU 점유율이 증가하는 형태였습니다. 하지만 전문 추적번호라는 업무 성격은 Unique 한 성격만 요구할 뿐 반드시 순서가 보장되어야 하는 형태가 아니므로 Cache + NoOrder 옵션으로 변경하기로 하였습니다.

 

현재 운영 중인 시스템이고 거래가 많은 시스템이라 온라인 중에는 Sequence의 속성을 변경하기고 힘들어서 별도의 Sequence를 생성한 후 애플리케이션에서 사용할 sequence를 변경하는 형태로 작업을 진행했습니다.

 

대용량 시스템은 거래가 많이 발생하기 때문에 언제나 세세한 최적화가 필요해 보입니다.