유저를 위한 시스템 개선기

안녕하세요. 여기어때 유저혜택개발팀에서 백앤드 개발을 하고 있는 코플 입니다. 저는 유저혜택개발팀에서 회원 파트의 일원으로 회원의 가입, 휴면, 탈퇴 등 회원 라이프 사이클 프로세스의 전반적인 부분을 관리하고 회원정보를 필요로 하는 서비스와 연동되는 회원 도메인 시스템을 개발하고 있습니다.

회원이 없는 서비스가 없는 만큼 여기어때의 시작과 함께해온 회원 도메인 시스템은 레거시 시스템이라 불릴 만한 부분입니다. 레거시 시스템이란 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어 등을 의미하는 말입니다.

여기어때는 2014년 최초 가입자를 시작으로 2022년 현재까지 8년여 동안 꾸준히 고객이 증가해 왔습니다. 현재는 월간 활성 사용자 400만명 이상이며 누적사용자는 1,700만명 이상으로 증가하였습니다. 증가한 고객만큼 다양한 니즈가 발생하였고 내/외부 요청에 대응하기 위해 저희는 다양한 기능과 많은 정보를 제공해야 했습니다. 그 결과로 회원 도메인 서비스도 상당한 변화를 겪으며 현재까지 운영되고 있습니다.

시스템 기능의 확장은 어떻게 보면 필수 불가결한 것 일지도 모릅니다. 하지만 이미 잘 구성되어 운영되는 시스템에 새로운 기능을 하나하나 추가하는 과정에서는 초기설계 당시에는 고려하지 못했던 변수가 종종 발생하게 됩니다.

회원 도메인을 호출하는 클라이언트와 서버입니다. 위 그림에서 알 수 있듯이 회원 도메인 서비스는 다른 서비스와 연계되며 여기어때 서비스 전반에서 폭넓게 활용되고 있습니다.

그래서 회원 도메인은 항상 안정적으로 작동해야 하고, 그런 서비스를 제공해야 하는 저희 파트 입장에서 레거시 시스템을 변경하거나 신규 개발하는 것은 상당히 부담되는 일입니다. 그럼에도 불구하고 서비스는 항상 개선되어야 하기에 지금도 회원 도메인 개선 프로젝트는 여전히 현재 진행형입니다.

여기어때에서 시스템을 어떻게 개선하고 있는지 한 가지 예를 이야기해 보려고 합니다.

1. 문제인식

올해 개선 작업을 지속적으로 수행 와중에 한 가지 큰 이슈가 발생하게 되었습니다. 바로 네고왕 이벤트 였습니다. 네고왕 이벤트는 진행 기간(2022.02.24~28) 동안 매일 오후 1시에 7,000장의 쿠폰을 선착순으로 지급하는 행사였습니다.

다른 영상 중 편집된 이미지입니다.

이때 네고가 깨졌어야…

파격적인 할인 이벤트였지만 지속적으로 다양한 이벤트에 대응해 왔던 회원 도메인 시스템이었기에 큰 고심 없이 이벤트를 준비하였습니다. 이벤트 관련된 회원정보 캐싱과 인프라 리소스 추가정도 준비만 해도 충분한 이벤트라고 생각 했었습니다.

하지만 네 … 정말 니 생각이었습니다.

예상 트래픽에 5배 이상의 가입 트래픽이 유입 되면서 이로 인한 응답 레이턴시(Latency)가 기준치 초과 발생하면서 회원 도메인 서비스와 연동하고 있는 서비스까지 장애가 전파되고 서비스 전체에 영향을 끼치는 상황에 이르렀습니다. 신규 가입의 트래픽을 유추하지 못한 결과였습니다.

당시 핀포인트 상황 캡처

빨간 구름이 싫어요…

이벤트 중 발생한 장애는 유저 도메인 시스템에 작지 않은 변곡점으로 작용하게 되었습니다.

