테크 블로그 TechBlog

 

안녕하세요.

 

분명히 SM으로 입사하였으나, SI 업무만 할당받는 느낌같은 느낌의 클라우드팀 DBA 백승엽 매니저입니다.

 

지난 번 작성한 "SMTC(주문결제)DB 품으로 날아간 결제모듈" 이후 

" 오래된 DB와 이별하는 방법 "이라는 주제로 두번째 글을 써보려고 합니다.

 

Why?

 

입사 이후, 가장 충격적이었던건 이 한 줄로 대신할 수 있을 것 같습니다.

 

" 2022년에 ORACLE 9i가 웬말이니? "

 

 

업무 소개를 해주던 클라우드팀 문광모 매니저에게 처음 한 말이 아직 기억납니다.

 

" 네? 9i DB가 있다뇨... 그게 무슨 말씀이세요? " 라는 물음을 던졌던 기억이 납니다.

 

9i DB의 업그레이드는 많이 해봤습니다만, 너무도 예전이었죠... 

아마 대략 2010년쯤 많이 했고, 늦었어도 2012년이 마지막이었던것 같은데... 말입니다... (쿨럭...)

 

지금은 2022년입니다. 9i는 2002년도에 출시된... DB란 말이죠...

(국민 모두가 대~~한민국! 하던... 짝짝짝~ 짝짝~ 하던 그 시절이지요...)

 

이 문제의 DB는 오래된 만큼 GSSHOP 업무 전 영역에 영향을 끼치고 있었고

그 영향력이 큰 만큼 문제가 생긴다면 그 후폭풍은 엄청날 것이었기에

이 DB의 업그레이드는 가장 우선순위가 높은 업무라고 판단 되었습니다. 

 

참고로, 이전에 게시했던 "결제모듈 이관"의 시작도 오래된 방송넷(ODS) DB의 노후화가 큰 요인이었습니다.

( 17년, 15년된 active/standby 서버... 13년된 DB... 이 정도면 묵은지는 물론, 된장도 못 먹을 것 같군요... )

 

오래된 시스템인만큼 당연히 H/W 장애도 2017년부터 24건이나 발생 중이었고,

최근 2년간만 해도 파트부품만 7번 교체하였으나, 점점 그 부품도 수급하기 어려워졌기에

이 GS리테일의 "불안요소"를 지우기 위해, 방송넷(ODS) DB의 빠른 업그레이드가 필요했습니다.

(DB서버 엔진에 core dump가 하루에 몇 GB씩 떨어졌기도 했었다지요.... 흠흠...)

 

지금은 안 계신 前 팀장님께서, " 이 DB 죽으면 우리 다 죽는거야 " 라는 무시무시한 말씀을 필두로

5월 중순에 덩그러니 프로젝트 PM까지 진행해야하는 DBA로 홀로 남겨졌고 

그렇게 ODS 업그레이드를 검토 및 진행하게 되었습니다.

(응? 근데... 왜... DBA가 PM인거죠...? 왜... why... )

 

당연히 이러한 경우엔, 프로젝트를 바로 띄워서,

한 방에 모두가 모여서 분석하고 설계하고 프로젝트 진행하면 조금 더 빠른 작업이 가능했겠지만

각 팀별로 당면한 많은 프로젝트들이 이미 진행중이었고,

나쁜 러시아로 인한 달러화 상승 영향도 있었던 상황이라, 다각도의 효율화를 위해

DBA, TA는 물론 모든 업무 담당자 및 개발 담당자 분들도 

기존에 운영하던 업무와 함께 병행하여 진행하게 되었습니다.

( 모두 정말 고생 많으셨습니다 ㅠㅠ )

 

How?

 

DB는 물론, 시스템의 업그레이드를 하려면, 가장 먼저 필요한것은 연계 시스템 파악일 것입니다.

 

허나, 2022년이 어떤 해이던가요....

 

 

여러분들이 아시는 것 처럼 2021년과 2022년은 마이데이터 프로젝트가 불어온 

" IT 인력 대이동의 시대 " 였기에, 많은 분들이 이직으로 인해 퇴직 or 새로 입사하셨고 

워낙 오래된 시스템이었기도 했기에 관련된 이력 또는 업무 연관성에 대해 

자세히 아는 분이 많지 않았습니다. 

(참고로 저희 DBA는 다 입사한지 1년이 안 되었...습죠... )

 

그래서 역으로 DB에 접근하는 IP부터 파악하기 위해

