"올리브영에 고객서비스 만족 위한 안정적인 클라우드 인프라 제공"이라는 [오라클 공식 발표]처럼

올리브영은 기존 물리 DB(IDC) 환경에서 오라클 클라우드 DB 환경으로 이사했습니다.

주문 스쿼드에서는 어떻게 사전 점검하여 안전하게 전환할 수 있었는지 이야기해 보겠습니다.

오라클 클라우드? OCI?

오라클에서 제공하는 클라우드 환경의 DB 서비스로 - OCI (Oracle Cloud Infrastructure)로 scale up / scale out을 통해 더 많은 자원이 필요할 때 물리 DB보다 더 유연하게 DB 사용할 수 있는 서비스로

올리브영을 이용하는 사용자는 계속해서 많아지고 제한된 자원에서 DB튜닝 및 분리 작업을 해도 물리적인 DB로는 서비스에 한계가 있어서, 상황에 맞게 자원을 높이고 줄일 수 있는 오라클 클라우드로 전환하게 되었습니다.

주문에서는 전환을 위해 무엇을 해야 하나요?

DB 이관 작업을 해보신 분들이라면 아시겠지만 이 작업, 결코 쉽지 않습니다.

DB 이관하고 주문처리가 안 되면 결국 사용자들은 최악의 구매 실패 경험을 하게 됩니다.

안전하게 DB 이관 작업을 하기 위해 주문 서비스에서는 무엇을 사전에 점검해야 할지 크게 3가지로 정리했습니다.

1. 주문과 관련하여 DB 링크를 사용하는 곳이 있는가?
2. OCI DB를 통해 주문 처리가 정상적으로 되는가?
3. OCI DB로 인하여 주문 처리 속도에 지연이 발생하는 부분은 없는가?

위에서 1번은 DB 링크를 사용하는 서비스를 찾아서 변경 / 방화벽 등을 사전 조치하였고, 2번은 주문 전체 기능 QA를 진행하여 이상 유무를 점검하였습니다.

마지막으로 3번, 주문 서비스는 주문정보처리 / 쿠폰사용처리 / 본품&증정품 재고 처리 등등의 작업이 복잡한 트랜잭션으로 처리가 되고 있고, 한 부분에서 DB 수행 지연 또는 Lock 등이 발생하면 전체적인 서비스에 영향이 발생할 수 있어서 주문 서비스에 대한 성능 테스트가 필요하다고 판단했고,

기존 물리 DB에서 처리되는 속도와 TPS를 OCI에서도 커버가 되는지 성능측정을 통한 안정성 확보를 위해 성능 측정을 했습니다.

주문 서비스 - 성능 측정 준비

성능 측정은 어떻게 할 것인가?

• 측정 대상 :

   주문서에서 결제하기 클릭하면서부터 최종 주문 성립까지 완료되는 구간을 측정 대상으로 선정

• 목표 사항 :

   "TO-BE OCI DB를 통한 주문처리 속도 & TPS, Response Time" Better than "AS-IS 물리 DB에서의 주문처리 속도 & TPS, Response Time"

• 측정 도구 :

   1차 - Local 환경에서 Jmeter로 성능 측정 시 애플리케이션에서 처리해야 하는 부분이 있는지 체크
   2차 - 올리브영 쿠폰 서비스의 마스터이신 Rey님께서 AWS Sandbox에 구성해 주신 nGrinder를 통해 실제 성능 측정 진행

• 측정 시 유의 사항 :

   외부 기관에 트래픽 전달되지 않도록 조치
   당연한 이야기지만 외부 기관에 성능 테스트용 트래픽을 전달하게 되면 외부기관에 장애로까지 연결 될 수 있기 때문에 통신을 보내지 않고 내부에서 정상응답 처리하여 다음단계로 진행될 수 있도록 최소한의 수정

• 측정 방법 :

   단일 상품 / 복합상품 / 복합상품 + 증정품등의 총 4가지 케이스로 주문 처리 성능 측정

• 측정 환경

   AS-IS 환경 : 물리 DB Cpu 2 Core
   TO-BE 환경 : OCI DB Cpu 8 Core
   위와 같이 셋팅하게 된 배경은 아래 core factor에서 추가 설명 드립니다.

