전체 글
항해 플러스 4기 백엔드 솔직 후기
벌써 항해 플러스 4기 10주간의 여정이 모두 마무리되었습니다.10주 동안 많은 일이 있었지만 내용을 정리할 겸 회고를 작성해보려고 합니다항해 플러스를 선택하게 된 계기저는 현재 3년 차 그룹웨어 서비스에서 웹 개발자로 재직 중이며, 개발자가 되기 전에 학부 시절 개발에 대해서 관심을 가지게 되었고 졸업 후 국비학원을 통해서 개발자로 취업하게 되었습니다. 현재 회사에서는 솔루션 회사이다 보니 기존에 이미 잘 만들어져 있는 소스코드 기반 위에서 작업을 하기 때문에 타 회사에서 사용하는 기술들에 비해서 많이 노후된 기술들을 사용하기 때문에 업무시간 외에 혼자서 공부를 하는데 어느 정도 한계가 있었습니다. 우연히 항해 플러스 광고를 보게 되었는데, 항해 플러스에 들어오기 전에 제가 가장 고민이 되었던 부분은..
항해 플러스 9주차 회고
9주차 책임 분리를 통한 애플리케이션 설계 1. 문제비즈니스 로직과 트랜잭션 범위 고려@Transactionalvoid payment() { 결제_요청_검증() 유저_포인트_차감() 결제_정보_저장() 주문_정보_전달() //외부 플랫폼 API 호출 } 예를 들어서 상품을 결제하는 결제 함수가 있다.결제처리 하는 비즈니스 로직 안에 여러 가지 함수들이 존재하며, 결제 처리가 끝난 후 최종적으로 주문 정보를 외부 API를 호출하여 전송해 주는 기능까지 존재한다. 즉, payment()가 정상적으로 성공 처리 되기 위해서는 외부 API에 호출 또한 정상적으로 통신이 되어야 한다. 위에 로직은 정상적인 것 같지만 심각한 문제가 있다.- 외부 플랫폼 API 호출 시 네트워크 이슈로 ..
항해플러스 8주차 회고
이번 주차는 콘서트 프로젝트를 진행하면서 대기열을 기존에는 RDB를 사용하여 구성하였으면, REDIS를 사용해서 구현하기 위해 다시 설계하고 구현해 보는 시간을 가졌다.대기열 리팩토링대기열은 기존에 동시성 유즈 케이스 고민하면서 사용했던 Redisson 라이브러리를 활용해서 Redis를 사용했다.대기열은 두 가지 상태를 가지고 있으며, 서비스 이용을 위해 대기하거나, 서비스를 이용할 수 있고, 대기열 만료 시간이 지난 사용자는 대기열에서 삭제가 되기 때문에 별도의 상태를 관리하지 않는 구조로 설계 방향을 잡았다.Wating QueueredissonClient.getScoredSortedSet("waitQueue");Redis Sorted Set 자료 구조를 기반으로 만들어진 RScoredSortedSet..
항해 플러스 5주차 회고
벌써 항해 플러스 과정이 절반이 지났다. 5주 차 동안 TTD, 아키텍처, 서버구축 등 과제를 하면서 정신없이 달려왔다. (절반 이상의 시간이 그동안 배운 내용들에 대해서 정리해야 될 것 같다.) 이번 주차 발제 과제였던 콘서트 프로젝트를 진행하면서 필요한 도메인이 무엇인지 생각하고 도메인 중심적으로 개발을 진행하려고 했지만, 막상 개발을 하면서 데이터를 우선 적으로 가지고 와야 할 것 같은데?라는 느낌이 강하게 들어서 개발을 진행하고 돌이켜보니 서비스 코드에 비즈니스 로직이 다 들어가는 느낌 적인 느낌.. DDD에 대해서 조금이라도 감을 잡기 위해서 "도메인 주도 개발 시작하기 : DDD 핵심 개념 정리부터 구현까지 " 책을 구매해서 읽어보고 있는데 (현재 3장..) 내가 한건 도메인 주도 개발 이라기..
콘서트 예약 프로젝트 회고
콘서트 예약 프로젝트를 진행하며 코딩을 하기 전에 시퀀스 다이어그램, ERD, API 명세를 만들면서 이걸 내가 할 수 있을까 라는 생각이 가장 먼저 들었지만 도메인을 나눠서 그 도메인에 맞는 책임과 로직을 구현하다 보니 하나씩 완성할 수 있었다. 오늘은 고민을 많이 한 2가지 케이스에 대한 내용을 회고하려고 한다. - 대기열 구현 - 포인트 충전 동시성 문제 대기열 구현 대기열 로직을 구현하고 동시성 테스트 케이스를 2가지 작성을 하였다. (테스트 환경 : 대기열이 0명인 경우) 1. 한명의 사용자가 대기열 신청을 동시에 여러 번 하는 경우 한 번만 신청이 완료되어야 한다. 2. 100명의 사용자가 동시에 신청하는 경우 ONGOING 상태를 가진 사용자가 QUEUE_LIMIT(대기열 제한수)와 같아야 ..
항해 플러스 4주차 회고
4주차 과제를 진행하면서 생긴 고민 콘서트 예약 프로젝트를 선정하고, 대기열 시스템을 구현하며 동시성 테스트를 작성했는데 통과하지 못하고 있다. 대기열 구현을 잘못한 것 같아서 지금 어떻게 해결해야 할지 고민하고 있다. 동시성 테스트 시나리오는 2가지로 구성 1. 여러 명의 사용자가 동시에 신청하는 경우 -> QUEUE_LIMIT 가 50인 경우, 100명의 사용자가 신청이 들어와도 50명의 사용자만 ONGOING 상태로 들어와야 한다. 2. 한 명의 사용자가 여러 번 신청하는 경우 -> QUEUE 테이블에 한 번만 들어와야 한다. 1. 여러 명의 사용자가 동시에 신청하는 경우 이 시나리오는 ONGOING 상태의 카운트를 QueueService가 init 되는 시점에 OngoingCount를 가지고 와서..
[Java] AtomicLong으로 동시성 문제 해결 (feat.비관적 락을 사용 하지 못한 이유)
콘서트 예매 사이드 프로젝트를 진행하면서 대기열 관련해서 개발을 진행하면서 비관적 락을 사용해서 대기열 동시성을 풀어 나가려고 했습니다. 요구사항 중 멀티 스레드 환경에서 여러 번의 요청이 들어와도 내가 정한 대기열의 인원수(QUEUE_LIMIT)만 ONGOING 상태로 저장되어야 하며, 대기열 등록 시 ONGOING 상태가 QUEUE_LIMIT 보다 크거나 같은 경우 WAIT 상태로 추가되어야 합니다. (REDIS를 사용하지 않고 대기열 문제를 풀어보고 싶어서 RDB를 사용) 대기열 등록 서비스 호출시 DB에서 ONGOING상태인 유저의 COUNT(*)를 가져와서 위에 요구사항 대로 진행하도록 구현을 하였습니다. 대기열 도메인 구현을 마친 후 마지막으로 동시성 테스트 코드를 작성하여 테스트를 돌려봤지만..
항해 플러스 3주차 회고
3주차 발제 서버구축 발제 주제를 보자마자 지금 까지는 장난이었고, 본게임이 시작되는 것 같은 느낌이었다. e-커머스 서비스, 맛집 검색 서비스, 콘서트 예약 서비스 3가지 시나리오 중 본인이 원하는 시나리오를 선택하여 프로젝트를 2주 동안 진행하게 되며, 5주 차부터 시작될 대용량 서비스 주제도 이번 프로젝트를 기반으로 리팩토링 하면서 진행하는 것 같다. 우선 나는 프로젝트 주제를 보자마자 콘서트 예약 서비스를 하고 싶었다. 코치님들이 난이도로 치면 제일 어렵다고 하셨다. 많은 걸 얻으려고 시작했기 때문에 어려운 만큼 더 많은걸 얻을 수 있지 않을까?라는 생각도 있었고 사실 평소에 친구들의 티켓팅을 자주 도와주었던 기억들이 있어서 어떻게 동작할까?라는 호기심이 컸다. 이번 주차 과제는 코딩은 없지만, ..
항해 플러스 2주차 회고
2주차 발제 주제는 아키텍처로 나에겐 정말 낯선 주제였다. 그동안 개발을 진행해 오면서 사실 아키텍처 부분에 있어서 심도 있게 고민해 본 적이 없었던 것 같다. 웹 개발을 조금이라도 배워봤으면 모두 다 알고 있는 레이어드 아키텍처 인생을 살고 있었기 때문에 당연하다는 듯이 레이어드 아키텍처를 사용해 왔다. 클린 아키텍처, 헥사고날 아키텍처는 얼핏 들어보기는 했지만 엄청난 패키지 구조를 보고 쉽게 이해하지 못했었다. (클린 아키텍처와 헥사고날 아키텍처의 차이점이 사실 아직 좀 애매한 것 같다.) 이번 주차 과제는 클린 + 레이어드 혹은 원하는 아키텍처를 선택하여 수강신청 API 를 구현하는 과제로 진행되었으며 과제를 진행하면서 정말 엄청난 일들을 경험했다. 우선 과제를 진행하기에 앞서서 이번 기회에 클린 ..
항해 플러스 1주차 회고
항해 플러스 1주차 회고 원래는 저번주에 작성했어야 하는 1주차 회고지만.. 2주차 과제를 받고 나서 2주차 과제를 해결하기 위해 나름(?) 공부를 진행하여 2주차 과제 풀이에 우선적으로 집중하느라 이제야 작성한다. 1주차 과제는 TDD 기반으로 진행하는 간단한 포인트 충전, 사용 API 과제였다. (HashMap으로 구성된 DB 구조) TDD기반 개발 경험이 없는 나는 과제 시작 전에 급하게 '테스트 주도 개발 시작하기 - 최범균', '테스트 주도 개발 - 켄트 벡' 책을 빠르게 읽고서 1주차 과제를 진행했다. (정말 다행이라고 생각) 사실 개발을 하면서 단위 테스트 와 통합 테스트의 차이를 잘 이해하지 못했다. (1차 멘토링을 받기 전까지 @SpringBootTest를 사용해서 통합 테스트만 만들었다..