Cloud Database Expert (CDE)

클라우드 비중이 높아짐에 따라 변화하는 DBA의 역할

오랜만에 포스팅입니다. 요즘은 기술적인걸 뭘 적어야하나 고민이 있기도 하고, 일도 바쁘고, 늦은 나이에 통계학을 전공하겠다고 대학 공부를 하다보니 좀처럼 여유가 없네요.

전에 데이터베이스 직군에 관한 글을 쓴적이 있는데 많은 분들이 질문을 주셨습니다. 저는 다른 DBA들보다 빠르게 변화를 받아들이고, 전형적인 온프렘 DBA에서 탈피하고, 클라우드를 최대한 활용하는 방법을 찾는 편입니다.

앞으로 많은 회사에서 원하는 DBA 포지션은 대기업이나 금융권처럼 DB팀 단위 구성보다 아마 성공한 스타트업의 IPO, ISMS 등을 준비하거나 규모가 커지면서 DB의 성능적인 이슈로 한계에 부딪혔을 때 전체적인 개선을 위해 더 많이 찾는 포지션으로 변하지 않을까 생각합니다. 물론 어디까지나 개인적인 의견입니다. 제 의견이 100% 맞지는 않을 것이고, 다르게 생각하는 분들도 계실테니, 아 이런 생각이 들수도 있겠구나 하고 넘어가주시면 될것 같습니다.

업무 범위의 변경

기존의 오라클이 주를 이루던 시절에 DBA는 대부분 운영 DB의 대한 관리 운영 업무가 주였고, 백업은 백업 업체 혹은 유지보수 업체를 통해 하청을 두는 경우가 많았고, 설치, 구성, 트러블 슈팅 같은 엔지니어링 업무는 SI 업체에 유지보수 계약을 통해 일감을 주는 경우가 많았습니다. 또, 데이터 모델링이나 신규 프로젝트, 데이터 이관 같은 업무는 DA 컨설팅이나 프로젝트 단위로 계약을 하여 진행하는 경우가 많았죠. 즉, 실제로 모니터링 하면서 긴급 장애에 1차 대응하고, 유저 관리나, 정책적인 부분 등을 처리하고, SQL 검수 하는 정도만 하는 경우가 많았습니다. 튜닝 같은 것도 대부분 프로젝트 단위로 튜너를 고용하고는 했죠.

데이터베이스는 업무 범위가 굉장히 넓고, 대부분 DBA를 둘 정도의 규모의 회사면, 직접 모든것을 하기 보다는 1차적인 운영을 제외하고 대부분의 엔지니어링 성격의 업무는 매니지드만 하는 역할이 많았죠. 지금 금융권이나 DB팀이 자리잡은 대기업 혹은 중견기업들은 비슷하게 운영되는 곳이 많을 겁니다.

최근에는 기업들이 비싼 오라클 라이선스 비용을 줄이려는 노력을 하고 있고, 클라우드의 파이가 커지면서 AWS를 사용하는 기업이 엄청나게 늘어났습니다. 특히나 스타트업들은 온프렘 환경보다 AWS를 많이 선택하고 있습니다. 따라서 AWS도 스타트업 회사들을 대상으로 RDS 홍보를 할 때 AWS를 사용하면 DBA가 없어도 DB 운용이 가능하다며 고객 유치를 하고는 하죠.

위 자료를 보면 모든 것을 기업이 해야하는 온프렘 환경에 비해, 완전관리형 DB인 Aurora를 사용하게 되면서 데이터 모델링 및 비지니스 로직만 구성하고 그 외의 회색 부분은  AWS와 공유하게 되어 업무가 줄고, 녹색의 하드웨어 적인 부분은 AWS로 넘어가는 것을 어필합니다. 많은 부분에서 매니지드 서비스가 이루어지며, 기업 입장에서는 간편해지고 있지만, 제 생각에는 결국 DBA는 필요합니다.

