문제 해결, 기술 비교 (36) 썸네일형 리스트형 NICE API 일시불 취소 개발하기 개요 기존에 NICE API로 일시불 결제는 구현되어 있지만 모든 취소는 상담원을 통해서만 가능했습니다. 업무시간(8:30~19:00) 이외에 상담원이 부재하여 바로 취소를 할 수 없어서 NICE API 일시불 취소를 개발했습니다. NICE API 일시불 취소 순서도 취소 요청부터 취소 완료 후 알림톡 발송까지의 과정입니다. 순서도 설명 본인이 요청한 주문인가? 취소의 조건으로 본인이 요청한 주문인지, 취소가 가능한 상황인지 확인합니다. 추소 요청 주문번호에 따른 결제자 아이디가 현재 로그인 한 아이디인지 확인합니다. 또한 상품 준비 중(배송 준비 중) 상태를 기준으로 이전은 즉시 취소가 가능하며 그렇지 않다면 취소 접수를 통해 상담원에 안내합니다. 취소 가능한 상태인가? 중복 취소를 방지하기 위해서 취.. 스케줄링에 어떤 기술을 사용할까?(@Scheduled vs Spring Batch vs Quartz) 개요 Quartz는 오픈소스 잡 스케쥴링 프레임워크로 자바를 사용합니다. 단순하면서도 엄청난 유연성을 가지고 있으며 이를 통해 스케쥴링 추가와 DB 클러스터링 설정을 해보겠습니다. @Scheduled vs Spring Batch vs Quartz 스케쥴링을 위한 기술로는 크게 3가지를 선택할 수 있습니다. 스프링 기본 기능의 @Scheduled, Spring Batch, Quartz입니다. 처음으로 @Scheduled는 스케쥴링 기본 기능만 제공하며 DB 클러스터링이 가능하지 않습니다. 외부 라이브러리인 Shed Lock을 사용하여 제어할 수 있으나 현재 java 버전에 맞지 않아서 사용이 불가합니다. 현재 이 방식을 사용하고 있었는데 INSERT 작업의 경우 2개의 서버에서 중복 작업하는 문제가 발생하.. redis 저장소를 cache, session 전용으로 분리하기 개요 현재 저의 개인 프로젝트에서는 redis에 캐시, 세션(+rememberme token)을 모두 하나의 redis에 저장하고 있습니다. 최근에 redis의 replica, mysql의 replica를 공부하면서 장애를 대비하는 분산 환경을 잘 구비해야겠다는 사실을 깨닫고 있었던 찰나에, redis에 모든 정보를 관리하고 있다는 것을 발견했습니다. 따라서, 이번에는 너무 하나의 redis에 데이터가 몰리지 않도록 다중 redis 설정을 해보겠습니다. 기존에는 어떻게 redis가 작업을 처리하고 있을까? 현재 하나의 redis에 캐시용, 세션용 데이터가 모두 들어오고 있습니다. 많은 데이터들이 한번에 redis에 저장, 조회되면 대용량의 경우에는 성능에 이슈가 생길 수가 있습니다. 따라서 캐시용과 세션.. Redis eviction 정책은 무엇을 사용해야 할까? 개요 Redis를 통해 캐시하는 작업을 공부했습니다. 그렇다면 자연스럽게 드는 생각은, Redis의 메모리가 다 차면 이후에 어떻게 삭제(eviction)해야할까? 입니다. 삭제에는 다양한 정책이 있으며 이는 Redis의 장점이기도 합니다. 이번 시간에는 다양한 redis의 삭제 전략을 알아보고 최적의 선택을 해보겠습니다. maxmemory 설정하기 maxmemory 설정은 Redis가 사용할 메모리 양의 최대치를 정하는 것입니다. Redis가 캐시로 사용될 때 새로운 데이터가 추가되면 오래된 데이터는 자동으로 삭제되도록 하는 설정이 일반적입니다. (memcached도 이런 방식을 사용합니다.) Redis의 경우에는 다양한 정책을 가질 수 있으므로 종류와 설정법을 알아보겠습니다. maxmemory는 re.. 페이징에서 JPA N +1 문제 해결하기 개요 JPA는 간편하게 쿼리문을 사용할 수 있는 장점이 있지만 일대다 관계 혹은 EAGER, LAZY 조회 전략에 따라서 N + 1 문제가 발생합니다. 도메인을 그냥 조회하는 법, DTO로 변환해서 조회하는 법 등 다양한 방법들이 있는데, 이번에는 QueryDsl에서 페이징을 할 때 N + 1 문제를 방지하면서 쿼리문을 최소한으로 유지하기 위한 전략을 알아보겠습니다. 문제 상황 페이징을 이용해서 스터디를 100개씩 조회하도록 합니다. 기존에는 Study M : N Account 관계를 가지고 있으므로, 중간 테이블로 StudyLikes 엔티티를 가지며 Study 1 : N StudyLikes의 관계를 가집니다. 스터디를 조회하고 나면, 각 스터디의 스터디 좋아요(StudyLikes)를 순회하며, 내가 좋.. Mysql Replication 구성하기 개요 이번 시간은 Mysql Replication 개념을 정리하고 읽기와 쓰기 작업에 Replication 구성 및 적용 과정을 알아보겠습니다. 복제(Replication) 복제(Replication)는 1개 이상의 레플리카(replica) 저장소가 소스 저장소와 동기화를 자동으로 유지하는 과정입니다. (기존의 일반적으로 사용하였던 master-slave라는 용어를 source-replica로 대체하는 추세입니다. 하지만 일부 문서를 하면서 전자 용어를 사용하는 부분도 있습니다.) 아래는 1개의 Master 저장소와 복제한 Slave 저장소가 있습니다. 기본적으로 복제는 비동기 방식입니다. 설정에 따라서 전체가 아닌 부분 데이터를 복제할 수 있습니다. 복제의 장점 1. 스케일 아웃 성능을 향상하기 위해 .. Redis Persistence AOF vs RDB 개요 Redis는 In-memory 데이터 저장소이므로 서버를 재시작하면 모든 데이터를 유실합니다. 또한 복제 기능을 사용해도 잘못된 코드나, 사람의 실수가 발생하면 복제본도 똑같이 데이터가 삭제됩니다. 또한 복원을 할 수 없습니다. 따라서, Redis를 캐시 이외에도 용도로 사용한다면 적절한 데이터 백업이 필요합니다. Redis Persistence 종류 Persistence란 SSD같은 저장소에 데이터를 저장하는 것입니다. Redis는 영속성을 위해 여러가지 옵션을 제공합니다. 대표적으로 RDB, AOF 2가지 방식이 있습니다. RDB(Redis Database) RDB 영속화는 일정한 가격으로 특정 시점 스냅샷을 수행합니다. RDB 장점 1. RDB는 단일 파일이며, 특정 시점의 메모리에 있는 데이.. Message Queues vs Pub/Sub Asynchronous Messaging Pattern 비동기 메세징은 확장성과 안정성, 성능 향상을 목적으로 발행자(producer)의 메세지 생성이 구독자(consumer)의 작업과 분리되는 방식입니다. 메세징 시스템을 다룰 때, 일반적으로 Message Queue와 Publish/Subscribe 2가지로 나뉩니다. Message Queues Message Queue는, 메세지를 만드는 발행자(publisher)와 메세지를 보관하고 있는 큐(Queue), 큐에서 메세지를 소비하는 여러개의 소비자(consumer)로 이루어져 있습니다. 이 통신 방식은 publisher가 consumer에게 명령을 내리는 방식으로 작동합니다. publishing 서비스는 메세지를 큐 혹은 exchange에 넣고, 1개.. 이전 1 2 3 4 5 다음
