feel_2

현업에서 장애는 예상치 못한 곳에서 항상 발생한다.피할 수 없다면 적극적으로 예방하고, 장애 발생 시 유연하고 빠르게 대처해야 하며, 같은 장애가 재발되지 않도록 조치를 취해야 한다.현업에서의 장애 대응 프로세스는 보통 장애 탐지 및 전파장애 분류 및 해결장애 복구 및 보고장애 회고이렇게 진행된다고 보면 된다.현업에서 장애를 빠르게 감지하기 위해서는 로깅, 모니터링 등의 방법이 있는데, 장애 상황을 감지하기 위해 다양한 조건을 설정하고 모니터링을 통해 장애 확산을 방지할 수 있다.그럼 우리가 자주 볼 수 있는 장애는 어떤 것들이 있고, 어떻게 대응을 하면 좋을지 같이 살펴보자. 외부 서비스 장애 Kafka 사례: 디스크 공간 부족으로 인해 Kafka Broker를 사용할 수 없음실패 원인: Kafka 브..

목적서비스의 기본적인 성능 테스트 및 예상치 못한 병목 현상이나 장애 상황에 대비하기 위해서 진행한다. 대상 API 콘서트 대기열 시나리오 에 있는 모든 API를 대상으로 테스트를 진행한다.GETapi/v1/concertsapi/v1/concerts/{concertId}api/v1/concerts/{concertId}/datesapi/v1/concerts/dates/{concertDateId}/seatsapi/v1/users/{userId}/balanceapi/v1/reservations/{userId}POSTapi/v1/payments/payapi/v1/reservationsapi/v1/queues/tokenPATCHapi/v1/{userId}/chargeDELETEapi/v1/reservations/..

