이아손의 아르고호

기록하는 이유분산 트랜잭션을 처음으로 적용해보면서 어떤 논리로 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..

기록하게된 이유같은 기능을 수행하는 코드가  중복으로 여러 비즈니스 로직에 흩어져 있던 부분을 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..

기록하게 된 이유회사 프로젝트를 진행하면서 jwt를 처음 활용했는데 그 과정에서 배운 내용들을 정리해본다.요구사항정산과 관련된 서비스에 실명인증 프로세스가 필요하게 되어서 개발을 맡게 되었다.인증 완료까지 한 화면에서 두 단계를 걸쳐서 이뤄져야 했다. 1) 인증하기 버튼을 누르면 기입된 정보로 실명인증을 해주는 외부기관의 API로 제대로된 정보임을 확인 받고2) 인증 성공 후 아래 버튼이 활성화 되며 해당 버튼을 누르면 실명인증이 완료된 회원이라는 정보를 DB에 저장하는 API로 처리이렇게 한 화면에서 1) 2) 과정이 두 API로 분리되기 때문에 고민해야될 부분이 생겼다.2단계 실명인증 과정에서 해당 요청을 보낸 유저가 1단계를 정상적으로 거쳤다는 것을 어떻게 보장하느냐가 문제였다.추가로 혹시나 많이 ..

백엔드 개발을 하다보면 반드시 보게 되는 NGINX인데 정확히 어떻게 돌아가는지, 왜 다른 웹서버들 보다 좋은지 몰랐다. NGINX 공식 웹페이지에서 좋은 참고 자료들을 찾을 수 있었는데 그 중 한 아티클을 통으로 번역해 보았다. 원문: https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/ Inside NGINX: How We Designed for Performance & Scale NGNIX는 현재 웹 성능 분야에서 선두주자이다. 그리고 이렇게 될 수 있었던 이유는 바로 설계 디자인에 있다. 많은 웹 서버나 어플리케이션 서버들이 간단한 스레드/프로세스 기반 아키텍처를 가지는 반면, NGINX는 정교한 이벤트 기반 ..