DBA에게 참교육 당한 애플리케이션 개발자
개발자라고 소개해놓고 지금까지 그럴싸한 개발 관련 글을 썼던 적이 없는 것 같습니다만, 이번엔 정말 개발 관련 글입니다. 물론 이론을 설명한 글은 아니고요. 제가 애플리케이션 개발자로서 일하면서 최근에 느낀 점을 적어보려고 합니다.
저는 서버 개발자입니다. 현재 커머스 회사에서 상품 데이터 플랫폼에 대한 대대적인 개편 작업을 수행하고 있습니다. 상품 데이터라는 것은 쉽게 예를 들면 쥐마켓, 12번가, 코팡 등의 쇼핑몰에서 판매자들이 판매하기 위한 상품 정보 데이터베이스라고 생각하시면 되겠습니다.
저의 경우 현재 라이브 중인 서비스에 대한 개편이다 보니 굉장히 어려움이 많은데요. 많은 것들에 대한 고려와 검토가 계속되다 보니 약 1년 가까이되는 긴 시간 동안 작업 중입니다. 그만하고 싶다.
상품 데이터 운영의 어려움
저흰 그렇게 성숙한 상품 플랫폼을 갖춘 회사는 아닙니다. 그러다 보니 이 상품 플랫폼에 자주 새로운 기능이 추가되곤 합니다.
상품 도메인을 경험해보신 분이라면 아시겠지만, 이 하나의 상품에 포함되는 데이터가 굉장히 많습니다. 상품명, 가격, 판매 시작일, 종료일, 상품 상세 설명, 상품 이미지, 상품 고시정보, 상품 인증 정보, 원산지, 배송정보, 옵션 등등 이외에도 수 십 개의 필드 혹은 연관 테이블이 필요하지요.
이 데이터들을 적절하게 나름 여러 테이블로 분리해서 개발을 시작했었습니다만, 운영을 하다 보니 상품 정보 메인테이블이 어쩔 수 없이 거대해졌고, 개선할 여유를 갖지 못한 채 운영을 계속할 수밖에 없었습니다.
그 상품 테이블에 수백만, 수천만 레코드가 쌓이다 보니 테이블 용량은 순식간에 커지게 됩니다. 앞서 언급했듯이 새로운 기능을 서비스에 추가하려면 그에 대한 데이터를 넣을 필드를 추가해야 하는데요. 담당 DBA에게 위처럼 거대한 테이블에 새로운 컬럼이나 인덱스 추가 요청을 하게 되면 서로 난감한 상황이 벌어지곤 합니다.
이유는, 온라인으로 빠르고 안전하게 얼터링을 하기엔 테이블의 데이터가 너무나 커져버렸기 때문입니다. 결국 사용자들의 요청이 뜸한 시간인 새벽시간대에 서비스 점검을 걸고 작업을 해야 하는데 이게 여간 부담스럽고 힘든 게 아닙니다.
물론 주기적으로 오래된 데이터를 지우면 해결되는 게 아니냐 생각하시겠지만, 상품 정보의 경우 만료되는 데이터가 아니다 보니 지우는 기준을 세우기도 애매합니다. 예를 들어 어떤 판매자가 한 달 전에 올렸던 상품은 인기가 시들해져서 판매 중지 처리했는데, 5년 전에 등록한 상품이 아직까지 잘 판매되고 있는 상황이 있을 수 있습니다. 실제로도 있고요.
DBA의 요구사항
기존 상품 시스템의 개편 작업이 마무리되어가고 있습니다. 애플리케이션 레벨의 개편뿐만 아니라 데이터베이스 구조도 개편하는 작업이기 때문에 DB 장비도 새로 발주를 받아야 했습니다.
저희가 DBA에게 원하는 조건은 단순했습니다.
“빵빵한 스펙의, 넉넉한 스토리지의 DB를 주세요.”
하지만 DBA들이 원하는 조건은 이러했습니다.
“빵빵한 스펙, 넉넉한 스토리지 드릴 수 있어요. 단, 개편 전의 거대한 상품 테이블 구조는 반드시 개선해주세요.”
해결방안으로 몇 가지를 제시해주셨습니다.
첫째로, 파티셔닝을 통한 주기적 데이터 삭제입니다. 하지만 위에서 언급했듯이 상품 데이터의 경우 명확한 날짜 기준으로 데이터를 삭제 하기가 좀 애매합니다.
둘째로, 샤딩입니다. 쉽게 말하면 거대한 테이블의 데이터를 적절히 나누는 것입니다. 사실 애플리케이션 개발자가 샤딩이 무엇인지, 샤딩이 왜 필요한지에 대해서 모를리는 없습니다. 다만, 샤딩을 할 경우 애플리케이션 개발자의 개발 방식과 지속적인 운영에 대한 피로도가 굉장히 높아집니다.
scale up? scale out? 샤딩?
다들 아시는 내용이겠지만 한 번 짚고 넘어가겠습니다.
scale up이란 머신의 성능을 올리는 방법입니다. scale out이란 머신의 추가를 통한 횡적 확장을 의미합니다. 대표적으로 mongoDB나 Elasticsearch의 데이터 노드 추가를 떠올릴 수 있겠습니다.
RDB의 경우는 scale out이 어렵습니다. mongoDB처럼 scale out이 가능한 구조가 아니다 보니 서버 스펙 자체를 올리는 scale up으로 대응하는 경우가 많은데요. 서버 성능을 무한정으로 늘릴 수는 없기에 분명 한계가 있습니다.
그리고 scale up을 떠나서, 한 테이블에 너무나 많은 데이터가 있으면 스토리지에 여유가 많이 남더라도 대응이 어려워집니다.
따라서 그때는 데이터를 수동으로 쪼개야 합니다. 그게 바로 샤딩입니다. 그 늦은 샤딩 시점에는 몇 천만, 몇 억 건의 데이터가 있을 것이므로 개발자 입장에선 굉장히 어려운 수고를 떠안아야 합니다.
아시겠지만 굳이 설명을 더 하자면, 샤딩은 크게 수직 분할과 수평 분할이 있습니다. 수직 분할의 경우 데이터의 필드를 여러 테이블로 쪼개서 구조화하는 방법입니다. 수평 분할은 테이블의 레코드를 여러 테이블로 나눠 저장합니다. 예를 들어 상품번호 1~100까지는 product1 테이블에, 상품번호 101~200까지는 product2 테이블에 저장하는 방법입니다.
애플리케이션 개발자의 고충
그러다 보니 단순히 조회만 하더라도 한 테이블만 뒤져도 될 것을 여러 테이블을 뒤져야 합니다. 수직 분할의 경우 쿼리에 join이 많아질 수밖에 없으며, 수평 분할의 경우 동일한 종류의 데이터를 여러 테이블에서 조회해야 합니다.
사실 위 내용은 DBA든, 애플리케이션 개발자든 상관없이 개발에 몸 담그고 있으면 누구나 아는 내용입니다. 그 아는 내용을 애플리케이션 개발자는 왜 외면할까요? 이유는 간단합니다. 개발이 훨씬 어려워지기 때문입니다. 위에서 잠깐 언급했습니다만, “join이 많아지고, select를 여러 테이블에서 한다”는 것은 말로는 쉽지만 실제 개발 공수는 몇 배는 더 커집니다. 심지어 연관 테이블들이 물리적으로 아예 다른 머신에 분리되어있다면 훨씬 더 어렵습니다.
때문에 애플리케이션 개발자 입장에서는
언제든 빠르고 안정적으로 DB 작업이 가능 하지만 몇 배의 개발 공수를 들이는 방법
몇 달에 한 번 있을까 말까 한 테이블 얼터링을 새벽 작업으로 진행해야 하는 리스크가 있지만 개발 공수가 현저히 적은 방법
이 중 후자를 택하는 경우가 많습니다.
처음부터 mongoDB 썼으면..?
물론 애초에 mongoDB와 같은 scale out이 자유로운 데이터 스토리지를 사용하면 되지 않을까 하는 생각도 했습니다. 만약 이 프로젝트가 저 혼자 진행하는 과제, 혹은 완전 신규 프로젝트였다면 이 방법도 고려했을 것입니다. 하지만 지금 진행하는 프로젝트는 무엇보다 안정적인 서빙이 필요합니다.
저희 DBA분들이 mongoDB와 같은 솔루션도 물론 지원을 하긴 합니다만, 아무래도 전통적으로 오랜 기간 동안 사용했던 RDB 운영을 더 안정적으로 하셨기 때문에 모험을 할 순 없었습니다. 실제로 그만큼 운영 노하우도 많이 쌓아 활용하고 계시고요.
그리고 과연 저희가 취급하는 상품 데이터가 관계형 데이터가 아닌 하나의 document 형태로 다뤄지는 게 옳은가에 대한 논의도 많이 해보았습니다. 결론만 얘기하자면 ‘아니다’였습니다. 따라서 mongoDB로의 전환은 scale out이 된다는 점 말고는 장점이 하나도 없다는 결론에 도달하였고, RDB를 계속 믿고 쓰기로 하였습니다.
참교육
어쨌든 제가 참교육당했던 부분은 위에 언급된 샤딩에 대한 이론적인 내용 때문이 아니었고요. 이런 것들을 저희에게 설득하는 DBA의 태도였습니다.
“저희가 귀찮으니까 샤딩이든 뭐든 꼭 해주세요. 매번 힘듭니다. 이런 식으로 하시면 운영 못해요.”
만약 이런 식으로 저희에게 요구해왔다면 매우 기분이 상했을 것입니다. 같이 잘해보자고 맡은 영역에 대한 운영 공수의 책임을 전적으로 저희에게 넘기는 듯한 태도이기 때문이죠.
하지만 저희 회사의 DBA들은 그렇지 않았습니다.
“현재 운영 중이신 그 서비스, 저도 정말 잘 이용하고 있습니다.
그 서비스가 빠르게 개발되지 못하는 상황,
혹은 안정적인 서빙이 어려워지는 원인이 DB 때문이라면 정말 안타까울 것 같아요.
DBA의 입장에서도 지원해드리는 그 서비스에 대해 주인의식을 갖고 있습니다.
때문에 그 서비스가 크게 성공하는 것이 DBA 입장에서도 기분이 좋습니다.
다만, 이런 식으로 데이터 구조개 개선되지 않은 채로 계속 쌓이다 보면 저희가 빠르게 대응해드리고 싶어도 그럴 수가 없습니다.
물론 서비스 개발 입장에선 어렵다는 거 압니다.
그리고 지금 당장 조치하지 않아도 몇 년 동안은 어떻게든 운영이 가능하긴 합니다.
하지만 이게 계속되면 2~3년 후에는 정말 더 이상 운영하기가 어려워질 수 있어요.
실제로 모 서비스의 모 테이블은 서비스 점검을 걸더라도 얼터링이 불가능합니다.
그 리스크를 감수할 수준을 넘어섰기 때문입니다.
그러니 꼭 사전에 이런 데이터 구조에 대한 깊은 고민 부탁드리겠습니다.
언제든지 고민되는 점이 있으면 저희에게 말해주세요.
조언해드릴 수 있는 것들에 대해선 성심성의껏 해드릴게요.”
어떤가요? 위아래 물론 결론적으로는 같은 내용이지만, 서비스에 대한 태도는 너무 차이가 납니다. 서비스 개발자 입장으로서 더욱더 믿고 뒤를 맡길 수 있다는 생각이 듭니다.
이론 적인 해결 방법이 아닌, 이런 마음가짐에 대한 참교육을 받았던 만남이었습니다.
마치며
회사 내부 사정 때문에 더 자세한 내용을 이 글에 담기는 어렵습니다. DBA가 어떻게 운영을 하는지, 어떤 수치까지는 괜찮고 어떤 수치가 넘어가면 정말 어렵다던지, 그럴 땐 어떻게 대응해야 하는지 등등 그분들의 고충과 그것을 해결하는 노하우를 이해할 수 있던 시간이었습니다.
저희는 DBA의 고충에 대해 어느 정도 이해하고, 단일 테이블에 많은 필드가 있던 엔티티를 적절한 수준으로 분리하는 방안을 수립했습니다. 개발 막바지이긴 하지만 이왕 개편하는 거 제대로 하는 게 낫기 때문입니다. 일정이야 뭐.. 조정하면 되니까요.
누구에게나 자신들의 입장이 있습니다. 그러다 보니 상대에게 원하는 것이 생길 때도 있죠. 그 원하는 것에 대해 응해주지 않을 때 불신이 생기게 됩니다.
하지만 이렇게 대화를 통해 서로의 입장을 알게 되니 더욱 서로를 이해할 수 있게 되었습니다.
그러니, 모르면 물어봅시다.
