달리는 인증 서비스의 NoSQL을 바꾸자. - 후기
달리는 인증 서비스의 NoSQL을 바꾸자. - 후기
회사에서 진행한 글에 대한 뒷이야기와 생각을 작성합니다.
작업에 대한 생각
아는 사람한테 이 작업을 마무리 했을 때, 정말 겁이 없다라는 이야기를 들었다. 어느정도 나도 공감하는 이슈이다. 회사에서 어찌저찌 돌아가고 있는 서비스를 갈아엎는다는 것은 따로 얻는 것 없이 리스크를 짊어지는 것이라고 생각한다.
물론 이 작업이 필요가 없는 작업이였나 물어보면, 반드시 필요한 작업이였다. 그러나 이 필요한 작업을 남들에게 설득시킬 수 있는 것은 다른 문제라고 생각한다. 개발자 입장과 기획자에서는 반드시 필요한 작업이였으나, 이를 사용하는 유저 입장에서는 정말 티가 안나는 작업이다. 큰틀에서 보면 백엔드 개발자로서 겪는 문제라고도 느낀다. 그러나 미래의 작업을 위해서 꼭 해야했던 작업이었다.
앞서 원글에서 이야기 했듯 이 작업을 진행할 때는 어떻게든 비즈니스와 엮어서 진행한다. 작은 비즈니스적인 개선을 하더라도 이를 같이 수면 위로 드러나게 하여, 결과가 나오게 작업을 만들고 싶다. 이럴 때 커뮤니케이션의 실력과, 비즈니스 인사이트, 개발 실력에 대한 하모니가 필요한 시점이라고 생각한다.
레거시에 대한 전략
레거시에 대한 생각은 꾸준히 바뀌는 것 같다. 입사하기전이나 초창기에는 레거시는 무조건 나쁘다라는 생각이 있었다. 레거시의 의미 개념을 생각하면 얼추 맞는말이긴한데, 관리를 안한 코드의 문제이고, 이는 개발자, 자원을 주지 않은 회사의 문제라고 생각한다.
관련해서는 그래서 욕심이 좀 있다. 내가 이 도메인을 책임진다면, 내가 역사를 하나 쓰고 싶다는 것. 과거 10년~20년 된 코드를 내 선에서 끊고, 신규 서비스를 진행할 준비를 하고 싶다는 것이 가장 큰 욕심이다.
이번에 서비스 개선 등을 진행하며, 동시에 작업하는 것이 많다. 내 업무시간에 하는 회사일도 있고, 퇴근해서 또 하는 다른 회사일, 주말에도 회사일을 좀 본다. 개인적인 욕심이 좀 많다.
회사가 나를 어떻게 볼지는 모르지만, 나는 회사에 대한 애사심이 좀 많은 것 같다. 회사의 서비스에서 셀러 서비스가 난 약점이라고 생각하고, 물론 그 약점이 우리팀에 있는 것은 아니고 모든 팀이 다 걸쳐있겠지만, 그 중에서 난 우리팀이 가장 변화에 적응할 수 있는 팀이 되고 싶다. 솔직히 더 본심을 이야기하면 내가 있는 조직이 언제나 변화에 가장 크게 적응하는 팀이 되고 싶다.
내가 개발자라는 직업을 좋아하는 이유는 정말 노력하고 투자하면, 2명 혹은 3명, 혹은 그 이상 10명 치의 일을 할 수 있다는 점이다. 그렇기 때문에 더 노력하고, 갈고 닦고 싶다. 다들 알다시피, 개발자들이 개발하는 모습을 보면 코드를 고민하는 시간이 대부분이고, 검색하는 부분이 대부분의 시간을 차지하고 코드를 짜는 시간은 어찌보면 그렇게 많지 않다.
고민과 검색하는 시간을 코드로 짜는 시간으로 바꾸고, 코드를 짜면서 그 고민과 검색하는 시간을 압도적으로 줄일 수 있으면 어떨까? 그 사람은 엄청난 시간과 에너지를 아껴서 퍼포먼스를 만들 수 있다고 생각한다.
과거 읽은 책 중 하나가, 업무를 하다가 다른 창, 화면을 보는 것이 엄청난 집중력 저하를 일으킨다는 연구결과를 본적이 있다. 개발을 할 때도 마찬가지라고 생각한다. 그래서 좀 더 효율의 극대화, 비즈니스의 방향 추구 등이 내 요즘 최고의 관심사다.
배포하고 발생한 이슈
언제나 그렇듯 큰 배포가 나가고 나면 여러가지 이슈가 발생한다. 큰 이슈는 발생하지 않도록 하나 여러 작은 이슈들이 발생한다. 그 이슈의 작고 큰 유무는 개인의 판단에 다르고, 회사 측면에서도 다르나 일종의 버그이니 얼른 해결을 해야한다고 생각한다.
1. Couchbase 와 MongoDB 전환시 Map 형태의 차이
놀랍게도 이커머스의 초창기 회사에 있기에 여러가지 아이디 계정을 보게된다. 아이디는 대부분의 서비스에서 유효한 키를 차지하기에 한번 생기면 바꾸기가 거의 어렵다. 특히 몇년동안 쌓인 잘못된 정책의 데이터가 이후 변경을 힘들게한다. 특히 초창기의 웹 서비스에서는 아이디에 대한 규칙이 없기 때문에 그 규칙을 깬 계정으로 인해 여러 서비스에서 방어로직을 넣고 서비스 이슈가 발생하게 됩니다. (대표적인 예시가 특수문자와 공백입니다.)
근데 이번에 작업을 하면서 특정 계정의 경우, 아이디에 "." 가 들어가는 문제가 있었습니다. Couchbase에서는 map 데이터에 "." 가 들어가는게 허용이 되는데, MongoDB에서는 이 값을 사용할 수가 없습니다. 그래서 싱크 때 여러 버그가 터지는 케이스가 있었습니다. 이런 부분을 치환해서 저장을 해야하는데, 치환해서 저장한다는 것은 다른 곳에서도 볼때마다 치환해서 봐야한다는 사실을 의미합니다. 즉, 여러 서비스에서 공통적으로 사용해야 한다는 것입니다.
2. 급격한 성능 저하
couchbase에서 mongodb로 전환했을 때 바로 성능이 따라오냐는 다른 문제입니다. 그리고 그 문제는 직접적으로 발생했습니다. 따라서 어떤식으로든 최적화가 필요한 상태입니다. 기존에서 couchbase에서 나오던 latency의 2배 ~ 3배 정도로 더 느려졌습니다.
추측은 다음과 같습니다.
- id로 접근을 특정 value로 접근을 해서 (다만, value로 indexing 처리를 했습니다.)
- mongodb보다 couchbase가 더 빨라서.
- 최적화가 되지 않아서.
3. 일부 데이터 검증 방법
데이터 양을 비교하는 것도 고민을 해야합니다. couchbase와 mongodb의 document 수가 같은지, 다르다면 어디서 차이가 나는지 걱정을 해야합니다.
mongodb의 퍼포먼스를 올릴 수 있는 코드를 찾고 있고, 그 코드를 체크할 부분을 찾아야합니다.
대표적인 예시로 find 가 아닌 findTop 으로 바꿨고, 더 빠른 처리를 고민하고 있습니다.
primary index와 secondary index의 차이가 있는지도 체크가 필요합니다.
어떤식으로 할 수 있을까... 생각보다 코드가 안나온다... 검색 체크가 필요한데...
해결 방식
1. MongoDB Converter 사용
"." 을 어떤걸로 전환을 할까 했는데, 결국은 아스키로 저장을 했습니다. "." 으로 변경해서 저장을 했고, 그 외에 어떤 특수문자를 할까 고민을 했는데 괜찮은 게 없었다.
@Bean
public void setUpMongoEscapeCharacterConversion() {
mongoConverter.setMapKeyDotReplacement(".");
}2. 성능 저하 해결
데이터가 어디서 시간이 많이 걸리는지 체크를 했는데, 특정 document를 접근하는 경우가 제일 많은 시간과 요청이 있었다. 그 값은 자주 변경되는 값이 아니기 때문에 1분 캐시를 먹여서 해결을 했다. 정말 드라마틱하게 mongodb의 트래픽을 줄였고 서비스 적으로도 이슈가 없었다.
mongodb에서도 건드릴 수 있는 부분이 있으면 체크를 할려고 했으나, 그 부분을 잘 해결되지 않았다.
3. 노가다로 맞춘다.
데이터는 억지로 맞추고, 버그 발생시 즉각적 대응 및 버그를 계속 체크한다.
어떻게 더 나아갈 수 있을까?
가장 어려운 부분이라고 생각한다. 특히, 나는 야근과 주말일이 가득한 사람이고 내 개인적인 욕심이 많기 때문에 남한테 이를 강요할 수는 없다. 최근 토스에서 이야기가 많은 것처럼, 나또한 내 욕심이 남의 철학을 건드려서는 안된다고 생각한다. 각자 자신의 스타일이 있고 그 스타일을 조율하는 것이 중요하다고 생각한다.
함께 가며, 전략적으로 가는 방법. 그리고 그들의 본심을 꺼낼 수 있는 방식을 가고 싶다. 그리고 나는 남들을 평가할 수 없으나, 남들에게 무언가를 부탁하려면 그 이상의 작업을 해야한다고 생각한다. 그래서 나는 남들이 하는 작업의 두배이상을 하려고한다. 그래야지, 다른 사람에게 뭔가를 이야기할 명분이 생긴다고 생각한다.
