개발 일기

상황 프레시 카트는 Redis 를 사용하고 있고, 용도는 아래와 같습니다 - 다중 서버 환경에서 로그인 유저의 세션을 보관할 수 있는 공통 저장소 - 추후 메인 페이지에서 보여지는 전체 상품 데이터를 캐싱하기 위해. 서버는 언제나 fail 될 수 있고, 서버 문제로 애플리케이션이 동작하지 않는다고 가정해봅시다. 서버가 동작하지 않는 시간 만큼 비즈니스 중단/고객의 불편이라는 손실로 이어집니다. 특히 프레시 카트의 메인 기능인 주문은 로그인을 해야 가능하기 때문에, 늘 로그인을 가능하게 하는 것이 중요합니다. Redis Clustering 을 선택한 이유 레디스의 fail over 방식으로는 replication, clustering, sentinel이 있습니다. 이에 대해서는 별도 포스팅에서 자세히 설명..

문제 판매자의 제품 등록 기능에서 Insert 쿼리가 다수 발생한다는 것을 발견했습니다. Disk I/O는 웹 서비스 성능에 많은 영향을 미치는 중요 모니터링 지표입니다. 디스크의 데이터 처리 속도가 메모리나 CPU에 비해 너무 느리기 때문입니다. DISK I/O를 줄이는 것은 DB 성능 개선의 핵심 이기도 합니다. 이번 글에서는 쿼리를 여러번 날렸을 때, 나타나는 지연 현상을 개선 해보겠습니다. 개요 네이버 쇼핑, 배달의 민족 등 평소 이용하는 이커머스 서비스를 보면, 소비자가 다양한 옵션을 구성할 수 있도록 제품이 제공됩니다. 이를 충족하기 위해, 판매자가 제품을 등록할 때, 다양한 옵션 그룹과 옵션을 설정할 수 있어야 합니다. 제품 등록 POST 요청 값의 예시입니다. 제품(샐러드) 에 옵션이 있을..

