기록창고

트랜잭션을 열때 하지 말아야할 것.. 😢 트랜잭션 사이에 기이이인 무언가을 넣지 말아야함 기이이인 무언가란? 시간이 오래 걸리는 연산 - 이런건 연산을 마치고 결과만 저장할때 외부요청 - 레디스든 msa 구조라서 다른 곳을 다녀와야 한다는 등등.. 외부의 장애가 바로 전파된다.. 트랜잭션을 열고, 커넥션을 잡고 A 라는 곳에 요청을 보냇는데 죽거나 장애가 있어서타임아웃을기다리게 된다면.. 어흑.. 바로 커넥션 풀에 있는거 다 쓰고 모든 요청이 디비만 기다리다가 다 500 ... 그래서 상태처리가 중요한 요청은 request 로 기록을 해두고, 요청을 보낸 다음에 다시 상태를 done 이나 fail 처리한다. class AService { fun sendMoney(to: String, from: Strin..

만약 connection pool 에서 모든 커넥션을 쓰고 있다면 어떻게 될까? 서버가 터진당 ;; 🥶 요청이 오면 톰캣 쓰레드에서 쓰레드를 할당 받고, 처리하는데 디비에서 데이터를 꺼내는데 오래걸릴경우(인덱스를 안타거나, 원래는 캐시에 저장되어야했으나 등등..) 쓰레드들이 db 커넥션을 할당 받기 위해 기다리는데 그럼 점점 요청들이 쌓이기 시작한다.. 공급(쓰레드풀)이 수요(요청)를 못따라감.. msa 구조라고 할때, 요청한 서버에서 할 수 있는건 타임아웃으로 걸거나 서킷을 걸어놓는 것이다. 그럼 터진 서버에서 해야할껀..? 빵 터졋을때 대응할 수 있는건... 서버를 늘리면 된다! 요청을 분산시키는 것이다.. 쿠버네티스를 쓴다면 팟을 늘리면되겟다.. 허헣.. 그다음엔 어플리케이션에서 대응해야할껀.. d..

회사에서 장애가 낫다 A, B, C, D 서버가 있다고 가정한다 C -> B -> A D -> B -> A B 서버 입장에서는 꼭 A 의 데이터가 필요하지않는 경우였다. 필요는 하지만, 없어도 사용자에겐 문제가 없는 경우 C, D 는 꼭 B 가 필요하다. 위처럼 요청을 보내는데, A 서비스에 장애가 생겼다..! 그래서 A 의 응답이 너무 늦어졋다.. C, D 에서 요청을 계속 보내고있는데, B 는 A 의 응답을 기다리고 있어 점점 쓰레드는 부족해져다가 결국 503 이 발생했다. 결국 C, D 도 장애로 이어진것 방지책 서킷브레이커를 이용하여, A 서버로 보낸 요청이 응답이 늦어나, 안온경우가 일정시간 누적이 되면 서킷 활성화하여, 모든 요청을 서킷이 응답하게 만들고, B 에서는 그의 응답에 대한 대응을 ..