메인 데이터베이스 IDC 탈출 성공기
안녕하세요. 우아한형제들 시스템신뢰성개발팀 박주희입니다. 2019년을 마무리하는 시점에 우아한형제들이 어떻게 메인 데이터베이스를 IDC 환경에서 탈출시켰는지, 그 과정을 공유하려고 합니다.
발단
2010년 6월 출범한 배달의민족은 (2018년 12월 기준) 앱 누적 다운로드 4000만 돌파, 월간 순 방문자 수 900만명, 전국 등록 업소 수 30여만개, 거래액 기준 연간 약 5조 원의 배달 주문을 처리하고 있습니다.
이런 성장을 뒷받침하기 위해 소수의 개발자가 빠르게 서비스를 개발했고, 하나의 메인 데이터베이스(Microsoft SQL Server)에 모든 데이터와 로직을 집중시키는 모노리틱 아키텍처(Monolithic Architecture) 방식을 택했습니다.
루비는 메인 데이터베이스의 사내 명칭입니다.
빠른 개발과 관리 포인트 집중을 위한 선택이었지만, 시간이 지나면서 모노리틱 아키텍처의 장점은 부메랑이 되어 치명적인 단점으로 돌아왔습니다. 소수의 인원이 빠르게 개발할 수 있었던 과거와 달리 여러 서비스가 동시다발적으로 메인 데이터베이스를 사용하면서 예상하지 못한 부작용이 발생했고, 사소한 기능 하나를 추가하는데도 분석하고 수정해야 할 개발 범위는 상상을 초월했습니다. 새로운 기술을 도입하거나 새로운 기능을 오픈할 때마다 미처 확인하지 못한 부분이 발목을 잡았고, 복잡한 로직과 구조 때문에 장애 상황에 빠르게 대응하지 못했습니다. 또, 메인 데이터베이스에 이슈가 생기면 배달의민족 전체 장애로 확산되기도 했습니다.
전개
이 상황을 타개하기 위해 변화에 유연하지 못한 IDC를 벗어나서 모든 데이터베이스를 클라우드 환경에서 운영하고자 했고, 우아한개발자들은 3년이 넘는 시간 동안 하나의 거대한 시스템을 작은 서비스 단위로 나눠서 구현하는 탈 메인 데이터베이스 프로젝트 (ex, 포인트 시스템) 을 진행해왔습니다.
이 기간에 크고 작은 프로젝트가 2~30개 정도 진행되었고 몇 달, 몇 년에 걸친 꾸준한 작업의 결과로 2019년 하반기에 접어들면서 서비스 영향도가 많이 줄어들었습니다.
절정
어쩌면…
정말 어쩌면…
메인 데이터베이스를 없앨 수도 있을 것 같다는 작은 희망을 품게 되었습니다.
서비스 영향도가 많이 낮아진 것이 수치로 확인되었기에, 과감하게 (겁도 없이) 메인 데이터베이스를 종료하고 싶다고 메일을 한 통 보냈습니다. (일단 한 번 질러봤습니다.)
위기
(겁도 없이) 메인 데이터베이스를 중단한다고 메일을 보낸 후, 약 3개월 동안 서비스 간 의존성을 확인하고, 서비스 범위를 확인하고, 각 시스템으로 이관해야 할 데이터를 분리해서 나누고 옮기고, 나누고 옮기는 과정을 (a.k.a. 노가다) 반복했습니다.
AWS DMS와 mysqldump를 사용해서 신규 데이터베이스로 데이터를 이관하고,
신/구 데이터베이스에 동시에 데이터를 적재하고 데이터를 검증할 수 있는 로직을 만들고,
SQL Server에서 커넥션을 확인한 후 사내 Platform Portal을 통해 AWS 리소스를 찾고,
수많은 소스 코드를 수정하고,
메인 데이터베이스에 의존적이던 (구) 어드민 시스템까지 통폐합하면서,
(이것말고도 더 많지만, 여기까지…)
3개월이라는 짧고도 긴 시간에 정말 많은 변화가 생겼습니다.
이 과정에서 개발, 기획뿐만 아니라 고객서비스, 광고계약 등 여러 부서의 많은 분들이 정신없는 3개월을 보냈습니다.
결말
그리고 3개월 후,
영원히 불가능할 줄 알았던 그 일이…
정말로 일어나고야 말았습니다.
2019년 11월 1일. 메인 데이터베이스로 유입되던 모든 커넥션이 제거되었고,
2019년 11월 26일. 마침내 배달의민족 서비스 한 축을 담당했던 메인 데이터베이스가 IDC에서 철수하게 되었습니다.
메인 데이터베이스 서버와 탈 IDC 기념 트리
하나의 큰 데이터베이스는 여러 개의 데이터베이스로 분리되었고,
메인 데이터베이스 하나에 의존했던 배달의민족 서비스는 이제 100개 이상의 데이터베이스가 빠른 비즈니스 변화에 맞춰서 유기적으로 움직이고 있습니다.
메인 데이터베이스 종료 후 배달의민족 서비스 아키텍쳐
교훈
이번 프로젝트를 진행하면서 발견된 몇 가지 문제점과 배운 점을 부끄럽지만 공유하려고 합니다.
문제점
- 서비스는 종료되었지만, 소스 코드는 그대로 남아있다.
프로시저 내부 로직은 전부 주석처리 했지만 호출하는 부분은 미처 제거하지 못해서 아무런 기능도 없는 프로시저가 호출되는 경우도 있었고, 프로시저를 호출하는 부분까지 정리가 되었지만 정작 프로시저는 그대로 남겨둔 경우도 있었습니다.
서비스가 종료되거나 아키텍처 개선 등으로 인해 리팩토링 되었지만, 레거시를 정리하지 않았기 때문에 발생하는 현상으로 단순히 안 쓰는 건데 그냥 좀 두면 어때라고 넘기기엔 생각보다 발생하는 문제가 컸습니다.
신규 개발 후 QA 과정에서 새로 개발한 시스템이 아닌 레거시 시스템으로 연결되어 테스트 당시에는 오류를 발견하지 못했지만, 시간이 지나면서 데이터에 누수가 생기기도 하고, 불필요한 부분에서 병목이 발생해서 전체 서비스 레이턴시에 문제가 생기기도 합니다.
관리 포인트는 점점 늘어나고 다음 프로젝트를 위한 개발 범위 산정이 계속해서 커지는 것도 레거시를 정리하지 못해서 생기는 부작용입니다.
- 테이블 이름, 프로시저명, 변수명 등 ‘이름’만으로 목적을 알 수 없다.
여러 명이 동시다발적으로 개발/운영을 하다 보니 명명 규칙에 대한 협의가 사전에 이뤄지지 않았습니다. 각자 편한 대로 혹은 쓰던 대로 이름 붙이다 보니 오타나 오기로 인해 의미가 왜곡되기도 했고, 이름만으로는 절대 목적을 알 수 없는 특수한 컬럼이나 테이블도 있었습니다. 빠르게 개발하고 즉시 투입해서 운영하다 보니 테이블의 용도나 목적, 의미에 대한 기록이 남아있지 않아서 지라, 위키, 구글을 하나하나 검색하고, 수십 명의 개발자에게 하나하나 확인해야 했습니다.
- 모두가 주인인 듯 모두가 주인이 아니다.
하나의 프로시저를 여러 시스템에서 호출하고, 여러 개발자가 동시에 수정하면서 모두가 사용하지만 아무도 오너십을 가지지 않는 상황이 되었습니다. 여러팀에서 같은 코드를 사용하면서 전체 로직 확인 없이 각자 필요한 부분만 조금씩 수정 하면서 내가 수정한 코드가 다른 부분에서 어떤 문제를 야기할 수 있는지 파악이 힘들어지고, 이로 인해 전체 시스템에 대한 불확실성이 증가하게 되었습니다.
- 거의 비슷한 기능을 하는 조금씩 다른 코드가 있다.
빠른 개발을 위해 기존의 코드를 복사해서 필요한 부분만 수정한 후 반영하게 되어 90%는 같지만 10%만 다른 코드들이 다수 생겼습니다. 동일한 소스 코드를 여러 방향으로 수정하다 보니 한번 계산된 데이터를 거꾸로 다시 풀기도 하고, 조인하지 않아도 되는 테이블을 조인하기도 했습니다.
배운 점
- 프로젝트를 계획할 때 레거시 제거도 프로젝트 범위에 포함하자
수많은 레거시가 제거되지 못하는 가장 큰 이유는 바로 ‘일정이 부족해서’ 일 것입니다. 처음 프로젝트를 시작할 때 전체 일정을 산정하게 되는데, 대부분 프로젝트에서 레거시 제거를 프로젝트 범위에 포함하지 않습니다. 하지만 이 과정이 생략됨으로 인해서 발생하는 부작용은 생각보다 큽니다.
- 명명 규칙을 미리 정하고 최대한 많은 사람에게 공유하자.
명명 규칙, 데이터 타입을 미리 정하는 것은 귀찮지만 중요한 일 중에 하나입니다. 혼자서 모든 것을 개발하고 유지보수 할 수 있으면 좋겠지만, 우리는 함께 일을 하고 있기 때문에 규칙을 정하는 게 중요합니다. 미리 규칙을 정하고 정해진 약속대로 한다면 여러 명이 개발한 소스를 빠르게 머지할 수 있고, 데이터 타입의 불일치도 최소화할 수 있어서 개발과 운영에 드는 리소스를 줄일 수 있습니다.
예를 들어 다섯 명의 팀원이 회원 시스템을 개발하기로 했는데, 명명 규칙과 데이터 타입을 미리 정하지 않았다면 (매우 극단적이지만) member_number varchar(20), mem_no int, MemNo bigint, M_no varchar(50), member_no nvarchar(20) 이렇게 다른 다섯 개의 명명과 데이터 타입을 가진 컬럼이 결과적으로 같은 회원 번호를 의미하게 될 수 있습니다.
그렇다면 개발이 어느 정도 진행된 시점에서 대대적으로 수정을 해야 할 수도 있고, 모르고 서비스를 오픈했다가 시간이 지난 후 데이터 잘림 현상이 발생하거나, 구조적인 문제로 성능 저하가 발생할 수도 있습니다.
- 코드에 대한 오너십을 갖자.
가급적 코드에 대한 오너십을 명확하게 하는 것이 좋습니다.
공통으로 사용하는 기능이라고 하더라도 오너십을 부여하고 이를 주기적으로 관리하는 것과 관리하지 않는 것의 차이는 큽니다.
아무도 관리하고 있지 않은 경우에 장애 인지 및 장애 복구가 전반적으로 늦어지고 장애 확산 가능성도 훨씬 커질 수 있습니다.
- 로직은 가급적 단순하고 명료하게 만들자.
기존에 동작하던 것과 비슷한 기능을 구현할 때 보통 기존 소스 코드를 복사해서 필요한 부분을 수정하게 됩니다. 기존 소스 코드를 재사용할 때는 반드시 불필요한 로직이 수행되고 있지는 않은지, 다른 곳과 불필요한 의존성이 존재하지 않는지 점검해봐야 합니다. 필요도 없는 데이터를 계산하느라 발생하는 성능 저하는 생각보다 자주 볼 수 있습니다.
마무리
오랜 기간, 많은 사람의 노력으로 이루어진 일입니다.
결코 순탄하지 않았던 과정을 성공적으로 마무리한 모든 우아한 개발자 여러분께 이 자리를 빌려 감사 인사와 박수를 보냅니다.
더 자세한 이야기가 궁금하신가요?
우아한형제들과 함께하신다면 이 모든 과정이 담겨있는 보물 같은 위키를 마음껏 열어볼 수 있습니다.
저는 이제 개운한 마음으로 11일간의 방학을 즐기러 떠납니다.
감사합니다.