당연히 잘 될 줄 알았던 회원 도메인 시스템이지만 그렇지 않았다는 것을 인지하게되었습니다. 그리하여 시스템을 개선하는 데 있어서 단순히 기존 기능의 이관(Migration)을 수행하기보다 성능의 개선과 더불어 장애가 전파되지 않도록해야했습니다. 그래서 저희에게는 아키텍처를 새로 설계하고 시스템을 구축해야 하는 과제가 주어지게 되었습니다.

2. 시스템과 정책 분석

여기어때의 시작과 함께 해온 시스템인 만큼 많은 요구사항과 정책의 변경이 있었고 오랜 기간 기능의 추가, 수정, 삭제가 이루어졌습니다. 그러나 변경된 정보를 담은 문서는 파편화 되어 있었고 관련 이력이 누락되었을 가능성도 배제할 수 없었기에 다양한 분석을 진행했습니다.

시스템을 분석하면서 작성했던 비지니스 정책 흐름도, 데이터 연계 UML, 시스템 연관 관계 UML 등 입니다.

도메인 비지니스 정책을 확인 하는 일

다양한 모듈과 연계되어 있었지만 관련된 히스토리가 누락된 경우가 제법 많았습니다. 문서도 찾고 소스와 데이터베이스 등을 확인하는 등 정말 다양한 일을 하였지만 그 중 가장 어려운 부분은 연관 업무를 하시는 분들에게 일일이 확인 하는 과정이었습니다. 프로세스 내에 여러 정책들이 녹여져 있었습니다. 어떤 이유에서 이러한 로직이 있는지 이 프로세스가 현재 정책과 일치 하는 것인지 아닌지 하나하나 파악해 가는 건 여간 어려운 일이 아니었습니다. 히스토리 관련된 문서가 없으면 커뮤니케이션에 소모되는 리소스가 컸습니다.

DB 트랜잭션 을 추적하여 필요한 DB I/O를 추산하고 이를 분리하는 일

회원 정보를 생성하면서 서비스 니즈에 의해서 회원의 정보 변환되거나 분리되어 저장됩니다. 이로 따라서 발생하는 DB I/O 중에 즉시 필요한 정보와 그렇지 않은 정보로 분류하는 작업을 진행했습니다. 이를 통해 클라이언트로 바로 전달해야 하는 데이터와 그렇지 않은 데이터로 분리할 수 있었습니다.

성능 테스트

유저 가입 / 로그인에 대한 다양한 니즈로 인해 기능들이 추가 되었음에도 불구하고 이에 따르는 성능 테스트가 제대로 이루어지지 못했다는 점을 확인하였고 뒤늦게나마 실제 상황과 유사한 조건에서 성능 테스트를 수행했습니다. 실제 소스 레벨에서 발생하는 문제점을 발견하여 해결하고 불필요한 로직을 제거하면서 수 회 테스트를 진행하여 잠재적인 리스크까지 파악했습니다.

이를 통해 다수의 DB I/O 와 다른 도메인 시스템과 연동하는 과정에 동기식으로 작동하여 레이턴시가 발생하면 그대로 연계 서비스에 작용하고 있다는 것을 파악할 수 있었고 현재는 사용하지 않은 정책 이거나 시스템에 불필요한 로직이 시스템 전반에 남아 있다는 사실을 파악할 수 있었습니다.

3. 시스탬 개선

개선의 방향에 대해서 다양한 고심을 하였습니다. 회원 도메인 시스템은 여기어때 서비스 전반의 도메인 모듈에서 활용 중인 특성상 빅뱅 프로젝트 를 진행하게 되면 리스크가 크다고 판단하였습니다. 그래서 Phase를 나누어 점진적으로 프로젝트를 진행하기로 하였습니다.

Phase 1에서는 이슈의 핵심이 되었던 회원 가입과 로그인의 성능을 개선하고 장애 전파를 최소화하는데 주안점을 두었습니다. 단순 비동기 방식으로 빠른 전환, 메세지 기반의 가입 프로세스 전환 등 다양한 의견이 있었지만 이벤트 발행 기반으로 변경하여 느슨한 결합을 이루도록 변경하고 이를 통해 당장 필요하지 않은 타 모듈 연동이나 DB I/O 를 격리 처리하여 성능을 개선하는 쪽으로 방향을 잡았습니다. 이벤트 발행 방식은 카프카의 가용성과 성능을 적극 활용했습니다.

