요청은 200 OK로 성공하는데, 서버는 왜 나를 비로그인으로 보는걸까 먼저 결론부터 말하자면, ios에는 쿠키 저장소가 두 개 있고 서로 통하지 않습니다.로그인은 웹뷰에서 일어나니 쿠키는 웹뷰 쪽에만 생기는데 서버로 요청을 보내는 코드는 네이티브 ( URLSession )를 쓰고 있었습니다. 그래서 쿠키가 하나도 안 실렸는데 해결은 웹뷰가 직접 요청을 보내게 하는 것입니다. 무슨 일이 있었나푸시 알림이 특정 회원에게만 안갔습니다. 운영 중인 쇼핑몰 앱 이야기입니다. 이 앱은 웹사티으틀 웹뷰로 감싼 형태예요. 화면은 전부 웹이 그리고, 앱은 껍데기 역할을 합니다. 푸시를 보내려면 기기마다 토큰이 필요합니다. 이 토큰을 서버 테이블에 저장해 두는데, 그 행에는 mem_idx라는 칸이 하나 더 있습니다...

지난 두 글에서는 코드를 자동으로 검사, 전달하는 방법(CI/CD)과, 서비스를 안 끊고 새 버전으로 바꾸는 방법(블루,그린 배포)을 정리했습니다.그런데 이 모든게 돌아가려면 결국 무대가 하나 필요합니다.바로 우리 서비스가 24시간 켜져 있을 서버입니다. 이번 글에서는 그 서버를 처음부터 세팅하는 과정을 정리하겠습니다.집에 굴러다니는 컴퓨터를 홈 서버로 쓰든, 클라우드에서 서버를 하나 빌리든, 결국 그 안은 대부분 리눅스라는 운영체제입니다.그래서 어디서 하든 해야 하는 일은 거의 똑같습니다. 이글은 우분투를 기준으로 합니다. 우리가 만들 구조 먼저 보기 세부 단계에 들어가기 전에, 서버 안이 어떤 모양이 될지 그림으로 보겠습니다.사용자가 우리 사이트에 접속하면, 그 요청은 먼저 서버의 정해진 문(포트)..

지난 글에서는 코드를 올리면 서버까지 자동으로 전달되는 흐름을 만들어봤습니다.그런데 막상 서버에 새 코드가 도착하면, 한 가지 문제가 남습니다. 지금 돌아가고 있는 서비스를 어떻게 새 버전으로 바꾸지 ? 가장 단순한 방법은 이렇습니다.돌아가던 걸 끄고,새 걸 켠다. 문제는 이 사이입니다. 크고 켜는 그 몇 초에서 몇십 초 동안, 우리 사이트에 들어온 사람은 접속이 안되는 화면을 보게 됩니다.방문자가 적을 땐 티가 안나지만, 누군가 딱 그 순간에 들어오면 사이트 죽었네 하고 나가버리는 경우가 생깁니다. 이걸 막는게 무중단 배포입니다.서비스를 한 순간도 끊지 않고 새 버전으로 바꾸는 방법인데, 그 중 가장 이해하기 쉬운 방식이 블루-그린 배포입니다.이번 글에서는 블루-그린에 대해서 정리하겠습니다. 블루 -..

배포를 처음 해보면 보통 이런식으로 합니다.코드를 다 짜고, 서버에 직접 접속해서, 손으로 빌드하고 다시 손으로 서버를 껐다가 켭니다.몇 번은 괜찮은데 이게 반복되면 슬슬 실수가 나옵니다.한 단계를 빠트리거나, 옛날 코드를 올려버리거나 하는 상황이 생깁니다. 그래서 이번 글에서는 코드를 깃허브에 올리기만 하면 빌드부터 서버 배포까지 알아서 돌아가게 만드는 방법을 정리해보려고 합니다.이걸 보통 CI/CD라고 부릅니다. CI/CD CI 지속적 통합 (Continuous Integration) - 코드를 올릴 때마다 이 코드가 제대로 빌드되고 테스트를 통과하는지 자동으로 검사합니다. CD 지속적 배포 (Continuous Deployment)- 검사를 통과한 코드를 자동으로 서버에 올려주는 것입니다. 즉 코..

