안녕하세요 클라우드팀 백승엽 매니저입니다.
아시는 분들은 아시겠지만, 홈쇼핑에서 사용하고 있던 IDC의 사용 주기가 만기됨에 따라 해당 IDC의 시스템 이전 방안에 대해 다각도로 검토하였고 현재, 클라우드 환경인 AWS로 IDC 이전을 계획 및 진행중에 있습니다.
이 시기와 더불어 2월에 IDC to AWS DB POC를 진행한 경험과 WEBDB를 aurora postgres로 전환이 진행되고 있는 것을 함께 묶어 DB migration 시 반드시 확인하고 고려해야 할 방법론에 대한 글을 써보고자 합니다.
(실은 예전에 써두었는데, 노트북 메인보드 교체하면서 원노트 글이 사라졌다죠.. 하핫... 다시 쓰는 맛이 참 좋네요... ㅜㅜ)
현재 홈쇼핑에서 사용중인 DB는 ORACLE 외에 mysql, aurora등의 DB들도 있으나, 홈쇼핑 3대 main DB인 ORACLE DB를 기준으로 작성해보도록 하겠습니다.
DB migration 방법론에 대해 쓰기 이전에, DB migration이 무엇인지를 설명드려보고자 합니다.
migration은 무언가를 시작점에서 목표점으로 옮기는 것을 의미하는 단어입니다.
그렇다면, DB migration은? DB(database)를 현재의 위치에서 어떤 "이유"로 인해 특정한 다른 위치로 옮기는 것을 의미하며, 보통은 기존의 운영환경에서 좀 더 나은 다른 운영환경으로 옮겨가는 과정을 의미합니다. (data는 물론, 사용하는 SQL 포함)
물론, 과정을 본다면 시스템을 분석하고, 영향도를 분석하고, 일정계획을 수립하고, DB migration을 진행하고, 최적화 하는 5단계로 나뉠수 있겠지만, 본 글에서는 DB migration을 하는 이유에 따라 나뉘는 4가지 방법에 초점을 맞추고 진행하고자 합니다.
위에서 언급한 그 "이유"에 따라서 DB migration은 크게 아래의 4가지로 나뉘게 됩니다.
1) 서버 및 장비 교체로 인한 migration
2) DB version upgrade
3) OS conversion (U2L)
4) DB conversion
첫 번째는 서버 및 장비 교체로 인한 migration 입니다.
작년 5월부터 11월까지 진행하였던 방송넷 DB의 업그레이드 사례가 있습니다.
물론, 해당 DB는 버전도 9i여서 DB version upgrade도 병행하였지만,
가장 큰 원인은 17년, 15년된 서버의 노후화가 더 중요한 요인이었습니다.
서버 및 장비 교체로 진행되는 경우는 큰 요소가 변경되지는 않습니다.
신규 장비를 구성하고 full backup을 미리 수행해서 restore하고
archive를 통한 증분적용을 해주면 되어서 전환작업 시 down-time도 길지 않습니다.
유의할 부분은, 교체되는 서버와 스토리지의 사양의 변화입니다.
물론, 교체주기가 지난 만큼 교체되는 장비의 CPU clock이나 memory size가 더 좋아졌겠지만 storage의 TPMC 등의 성능을 미리 체크해둔다면 성능 이슈를 사전에 대비할수 있습니다.
상대적으로 봤을 때, 비교적 가장 간단한(?) DB migration 입니다.
두 번째는 DB version upgrade입니다.
DB도 특정 제품이며, 그 특정 제품도 시간에 따라 불안한 요소는 고치고, 좀 더 경쟁력을 키우기 위해서 좋은 기능은 하나 둘씩 더해가면서 시간에 따라 version이 올라가게 됩니다. 생활속에서 사용하시는 스마트폰의 OS version처럼 계속 올라가고 시간이 많이 지나면 예전 version에 대한 지원은 종료하는 것처럼, DB 제품군도 마찬가지로 시간이 많이 지나게되면 지원 service를 종료하게 되는 EOS라는 (End Of Service)는 지원 주기가 있습니다. 따라서 운영하는 입장에서는 지속적인 제품 service를 제공받기 위해서 늘 그 주기에 맞추려고 노력하곤 합니다.
허나, 흔히 말하는 24 x 7 x 365로 쉴틈없이 운영되는 시스템은 그 upgrade를 매번 진행하기 어려운 사유들이 많아 EOS보다 그 시기가 많이 밀릴 수도 있게 되는데, 그 사유들보다 더 자리잡고 있는 위험요소는 DB version upgrade 시에는 늘 성능 이슈가 발생할 수 있다는 점입니다.
DB version이 변경되면, 흔히 말하는 SQL의 수행 경로, SQL의 access path를 결정하는 optimizer가 바뀌며
이로 인해 SQL의 실행계획이 바뀌는 경우가 많기 때문입니다.
당연히 이는 개별적인 SQL의 성능에 큰 영향을 미치고, 이 영향을 받은 SQL의 중요도에 따라 순식간에 CPU가 100%에 달하거나 IO wait가 100%에 달하는 경우가 발생하며 순식간에 장애상태로 빠지기 때문에 반드시 수행해야하는 단계로 이 단계가 부담스러워서 DB upgrade를 진행하지 못하는 경우도 (아주, 정말) 상당히 많습니다.
그러므로, DB version이 upgrade 하기 전에는 반드시 SQL 전수조사를 진행해야 합니다.
방송넷 DB도 서버 교체와 함께 기존의 9.2.0.4 version에서 11.2.0.4로 DB upgrade도 함께 진행되었기에 전수조사 및 주요 SQL의 전/후 성능비교를 진행했으며 상당 수의 SQL tuning을 진행하며 성능 안정화를 이끌어 냈습니다. (SQL tuning의 신, 이태수 매니저님께 다시 한번 감사하다는 말씀을 드리고 싶습니다)
DB version이 upgrade되면 SQL 전수조사 외에 다른 version 이슈 또한 발생합니다.
대부분의 시스템은 여러 version으로 운영되고 있으므로 client와 server간의 version compatible로 인한 DB connection 가능 여부를 확인해야 하며 부가적으로 지원되는 JDK, JDBC의 version도 확인해서 기존 연계 서버 시스템간의 접속 영향도 또한 파악해두어야 합니다. (당연히, 연계 사용 tool의 지원 여부는 필수 !)
모든 연계 시스템이 깔끔하게 정리되어 있다면 파악된 업무영역만 확인하면 되겠지만 만일, 그렇지 않다면 주기적으로 월 단위의 DB서버 netstat 결과 및 방화벽의 접속 log 등을 월간별로 정리해서 in-bound / out-bound 세션들을 모두 확인해야 할수도 있습니다. (솔직히 무조건 하긴 해야 합니다... 혹시 모르니까요...)
세 번째는, 흔히 U2L(Unix to Linux)로 말하는 OS conversion입니다.
ORACLE DB의 license는 상당한 고가를 자랑합니다. (유지보수 비용도... -_-) 강력한 성능과 다채로운 기능으로 고객을 유혹하는 반면, 그 사용의 대가는 정말 비싸지요.
이 ORACLE DB의 Process 단위의 license 산정 시 적용되는 core factor는 Unix 대비 Linux에서는 2배로 계산됩니다. ( Unix 1 core : Linux 2 vCPU or oCPU)
몇년 전부터, linux 서버도 기존 대비 상당히 성능이 좋아져서 이 license factor와 함께 각 회사 별로 IDC 이전 혹은 서버 교체 주기 도래 시에 U2L 진행을 하는 경우가 많았졌고 특히, 요즘은 특히 클라우드 환경으로 이전하기 위한 U2L이 많이 이뤄지고는 합니다. 주요 클라우드 서비스 제공사들의 주요 OS가 모두 Linux이기 때문입니다.
물론, 이 외에도 오픈소스로의 전환 및 다양한 신기술 발표 및 적용주기가 unix에 비해 짧은 저비용 구조 또한 강점이겠죠.
위와 같은 이유들로 지금 홈쇼핑 시스템 DB들도 IDC에서 AWS로 이전을 계획하고 진행하고 있습니다.
동일한 OS를 사용하면, DB migration을 이용하는 방법이 그리 어렵지는 않습니다만, OS가 다르다면 byte를 저장하는 순서 기반인 Endian 방식이 달라지므로 작업이 굉장히 복잡해 집니다.
U2L 같은 경우는 Unix는 Big endian, Linux는 Little endian을 사용하고 있어 상호간의 data file의 호환이 이뤄지지 않기 때문에 hot backup 같은 file 기반의 backup을 이용할수 없게 됩니다.
그렇기 때문에, 별도의 논리적인 backup으로 migration을 진행해야 하며 작업 단계가 많이 늘어나고 down-time도 더 늘어날수 밖에 없게 됩니다.
이번에 main DB들이 진행하고자 하는 migration 방법은 ORACLE 사에서 제공하는 XTTS입니다.
cross platform간에 table과 index가 보관되는 tablespace에 대한 migration(tablespace transportable tablespaces)을 진행하여 XTTS라는 naming이 붙여진 방법입니다.
config file에 source와 target 환경에 대한 OS 및 기타 DB 관련 정보 및 이관 대상인 tablespace들을 설정하고 RMAN을 통해 필요한 tablespace들의 논리적인 full backup 받고, 이를 임시 스토리지인 AWS snowball 혹은 전용선 서비스인 Direct connect를 통해 전송하여 새로운 OS platform에 맞도록 tablespace들을 1차적으로 convert 합니다.
이후, 동일한 방식으로 추가적인 증분백업을 받아서 전송하고, 변환하여 적재하다가 전환작업이 이뤄지는 날, 기존 source DB를 read-only 상태로 변환하여 마지막 증분백업 및 metadata (user, grant, PL/SQL objects)등을 dump로 받아서 이관하여 적용하는 순서로 모든 작업이 이뤄지게 됩니다. (간단하게 적었지만, 안에 세부적인 작업들은… 참 많습니다 ㅠㅠ DBA의 숙명이라지요)
ORACLE의 경우 DB의 size가 크거나 version 혹은 LOB type 같이 size 및 속도에 많은 영향을 주는 object가 많다면 RDS와 같은 PaaS 형태의 DB로 이전을 하기 어렵기에, 위와 같이 U2L migration을 진행하고 있는 추세입니다.
개인적으로, 2021년 여름에 H그룹사 DB를 AWS로 U2L 이관 시 XTTS 3.x version을 이용하였습니다. 현재는 4.3 version이 출시되었는데, 조금 더 작업 절차가 간소화 해져서 POC 진행 시 조금 더 수월했습니다. (물론, 그래도 참 복잡하긴 합니다 ㅠㅠ)
참고삼아, U2L 검증을 하였던 AWS POC 내역을 함께 살펴 보겠습니다.
기존 SMTCDB는 RAC라는 ORACLE사의 독자적인 architecture를 사용하였습니다.
허나, AWS에서는 RAC라는 architecture가 정식으로 인증되지 않아 다른 방향을 살펴보았고 여러 환경 및 조건으로 인해 active-standby의 HA 구조로 구성하되 DR까지 함께 대비할 수 있도록 active node는 Zone A에, standby node는 Zone C로 HA 환경 구성을 하였습니다.
위의 구조로 설정하며 가장 중요하게 여긴 POC 요소는 기존 IDC에서 사용하던 Unix 서버의 사양과 storage의 성능이 AWS 환경에서도 어느 정도 가능한지에 대한 입증 부분이었습니다.
SMTCDB라는 DB는 아무래도 홈쇼핑의 메인 DB이기에 그 연관되는 시스템은 정말 많았고 해당 DB의 전체 기능을 모두 재현해서 확인할 시나리오 및 재연 방안은 사실 어려웠습니다.
그래서, POC 주요 내용은 2022년 초 코로나 진단키트, 그리고 핫하게 대한민국을 흔들었던 포켓몬빵 판매 이벤트시의 분당 최대 주문 부하를 어느 정도까지 커버가 가능할지에 대한 검증이 중점이었습니다.
주문과 함께 진행되는 상품등록 부하를 증가시키면서 각 수치별로 나타나는 병목들을 측정하였고 기존 분당 최대 주문 건수에 약 18%까지 더 판매부하를 감당할 수 있음을 확인하였습니다. (세부 수치는 보안상... )
물론, 추후 세부 테스트 및 전환 작업 후에 수 많은 연계 업무와 배치 job들이 함께 재현되면 그 부하에 따라 storage IOPS 및 instance class의 변경이나 업그레이드가 필요할 수는 있겠습니다만 계획단계부터 열심히 진행중인 홈쇼핑서비스부문의 많은 담당자 분들의 수고와 노력과 함께 안정적으로 AWS 이관이 잘 마무리 되는 초석이 되었으면 좋겠습니다.
네 번째는, 가장 극한의 단계인 DB conversion입니다.
모두 마찬가지겠지만, data를 이관해야하는 DBA 입장에서는 제일 진행하고 싶지 않은 방법입니다
(정말 힘들어요... ㅜㅜ 그래도 해야한다면 해야하겠지요...)
DB를 conversion 하는데는 많은 이유가 있겠지만 강력한 성능을 보장하나 비싼 라이센스와 유지보수 비용 또한 자랑하는 ORACLE의 그늘에서 벗어나 효율적인 비용으로 운영하고 클라우드 환경에 보다 더 어울리는 open source DB로 전환하기 위한 이유가 제일 클겁니다.
헌데, 그 중요함의 전제가 있습니다. DB conversion을 하더라도 source DB에서 사용하는 모든 것들을 파악해서 이것들이 target DB에서 온전히 동작해야 한다는게 기본일겁니다.
그러나, 안타깝게도 DB는 각 제품별로 지원하는 SQL 문법과 세부 기능은 물론, 지원되는 data type과 object type 또한 모두 다르기에 위에서 언급한 '온전히 동작해야 하는 것들'이 보장되지 않을 수 있으며, 이는 모두 별도로 변환해서 진행해야 하는 개발 공수로 이어지게 됩니다.
예로 들면, D항공사의 DB conversion의 경우, 많은 수가 아니라 무겁게 여기지 않던 package 등의 PL/SQL object들이 별도의 개발팀을 공수하였음에도 해결되는 기간이 길어져서 결국, 전체 프로젝트 일정이 두 달 가까이 지연되는 사례도 있었습니다.
프로젝트에는 많은 이유와 근거로 만들어져서 준수해야만 하는 일정이 있으나 여러 사정 상, 결국 그 일정이 굉장히 타이트해 질 수 있습니다.
그래서, 그 일정 속에서 기존 SQL이 동작하도록 문법을 수정하는 SQL 변환작업과 미 지원 되는 object를 해결하기 위해 AWS에서 제공되는 SCT 같은 변환 Tool 또는 수작업으로 진행하는 object 변환 작업이 늘 길게 이뤄지는게 현실입니다.
허나, 그 작업은 안타깝게도 필수적으로 이뤄져야 하는 첫 단계 작업이며, 그 다음 단계인 두번째, 최적화 공수 또한 많이 산정되어야만 DBmigration 후 시스템 안정도 함께 이뤄질수 있습니다.
어찌 보면 당연한 말 일수 있습니다. Source DB는 오랫동안 최적화해서 사용하던 ORACLE DB였는데 다른 DB로 conversion한다면 DB migration에서 장시간의 최적화 작업까지 함께 이뤄져야 동일한 성능을 보이게 될것이기 때문입니다.
그러므로, DB conversion 계획을 수립할 부터,
전체 계획의 제일 우선순위로 파악해야 할 것들은 '어려운 것부터 정리 '입니다.
먼저, DB에서 사용하고 있는 object들의 전체 전수조사가 필요합니다.
이후, 그 object에서 가져가야하는 것과 버릴 수 있는 것들을 나눠서 migration 대상을 경량화 하고 다음 단계로, 가져가야 하는 것들 중 target DB로 conversion이 가능한 것들과 가능하지 않은 것을 나누고 가능하지 않은 것들의 처리방안에 대해서 확인 및 수립해야 합니다.
가능하지 않은 것들의 계획 수립 및 검증이 끝난 이후에야 가능한 것들을 옮기고, 최적화를 하는 단계도 의미가 있어지기 때문입니다.
가능하지 않은 것들의 수가 적고, 기간의 여유가 없다고 일단 할 수 있는 것부터 진행하면 반드시 막바지에 가능하지 않은 요소들이 프로젝트를 오픈할 수 없거나 혹은 지연시키거나 혹은 시스템 성능저하를 일으키는 암초로 돌아오게 되기 때문입니다.
네. 그렇습니다.
첫 번째 방법부터 네 번째 방법은 모두 하나하나도 어려운 작업입니다만, 상황에따라 서로 연결되어 복합적으로 진행될 수도 있습니다.
그 가운데서도 늘 가장 중요한 요소는
'반드시 제일 어렵고 안될 것 같은 요소의 해결 방안 확인'부터 진행되어야 합니다.
쉬운 건 이슈가 될 가능성이 적지만, 어려운 건 해결이 되지 않을 가능성이 크기 때문입니다.
또한, '각 파트별로 위험요소를 파악할게 아닌, 전 파트가 위험요소를 함께 판단해야 합니다'
내 파트에서는 위험요소가 아니지만, 다른 파트에서는 최우선의 위험요소일수도 있기 때문에 전체적으로 모두 아울러서 보는 시각이 반드시 필요합니다.
현재, 홈쇼핑의 많은 시스템들이 AWS로 이관을 진행하였고 DB들도 이관 진행중에 있습니다.
세 번째 방법인 OS conversion인 U2L을 통해 주문/결제 DB, 방송넷 DB도 곧 진행될 예정이지만,
모바일 센터와 함께 진행중인 WEBDB의 aurora postgres로의 DB conversion이 먼저 진행중에 있습니다.
많은 것들이 변해야하고, 또 변할수밖에 없는 상황에서 시간도 제한적이고
인원도 예산도 제한적이기에 분명, 복잡하고 어렵고 힘든 작업이 예상됩니다
하지만, 연계된 모든 담당자의 노력과 수고가 있기에 꼭 잘 마무리 되었으면 좋겠습니다.
두서 없는 글 읽어주셔서 감사 드리고 관련되어 궁금하신 점 있으시면 언제든지 문의 해주세요.
감사합니다!
백승엽 Yup | 디지털서비스본부 > 홈쇼핑서비스부문 > 클라우드팀
OCM 10g / AWS DB Specialty
'Cloud&Security' 카테고리의 다른 글
| Oracle to AWS Aurora PG 1탄 (Shareplex AWS 전환 여정) (19) | 2024.02.29 |
|---|---|
| Oracle to AWS Aurora PG 3탄 개발자의 청천벽력 이야기 (1) | 2024.02.29 |
| Kafka 도입 스토리 - 홈쇼핑 방송영역 활용 사례 (0) | 2023.02.20 |
| 엔터프라이즈 MSA 이야기 1탄 - 주문서비스(Milestone1) (2) | 2023.01.02 |
| 오래된 DB와 이별하는 방법 (10) | 2022.12.27 |