반응형

사내에서 처음으로 세미나를 진행했다.
다행히 온라인이라 스크립트 작성해서 보면서 읽을 수 있어서 자연스럽게 말하려고 연습하느라 죽을 뻔 😇

세미나 주제는 7월에 발생했던 DB 장애의 원인과 해결 그리고 트러블슈팅을 간략히 소개하고
구조적으로 남아있는 Master/Slave DB 구조의 한계에 대해 말하고 팀 차원에서 개선 방향을 논의하기 위해서였다.
Master/Slave DB 구조의 장애 내용과 개선 방안에 대해서는 아래 링크에 정리해두었다.
(참고로 Master/Slave 라는 단어 대신 Writer/Reader라는 단어를 사용하는 흐름으로 바뀌었다)

2021.09.23 DB 장애로 배운 Master/Slave DB 아키텍처 개선 방안

 

2021.09.23 DB 장애로 배운 Master/Slave DB 아키텍처 개선 방향

2021년 7월, DB 장애가 발생했다. 현 회사의 DB는 Writer 인스턴스 1대와 N개의 Reader 인스턴스로 이루어져있는 Master/Slave 구조인데, Writer에 허용량 이상의 세션이 물리면서 DB가 죽게 됐다. 다음부터는

prohannah.tistory.com

 

사실 세미나를 할 생각은 없었고, 원래는 1차 DB 접근 방법을 개선하기 위해 구현한 공통 클래스의 설명과 사용법을 안내하려고 했었다.
그런데 단순히 사용 방법에 대해서만 안내하면 장애 사건과 사내 DB 구조에 대해 배경 지식이 없는 분들은 단순히 '코드 스타일이 달라졌다, 레이어가 분리되었다.' 정도의 감흥만 있을 것 같았다. 그래서 문서를 작성할 때 깔끔하게 사용법만 가이드해서 가독성을 높일까? 이 클래스가 필요하게 된 이유와 한계에 대해서도 함께 공유할까 많이 고민을 했었다. 그러다가 왠지 처음 공유하는 문서니까 다들 관심있게 봐주실 것 같아서 가독성 포기하고 문제 배경과 조치 방안 그리고 DB 구조적인 문제에 대해서도 문서에서 함께 다뤘다.

텍스트로만 가능한 세미나 발표자료 중 일부 😂

문서를 팀에 공유했는데 한번 세미나를 열어보라고 제의를 해주신 분이 계셨고, 나도 이 문제에 대해 팀 차원에서 함께 논의하는 게 좋을 것 같아서 알겠다고 말씀드리고 진행했었다. 😇 심장 떨려서 죽는 줄 알았다.

위에 링크한 포스팅에서도 적어놨지만, 세미나에서 발표할 때 어렴풋이 주워들은 개선 방향에 대해 정리해서 공유했고, 마이 유니콘님께서 이 클래스의 한계점에 대해서 명확하게 한번 더 쉽게 풀어서 설명해주셨다. 그리고 단기적/장기적 개선 방향에 대해서 의견을 나눠주셔서 너무 좋았다. 궁금한 게 생겨서 물어보면 척척 답변을 해주셨다 🥰 최고야 짜릿해

나는 다수의 앞에서 발표 형식으로 말하는 거에 되게 부담감을 가지고 있어서 문서나 글로 내용을 공유하는 게 더 편하기는 했는데, 주제에 따라서 집중을 한번에 받을 수 있고 피드백을 주고 받는 게 빠른 세미나를 선택하는 것도 효과적이라고 생각한다.

반응형