일정이 절반이 된 인증 개선 프로젝트의 우선순위와 단계 분할 (2023-07)

세 가지 문제와 앞당겨진 일정

성수기 트래픽은 해마다 늘고, 지금까지 쓰던 임시방편은 한계에 이르렀습니다. 팀은 문제를 세 범주로 정리했습니다. 트래픽이 늘면 master DB 부하도 같이 늘어 scale up만으로는 버티기 어려운 구조였고, 거대한 모놀리식 서비스는 작은 변경도 배포 비용이 컸습니다. MSA로 분리된 서비스마다 인증 로직을 따로 구현해 변경을 여러 곳에 반복 적용해야 하는 문제도 있었습니다.

팀은 시니어 1명과 경력이 합쳐 1년이 안 되는 주니어 2명입니다. 스토리포인트 산정이 어려워 스프린트마다 반드시 끝낼 일을 정하는 방식으로 계획했고, 개발 기간은 2달, 목표는 7월 성수기 전 운영 배포였습니다. 그런데 쏘카 스테이 출시에 맞춘 대규모 이벤트가 성수기보다 앞서 잡히면서 본부장이 일정을 한 달 당기자고 했습니다. 기간이 절반이 된 것입니다.

필수와 선택으로 나눈 페이즈

시간, 인력, 할 일 가운데 조정할 수 있는 것은 할 일뿐이라고 보고 계획을 필수와 선택으로 갈랐습니다. 필수는 메인 서비스의 인증 코드 분리이고, 나머지 서비스의 분리와 성능 최적화는 하면 좋은 일로 두었습니다.

페이즈 1에서 한 가지 걸림돌이 있었습니다. 쏘카의 표준 마이크로서비스는 gRPC와 비동기 처리를 쓰는데, 팀에게는 높은 벽이었습니다. 이 둘은 성능을 높이는 기술이고 이번 목표는 DB 부하 분산과 아키텍처 개선이므로, 익숙한 HTTP와 동기 방식으로 구성하고 gRPC와 비동기는 나중으로 미뤘습니다. 문제를 작게 나눈 것이 주니어가 다룰 수 있는 수준으로 낮추는 데 도움이 됐다고 합니다.

페이즈 2는 작업량이 가장 많았습니다. API 요청을 분석해 읽기가 쓰기보다 압도적으로 많다는 것을 확인하고, 읽기 분리를 2-1, 쓰기 분리를 2-2로 나눴습니다. 처음 5개 서비스의 50여 개 API가 3개 서비스의 10개 API로 줄었습니다. 서비스 수가 줄어 테스트 환경 구성과 테스트 시간도 줄었습니다. 반복 작업을 하며 숙련되자 쓰기 분리까지 해냈습니다.

캐시와 데이터 정리가 더해진 페이즈 3

master DB 부하 분산을 달성한 뒤, 쏘카 스테이 홍보를 위한 파격적인 대규모 프로모션 소식이 들어왔습니다. 팀은 캐시를 도입하기로 했고, 앞선 페이즈로 인증이 한 서비스에 모여 있어 캐시를 그 서비스에만 적용하면 됐습니다. 그런데 기대만큼 빨라지지 않았습니다. 원인을 찾아보니 캐시를 적용한 테이블에 쏘카가 지나온 10년 치 데이터가 계속 쌓여 있었고, 이를 이관해 쓰는 데이터만 남기는 최적화를 함께 했습니다. 이 내용은 /external/socar/blog/11-auth-token-traffic-development/의 테이블 정리와 캐시 단계에 해당합니다.

망한 데모에서 얻은 것

저자는 정기적인 데모가 각 페이즈의 성공 여부를 판단하는 근거가 됐다고 봅니다. 사내 규약대로 gRPC를 쓴 첫 데모는 미완성 상태에서 진행했다가 오류로 시나리오를 끝내지 못했습니다. 그래도 제3자의 시선으로 메모리 사용 문제나 QA의 사용자 관점 피드백을 받았고, 팀 기술 수준에 맞지 않는 기술이 속도를 막고 있다는 판단으로 HTTP 전환을 결정했습니다. 준비 부담을 줄이려고 별도 자료 없이 코드와 실행 과정을 그대로 보여 줬습니다.

저자가 꼽은 효과는 세 가지입니다.

• 막연한 목표가 구체적인 작은 목표로 바뀌어 두려움이 줄었습니다.
• 완료된 페이즈를 고치지 않고 이후 목표만 조정할 수 있었습니다.
• 페이즈 단위로 배포해 문제가 생기면 이전 페이즈로 되돌리면 됐습니다.