Official-Dev. blog

해당 포스팅에서는 아래 강연의 내용을 참고해서 작성합니다. 참고: https://www.youtube.com/watch?v=v9rcKpUZw4o&t=928s 채널계와 계정계 왜 은행에서는 1개월, 3개월, 6개월 등 기간에 따른 입금+출금 내역을 조회할 수는 있지만, 무한 스크롤 UI를 제공하지 않을까? 일반적으로 은행 시스템은 아래 구조로 분리되어 있다. 계정계 - 실제로 유저의 돈을 다루며, 원본 데이터가 저장됨 (아주 높은 신뢰도 요구) 채널계 - 유저의 요청을 직접 받아 계정계로 전달 예로 토스 뱅크에서는 채널계는 여러개의 서버와 여러개의 DB로 분리되어 있다. 서버의 Scaleout이 용이하고, DB 부하가 커지면 DB를 분리하기 쉽다. 트랜잭션 처리가 불편하다. 반면 계정계의 경우 아주 높은 ..

만약에 특정 기업에서 선착순 50명에게 맥북을 1만원에 파는 이벤트를 한다고 하자. 동시성 이슈를 어떻게 처리할 수 있을까? 문제 상황 '그냥 DB에 Select하고 50명이 없을 경우 Insert하면 되지 않나??' 라고 생각하면 안된다. 다수의 스레드가 SELECT를 수행한 시점에 재고가 있었다면 모두 Insert를 수행할 것이다. 이러한 실시간 선착순 이벤트에서 고려해야 하는 부분은 다음과 같다. 동시성을 어떻게 보장할 지 (feat. 다수의 스레드, 다수의 서버) 한 번에 쏠리는 트래픽을 어떻게 처리할 지 1. Queuing(Redis) 대표적인 솔루션으로 큐잉을 적용할 수 있다. Redis의 경우 분산 처리가 가능하고 자원 낭비가 적고 효율적이라서 대용량 트래픽을 효과적으로 처리할 수 있고, 싱..

MSA간 메시지를 주고 받는 것이 필요할 때가 있다. MSA에서 아래 서버가 있다고 가정하자. 송금 시스템 메일 알림 시스템 송금 시스템은 송금이 완료되면 메일로 알림을 보낸다. 가장 쉬운 방법은 동기 API 호출을 떠올릴 수 있다. 동기 API 호출 - 문제점 내가 다니는 회사의 레거시한 시스템의 경우 동기 API 호출을 통해 MSA에서 메시지를 주고받고 있다. 짐작 가능한 단점은 당연히 아래의 문제가 있다. 서비스 간 성능 및 장애를 공유하게 된다. (1개 시스템의 장애가 MSA 전체의 처리량 저하 및 장애로 이어질 수 있다.) 서비스 간의 강결합이 생긴다. (메일 알림이 실패하면 송금도 실패함) 사실 이번 글에서 다루고자하는 내용은 해당 내용보다는 아래의 내용이다. 동기로 API 호출을 한다고 해서..

처리량이 서버에 미치는 영향 (+ 비동기, CQRS) 최근 CQRS를 공부해보면서 처리량이 서버에 미치는 영향을 알게 되었다. 우아한 형제들의 강연을 보면 아래와 같은 CQRS 아키텍처를 많이 사용함을 알 수 있다. 하지만 우아한 형제들에 다니시는 전 동료분께 여쭤보니 모든 시스템이 해당 아키텍처를 적용하는 것은 아니라고 했다. 전사 Default는 Slave DB를 활용하는 정도의 느낌..? 프론트 서버나, 상품 노출, 가게 노출 등 도메인에서는 활발하게 적용 그래서 해당 아키텍처를 적용하는 기준(?) 같은 것이 있냐고 묻자, 중요한 힌트를 얻었다..! 앱쪽과 가깝게 위치한 서버에서는 1ms의 latency에도 매우 민감하다 Thread가 요청을 처리하지 못하고 쌓일 때 생기는 문제들 때문 비동기와 C..

최근 가장 궁금했던 것 중 하나가 MSA에서 이벤트 기반 아키텍처를 구축하는 방법이다..! 사실 뭐 어렴풋이 도메인 이벤트(내부 이벤트)와 메시징 시스템(외부 이벤트)를 사용해서 Publisher와 Subscriber 형태로 구축하면 되겠지..? 라고 생각했지만, 실무자의 경험이 듣고 싶었다. 그래서 해당 포스팅에서는 권용근님의 회원시스템 이벤트기반 아키텍처 구축하기라는 강연을 보고 나름대로 정리하는 것을 목표로 한다. 강연 Link: https://www.youtube.com/watch?v=b65zIH7sDug&t=794s 무엇을 이벤트로 발행할 것인가? Micro-Service Architecture(MSA)를 언급할 때 Event-Driven Architecture를 함께 언급하게 된다. 마이크로서..

