모의 주식 투자 서비스 '무주시'를 리팩토링하며 가장 먼저 한국투자증권 실시간 체결가 웹소켓 세션 및 구독 관리 구조를 되돌아보았다. 이전에도 리팩토링을 진행하였지만, 그 과정에서도 구조에 대한 몇 가지 의문이 남아있었다. 웹소켓 세션과 구독 종목 관리 책임이 혼재되어 있어 계층간 경계가 모호하다는 느낌을 받았었다. 특히, 도메인 주도 설계와 헥사고날 아키텍처의 Port&Adapter를 통해 외부 인프라와 계층간 결합도를 분리하는 중요성에 대한 지식을 얻은 뒤 기존 리팩토링 구조에 대한 아쉬움이 크게 부각되었다. 이번 포스팅에서는 기존 리팩토링 구조에서 위와 같은 아쉬웠던 문제를 개선해 피드백한 과정을 정리하고자 한다.
여행 기록 관리 플랫폼 '여기가' 프로젝트를 진행하며 이메일 인증·비밀번호 초기화 이메일 전송 기능 개발을 담당하게 되었다. 이메일 전송은 외부 메일 서버를 거쳐 실행되는 작업으로 Network I/O 등 시간이 오래 걸리는 작업이다. 따라서, 핵심 비즈니스 로직과 이메일 발송 로직을 분리하여 결합도를 낮추고, 향후 메일 서버 분리의 확장성을 염두에 두고 이메일 발송 로직을 이벤트 기반 아키텍처(EDA)로 분리하였다. EDA 도입 후 메시지 브로커로 이벤트가 발행되지 않아 이벤트가 유실되는 문제를 겪고 이에 대한 해결 방법을 모색하던 중 'Transactional Outbox Pattern'을 알게 되었다. 이번 포스팅에서는 저장된 이벤트 아웃박스를 폴링하여 실패·미발행 이벤트를 발행하는 구조를 구현한 경험을 공유하고자 한다.
여행 기록 관리 플랫폼 '여기가' 프로젝트를 진행하며 이메일 인증·비밀번호 초기화 이메일 전송 기능 개발을 담당하게 되었다. 이메일 전송은 외부 메일 서버를 거쳐 실행되는 작업으로 Network I/O 등 시간이 오래 걸리는 작업이다. 따라서, 핵심 비즈니스 로직과 이메일 발송 로직을 분리하여 결합도를 낮추고, 향후 메일 서버 분리의 확장성을 염두에 두고 이메일 발송 로직을 이벤트 기반 아키텍처(EDA)로 분리하였다. EDA 도입 후 메시지 브로커로 이벤트가 발행되지 않아 이벤트가 유실되는 문제를 겪고 이에 대한 해결 방법을 모색하던 중 'Transactional Outbox Pattern'을 알게 되었다. 이번 포스팅에서는 각 도메인 이벤트를 일관된 EventOutbox로 변환하여 저장하는 과정을 구현한 경험을 공유하고자 한다.
여행 기록 관리 플랫폼 '여기가' 프로젝트를 진행하며 이메일 인증·비밀번호 초기화 이메일 전송 기능 개발을 담당하게 되었다. 이메일 전송은 외부 메일 서버를 거쳐 실행되는 작업으로 Network I/O 등 시간이 오래 걸리는 작업이다. 따라서, 핵심 비즈니스 로직과 이메일 발송 로직을 분리하여 결합도를 낮추고, 향후 메일 서버 분리의 확장성을 염두에 두고 이메일 발송 로직을 이벤트 기반 아키텍처(EDA)로 분리하였다. EDA 도입 후 메시지 브로커로 이벤트가 발행되지 않아 이벤트가 유실되는 문제를 겪고 이에 대한 해결 방법을 모색하던 중 'Transactional Outbox Pattern'을 알게 되었다. 이번 포스팅에서는 각 도메인 이벤트를 일관된 EventOutbox로 변환하여 저장하는 과정을 구현한 경험을 공유하고자 한다.
여행 기록 관리 플랫폼 '여기가' 프로젝트를 진행하며 이메일 인증·비밀번호 초기화 이메일 전송 기능 개발을 담당하게 되었다. 이메일 전송은 외부 메일 서버를 거쳐 실행되는 작업으로 Network I/O 등 시간이 오래 걸리는 작업이다. 따라서, 핵심 비즈니스 로직과 이메일 발송 로직을 분리하여 결합도를 낮추고, 향후 메일 서버 분리의 확장성을 염두해 이메일 발송 로직을 이벤트 기반 아키텍처(EDA)로 분리하였다. EDA 도입 후 메시지 브로커로 이벤트가 발행되지 않아 이벤트가 유실되는 문제를 겪고 이에 대한 해결 방법을 모색하던 중 'Transactional Outbox Pattern'을 알게 되었다. 이번 포스팅에서는 Transactional Outbox Pattern이 EDA에서 왜 사용이 되는지에 대해 알아본 경험을 공유해보고자 한다.
여행 기록 관리 플랫폼 '여기가' 프로젝트를 진행하며, 비밀번호 초기화 이메일 전송 기능 개발을 담당하게 되었다. 기능 개발을 완료한 뒤 이메일 전송을 보장하기 위한 의문이 들었다. 여러 방법들을 모색하던 중 '트랙잭션 아웃박스 패턴'에 대해 알게되었고, 이는 이벤트 기반 아키텍처(Event Driven Architecture)와 연관이 있다는 점을 배우게 되었다. 이번 포스팅에서는 이벤트 기반 아키텍처가 왜 사용되는지와 이벤트를 통해 얻을 수 있는 장점에 대해 서술해보고자 한다.
모의 주식 투자 서비스 '무주시'를 되돌아보며 이전부터 여러가지 문제가 발생했었던 한국투자증권 웹소켓 관련 부분을 리팩토링하기로 하였다. 기본적으로 한국투자증권에서는 세션 당 웹소켓 호출(구독 수) 유량 제한 정책으로 인하여 하나의 세션 당 41개의 종목에 대한 구독이 가능하다. 따라서, 다중 계좌를 사용하여 운용 가능 웹소켓 세션 수를 늘려 해당 정책에 대응하고자 한다. 또한, 이전부터 발생하였던 웹소켓 세션을 저장하기 위하여 해당 필드를 static 변수로 선언하여야지만 저장이 가능했던 이슈 등에 관한 내용을 다뤄보고자 한다.
이전부터 톰캣은 Java NIO 기반의 Non-Blocking I/O 기반으로 동작한다는 말을 듣기는 하였지만 이에 대해 제대로 이해를 하지 못하고 단지 쓰레드풀만 사용한다는 것 정도만 알고 있었다. 최근 스프링부트의 웹 서버 설정 등의 과정을 공부하며 다시 톰캣의 기본적인 동작 원리에 대해 공부해보기로 하였다. 이 과정에서 톰캣과 같은 웹 서버들은 Non-Blocking I/O 방식을 왜 사용하는지, 무엇인지에 대해 공부해본 내용을 정리하고자 한다.
이전에 진행했던 주식 투자 웹 서비스 프로젝트 '무주시'를 리팩토링하며 예전에 작성하였던 코드들을 다시 되돌아보고 있다. '무주시'는 한국투자증권 API를 사용하여 주식 관련 정보를 받아온다. 그 중 주식 분봉 데이터를 받아오는 과정에서 성능적인 문제점이 존재하였고, 최근 서버에서 쓰로틀링(Throttling)을 통한 API 호출 유량 제한 관련 포스팅들을 읽고 API 호출 유량 제한 정책을 두고있는 한국투자증권 API에 대응하는 용도로 무주시의 서버에 쓰로틀링을 적용하여 외부 API를 호출하면 이러한 문제를 해결할 수 있을 것이라 생각하였다. 해당 포스팅에서는 쓰로틀링 및 기타 리팩토링을 통한 성능 개선의 경험을 풀어보고자 한다.
여행 기록 관리 플랫폼 서비스에서 사용자 데이터 삭제 정책 중 Soft Delete 정책을 도입하기로 하였다. @SQLRestriction 어노테이션을 사용하여 엔티티 조회 시 쿼리 내 삭제된 사용자를 제외하는 조건문을 자동으로 추가하였다. 해당 프로젝트를 진행 중 Soft Delete 정책과 @SQLRestriction을 사용하며 겪었던 문제와 개인적인 생각을 정리하고자 한다.
Presentation Layer에 대한 단위 테스트 진행 시, CustomUserDetails를 메서드 파라미터로 사용하는 핸들러 메서드에서 값을 바인딩하지 못하는 문제를 발견하였다. 해당 문제를 찾은 과정, 발생 이유와 해결 방법을 해당 포스팅에 담아보고자 한다.
여행 기록 관리 플랫폼 프로젝트를 진행하며 이미지 관련 기능 부하 해결을 위하여 RabbitMQ 도입에 관한 논의를 진행하였다. 이전 Redis pub/sub 구조를 사용하며 메시지 브로커를 사용하는 MOM 구조에 관심이 생겼고 AMQP 구현 서비스들에 대한 호기심이 있었다. 또한, RabbitMQ를 도입하여 서버의 부하를 분산(감소)시킨다는 글들을 많이 보았으나 이에 대한 명확한 근거나 상황에 대한 설명이 부족하여 해당 포스팅을 통해 알아보고자 한다.
멋쟁이사자처럼 백엔드 운영진 및 대학교 학습 멘토를 진행하며 JPA를 가르치게 되어, JPA에 관한 기본적인 개념부터 다시 되돌아보고 있다. JPA의 고질적인 문제인 N+1 문제를 알아보고자 한다.
멋쟁이사자처럼 백엔드 운영진 및 대학교 학습 멘토를 진행하며 JPA를 가르치게 되었다. 필자도 JPA의 기본 개념부터 다시 되돌아보며 이에 대한 정리를 남기고자 한다. 해당 포스팅에서는 JPA의 연관 관계 매핑 과정에서 fetch 전략에 대해 자세히 정리해보고자 한다.
필자는 다른 사람들의 프로젝트을 열람하던 중 레코드 존재 여부 확인 과정에서 사용하는 메서드에서 의문점을 느끼게 되었다. 해당 포스팅에서는 레코드 존재 여부 확인 과정에서 사용하는 메서드에 따른 SQL 쿼리문의 차이와 그로 인한 성능 차이를 비교하고자 한다.
필자는 모의주식 투자 웹 프로젝트를 진행하며 한국투자증권 오픈 API를 사용하였다. 호출 유량 제한으로 인하여 여러 개의 인증키들을 등록해야할 소요가 발생하여 리스트 형태의 환경변수들을 바인딩하며 겪었던 문제 상황과 트러블 슈팅 과정을 나누고자 한다.
본 포스팅은 기존 블로그(https://velog.io/@hky035/websocket)에서 작성된 글입니다.