Official-Dev. blog

Pinpoint는 Naver에서 2015년에 오픈소스로 공개한 APM 도구이다. 분산 환경에서 JVM 언어 기반으로 작성된 서버에서 많이 사용한다. APM이란 ? APM이란 Application Performance Management / Application Performance Monitoring의 약자이다. 즉, 애플리케이션의 성능을 관리/모니터링 한다고 보면 된다. APM 도구를 사용하면 서버에서 발생하는 메트릭(CPU, Memory, Thread, Transaction, …), 이벤트, 로그, 트랜잭션 등을 모니터링할 수 있다. 이렇게 분석한 데이터는 아래의 목적을 위해 활용할 수 있다. 성능 문제를 예측하고 방지 고객 기대 성능 보장, 고객 경험 향상 응답 시간 보장 가용성 증대, 다운타임 감..

GraphQL 이란 2012년 페이스북의 클라이언트 데이터 전송 방식 개선 목적으로 시작되었다. GraphQL이란 클라이언트와 서버의 통신 명세이다. (REST와 마찬가지로 실체는 없다.) 명세를 기반으로 다양한 라이브러리가 생성되었다. 구조(스키마)와 행동(리졸버)로 구성된다. vs REST API GraphQL과 REST API의 차이를 알아보자. GraphQL REST 구성 스키마 / 타입 시스템 URL endpoints 동작 Query, Mutation, Subscription CRUD End-point 단일 접점(API 1개) URL 집합 데이터 포맷 Only JSON JSON, XML, … 관점 클라이언트 주도 설계 서버 주도 설계 러닝 커브 어려움 보통 (비교적 쉬움) 그러면 이러한 차이는 ..

이전에 Java Spring에서 샤딩을 처리하지 못하던 이슈를 해결한 경험이 있다. 해결 과정: https://jaehoney.tistory.com/180 그때 당시는 해당 기술이 샤딩(Sharding)인지도 몰랐다. 참고로 당시 0년차였다.. 추가로 당시는 대단한 일을 한 것처럼 느껴졌지만 지금은 샤딩을 처리하는 다양한 기술들을 알게 되었다. Naver D2, 우아한형제들 기술블로그, 카카오 뱅크 발표, 요기요 기술 블로그, ... 그래서 이전에 구현한 코드를 어떻게 개선할 수 있을 지 생각해보기 위해 포스팅을 하게 되었다. 샤딩을 처리하는 방법 DB 서버 1대로 트래픽이나 저장량이 감당이 안될 때, Local cache나 Global cache를 동원하기도 한다. 그리고 Master-slave 패턴을..

현재 고객 서비스를 위해 도메인 별로 시스템을 만들어서 MSA 환경을 구축하고 있다. 각 클라이언가 직접 마이크로 서비스를 호출하는 것에는 문제점이 있다. 클라이언트와 마이크로 서비스 간의 강한 결합 개별 마이크로 서비스에 대해 많은 통신이 필요하다. 엣지 기능을 각각의 마이크로 서비스가 직접 구현해야 한다. 보안 및 권한 처리 장애 처리 로깅, 모니터링 요청 개수 제한 캐싱 ... API Gateway 패턴을 사용하면 단일 접점을 활용해서 각각의 마이크로 서비스의 내부에 대해 알 필요가 없다. 즉, API 내부 동작에 대한 캡슐화가 이뤄지고 강한 결합이 끊어진다. 그리고 API Gateway가 공통된 기능을 제공하게 되어 각 마이크로 서비스의 책임이 가벼워진다. 단일 진입점을 제공 각 엣지 기능을 한 ..

해당 포스팅에서는 아래 강연의 내용을 참고해서 작성합니다. 참고: 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에 대해 조금 더 자세히 설명해준다. 해..