테크 블로그 TechBlog

 

 

안녕하세요.

DX본부 클라우드 2팀에서 DBA로 근무 중인 문광모 매니저입니다.

 

이번 편에서는 실시간 데이터 복제 편으로 SharePlex for Postgres 적용하면서 경험한 내용들을 써보겠습니다! 

 

글재주가 부족하지만 재밌게 봐주시면 감사하겠습니다. 

 

2023년 하반기부터 시작된 탈 Oracle 프로젝트! 

GSSHOP MC/PC 메인 DB로 기간계DB로부터 CDC(SharePlex) 동기화되는 고객, 상품, 쿠폰, 프로모션 데이터와 매장/딜, 주문서, 장바구니 데이터, WithNet(API포함) 데이터로 구성 MC/PC 외 약 100여 개의 Application에서 사용하는 WEB DB입니다. 

 

SharePlex 제품은 온 프레미스, 클라우드 및 오픈소스 환경을 위한 이기종 데이터베이스 복제 솔루션입니다. GSSHOP 메인 DB에서 발생하는 데이터를 SharePlex for Oracle 을 통해서 WEB DB로 실시간 데이터 동기화를 하고 있습니다.(238개 테이블 데이터)

AS-IS 아키텍처

TO-BE에서는 IDC에서 AWS 클라우드로, Oracle에서 Postgres로 변경되면서 SharePlex for Kafka / SharePlex for Postgres / AWS MSK 3가지 아키텍처에 대해서 고민하였고, 기능 검토 및 테스트를 통해 범위를 좁혀 갔습니다.

 

특정 컬럼만 복제할  것인지, 복제 중에 로직이 필요한지, 공통 테이블의 복제 여부와 판단, 관리는 어떻게 할 것인지, 성능은 어떠한지, 안정성 및 적용 사례는 있는지 등등 여러 방면으로 검토한 끝에 저희 시스템에 가장 적합하다고 판단되는 SharePlex for Postgres로 선정하고 개발계부터 적용하여 테스트 진행하였습니다.

 

Source DB는 그대로 IDC에 있고, Target DB만 AWS RDS로 변경! (SharePlex 제품을 Source DB에 설치할 수도 있고, 저희처럼 EC2에 별도로 구성할 수도 있습니다)

 

Source DB 서버에 올릴 경우에는 엔진이 2개가 되는 만큼 Source DB의 Resource를 사용하기 때문에 이를 방지하고자 중계서버(AWS EC2)에 올리게 되었습니다.

TO-BE 아키텍처

기존 AS-IS에서는 DB 서버 안에 제품이 있어서 빠르게 Capture 및 Import 가 되었지만 변경된 아키에서는 DB 서버에서 분리되다 보니 Target 서버에서 Import 시 기존보다 늦어질 수밖에 없었고, 또한 IDC에서 내부 통신하던 Network 구간이 AWS RDS로 오면서 Network Hop 많아지고 그로 인한 성능 저하의 문제도 예측해야 했습니다.

 

Network Hop으로 인한 성능은 측정 결과 IDC To IDC 는 1ms 이하, IDC To AWS는 Network Hop 차이로 인해 3~4ms의 성능을 보였습니다.

 

단 건의 경우 이 정도의 성능은 문제가 되지 않지만, 건 바이 건으로 3~4천 회의 데이터를 계속 주고받아야 되는 경우라면 성능 지연이 발생하게 되고, 이로 인한 복제 성능에 문제가 되지 않는지 성능 테스트를 진행하였습니다. (이 편에서 쓰는 건 아니지만... 이 문제로 인해 IDC Oracle <-> AWS Oracle 시에는 db link 동작이 건 바이 건으로 동작하는 경우 심각한 성능 저하가 발생하고 배치의 경우도 같은 로직이라면 성능 저하가 발생합니다.)

 

AWS MSK 세션 진행할 때 타 사이트에서 성능 테스트 결과 초당 4000 건의 데이터를 보낼 수 있는 성능을 보였다고... 저희 환경에서 성능 테스트 결과 초당 1000건까지 무난했고, 2000건 증가 시 점진적으로 밀리는 경향을 보였습니다.

 

