테크 블로그 TechBlog

안녕하세요. 클라우드팀 백승엽 매니저입니다.

 

 

얼마전, 주문P팀의 결제모듈을 ODS(방송넷)DB에서 SMTC(주문결제)DB 로 이관하며,

 

경험한 것에 대해 나누고자 글을 씁니다.

 

 

한 기업에 DB를 처음 만들게 되면, 

 

점차 시간이 지나 업무 범위가 넓어지고, 필요한 기능이 점차 추가되고 

 

DB의 크기가 커져가면서, DB 내에 많은 업무와 관련된 종속성이 생기고는 합니다.

 

 

물론, 다른 프로젝트나 혹은 기존 업무와 관련된 새로운 DB가 생기면 

 

DB link 혹은 EAI로 연동되고 여러 DB간의 관계 또한 생겨나지만,

 

흔히 말하는 24X7 365로 운영되는 실시간 주요 업무들은 이미 많이 복잡해진 이후라,

 

특정 기능을 이관하려 할때 고려해야할 요소가 많아지고

 

빠른 시간 내 이관이 불가능해지는 경우가 많습니다.

 

 

이번에 이관된 결제모듈의 경우도, DB명은 방송넷DB이지만

 

가장 오래된 DB인만큼 많은 업무가 혼재되어 있었고

 

그 중 홈쇼핑의 결제모듈이 현재 메인으로 불리우는 SMTCDB가 나중에 생성되었음에도

 

아직 빠져나오지 못하고 남겨져 있었습니다.

 

 

ODS DB의 경우, H/W가 Active 서버가 17년, Standby 서버가 15년된 장비로

 

2017년부터 24건의 H/W 장애가 발생중이었고

 

최근 2년간만 해도 7건의 파트교체가 이뤄졌으나 점차 부품 수급도 어려워지는 여건이라

 

안정적인 서비스를 위해서는 해당 DB의 서버교체 및 업그레이드가 시급한 상황이었습니다.

 

 

그래서, ODS 업그레이드 프로젝트 또한 시작하려고 하고 있었죠.

 

 

허나, 아무래도 그 작업의 범위가 크고 시간이 오래 걸리므로 

 

마냥 그 업그레이드를 기다리기 어려웠고, 주문P팀의 결단 및 요청으로

 

가장 최신 서버이자 메인 DB인 SMTC로  "결제모듈이관"을 진행하게 되었습니다.

 

(여담이지만, ODS DB의 업그레이드는 최근 성공적으로 마무리 되었으며 이건... 다른 글로.. 다시... 쿨럭...)

 

 

DB 부분 이관에서 중요한 요소는 여러가지가 있지만 

 

가장 중요한 것은,  타 업무에 영향을 미치지 않아야 하는 것이 첫번째 입니다. 

 

 

결제모듈과 관련된 테이블 및  object들이 이관 되었을 때,

 

해당 테이블을 참조하는 타 업무에 영향도가 있을지에 대한 파악이 되어야 하는거죠.

 

 

GSSHOP 관련 업무 담당자들을 통해 영향도 확인을 실시하였고 

 

다행히도, 영향도가 크지 않아 이관 시의 우려 요소는 없었습니다.

 

 

그 다음으로 중요했던 것은 이관 환경의 일치 여부입니다.

 

대상 DB는 source와 target이 동일한 DBMS인 ORACLE이었지만

 

한 가지 이슈가 Character set이 다르다는 것이었습니다.

 

(Character set은 특정 인코딩으로 나타낼수 있는 문자의 집합을 의미합니다)

 

 

 

ODS DB의 경우 8i version에서부터 이어진 DB였기에

 

한글지원이 2350자까지 지원되는 2bytes 형식의 KO16KSC5601이라는 character set을 사용하고 있었고,

 

이관되어야할 SMTCDB는 11172자를 지원하는 3bytes 형식의 UTF8을 사용하고 있었죠.

 

 

이런 경우, dump 형식으로 테이블들을 이관할 때

 

varchar2, char등의 문자형 데이터 타입에서 오류가 발생하게 됩니다.

 

2bytes로 되어있던 데이터 중, UTF8로 옮겨질 때 3bytes로 늘어나는 문자에서 오류가 발생하기 때문입니다.

 

 

예를 들어 기존에 A라는 테이블에

 

기존 8자리와 40자리였던 테이블의 구조 그대로 옮기면, 

 

기존 2bytes에서 3bytes로 변경되는 특정 문자가 저장될 공간이 공간이 부족하게 되어

 

오류가 발생하게 됩니다.

 

 

그래서, 오류를 방지하기 윈해서는 우선 1차로 테이블의 구조만 이관하고, 

 

문자형 컬럼을 전수 조사해서 char, varchar2 type을 모두 1.5배로 re-size 해주고 

 

다시 dump로 데이터를 import 해줘야 합니다. 

 

 

그런데 말입니다...

 

이렇게 이관을 하면 끝날것 같지만... 여기서 한가지 문제가 발생합니다.

 

 

char type인 컬럼들이 공백이 남게 됩니다. 

 

오류가 발생할 것을 대비해  기존 8자리였던 컬럼을 12자리로 바꿔서 데이터를 넣으면 

 

데이터는 오류없이 들어가더라도 고정형 타입인 char 컬럼은 공백 4자리가 남게 되고, 

 

