Go Gradually - Repository

실제로 k3s를 이용해 배포한 뒤, 발생한 예외를 바로바로 확인하기 어려운 문제가 있었다. 따라서, 디스코드 웹훅을 이용해 예외를 메시지로 받아보려 한다.목차에러 로그를 디스코드 메시지로 전달할 Appender에 대해 알아보기DiscordWebhookAppender 구현하기logback-spring.xml 정의하기AppenderLogback에서 Appender는 “로그 이벤트(ILoggingEvent)를 받아서, 특정 출력 대상(sink)으로 내보내는 출력 어댑터”이다. 간단하게 Appender가 동작하기까지의 동작 과정을 살펴보면 다음과 같다.SLF4J API: log.info(...), log.error(...) 호출Logback Logger: 로그 이벤트(ILoggingEvent) 생성(선택) Fi..

API 게이트웨이는 프론트와 백엔드 간의 연결 전에, 백엔드 서버를 Production에 올려 테스트할 때 필요하기에 만들게 되었다.1. 인증 로직 번거로움 관점백엔드 기능의 서브 도메인 단위 통합테스트를 하고 싶었는데, 현재 서브 도메인 내에서 자체적으로 인증 기능을 수행해고 있었다.그래서 curl로 간단하게 테스트하기가 어려운 문제가 존재하고 있었다.인증 기능과 같은 공통 로직 관점 기능이 마이크로서비스에 침투해 있으면, 우리가 구현한 기능만 간단하게 테스트하기가 까다로워지는 문제가 발생한다.2. 프론트가 API 버전을 몰랐으면 좋겠다.프론트가 버전을 몰라도, request Body 기반으로 라우팅을 수행할 수 있으면 좋겠다.그런데, request body 파싱->객체 변환->API 재호출은 게이트웨..

목차인프라 세팅ARC 설치ARC가 사용할 ServiceAccount 정의pinit 네임스페이스에서 role 생성 & sa와 바인딩워크플로우 작성테스트/빌드도커파일 작성도커 이미지 업로드러너가 해당 서비스 어카운트를 이용해 kubeconfig 생성kubectl을 이용해 해당 deployment 실행deployment 정의파드에 secret 환경 변수 세팅하기도커 이미지를 받아오고 해당 이미지를 배포Health Probe 시스템 구축서비스/인그레스 설정들어오는 서비스 설정인그레스/게이트웨이가 해당 서비스를 가리키도록 설정이 글은 쿠버네티스 클러스터 내에 Github Self-Hosted runner를 두고, 해당 러너에서 워크플로우를 트리거해 CI/CD를 진행하는 과정을 담은 가이드입니다.진행하며 이해가 안..

문제 상황현재 auth 서비스와 task 서비스는 이벤트를 통해 상호작용을 조율하고 있다. 그런데, 사용자가 회원가입 후 로그인을 한 뒤 task서비스를 이용하려는데, task에 회원 정보가 존재하지 않다면 어떻게 될까? 로그인 성공 - task에 이벤트가 도착한 후task 서버에서 사용자 정보를 정상 처리정상 플로우로그인 성공 - task에 이벤트가 도착하기 전task 서버에서 auth 서버에서 처리한 사용자 정보를 아직 못받음일정을 생성할 수 없음(예외 발생)사용자의 지역 정보를 받아와야 하는데, member record 자체가 없음별명도 존재하지 않음 문제를 깔끔하게 정리해보자.현재 이 문제는 task, auth 서버 간의 문제다.사용자 경험(UX) 기준에서, 별명 정보는 필수가 아니다.진짜 문제는..

현재 시스템 구조현재 요구사항에는 일정 시작 시간에 푸쉬 알림을 보내야 한다는 요구사항이 있다. 하지만, 이미 일정을 진행중인/종료한 사람에게 해당 푸쉬알림이 발송될 경우, 이는 UX 측면에서 사용자의 집중력을 해칠 우려가 있기 때문에, 일정이 시작된 후에는 푸쉬 알림이 발송되지 않아야 한다. 내부 상태 변화(Schedule의 "시작됨" 상태 변화와 "취소됨" 상태 변화)를 외부 시스템이 알아야 하는 경우가 발생했다. 이렇다면, 일정 시작 시간에 발송되는 푸쉬 알림은 일정이 "시작되지 않음" 상태일 때에만 발송되어야 한다.즉, 일정의 "시작되지 않음" 관련 상태/상태 변화가 외부 시스템에 전달되어야 한다. 이에 대해 나는 다음과 같은 해결책을 고려했다.도메인 이벤트로 해결하기상태 변화 알리기 - 일정 시..

