2023년 한해를 돌아보며…
언젠가 불가리아 바르나 흑해에서 찍은 일출
또 새 해가 밝았습니다! 2023년 안녕~
2023년 어찌보면 많은 것을 이뤄낸 해기도 하고, 개인적으로 스스로를 DBRE라는 틀에 맞게 조금씩 바꿔간 그런 한 해였습니다.
정신없이 지난간 것 같으면서도, 나름 잘 정리를 하며 지나간 듯 합니다.
그래서 2023년 한해를 정리해보고자 합니다.
2023년에 한 일
AWS RDS Aurora for MySQL v1 의 EOL에 따른 데이터베이스 버전 업그레이드 작업
AWS에서 EOL이라고 공시한 마지막 유효기간이 2월 28일이었던것 같습니다.
작년부터 개발 본부에 EOL 준비해야 한다. 크게 목소리를 높였지만, 크게 돌아오는 반응 없었습니다.
스테이징 환경도 없기 때문에 테스트 환경에서는 실제 운영에서 발생하는 변수를 잡아내기는 쉽지 않은 일이고, 또한, MySQL 엔진이 5.6에서 5.7로 업그레이드 되는 과정에서 옵티마이저가 RBO에서 CBO로 바뀌고, 여러가지 변경점으로 인해 수행되는 쿼리들의 플랜이 바뀌는 일도 대비를 해야 했기 때문에 일거리가 많았습니다.
실제, Slow Query로 잡히는 모든 쿼리들을 수집해서, 5.7버전에서 테스트하고, 5.7에서 속도가 안나오는 쿼리는 튜닝해서 개발팀에 전달하고 업그레이드 후에 작업 해야할 내용들을 기록하여 업그레이드 이후 바로 적용을 위한 준비를 했습니다.
Aurora v2 버전으로 업그레이드를 하면서 잡고 싶었던 부분이 많이 있었습니다.
이미 제가 입사전에 MySQL의 상태가 말이 아니었기 때문에, SQL_MODE=0, 이나 ‘0000-00-00 00:00:00’으로 채워진 제로 데이트 값을 제거하고, 안쓰는 테이블, 인덱스를 모두 정리하고 5.7로 버전업을 하고 싶었으나,
워낙 신규 서비스 런칭에 챌린지가 많은 본부 상황으로 하여금, 소스를 수정할 여유가 없어 그냥 버전업과 SQL 튜닝, 그리고 기존의 프로시저를 최대한 걷어내는것에 만족해야 했습니다.
실제, Aurora의 병렬 쿼리 기능 및 몇몇 메모리 조율 실패로 인해 첫번째 업그레이드 작업은 실패로 돌아갔고, 2주간 재정비를 통해 다음 작업에서 버전 업그레이드 작업을 성공적으로 완수할 수 있었습니다.
EOL 준비를 하면서 많은 일이 있었습니다. EOL을 앞두고 AWS에서는 부랴부랴 블루그린 배포 기능의 베타 버전을 출시하였고, 실제 베타 버전을 사용하면서 겪게 되는 문제가 많았습니다.
오죽 했으면 AWS팀으로 부터 먼저 사과메일을 받았을까요?
결국엔 업그레이드를 완료하고 이런 글을 쓸 수 있게 되었지만요
EOL 기간내에 버전 업그레이드를 한 것은 다행이라고 생각합니다.
하지만 SQL 표준을 지키기 위한 SQL_MODE 적용이나, 불필요한 오브젝트들을 덜어내고 데이터 품질에 대한 근본적인 개선을 요구했으나, 그런 저의 목소리가 개발본부에 닿지 못한 점은 좀 아쉬웠습니다.
히스토리가 없는 레가시의 존재는 정말 서비스를 운영하는데 큰 애로사항이 된다는 걸 뼈저리게 느꼈습니다.
하지만 이후, 그동안 수집한 자료들을 통해 불필요한 오브젝트를 착실히 하나 둘씩 걷어내고 있으며, 프로시저를 사용하던 로직도 대부분 소스단으로 전환하여 DB의 부담을 낮추는 작업을 계속 진행해 왔습니다.
2024년에도 Aurora for MySQL v2의 EOL이 있을 예정인데, 올해는 모두 작년보다는 많이 협조를 해 줬으면 하는 바램입니다. SQL_MODE = 0 이거 진짜 걷어내고 싶다구요.
CDC를 위한 사전 준비 작업
제 입장에서 가장 아쉬운 작업중 하나입니다. AWS Aurora for MySQL은 더티 페이지를 사용하지 않는 이슈로 인해 BinLog 사용에 대한 기본값이 OFF입니다. 예전 버전에서는 그에 따른 성능 이슈도 있었구요.
떄문에 정말 많은 테스트를 하였고, 부하 테스트를 하며 나온 측정값으로 Aurora의 성능을 어느정도 정확하게 파악 할 수 있었습니다.
실제 준비는 다 해놨는데, 블루그린 테스트 당시, 한국 문서에만 MIXED만 된다, 그리고 공식문서에 권장값은 MIXED로 나와 있기에 생각없이 Binlog_format을 MIXED를 택한 것이 큰 문제가 되었네요.
실제 CDC를 위한 Binlog_format 값은 DMS나 카프카 debezium이나 모두 row 말고는 지원하지 않는데 말이죠..
결국 재구동을 한번 더 해야해서 다음 서비스 점검 때까지 미뤄두고 있는 상황이 좀 아쉽게 되었습니다.
신규 플랫폼 데이터 설계
지금 메인 서비스의 데이터베이스는 말 그대로, 개발자들이 모여 개발하다 운영으로 전환하고 되는 되로 설계한 DB를 가지고 있기 때문에 입사 2년차가 지났음에도 계속해서 개선 작업을 하고 있습니다.
정규화 하나도 안된 테이블들, 컬러인 100개, 200개 씩 있는 테이블들, 데이터 중복도 너무 많고, 중복 데이터가 여기저기서 발생하여 데이터 정합성과 무결성이 전혀 지켜지지 않는 테이블 설계 등등… 엉망진창인 인프라와 더불어 스타트업들이 갖는 DB 고질병이죠.
회사에서 신규 서비스를 런칭하게 되었는데, 갑자기 7월쯤인가 개발을 해서 11월에 오픈해야해 라고 이야기를 하더군요.
신규로 가는거 DB만큼은 최대한 이쁘게 모델을 뽑아서 가자. 그게 성능에서도, 확장성에서도 좋기 때문에 이쁘게 정규화 모델 뽑아서 가자 라고 결심했고,
미친듯이 기획 컨플과 피그마를 보고, 또 기획자들과 미팅 해가면서 빠르게 설계 했습니다.
컨플에 모델에 대한 변경 히스토리를 지속적으로 업데이트 관리하면서 개발자들과 소통을 원활하게 하였고, 정확한 ERD와 테이블 정의서를 매 버전 제공을 했기에 개발자들로부터 좋은 피드백을 받을 수 있었습니다.
그리고 데이터 모델 자체는 주어진 시간이 짧았지만 매우 잘 뽑은것 같습니다. 정규화 원칙도 3정규화까지는 잘 지켰고, 데이터 품질을 위한 초기 네이밍 규칙이나, 약어에 대한 정의, 기본이 되는 것들이 다 잡고 들어갔고,
MySQL 특성상 데이터가 쌓였을 때, Count()에 대한 대처나 Block I/O을 최적화 하기 위한 노력을 많이 했습니다.
아무래도 예전 회사에서 기존 MSSQL 데이터를 신규 MySQL 데이터베이스로 옮기면서 재설계 작업을 많이 했던게 큰 도움이 되었습니다.
SlowQuery에 대한 모니터링 개발
Aurora MySQL의 슬로우 쿼리는 슬로우쿼리 로그나 퍼포먼스 스키마에 의존하는 클라우드 와치등에 의존하는 수 밖에 없습니다.
써보신 분들은 알겠지만, 슬로우쿼리 로그나 클라우드 와치에 매번 접속하는 것은 매우 불편합니다.
그래서 파이썬으로 슬로우 쿼리 수집기를 만들었고, information_schema의 PROCESSLIST를 직접 스크랩하여, 실행 시간이 일정 시간이 지난 쿼리들을 캐시에 담아두었다, PROCESSLIST에서 빠지면 MongoDB에 저장하고, 필요에 따라 OLD플랜을 같이 저장하는 방식의 수집기를 개발했습니다.
SQL 쿼리를 직관적으로 보여주고, Markdown 형식으로 내려받을수 있게 API 개발도 되었습니다. MD형식이라 컨플에 첨부하거나 할때 정말 좋습니다.
해당 쿼리 수집을 통해 20여개의 쿼리를 튜닝하고 인덱스를 컴파운드 인덱스로 조정했습니다.
아직도 수집기에 쌓이는 쿼리양을 보면 갈길이 멀긴 합니다만 , 져희 회사 앱이 조금은 빨라진 것 같다고 느끼시면 다 제 덕입니다.
그 외도 RDS_EXPORTER나 클라우드 와치를 접속해야지만 확인할 수 있는 데이터를 손쉽게 그라파나에서 모아 볼수 있도록 계속 개발 작업중에 있습니다.
데이터 통계학과에서 두 번째 학사 학위 취득
아 길고길 통계학 전공과정이 끝나고 이제 졸업입니다. 통계학 정말 힘들었습니다.
수학, 알고리즘, 데이터마이닝, 딥러닝 등등 요즘 통계학과에서는 통계 분석 뿐만 아니라, AI 관련 수업도 많이 늘었습니다.
결국 AI도 통계학을 기반으로 알고리즘이 만들어지다보니…
아직은 힘들게 배운 통계학으로 어떻게 활용할지 머릿속 구상만 하고 있습니다.
AI쪽 데이터 설계 업무를 좀 해보고 싶은 마음입니다.
주요 업무는 이 정도였고, 팀에서 진행하고 있는 IaC덕에 테라폼도 깔짝 대보고, 모니터링 개발을 하면서 파이썬도 해보고, Go도 해보고, node.js도 해보고 다양한 시도를 해본 한 해 였던거 같습니다.
올 한해 솔직히 회사에 실망한 적도 많고, 주변 몇 이상한 동료로 인해 회사를 떠나고자 했던 맘이 들었던 것도 사실입니다.
회사에 입사해서 이런 과정을 밟으면서 회사 데이터베이스 업무에 많은 것을 했다고 생각했는데 작년에는 평가도 박했다고 생각을 했고, 역시 IT 회사가 아니라 IT인력에 대한 평가가 박한가 하면서 말이죠.
올해는 우리 잘생긴 정팀장님이 힘써주고, 어여쁜 본부장님께서 힘써주신 덕분에 노력한 만큼 평가도 받고 연봉인상도 챙긴것 같습니다.
그리고 DBA를 하면서도 “앞으로는 뭘해야 할까? SA로 전향? 데이터 사이언티스트로 전향?, AI 분야로 전향?” 을 고민하던 저에게 당분간 DBRE로 틀을 잡고 갈 수 있도록 해준 한 해였던 것 같습니다.
좀 더 나은 DBRE가 되고 나서, 다른걸 생각해 봐야겠습니다.
2024년의 목표는 우선 EOL과 모니터링 고도화, 그리고 신규 플랫폼 런칭이 있겠고, 개인적으로 Neo4J같은 그래프 데이터베이스로 AI의 기반으로 사용할 수 있는 그래프 데이터베이스의 설계 및 데이터 분석을 해보는게 목표입니다.
최신 댓글