상황 프레시카트라는 이커머스 서비스의 주문 기능을 구현하고 있었습니다. 주문의 특성 상, 여러 유저가 하나의 상품을 동시에 주문하는 상황이 빈번할 것입니다. 이렇게 동일한 재고 수량 데이터를 차감하는 상황이라면 코드가 잘 작동할지 점검 해보고 싶었습니다. 먼저 주문 기능의 동작을 살펴보겠습니다. 이는 하나의 트랜젝션 내에서 수행됩니다. 1) 유저가 CART(DTO) 에 주문 객체를 담는다. 2) Product_Inventory 테이블에서 주문하려는 제품의 재고를 확인한다. 3) 재고가 있는 경우 주문 수량만큼 차감하여 수량을 업데이트 한다. 3) 주문을 완료한다 주문 로직 - OrderRegisterProcessor.java @Transactional public void place(LoginUser u..

프레시카트는 1인 프로젝트 입니다. 1인 프로젝트이다 보니, 팀과 협업할 때보다 충돌이 발생하는 지점이 적었고 신경 쓸 부분도 많지 않았습니다. 현업에서는 개발 못지 않게, 개발 환경을 구성하고 개선하는 것 역시 필요할 것이라고 생각했습니다. 이전의 팀 프로젝트에서 느꼈던 어려움을 돌이켜보고, 개발자 동료들이 공유해주는 어려움을 참고하면서 여러 기술을 도입해보았습니다. Flyway로 데이터 베이스 스키마의 변경 이력 관리 도입 이유 이전에 팀 프로젝트를 할 때, DB를 공유해서 쓰면서 어려움을 겪은 적이 있었습니다. 스키마 변경이 있을 때마다, 공유된 내용을 확인하고, 변경 사항을 인지해야 했습니다. 성과 flyway 적용으로 변경 이력을 문서화 할 수 있게 되었습니다. 변경에 맞춰 애플리케이션 로직도 ..

상황 이커머스 서비스를 구현하면서, 서버 메모리에 세션을 저장하는 방식으로 로그인을 구현했습니다. 추후 서버가 증설될 경우, 세션이 여러 서버에 걸쳐 공유되어야 하는데, 기존 구조는 서버마다 저장소를 독립적으로 갖는다는 한계가 있었습니다. 이전 포스팅 에서도 살펴 보았듯, 세션의 특성 상 서버 scale-out 시에는 (서버의 대수를 늘리는 것) 별도 처리를 해줘야 하기 때문입니다. 실제로 유저가 몰려서 서버를 증설하는 상황은 아니었습니다. 하지만, 유저가 늘어나고 이에 따라 scale-out 하는 것이 매우 흔한 상황임을 가정해볼 때, 다중 서버 구성에 대비하는 것이 중요하다고 생각했습니다. 깊이 학습해볼 필요성을 느껴서 Redis로 로그인 중앙화를 구현하였습니다. 이번 포스팅에서는 1. 해당 문제를 ..

객체 지향을 고민하게 된 계기 작년에 스프링 입문을 위한 자바 객체 지향의 원리와 이해 책을 읽었습니다. (이 책을 읽고 나서 스프링을 좀 더 개발 의도에 맞게 (== 객체 지향을 생각하며) 바라볼 수 있었습니다. 디자인 패턴, SOLID 등을 소개하면서 어떻게 객체 지향을 적용할 수 있을지, 좋은 가이드가 되어준 책 이었는데요. 스프링 개발자라면 꼭 읽어보기를 추천합니다. ) 객체 지향은 인간이 사물을 인지하는 방식대로 프로그래밍 하는 방식입니다. 즉 기계에 맞춰 사고하던 방식이 아니라, 인간이 현실세계를 인지하는 방식으로 프로그램을 만들자는 의도에서 출발합니다. 객체 지향 원칙을 지키다 보면, 결합도는 낮추고 응집도는 높이는 방향으로 설계하게 됩니다. 그리고 이는 재사용성, 유지보수성을 용이하게 해줍..

상황 비밀번호 암호화를 구현하는 기술을 고민하고 있었습니다. 해시를 적용하고자 했으나, 해시는 같은 입력 값에 대해, 항상 같은 결과 다이제스트가 나오는 취약점이 있습니다. 문제 위의 취약점 때문에, 해시 알고리즘은 레인보우 테이블을 사용해서 해킹 당할 위험이 있었습니다. 해결/결과 솔트는 해싱 하기 전에, 랜덤 문자열을 비밀번호에 더합니다. 솔트와 함께 암호화 하면, 솔트가 임의 값이기 때문에 원래 값을 찾아내기 어렵습니다. 즉, 사용자 별로 다른 솔트를 사용한다면, 동일한 패스워드를 사용하더라도 다이제스트가 다르게 생성됩니다. 자바에서 지원하는 BCrypt 라이브러리를 사용하여 솔트를 구현했습니다. 해시와 비교할 때, 결과값이 예측 불가능하기 때문에, 보안을 강화하는 이점을 얻을 수 있었습니다.

상황 인증 기능을 구현할 때, 로그인이 필요한 API에 인증 처리를 강제해야 했습니다. 기존 코드는 인터셉터의 addPathPatterns로 모든 경로를 더하고, excludePathPatterns로 일부 경로만 제외하여 구현했습니다. 문제 위의 방식은 로그인이 필요 없는 경로를 추가할 때마다 직접 입력해줘서, 오타가 발생할 위험이 있었습니다. 이러한 위험을 줄이면서, 컨트롤러에서 로그인 필요 여부를 명시적으로 표현하는 방법을 고민하였습니다. 해결 /결과 @LoginCheck 라는 커스텀 애노테이션을 만들었습니다. Retention Policy를 설정하여, 런타임까지 객체를 유지 했습니다. 메서드 단위로 적용함으로써, 인터셉터를 거쳐갈 때 @LoginCheck가 붙은 메서드는 로그인 여부를 확인하도록 강..