1. 가장 집중한 챕터 및 Step 소개내가 가장 집중한 챕터는 Chapter3의 콘서트 예약시스템 개발이었다.대기열 구현, 좌석 임시예약이 핵심인 프로젝트였습니다. 그 전까지 트래픽 제어를 위한 대기열 구현을 해보지 않았고, 동시성 제어도 따로 의식적으로 개발한 적이 없었습니다. 2. 기술적 도전 및 트러블 슈팅1) 대기열 구현 2) Jpa 1차 캐시(영속성 컨텍스트)로 인한 비관적 락 조회 오류 /** 일반 좌석 조회 */ Seat seat_ex = seatReader.findSeatBySeatNoAndConcert(seatNo, concertId, concertDate) /** 비관적락으로 Seat 조회 */ Seat seat = seatReader.findSeatBySeatNo..
[9주차 과제]내가 개발한 기능의 트랜잭션 범위에 대해 이해하고, 서비스의 규모가 확장된다면 서비스들을 어떻게 분리하고 그 분리에 따른 트랜잭션 처리의 한계와 해결방안에 대한 서비스설계 문서 작성실시간 주문, 좌석예약 정보를 데이터 플랫폼에 전달하는 요구사항을 기존 로직으로 구현했을때 발생하는 문제와 해결방안에 대한 문서 작성 [트랜잭션 분리의 중요성]서버 어플리케이션에서 트랜잭션의 범위를 어떻게 잡는지에 따라서 성능에 영향을 줄 수 있다.문제상황 1번 : 1개의 트랜잭션에 너무 많은 작업이 있거나, 조회가 Slow Read 쿼리가 포함되어 있는 경우트랜잭션 내에서 테이블의 데이터에 Lock을 잡은 상황이라면 다른 사용자는 트랜잭션이 모두 끝날 때까지 대기해야 하는 문제Slow Read 하는 쿼리가 있는..
안녕하세요 강정호입니다. 이번 포스팅은 제가 콘서트 예약시스템에서 구현한 대기열에 대한 설계에 대해서 작성해보겠습니다. [대기열이란?]대기열은 서버에 대용량 트래픽이 몰릴 때를 대비해서 서버의 부하를 일정 수준으로 유지하기 위해 만듭니다.대기열에 있는 사용자의 요청은 일정 시간이 지나면 예약이 가능한 상태로 변경되어 고객들은 콘서트 예매를 할 수 있습니다.이렇게 하여 단시간에 서버에 발생하는 부하를 줄여서 안정적으로 서버를 유지할 수 있습니다. [대기열 구현 방법]제가 생각한 대기열 구현 방법은 2가지가 있습니다. 1. DB를 활용한 대기열 구현 대기열 진입고객이 토큰 발급 API 호출 => 토큰이 없다면 사용자ID와 토큰 발급 => DB 대기열 테이블에 사용자의 상태값과 함께 INSERT. 스케쥴러- ..
오늘은 트러블 슈팅에 대해서 포스팅 하려고 합니다. [문제 상황]비관적 락을 사용해서 좌석 예약시 동시성 제어를 할 수 있도록 프로그램을 개발했습니다.그러나 5개명의 사용자가 1개의 좌석 예약을 했을 때, 5명 모두 좌석 예약에 성공하는 현상이 발생했습니다. 이론상 1개의 좌석이 먼저 선점되어 예약이 되면 나머지 4명은 좌석 예약 불가해야 합니다. [문제가 발생한 코드] /** 좌석 예약 */ @Transactional public ReservationResponse reserve(ReservationRequest request) { // 1. 사용자를 조회한다. User user = userManager.findUserById(request.getUserId()); if(user ..
8주차에는 콘서트 예약시스템 내에서의 인덱스가 필요한 쿼리에 대해서 인덱스 설계 및 성능 개선사항을 체크하였다.그리고 Redis 캐시를 사용해서 대기열을 설계하고 구현하는 것을 했다. Keep : 현재 잘하고 있는 점- 좌석 조회 쿼리에 인덱스를 걸어서 성능 효과를 봤다.- Redis를 활용해서 대기열 구현에 완료. Problem : 현재 겪는 문제점1. 인덱스 설계에 대한 고민이 더 필요하다=> 카디널리티가 높은 것(중복수치가 낮은 컬럼)으로 인덱스를 설계하라고 했는데, 그러면 PK로 인덱스를 거는게 맞지 않나?=> 인덱스 설계시 많이 걸러낼 수 있는 컬럼을 인덱스 컬럼으로 걸어라. 2. Redis 쓰임새에 대한 고민Redis를 DB와 어플리케이션 사이의 어떤 중간 매개자로 생각하고 구현을 했다. 즉..
오늘은 대용량 트래픽 3주차 강의이다. [인덱스 리뷰]데이터가 100개인데, 인덱스를 태워서 조회한 데이터가 70개이면비효율적인 인덱스이다.조회결과가 전체 대비 높지 않아야 한다.- 무조건 인덱스를 거는게 좋은 건 아니다. 적절한 곳에 걸어야 한다. [캐시 사용]1. [트랜잭션]1. 서버에서 DB 커넥션 관리를 해야 하는데 트랜잭션을 길게 가져가면 커넥션 관리가 어려워진다.2. [어플리케이션 이벤트 리스너] 개선 1) 주문정보전달이 실패하면 결제요청, 유저포인트 차감, 결제정보저장이 모두 롤백이 된다.그래서 주문정보전달은 따로 뺸다.개선 2) 주문정보전달은 별도의 스레드가 처리할 수 있도록 @Async를 한다.그렇지 않으면 고객은 주문정보전달이 끝날때까지 기다려야 하기 때문이다.개선 3) Event..
Chapter 2 : 비밀에 접근하는 법pg 52 : 감정은 우리의 주파수를 알려주는 회로다기분이 좋으면 => 우주가 "당신은 기분이 좋다"기분이 나쁘면 => 우주는 "중지!! 당신은 지금 나쁜생각을 하고 있어!"생각을 바꿔서 좋은 일을 생각하라. pg 53당신은 "생각하는 것" 보다는 "느끼는 것"을 받게 된다.사람들은 감정만 바꾸면 하루 전체를, 심지어 인생까지도 바꿀 수 있다는 사실을 전혀 모른다.기분이 좋아야 좋은 상황과 사람들을 끌어당기게 된다. pg 55 뭔가 당신에게 갔다면 당시이 끌어당겼다는 뜻이다. 지속적인 생각으로 끌어당겼다는 의미다. pg 58사랑은 가장 높은 주파수에 있다. 더 큰 사랑을 느끼고 내보낼수록 더 큰 힘을 얻게 된다. pg 61자신이 무엇을 생각하는지 알려면 자신의 감정..
콘서트 예약시스템에서 사용하는 쿼리 중에서 인덱스로 성능을 개선할 수 있는 부분에 대해서 알아보자. [콘서트 예약시스템에서 성능개선의 여지가 있는 쿼리] 특정일자에 대한 예약 가능한 좌석리스트 조회@Query("SELECT s FROM Seat s WHERE s.seatNo = ?1 AND s.concert.concertId = ?2 AND s.concertSchedule.concertDate = ?3") public Seat findSeatBySeatNoAndConcert(Long seatNo, Long concertId, LocalDate concertDate); 위 쿼리를 보면 Seat 번호를 조회하기 위해서 Concert, ConcertSchedule 테이블과 조인을 한다.만약에 좌석갯수가 3만..
대용량 트래픽 처리 서버를 구축할 때 동시성을 제어하는 것은 매우 중요하다.왜냐하면 대량의 트래픽이 몰릴 때 데이터의 정합성을 유지하는 것이 필수적인 요소이기 때문이다. 내가 직접 개발하면서 경험한 동시성 제어 프로그래밍에 대해서 작성해본다. [동시성 제어 프로그래밍 방식]동시성 제어 프로그래밍은 트랜잭션, 트래픽, 분산 환경 여부 등에 따라 다르게 채택하여 사용할 수 있다.콘서트 예약시스템에서 동시성 이슈가 발생하는 지점은 아래 2가지이다.1) 좌석 예약2) 포인트 충전, 사용 좌석 예약 기능 동시성 제어 프로그래밍1. synchornized - 부적합Java에서 제공하는 가장 기본적인 동시성 제어 프로그래밍 방법이다.좌석 예약 메서드에 synchronized를 걸면 싱글 스레드 방식으로 좌석 예약을 ..
이번주는 동시성 구현에 대해서 구현하는데 재미있었다.6주차에 CI/CD는 생각보다 어렵고 지루했는데 다시 코딩하니 재미있었다. Keep : 현재 만족하고 개선할 부분1. 포인트 충전에 대해서 비관적락과 테스트 코드 구현 완성.사용자가 포인트 충전 요청에 대해서 모두 순차적으로 충전해줘야 한다고 생각해서 비관적락으로 구현 2. 좌석 예약을 낙관적 락, 비관적 락으로 구현 완료.3주차 때 좌석예약을 비관적 락으로 구현했는데 테스트가 중간에 끝나지 않고 계속해서 도는 현상이 발생했다.알고보니 테스트 코드의 countLatchDown.await() 메서드를 잘못 사용하고 있어서 그랬었다. 원인 : await() 메서드로 인해서 다른 스레드가 끝날 때까지 무한대기.for(int i=0; i{ try{..
[어떤 Lock을 적용할지 고려하는 순서]1. DB Transaction과 Lock 범위에 따른 처리를 고려해야 한다.트랜잭션 시작, 종료 전후로 락을 획득해야 하는지트랜잭션을 먼저 시작하고 락을 획득해도 되는지 등등 2. 낙관적 Lock으로 해소가 가능한가?먼저 낙관적락으로 해소가 가능한지 확인한다.낙관적 락이 적합한 경우는첫 번째 조건 : 수정에 실패했을 때, 해당 비즈니스로직의 실패로 이어져도 되는 경우두 번째 조건 : 동시에 많은 충돌을 발생시키지 않는 경우(Retry로 해소) 3. 비관적 Lock으로 해소가 가능한지?비관적 락이 적합한 경우는첫 번쨰 조건 : 작은 트랜잭션 범위 내에서는 빠르게 처리 가능두 번째 조건 : 반드시 순서대로 처리해야 하는 작업에 효과적 주의 : Lock의 잠금 범위에..
- Total
- Today
- Yesterday
- 재테크공부
- 월급쟁이부자들
- 깃허브
- ```````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````
- 부동산공부
- 관계대수
- 깃
- 월부닷컴
- 작성 방법
- docker
- 파라메터
- resize
- 바
- Spring boot
- 폭포수
- 유즈케이스
- 회고
- 열반스쿨기초반
- 도커
- github
- front
- 개발자 회고
- Use case
- 인셉션
- 2023년
- 내년은 빡세게!!
- push_back
- Inception
- GIT
- pop_back
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |