개발놀이터

0. Introduce 블루 그린 배포까지 성공적으로 완료했고 Jenkins라는 CI 자동화 툴로 자동화까지 성공했습니다만 실전에서는 어떻게 배포를 하는지에 대해서 궁금해졌습니다. 때문에 Graceful Shutdown을 도입하게 되었습니다. 1. 기존 배포 블루 그린 배포에서 이전 버전이 내려가고 새로운 버전이 올라간다. 2. 기존 배포의 문제점 블루 => 그린으로 배포하는 과정에서 이전 버전을 갑자기 닫아버리면 이전 버전을 이용하고 있던 사용자의 시스템이 멈춰버립니다. 이 때 결제를 진행하고 있다거나 데이터베이스를 이용하는 로직 도중 서버가 내려가버리면 트랜잭션이 에러에의해 롤백되는 것이 아니기 때문에 도중에 로직이 멈춰버릴 가능성이 있습니다. 이는 부정적인 사용자 경험으로 이어질 뿐더러 롤백을 제대..

프로젝트를 구현할 때 어떤 기술을 어떻게 구현했는지도 물론 중요하겠지만 왜 그 기술을 선택했는지에 대한 고찰이 조금 부족했다는 생각이 들었습니다. 물론 사전에 조사는 다 했지만 직접 써보고 단점을 겪어본 것이 아니기 때문에 추상적일 뿐이었습니다. 이번 기회에 정확히 어떤 기술이 어떤 장점과 단점이 있고 내 프로젝트에 어떤 이유때문에 이 기술을 선택하게 되었는지에 대한 정리를 해봤습니다. 기술 선택 이유 제 프로젝트에는 다음과 같은 기술이 선택되었습니다. 캐싱에 Redis 검색엔진에 Elasticsearch 인증에 JWT 동시성 문제 해결에 비관적 락 배포에 docker 자동화에 jenkins 1. 캐싱에 Redis 스프링에서 캐싱을 사용하기 위해서 다양한 방법이 존재합니다. Redis Memcached ..

기왕 시작한거 끝을 보자는 느낌으로 배포까지 진행하자고 생각했습니다. 또한, 단순히 배포하는 것이 아니라 실제 프로덕트에서 사용중인 무중단 배포를 진행해보고 싶었습니다. 무중단 배포에는 크게 세가지 방법이 있었는데 그 중 블루 그린 배포가 매력적이라고 느껴져 무중단 배포에 블루그린 배포를 진행하였습니다. 1. 기존 프로젝트의 배포 Cafe 24의 웹 호스팅을 이용해 배포 WAR 파일을 이용해 배포 2. 기존 프로젝트에서 배포의 문제점 단일 서버이기 때문에 DB 서버만 키운다던가 하는 유연한 대처가 불가능 가장 큰 문제점은 배포를 하고 나서 정상적으로 배포가 안되는 경우가 많았음 항상 서버를 몇번씩 재시작을 해줘야 정상적으로 서버가 작동되었는데 이 시간이 대략 5분정도 걸렸음 3. ver.2에서 개선한 점..

1. 기존 검색 방식 LIKE 연산자를 이용한 검색을 했습니다. 2. 기존 검색의 문제점 인덱스 설정을 할 수 없습니다. 인덱스를 설정하면 시간 복잡도가 O(log n)이지만 인덱스를 설정하지 못하기 때문에 시간 복잡도가 O(n)에 바인딩 즉, 풀스캔으로 조회합니다. 3. ver.2에서 개선한 점 Elasticsearch의 역색인을 이용해 검색 성능을 20배 (100만행 기준) 끌어올렸습니다. Elasticsearch 고난 항상 느끼는 것이지만 NoSQL은 진입장벽이 어마어마한 것 같습니다. RDBMS에 너무 익숙해진 것도 있겠지만 하나부터 열까지 새롭지 아니한게 없었습니다. RESTful API로 테이블 (인덱스)를 만들고 모든 CRUD 또한 RESTful API를 따르고 있었습니다. 또한, GUI도 ..

기존 동시성 문제 기존에도 동시성 문제가 발생한다는 것을 느낌적으로 알아차렸습니다. 이에 Synchronized 키워드를 이용해 동시성 문제를 해결했습니다. 기존 동시성 문제의 문제점 Synchronized 키워드는 다른 동시성 문제를 해결하는 방법보다 성능상 좋지못합니다. ver.2에서 개선한 동시성 문제 JPA의 특징 때문에 Synchronized 키워드는 어울리지 않는다고 판단하여 JPA와 어울리는 낙관적 락 / 비관적 락 중 하나를 선택하였습니다. 우선 테스트 코드를 통해 "동시성 문제가 발생합니다" 라고 증명하는 것부터가 문제였습니다. 그 때 마침 "단위 테스트" 라는 것에 꽂혀서 어디선가 DB를 불러오는 단위 테스트는 안티 패턴이다 라는 말이 생각났습니다. 그래서 Mock 객체를 이용한 단위 ..

