실습 중심

Portfolio

포트폴리오

Resume

이력서

백엔드

6주간 매주 실전 미션을 통해 여러분의 프로젝트를 이력서에 써먹을 수 있는 경쟁력 있는 포트폴리오로 변화시키는 챌린지 과정입니다. 단순 과제 제출이 아닌, 현직자가 직접 여러분의 결과물을 리뷰하고 즉시 적용 가능한 개선점을 제시합니다. "이 정도면 면접에서 어떤 질문이 나올까?"까지 미리 대비할 수 있습니다.

딩코딩코

입문

초급

중급이상

딩코딩코 DB 무료 강의 출시 기념

자바

Java

스프링

Spring

MySQL

레디스

Redis

백엔드 6주 실전 미션과 1:1 피드백으로 완성하는 합격 포트폴리오

6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법

[0주차] 시작하기 앞서서 🏃

[1주차] 합격을 부르는 이력서의 구조 📝

[2주차] 설득력을 높이는 수치화 기술 📊

[3주차] 속도를 지배하는 DB 인덱스 ⚡

[4주차] 꼬임을 막는 트랜잭션과 락 전략 🔒

[5주차] 병목을 뚫는 서버 코드 최적화 🧠

[6주차] 부하를 견디는 서버의 비밀, Redis 🚀

백엔드 개발자로서 필수적인 개발 지식들을 깊이있게 학습하고 싶으신 분들게 강력하게 추천드립니다!

개인적으로 공부를 할 때 강의를 애용하는 편입니다. 그만큼 양질의 지식을 단시간에 습득하고 그 지식을 빠른 시간에 응용할 수 있기 때문입니다.

먼저 이런 분께 추천 드립니다. 스프링을 공부하신 분이나 스프링으로 배포 서비스를 진행할 분에게 정말 알맞는 강의입니다. 스프링에서 발생할 수 있는 성능 문제를 대학생 혹은 취준생 분들이 실제 개발 혹은 배포 환경에서 문제를 겪기는 쉽지 않을거라 생각이 듭니다. 

하지만 이 강의에서는 직접 성능 문제를 구현 해놓고 해결하는 과정을 보여줍니다. 제일 좋은 점은 개발 코드와 개발 환경이 테라폼으로 완벽히 설정돼 있기에 정말 수강생에게 필요한 지식만 전달합니다. 또한 다른 강의에서 포트폴리오 작성 시 흔히 말하는 성능 문제를 해결하고 개선 부분을 수치로 보여라 라는 이상적인 말을, 이 강의에서 직접 어떻게 성능 문제가 발생하는지, 모니터링하는지, 해결하는지를 알려줍니다.

저의 IT관련 선후배와 지인에게 공유하고 싶은 강의입니다. 돈이 전혀 아깝지 않습니다.

좋은 강의 제공해주신 덕분에 정말 큰 도움이 됐습니다. 매 주 차 강의를 볼 때마다 문제 해결 능력을 키우는 방법이 무엇인지 감탄했어요. 다음 백엔드 관련 강의도 정말 기대하고 있습니다.

강의 많이 듣는 편인데 테라폼으로 AWS 설정할 때부터 감탄하면서 강의 들었습니다.  인프런에서 백엔드개발자 강의로는 최고 아닐까 싶습니다. 

아주 간단하지만 중요한 문제해결부터 캐시에서도 복잡한 부분까지 전부 다루고 있어 정말 배울게 많고 다시 봐야겠다는 생각이 드는 강의였습니다.  이력서에 대용량 트래픽 경험에 난 뭐라고 해야하지 했는데 이 강의를 통해 충분히 극복 가능하지 않을까 생각합니다. 

이 강의 보면서 강사님의 자신감 넘치는 열정적인 강의 자세 및 꼼꼼한 준비를 보면서 느낀바도 많습니다. 아직 스스로 많이 부족한데 자신감 가지고 계속 꾸준히 노력해야겠습니다. 

아직 남은 2개 미션도 어떻게든 해서 제출하도록 하겠습니다.

좋은 강의 감사합니다.

대략적으로 알고 있는 내용들의 방향성을 잡을 수 있었습니다, 핵심과 중요한 부분만 찝어주는 밀도 높은 강의내용이 너무 알차고 공부해야지 하고 미뤄뒀던 부분을 시작할 수 있게 의지를 다시 한번 다지게 되었습니다.   내용이 알차고 개발자라면 이런방향으로 공부를해야하는구나 방향성을 잡을 수 있게 도와주는 좋은 강의입니다. 감사합니다~

차근차근 설명해주시면서 면접 시 들어올 수 있는 질문과 꼬리 질문 등에 대한 내용도 언급해주셔서 많은 도움이 됩니다.
이론으로는 알고 있었지만 질문으로 접하니 당황해서 생각나지 않는 경우가 있었는데, 해당 이론에 대해 어떤 식으로 질문이 들어올 수 있는지 대략적인 느낌을 알 수 있게 되었습니다.

현직자이지만 깊이 있게 알고 있지 못했던 캐싱 개념과 락 등 도움이 많이 되었던 강의입니다! 딩코님 열정과 에너지에 힘을 얻고 백엔드 개발자로써 성장하는데 매우 큰 자산이 되는 강의입니다! 감사합니다 ㅎㅎ

<ol><li>캐싱 대상 선정<ul><li>대시보드 홈 API: 최근 7일의 일별 통계 데이터를 보여주는 대시보드로 매번 4번에 나누어 9개 테이블에 JOIN 쿼리로 구현되어 응답시간이 3s 이상걸림, 조회는 잦은데, 하루 한번만 갱신되면 충분하다고 판단</li><li>공용 API 키: MSA 환경에서 4개의 서비스가 외부 API에 1개의 API 접근키를 공용으로 사용하여 데이터를 획득하는 상황<ul><li>API rate limit(5초 마다 호출 가능, 미준수 시 10분간 접근차단, 계정당 API키 1개 발급가능)</li><li>value에 API키 마지막 사용 시간 기록</li></ul></li></ul></li><li>개선사항<ul><li>대시보드 홈 API<ul><li>TTL: 1시간, Jitter ±10%로 설정해 cache avalanche 방지</li><li>무효화: 어제자 통계데이터가 추가되면 API 서버에서 Redis의 해당 키를 바로 DEL(명시적 무효화)</li></ul></li><li>공용 API 키<ul><li>분산 락 + Double Checked Locking으로 동시 갱신 제어</li></ul></li></ul></li><li>개선 전후 성능<ul><li>대시보드 홈 API<ul><li>p95 응답시간 약 90% 단축 (5000ms -&gt; 400ms)</li><li>DB 쿼리&nbsp; 80% 감소 (100회/분 -&gt; 20회/분)</li></ul></li></ul></li><li>Hot Key 방어 및 동시성 제어<ul><li>공용 API 키<ul><li>분산 락으로 동시 접근(사용) 제어</li></ul></li></ul></li><li>정합성<ul><li>대시보드 홈 API<ul><li>변경 횟수가 적은 데이터라 TTL 갱신만으로 충분함</li></ul></li><li>공용 API 키<ul><li>캐시 update 시 MeterRegistry를 활용하여 Grafana/Prometheus로 모니터링</li></ul></li></ul></li></ol>===== 딩코님!!6주간 정말 재밌고 이해가 쏙쏙되는 재밌는 강의였습니다!!!!(최근 인프런에서 공부했던 강의중 제일 재밌었어요!!)어려운 개념들을 이렇게 쉽게 설명하시다니 딩코님이 강의준비를 위해 신경 엄청 쓰셨다는게 느껴져서 정말 감사하고 몰입이 잘 되었습니다!!수치화를 세부적으로 어떻게 작성해야하는가에 대한 고민이 많았는데 마침 딩코님의 챌린지를 보게되서 운이 너무 좋았다는 생각이들어요!! 다시 한번 감사합니다!!앞으로도 강의 많이많이 만들어주세요!! 인프런 팔로우했습니다!! 날이 갑자기 추워졌는데 몸 조심하시고 따듯한 연말 보내시길 기원하겠습니다.&nbsp;

6주차 미션 - Redis 캐싱 전략 설계 🔥

이재영

<h3>1. N+1 / 벌크 연산 / 비동기 처리 중, 어떤 항목을 적용했고, 왜 그 부분을 선택했나요?</h3>선택 API: <code>POST /v1/orders</code> 개선 항목<ul><li>JPA N+1 문제 식별 및 해결: 주문 생성 시 장바구니에 담긴 상품 정보를 개별 조회로 인한 다중 쿼리 제거</li></ul><ul><li>벌크 연산: 주문 상품의 품목 수만큼 UPDATE 하던 재고 차감을 단일 벌크 UPDATE 또는 batchUpdate로 축소</li></ul>선택 이유 주문 생성은 세 도메인(상품, 주문, 결제)이 서로 교차되는 지점이 명확합니다. N+1, 벌크 연산을 모두 5주차 강의 내용을 중점으로 녹여낼 수 있다고 생각했습니다. <h3>2. 구체적으로 어떤 방식으로 개선(또는 적용)했나요?</h3>2.1 N+1 제거: 한 번에 필요한 상품을 모아서 조회<ul><li>문제 <code>orderItems</code> 각각에 대해 <code>productRepository.findById()</code>를 반복 → N+1 발생</li></ul><pre><code> for (CreateOrderItem req : request.items()) {
 Product p = productRepository.findById(req.productId())
 .orElseThrow(...);
 // 가격 계산
 // 재고 확인 
 // ...
}</code></pre>&nbsp;<ul><li>해결 한 번의 IN 쿼리로 모든 상품을 적재하고, Map으로 바인딩</li></ul><pre><code>List&lt;Long&gt; productIds = request.items().stream()
 .map(CreateOrderItem::productId).distinct().toList();

