이아손의 아르고호

IntroMSA 환경에서 운영 중인 서비스에서 간헐적으로 자원 고갈이 발생하는 케이스가 있었다.3rd Party에 제공하는 OpenAPI 서비스 중 리소스 heavy한 API로 특정 유저들이 요청을 몰아 보내면서 db thread pool이 고갈됐고, 얼마 지나지 않아 전체 서비스가 다운됐다.양상이 매우 비슷한 DDoS 공격 같은 경우 앞단 L4나 게이트웨이에서 IP기반으로 어뷰징 방지를 하고 있지만,application level 정보인 user-id 기반의 제어가 필요하게 되었고, 어플리케이션 내에서 Rate Limiter를 개발하게 되었다. 구현 내용Rate Limit를 적용하는 방법은 요구사항에 따라 다양하다 (Rate Limiter란 무엇인가 참고)이번 케이스에선 다음과 같이 설계하였다. 어플리..

Intro.파트 1에 이어서 실제 운영환경에서 사용하면서 발견한 주의점들을 정리해보겠다.https://argonautsfleece.tistory.com/116 [MSA] Hystrix - 12년 전 maintenance 모드로 진입한 라이브러리를 굳이 이제와서 정리하는 이유는..여전히 사용 중이고(Resillience4j로 전환 중이긴 하지만) 최근에 HystrixBadRequestException 관련 운영 이슈를 겪으면서 이것argonautsfleece.tistory.com 1. Hystrix Timeout의 한계 @HystrixCommand( fallbackMethod = "getUserFallback", commandKey = "GetUserById", ..

2년 전 maintenance 모드로 진입한 라이브러리를 굳이 이제와서 정리하는 이유는..여전히 사용 중이고(Resillience4j로 전환 중이긴 하지만) 최근에 HystrixBadRequestException 관련 운영 이슈를 겪으면서 이것저것 파보면서 알게 된 내용이 많다.MSA 시스템에서 중요한 부분을 담당하기 때문에 지금이라도 그 필요성을 이해하고 내부 동작 방식에 대해 공부하는 것이 나중에도 많은 도움이 되리라 생각하고 알게 된 내용을 적어본다. 추가로 선수지식이 어느 정도 필요한데, 소스를 이해하기 위해선 아래 개념들은 알고 있는게 이해에 도움이 될 것 같다.- java Future- rx Observable (hot/cold) 이 글은 Hystrix의 사용법에 대해선 자세히 다루지 않고 소..

기록하는 이유분산 트랜잭션을 처음으로 적용해보면서 어떤 논리로 SAGA 패턴을 적용했고 개발하면서 배우게 된 내용들을 기억하기 위해 기록해보려 한다. 시스템 요구사항"계약 완료" 라는 기능 구현을 하게 되었는데 다음과 같은 시퀀스로 수행되어야 한다. 1. 계약 검증 (DB A: MySQL)현재 요청한 계약서가 검토과정을 거쳐서 계약 완료 상태로 전환이 가능한지 확인. (이 상태 정보는 DB A (mysql)에 들어있음) 2. 계약 확정 (DB B: Oracle)전환이 가능한 상태면 페이지에서 기입한 계약 사항을 확정하고 이걸 DB B (oracle)에 저장 3. 외부 인증 및 이력 기록 (DB C: Oracle)확정된 계약 정보를 외부 인증 API에 HTTP 요청으로 전송하여, 제3 인증 파티에서 계약 ..

기록하게 된 이유Spring Batch로 신규 배치 잡 개발을 하던 중 jobParameter가 의도하지 않은 방식으로 작동하면서 알게 된 내용들을 정리해본다. 발생한 이슈외부 시스템과 데이터를 실시간으로 동기화 하는 배치가 있는데, 일부 누락 건들이 발생하면서 이 누락 건들을 재시도하는 배치를 개발했다.이 신규 재시도 배치를 실행 시 argument에 따라 두 가지 방법으로 실행하도록 했는데 1. argument 가 없을 시 -> runtime 중 default 조회 시간대 생성 (당일 00:00 ~ 23:59)2. argument 가 있을 시 -> 입력한 argument에 따라 조회 시간대를 생성 @Getter@NoArgsConstructor@ToStringpublic class SampleJobP..

1. 2PC의 개념2PC는 분산환경에서 트랜잭션의 원자성을 지키기 위해 사용하는 프로토콜이다. 무엇이 문제인가흔히 말하는 MSA 환경: 서비스 단위로 DB와 서버 어플리케이션이 분리되어 있는 환경에서여러 인스턴스 & 각 DB를 거치는 트랜잭션(이를 분산트랜잭션이라 한다)을 어떻게 all or nothing으로 처리할 수 있는가?이런 환경에서는 db transaction (begin, end) 또는 서버 어플리케이션 코드 단위의 트랜잭션 기능(ex. @Transactional)은 원자성을 보장해주지 못한다.이를 해결하기 위해 등장한 것이 2PC이다.우선 알아야 할 단어가 있는데 바로 노드다. 노드란: 분산 시스템 내에서 트랜잭션에 참여하는 개별 인스턴스 or 서버 (주로 DB)를 지칭한다.노드는 두 가지 ..

기록하게 된 이유외부에 공개되어있는 API를 운영하면서 간단한 방법으로 업무를 매우 효율적으로 처리한 경험을 회고로 정리해본다.MSA 에서 어떻게 트레이싱이 이뤄지는지 조금 더 깊게 알게 된 좋은 계기 되었다. 이슈 사항외부에서 사용할 수 있게 공개한 API를 운영을 하다가 보면 다양한 문제를 겪게 된다.실제 로직 상 이슈가 있어서 수정이 필요한 경우도 있지만, 클라이언트 단에서 잘못 요청을 줬거나 API 스펙에 대한 이해도가 떨어지는 상황에서 문의를 하는 등 문제 자체는 복잡하지 않은 경우가 대부분이다. 하지만 운영자 입장에서는 상황 파악에 필요한 정보들은 문의 내용 내 파편화 되어있고, 이를 바탕으로 해당 로그를 찾기엔 생각보다 어렵다.- 문의 내용 내 이슈가 발생했던 정확한 시간이나 어떤 응답을 받..

기록하게 된 이유팀 서비스 중 OOM으로 장애를 겪은 회고를 적어본다.장애가 실제 발생했을 때는 사실 GC나 jvm memory에 대한 경험이 부족해서원인 분석을 위해 어디부터 확인해야 될지 몰랐고, 허겁지겁 찾느라 원인 후보들에 대한 이해가 완전하지 않았다.하지만 다시 내용을 처음부터 살펴보니, 에러가 발생한 원인은 정말 생각지도 못한 부분이라 개인적으로 흥미로웠고,공부할 만한 내용들이 많다고 생각들어서 늦게나마 회고 형태로 정리해본다. 장애 상황서비스 중인 서버 10대 중 대부분에서 DB Connection 에러와 함께 java oom 이 발생했다.1차 대응으로 전체 was를 재기동 해봤지만, 얼마 지나지 않아 서비스 중단은 계속됐다. 용의자 1. Slow QueryDB connection과 java..