기존 인증 방식 스프링 시큐리티에 100퍼센트 의존하는 방식이었습니다. 스프링 시큐리티는 웹 세션으로 동작합니다. 기존 인증 방식의 문제점 추후에 MSA로 변경하는 과정에서 필요한 stateless한 인증 방식이 필요했습니다. ver.2에서 개선한 인증 방식 스프링 시큐리티의 Authentication 객체를 이용해 JWT를 만들어 회원 인증에 사용했습니다. 인증 레이어를 기존 스프링 시큐리티 하나에서 JWT를 추가해 두개의 인증 레이어를 사용할 수 있었습니다. 스프링 시큐리티에 100퍼센트 의존했으면 구현할 수 없었던 OAuth 의 Remember-me 기능을 JWT를 이용해 구현할 수 있었습니다. JWT로 인증 추가 0. 고민 사실 이 프로젝트를 진행할까 말까 수많은 고민이 오갔습니다. 이미 인증으로..

기존 SMTP SMTP 는 stateful 프로토콜 + 동기 네트워킹입니다. 기존 방식의 문제점 이메일은 회원가입시 2FA로 이용됩니다. 회원 가입을 할 때 이메일을 보내면 이메일이 전송되는데 걸리는 시간인 3~4초 가량을 아무것도 할 수 없습니다. 이는 부정적인 유저 경험으로 이어질 우려가 있습니다. ver.2에서 개선한 SMTP SMTP를 @Async 어노테이션으로 비동기 처리를 하였습니다. 기존 방식대비 고객경험을 90배가량 개선할 수 있었습니다. 먼저 JavaMailSender를 빈으로 등록해줬습니다. package com.hello.capston.config; import org.springframework.context.annotation.Bean; import org.springframewo..

기존 프로젝트의 방식 "누가"에 대한 데이터가 굉장히 많이 필요합니다. "누가" 장바구니를 담았는지, "누가" 좋아요를 눌렀는지, "누가" 결제를 했는지, "누가" 로그인을 했는지 등등... 총 42개의 API 중 66%에 해당하는 28개의 API에서 "누가"에 해당하는 데이터를 요청했습니다. 총 DB 연산 143개 중 약 30%에 해당하는 43개의 DB 연산이 "누가"에 해당하는 데이터를 요청합니다. 기존 프로젝트의 문제점 정적 데이터를 항상 DB에서 조회하기 때문에 조금만 트래픽이 몰리면 DB의 심각한 부하가 우려됩니다. ver.2에서 개선한 문제점 정적 데이터이기 때문에 캐싱을 적용하면 좋겠다고 판단하였습니다. EHcache, Memcached, Redis 중 고민하였고 세션까지 분리할 수 있고 다..

유튜브를 보다가 시니어 개발자분들이 나와서 얘기하는 것 중에 Version 2 를 만들어봐라 시간이 된다면 3, 4 이렇게 점진적으로 고도화시켜봐라 그것이 반드시 도움이 될것이다 라는 얘기를 들었습니다. ver.2 를 만들기 위해서는 어느정도 큰 규모의 서비스여야 한다고 생각이 들어서 제가 만든 프로젝트 중에 가장 규모가 큰 온라인 홈쇼핑을 ver.2로 만들기로 했습니다. 기존 ver.1 에서의 문제점을 분석하고 해결할 수 있는 기술을 공부하고 테스트하고 적용하기까지의 블로그 포스팅이 될 것 같습니다. 우선 제가 분석한 제 온라인 홈쇼핑 ver.1의 문제점은 다음과 같습니다. 인증, 인가에 Spring Security를 사용하고 있는데 추가적인 레이어가 필요할 것 같다 현재는 세션을 쓰고있음 데이터베이스..

이번 프로젝트의 주제와 별개로 제 나름대로의 목표는 두가지입니다. TDD 적극 이용 네이티브 쿼리 없애기 제 프로젝트는 아무 생각없이 프로젝트를 진행하는 것이 아니라 제가 얻어가는 것이 하나라도 있어야 한다는 대전제를 가지고 있습니다. 따라서 이번 프로젝트에서는 TDD 적극 이용, 그리고 네이티브 쿼리 없애기를 목표로 진행하도록 합니다. 개요 주제 선정 이유 이번 주제는 스터디 모임 사이트입니다. 말 그대로 스터디 모임에 있어서 편리함을 주는 사이트입니다. 기존 스터디 모임 사이트가 있긴 하지만 단순히 스터디 할 사람 모여라~ 하고 모이고 스터디하고 이런 사이트가 주로 이룹니다. 따라서 제 사이트는 다른 스터디 사이트들과 차별점을 이룹니다. 바로 프로그램이 알아서 스터디를 관리해준다는 것입니다. 이런 사..