List&lt;Product&gt; products = productRepository.findAllByIdIn(productIds); // IN (...)
Map&lt;Long, Product&gt; productMap = products.stream()
 .collect(Collectors.toMap(Product::getId, Function.identity()));</code></pre>&nbsp;2.2 벌크 재고 차감: 한 방에 업데이트<ul><li>개선 목표: 품목 N개일 때 UPDATE N회를 → 1회 또는 최소한 횟수로!</li><li>해결 방법: <code>JdbcTemplate.batchUpdate</code></li></ul><pre><code>jdbcTemplate.batchUpdate(
 "UPDATE product SET stock = stock - ? WHERE id = ? AND stock &gt;= ?",
 orderItems, orderItems.size(),
 (ps, item) -&gt; {
 ps.setInt(1, item.quantity());
 ps.setLong(2, item.productId());
 ps.setInt(3, item.quantity());
 }
);</code></pre>새로운 문제 발생: 하지만 벌크 연산은 JPA 1차 캐시와 동기화되지 않는 문제가 새롭게 발생했습니다. 이 문제를 단순히 극복하기 보다 최적화를 위해 좀 더 고민해야 할 것 같습니다.&nbsp;<h3>3. 모니터링(또는 로그) 결과, 개선 전후 무엇이 얼마나 좋아졌나요?</h3>실습 환경<ul><li>Spring Boot 3.5.6, JPA/QueryDSL, Java 21, AWS t3.small, MySQL 8.0</li></ul>측정 방법<ul><li>SQL: Hibernate SQL 로그 + p6spy(쿼리 카운트/소요)&nbsp;</li><li>메트릭: Micrometer → Prometheus → Grafana 대시보드</li><li>부하: k6/JMeter로 동시 30VU, 1분 시나리오 (장바구니 3~5품목)</li></ul>응답 개선<ul><li>평균 응답 시간: <code>420ms</code> → <code>190ms</code></li><li>P95: <code>880ms</code> → <code>360ms</code> &nbsp;</li><li>P99: 1.6초 → <code>720ms</code> </li></ul>P95 기준으로 대략 60% 단축했습니다.쿼리 발생 수(주문 1건, 품목 4개 기준)<ul><li>개선 전: 상품 조회 4회 + 가격, 옵션 등 총 ~18회 쿼리 발생</li><li>개선 후: 상품 1회(<code>IN</code>) + 재고 벌크 1회 + 주문/아이템 저장 2~3회 → 6회 쿼리 발생</li></ul>18회 쿼리 발생에서 6회 쿼리 발생으로 쿼리 수 66% 감소했습니다.&nbsp;&nbsp;<h3>4. 개선 과정에서 겪은 문제나 고려해야 할 사항은 무엇이었나요?</h3>벌크 연산과 1차 캐시 불일치 문제를 극복하기 위해 벌크 UPDATE 이후 <code>EntityManager.clear()</code> 또는 해당 엔티티만 재조회가 필요합니다. 그리고 상품 재고 경쟁이 심한 경우도 고려해야 되는데, 4주차에 학습한 락을 활용할 수 있을 것이라고 생각했습니다. 재고 경쟁이 심하다면 비관적 락을 선택합니다. 그러나 트래픽이 많지만 충돌 빈도가 낮으면 낙관적 락과 함께 버전을 추가하고 재시도를 선택할 수 있을 것으로, 시나리오에 따라 락을 선택하는 방법을 생각했습니다.

5주차 미션 - 서버 성능 최적화 (N+1/벌크/비동기) 🔥

optional94

<ol><li>개선 항목 선택<ul><li>외부 api 호출을 통해 전사 자원을 refresh 하는 api에서 bulk 연산 문제가 의심되어 최적화 진행</li></ul></li><li>개선 방법<ul><li>Refresh 작업 일부(외부 API 호출)를 @Async로 분리하여 병렬 조회 처리</li><li>DB업데이트 시 dbcTemplate batchUpdate() 활용하여 bulk update(insert)</li><li>Hibernate의 StatementInspector를 이용해 실제 실행되는 쿼리 모니터링</li></ul></li><li>개선 전후 결과<ul><li>Refresh 시 update/insert 쿼리 수 1/10로 감소, 쿼리 수행 시간 5s → 750ms로 단축</li><li>refresh 작업(1500 건 update)은 JdbcTemplate batchUpdate 사용 후 15초 → 5초로 단축</li><li>@Async 적용 후 p95 응답 시간 1분 → 15초 수준으로 개선</li></ul></li><li>주의사항<ul><li>외부 API 조회요청 시 과도한 요청을 하지 않도록 병렬 조회 수 조절 필요</li><li>비동기 로직에서 예외 처리(CompletableFuture 예외)와 스레드 풀 모니터링이 필요</li></ul></li></ol>

5주차 미션 - 서버 성능 최적화 (N+1/벌크/비동기)

<h3>1. “현재 프로젝트에서 동시성 문제가 발생할 가능성이 있는 시나리오는 무엇인가요?”</h3><ul><li>주문 시 상품 재고 차감</li></ul>여러 사용자가 동시에 같은 상품을 주문할 때 재고가 0개인데도 주문이 완료되거나, 재고가 1개 남았을 때 동시에 여러 주문이 발생하여 재고가 마이너스가 되는 동시성 문제가 발생할 수 있습니다. <h3>2. “동시성 제어(트랜잭션 Isolation, Lock, Optimistic Lock 등)를 적용한다면, 어떤 방법을 고려해볼 수 있을까요?” </h3>재고 데이터를 읽는 시점에 <code>SELECT ... FOR UPDATE</code> 구문 혹은 <code>@Lock(LockModeType.PESSIMISTIC_WRITE)</code> 을 사용하여 해당 레코드에 배타 락을 겁니다. 이렇게 하면 다른 트랜잭션은 해당 락이 해제될 때까지 대기해야 하므로 데이터의 정합성을 확실하게 보장할 수 있습니다.이때 비관적 락의 단점인 교착 상태(Deadlock)를 극복하기 위해 정책을 중심으로 애플리케이션 레벨에서 극복합니다. 재고 차감과 락이 반드시 필요한 핵심 비즈니스 로직의 트랜잭션 범위를 최소 범위로 묶은 후에 쿼리 수준에서 락 대기 시간(<code>innodb_lock_wait_timeout</code>)을 대략 3~5초로 설정하고 데드락이 감지되면 강제로 롤백하여 3회 재시도 후에도 실패하면 사용자에게 적절한 피드백을 제공합니다. 주문 내역 스냅샷 생성, 구매 내역 알림 발송 등은 다른 트랜잭션으로 분리 혹은 비동기 처리합니다.<ul><li>트랜잭션 1: 상품 재고 차감<code>SELECT ~ FOR UPDATE</code> + <code>UPDATE</code> 쿼리 수행)</li><li>트랜잭션 1 COMMIT 수행</li><li>트랜잭션 2: 주문 정보 테이블(<code>orders, order_items</code>) 에 데이터 삽입</li><li>비동기 처리: 구매 내역 알림 발송</li></ul>최소 범위 트랜잭션 + 락 대기 시간 설정과 주문 재시도를 통해 락을 점유하는 시간이 매우 짧아져 데드락 발생 확률을 크게 낮출 수 있을 것으로 기대할 수 있지만, 데드락 발생 여지가 존재합니다. 데드 락을 원천 차단하기 위해서 데이터베이스 트랜잭션 락에 의존하지 않고, 애플리케이션 레벨에서 먼저 잠금을 획득합니다. Redis의 원자적 명령으로 분산 락을 사용하거나 요청을 한 줄로 아예 세워버리는 메시지 큐 방식인 Kafka를 떠올릴 수 있습니다.하지만 제 수준에서는 4주차 학습 내용을 중점으로 Transaction, Lock, Multi Thread &amp; Concurrency, @scheduled, @Version, Facade Pattern, Spring Event, 동시성 이슈 테스트 및 모니터링 보는 방법에 대한 학습을 목표로 하고 있습니다. <h3>3. “트랜잭션 범위를 어떻게 설정하고, 트랜잭션 내에서 불필요한 작업(예: 외부 API 호출)을 제거할 수 있을까요?” </h3>이벤트 기반 관심사 분리를 할 수 있습니다. 4주차 수업에서 설명해주신 이벤트 기반(Event-Driven) 아키텍처로 핵심 로직과 부가 기능을 분리할 수 있습니다.&nbsp;<h3>4. “동시성 이슈를 테스트하거나, 개선 전후를 어떻게 측정·검증할 계획인가요?</h3>4주차 수업에서 설명해주신 것과 동일하게 부하 테스트 시나리오를 K6 스크립트로 작성하고, 동시성 제어 로직 적용 여부에 따른 개선 전후의 시스템 성능을 측정하고 비교 분석합니다. 관측 비교 대상으로 데이터 정합성, TPS, Latency, Error Rate, P95, P99 등을 지표로 정합니다.이후 모니터링으로 예기치 않은 병목 혹은 문제가 발생하는지 관찰합니다.&nbsp;&nbsp;&nbsp;

4주차 미션 - 트랜잭션 & 동시성 제어 🔥

<ol><li>“현재 프로젝트에서 동시성 문제가 발생할 가능성이 있는 시나리오는 무엇인가요?”<ul><li>동시에 여러 사용자가 같은 상품을 주문할 때 재고가 음수가 된다</li></ul></li><li>“동시성 제어(트랜잭션 Isolation, Lock, Optimistic Lock 등)를 적용한다면, 어떤 방법을 고려해볼 수 있을까요?”<ul><li>비관적 락: @Lock(LockModeType.PESSIMISTIC_WRITE)<ul><li>장점: 배타락을 사용하여 확실한 동시성 제어 보장 가능하다. 충돌이 자주 발생하는 경우 낙관적 락보다 성능이 좋다.</li><li>문제점: 한번에 하나의 트랜잭션만 접근 가능하기 때문에 동시성이 떨어져 전체 처리에 소요되는 DB 리소스, 소요 시간이 늘어난다.</li></ul></li><li>낙관적 락: @Lock(LockModeType.OPTIMISTIC)<ul><li>장점:version 정보를 활용하여 update 하기 때문에 비관적 락보다 전체 처리 소요시간이 짧다.</li><li>문제점:&nbsp;fk가 설정되어 있는 컬럼에 대해 공유락이 발생하여 다른 트랜잭션의 배타락과 겹칠 경우 dead lock 발생 가능성이 있다. 버전 충돌이 자주 발생하게 되면 다른 트랜잭션과 함께 롤백되어 정상적으로 처리되지 않을 가능성이 있다, 따라서 재시도 로직(facade) 및 로깅을 신경 써주어야 한다.</li></ul></li><li>네임드 락: GET_LOCK(), RELEASE_LOCK()<ul><li>장점: 특정 레코드가 아닌 리소스(행위)에 대해 잠금 제공 가능하다. 분산 환경에서도 사용 가능하다.</li><li>단점: 로직상 트랜잭션이 완료되기 전 다른 트랜잭션에서 네임드락을 획득하여 사용할 수 있어 REQUIRES_NEW 전파속성을 활용하여 내부 트랜잭션으로 네임드락을 commit 해주어야 한다, 이 과정에서 커넥션을 2개 사용하게 되어 관리가 필요하다.</li></ul></li></ul></li><li>“트랜잭션 범위를 어떻게 설정하고, 트랜잭션 내에서 불필요한 작업(예: 외부 API 호출)을 제거할 수 있을까요?”<ul><li>문제: 기존 시스템에서는 자원 관리를 위한 별도의 서비스 A와 전사 결재 문서를 생성하는 서비스 B가 존재하고 있음, 자원 사용 승인을 위해 B에 요청 시 실패하게되면 A에서 입력한 결재 문서 데이터가 생성되지 않는 문제 발생.</li><li>개선:<ul><li>트랜잭션 범위 조정 및 분리<ul><li>요청 후 정상 응답 시 데이터 저장 -&gt; 결재 문서 생성 요청 시 DB에 결재 요청 데이터를 저장</li><li>저장된 데이터를 바탕으로 외부 API 요청</li></ul></li><li>외부 API 요청 후 정상 생성 여부를 비동기적으로 보정하기 위한 후보정 로직 도입.&nbsp;<ul><li>SpringEvent를 사용하여 정상 응답 시 사용자에게 알람 메일 발송하도록 개선</li><li>스케쥴러를 활용하여 저장된 요청 데이터로 결재 문서 생성 status를 체크하여 정상생성될 때까지 retry 결과적 일관성 확보&nbsp;</li></ul></li></ul></li><li>결과:<ul><li>SpringEvent를 활용하여 비즈니스 로직과 부가기능 분리</li><li>네트워크 장애나 API 응답 누락이 발생하여도 문서 생성 프로세스에는 영향 없음</li><li>트랜잭션 범위를 조정하여 외부API 응답과는 상관없이 입력 데이터 유실없는 사용자 경험 개선&nbsp;</li></ul></li></ul></li><li>“동시성 이슈를 테스트하거나, 개선 전후를 어떻게 측정·검증할 계획인가요?”<ul><li>k6, JMeter를 활용한 TPS 100이상 부하 테스트를 통하여 CPU, 메모리, DB커넥션 사용시간 비교</li><li>실패 요청으로 인입되는 cs 감소 수치화</li><li>생성 요청 시 소요되는 시간 감소 (10s -&gt; 3s)</li></ul></li></ol>

4주차 미션 - 트랜잭션 & 동시성 제어

<h1>성능 개선 과제 제출</h1>&nbsp;<h1>들어가기에 앞서</h1>들어가기에 앞서, 장바구니에 담긴 10개의 상품을 하나의 주문으로 구매하는 경우를 가정하고 진행하였습니다. 또한 k6그래프와 k6 로고의 차이가 있어 모든 테스트는 로그를 바탕으로 해석했으니 참고바랍니다 😀&nbsp;그리고 코드 개선 전 10개의 상품을 주문하는 1000명의 가상 사용자를 바탕으로 측정한 K6 테스트 결과입니다.<img src="https://cdn.inflearn.com/public/files/posts/11f12760-29d1-46c0-b42f-b9d691dd572b/fd9733ba-ca14-41c0-98d9-a26e430930f6.png" media-type="img" alt="image.png" title="image.png" width="527" height="260"><pre><code class="language-shell"> HTTP
 http_req_duration..............: avg=32.48s min=0s med=36.83s max=52.55s p(90)=41s p(95)=42.13s
 { expected_response:true }...: avg=35.71s min=230.58ms med=36.98s max=52.55s p(90)=41.14s p(95)=42.61s
 http_req_failed................: 9.04% 844 out of 9329
 http_reqs......................: 9329 28.273064/s</code></pre><ul><li>평균 tps :&nbsp; 약 28.27/s&nbsp; </li><li>평균 latency : 약 35.71s</li></ul>&nbsp;&nbsp;<h2>1. N+1 / 벌크 연산 / 비동기 처리 중, 어떤 항목을 적용했고, 왜 그 부분을 선택했나요?</h2>N+1 문제 해결과 벌크 연산(배치 처리) 두 가지를 적용했습니다.먼저 N+1 문제를 선택한 이유는, 10개 상품 주문 시 Variant 조회를 위해 10번의 개별 DB 조회가 발생하는 명확한 병목을 발견했기 때문입니다. 이는 네트워크 왕복 횟수를 직접적으로 증가시켜 성능 저하의 주요 원인이었습니다.&nbsp;벌크 연산은 세 곳에 적용했습니다:<ul><li>OrderItems 저장: 10개 상품을 10번의 개별 INSERT 대신 1번의 배치 INSERT로 처리</li><li>재고 감소: 리스트로 구매하려는 상품을 DB에 넘겨서 한 번의 DB 엑세스로 10번의 개별 UPDATE를 활용한 재고 감소</li><li>Variant 조회: N+1 해결의 일환으로 IN 절을 사용한 배치 조회</li></ul>비동기 처리도 시도했으나, 테스트 결과 2.25%의 미미한 개선만 있었고 오히려 스레드 생성 비용, 컨텍스트 스위칭, 동기화 비용 등의 오버헤드가 더 크게 작용했습니다. 작업 시간이 짧은(15ms 내외) 경우 비동기의 이점이 없다는 것을 확인하고 동기 방식으로 유지했습니다.<hr><h2>2. 구체적으로 어떤 방식으로 개선(또는 적용)했나요?</h2><h3>2-1. N+1 문제 해결 (Variant 조회)</h3>개선 전:<pre><code class="language-java">for (ProductLine productLine : request.getProduct()) {
 ProductVariantDto variant = productVariantRepository.findProductVariantByOptionName(
 productLine.getProductId(),
 productLine.getOptionName()
 );
 // 10번의 개별 SELECT 쿼리 발생
}
</code></pre>개선 후:<pre><code class="language-java">// 1. 배치 조회
List&lt;ProductVariantDto&gt; variants = productVariantRepository
 .findProductVariantsByOptionNames(request.getProduct());

// 2. HashMap으로 변환 (O(1) 조회)
Map&lt;String, ProductVariantDto&gt; variantMap = new HashMap&lt;&gt;();
for (ProductVariantDto variant : variants) {
 String key = variant.getProductId() + "_" + variant.getVariantName();
 variantMap.put(key, variant);
}