문제결제 API 쪽 비즈니스 로직의 트랜잭션 생명주기가 길다.결제 API 쪽을 한번 살펴보자.@Component@RequiredArgsConstructorpublic class PaymentFacade { private final PaymentService paymentService; private final UserService userService; private final ConcertService concertService; private final WaitingQueueService waitingQueueService; /** * 결제 요청하는 유즈케이스를 실행한다. * * @param command reservationId, userId 정보 ..

조회를 할 때 데이터가 얼마 없을 때는 상관없지만, 데이터가 수천, 수만 건의 경우 인덱스가 있냐 없냐의 따라 성능 차이가 엄청 크다고 한다.보통 인덱스는 카디널리티가 높은(중복도가 낮은) 컬럼으로 설정한다고 한다. (참고로 pk는 기본으로 인덱스로 설정되어 있음)예를 들어 주민등록번호의 경우 카디널리티가 높다고 할 수 있다.(Unique 하기 때문에)지금 나의 시나리오(콘서트 대기열)에서 인덱스 추가를 통해 성능을 개선할 수 있는 부분이 있는지 알아보자. 문제콘서트 예약 가능한 좌석을 조회하는 API 의 경우, 실제로 하나의 콘서트장에 5만명이 앉을 수 있는 대형 장소에서 하는 경우가 많다. 콘서트가 1만개만 있어도, 콘서트 좌석 조회하는 데이터는 5억개의 자리의 데이터가 들어가 있을 것이다. 원인테스..

캐시란?캐시는 자주 액세스하거나 계산 비용이 많이 드는 데이터를 일시적으로 저장하는 데 사용된다. 데이터에 액세스하는 데 걸리는 시간을 줄이고, 느린 리소스나 시스템의 로드를 줄여 성능을 향상시키는 데 도움이 된다.그럼 캐시를 사용하기 위한 적절한 데이터의 판단 기준은 무엇일까?데이터가 변경에 민감한지?데이터의 연산에 드는 비용이 비싼지?데이터의 변경이 전파가 되는지?→ 요약하자면, “잘 바뀌지 않으면서 접근할 일이 많은 데이터, 변경되더라도 다른 서비스에 큰 영향을 미치지 않는 데이터” 가 캐시에 저장하여 활용하기 적절하다.그럼 DB에서 계산 비용이 많이 드는(쿼리를 날렸을 때 시간이 오래 걸리는) 경우는 어떤 경우들이 있을까?조인이 복잡할 경우복잡한 조인 조건이 있는 여러 테이블과 관련된 쿼리, 특히..

제가 콘서트 예약시스템에서 구현한 대기열에 대한 설계에 대해서 얘기해보겠습니다. 대기열이란?대기열 시스템은 많은 사용자들이 동시에 접근하는 상황에서, 시스템의 안정성과 성능을 보장하기 위해 필수적인 요소입니다. 특히, 티켓 예매, 상품 구매, 서비스 예약 등과 같은 상황에서 대기열 시스템이 중요한 역할을 합니다.만약 1000명의 유저가 동시에 좌석 예약을 위해 요청을 보낸다면, 정해진 선착순 100명만 예약이 가능하게 하고, 나머지는 대기열에서 대기하게 됩니다.이렇게 하면 트레픽의 유량을 제어할 수 있기 때문에 서버의 부하를 줄일 수 있습니다. 대기열에 있는 유저는 일정 시간이 지나면 좌석 예약이 가능하게 되어 콘서트 좌석을 예약할 수 있습니다. 대기열 구현 방법전통적으로? 대기열을 구현하는 방식에는 크..

동시성 문제먼저 동시성 문제가 무엇인지 간단하게 짚고 넘어가보자.동시성 문제란?여러 작업들이 **동시에 하나의 공통 자원을 점유**하려고 시도할 때 발생하는 문제그럼 이런 동시성 문제가 발생하면 무엇이 문제인가?내가 원하는 결과와 다른 결과가 발생할 수 있다.ex) 데이터를 수정하였으나 조회했을 때 내 예상과 다른 값이 반환동시성 문제로 인해 데이터 무결성이 깨지고, 이로 인해 정합성을 저해시킬 수 있다.데이터의 무결성?데이터 값이 정확한 상태데이터의 정합성어떤 데이터들의 값이 서로 일치하는 상태데이터의 무결성이 훼손 되는 경우 주문정보 테이블에서 고객번호가 모두 -1으로 입력되어 있고, 고객정보 테이블에도 -1의 값을 갖는 고객이 존재한다. (데이터의 값이 일치한다.)그러나 고객번호는 반드시 1 이상의..

1. 간단한 자기소개 안녕하세요 백엔드 5년차 개발자입니다. 열심히 항해 중입니다.   2. 이번 챕터를 시작하며 꼭 해내고 싶었던 목표 하나의 온전한 서버 개발을 목표로 하였습니다.   3. 이번 챕터를 마무리하며 가장 기억에 남는 성취 db를 통하여 대기열을 구현한 것에 가장 큰 성취감을 느꼈습니다.    4. 이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것 domain 과 entity 를 완전히 분리하여 계층 간에 종속성을 없애고 싶었는데, 그렇게까지 못하여 아쉬웠습니다.   5. 다음 챕터에서 반드시 성공하고 싶은 목표  다음 챕터에서는 동시성과 대용량 트래픽에 대하여 다 고려하여 실무에서까지 이용할 수 있도록 설계해보도록 하겠습니다.   6. 내가 강화해야 할 강점 중 가장 중요하다고 생각..

문제이번 주차를 지나며 겪었던 문제가 무엇이었나요?-> 시퀀스 다이어그램과 DB 설계가 가장 어려웠습니다.시도문제를 해결하기 위해 어떤 시도를 하셨나요?-> 시퀀스 다이어그램에서 주체의 단위를 도메인별로 설정하고 진행하였습니다.또한 DB 설계를 할때 어디까지 정규화와 반정규화를 할지 다른 사람들 설계한 것도 참고하고, 코치님들의 발제 Q&A도 한번 더 녹화본으로 보았습니다.해결문제를 어떻게 해결하셨나요?-> 코치님이 올려주신 시퀀스 다이어그램 작성 예시를 보고 도메인 관점으로 작성을 하였습니다.    시퀀스 다이어그램을 작성할 때 중요한 점은 디자이너나 코드를 모르는 사람도 보고 알아볼 수 있게 쉽게 작성이 되야 한다는 점입니다.DB ERD 설계를 할 때는 어디까지 정규화를 하고, 반정규화를 할지가 정말..