다만, 저희가 현재 쓰고 있는 복제 기준으로는 충분했기에 성능은 문제가 되지 않았습니다.(오픈 이후에 기존 IDC의 Backlog(복제 지연) 데이터 수치 보다 현격하게 줄었음을 Backlog 모니터링을 통해서 확인하였습니다. NetWork Hop이 증가했지만 성능이 향상된 이유는 Write/Read 노드 분리에 따른 스펙 변화, SQL 튜닝을 통한 리소스 효율화를 통해서 성능 향상이 되었습니다) Batch 쿼리의 경우는 One Commit으로 인한 복제 지연은 동일하게 발생하고 있고, 이 부분은 Batch Commit 주기 변경이나 SharePlex 복제 안 되는 계정으로 Source/Target DB 개별 입력하는 것으로 개선하고 있습니다.

 

제품에서의 문제점은 초기적제가 되지 않는 것이었습니다. SharePlex for Oracle의 경우는 Oracle SCN을 이용하여 Dump 추출 Target improt를 통해서 초기 적재 + 이후 데이터 적재까지 SharePlex를 통해서 진행할 수 있었는데, Postgres 경우는 이기종 DBMS로 해당 기능을 지원하지 않았습니다.

 

그러다 보니, 데이터 초기 적재는 AWS DMS로 (AWS DMS 작업은 DBA 이준성 매니저님의 엄청난 노력으로...... 피나는) 오픈 당일에는 Application, DB, AWS DMS 종료를 확인하고 SharePlex로 전환하는 방식으로 적용하게 되었습니다.

 

Oracle To Postgres로 전환하기 위해서 노력하신 수많은 개발자분들과 DBA분들 그리고 업무 팀장님들, 인프라 담당하는 클라우드 팀, 보안 팀 모두 합심하여 노력한 수개월!!!(너무 고생 많으셨습니다)

 

드디어 대망의 오픈날 (설날 전날.....인건...^0^)

크고 작은 문제들을 해결해 가면서 시스템 오픈!! 

 

오픈 이후에도 여러 가지 문제들이 있었지만 즉각 대응하며 안정화를 지속적으로 하였습니다. (설날 내내.. 고생하신 개발자분들.. PG 전환에 연관된 모든 분들 모두 고생 많으셨습니다.)

 

관련 내용들이 많으나.. 이번 편은 SharePlex 편이므로.. 다른 분께 내용은 넘기며 오픈 이후 발생한 SharePlex 편만 이어서 작성하도록 하겠습니다.

 

오픈 일주일 전 SharePlex에서 이모지 데이터 복제 시 Queue Down 문제가 확인되어서 해당 문제를 Global SR 오픈하고  저희 나름대로는 이모지 데이터가 많지 않다고 판단, 이후 이모지 발생 시 대처 방안 수립하고 이모지 테이블들의 단독 Queue 분리를 통해 다른 테이블은 영향받지 않도록 사전 조치를 한 상태였습니다.

 

수 많은 이모지 데이터들..

이모지 데이터 입력시 에러: UTF8

 

그러나, 실제 오픈 이후 생각보다 많은 곳에서 이모지 데이터들이 발생하게 되었고 이모지 발생 시 Queue Down 되고, SharePlex Queue에서 해당 데이터를 강제적으로 삭제해야만 그 이후 데이터 복제가 가능했습니다.

 

오픈 당일 바로 발견된 테이블 2개에 대해서는 Queue에서 데이터 삭제 이후 재복제 처리하였지만 이모지 데이터가 또 발생되어 계속해서 Queue Down 되는 상황이 발생되었습니다.

 

더 이상 SharePlex 복제가 힘들다고 판단하고 SharePlex에서는 복제 제외 처리, 개발 담당자분은 Application 수정을 통해서 Source/Target DB 데이터 동시 입력으로 변경하여 적용하였습니다. (이 자리를 빌려서 고생 많이 하셨던 유경희 매니저님, 조용호 매니저님 고생 많으셨습니다.)

 

오픈 이후에도, 설날에도 동일 문제들이 발생되어 이모지 데이터 발생 시 Queue Down 되지 않고 해당 SQL만 실패하도록 Workround를 설정을 적용하게 되었습니다. (해당 문제로 인해 오픈 이후 최대로 큰 장애를.. 너무 죄송합니다.  PG 전환 잘하고 SharePlex 복제로 인한 장애로..😭😭😭😭😭)

 

Quest Soft에서는 SharePlex for Postgres적용 사례가 많다고 했지만.. 이런 것들을 보면 많지는 않았던 거 같습니다. 이 밖에도 문제들이 많아서...

 

결론적으로는, 오픈 당일 2개 테이블 이후에 9개 테이블에서 이모지 복제로 인해서 SQL Error 발생하게 되었고 발생 이후  담당 개발자분들이 빠르게 Application 수정하고, SQL Error 발생 시 Teams 알람 연동, 데이터 확인 이후 보정 조치를 통하여 더 이상 장애는 피할 수 있었습니다.