// 3. 각 상품에 매핑
for (ProductLine productLine : request.getProduct()) {
 String key = productLine.getProductId() + "_" + productLine.getOptionName();
 ProductVariantDto variant = variantMap.get(key);
 // 설정...
}
</code></pre>MyBatis XML (IN 절 사용):<pre><code class="language-xml"> &lt;select id="findProductVariantsByOptionNames" resultType="com.avengers.musinsa.domain.product.dto.response.ProductVariantDto"&gt;
 SELECT
 product_variant_id as productVariantId,
 product_id as productId,
 variant_name as variantName,
 price as price,
 stock_quantity as stockQuantity,
 size_value as sizeValue,
 color_value as colorValue,
 material_value as materialValue,
 extra_price as extraPrice
 FROM product_variants
 WHERE (product_id, variant_name) IN
 &lt;foreach collection="products" item="product" open="(" close=")" separator=","&gt;
 (#{product.productId}, #{product.optionName})
 &lt;/foreach&gt;
 &lt;/select&gt;
&lt;/mapper&gt;</code></pre><h3>2-2. OrderItems 배치 INSERT</h3>개선 전:<pre><code class="language-java">for (ProductLine product : request.getProduct()) {
 orderRepository.createOrderItems(orderId, product, couponId);
 // 10번의 개별 INSERT
}
</code></pre>개선 후:<pre><code class="language-java">// 1번의 배치 INSERT
orderRepository.batchCreateOrderItems(orderId, request.getProduct(), couponId);

</code></pre>MyBatis XML (UNION ALL 사용):<pre><code class="language-xml"> &lt;insert id="batchCreateOrderItems"&gt;
 INSERT INTO ORDER_ITEMS
 (ORDER_ITEM_ID, PRODUCT_ID, COUPON_ID, ORDER_ID, QUANTITY,
 UNIT_PRICE, TOTAL_PRICE, DISCOUNT_RATE, DISCOUNTAMOUNT,
 COLOR, ORDIER_ITEM_SIZE)
 SELECT
 SEQ_ORDER_ITEMS.NEXTVAL,
 A.*
 FROM (
 &lt;foreach collection="orderProducts" item="product" separator="UNION ALL"&gt;
 SELECT
 #{product.productId, jdbcType=NUMERIC} as product_id,
 #{couponId, jdbcType=NUMERIC} as coupon_id,
 #{orderId, jdbcType=NUMERIC} as order_id,
 #{product.quantity, jdbcType=NUMERIC} as quantity,
 #{product.finalPrice, jdbcType=NUMERIC} as unit_price,
 #{product.totalPrice, jdbcType=NUMERIC} as total_price,
 #{product.discountRate, jdbcType=NUMERIC} as discount_rate,
 #{product.productDiscountAmount, jdbcType=NUMERIC} as discount_amount,
 #{product.color, jdbcType=VARCHAR} as color,
 #{product.orderItemSize, jdbcType=VARCHAR} as order_item_size
 FROM DUAL
 &lt;/foreach&gt;
 ) A
 &lt;/insert&gt;

</code></pre><h3>2-3. 재고 감소 배치 UPDATE</h3>개선 전:<pre><code class="language-java">for (ProductLine product : request.getProduct()) {
 productVariantRepository.decrementStock(
 product.getVariantId(), 
 product.getQuantity()
 );
 // 10번의 개별 UPDATE
}
</code></pre>개선 후:<pre><code class="language-java">productVariantRepository.batchDecrementStock(request.getProduct());
// 1번의 배치 UPDATE
</code></pre>MyBatis XML (CASE WHEN 사용):<pre><code class="language-xml"> &lt;update id="batchDecrementStock"&gt;
 &lt;foreach collection="products" item="product" open="BEGIN" close="END;" separator=""&gt;
 UPDATE PRODUCT_VARIANTS
 SET stock_quantity = stock_quantity - #{product.quantity}
 WHERE product_variant_id = #{product.variantId}
 AND stock_quantity &gt;= #{product.quantity};
 &lt;/foreach&gt;
 &lt;/update&gt;</code></pre><hr><h2>3. 모니터링(또는 로그) 결과, 개선 전후 무엇이 얼마나 좋아졌나요?</h2><h3>3-1. 단위 테스트 결과 (1,000개 주문, 각 주문당 10개 상품)</h3><img src="https://cdn.inflearn.com/public/files/posts/7e1e153e-ef5c-4efc-a44d-ecfaf002d807/d3494e11-1b9a-4143-bb76-dce6481f1ccd.png" media-type="img" alt="image.png" title="image.png" width="318" height="165">&nbsp;전체 주문 프로세스:<ul><li>개선 전: 122,861ms</li><li>개선 후: 74,627ms</li><li>개선율: 39.34% (48,234ms 단축)&nbsp;</li></ul>세부 개선 내역:<img src="https://cdn.inflearn.com/public/files/posts/e563b8b3-b50d-4912-a663-f410603838e0/162ff8c7-ddb5-479f-be6f-67df08f31100.png" media-type="img" alt="image.png" title="image.png" width="527" height="136">(테스트 코드와 결과 모두 있지만, 너무 길어질까봐 사진을 첨부하지는 않았습니다.)&nbsp;<h3>3-2. k6 부하 테스트 결과 (1,000 VUs, 5분)</h3>성능 지표:<ul><li>TPS: 28.27/s → 29.75/s (약 5.2% 개선)</li><li>Latency (평균): 35.71s → 33.18s (약 7.1% 개선, 2.53초 단축)</li><li>HTTP 요청 실패율: 9.04% → 7.20% (안정성 향상)</li></ul>VUs 그래프 안정성: 개선 후 가상 사용자 처리 패턴이 더욱 일관되고 안정적으로 변화&nbsp;<h3>3-3. DB 접근 횟수 개선</h3>10개 상품 주문 시:<ul><li>개선 전: 총 32번 DB 왕복 (Variant 10번 + OrderItems 10번 + 재고 감소10번 + 배송정보 생성 + order 생성)</li><li>개선 후: 총 5번 DB 왕복 (Variant 1번 + OrderItems 1번 + 재고 1번 + 기타 2번 + 배송정보 생성 + order 생성)&nbsp;</li></ul><hr><h2>4. 개선 과정에서 겪은 문제나 고려해야 할 사항은 무엇이었나요?</h2><h3>4-1. 비동기 처리의 한계</h3>시도: OrderItems 저장과 재고 감소를 <code>@Async</code>로 병렬 처리결과: 2.25%의 미미한 개선원인 분석:<ul><li>스레드 생성/소멸 비용 (1,000번 반복 × 2개 = 2,000개 스레드)</li><li>컨텍스트 스위칭 오버헤드</li><li><code>CompletableFuture.allOf().join()</code>의 동기화 비용</li><li>실제 작업 시간(15ms)보다 오버헤드(5~7ms)가 상대적으로 큼</li></ul>결론: 작업 시간이 짧은 경우 비동기의 이점이 없으며, 오히려 동기 + 배치 처리가 더 효과적임을 확인할 수 있었습니다.&nbsp;<h3>4-3. Oracle DB의 특성</h3>문제: 배치 UPDATE 시 세미콜론(;)으로 여러 UPDATE를 구분할 수 없다는 에러 발생해결: <code>BEGIN ... END;</code> 블록을 사용&nbsp;문제: MyBatis에서 null 값 처리 시 <code>jdbcType</code> 미지정으로 인한 Oracle 호환성 에러해결: XML에서 모든 파라미터에 <code>jdbcType</code> 명시&nbsp;<h3>4-4. 코드 개선과 실제 성능의 괴리</h3><img src="https://cdn.inflearn.com/public/files/posts/d68c62b0-906f-4984-9617-8ad96095bdd7/811a8859-f58a-4884-8594-805013b3ea55.png" media-type="img" alt="image.png" title="image.png" width="527" height="258"><pre><code class="language-shell"> HTTP
 http_req_duration..............: avg=30.79s min=0s med=34.8s max=55.23s p(90)=38.65s p(95)=41.09s
 { expected_response:true }...: avg=33.18s min=734.14ms med=34.9s max=55.23s p(90)=38.76s p(95)=41.19s
 http_req_failed................: 7.20% 707 out of 9818
 http_reqs......................: 9818 29.750433/s</code></pre>현상: 코드 레벨에서 39% 개선되었으나, k6 테스트에서는 TPS 5%, Latency 7% 개선에 그침원인:<ul><li>로컬 환경 한계 (네트워크 지연 거의 없음)</li><li>DB 커넥션 풀 부족</li><li>단일 서버의 CPU/메모리 한계</li><li>병목이 애플리케이션 코드가 아닌 인프라에 존재</li></ul>교훈: 코드 최적화만으로는 TPS/Latency를 획기적으로 개선하기 어렵다는 사실을 알 수 있었습니다. 실제 운영 환경(애플리케이션-DB 물리적 분리)에서는 배치 처리의 효과가 더 클 것으로 예상되며, 큰 성능 향상을 위해서는 인프라 레벨의 개선(수평적 확장, 캐싱, DB 최적화 등)이 필수적임을 배울 수 있었습니다.&nbsp;<h3>4-5. 트랜잭션 관리의 복잡성</h3>고민: Variant 조회를 트랜잭션 밖으로 빼서 범위를 줄일까?결론: 유지하기로 결정이유:<ul><li>Variant 조회는 단순 SELECT로 실질적 성능 이득이 크지 않음</li><li>오히려 커넥션을 2번 획득하는 오버헤드 발생 가능</li><li>주문 생성, OrderItems 저장, 재고 감소는 반드시 하나의 원자적 작업이어야 함 (데이터 정합성)</li></ul>교훈: 트랜잭션 범위는 짧을수록 좋다는 일반론보다, 비즈니스 요구사항(데이터 정합성)이 우선입니다.&nbsp;<h3>4-6. 측정의 중요성</h3>이번 프로젝트를 통해 "측정하지 않으면 개선할 수 없다"는 것을 체감했습니다. 막연한 추측이 아닌 실제 측정 결과를 바탕으로 의사결정을 내려야 하며, 모든 상황에 적용되는 만능 해결책은 없다는 것을 배웠습니다.

N+1 / 벌크 연산 / 비동기 처리

최민영

&nbsp;<ol><li>“현재 프로젝트에서 동시성 문제가 발생할 가능성이 있는 시나리오는 무엇인가요?”&nbsp;쇼핑몰에서 선착순 100명에게 할인 쿠폰을 제공하는 경우 쿠폰이 99개인 경우에 다수의 스레드가 모두 쿠폰의 갯수를 99개에서 조회를 해서 해당 유저의 쿠폰 데이터를 생성해주게 되면 100개를 넘기는 상황이 발생한다.&nbsp;&nbsp;&nbsp;&nbsp;</li><li>“동시성 제어(트랜잭션 Isolation, Lock, Optimistic Lock 등)를 적용한다면, 어떤 방법을 고려해볼 수 있을까요?”</li></ol><ul><li>synchronized - 1대인 경우 1개의 스레드만 작업하게 하므로 해결 가능할 수 있으나, 서버가 여러 대가 되는 경우 다시 같은 경쟁 상태가 일어나게 됨</li><li>비관적 락, 낙관적 락 - 비관적 락은 충돌이 자주 발생하여 성능에 문제가 있고, 낙관적 락은 충돌이 자주 발생하는 경우에 retry가 자주 발생하여 오히려 속도가 떨어질 수 있음</li><li>redis 를 활용- 레디스 싱글스레드이므로 레디스가 쿠폰 갯수를 관리하도록 한다.<ul><li>하지만 쿠폰의 갯수가 100개 아니라 10000개인 경우 데이터베이스에 부하를 주게 됩니다. 다른 서비스도 사용하는 데이터베이스였다면 다른 서비스에도 장애를 줄 수 있습니다.</li><li>이런 경우에는 쿠폰 생성을 카프카와 같은 메시지 큐를 활용하여 쿠폰 생성을 메시지를 카프카로 보내고 컨슈머가 이를 처리하도록 하여, 처리량을 조절할 수 있게 하여 데이터베이스의 부하를 줄여줍니다.&nbsp;</li><li>만약 쿠폰을 발급을 처리하는 중에 에러가 발생하여 쿠폰 발급 갯수의 정합성이 맞지 않는다면 예외처리하여 실패한 경우의 이벤트를 데이터베이스에 기록하고 schduled task 로 주기적으로 실패한 이벤트를 조회하여 쿠폰 발급의 정합성을 맞춰줍니다. </li></ul></li></ul>&nbsp;<ol start="3"><li>“트랜잭션 범위를 어떻게 설정하고, 트랜잭션 내에서 불필요한 작업(예: 외부 API 호출)을 제거할 수 있을까요?”&nbsp;</li></ol><ul><li>트랜잭션에 불필요한 외부 API 호출 등이 포함된 경우 트랜잭션 수행시간만 길어지므로 DB 커넥션 풀을 DB 작업에만 트랜잭션이 한정되도록 범위 설정 하고API 호출은 트랜잭션 밖에서 이루어지도록 함</li><li>구현은 facade 패턴을 활용하여 로직을 순차적으로 구현&nbsp;</li></ul><ol start="4"><li>“동시성 이슈를 테스트하거나, 개선 전후를 어떻게 측정·검증할 계획인가요?”</li></ol><ul><li>ngrinder, k6 등으로 부하테스트를 진행하여 개선 전후를 grafana, AWS cloud watch 등으로 지표를 확인하여 이를 기록한다.</li></ul>

아라레

<ol><li>현재 프로젝트에 사용자가 400명 이상으로 증가하면 어떤 문제가 발생할까요?&nbsp;</li></ol>: 트래픽이 증가하여 서버에 과부하가 발생하고, 응답 시간이 느려지거나 서비스가 중단될 수 있음.: 많은 사용자의 데이터가 증가하면서 데이터베이스가 성능 저하되거나 데이터 일관성이 깨질 수 있음<ol start="2"><li>현재 제공하던 기능에서 추가로 제공될만한 기능이 있다면 뭐가 있을까요? 해당 기능을 제공하려면 어떤 변화가 필요할까요?</li></ol><ul><li>추가 기능</li></ul>: 게시판 댓글 기능<ul><li>기능 제공을 위한 변화</li></ul>(1) 댓글 테이블 추가 및 게시글 테이블 연관관계 생성: 기존 데이터베이스 테이블 구조를 변경 및 재설계 필요(2) 유저 기반 구조로 변경: 댓글 작성 및 관리 권한을 유저에게 부여하는 구조로 전환<ol start="3"><li>현재 프로젝트에 예상보다 많은 사용자가 유입된다면 저희는 어떤걸 공부해야 할까요?</li></ol>: 빠른 검색을 위한 elasticSearch 시스템 학습 필요: 데이터를 빠르게 불러오기 위한 Redis 캐싱처리 학습 필요

2주차 미션 - 프로젝트 확장성 분석 🔥

2주차 미션 제출 - 프로젝트 확장성 분석

밤의멜로디

<h1>1. “현재 프로젝트에서 동시성 문제가 발생할 가능성이 있는 시나리오는 무엇인가요?”</h1>&nbsp;<h2>1-1. 브랜드 또는 상품 좋아요 누르기</h2><ul><li>현재 브랜드 테이블에 likeCnt 속성과 상품테이블에 likeCnt 속성이 있음</li><li>그리고 유저와 브랜드 / 유저와 상품 테이블 모두 다대다 관계여서 중간테이블을 둔 상태</li><li>현재 트랜잭션 및 동시성 제어를 고려한 코드 작성이 안돼있어서</li><li>멀티 스레드 환경에서 여러 사용자가 동시에 좋아요를 누르게 된다면</li><li>중간테이블에는 좋아요를 사용자의 좋아요 이력이 Insert 되나,&nbsp;</li><li>현재 브랜드랑 상품테이블의 liekCnt 속성 업데이트 방식이&nbsp;</li><li>기존의 likeCnt + 1 로 업데이트 하는 방식이라서 LostUpdate 발생 가능성 있음</li></ul>&nbsp;<h2>1-2 중복 상품이 장바구니에 추가되는 부분</h2><ul><li>해당 부분은 요구사항에 따라 달라지는 부분임<ul><li>장바구니에 동일한 상품이 있을 경우 장바구니 추가를 막는 로직</li><li>동일한 상품이 장바구니에 존재하는 경우,&nbsp; 장바구니에 상품 추가를 막고, 장바구니에 존재하는 상품의 개수를 증가시키는 로직(해당 프로젝트에 사용하는 방식)</li></ul></li><li>그러나 해당 프로젝트 요구사항을 기준으로 분석해보겠음</li><li>유저가 장바구니에 동일 상품, 동일 옵션을 동시에 두 번 추가하면</li><li>기존 장바구니에 해당 상품이 2개 있다고 가정&nbsp;<ul><li>첫 번째: "3개 추가" 버튼 클릭&nbsp;</li><li>두 번째: 바로 또 "3개 추가" 버튼 클릭 (첫 번째 요청이 완료되기 전)&nbsp;</li><li>→ 서버에 거의 동시에 2개 요청 도착</li><li>우리가 원하는 건 동일한 상품에 대해 총 8개에 대한 상품이 추가되는 것이 목표인데, 5개로 조정됨</li><li>LostUpdate 문제</li></ul>&nbsp;</li></ul><hr><h1>2. “동시성 제어(트랜잭션 Isolation, Lock, Optimistic Lock 등)를 적용한다면, 어떤 방법을 고려해볼 수 있을까요?”</h1>&nbsp;<h2>2-1</h2>[문제상황]여러 사용자가 동시에 같은 브랜드나 상품에 좋아요를 누를 때, 중간테이블에는 좋아요 이력이 정상적으로 들어가지만, 메인 테이블의 likeCnt가 실제보다 적게 업데이트되는 문제&nbsp;[해결책] - 비관적 락<ul><li>이유 : 좋아요는 사용자 경험상 즉시 반영되어야 하며, 정확성이 매우 중요한 특성임</li><li>적용 방식 : 브랜드나 상품 정보를 조회할 때 FOR UPDATE를 사용해서 다른 트랜잭션이 접근 못하게 막기</li><li>장단점 : 100% 정확한 결과를 보장하지만, 약간의 대기시간이 발생할 수 있음. 그러나 좋아요 처리 로직은 오래 걸리는 작업이 아니라고 생각해 충분히 도입 가능하다고 판단.</li></ul>&nbsp;<h2>2-2&nbsp;</h2>[문제상황]같은 사용자가 동일한 상품을 빠르게 연속으로 장바구니에 추가할 때, 실제로는 6개를 추가했는데 3개만 추가되는 것처럼 보이는 문제&nbsp;[해결책] - unique 제약조건 + merge문 + 자바 예외처리<ul><li>현재 프로젝트에서 오라클 사용하여 오라클 Merge 문 사용</li></ul>&nbsp;UNIQUE 제약조건:<ul><li>중간 테이블에 user_id와 product_variant_id 조합의 UNIQUE 제약 추가</li></ul>&nbsp;MERGE 문 활용:<ul><li>기존: 자바에서 조회 → 계산 → 업데이트 3단계 분리로 Lost Update 발생</li><li>개선: SQL 에서&nbsp; MERGE 문으로 "존재하면 수량 증가, 없으면 추가"를 한 번의 쿼리로 처리</li></ul>&nbsp;동시성 보장 원리<ul><li>동시에 같은 상품 추가 시도 시, 오라클의 UNIQUE 인덱스 락에 의해 순차 처리됨</li></ul><ul><li>첫 번째: 락 획득 → INSERT 성공</li><li>두 번째: 락 대기 → 중복 키 발견 → 예외 발생 → UPDATE로 수량만 증가</li></ul>&nbsp;장점: 대부분 한 번에 성공, 드문 충돌은 인덱스 락으로 순차 처리 보장이유: UNIQUE 제약조건 + 인덱스 락이 "동시 실행"을 "순차 실행"으로 자동 변환&nbsp;<hr><h2>3. "트랜잭션 범위를 어떻게 설정하고, 트랜잭션 내에서 불필요한 작업(예: 외부 API 호출)을 제거할 수 있을까요?"</h2><h3>3-1. 현재 프로젝트의 트랜잭션 범위 문제점</h3>분석 대상 코드: 좋아요 기능<pre><code class="language-java">@Transactional
public BrandLikeResponse BrandLikeToggle(Long userId, Long brandId) {
 UserBrandStatus status = brandRepository.getUserBrandStatus(userId, brandId); // ❌ 
 
 if(status == null) {
 brandRepository.insertUserBrandLike(userId, brandId);
 brandRepository.plusBrandLikeCnt(brandId);
 return brandRepository.getIsLikedBrand(userId, brandId);
 } else {
 Integer currentLiked = status.getLiked();
 brandRepository.switchBrandLike(userId, brandId);
 
 if (currentLiked != null &amp;&amp; currentLiked == 1) {
 brandRepository.minusBrandLikeCnt(brandId);
 } else {
 brandRepository.plusBrandLikeCnt(brandId);
 }
 return brandRepository.getIsLikedBrand(userId, brandId); // ❌ 
 }
}
</code></pre>문제점:<ul><li>불필요하게 긴 트랜잭션 범위 (조회 → 검증 → 업데이트 → 조회)</li><li>마지막 <code>getIsLikedBrand()</code> 조회는 트랜잭션 내에 있을 필요 없음</li><li>트랜잭션안에 관련 없는 코드가 있어 DB 커넥션을 오래 점유하게 되어 성능 저하 가능성</li></ul>&nbsp;<h3>3-2. 개선 방안</h3><ul><li>트랜잭션은 최소한의 쓰기 작업만 포함</li><li>읽기 전용 작업은 트랜잭션 밖으로 분리</li><li>외부 API 호출, 복잡한 비즈니스 로직은 트랜잭션 전/후 처리</li></ul>[적용 1] - 좋아요 기능 개선<pre><code class="language-java">@Transactional
public void executeBrandLikeToggle(Long userId, Long brandId, UserBrandStatus status) {
 // 트랜잭션 내에는 쓰기 작업만
 if(status == null) {
 brandRepository.insertUserBrandLike(userId, brandId);
 brandRepository.plusBrandLikeCnt(brandId);
 } else {
 brandRepository.switchBrandLike(userId, brandId);
 if (status.getLiked() == 1) {
 brandRepository.minusBrandLikeCnt(brandId);
 } else {
 brandRepository.plusBrandLikeCnt(brandId);
 }
 }
}

public BrandLikeResponse BrandLikeToggle(Long userId, Long brandId) {
 // 트랜잭션 밖에서 조회
 UserBrandStatus status = brandRepository.getUserBrandStatus(userId, brandId);
 
 // 트랜잭션으로 쓰기 작업만 실행
 executeBrandLikeToggle(userId, brandId, status);
 
 // 트랜잭션 밖에서 최종 결과 조회
 return brandRepository.getIsLikedBrand(userId, brandId);
}
</code></pre><ul><li>트랜잭션과 관련 없는 기능들은 트랜잭션에서 제외 -&gt; DB 커넥션 풀 고려를 위해</li><li>유저의 브랜드 좋아요 상태, 최종결과는 따로 분리 [적용 2] - 주문 생성 기능에서 외부 작업 분리</li></ul><pre><code class="language-java">// ❌ 기존 코드
@Transactional
public OrderCreateResponse createOrder(Long userId, OrderCreateRequest request) {
 Long shippingId = orderRepository.createShipment(request);
 Long orderId = orderRepository.createOrder(userId, shippingId, request.getPayment());
 
 // 외부 API 호출이 트랜잭션 내에 있으면 안됨
 paymentGateway.processPayment(orderId, request.getPayment()); // ❌
 
 return new OrderCreateResponse(orderId);
}

// ✅ 개선
public OrderCreateResponse createOrder(Long userId, OrderCreateRequest request) {
 // 1. 외부 결제 API 먼저 호출 (트랜잭션 밖)
 PaymentResult paymentResult = paymentGateway.processPayment(request.getPayment());
 
 // 2. 결제 성공 시에만 DB 저장 (트랜잭션 내)
 if (paymentResult.isSuccess()) {
 return saveOrder(userId, request, paymentResult);
 }
 throw new PaymentFailedException();
}

@Transactional
private OrderCreateResponse saveOrder(Long userId, OrderCreateRequest request, PaymentResult paymentResult) {
 Long shippingId = orderRepository.createShipment(request);
 Long orderId = orderRepository.createOrder(userId, shippingId, request.getPayment());
 return new OrderCreateResponse(orderId);
}
</code></pre>&nbsp;&nbsp;<h3>3-3. 트랜잭션 범위 설정 원칙 정리</h3><ul><li>트랜잭션을 사용해야 하는 경우<ul><li>DB 쓰기 (INSERT/UPDATE/DELETE) - 원자성 보장을 위해</li></ul>&nbsp;</li><li>트랜잭션을 사용하지 말아야 하는 경우<ul><li>단순 조회 (SELECT) - 트랜잭션 필요 없음</li><li>외부 API 호출 - DB 커넥션 점유 최소화</li><li>복잡한 계산 로직 - 트랜잭션 시간 단축을 위해</li><li>파일 I/O - 느린 작업 분리</li></ul></li></ul>&nbsp;트랜잭션 분리의 중요성<ul><li>트랜잭션 작업이 필요하지 않은 경우를 트랜잭션 코드에서 제거한다면 다음과 같은 이점을 얻을 수 있음<ul><li>DB 커넥션 점유 시간 최소화</li><li>동시 처리 성능 향상</li><li>데드락 발생 가능성 감소</li></ul></li></ul><hr><h1>4. “동시성 이슈를 테스트하거나, 개선 전후를 어떻게 측정·검증할 계획인가요?”</h1><h3>1. 단위 테스트로 기능 검증</h3>[좋아요 기능 테스트]<ul><li>JUnit + ExecutorService 사용해서 여러 스레드가 동시에 좋아요 실행</li><li>예를 들어 100명이 동시에 좋아요 누르면 정확히 100개 증가하는지 확인</li><li>같은 사용자가 동시에 두 번 클릭해도 한 번만 반영되는지 검증</li></ul>&nbsp;[장바구니 기능 테스트]<ul><li>JUnit + ExecutorService 사용해서 동시에 같은 상품을 여러 번 추가</li><li>예를 들어 같은 사용자가 "3개 추가"를 10번 동시에 실행하면 정확히 30개가 추가되는지 확인</li><li>MERGE 문 실패 시 예외 처리로 UPDATE가 정상 실행되는지 검증</li><li>UNIQUE 제약조건으로 중복 레코드가 생성되지 않는지 확인'&nbsp;&nbsp;&nbsp;</li></ul><h3>2. 부하 테스트로 성능 측정</h3><ul><li>K6와 같은 도구로 실제 부하 상황 재현&nbsp;</li><li>동시 사용자 100명, 요청 1000회 정도로 테스트</li><li>Grafana (모니터링) 로 TPS(초당 처리량), 평균 응답시간, 에러율 측정 및 모니터링&nbsp;</li></ul>&nbsp;

동시성 제어 분석 및 테스트 계획

<ol><li>“현재 프로젝트에서 동시성 문제가 발생할 가능성이 있는 시나리오는 무엇인가요?”<ol><li>채팅방 생성<ol><li>문제 : 두 사용자가 동시에 채팅 생성</li></ol></li><li>게시글 좋아요 토글<ol><li>여러 사용자가 같은 게시글에 동시에 좋아요/취소</li><li>&nbsp;</li></ol></li></ol><hr></li><li>“동시성 제어(트랜잭션 Isolation, Lock, Optimistic Lock 등)를 적용한다면, 어떤 방법을 고려해볼 수 있을까요?”<ol><li>채팅방 생성<ol><li>DUPLICATE KEY 적용으로 중복방지</li><li>유니크 키를 사용한 save</li></ol></li><li>게시글 좋아요<ol><li>비관적 락<ol><li>post 컬럼을 잠그고 카운트 증감</li></ol></li><li>낙관적 락 (@version 사용)<ol><li>충돌시 재시도&nbsp;</li></ol></li></ol></li></ol><hr></li><li>“트랜잭션 범위를 어떻게 설정하고, 트랜잭션 내에서 불필요한 작업(예: 외부 API 호출)을 제거할 수 있을까요?”<ol><li>채팅방 생성<ol><li>외부 알림 푸시는 트랜잭션 밖에 비동기 처리 springEvent 처리&nbsp;</li></ol></li></ol><hr></li><li>“동시성 이슈를 테스트하거나, 개선 전후를 어떻게 측정·검증할 계획인가요?”<ol><li>채팅방 생성<ol><li>&nbsp;멀티스레드 정합성 테스트</li></ol></li><li>게시글 좋아요<ol><li>비관적 락<ol><li>충돌 에외 거의 없으니 지연 시간 측정</li></ol></li><li>낙관적 락<ol><li>충돌 수/ 재시도 횟수 또는 재시도 성공률(횟수 제한 할 경우) 지표로 확인</li></ol></li></ol></li></ol></li></ol>

김지수

<ol><li>“현재 쿼리에서 병목(성능 저하) 가능성이 있을 만한 부분은 어디라고 생각하나요?”<ul><li>“축제 조회” API 요청 시 WHERE 절로 <code>status</code>과 <code>mapx</code>, <code>mapy</code> 를 많이 사용하고, 정렬(<code>ORDER BY created_at</code>)도 자주 쓴다.</li></ul></li><li>“인덱스(또는 복합 인덱스)를 새로 추가한다면, 어떤 컬럼(들)에 추가하고 싶나요?”<ul><li>현재 인덱스가 없어서 Table Full Scan을 하고 있기 때문에, <code>status</code> 컬럼을 기준으로 인덱스를 설정해서 type을 <code>ref</code>로 검색할 수 있도록 개선할 수 있다.</li></ul></li><li>“인덱스를 적용하거나 쿼리를 튜닝한 뒤, 성능을 어떻게 측정·검증할 계획인가요?”<ul><li>인덱스 생성 전후 <code>EXPLAIN</code> 으로 type(ALL vs ref)과 rows 수 비교</li><li>HTTP 응답 속도를 비교(582ms → 325ms)</li></ul></li><li>“만약 인덱스 적용 후 데이터 삽입·수정 시 성능 저하가 생긴다면, 어떻게 대처할 수 있을까요?”<ul><li>너무 많은 인덱스를 만들지 않도록 주의한다.</li></ul></li></ol>

3주차 미션 - DB 인덱스 최적화 실습 🔥

3주차 미션 - DB 인덱스 최적화 실습 미션 제출

이길훈

1. 현재 프로젝트에 사용자가 400명 이상으로 증가하면 어떤 문제가 발생할까?부하 테스트 결과를 보면 VUsers를 400으로 설정한 경우 로컬 환경에서 아래 결과가 나온다.<ul><li>http_reqs: 385/s</li><li>http_req_durations: avg=23.82ms</li></ul>이 결과를 통해 1초 안에 응답을 못 받는 사용자가 나오는 문제가 발생하고, 응답 대기 시간도 매우 길어지는 문제가 발생한다.&nbsp;2. 현재 제공하던 기능에서 추가로 제공될만한 기능이 있다면 뭐가 있을까? 해당 기능을 제공하려면 어떤 변화가 필요할까?<ul><li>외부 API 연동 (예: SNS에 게시글 올리면 자동으로 게시판에 업로드)<ul><li>OAuth2.0을 통한 외부 SNS 인증 구현</li><li>외부 API 연동 모듈 개발</li><li>웹훅(Webhook) 앤드 포인트 개발</li></ul></li></ul>3. 현재 프로젝트에 예상보다 많은 사용자가 유입된다면 어떤걸 공부해야 할까?<ul><li>인프라 확장<ul><li>스케일 업 또는 스케일 아웃</li><li>로드 밸런서</li><li>클라우드 컴퓨팅</li></ul></li><li>성능 최적화<ul><li>캐싱</li><li>CDN (Content Delivery Network)</li><li>데이터베이스 최적화</li></ul></li></ul>

2주차 미션 - 프로젝트 확장성 분석

<ol><li>현재 프로젝트에 사용자가 400명 이상으로 증가하면 어떤 문제가 발생할까요?<ul><li>네트워크 트래픽 증가로 비효율적인 트래픽 사용</li><li>서버 부하(cpu, memory)로 응답속도가 느려지고, DB 연결 수 제한으로 인해 서비스 장애발생&nbsp;</li></ul></li><li>현재 제공하던 기능에서 추가로 제공될만한 기능이 있다면 뭐가 있을까요? 해당 기능을 제공하려면 어떤 변화가 필요할까요?<ul><li> 지역별, 나이별 사용자 별로 조회수, 좋아요 증가 속도를 고려한 인기 게시글 추천 기능: 게시글 별 통계를 위한 DB 확장 혹은 통계 정보만을 처리하기 위한 No-SQL DB 도입 고려</li></ul></li><li>현재 프로젝트에 예상보다 많은 사용자가 유입된다면 저희는 어떤걸 공부해야 할까요?<ul><li>네트워크 트래픽 개선을 위한 CDN(AWS CF) 개념을 공부해야 한다.</li><li>효율적인 DB 커넥션을 위한 thread pool 개념을 공부해야 한다.</li><li>읽기 쓰기 비율에 따른 Master, Replica DB 개념을 공부해야 한다.</li><li>데이터 조회를 위한 query 튜닝 개념을 공부해야 한다.</li><li>부하 분산을 위해 로드 밸런싱 개념을 공부해야 한다.</li><li>데이터 저장 및 응답 성능을 개선하기 위한 Redis 같은 캐시 시스템을 학습해야 한다.&nbsp;</li><li>API 응답 속도를 높이기 위해 비동기 처리 및 멀티스레딩 기법을 공부해야 한다.&nbsp;&nbsp;</li></ul></li></ol>

아직 개인 프로젝트를 시작하지 않아서 그전에 했던 팀 프로젝트 간단하게 만든 부분에 대해서 이야기해보겠습니다.<ol><li><code>category_name </code>으로 검색후 <code>create_a</code>t 정렬시 데이터가 많으면 full scan 이 발생할 것 같습니다. <code>post_category_matches</code> 조인 시 <code>category_id</code> / <code>post_id </code>컬럼에 인덱스가 없으면 조인시 풀 스캔 발생할 것 같습니다.</li><li>게시판 테이블에 <code>category_id</code> , <code>create_at</code> 복합 인덱스 를 걸어서 최신순 카테고리별 조회를 동시에 조회하는게 좋을 것 같습니다.</li><li>더미 데이터를 넣은 후 <code>EXPLAIN </code>으로 인덱스 적용 전 후 쿼리를 실행 후 rows 나 using index 등 여부를 비교 하고 실제 응답시간을 측정 할 계획입니다.</li><li> 첫째 자주 사용하지 않는 인덱스를 제거하는게 좋을 거 같습니다. 둘째 파티셔닝? 이부분에 대해서는 강의를 봤지만 정확히 어떻게 흘러가는지 잘 모르겠습니다. 사용해봐야 알 것 같습니다. 배치 삽입 시 인덱스를 비활성화 후 삽입 완료 후 재생성 하는것도 하나의 방법인거 같은데 인덱스를 다시 거는 부분에 대해서도 시간이 걸릴 거 같습니다. 이정도 생각이 됩니다. ``` 강의를 보고 코드도 보면서 많은 것을 배울 수 있었습니다. 감사합니다. 현재 인공지능사관학교에서 수업이랑 마지막 프로젝트 들어가기전에 연습? 병행을 하다보니 버스로 왔다갔다하면서 핸드폰으로 어플로 강의를 보고 있었는데 중간에 어플에서는 챌린지만 나오지 않아서 따라가지 못한 부분이 있습니다. 늦었지만 열심히 따라가보겠습니다. ```</li></ol>

3주차 미션 과제

이번 주차 과제에서는 데이터베이스 인덱스를 어떻게 적용할 수 있을지, 그리고 적용 후 쿼리 성능이 어떻게 달라지는지를 직접 고민하고 실험해보는 시간을 가져볼 예정입니다.&nbsp;과제를 진행하기 위해서, 프로젝트 내에서 사용 중인 DB 테이블을 살펴보고, 가장 자주 조회하거나 성능이 중요해 보이는 테이블 1개를 선택해주세요.해당 테이블에서 주로 사용하는 쿼리(예: 검색, 정렬, 페이징, JOIN 등) 1~2개를 골라, 아래 질문에 답해보세요.&nbsp;다음 질문에 대한 여러분의 답을 과제 제출란에 작성해주세요!&nbsp;<h3>1. “현재 쿼리에서 병목(성능 저하) 가능성이 있을 만한 부분은 어디라고 생각하나요?”</h3>게시글 목록 조회 입니다. 게시글 목록 조회는 다음과 같이 구성되어 있습니다.<ul><li>페이징</li><li>검색</li><li>정렬(Default: 오름차순)</li></ul>&nbsp;<h3>2. “인덱스(또는 복합 인덱스)를 새로 추가한다면, 어떤 컬럼(들)에 추가하고 싶나요?”</h3><code>board_id</code>, <code>article_id</code>&nbsp;<h3>3. “인덱스를 적용하거나 쿼리를 튜닝한 뒤, 성능을 어떻게 측정·검증할 계획인가요?”</h3>전체 데이터를 기준으로 첫 번째 값, 중간 값, 마지막 값을 기준으로 <code>EXPLAIN/ANALYZE</code>로 실행 계획을 먼저 확인합니다. Covering Index가 적용되는지, 원하는 Key를 타는지 체크합니다. 또한 실제 실행 시간과 I/O 통계를 측정한 뒤, 부하 테스트와 모니터링으로 서비스 환경에서의 성능을 장기적으로 검증하겠습니다.&nbsp;<h3>4. “만약 인덱스 적용 후 데이터 삽입·수정 시 성능 저하가 생긴다면, 어떻게 대처할 수 있을까요?”</h3><ol><li>중복/부분중복/미사용 인덱스는 과감하게 삭제 후 정말 필요한 인덱스만 유지하고, 업데이트가 자주 발생하는 컬럼은 인덱스를 최소화합니다.</li><li>상태값, 카운터 같은 UPDATE 빈번 컬럼은 별도 테이블로 분리하거나 인덱스를 제거합니다. 이때 읽기는 조인/캐시로 보완합니다.</li><li>UNIQUE 인덱스는 CHANGE BUFFER 미적용으로 인해 쓰기 비용이 높기 때문에 반드시 필요한 것만 유지합니다.</li><li>읽기 전략을 Keyset으로 유지하여 핵심 복합 인덱스 1개로 깊은 페이지도 빠르게 처리합니다. 이에 따라 추가 인덱스 증설 필요성이 감소합니다.</li></ol>

3주차 미션 제출

1. 트래픽이 늘어난만큼 서버 부하가 커져 모든 사용자 요청에 대한 응답 시간이 느려질 것이다. 특히, 이용자가 몰리면 설정해둔 데이터베이스 커넥션 풀을 쉽게 초과해 긴 대기시간, 응답 오류 등을 유발하고 정상적인 서비스를 제공할 수 없게 된다.사용자가 많으니 CPU가 데이터베이스에 직접 접근하는 빈도도 늘어나지 않을까? 예상한다. 그런데 내가 알기론 CPU가 데이터베이스에 직접 접근하는 것은 속도가 매우 느린 것으로 알고 있다. 이 부분도 서비스 질적 하락을 유발할 수 있지 않을까 추측된다.2. 알림 기능을 추가하고 싶다. 커뮤니티를 이용하는데 알림 서비스의 구현은 이용자의 사용 경험에 긍정적으로 작용한다. 우선 알림 테이블을 만들어야 할 것이다. 그리고 잘 모르는 부분이지만 rabbit mq나 kafka같은 비동기 시스템을 통해 알림의 전송을 구현해야 할 것이다. 보통 커뮤니티는 로그아웃 한 시간이 많을것이다. 그런데 로그아웃 했다고 알림이 기록되지 않는다면 로그인 할 때 마다 직접 자신의 글 내역을 조회하는 상당한 불편함을 야기할 것이다. 그래서 로그아웃 한 상태를 고려한 조치가 필요할 것 같고, 인터넷을 찾아보니 SSE을 이용하면 실시간 통신이 가능하다고 한다. 로그인 상태에서의 알림은 SSE로 처리하면 좋지 않을까 생각한다.3. 검색 기능을 다양하게 제공하니 효율적인 쿼리 작성 및 DB구축에 대한 공부가 필요할 것이다. 모든 일을 데이터 베이스와 작업하면 속도가 느리니 상대적으로 속도가 빠르다고 하는 레디스에 대한 공부도 필요할 것이다. 잘 모르지만 지금 구조라면 서버 하나가 고장 났을 때 혹은 서비스 하나가 문제가 생겼을 때 모든 서비스에 영향이 가지 않을까 싶어서 이를 분리해서 일부 서비스가 비정상이더라도 정상적으로 운영할 수 있는 서비스는 유지가 되게끔 할 방도를 알아봐야 할 것이다. 비동기와 동기 등의 개념도 알아봐야 할 것 같다.솔직히 모르는게 너무 많은 상황이다. 아직 자바와 스프링 실력도 빈약한 편인지라 작성한 답변이 정답에 가까운지 오답인지 확신도 서지 않는다. 인터넷에 검색하거나 책을 찾아봐서 덕지덕지 적는 현실이 아쉽지만 노력하면 나아지지 않을까? 기대해본다.

2주차 미션 제출

jackt0506

<h2>0. 질문에 답하기 전에</h2>운영 환경은 AWS <code>t3.micro</code> 단일 인스턴스(vCPU burst Memory 1GiB)이라고 가정합니다. 해당 인스턴스는 Docker compose에 Monolith Architecture Spring Boot 3.x,x, Redis Container, Prometheus/Grafana, K6, JMH)로 구성되어 있습니다.<ol><li>RDS는 단일 인스턴스로 <code>db.t3.micro(MySQL 8.0)</code> 입니다.&nbsp;<ul><li>AWS EC2 instance: <code>t3.micro</code></li><li>AWS RDS DB instance: <code>db.t3.micro</code></li></ul></li></ol><h2>1. 현재 프로젝트에 사용자가 400명 이상으로 증가하면 어떤 문제가 발생할까요?</h2><h3>1.1 즉시 보이는 문제점</h3><ul><li>응답 지연 급증: P95, P99 Latency 급증으로 Timeout, 502, 504 발생</li><li>DB 접속 실패: "too many connections", "connection Timeout" 발생</li><li>CPU, Memory 자원 부족: <code>t3.micro</code> 성능을 초과한 자원 사용</li><li>캐시 적중률 불안정: Traffic Spike 때 Redis Cache Miss/Strom 발생</li><li>디스크 초과: Log, Metric, Profiles 파일 급증</li></ul>수많은 문제 중에서 가장 큰 문제인 <code>t3.micro</code>, <code>db.t3.micro</code>은 매우 낮은 시스템 성능의 한계로 인해 400명 이상의 사용자를 감당할 수 없습니다. 해당 서버는 더이상 접속할 수 없는 상태가 될 가능성이 매우 높습니다. 2. 현재 제공하던 기능에서 추가로 제공될만한 기능이 있다면 뭐가 있을까요? 해당 기능을 제공하려면 어떤 변화가 필요할까요?Snowflake나 UUIDv7과 같은 기본 키 생성 전략을 사용하면, 시간 순서가 보장되는 특성 덕분에 조회 성능 안정성을 기대할 수 있고, 분산 환경에서 Sharding 시 Shard Key로 활용되어 Scale-Out에 유리합니다.즉시 MSA 전환까지는 오히려 더 많은 비용과 자원이 발생할 것으로 예상되어 불필요하다고 생각합니다. 하지만 각 도메인마다 경계를 명확히 분리한다면 나중에 전환 비용이 크게 줄어들 것으로 기대할 수 있다고 생각이 듭니다. 현행은 Monolith Architecture이지만 Hexagonal Architecture와 DDD Architecture 로 설계해두면 매우 긍정적이라고 생각합니다. 만약 여러 팀원들과 함께 개발하는 상황인 경우, 모든 팀원들이 MSA 전환 경험과 운영 환경 경험도 MSA가 더 풍부하다면 오히려 좋은 기회라고 볼 수 있다고 생각합니다.&nbsp; 3. 현재 프로젝트에 예상보다 많은 사용자가 유입된다면 저희는 어떤걸 공부해야 할까요?현재 프로젝트를 기준으로 예상보다 많은 사용자가 유입되면 시스템은 첫 번째 질문의 답변보다 더 수많은 문제에 직면할 수 있습니다. 대표적으로 아래와 같은 문제들이 존재합니다.<ul><li>서버 리소스 한계: CPU 크레딧 고갈, 메모리 부족, 컨테이너 간 자원 경합</li><li>데이터베이스 병목: 커넥션 초과, 슬로우 쿼리, 인덱스 미비, N+1 문제</li><li>시스템 불안정성: 모니터링 부재로 장애 원인 파악 지연, 알림 체계 부재로 대응 늦어짐</li><li>아키텍처 한계: 단일 인스턴스에 앱·모니터링·Redis 등이 함께 있어 성능 간섭 발생</li></ul>이러한 문제들을 빠르게 감지하고 원인을 파악하기 위해서는 우선적으로 모니터링을 체계적으로 살펴보는 방법을 학습해야 합니다. 단순히 증상만 보는 것이 아니라, CPU, 메모리, DB 커넥션 수, 응답 지연 시간, 에러율 같은 주요 지표를 분석해 병목 지점을 정확히 찾아내는 능력이 필요합니다. 원인을 파악한 이후, 문제 해결을 위한 우선순위를 세워 단계적으로 공부를 이어갈 수 있습니다.<ul><li>인프라 안정화: 인스턴스 성능 상향, 앱·모니터링·Redis 분리, 컨테이너별 CPU/MEM limit 설정</li><li>모니터링 고도화: CloudWatch CPUCreditBalance 알람, 슬랙 알림 연동</li><li>DB 최적화: Hikari maximumPoolSize 조정, 인덱스 개선, N+1 제거(Querydsl 최적화)</li><li>아키텍처 개선: 모듈러 모놀리식으로 도메인 경계를 명확히 하여 코드 유지보수성과 확장성 확보&nbsp;</li></ul>