이벤트 발행 방식에 예를 들어 회원 가입을 설명하면

"회원가입 하면 ~이 필요하다"

"회원가입이 되면 신규 회원에게 쿠폰을 발행해야 한다." 
"회원가입이 되면 회원 등급 정보가 생성되어야 한다"
"회원가입이 되면 마케팅 관련 모듈과 연동하여야 한다" 

등의 처리가 필요하게 됩니다. 하지만 위 세 가지 작업은 실제 “회원가입” 본질과는 무관한 작업입니다. 회원 도메인 시스템에서는 회원가입에 의해서 생성된 정보를 이벤트와 함께 카프카 토픽으로 발행합니다.

회원가입 이벤트를 리스닝하고 있는 구독 서버에서 또는 도메인 모듈에서 필요로 하는 동작을 수행하도록 이벤트 발행 방식의 아키택처로 전환하였습니다.

로그인도 마찬가지로 실제 로그인 이외의 기능 중 동기적으로 처리가 필요하지 않는 작업은 이벤트 발행 방식으로 처리 하였습니다. 카프카로 발행이 실패된 케이스는 레디스(Redis)에 적재하여 재발행 되도록 구성하였습니다. 기능별 메세지 방식이 아닌 회원가입과 회원로그인을 이벤트를 발행하면서 타 모듈과 연계할 경우 회원 시스템의 변경을 최소화 하였습니다.

이를 통해서 회원 가입과 로그인이 여타 다른 도메인 모듈에 의존하지 않도록 의존관계를 제거하고 장애가 전파 되지 않도록 서비스를 격리했습니다.

더불어 단순히 기술적으로 개선하기 보단 PO와 협업하여 회원 프로세스 전반의 정책을 확인하고 개선점을 찾는 의미 있는 작업이었습니다.

Phase2에서는 PHP 레거시에 잔존해 있던 API 들을 MSA 환경으로 전환하고 회원 내부 도메인을 각각 분리하여 트래픽 분산하는 프로젝트가 현재 진행중입니다. 도입부에서 말씀드렸던 많은 시스템과의 연계 과정을 좀 더 느슨하게 변경하고 대용량 트래픽 발생 시 대처에 유연성을 확보하기 위한 작업입니다.

저희는 다음 Phase에서는 데이터 정합성 향상을 위한 추가적인 작업과 대용량 트래픽 발생 시 유연하게 대응하기 위한 작업들을 순차적으로 계획하고 있습니다. 이러한 서비스에 관심이 있으시다면 여기어때의 젊은이에 지원 부탁 드립니다.

끝으로, 늘어나는 트래픽 대응하는 것은 어떻게보면 개발자에게는 영원한 과제일지 모릅니다. 서비스 개발자 입장에서 서비스 내에 산재한 문제를 발견하고 이것을 파악하고 해결하기 위한 과정에 대해서 한번 이야기 해보고자 하는 마음에 글을 작성하게 되었습니다.

이벤트를 발행하여 트래픽을 처리하는 방식은 다양한 문제 해법 중 하나에 불과 합니다. 다만 문제 인식 → 시스템과 정책분석 → 시스템개선 → 피드백의 과정은 어떠한 시스템 문제에도 적용 가능하다고 생각합니다. 협업을 통한 커뮤니케이션이라는 요소가 이 과정에서 큰 힘을 발휘하게 됩니다. 그리고 체계적으로 시스템에 관해 문서화하는 것은 중요한 일 입니다. 이를 통해서 점차 서비스 품질을 향상을 기대해볼 수 있을 것이라 생각하고 있습니다.

품질이란 누가 보지 않을 때에도 제대로 돌아가는 걸 뜻한다 — 헨리포드

더 나은 품질의 서비스를 유저에게 제공하기 위해서 꾸준히 노력하겠습니다. 감사합니다.