화면 및 로직에서 빈칸으로 인한 오류가 발생하게 되는거죠.

 

 

이 공백을 해결하려면, 공백을 자동으로 없애면 될 겁니다.

 

아시는 분은 아시겠지만, 오라클이 어떤 DB인가요?

 

 

늘 전세계 RDBMS 점유율 1위를 자랑하는 막강한 DB이니 당연히 이 정도 자동 수정 기능은....

 

 

지원.... 안됩니다... ㅜㅜ (쿨럭...) 

 

 

장인 정신으로 한땀한땀 테이블마다 존재하는 컬럼들 하나하나 모두 수작업 해줘야만 합니다.

 

 

테이블 구조를 바꾸는 명령어인 alter table을 이용한 modify를 떠올리셨을수도 있겠지만

 

이미 사용 중인 테이블을 modify로 column 길이를 바꾸려면, 테이블 내에 데이터가 없어야 합니다.

 

그럼... 결국 데이터를 날려야 하니, 원래 테이블 내에서는 해결할 방법은 없게 됩니다.

 

 

그렇다면, 별도의 테이블을 이용하면 되겠죠 

 

위에서 SMTC로 옮겨온 테이블들은 UTF8로 저장된 데이터들이니

 

이제 길이는 신경 쓰지 않고, 그 데이터를 이용하되 공백만 없애주면 됩니다.

 

 

기존 ODS DB에서의 길이와 같은 임시 테이블들을 생성하고

 

TRIM 함수를 사용하여 공백을 제거한 데이터만 테이블에 다시 넣어주면 되겠죠..

 

 

그리고 그 임시테이블을 원래 이름대로 rename 해서 사용하거나

 

아니면 원 테이블 구조만 만들고 다시 거기다 넣어주는

 

수고스러운 작업만 하나하나 수행해주면 됩니다... ㅠㅠ

 

 

이해를 돕기 위해 실제 쓰였던 SQL을 보여드리자면, 9i DB에서 데이터를 가져온 

 

TB_BP003_TEMP라는 테이블의 char type은 공백이 존재하니,

 

원래 사이즈와 동일한 TB_BP003_TEMP_TTT에 char, varchar2는 TRIM을 적용하고 

 

아닌 컬럼들은 그대로 하나하나 작업해줘야 하는거죠...

 

 

하나하나 확인하고 스크립트 작성하고 이행하는데 걸린 시간만... 슬프네요... ㅠㅠ 

 

 

위 그림처럼, 모든 결제모듈 이관 테이블의 char, varchar2 타입의 컬럼이 포함된 테이블의

 

원래 ODS 때 컬럼 길이를 가진 백업 테이블을 만들고

 

거기에 char, varchar2 컬럼만 확인해서 INSERT~SELECT에 TRIM 함수를 써서 데이터를 넣어주고

 

다시 원래 테이블들의 구조만 가져와서 import 하고난 후 백업 테이블의 데이터를 넣어주는

 

작업을 하고 나서야 이관이 완료가 되었습니다.

 

 

왜 테이블 rename 하지 않았냐고 물으실 수 있는데...

 

테이블만 rename하면 PK, index 및 관련 object의 naming도 다 변경해줘야 하는 수고가 들어서

 

그렇게 하였답니다 ㅎㅎ

 

 

물론, 위 이관 작업 외에도 당연히 많은 확인사항과 작업이 있었습니다.

 

 

이관 대상 테이블 선정 외에도 다른 function, trigger 등의 object 등의 이관도 있었고

 

제휴포인트 이관작업, 카드사의 결제 테스트 이슈, 방화벽 및 라우팅 이슈, 파일 전송 등의 문제도 있었고,

 

DB schema 사이의 권한 부분도 명확히 정리된 부분이 많지 않아

 

테스트 하면서 하나하나 기능을 확인하고 추가로 부여해야만 하기도 했습니다.

 

 

그렇게 많은 수고와 노력들이 더해지고 건강하게(?) 이관을 마치고서

 

22년 10월 말부터 GSSHOP의 결제모듈은 SMTCDB 품안에서 잘 커가고 있답니다. 

 

 

해당 프로젝트를 진행하면서 정말 고마운 분들이 많습니다. 

 

 

제휴포인트 이관 함께 해주신 조병규 매니저님과

 

결제모듈 전반적인 테스트를 지원해주신 정현철 매니저님께 많은 감사드리고

 

무엇보다, 입사한지 오래되지 않아 업무에 대한 파악도 어려운 상황에서

 

결제 모듈 이관 application 담당자로서, 오랜 시간 함께 이관하느라 고생하고

 

오픈하고서도 고생 많았던 주문P팀 이정진 매니저님께 special thanks to 날려드리고 싶습니다.

 

 

다음 번엔, 묵은지도 이 정도면 못먹을 것 같은

 

17년된 ODS 서버 교체와 업그레이드 스토리로 다시 찾아뵙겠습니다.

 

 

늘 모두가 행복하고 보람있는 회사 생활이 되길 소망하며, 이만 줄이겠습니다.

 

감사합니다.

 

---

백승엽  Yup  |  디지털서비스본부  >  홈쇼핑서비스부문  >  클라우드팀

 

OCM 10g  / AWS DB Specialty

---