<ol><li>현재 프로젝트에 사용자가 400명 이상으로 증가하면 어떤 문제가 발생할까요?&nbsp;</li></ol><ul><li>일단 동시 접속이라고 가정을 한다면 DB 커넥션이라던가 DB INDEX를 제대로 안해놓고 했을때 문제가 생길 것 같습니다.</li><li>그리고 현재 구매시 재고 차감에 비관적 락을 사용했는데 이러한 부분들이 문제가 될 것 같습니다.&nbsp;</li></ul><ol start="2"><li>현재 제공하던 기능에서 추가로 제공될만한 기능이 있다면 뭐가 있을까요? 해당 기능을 제공하려면 어떤 변화가 필요할까요?</li></ol><ul><li>현재 쿠폰이나 포인트 등의 기능을 추가 할 수 있을 것 같습니다. 중복 방지를 위해 멱등성 처리를 위한 방식을 도입 해야 할 것 같습니다.</li></ul><ol start="3"><li>현재 프로젝트에 예상보다 많은 사용자가 유입된다면 저희는 어떤걸 공부해야 할까요?</li></ol><ul><li>DB 마스터, 슬레이브를 사용하거나 redis, 캐시 쪽을 공부하는 방법이 있을 것 같습니다.</li></ul>

현재 개발 중인 프로젝트가 확장될 경우 발생할 수 있는 문제

