목차 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..
✍️ 문제 상황 로컬 환경에서 통합 테스트할 때 매번 서버를 올리는 일이 매우 번거로웠습니다. 세션과 캐시를 위한 redis 서버를 테스트할 때 마다 매번 올리는건 개발 생산성을 낮춘다고 판단했습니다. 이러한 현상은 제 팀원에게도 나타날 것이기 때문에 지금 개선하지 않으면 팀원 수에 비례하여 개발 생산성이 낮아질 것으로 판단했습니다. 💡 통합 테스트 과정 redis 서버를 실행(수동) → 통합 테스트 실행(수동) → 테스트 완료 → redis 서버 clear(수동) ✍️ 접근 방법과 해결 과정 로컬 환경에서 서버 환경 구축을 자동화할 수 있는 툴이 있는지 조사했습니다. 여러 툴들이 있었지만, 현업에서는 도커를 사용하기 때문에 이를 선택했습니다. 또한 docker가 Ubuntu20.04에서 기본으로 설치돼..
✍️ 문제 상황 통합 테스트 구동 시 회원가입이 돼있지 않은 코드가 로그인에 성공하는 문제가 있었습니다. 로그인 하기 전에 유저 정보가 저장돼있는지 확인하는 절차까지 진행했지만 문제 상황은 여전했습니다. 이에 유저 로그인 로직에 문제가 있다고 파악하여 로그인 로직에 로그를 남겼고 @Transactional 상황에서 @Cacheable이 적용된 데이터가 rollback 되지 않는게 문제의 원인이라고 판단했습니다. @DisplayName("로그인, 실패 시나리오") @Test void login_failed() throws Exception { // given // 가입되지 않은 사용자 // userService.createUser(userDTO); // when // 유스케이스/로그인/Fail path R..
서두 오늘 빡독 시간엔 저번에 이어서 '함께 자라기 애자일로 가는 길'을 읽었습니다. 제가 지속적으로 키우려고 하는 능력과 관련된 얘기가 나와서 아주 재밌게 읽었네요. 실제로 오늘 책에서 읽은 얘기를 멘토링 시간에 활용도 해봤습니다. 무얼 읽었고, 저와 어떤 관련이 있었는지, 앞으로 어떻게 활용할지와 마지막으로 이전 글에서 언급한 타당성과의 연관 관계를 정리 해보겠습니다. 오늘 읽은 part 요약 전문가들의 전문성을 뽑아내고 적용하는 것이 자신의 전문성을 빨리 높일 수 있는 방법이다. 전문성을 효과적으로 뽑아내려면 추상적이고 원론적인 답변을 얻을 수 있는 질문이 아닌, 구체적인 사건에 대해 말하도록 유도 해야 한다. 전문가들이 보통 추상적이고 원론적인 답변을 하는 이유는 사고 과정을 무의식적으로 자동화 ..
서두 오늘 빡독 시간엔 저번에 이어서 '함께 자라기 애자일로 가는 길/김창준 지음'을 읽었습니다. 평소에 가지고 있던 생각을 정리하고 확인하는 경험이 있었습니다. 어떤 내용을 읽고 제 평소 생각과 연결 시켰는지 짧은 글로 남깁니다. 오늘 읽은 part 요약 컴퓨터로 대체되기 어려운 일은 학습하기 힘든 환경 내 학습하기 힘든 주제와 관련됨. 예를 들면, - 목표가 모호하고 주관적일 수 있으며 동적임. - 매 순간 선택할 수 있는 행동/선택 종류가 불확실함. - 매 순간 내가 목표에 얼마나 근접했는지 평가하기 어려움. - 등등 이러한 영역은 소위 직관, 창의적 지능, 사회적 지능과 관련됨. 직관적 전문성을 가지려면 타당성과 피드백이 중요함. 타당성은 직관이 적용되는 영역에도 어느 정도 인과 관계와 규칙성이 ..