근본적인 해결을 위해서는 SharePlex 제품 Patch 가 진행되어야 하지만, 해당 문제 수정에 다른 문제들까지 연결돼 있어서 Patch 제작이 쉽지 않은 상황이었습니다. 제품 Patch를 하지 않고 해결할 수 있는 방안으로 중계서버에서 언어를 한번 변경시켜주는 기능을 적용하게 되었습니다. 이모지 데이터 복제 시 에러 문제는 Source DB의 언어 셋(UTF-8) 설정이 문제였으며 이를 해결하기 위해서 중계서버에 Oracle Client를 설치하고 파라미터 적용(AL32UTF8)을 통해서 이모지 복제 처리가 되도록 수정하였습니다.!!! (길고 길었습니다...)

 

가장 시급했던 문제를 해결하고 기쁨도 잠시, 큰 문제는 아니지만 해결해야 될 문제들이 아직 있었으니..

 

SharePlex로 복제되는 Target 테이블에 트리거 설정이 되어있는 경우 트리거를 통한 날짜 데이터가 Asia/Seoul 날짜가 아닌 UTC로 입력되는 문제가 있어서 있었고, 이를 해결하기 위해 임시방편으로 트리거 구문에 SET TIMEZONE = 'Asia/Seoul' 추가 이후 재생성으로 해결하였고, Global SR에서는 원인 파악을 하고 있습니다.

 

또한... Postgres에서는 Transaction 처리 이후 종료가 되지 않으면 파라미터 설정(30분~2시간 설정)에 의해서 강제로 종료시키게 되는데 SharePlex에서 연결된 세션들이 trsancation 처리 이후 내부 SQL를 수행하고 종료 처리가 되지 않는 현상이 발생..... 이로 인해서 세션을 강제로 종료시키면 Queue Down 되었습니다. 우선적으로 Queue는 재기동되도록 설정하여 데이터 문제는 없으나 해당 문제가 계속 적으로 발생하고 있고, 이 문제는 SharePlex에서 세션 종료 처리를 안 한 문제로 확인이 되어 제품 Patch가 예정되어있습니다. 😭 (한 번에 Patch... 했으면)

 

또 또한... Postgres DB에서 쿼리의 실행계획을 모니터링하기 위해서 QPM 기능을 적용하였는데, 실행계획 수집 임계치가 MAX에 도달하여 Query 수행 시 더 이상 실행계획이 수집되지 않는 경고성 메시지가 나오게 되었습니다. SharePlex에서는 이 경고성 메시지를 에러로 처리해서 큐가 Down 되는(... 왜 이러지...) 문제가 발생하여 이 또한 제품 Patch 예정입니다. (* QPM은 쿼리 수행 시 실행계획을 기록하고 승인하고, 좋은 실행계획으로 Query 수행이 될 수 있도록 하는 기능입니다.)

 

여담이지만, Postgres DB 오픈 이전에 Quest Soft 제품 최고 책임자가 분께서 미국에서 GS강서 타워로 직접 방문하여 SharePlex for Postgres 많이 사용되고 있고 문제가 될 게 없다. 만약 문제가 생긴다면 2주마다 Patch 가 제작되고 있으며 GS리테일의 오픈에 많은 관심과 지원을 해주겠다고 하고 가셔서 믿음이 많았으나....( Richard Schiller 잘 계시죠^^?)

 

현재 상황을 보면... 다른 곳 보다 먼저 경험을 한 것 같다... 다른 곳에서 사용할 때는 이러한 문제들이 Patch 된 버전으로 잘 사용하시기를^^....

 

길고 길었기에... 요약한다고 요약했으나 많이 길어졌습니다. SharePlex Backlog 수집, Teams 연동, 모니터링 방법에 관한 내용들도 많이 남아 있지만 너무 길어질 것 같아서 이 편에서는 이만 마무리하겠습니다.  

 

긴 글 읽으시느라 고생 많으셨고 읽어주셔서 감사드립니다.

 

항상 고생하시는 GS리테일 임직원 여러분 모두 리스펙트 하고 존경합니다!!

 

이상 글을 마치겠습니다.

 

---

 

 

문광모 KM | DX본부 > 홈쇼핑 DX부문 > 클라우드팀 

이기종 DB(Oracle, Exadata, Postgres, Mysql, AWS RDS) / META / SmartDBA / DB 관련된 업무를 담당하고 있습니다.

안정적인 DB 운영에 초점을 두고 설계부터 운영까지 함께 하는 것을 좋아합니다. ^^ 

---