몇 달간 해당 DB서버의 RIP 및 VIP 접근 이력부터 쌓아두고 구분하는 작업부터 시작했습니다.

(엑셀 파일이 몇십 MB가 넘었더랬죠?... ㅠㅠ 고생해주신 보안운영파트의 장시영 매니저님! 늘 감사드립니다)

 

접속한 IP를 모두 확인하고 그 IP에 대응되는 hostname과 매칭하여

관련된 서버들을 분류하고 해당 서버와 연관된 업무 담당자 및 개발 담당자 분들을 확인하였습니다.

 

오랫동안 GSSHOP의 근간이었던 시스템인만큼

고객, 상품, 주문, 방송, 물류, 전시, 회원, SAP, 통합보험, 그룹웨어, 데이터팀, BMS, 영상제작2팀 등 

13개 업무와 연관되어 많은 담당자 분들이 계셨습니다.

 

전체 100 여분이 넘는 업무 담당자와 개발 담당자 분들을 하나의 채팅방에 일단 모시고,

전반적인 계획에 대해 소개한 뒤, 일단 테스트 DB 환경 구성 검토부터 시작했습니다.

 

ODS DB version은 9.2.0.4....  참.... 으로 오래된 버전으로

서버, OS, DB 모두 어느 정도로 업그레이드 해야할지가 중요했습니다.

서버는 OS에 종속적이라 OS version에 맞추어 수급하는 것으로 했고

OS는 DB version에 종속적이라 DB version이 중요했습니다.

 

기존 기간계의 DB는 모두 11g 버전에 OS도 AIX 7.1을 사용중이었으므로

ODS만 너무 최신 버전을 적용하면, 기존 시스템들과의 호환성 문제가 발생할 우려가 있었습니다.

( client / server , JDK, ODBC 및 기타 연계 tool과의 호환 및 지원 여부 등 )

 

현재 IDC 이전과 더불어, 구조개선 및 DB 변경 계획도 진행예정이므로

일단, 빠른 이관을 목표로 기간계 주요 DB들과 동일한 version인 ORACLE EE 11g (on AIX 7.1)로

업그레이드 하기로 결정했습니다.

( 조만간 다시 업그레이드 or  오픈소스로 전환이 될지도... 아마 후자겠지요... 헙... )

 

What?

 

ORACLE DB를 업그레이드 하는 방안은 여러가지가 있겠지만, 운영 중의 down-time을 최소화하여

비지니스 영향도를 줄이면서도 안정적으로 진행할 수 있는 방안이 필수적입니다.

 

물론, 선 이관 후, CDC 같은 tool을 이용한다면 더 down-time을 최소화 할 수 있겠지만

한번의 작업을 위해 해당 tool을 구매해야하는 라이센스 비용 부담이 크고,

data type에 따라 추가적인 이슈나 archive log에 대한 보유 및 전송에 대한 대응방안이 

추가로 필요할수 있으므로 정기적으로 시행하는 PM 작업 시의 down-time 내에서

작업이 가능한 방안 중 가장 간결한 방안으로 계획하였습니다. (물론, 겉에서 보기에만... )

 

ORACLE DB 업그레이드 순서도

 

BCV 스토리지 복제 솔루션을 통해서 현재 운영중인 DB 스토리지에 사전에 복제를 걸어두고,

DB 서비스 중지 후 약간의 동기화 시간을 대기한 후, 

임시 서버에서 11g로 바로 업그레이드 가능한 9.2.0.8 version으로 1차 업그레이드를 진행하고서

이후, 사전에 마련된 신규 OS와 DB 엔진이 설치된 신규 서버로 해당 스토리지를 이동하여

11.2.0.4 version으로 2차 업그레이드를 마무리 하는 방안이었습니다.  

 

9i to 11g DB 업그레이드 방안

 

위와 같이 진행한 이유는 원본 서버 및 DB의 노후화도 원인이지만, 

원복 사유 발생 시 빠른 원복을 해야하기 때문에 

원본의 변경사항이 없는 작업계획이 필요했기 때문입니다.

 

그래서 중간에 11g로 바로 업그레이드 가능한 최소 버전인 9.2.0.8 version의 임시 서버를 이용해

1차 업그레이드를 하고, 불필요한 파일 이동이나 증분백업 적용이 없이 작업 단계를 단순화하여

스토리지 이동만으로 2차 업그레이드 작업으로 연결되도록 작업 방향을 수립 하였습니다.

 

migration 방향 및 방법은 정해졌고 이제 남은 건