인증서 기간이 만료돼서 새로 발급받아 교체하는 작업을 진행했습니다.처음 해보는 작업이기도 했고, 자주 있는 작업이 아니라는 말씀에 다음 번엔 헷갈리지 않기 위해 과정을 남겨둡니다.특히 dec_key.pem을 만드는 부분에서 헤맸는데, 같은 실수 하실 분들께 도움이 됐으면 합니다. 상황 정리 서버에는 키와 인증서 관련 파일이 세 개 있었습니다. key.pem : 발급받은 개인키 (passphrase가 걸려 있는 암호화된 키)cert.pem : 인증서dec_key.pem : 암호를 푼 키. Nginx가 실제로 읽는 파일여기서 헷갈리기 쉬운게 dec_key.pem입니다. 이건 제가 내용을 직접 채워 넣는 파일이 아니라,key.pem의 암호를 풀어서 만들어내는 결과물입니다. Nginx는 구동될 때 passphr..

커밋할수록 성장하는 벚꽃나무 개발기 GitHub 프로필 README를 꾸미다가 문득 이런 생각이 들었습니다.배지, 스탯 카드, 뱀이 기여 그래프를 먹는 애니메이션 등등.. 다들 비슷하기도 하고 나만의 무언가가 있으면 좋겠는데. 그러다 gitanimals 를 보면서 이런거 직접 만들어보자, 되지 않을까 싶었습니다. 커밋할수록 벚꽃나무가 자라고, 레벨 시스템을 붙여서, 그렇게 LevelUp Tree 가 시작되었습니다. 아이디어 - 씨앗(Lv.1)에서 시작해서 총 10단계, 만렙은 100입니다. - 커밋 수가 곧 경험치입니다. 매일 코딩하면 나무가 자라야 합니다.- 레벨 91이상이 되면 벚꽃이 흩날리는 애니메이션 - README에 이미지 한 줄로 삽입 가능. (설치, 토큰 필요없이) 마지막 조건이 핵심..

Spring Data JPA의 Page를 그대로 쓰면 안 되는 이유 — 공통 페이징 응답 DTO 설계하기Spring Boot · Java · JPA · API 설계Spring Data JPA를 처음 쓰면 자연스럽게 Controller에서 Page를 그대로 반환하게 됩니다. 동작은 하지만, 프로덕션 API에서는 여러 문제가 생깁니다. 이 글에서는 왜 Page를 직접 반환하면 안 되는지, 그리고 공통 페이징 DTO를 어떻게 설계하면 좋은지 코드와 함께 정리합니다.1. Page를 그대로 반환하면 생기는 문제다음처럼 Controller를 작성했다고 가정해봅시다.// 문제가 있는 방식@GetMappingpublic ResponseEntity> getUsers(Pageable pageable) { return..

Kafka Retry와 DLQ를 도입하게 된 이유 이커머스 프로젝트에서 주문 요청을 사가 오케스트레이터로 구현을 했는데 실패한 메시지를 재시도 하려다가 서비스 자체가 죽어버리는 상황이 발생했다. 서비스 간 호출 실패를 어떻게 다뤄야 할지 고민이 되었다. 무한 재시도를 하지 못하게하고, 실패한 이유를 데이터로 남겨서 운영자나 관리자가 확인하고 통제를 할 수 있지 않을까라는 생각을 해보았다. 이 고민의 결과로 Retry와 DLQ를 함께 도입하게 되었다. Retry란 무엇인가? 메시지 처리가 실패했을 때, 같은 메시지를 다시 처리하도록 Kafka Consumer가 재시도하는 매커니즘이라고 한다. Spring Kafka 기준으로 Retry는 - 동일한 offset의 메시지를 일정 시간 간격을 두고 지정..

Improving Event Reliability in a Saga Orchestrator with the Outbox Pattern 지금 진행 중인 프로젝트는 이커머스 도메인을 기반으로 한 MSA 아키텍처 구조의 프로젝트이다. 주문 생성과 주문 취소와 같은 핵심 비즈니스 흐름은 여러 서비스에 걸쳐 진행되기 때문에 하나의 흐름으로 제어하기 위해 사가 오케스트레이터 패턴을 적용하였다. 사가 오케스트레이터는 각 단계의 성공과 실패를 상태로 관리하고 있고, 다음 단계의 처리를 이벤트 기반으로 트리거하는 역할을 하고 있다 사가 테이블에는 "어디까지 진행되었는지"에 대한 상태 정보가 저장되고, 동시에 Kafka 이벤트를 통해 다음 서비스가 실행되는 구조로 설계되어 있다. 초기 설계에서는 사가 테이블에 상태..