전체 글

취업코스를 경험하면서 많은 분들을 만났고, 취업을 위한 것만이 아니라 개발 자체에 즐거움을 느끼고 노력하는 모습에서 큰 자극을 받았다. 내가 학습한 부분에 대해 도움을 드리기도 하고, 내가 도움을 받기도 하면서 함께 성장해 나가는 과정을 경험했고, 최종적으로 예약 상품 MSA 프로젝트까지 수행해 나가면서 많은 성장을 할 수 있었던 것 같다. 프로젝트를 마무리하면서 경험들을 되돌아보고 더 좋은 발전을 위해서 회고록을 작성한다. 1. 프로젝트 목표 특정 시간부터 상품구매 버튼이 오픈되고, 짧은 시간에 많은 주문 트래픽이 발생하는 상황을 가정하여 프로젝트를 설계, 구현해보는 프로젝트를 진행하였다. 나는 크게 3가지의 주제에 대해 고민해보는 것을 목표로 잡고 프로젝트를 진행하였다.(특정 시간대에 대량의 주문 트..

🎯 CircuitBreaker와 Retry가 뭘까? 프로젝트를 진행하면서 주문 서버에 재고 관리 로직이 함께 들어가 있었다. 재고 관리 로직은 주문, 결제, 상품 관리 등 다양한 로직에 사용되어 트래픽이 많을 것으로 예상되어 확장성을 가지면 좋겠다고 생각하였고, 각 기능별로 유지보수를 위하여 서버를 분리해 보는 학습을 해보면 좋겠다고 생각하였다. 회복탄력성은 Open Feign의 resilience4j-circuitbreaker 와 resilience4j-retry를 사용하였다. MSA 학습을 위하여 뉴스피드 도메인을 간단히 설계하였다. https://topaz-raincoat-203.notion.site/65cae744cebd44cbabc3771e222e3737?pvs=4 위와 같이 분리된 서버 간에 ..

🎯 한 사람에 대한 여러 요청을 어떻게 제한할 수 있을까? 예약 상품 프로젝트는 특정 시간에 상품이 오픈되고, 많은 사용자가 짧은 시간에 주문 요청을 할 것이라고 가정한다. 위의 그림에서 고려사항1이 생겼다. 한명의 사용자가 여러 PC에서 로그인하여 동시 요청하는것을 방지하려면 어떻게해야할까? 고민해본 해결방법은 아래와 같다. 1. 로그인할 수 있는 기기 개수에 제한을 건다. 2. Gateway에서 RateLimit을 구현하여 많은 요청을 막는다. 🎯 [프로젝트에 적용] 로그인 기기 개수에 제한 걸기 로그인 할 수 있는 기기 개수에 제한을 두어 많은 PC에서 같은 ID로 주문 요청 하는것에 제한을 두려고 한다. 현재 로그아웃 구현 상태는? 현재 로그아웃 방식을 활용하기 위하여 redis를 활용하고 있다..

📌 서버를 확장한다면 synchronized를 사용하면 안 될까? 이 전에 단일 서버 환경에서 synchronized를 활용하여 동시성 문제해결에 접근해 보았다. 만약 현재 상태에서 서버를 확장한다면 어떻게 될까? 아래와 같이 하나의 프로세스 내에서는 synchronized로 인해서 1개의 스레드만 redis에 접근할 수 있다. 그러나 여러 프로세스 상에서는 동시에 redis에 접근할 수 있기 때문에 redis와 관련된 연산을 원자적으로 처리할 수 있도록 해줘야 한다. 만약 아래와 같이 redis가 아니라 MySQL과 같은 Database로 바로 접근하는 경우라면 synchronized와 MySQL의 테이블락을 활용하여 시스템을 구성해 볼 수 있을 것 같다. 이런 경우에는 각 서버에서 synchroniz..

📌 고민사항 이전에 재고의 동시성 문제를 해결하기 위하여 synchronized를 활용하여 재고수량 변경 부분에 락킹 처리를 해주었다. 그리고 단일서버 synchronized의 임계영역을 최소화 하기위해서 상품 판매 오픈전에 미리 특정상품 A에 해당하는 재고 수량정보를 로컬서버에 캐싱해 온 후 수량정보를 변경하는 방식을 생각했었다. 이러한 상황에서 아래와 같이 크게 3가지 고민사항이 생겼다. 1. 캐싱을 한다면 로컬 서버(메모리)에 캐싱할 것인가? 아니면 redis와 같은 global캐시를 활용할 것인가? 2. 상품 판매 오픈전 캐싱해올 때 어떤방식으로 캐싱해 올 것인가?(판매자의 수동처리 or 배치처리) 3. 캐시의 경우 서버가 다운되는 순간 날아가 버리고, 재고수량 관리에 문제가 생길 것이다. 이러한..

📌 고민사항 재고 증가/감소 로직에서 동시성 문제가 발생하였고, 해당문제를 해결하기 위해서 뮤텍스, 세마포어, 원자적연산등의 방법들을 고려하였다. 자바에서 뮤텍스 방식을 활용하기 위해 synchronized를 지원하는데, 동시성 문제가 발생할 수 있는 임계영역에 락을 걸어서 다른 스레드가 접근하지 못하도록 막는 방식이다. 락 방식을 사용할 때 가장 생각해봐야 할 점은 하나의 스레드에서 락을 걸어버리는 순간 다른 스레드는 해당 자원에 접근하지 못하기 때문에 대기를 하게되고, 병목현상이 발생될 수 있다는 점이다. 그래서 synchronized를 적용시킬 때에는 적용시킬 영역을 최소화 하는것이 중요하다. 📌 기존의 재고 감소 로직 아래는 동시성 문제가 발생할 수 있는 재고 수량 감소 메서드이다. @Transa..

📌 목표 3주 차는 실제로 계획한 테이블을 생성하고, 데이터를 옮기는 작업을 수행하는 것이었다. 테이블의 데이터를 새로운 테이블로 옮기기 위하여 옮길 새로운 데이터베이스를 연결하고, 데이터를 옮긴 후 테스트까지 작성해 보는 것이 목표였다. 4주 차 과제의 목표는 하나의 채팅서버에 API와 소켓서버가 통합되어 있어서 API 배포 시 소켓 서버의 세션이 끊기는 문제가 있는데, 이를 해결해 나가는 과제였다. 📌 데이터베이스 dual update 먼저 서버에 새로운 Database를 연결하여 하나의 서버에 2개의 데이터 베이스를 연결하는 것이 목표였다. NestJS에 PostgreSQL을 연결하는 방법은 2가지를 고려하였다. 1. ts-postgres 2. typeORM Spring 환경에서 JDBC를 사용할지..

📌 직무부트캠프 채팅 마이그레이션 백엔드 직무 체험 2주차 회고 2주차 부터는 본격적으로 프로젝트를 분석하고, 마이그레이션 계획을 세우는 것 이었다.(두근두근) 📌 어떤 테이블을 마이그레이션 해야할까? # 마이그레이션 테이블 선정 마이그레이션 테이블 선정함에 있어서 말도 안되는 실수를 저질렀다. "그냥 데이터 많이 쌓이는 테이블을 옮기면 되는거 아니야?" 부끄러운 수준의 생각이다.. 그냥 같은 건 없다. "데이터가 많이 쌓이는 테이블을 옮겨야한다" 라는건 맞는 말이겠지만 조금 더 구체적인 기준과 이유가 정리되어야 한다. 최종적으로 나는 chat, chat_like, user 테이블을 선정하였고, chat과의 연관관계(join을 통한 결합 등)를 근거로 제시하였다. chat데이터 응답이 user, chat..

📌 자바 제공하는 스레드 vs 운영체제 스레드 자바에서 스레드를 사용할 때에는 Thread객체를 생성하고, 작업할 내용을 프로그래밍 한다. start()메서드가 실행되면 쓰레드 객체는 새로운 운영체제 스레드를 만들어달라고 요청하고, JVM에 요청해 정해진 크기의 스택 공간을 할당받아 로컬변수를 저장한다. 즉, Thread 객체는 운영체제의 스레드 1개가 담당하여, CPU의 core에 의해 스케쥴링된다. 이렇게 운영체제 스레드와 1:1로 맵핑되는 스레드를 “Platform Thread”라고 부른다. 이러한 Platform Thread는 OS Thread와 1:1로 매칭되기 때문에 많은 비용이 든다. 요약 CPU 스레드 스케쥴링에 대한 모든 책임을 운영체제가 가지고 있다. Platform Thread는 운영..

도메인 주도 개발이라는 책을 읽으면서 이벤트라는 개념을 알게 되었고, 이벤트는 비동기적인 방식으로 동작한다라는 것을 알게되었다. 동기와 비동기의 차이에 대해서 이해 해보고, 동기 비동기를 언급하면서 Blocking, Non-blocking 이라는 용어도 등장하는데 이러한 용어들의 개념과 차이를 알아보자. 📌 Sync(동기) vs Async(비동기) 단순히 생각하면 동기는 특정 작업이 끝날 때 까지 기다리고, 순차적으로 실행되는 방식이다. 반면에 비동기는 다른 작업이 끝나지 않아도 기다리지 않고 자신의 동작을 수행하는 방식입니다. 하지만, 이렇게 단순히 생각하면 Blocking, Non-blocking 관점을 생각했을 때 해석이 먼가 어렵게 되는 것 같다. 그래서 나는 다음과 같이 이해하려고 한다. 동기방..