배경
e-commerce 도메인에 기존 PHP 레거시 코드를 kotlin으로 변환하는 작업
변환 작업을 최우선으로 생각해서 각각 다른 팀에 팀원이 모여서 작업을 한다.
목표
팀의 목표는 결제를 제외한 모든 페이지 전환이다. 그 중에 제일 먼저 배포되는 인증 첫 번째 작업을 성공적으로 배포하는 것을 목표로 합니다.
작업 자체가 모든 페이지를 PHP->Kotlin 으로 한번에 변환하는 것이 아닌, 부분 부분 변환을 하는 작업이다. 그 중에 제일 선행되어야 하는 작업은 인증이다. 모든 페이지에서 필요한 작업이기 때문이다.
스펙
FE: next, typescript, react, graphql, rest api
BE: kotlin, spring boot, graphql, rest api
과제
- 기존에 사용자들은 어떠한 영향도 없어야 한다.
1.1 기존에 로그인한 사용자 유지 - 0부터 시작하는 백엔드 개발
2.1 모니터링 시스템
2.2 git 전략 - 개발
- 배포
- 트러블 슈팅
5.1 NAVER 인증시 일부 유저의 약관동의 정보 가져오기 404 오류
5.2 JWT 브라우저 쿠키 만료시간 설정 오류
기존에 사용자들은 어떠한 영향도 없어야 한다.
달리는 차 바퀴를 교체 하기
이미 운영되는 도메인이기 때문에 어떠한 영향도 없어야 한다.
기존 사용자는 어떠한 변경점을 느끼지 못 해야한다.
kotlin에는 PHP 에 대한 어떠한 종속성도 가지면 안된다.
모든 페이지가 kotlin으로 전환시에 또 다른 추가작업이 필요하고 그에 따라 더 많은 리소스가 낭비되기 때문이다. 또한, 굳이 레거시 시스템을 신규 작업에 넣어야할 필요성이 없다.
기존에 로그인한 사용자 유지
문제
사용자의 첫 진입점은 PHP , next(kotlin) 두 곳중에 1곳이다.
사용자가 PHP 페이지에 첫 진입 후 next(kotlin)에 접근하면 로그인이 유지되지 않는다.
PHP의 경우 CI_SESSION 이라는 키로 세션 아이디를 쿠키에 저장하고 있다.
kotlin 의 경우 JWT 토큰을 쿠키에 저장하고 있다.
매번 PHP 진입 할때도 JWT 토큰을 쿠키에 저장하면 되지 않는가?
그렇다면 문제가 발생한다. kotlin 으로 변환된 페이지에서 로그아웃을 하더라도, PHP에 로그인이 유지되면서 JWT 토큰을 쿠키에 저장하는 문제가 생긴다.
해결
- 전환 작업 운영 배포전 3개월간 PHP에 USER ID 기준으로 JWT 토큰을 생성하는 작업을 먼저 배포한다.
- PHP에도 JWT가 없으면 로그아웃 시킨다.
- PHP JWT가 있고 CI_SESSION(PHP 인증 정보)가 없는 경우 CI_SESSION(PHP 인증 정보)를 새로 생성한다.
- 전환 작업 운영 배포시에 2, 3번 작업도 PHP도 같이 배포한다.
모든 인증 기준은 JWT 로 통일한다.
| JWT 쿠키 | CI_SESSION(PHP 인증 정보) | 로그인 여부 |
|---|---|---|
| O | X | O |
| O | O | O |
| X | O | X |
| X | X | X |
0부터 시작하는 백엔드 개발
모니터링 시스템
git 전략
해당 프로젝트 자체가 각각 다른 팀에 있는 인원이 같이 진행하기 때문에 각각 사용하고 있는 git 전략 및 배포 전략이 달라 통일이 필요했습니다.
Git-Flow
Git-Flow 전략을 사용하는 방식 채택
1. 러닝커브가 높지않다.
2. 기존 도메인에서도 사용하는 사람이 다수라 해당 전략 사용
모니터링 시스템
익셉션 처리
목적
- 프론트엔드에서 익셉션 별로 처리하기 쉽도록
- 모니터링시 명확하게 확인 가능하도록
도메인 별로 익셉션 처리
- 각각 도메인 별로 익셉션을 처리 할 수 있도록
open class BusinessException : RuntimeException클래스 추가 - 각각 도메인 별로 위에
BusinessException을 상속 받아 익셉션 코드, 메시지를 만들 수 있도록 한다.
프론트에서 익셉션 정보를 확인 가능하도록 처리
- https://netflix.github.io/dgs/error-handling/#the-typederror-interface
- 익셉션 별로 각각 메시지와 코드를 맵핑해서 프론트엔드에서 확인가능
- BusinessException, AccessDeniedException 와 같이 정의된 익셉션 처리 및 정의 되지 않은 RuntimeException 익셉션을 가공하여 response 생성
DataDog 사용
datadog monitor 에 error 에 대한 모니터링을 추가해서 slack 으로 알림 오도록 추가
https://docs.datadoghq.com/ko/monitors/
개발
- 로그인 및 회원가입 구조 설계
- Delegate를 사용해 각 역할(Role)에 특화된 검증 로직을 위임하여 재사용성을 높이고 유지보수성을 개선.
- 로그인 공통 기능 Façade 및 OAuth Service 공통 인터페이스로 구현하도록 설계
배포
각각 종속성이 강하기 때문에 배포전에 순서를 정하고 배포한다.
배포는 아래 순서로 배포한다.
1. kotlin -> 배포 후 postman 혹은 기타 다른 툴로 api 동작 운영에서 확인
2. PHP -> 배포 후 기존 로그인 사용자 유지 확인
3. next -> 프론트 배포 후 모니터링 시작
조금 더 시간이 있었더라면 카나리 배포 처럼 운영 환경에서 리스크를 줄이는 방법을 적용했었어야 했다.
트러블 슈팅
NAVER 인증시 일부 유저의 약관동의 정보 가져오기 404 오류
확인
- 배포 직후 로그에 naver 인증시에 404 오류 발생 확인
- 내부직원중에 일부가 로그인 안된다는 내용 전파
원인
외부 API 라서 원인 확인이 어려웠으나, 동일한 케이스가 다른 곳에서도 발생했다는 것을 확인 naver api 에 문제가 있어 정확한 원인 확인이 어려웠습니다.
https://developers.naver.com/forum/posts/34228
https://developers.naver.com/forum/posts/34684
해결
naver 인증시에 마켓팅 동의 선택 항목의 정보를 가져와야하기문에 해당 플로우를 생략할 수 없었습니다.
하지만, OAuth를 활용한 로그인이 아닌 ID/PW의 경우 따로 마켓팅 동의를 받고 있는 로직이 있어 해당 부분을 약관동의 정보를 가져올때 404 오류 발생시 따로 동의를 받을 수 있도록 플로우 추가 후 핫픽스 배포
JWT 브라우저 쿠키 만료시간 설정 오류
확인
로그인이 안된다는 내용의 슬랙을 전파 받고 확인
BE, FE 각각 로그 확인
BE 확인 내용에서는 로그인에 JWT가 제대로 반환된부분 확인
원인
FE 에서 JWT 쿠키 생성시 만료시간을 설정할때 빌드 시점기준으로 시간을 더해 주는 방식으로 되어 이미 만료된 쿠키를 생성하여 쿠키가 제대로 생성되지 않아 오류 발생
해결
1차 배포 - FE 에서 JWT 쿠키 만료시간 하드코딩 후 핫픽스 배포
2차 배포 - JWT 쿠키 생성시점에 만료시간 생성하도록 로직 수정 후 배포
