목차 1. 문제 상황 2. 요구 사항 분석 3. 스케줄링 전략 선정 테스트 환경 스케줄러 전략 간단 요약 스케줄러 전략별 장단점 스케줄러 전략 상세 설명 및 테스트 결과 스케줄러 전략 3번 선택 4. 개선 필요 사항 ✍️ 사전 지식 용어 당행 : 사용자로부터 이체 요청을 받고, 이체 입금을 진행하는 은행 타행 : 이체 과정에서 출금을 진행하는 은행 당행 이체 : 입금 은행과 출금 은행이 동일한 이체 타행 이체 : 입금 은행과 출금 은행이 다른 이체 OutBox 데이터 : 이벤트나 메시지를 DB에 있는 아웃박스에 저장해서 DB 트랜잭션의 일부로 발행하는 패턴을 Transactinal OutBOx라고 합니다. 서로 다른 서버의 트랜잭션을 관리하고 할 때, eventual consistency를 보장하기 위해..
목차 1. 개요 2. 서버가 다운되면 무슨 일이 일어날까? 기존 타행 이체 순차 다이어그램 서버 다운 가능 지점 3. Transactional Outbox Pattern 이벤트 발행 패턴 선정 아웃박스 패턴을 적용한 순차 다이어그램 서버 다운 check, 아웃박스 패턴을 적용한 순차 다이어그램 이체 입금 요청 API의 멱등성 4. 구현 ✍️ 개요 이체 기능을 설계하면 가장 신경 쓴 것은 데이터 정합성이였습니다. 키워드의 검색 횟수 같은 데이터는 정합성이 완전하게 맞춰질 필요가 없을 수 있습니다. 하지만 돈과 같은 경우는 1원이 없어지더라도 이는 결국 회사 혹은 고객의 돈이 없어지는 것 이기 때문에 큰 문제로 이어질 수 있습니다. 그렇다면 돈은 언제 없어질까요? 돈은 이체 하는 과정에서 해피케이스가 아닌 ..
목차 1. 프로젝트 소개 2. 프로젝트 개선 그래프 3. 트래픽의 개략적인 측정 4. 서버 인프라 구성 5. 문서화 ✍️ 프로젝트 소개 카카오 뱅크, 토스 뱅크, 케이 뱅크 등 은행 도메인의 돈통을 구현하는 프로젝트 입니다. 은행에서는 이자 적립, 예약 이체 등 여러 기능들이 있지만, 현 프로젝트에선 대용량의 트래픽이 발생하는 상황에서 '이체' 기능을 잘 수행할 수 있는 백엔드 개발을 중시했습니다. 데이터 정합성, 속도와 사용자 경험을 생각하며 이체 기능을 설계하고 구현했습니다. 서버에 장애가 일어나는 상황을 생각하며 데이터 정합성을 고려했고, 속도 관련 이슈를 해결하기 위해 nGrinder와 APM을 이용하여 객관적인 근거를 찾았습니다. 해결 방법을 찾을 때는 사용자 경험을 고려하며 기획과 Engine..
안녕하세요🙌! 개발자 갈레입니다! 이번 글에서는 야크의 털은 어디까지 깎아야할까(문제를 해결하기 위해 어느정도 깊이까지 공부해봐야할까)에 대한 저의 경험과 결론을 공유하려 합니다. 야크 털 깎기란 '목표한 일 하나를 하기 위해 연관된 작업들을 하다가 결국 원래의 목적을 잃고 완전히 관련 없는 작업을 하게 되는 것'입니다. 아래는 하나의 예시입니다! 나무를 베기 위해 도끼를 구했다. 도끼날이 너무 무뎌 날을 갈기 위한 돌을 구하려 한다. 그런데 어떤 마을에 정말 좋은 돌이 있다는 이야기를 듣는다. 그 마을에 가기 위해 야크를 구한다. 야크 털이 너무 길어서 털을 깎기 시작한다. 결론 결론부터 말하겠습니다! 저는 문제를 본래의 목적과 상관 없이 너무 깊이 파고드는 느낌이 들 땐 아래 질문 세가지를 던집니다!..
안녕하세요🙌! 개발자 갈레입니다! 이번 글에서는 스프링 프로젝트에서 AWS SecretsManager를 이용하여 보안 프로퍼티를 주입하게 된 과정과 결과에 대해 알아볼겁니다! 들어가며 글을 읽으면서 여러분들이 스스로의 프로젝트에 맞는 적절한 도구를 선택하고 pros and cons를 생각하며 적용까지 할 수 있는 시야 혹은 사고 과정 틀을 얻을 수 있으면 합니다. 이를 얻으면 여러분의 프로젝트가 제것과 다를지 몰라도, 논리적인 사고 과정은 큰 틀을 벗어나지 않기 때문에 분명 도움이 될거라 생각합니다. 그럼 시작해볼까요! 궁금증(호기심)을 가지면 좋은 컨텐츠 보안 프로퍼티를 왜 신경써야할까? 보안 프로퍼티 관리 도구는 어떤 특징을 가져야할까? 현재 프로젝트에 적용하기 좋은 방식은? 글을 읽으시면서 핵심 부..
💪동기 현재는 redis와 mysql만 도커 이미지로 사용하고 spring 프로젝트는 도커 이미지로 사용하고 있지 않았음. 배포를 따로 하지 않았기 때문에 문제가 되지 않았음. 하지만 배포를 하게 되면 spring 프로젝트도 도커 이미지로 빌드 되기 때문에 이를 저장할 저장소가 필요했음. 🏃♂️목표 도커 이미지를 저장할 저장소 찾기 🗒️데이터 특성 파악 도커 이미지가 어떻게 저장돼있는지 알아야 이를 저장할 공간을 선정할 수 있음. docs.microsoft에 따르면 도커 이미지는 연속된 레이어로 구성된 파일 묶음임.[1] 해당 레이어는 윈도우 기준 C:\\ProgramData\\docker에 저장돼 있지만, “image”와 “windowfilter” 디렉토리에 나눠져 있음.[2] 도커 이미지를 다룰 때..
안녕하세요! 저는 개발자 갈레입니다! 오늘은 Session storage에 쓰일 DB 선정 과정에 대해 알아볼겁니다. 여러분들이 이 글을 읽고 비슷한 문제를 겪었을 시, '이러한 방식의 해결 과정도 있다~' 정도만 알면 아주 좋을 듯 합니다:) 그럼 시작해보죠! 🏃♂️목표 Refresh token을 저장할 DB 선정 🗒️데이터 특성 파악 1) 저장 값 분석 Refresh token은 Access token과 같이 문자열로 저장됨. 또한 클라이언트 마다 단 하나의 Refresh token만 존재하도록 해야함. key-value(String) 방식을 사용하면 이를 쉽게 구현할 수 있음. 2) 저장 장소 특성 Refresh token은 세션 정보임. 클라이언트가 로그인 중에만 유지될 정보이기 때문에 영속성을..
✍️ 문제 상황 테스트 작성 시, 단위 테스트를 모두 작성하고 통합 테스트는 모듈간의 연결 유무를 확인할 수 있는 최소한의 개수의 테스트만 작성했습니다. 하지만 통합 테스트의 정의와 필요성에 대해 재고하면 좋을 것 같다는 피드백이 있었습니다(Github PR review link) 고생많으셨어요! 통합테스트를 주로 어떻게 작성하는지에 대해서는 한 번 찾아보시면 좋겠습니다. 기본적으로 통합테스트는 단순히 서비스간 혹은 디비간의 통신이 잘 되는지만 확인하는게 아니라 모든 환경이 갖추어진 상태에서 API들이 원하는대로 동작하느냐를 테스트하기위함이고, 따라서 가급적 유저 입장에서 실행 가능한 많은 시나리오들을 통합테스트케이스에서 처리할 수 있도록 하는게 좋습니다. CI/CD를 설정하고 통합테스트에서 유저들의 u..