AS-IS vs TO-BE - core factor

물리 DB CPU 1개의 core가 OCI DB CPU 몇 core와 상응하는지 사전에, Oracle에서 제공하는 Core Factor 자료를 통해 확인하였습니다.

Oracle Processor Core Factor Table에 따르면 기존 저희가 사용하고 있는 물리 DB는 IBM 장비로 Core Processor Licensing Factor는 1이고, 이관 대상인 OCI DB는 0.5입니다.

풀어서 설명하면 '물리 DB 1core는 OCI DB 2core와 같다'입니다.

단순 Factor 외에 OCI DB의 구성 차이가 있어서 (Cloud, RAC 구성 환경 차이로) AS-IS 1 core 당 TO-BE 4 core 수준으로 예상하고 QA환경 물리 DB는 2 Core / OCI DB는 8 Core로 셋팅하게 되었습니다.

주문 성능 측정 진행

올리브영을 이용하는 고객님들의 한번 주문 시 평균 상품 구매 SKU가 3개 내외로 아래와 같은 케이스로 성능테스트를 진행하게 되었습니다.

- 단일 케이스 : 상품 SKU 1개 주문
- 복합 케이스 1 : 상품 SKU 2개 / 증정 SKU 1개
- 복합 케이스 2 : 상품 SKU 3개 / 증정 SKU 2개
- 복합 케이스 3 : 상품 SKU 5개 / 증정 SKU 3개

1️⃣ 물리 DB 성능 측정 진행 & OCI 성능 측정 진행

성능 측정은 아래 표와 같이 각 케이스별 TPS와 응답 속도 측정이 완료 되었습니다!

2️⃣ 한방에 성공 했을까?

아닙니다. 역시 DB 버전 올리고 전환은 한방에 되지 않더군요.

왜?

1. 예상했던 물리 1 core = OCI 4 core로 예상했으나, 실제 측정을 해보니 물리 1 core = OCI 5 core가 되어야 동일한 수준의 성능이 나옴을 확인했습니다.

2. 기존 주문 처리에서 많은 쿼리들이 사용되는데, 그중 몇몇 무거운 쿼리의 Plan이 변경되면서 기존 물리 DB와는 다른 양상으로 수행되어 응답속도가 현저히 떨어지는 케이스가 있었습니다.

아래 그림처럼 TPS가 뒤죽박죽인 그래프가 계속해서 반복되었습니다.

그래서 OCI core 증설하고, DBA분하고 같이 쿼리 튜닝하고 나은 속도를 위해서 성능 테스트는 계속 되었고

계속해서 튜닝하고 측정을 반복한 끝에 OCI 환경에 적합한 튜닝 포인트를 찾았고,

그렇게 원하던 안정적인 성능을 확인하여 전환을 진행해도 되겠다고 판단 되었습니다.

OCI 이관!!

그렇게 준비한 대망의 OCI 전환! 과연 잘 되었을까요?

오픈하고, 실제 운영에서는 성능 테스트와 다른 양상으로 일부 쿼리 플랜이 변경되어 수행 되었습니다.

치명적으로 느려지진 않았으나 서비스 트래픽이 높아질 경우를 대비해서 지연되는 쿼리는 바로바로 튜닝을 해주었습니다.

그렇게 튜닝하고 OCI 이관으로 많은 부분이 개선 되었는데 그 중에서도 특히,

기존에 물리 DB에서 아무리 튜닝해도 무거웠던 Heavy Query도 OCI로 이관하면서 튜닝하여 기존 50ms ~ 200ms로 수행되었던 수준의 쿼리가 3~4ms로 획귀적으로 개선 되었습니다.

오라클 클라우드로 DB를 전환하여 올리브영 온라인몰의 오랜 숙명이었던 물리 DB 자원의 한계를 극복하고, 보다 더 나은 서비스를 고객님들께 제공 드릴 수 있게 되었습니다!

저희 올리브영에 유능하신 천재 DBA분들께서 오라클 클라우드로 전환 작업을 성공할 수 있게 해주셨고, 주문 담당자로서 DBA분들과 같이 수행했던 사전 점검기를 간략하게 기재 해보았습니다.

감사합니다!