dev_0hoon

1. msa 관련 추천영상 보기  카프카란 무엇인가?  전 서비스에서는 "토큰만료해주세요"가 아닌 "예약완료 되었어요"를 줘야한다.그걸 메세지를 보고 땡겨오는 서버 입장에서는 내가 해야하는 구나, 가 아니라 상대가 준 메세지를 보고 내가 할 일하면 된다는 입장으로 만들면 메세지를 받는 여러 콘슈머 즉 서버가 있다면 메세지를 주는 서버의 완료 메세지를 보고 자기할일을 하기 떄문임 주문정보를 카프카로하면 Async가 필요가 없다?  내가 보낸 메세지를  내 콘슈머에서 직접 불러본다. 그럼 아웃박스패턴의 체크가 가능하다.

😀 과제 개요내가 개발한 기능의 트랜잭션 범위에 대해 이해하고, 서비스의 규모가 확장되어 MSA 형태로 서비스를 분리한다면 어떤 서비스로 분리 확장될지 설계하고, 그 분리에 따른 트랜잭션 처리의 한계와 해결방안에 대한 서비스 설계문서 작성해당 과제의 이유는 한 트랜잭션이 길어질 경우에 대한 대비이다. 트랜잭션 안에 트랜잭션이 불필요한 로직에서 시간이 많이 소비 될 수 있다. 또한 로직이 길어 서로 연관관계가 없을 로직이 실패하게 된다면 전체가 롤백 되어버리기도 한다. 외의 데드락 문제 등을 야기 할 수 있다. 이 과제의 핵심은 서비스 분리의 확장으로 보이지만, 사실 트랜잭션을 나눠주는 작업이 중요할 것이다. (MSA 또한 그러한 문제를 해결하기 위함이 있으니..?)📚 시작하기 앞서.. MSA란?- 도..

여기서 주문정보전달은 결제의 부가적인 로직이기 때문에 분리 되어야 한다.  주문정보전송은 sendOrderInfo는 대충 목으로 만들어줬다. 1) 주문정보 전송이 늦어지면 결제처리에 대한 프로세스도 함께 지연된다. 2) 데이터 수집 플랫폼으로 주문데이터가 전달 api가 실패했을 떄, 결제가 취소된다. 3) 데이터 수집 플랫폼으로 주문데이터 전달 api가 timeout이 발생했을 떄도 결제가 취소된다.- 반대로 데이터 수집플랫폼은 실패한 결제임에도 저장이되고, 우리 시스템에서는 결제 실패가 되어 데이터가 맞지 않게된다.  위의 코드는 예이다. 제대로 작동하진 않을 것이다 (aop로 돌아가는 트랜잭션이기에?) 1) 이렇게 트랜잭션을 나눈다면?- 데이터는 정상적으로 결제에 대한 트랜잭션이 있어 결제만 관리가된..

🙂개요 - 나의 시나리오에서 수행하는 쿼리들을 수집해보고, 필요하다고 판단되는 인덱스를 추가하고 쿼리의 성능개선 정도를 작성하여 제출자주 조회하는 쿼리, 복잡한 쿼리 파악Index 추가 전후 Explain, 실행시간 등 비교 🚩 콘서트 예약시스템 사용자 플로우사용자 첫 접근 시 토큰을 발급, -> 대기열에서 기다림 ->차례가 오면 활성화 토큰콘서트 예약 가능 날짜를 조회한다.콘서트 예약 가능 좌석을 조회한다.콘서트 좌석을 예약한다.좌석을 결제한다. 사용자는 크게 5개의 플로우를 타게된다. 그 중에 1번에 해당하는 토큰은 Redis에서 관리되며, 쿼리를 사용하지 않게 끔 진행하려한다.2,3,4,5번의 플로우에서는 쿼리가 사용 된다. ▶️ 예약 가능 날짜 조회 select cs1_0.c..