데이터베이스의 성능은 어디까지나 I/O를 줄이는 것이 첫번째 입니다. I/O를 줄이기 위한 데이터 정규화, 비지니스 모델에 최적화된 데이터 모델링, 그리고 Slow 쿼리 튜닝은 매니지드 서비스라도 절대 DBA가 없으면 안되는 일입니다. DBA가 없는 경우 대부분 인스턴스의 사이즈를 키운다거나, 수를 늘리는 방법, 즉 비용을 증가시켜 해결하는 경우가 많은데, 이러한 방법은 기업 입장에서 장기적으로 좋은 모델이라고는 볼 수 없습니다. 인스턴스의 크기가 커지면 비용은 급격하게 늘어나게 되죠. 그렇기 때문에 DB의 성능을 최적화 할 수 있는 DBA는 기업 규모가 커져가는 단계에서는 반드시 필요하다고 이야기 할 수 있겠네요. 장애처리나 어려운 점은 밴더사나 파트너사를 통해 처리하는 방식으로 변해가고 있기에 설치나, 트러블슈팅, 백업 관리등 엔지니어링 적인 부분에서 부담은 줄어들고 있습니다.

기존에 DBA는 대부분 하나의 기종, 특정 데이터베이스 기종에 특화되어 있는 사람이 많습니다. 오라클, MySQL 등 RDBMS가 주로 시장을 이루고 있었죠. 하지만 클라우드와 매니지드의 장점을 통해 우리는 하나의 DB에 매여 있을 필요가 없어 졌습니다. 기업은 빠르게 변화하는 트렌드에 대응하고, 많은 정보가 오고 감에 따라 대용량 데이터베이스를 필요로 하게 되었습니다. MSA나 쿠버네티스를 이용한 컨테이너 서비스를 필요로 하는 기업도 늘고 있고, 좀 더 복잡한 관계를 표현하거나, 수많은 정보에 대한 분석을 원하는 기업도 늘고 있습니다. 따라서 DocumentDB, GraphDB, Key-Value, Wide Column Store 등 다양한 DB를 용도나 기능에 맞게 사용해하는 시대가 되었습니다.

다만 혼자 이런 다양한 DB를 모두 다룰수 있는 사람이 시장에 많지 않고, DB라는게 한 기종의 전문가가 되는데 있어서 오랜 시간이 필요하기 때문에 모두 잘하는 것은 참 어려운 문제입니다. 각 데이터베이스는 해당 DB가 가진 저만의 아키텍처가 있고, 그 아키텍처에 맞는 데이터 모델링을 해야 어떤 DB던 간에 성능을 보장할 수 있습니다.

한 가지 이상 RDBMS를 다룰수 있고, 두 가지 이상의 NoSQL 데이터베이스를 다룰수 있으며, 각 DB에 맞는 모델링을 할 수 있고, 기능적으로나 용도에 맞게 적재적소에 사용할 수 있다면(SA적인 측면을 이야기 합니다) 클라우드 데이터베이스 전문가! 라고 부를수 있지 않을까요?

인력은 부족하고, 기업은 빠르게 많은걸 개발하길 바라는 최근 환경에서 DB는 장기적인 관점에서 볼수 있는 좋은 모델링을 더 많이 필요로 하게 되고, 개발팀이 원하는 빠른 대응과 비지니스 로직에 맞는 데이터 모델링 등 적극적인 참여를 통해 개발 전반에 같이 협업할 수 있는 커뮤니케이션 능력이 중요해 졌습니다. 즉, DBA들에게도 변화의 시기가 오고 있다라고 생각합니다. 앱의 빠른 반응 속도, 빠른 검색, 빠른 동작 등은 생각보다 매출을 올리는데 좋은 방법 중 하나입니다. 한국인은 빨리빨리의 민족 아닙니까? 최적의 DB를 선택하여 성능을 더 늘릴 수 있다면 더 이상 RDBMS를 고집할 이유도 없습니다.