DB 업그레이드로 인한 성능 이슈가 발생하지 않도록 하기 위해

전체 SQL를  검증하는 단계가 필요했습니다.

 

해당 DB의 사이즈가 10TB가 넘는 대용량 사이즈기도 했고

오랜 기간동안 사용된 DB이기도 했지만

무엇보다 SQL의 access path를 결정하는 통계정보가

10년이 넘은 데이터를 사용하고 있었습니다.

 

통계정보는 사실 SQL의 성능에 절대적인 영향을 미치기에

건드리기 쉽지 않은 것이 사실입니다. 

 

허나, 그간 테이블 및 인덱스 사용현황은 지나온 시간만큼 커진 DB 크기만큼 

너무도 많이 달라졌기에, 최신의 DB 현황정보가 필요했습니다. 

 

그래서, 테스트 서버에서 DB 전체에 대해 최신 통계정보를 수집하여 적용한 후,

기존 개발DB와의 성능비교를 통해 SQL 전수조사에 돌입하였습니다.

 

DB 성능 모니터링 Tool인 Maxgauge에서 약 6개월간의 서버별, schema별로

elapsed time per exec, logical reads per exec, physical reads per exec 기준으로 선별하여

Top 300의 SQL을 먼저 전수조사 하여 DBA 측면에서 tuning안을 공유하였고

이 외에 업무 담당자와 개발 담당자의 측면에서 중요 SQL에 대한 성능 비교 후

이슈가 있는 SQL을 tuning 하여 성능 개선을 진행하였습니다.

 

이렇게 사전에 미리 tuning을 검토하고 진행한 결과, 장시간 수행되던 배치는 물론

OLTP 업무 또한 대폭적으로 개선되며, 시스템 오픈 이후, 쾌적한 환경 제공과 함께

성능적인 이슈가 발생하지 않고 스텔스 모드(?)로 프로젝트가 마무리 되는 쾌거를 이룬 것 같습니다.

 

DB CPU 사용량 비교

< CPU - MAX는 기존 대비 1/2,  AVG는 기존 대비 1/4로 감소 >

 

DB reads 사용량 비교

< DB block reads는 약 15~20배 효율 증가 >

 

주요 배치 SQL 사용현황 비교

< 주요 배치 SQL은 약 5~16배 효율 증가 >

 

 

위와 같이 CPU 사용량 및  DB block reads가 모두 감소하고

OLTP성은 물론 배치 SQL의 성능도 많은 향상이 이끌어냈습니다만,

무엇보다 OS와 DB version 업그레이드되고  서버가 신규로 교체되어

항상 GSSHOP 업무의 "절대 불안요소" 이기만 했던 방송넷 (ODS) DB가 

서비스 안정성을 확보하였다는 점이 가장 큰 수확이었다고 판단됩니다.

 

DB 업그레이드를 끝내고 가장 뿌듯했던 말이

"이렇게 했는지, 안했는지 모르게 지나간 DB 업그레이드는 처음인것 같아" 라는 말씀이었습니다.

 

5월 중순부터 준비해서, 11월 5일 전환작업까지 약 6개월의 시간동안 진행한 프로젝트였기에

많은 시간이 소요된 만큼의 많은 우여곡절이 있었습니다.

 

이렇게 대폭적인 성능 향상과 함께 성공적으로 ODS 업그레이드를 이뤄내고 마무리 하게 된 것은 

분명, 수많은 업무 담당자 및 개발 담당자 분들께서 기본적인 많은 운영 업무 속에서도

함께 테스트하고 검증 해주셨기 때문일겁니다.

 

허나, 그 분들중에서도 각 업무별로 선정되신 13분의 대표선수 분들 (+ 클라우드팀)께서

오랜기간 주간회의 참석은 물론, 같은 팀 및 파트분들을 리드해주시면서

좋은 의견 제시는 물론, 수 많은 테스트와 검증을 함께 진행 해주셨기 때문이라 생각됩니다. 

 

ODS 업그레이드를 함께 수고해주신 13인의 대표선수 분들 (+ 클라우드팀)께

특히 감사의 말씀을 드리고 싶다는 말로 이번 글을 마무리 하도록 하겠습니다. 

(한분 한분 성함을 쓰다가... 부담스러우실것 같아서... 이렇게만 써봅니다 ㅎㅎ)

 

정말 모두 수고 많으셨습니다!

 

p.s

그나저나... 이제 IDC 이전이 문제로군요... (to be continued....)

 

 

 

---

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

 

OCM 10g  / AWS DB Specialty

---