이아손의 아르고호

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

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..

1. 프록시 패턴이란? 특정 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴. 구성요소 1) Proxy - 프록시 객체가 RealSubject에 대해 접근할 수 있도록 참조를 갖는다. - RealSubject와 Subject 인터페이스가 동일하다면 프록시는 Subject에 대한 참조를 할 수 있다. - RealSubject에 대한 접근을 제어하며, 생성/참조에 대한 권한을 가질 수 있다. 2) Subject - RealSubject와 Proxy의 공통 인터페이스이며, RealSubject가 필요한 곳에 Proxy를 통해 사용할 수 있도록 한다. 3) RealSubject - 프록시가 대신하는 실제 객체를 정의한다. 프록시의 종류 1) Remote Proxy: 요..

기록하게된 이유같은 기능을 수행하는 코드가  중복으로 여러 비즈니스 로직에 흩어져 있던 부분을 Spring AOP를 활용하여 해결한 내용을 기록한다. 이슈 사항Open API를 운영하면서 응답 내 ID 필드가 마스킹이 누락되어 있어서 수정하려 소스를 확인해보니 어느 특정 API만 마스킹이 안되고 있었다.모든 API들의 마스킹 로직을 전수 조사 해보니 다음과 같은 구조였다.@Datapublic class OrderDto { private String id; private String email; // ... 나머지 코드 public String getId() { return MaskingUtil.maskData(this.id, MaskingType.ID); } ..

기존 레거시를 msa 서버 어플리케이션으로 이관 후 중복처리가 발생한 에러에 대해 회고록을 남긴다.1. 내용 파악레거시 프로젝트를 이관하면서 에러 케이스에 대비해 다음과 같은 정책을 적용했다.- 모니터링 기간 동안 모든 request는 기존 레거시 프로젝트가 받는다.- 레거시 코드 안에서 이관한 API를 retrofit2client로 호출- 이관 API 에러 응답 시 기존 레거시 코드 실행 코드의 느낌은 대략 이렇다./* 레거시 프로젝트 컨트롤러 */...public Response legacyProcess(Request request) throws CustomException { try { Response result = getNewApiService().callNewAPI(reque..

1. 스테이트 패턴이란? 스테이트 패턴을 이용하면 객체의 내부 상태가 바뀜에 따라서 객체의 행동을 바꿀 수 있다. 마치 객체의 클래스가 바뀌는 것과 같은 결과를 얻을 수 있다. 구성요소 Context - 클라이언트가 필요한 인터페이스르 정의한다. - 현재 상태를 나타내는 ConcreteState 서브클래스를 유지한다. State - 특정 상태에 해당되는 기능들이 정의된 인터페이스를 선언하고 있다. ConcreteState - 각 서브클래스는 해당되는 상태의 기능들을 구현한다. 2. 동기 장점 - 상태에 특화된 행동들을 분리하고, 새로운 행동을 추가하더라도 다른 행동에 영향을 주지 않는다. - 코드 복잡도를 줄일 수 있다. - 상태의 전환이 명시적으로 변한다. 단점 - 구조의 복잡도가 증가한다. 3. 구현..