아키텍처와 마이그레이션
주제 허브

큰 시스템을 멈추지 않고 어떻게 바꾸나

아키텍처와 마이그레이션

모듈러 모놀리스와 이벤트 중심 설계, 레거시 위에 세운 검증 로직, 스트랭글러 패턴과 무중단 전환. 설계 결정을 내린 이유와 그 결정을 되돌린 이유를 모은다.

56편 직접 만들고 재 본 것 42 기술 블로그 리뷰 7 컨퍼런스 발표 리뷰 7 최근 글

직접 만들고 재 본 것

42편
  1. 모듈식 모놀리스를 선택한 이유 — MSA의 유혹을 거부하기
  2. 가격이 아니라 이벤트를 팔자 — monticker 설계 철학
  3. Shadow Release로 조회를 옮기기: MyBatis 결과와 QueryDSL 결과를 나란히 비교하며 전환한 기록
  4. 타임아웃, 재시도, 백오프 - 증폭과 지터, 그리고 데드라인 전파
  5. spring-internals-lab로 다시 읽는 Spring 1 - 이 프로젝트는 무엇을 검증하려는가
  6. API 버저닝과 호환성 - 스키마 진화 규칙
  7. 분산 트랜잭션 - 2PC와 Saga, 보상 트랜잭션이 실패하는 방식
  8. 모듈러 모놀리스 - 경계를 코드로 강제하는 방법
  9. spring-lite로 이해하는 Spring 구현 1 - 프로젝트 구조와 설계 범위
  10. 트레이스 샘플링 - 헤드와 테일 샘플링의 선택 기준
  11. 멱등성 설계 - 키의 단위와 저장 위치, 만료와 재시도 계약
  12. 토스증권 Kafka 데이터센터 이중화 리뷰: 미러링보다 오프셋이 어렵고, 재난과 작업의 기준이 다르다
  13. 이벤트 소싱과 CQRS - 언제 비용이 이익을 넘는가
  14. 토스증권의 CQRS·검증기와 ParityPay의 스냅샷·대사: 읽기 모델을 분리하면 반드시 따라오는 세 가지 장치
  15. 토스증권 공개 자료로 읽는 시세·주문 아키텍처: 무엇을 잃어도 되는지 먼저 정한다
  16. 시간과 순서 - 물리 시계의 한계, 논리 시계, 하이브리드 시계
  17. REST, gRPC, GraphQL - 선택 기준과 각자가 내는 비용
  18. redis-lite-java로 이해하는 Redis 아키텍처 개요
  19. 합의 알고리즘 - Raft를 상태 기계로 읽기
  20. 멱등한 API 설계 - HTTP 메서드의 의미와 재시도 계약
  21. ParityPay로 검증하는 결제 정합성 1 - 장애가 나도 지켜야 할 금융 불변조건 여섯 가지
  22. 키 생성 병목을 추적해 구조를 바꾼 기록: Part 3 - 채번을 INSERT 시점으로 옮기고 범위 단위로 받기
  23. 일관성 모델 - 선형화, 순차, 최종 일관성, 그리고 CAP를 설정값의 언어로
  24. 대량 배치 안정성을 높이기 위한 구조 개선: Part 5 - 배타적 락과 조건부 해제로 순서를 보장하기
  25. 키 생성 병목을 추적해 구조를 바꾼 기록: Part 1 - INSERT가 느린 줄 알았다
  26. 위반 480건 위에 아키텍처 규칙을 도입하기: 신규 코드는 100% 강제, 레거시는 점진 정리
  27. Bulkhead Pattern
  28. 모든 도메인이 100% 정합성을 요구하지는 않는다: Post-Commit 이벤트와 재시도 3회 정책을 정한 기준
  29. 폴링 배치를 SQS 이벤트 파이프라인으로 바꾼 이유: 재시도, DLQ, 메시지 ID 멱등
  30. Microservice Architecture
  31. Redis 기반 인증 토큰 관리로 분산 환경의 인증 일관성 확보
  32. JSP 기반 시스템의 구조적 문제를 해결한 아키텍처 전환기: DTO 중심 아키텍처 전환과 검증 체계 개선
  33. JSP 기반 시스템의 구조적 문제를 해결한 아키텍처 전환기: 시퀀스 테이블 기반 코드 생성의 병목을 해결한 이야기
  34. JSP 기반 시스템의 구조적 문제를 해결한 아키텍처 전환기: MyBatis와 JPA 공존 환경의 데이터 정합성 전략
  35. JSP 기반 시스템의 구조적 문제를 해결한 아키텍처 전환기: API 명세 없는 레거시 시스템의 신규 시스템 이관 전략
  36. JSP 기반 시스템의 구조적 문제를 해결한 아키텍처 전환기: JavaScript에 과도하게 집중된 로직 분리하기
  37. DB 스키마만으로 외주 시스템을 내재화한 리빌딩 여정
  38. Spring 애플리케이션에서 예외를 설계하는 방법
  39. Microservice Architecture
  40. Unique ID Generation Strategy in Distributed Systems
  41. Microservices Architecture
  42. Facade

기술 블로그 리뷰

7편
  1. 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  2. 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  3. 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  4. 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  5. LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  6. 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  7. 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다

컨퍼런스 발표 리뷰

7편
  1. SLASH 23 리뷰 - 은행 최초 코어뱅킹 MSA 전환기 (feat. 지금 이자 받기): 80회 DML을 50회로, MCI 대비 170배, 빅뱅 없는 전환
  2. SLASH 24 리뷰 - 토스뱅크가 차세대를 하지 않는 이유, 지속 가능한 마이그레이션 전략: 스트랭글러 피그, 6단계 사이클, 컴포지트 분할 정복, 병렬 실행 비교 검증
  3. SLASH 24 리뷰 - 리플레이 검증으로 새로운 금융 시스템 안전하게 도입하기: 운영 트래픽을 그대로 재생해 차세대 원장을 검증하다
  4. SLASH 23 리뷰 - Kafka 이중화로 다양한 장애 상황 완벽 대처하기: Active-Standby를 믿지 않고 Active-Active로 간 이유와 IDC 장애 당일의 순서
  5. SLASH 24 리뷰 - Next 코어뱅킹, MSA와 MySQL로 여는 평생 무료 환전 시대: Oracle을 버린 이유, 30ms 환전, 자정에도 멈추지 않는 잔액 대사
  6. SLASH 22 리뷰 - 왜 은행은 무한스크롤이 안되나요: 채널계가 거래내역을 직접 갖기 위한 여덟 가지 방어
  7. SLASH 21 리뷰 - 결제 시스템의 SDK와 API 디자인: 4단계를 2단계로, DELETE·PUT을 버린 이유, 한글 enum