해당 포스팅은 "B마트 전시 도메인 CQRS 적용하기"라는 강연의 내용을 정리한 글이다. https://www.youtube.com/watch?v=fg5xbs59Lro CQRS CQRS는 Command and Query Responsibility Segregation의 약자로 명령과 조회의 책임을 분리라는 뜻이다. 이전에 CQRS의 내용을 정리한 적이 있는데 외부 강연들을 보면서 추가로 궁금한 사항들이 생겼다. 왜 조회 모델을 DB에 저장을 할까..?!, 데이터가 변경되면 어떻게 Pub/Sub를 적용해서 조회 모델에 반영될까?... (이전 포스팅: https://jaehoney.tistory.com/255) B마트 전시 도메인 CQRS 적용하기라는 강연에서 CQRS에 대해 조금 더 자세히 설명해준다. 해..

해당 포스팅은 [우아콘2020] 배민 프론트서버의 사실과 오해 라는 아주 멋진 강연을 해석하는 것에 중점을 둔다. Link: https://www.youtube.com/watch?v=38cmd_fYwQk 프론트 서버 프론트 서버란 사용자 전면에서 요청을 처리하는 서버를 말한다. 즉, 이렇게 앱과 통신을 직접적으로 하는 서버를 말한다. 수많은 외부 서비스의 실시간 상태가 필요 프론트 서버에서 1개의 가게를 노출하는데 필요한 외부 요청 수가 13번이었다. 하나의 요청을 보내는 데 걸리는 시간은 50ms이지만, 13번이면 650ms로 사용자에게 느리게 느낄 수 있는 속도이다. 그래서 비동기 방식의 요청이 필요했다. 비동기 요청을 하면 13개의 요청 중에서 가장 늦게 처리되는 요청의 수행 시간이 전체 요청 시간..

개요 1개 애플리케이션에서 여러 개의 DB 서버를 사용한다면 Java의 경우 JTA나 ChainedTransactionManager 등을 사용해서 분산 트랜잭션을 사용할 수 있다. 문제는 MSA에서 트랜잭션을 어떻게 보장하냐는 것이다. 결제을 한다고 하면 아래의 마이크로 서비스와의 연동이 있을 수 있다. 주문, 배달, 리워드 해당 기능들이 결제 서버, 주문 서버, 배달 서버, 리워드 서버 등으로 분리되어 있다. 트랜잭션을 어떻게 관리할 수 있을까? 2PC (Two-Phase Commit) 2단계에 거쳐 영속하는 작업을 말한다. 해당 가상의 서비스에서는 주문이 끝나면 회원에 등록된 카드로 금액이 결제 되어야 한다. 배달이 진행되어야 하고 사용한 포인트는 차감되어야 한다. Transaction Coordin..

장점 각 서비스를 독립적으로 배포가 가능하다. 유연한 확장 코드 관리가 편리하다. (git conflict 가능성 감소) 책임이 명확하게 분리된다. 장애 범위가 축소된다. 광고 서비스가 장애나도 전체 범위로 확산되지 않음 팀별 코드 이해도 증가 생산성 증가 출시 시간 단축 단점 구현 난이도 상승 API 사용 범위 파악이 어려움 해당 API 스펙을 변경하면 예상 치 못한 서비스에서 장애가 날 수 있음 리소스 비용이 크다. 서버가 많이 필요 배포가 훨씬 더 많고 잦음 트랜잭션 관리가 복잡함 분산 서비스마다 트랜잭션 관리를 처리해야 함 메시징 시스템이 필요할 수 있음 통합 테스트가 어려움

스토리지의 종류 최근에 사이드 프로젝트를 담당하게 되면서 영상물을 서버에 저장하는 작업이 필요했습니다. 제가 아는 서버에 파일을 저장하는 방법은 두 가지였습니다. DB에 파일명, 확장자와 BinaryData로 내용을 저장하는 방법 파일을 서버에 저장하고 DB에서는 그것을 꺼내쓸 수 있는 데이터만 저장하는 방법 어떤 것이 좋을 지 궁금해서 당근마켓 피드 & 디스커버리 팀에서 일하는 지인에게 어떤 것을 사용하냐고 물어봤어요! 결론은 예전에는 첫 번째 방법처럼 DB에 BinaryData로 저장하다가 CDN 사용 이점때문에 두 번째 방법으로 갈아탔다고 하네요. 추가로 오브젝트 스토리지에 영상물을 저장한다고 했습니다. 저는 오브젝트 스토리지가 어떤 것인지도 잘 몰라서 스토리지 종류에는 어떤 것이 있는 지 알아보기..