물론 하나의 DB를 깊게 파고, 세세한 아키텍처 까지 들여다 보고, 더 깊게 가져가는 것도 좋다고 생각합니다. 하지만 빠르게 개발해야하는 환경에서 개발자들하고 더 많은 커뮤니케이션을 하는 것이 재밌고, 회사 상품 개발에 전반적으로 참여하길 원한다면 넓고 다양하게 가져가 보는것도 재밌게 일할 수 있는 방법중에 하나라고 봅니다.

클라우드에 입문했을 시기와 현재를 비교해 보면

2013 ~ 2014년 이때 쯤 많은 기업이 가상화 장비에 관심을 크게 기울이기 시작했죠. VM웨어나 Xen 서버 같은 가상화 장비들이 도입되기 시작했습니다. VM웨어에 DB를 올려서 서비스 하는 기업도 보이기 시작했습니다. 미국에선는 2006년 아마존이 처음 공유 스토리지 서비스 S3를 선보이면서 클라우드 서비스의 터를 닦았고, 이듬해 다양한 클라우드 서비스를 출시하면서 지금의 AWS가 되었습니다. 2010년 즈음에 공유 스토리지 서비스를 클라우드라고 내세우며 서비스 하던 국내 기업들이 생겨났고, 2020년에는 본격적으로 IaaS, PaaS, SaaS 제공하는 국내 클라우드 업체도 늘기 시작했습니다.

제가 클라우드에 관심을 가진건 2017년 후반기 쯤인것 같습니다. 이 비싼 오라클이 과연 언제까지 갈까? 라는 의문이 들었고, 오라클의 대체재는 뭐가 있을까 고민하게 되더군요. 클라우드에 관심이 있는 인프라 엔지니어들이 오픈스택을 가지고 다양한 시도를 하기 시작했고, 오픈스택이나 아파치 클라우드 스택 등을 통해 클라우드 서비스 구현을 위한 노력을 시작한 시기인것 같습니다. 그리고 첫번째로 관심을 가진 오픈소스DB가 PostgreSQL이었습니다. 그리고 자연스럽게 MySQL, MariaDB와 비교가 시작 되었습니다. 클라우드 쪽으로 전향 하고자 선택했던 것은 PostgreSQL였는데 지금은 MySQL DBA, 정확히는 AWS Aurora DBA를 하고 있네요.

1년간 PostgreSQL을 현업에서 만져보면서 참 힘들었습니다. 레퍼런스도 없고, 국내에 번역된 자료도 많지 않았거든요. 뭔가 구현하려면 추가적으로 설치해야하는게 뭐가 그리도 많은지… PostgreSQL 처음 접할 당시에 안정화 버전은 9.6버전이었고, Auto Failover나 커넥션풀 관리등을 위해서는 설치해야하는 것들이 많았습니다. 그러면서 P-S-S 구조로 자동화 배포를 만들고, 설치시에 VM 사양에 맞게 자동으로 파라미터를 조정하고 하는 작업을 위해 Ansible을 공부하게 되었고, 이 때를 기점으로 정말 많은 공부를 시작한것 같네요. 당시에는 오픈스택 위에 모든걸 구현해야 했기에 설치 자동화나 다양한 오픈소스 POC, BMT들 하게 되었고, 그러면서 시야가 넓어지게 된 것 같습니다. 그러다 보니 비지니스가 원하는 기능 구현을 위해 용도에 맞는 다양한 데이터베이스에 대한 관심도 생기기 시작했고, MongoDB나 Redis, 엘라스틱 서치, Neo4j, Arango 등 을 공부해보게 된거 같습니다. 깊이 보단 넓이를 선택하였고, 지금의 저는 5개 이상의 데이터베이스를 잘 다룰 수 있다고(데이터베이스 특성에 맞는 모델링과 인프라적인 SA 구현, 개발 가이드 제공, 튜닝) 말할 수 있을 것 같네요.

늘 말하는 거지만, 정답은 없습니다.

깊이도, 넓이도 좋습니다.

늘 안정적인 것도, 늘 새로운 것을 찾는 것도 모두 좋습니다.

하고 싶은 대로, 마음 가는대로 자신만의 답을 찾길 바랍니다.