FCM 토큰으로 푸시알림을 발행하려고 하자, FCM 토큰이 UNREGISTERED되어 있다는 응답을 받았다.공식 문서를 참고한 결과, FCM 토큰이 만료되었다는 의미라는 것을 알게 되었다. 토큰이 예상하지 못한 방식으로 만료될 수 있다는 것을 알게된 나는 토큰의 만료 관리 정책을 고려해야 한다는 걸 알 수 있었다.하지만, 일단 지금의 목표는 알림 발송이니, 알림 안오는 버그부터 해결하자.그렇게 만료된 토큰을 삭제하고 다시 시도해본 결과, 에러 메시지가 달라졌다.이번에는 Invalid Argument 문제를 마주했다. GPT에게 자주 발생하는 Invalid Argument 에러에 대해 물어보니 다음과 같이 답변해주었다.진짜 FCM 등록 토큰을 넣었나? 엉뚱한거 잘못 넣은 거 아닌가?토큰 문자열이 손상된 ..

백엔드 서버 관점에서 일반적인 이벤트 발행의 Best Practice를 생각해보자.새로운 방법의 발견이 아닌, 일반적인 방법을 정리 후 적용하는 게시글이다. 트랜잭셔널 아웃박스 패턴 (Transactional Outbox Pattern)프로듀서 -> MQ 사이의 1회 이상 전송을 보장하는 매커니즘(패턴)이다.DB의 트랜잭션은 사용자의 요청과 DB 상태 변경을 원자적으로 묶어준다. 하지만, DB 상태 변경과 이벤트 기록, 그리고 이벤트 발행까지는 원자적으로 묶이지 않는다.트랜잭셔널 아웃박스 패턴은 DB 상태 변경과 이벤트 기록을 트랜잭션으로 묶는다.하지만, 트랜잭션 아웃박스 패턴은 1회 이상 발행 보장이지, 1회 발행 보장은 아니다.즉, 중복 발행 가능성이 있다.발행 후 해당 메시지를 발행함을 표기하지 못..

웹 푸쉬 알림은 표준 Web Push 프로토콜을 따르며, VAPID 인증 방식을 사용하여 브라우저에 푸쉬 알림을 전송한다.이때 VAPID(Voluntary Application Server Identification)는 애플리케이션 서버가 푸쉬 서비스에 자신을 식별할 수 있도록 도와주는 메커니즘이다.VAPID는 그 자체로 푸쉬 서버에게 자신을 알리는 ID가 됨과 동시에, VAPID는 공개 키 암호화 방식을 사용하여 서버가 푸쉬 요청을 보낼 때 자신을 증명할 수 있게 한다.Web Push 구현 목표브라우저에서Notification 권한 요청pushManager.subscribe() 로 endpoint, keys.p256dh, keys.auth 획득서버에서VAPID 키 쌍 생성 및 관리payload 암호화,..

추천 이전 글: Rabbit MQ의 이름 짓기 [RabbitMQ] Rabbit MQ의 이름 짓기개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다dev.go-gradually.me Rabbit MQ를 이용한 이벤트 송/수신 방식을 설계하려면, 이 또한 계약을 설계해야 한다.프로토콜, API, 메시지 포맷 등을 설계하는 것은 성능 최적화 이상 중요한 백엔드 개발자의 매우 중요한 역할 중 하나이다.MSA 에서 이벤트 기반 메시징을 설계할 때, 다음과 같은 사항들을 고려해야 한다.프로듀서 주체Exchange nameRouting key컨슈머 주체Queue nam..

이번 글은 이전 글의 다음 단계인 2, 3단계에 대해 다룹니다.코드는 다음 링크를 통해 확인 가능합니다. GitHub - GoGradually/pinit-authContribute to GoGradually/pinit-auth development by creating an account on GitHub.github.com 첫 MSA 도입, 한번에 다 만들려고 하면 복잡하다.각각 독립적인 기술인 만큼, JWT + OIDC 조합 두 단계로 나눠서 접근하자.목차내 JWT 인증 흐름 먼저 만들기그다음 OIDC 로그인 붙여서 “로그인 수단”만 확장하기회원가입 이벤트 발행 + be 서버에 공개 키 공유해서 인증 연동하기2. OIDC (외부 로그인) 붙이기(0) OIDC의 이해User-Browser사용자가 브라우..