g_a_m_e_

1. 서버 부하, DB 부하, 배포 중 서비스 중단 위험2. 캐시 시스템 도입, 무중단 배포3. db 성능 최적화 및 쿼리 최적화, 서버 확장(로드밸런싱 및 오토 스케일링), 캐싱 전략, 비동기 처리, 모니터링 및 장애 대응&nbsp;정도 있습니다.&nbsp;

현재 개발중인 프로젝트가 확장될 경우 발생할 수 있는 문제

* 포트폴리오 주제: QnA 게시판 API* 목표 기능:- 회원 가입 기능- 질문, 답변, 댓글 CRUD- 질문마다 답변 채택 기능- 질문, 답변, 댓글 좋아요 기능* 개발 방식: 스프링과 DB(MySQL)만으로 개발 진행 후 추가적인 성능 개선 진행 예정* 회원가입, 로그인, 질문 등록, 질문 조회수 계산 부분만 개발된 상태로 현재 진척도를 기준으로 과제 진행하였습니다.1. 현재 프로젝트에 사용자가 400명 이상으로 증가하면 어떤 문제가 발생할까요?<ul><li>DB 인덱스 미설정으로 DB 통신 보틀넥 예상<ul><li>게시글 조회 시 동일 유저의 조회는 일정시간동안 1회만 집계되도록 제한하기위해 DB에 QuestionViewer(질문글식별자, 유저식별자 포함)를 저장하고 조회 -&gt; 게시판 특성상 조회 비율이 높을 것이기에 QuestionViewer 데이터가 빠르게 쌓이면서 인덱스는 설정되지 않아 QuestionViewer 조회에 보틀넥 예상됨 -&gt; 주기적인 QuestionViewer 삭제와 인덱스 설정 필요</li></ul></li><li>요청의 대부분은 조회 작업일 것으로 예상되어 나머지 회원가입, 로그인, 질문 등록 작업은 요청이 적어 문제가 없을 것으로 보입니다.</li></ul>2. 현재 제공하던 기능에서 추가로 제공될만한 기능이 있다면 뭐가 있을까요? 해당 기능을 제공하려면 어떤 변화가 필요할까요?<ul><li>일정 기간 단위로 인기 질문 선정<ul><li>n일 단위로 조회수, 좋아요 수, 댓글 수, 답변 수 등을 조합해 인기 질문을 선정하는 기능</li><li>특정 시간에 인기 질문을 선정하는 작업을 실행하면 단시간에 일정 기간동안 작성된 모든 질문글마다 조회, 좋아요, 댓글, 답변을 모두 고려해야하므로 서비스 성능 저하를 일으킬 것입니다. 따라서 질문 등록 시 인기 질문 선정을 위한 점수를 저장할 방법을 마련하고 해당 질문에 대한 조회, 좋아요, 댓글, 답변 요청마다 점수를 갱신하여 작업 시간을 분산시키는 것이 좋아보입니다.</li><li>n일 단위로 인기 질문을 선정하므로 당장 점수 갱신이 필요 없으니 메시징 큐를 이용하여 지연 처리를 수행해도 좋을 것 같습니다.</li></ul></li></ul>3. 현재 프로젝트에 예상보다 많은 사용자가 유입된다면 저희는 어떤걸 공부해야 할까요?<ul><li>AWS<ul><li>서버 스케일 아웃, DB 스케일 업 수행 방법</li><li>서버 스케일 아웃에 따른 로드 밸런싱 방법</li></ul></li><li>레디스<ul><li>조회수, 인기 질문 점수 산정 등에 캐싱 사용해 DB 부하를 감소시킴</li></ul></li><li>DB<ul><li>게시판은 조회 트래픽이 높으니 DB를 마스터&amp;레플리카로 분리하고 레플리카를 많이 늘리는 식으로 조회 트래픽에 대응</li></ul></li></ul>&nbsp;

2주차 미션 / 프로젝트 확장성 분성

백엔드해야지

개발 · 프로그래밍

커리어 · 자기계발

데이터베이스

개발 도구

취업 · 이직

데브옵스 · 인프라

ViewContent.1769762636.338284.0df581a4-b6c9-4182-a94e-b1be1a71e9b9