앞서 우리가 학습한 Transaction, Lock, Index, Cache 등은 모두 비즈니스 로직을 처리하는 데에 있어 중요한 Database의 부하를 줄이고, 속도 및 성능을 향상시키기 위함이었습니다. 그런데 Lock의 범위 뿐 아니라 무분별한 비즈니스 로직과 트랜잭션의 규모 또한 우리가 예측하지 못한 문제를 발생시킬 수 있습니다.  어떤 문제로 이어질 수 있을까? - 다수의 SlowRead 작업으로 인해 요청 처리에 영향을 줄 수 있음- Transaction 범위 내에서 Lock을 사용하고 있을 경우, 해당 자원에 접근하는 다른 요청의 대기 혹은 데드락 상황을 유발할 수 있음- 긴 생명 주기의 Transaction의 경우, 오랜 시간은 소요되나 후속 작업에 의해 전체 트랜잭션이 실패할 수 있음  ..

- 쿼리에 대한 부하를 줄일 수 있는 훈련- 비즈니스 로직 별 트랙잰션 범위를 파악하고 사이드 이펙트에 대해 고려해 본다. > 사이드이펙트란? 의도치 않은 결과로 예로 고혈압약을 먹었는데 머리가 풍성하게 자라나는 것같은 의도하지 않았지만 나타나는 결과들이다.- 비즈니스를 적절하게 핸들링 할 수 있도록 선후관계를 파악하고, 애플리케이션 이벤트를 활용해 관심사를 분리하도록 개선해 본다. ---- 인덱스란? 서비스 개발자의 중요한 역량 중 가장 중요한 것은 데이터베이스를 핸들할 수 있는 역량이다. 그 중 중요한 것이 index이다.  - 인덱스는 조회 성능을 높일 수 있지만 아래 사항들을 고려하여 설계해야 함  - 한번에 찾을 수 있는 값  - 인덱스 재정렬 최소화 - 데이터 삽입, 수정이 적은 컬럼  - 인..

🤷 콘서트 예약 프로그램일반적으로 콘서트를 예약할 때에는 '인기가수'의 '팬'들이 몰리게 되며 트래픽이 발생한다. 곧 서버가 부하를 받게 된다. 적은 부하로 트래픽을 처리하기 위한 방법 중 사용 토큰 전략이 있다. Token (feat Redis)in-memory 데이터베이스인 Redis를 이용한 token 대기열  콘서트 예약프로그램의 대기열 방식은1. 사용자 처음 등장 -> 토큰 생성 -> 토큰 대기열로 들어감2. 토큰 대기열 -> 순번에 따라 활성화 토큰으로 전환 (서버의 상태에 따라 대기 시간이 정해짐)3. 활성화 토큰 -> 예약, 결제 등이 가능해짐 이 있다. 이곳에서 토큰 관리는 두가지로 나누게 된다.대기열 토큰 (Waiting Tokens)활성화 토큰 (Active Tokens)대기..

🤷 콘서트 예약 프로그램일반적으로 콘서트를 예약할 때에는 '인기가수'의 '팬'들이 몰리게 되며 트래픽이 발생한다. 곧 서버가 부하를 받게 된다. 적은 부하로 트래픽을 처리하기 위한 방법 중 사용 Caching 전략이 있다.Caching데이터를 임시로 복사해두는 Storage 계층적은 부하로 API 응답을 빠르게 처리하기 위해 사용 콘서트 예약프로그램은콘서트 일정 조회좌석 조회좌석 예약결제총 4개의 핵심 기능을 가지고 있다.  캐싱은 보통 메소드 단위로 작성된다. 자주 변화가 일어나지 않는, 하지만 많은 사용자들이 찾는 부분을 캐싱하는 것이 옳다.만약 사용자가 자주 찾는 정보를 캐싱하면, 서로 다른 정보를 보며 혼란이 일어날 것이다. 이곳에서 Caching으로 처리가 가능한 조회 부분을 볼 수 있다.콘..