dev_0hoon

checks의미 : 테스트 스크립트에서 정의한 체크(Check) 결과를 보여줍니다.100.00% 100x0: 모든 체크가 성공했음을 나타낸다. 여기서 100번의 체크가 수행되었고, 모두 성공했으며 실패는 없습니다. (/ 가 성공 x가 실패) data_received의미 : 테스트 동안 수신된 데이터의 총량입니다.27kB 18kB/s : 총 27KB의 데이터가 수신되었으며, 초당 평균 18KB가 수신되었습니다. data_sent의미: 테스트 동안 전송된 데이터의 총량입니다.16kB 10kB/s: 총 16kB의 데이터가 전송되었으며, 초당 평균 10kB가 전송되었습니다. http_req_blocked의미: 요청이 블록되는데 걸린 시간입니다. 이는 DNS조회, TCP 연결 수립, TLS 핸드쉐이크 등을 포함할..

향해99 최종장으로써 장애대응을 파트를 진행하려 한다. 대부분이 부하 테스트의 목적이 있는 것 같은데, 4가지의 테스트가 있다.  Load Test (부하 테스트)- 시스템이 예상되는 부하를 정상적으로 처리할 수 있는지 평가- 특정한 부하를 제한된 시간 동안 제공해 이상이 없는지 파악- 목표치를 설정해 적정한 Application 배포 Spec 또한 고려해 볼 수 있음 Endurance Test( 내구성 테스트 )- 시스템이 장기간 동안 안정적으로 운영될 수 있는지 평가- 특정한 부하를 장기간 동안 제공했을 때, 발생하는 문제가 있는지 파악- 장기적으로 Application을 운영할 때 발생할 수 있는 숨겨진 문제를 파악해 볼 수 있음 (feat. Memory Leak, Slow Query 등 ) Str..

현재 사용 중인 Docker Compose 파일의 버전이 오래되었다는 경고 메시지를 받고 있습니다. 또한, 사용 중인 이미지의 포맷에 대한 경고도 나타나고 있습니다. 이를 해결하기 위해 다음 단계를 수행할 수 있습니다.1. 최신 Docker Compose 버전으로 업데이트Docker Compose 파일을 최신 버전으로 업데이트합니다. Docker Compose 파일의 version 필드를 최신 버전으로 변경합니다.2. 최신 이미지 사용주키퍼와 카프카의 최신 이미지를 사용하도록 Docker Compose 파일을 업데이트합니다. 아래 예시는 최신 이미지를 사용하도록 수정된 docker-compose.yml 파일입니다.version: '3.8' # 최신 버전으로 변경services: zookeeper: ..

💡요즘 왜 다들 카프카, 카프카 하는 걸까?    - 대규모 실시간 데이터 스트리밍을 위한 분산 메세징 시스템    - 높은 처리량 및 개발 효율을 위한 분산 시스템에서 고가용성과 유연함을 갖춘 연계시스템이 필요 카프카 Overview1. Producer & ConsumerProducer - 메세지를 카프카 브로커에 적재(발행)하는 서비스Consumer - 카프카 브로커에 적재된 메시지를 읽어오는(소비) 서비스         - 메세지를 읽을 때마다 파티션 별로 offset을 유지해 처리했던 메세지의 위치를 추적         - CURRENT-OFFSET            컨슈머가 어디까지 처리했는지를 나타내는 offset이며, 동일한 메세지를 재처리하지 않고, 처리하지 않은 메세지를 건너뛰지 않기..

### 1. 문제 **(과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)**이번 주차를 지나며 겪었던 문제가 무엇이었나요?index와 msa 관련 서비스 트랜잭션 별로 나누는 것은 처음이여서 문제가 어렵게 느껴졌습니다. ### **2. 시도** 문제를 해결하기 위해 어떤 시도를 하셨나요?멘토링, 학습매니저님의 지식을 적극 활용했습니다. ### **3. 해결** 문제를 어떻게 해결하셨나요?블로그에 보고서를 작성하면서 제가 모르는 부분을 하나씩 찾아봤습니다. 찾아보면서제 상황에 대입해 문제를 하나씩 풀어갔습니다. ### **4. 알게된 것** 문제를 해결하기 위해 시도하며 새롭게 알게된 것은 무엇인가요? 과연 이해할 수 있을까 싶었던 index 문제는 보고서를 작성하는 개념이 좋았던 것 같습니다.단일 인..

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

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

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