에브리톡

마주한 문제

신규 회원의 알림이 오지 않았습니다. 푸시를 보내는 함수만 볼 문제가 아니라, 알림을 받을 기기의 토큰 등록부터 실패하는 상황이었습니다. 이미 배포된 앱을 고치려면 스토어 심사와 사용자 업데이트를 기다려야 했습니다.

확인한 과정

처음에는 앱 버전별 필드명 차이를 의심했지만 후속 검토에서 진단을 정정했습니다. 앱의 snake_case 요청을 서버 전역 interceptor가 camelCase로 바꾼 뒤, DTO 검증이 그 값을 거절하고 있었습니다. DTO 단위 테스트나 컨트롤러 직접 호출은 이 앞단을 지나지 않아 결함을 놓쳤습니다.

선택한 방법

정상 설치본의 요청을 서버에서 받을 수 있게 고쳤습니다. 전역 검증을 느슨하게 만드는 대신 등록 라우트의 검증 앞에서 선택 기기 정보를 정리했습니다. 너무 긴 기기 식별자는 잘라 저장하면 다른 기기와 겹칠 수 있어 버리고, 진단용 앱 버전만 길이를 제한했습니다. 사용자 ID는 요청 body가 아닌 인증 정보에서 가져오도록 유지했습니다.

어떻게 확인했는가

실제 interceptor·ValidationPipe·DTO를 연결한 HTTP 테스트와, 컨트롤러가 정규화한 값을 저장 서비스에 넘기는 테스트를 분리했습니다. 결함을 되돌렸을 때 정상 앱 요청이 다시 실패하는지도 확인했습니다. 당시 복구 기록에서는 토큰 등록·기기 정보 저장과 사용자 수신 확인을 각각 남겼습니다.

단계별 처리와 경계

1. 앱의 등록 요청

   필수 토큰과 선택 기기 정보가 서버에 도착합니다.

2. 전역 필드명 변환

   snake_case가 camelCase로 바뀐 뒤 다음 단계로 갑니다.

3. 입력 정리·검증

   이 라우트의 부가값을 정리하고 기존 필수값 검증을 통과시킵니다.

4. 소유자와 함께 저장

   인증한 사용자와 정규화된 메타데이터를 등록 서비스에 전달합니다.

5. 후행 미러 동기화

   DB 커밋과 커넥션 반환 뒤 미러를 동기화합니다. 실제 푸시 전달은 별도입니다.

마주한 문제

관리자가 권한이나 앱 버전 정책을 바꿔도 다른 서버의 로컬 캐시는 이전 값을 가지고 있었습니다. 그렇다고 로컬 캐시를 모두 없애면 Redis 장애 때 인증 요청이 DB 조회로 몰릴 수 있었습니다.

확인한 과정

권한 조회와 앱 버전 설정은 같은 무효화 버스를 쓰지만 값의 원본과 캐시 방식이 달랐습니다. 공유 캐시를 로컬로 가져오며 만료 시간을 다시 시작하는 문제와, 무효화 전에 시작한 설정 조회가 늦게 끝나 옛 값을 다시 저장하는 문제를 따로 재현했습니다.

선택한 방법

권한 캐시는 로컬 L1과 Redis L2를 함께 두고 절대 만료 시각을 전달했습니다. L1으로 가져올 때도 L2의 남은 수명만 사용합니다. 별도로 앱 버전 설정에는 읽기 시작 시점의 세대를 기록해, 조회 중 무효화가 일어났으면 그 결과를 다시 캐시하지 않도록 했습니다. 구독 연결도 명령용 연결과 분리했습니다.

어떻게 확인했는가

만료가 뒤로 늘어나는 조건과 조회·무효화의 완료 순서를 뒤집는 조건을 회귀 테스트에 넣었습니다. 실제 Redis에서는 노드 간 메시지 수신과 일반 명령의 병행을 확인했고, 배포 후에는 구독 상태를 관측했습니다. 설계 의도와 실제 트래픽에서의 캐시 적중은 다른 확인 항목으로 남겼습니다.

단계별 처리와 경계

1. 권한 조회 · L1

   유효한 로컬 값이 있으면 반환하고, 없을 때만 다음 저장소를 조회합니다.

2. 공유 값 · L2

   Redis 값이 유효하면 원래 만료를 넘기지 않는 수명으로 L1에 올립니다.

3. 캐시 없음 · DB

   공유 값도 없거나 읽기에 실패하면 사용자·권한을 DB에서 조회합니다.

4. 결과 반환·보관

   DB 결과를 L1에 두고, 공유 캐시 사용 조건이 맞을 때만 L2에도 씁니다.

마주한 문제

기존 컨테이너를 내리고 새 컨테이너를 올리는 배포 방식에서는 그 사이 요청을 받을 프로세스가 없었습니다. 앱을 쓰고 있는 사용자가 매 배포의 영향을 받는 문제였습니다.

확인한 과정

같은 호스트의 두 슬롯을 번갈아 쓰는 방식부터 적용했습니다. 계획에 있던 헬스 경로가 실제로 없거나 nginx 설정이 중복으로 포함되는 문제를 확인해 수정했습니다. 전환 직후 200 응답만 보면 여전히 살아 있는 구 슬롯의 응답을 새 버전의 성공으로 오인할 수 있다는 점도 검증 기준에 반영했습니다.

선택한 방법

유휴 슬롯을 먼저 띄우고 nginx 설정 검사 후 upstream을 바꾸도록 배포를 구성했습니다. 전환 직후뿐 아니라 구 슬롯을 드레인·정지한 뒤에도 응답을 다시 확인합니다. 실패 단계에 맞춰 upstream·유휴 슬롯·이미지 태그를 복구하고, 구 슬롯 정지가 실패하면 정상 완료 대신 수동 확인 상태를 남깁니다.

어떻게 확인했는가

정방향과 역방향 스왑, 없는 이미지와 부팅 실패를 나누어 시험했습니다. 내부·외부 프로브로 당시 관측창의 응답을 기록하고 실패 시 기존 슬롯 유지와 정리를 확인했습니다. 이후 DB·캐시와 분산 상태를 먼저 정리한 뒤 ALB·ASG 운영으로 전환했으며, 그 단계는 별도로 노드 상태·의존 서비스·배포 이미지 일치를 확인했습니다.

단계별 처리와 경계

1. 유휴 슬롯 기동

   기존 슬롯이 요청을 받는 동안 다음 버전을 준비합니다.

2. 설정 확인·스왑

   upstream을 바꾸고 nginx 설정 검사 후 reload합니다.

3. 전환 직후 확인

   프록시를 거친 응답을 확인하되 이것만으로 전환 완료를 선언하지 않습니다.

4. 이전 슬롯 드레인

   진행 중 요청을 기다린 뒤 정지 결과까지 확인합니다.

5. 새 슬롯 단독 검증

   이전 슬롯 없이도 응답하는지 확인하고 실패 시 복구 경로로 들어갑니다.