마이크로서비스

MSA로 전환 시 고민해야 할 분산 데이터 관련 문제가 트랜잭션만 있는 것은 아닙니다. 쿼리를 구현하는 방법도 찾아내야 합니다. 💡 트랜잭션 문제 해결 법 → [MSA] 마이크로서비스 사가 패턴 [MSA] 마이크로서비스 사가 패턴 단일 DB에 접근하는 모놀리식 애플리케이션의 트랜잭션 관리는 어렵지 않습니다. 하지만 다중 DB, 다중 메시지 브로커를 사용하는 모놀리식 애플리케이션이나, 자체 DB를 가진 여러 서비스로 구 sawaca96.tistory.com DB가 하나뿐인 모놀리식 애플리케이션에서는 비교적 쉽게 쿼리를 구현했습니다. 하지만 MSA에서는 의외로 쿼리를 작성하기가 어렵습니다. 여러 서비스 여러 DB에 분산된 데이터를 조회해야 하기 때문입니다. 이를 해결하기 위한 2가지 패턴이 있습니다. API..

단일 DB에 접근하는 모놀리식 애플리케이션의 트랜잭션 관리는 어렵지 않습니다. 하지만 다중 DB, 다중 메시지 브로커를 사용하는 모놀리식 애플리케이션이나, 자체 DB를 가진 여러 서비스로 구성된 MSA는 트랜잭션 관리가 어렵기 때문에 좀 더 정교한 메커니즘이 필요합니다. 따라서 서비스가 분리되면서 ACID(원자성 Atomic, 일관성 Consistency, 격리성 Isolation, 지속성 Durability) 트랜잭션으로 관리해 오던 단일 DB를 ACD 사가로 관리하는 다중 DB 아키텍처로 전환해야 합니다. 💡사가(sage)는 ACID에서 Isolation이 빠진 ACD만 지원하는 로컬 트랜잭션입니다. 사가를 이용해서 여러 서비스에 걸친 트랜잭션을 구현하고 데이터 일관성을 유지하는 방법에 대해 알아보겠..

모놀리식 애플리케이션은 대부분의 모듈이 언어 수준의 메서드나 함수를 통해 서로 호출하기 때문에 REST API나 클라우드 서비스 연계 모듈을 작성하지 않는 이상 IPC는 크게 신경 쓸 필요가 없습니다. 이와 달리 MSA는 애플리케이션을 여러 개의 서비스로 구성하며 서비스는 대부분 요청을 처리하기 위해 서로 협동합니다. 서비스 인스턴스는 여러 머신에서 실행되는 프로세스 형태이므로 반드시 IPC(Inter-Process Communication)를 통해 상호 작용해야 합니다. 이번 글에서는 IPC의 종류와 가용성 측면을 따졌을때 MSA에서 어떤 IPC를 쓰는 것이 좋은지 알아보겠습니다. 동기 RPI 통신 💡 RPI는 클라이언트가 서비스에 요청을 보내면 서비스가 처리 후 응답을 회신하는 IPC입니다. 💡 메시..

아키텍처는 확장성 신뢰성 관리성 테스트성 배포성등 ~성 으로 끝나는 서비스 품질 요건에 영향을 미칩니다. 따라서 어떤 아키텍처를 사용하느냐에 따라 품질 요건을 얼마나 충족할 수 있을지 결정됩니다. 오늘은 마이크로서비스 아키텍처에 대해 알아보도록 하겠습니다. 💡본문에서 마이크로서비스 아키텍처를 MSA(MicroServiceArchitecture)라고 부르겠습니다. MSA는 애플리케이션을 느슨하게 결합된 여러 서비스로 구성하는 아키텍처 스타일입니다. 💡여기서 서비스란 어떤 기능이 구현되어 단독 배포가 가능한 소프트웨어 컴포넌트입니다. 느슨하게 결합된 서비스는 구현 코드를 감싼 API를 통해서만 상호 작용하므로 클라이언트에 영향을 끼치지 않고 서비스 내부 구현을 바꿀 수 있습니다. 그리고 애플리케이션 개발 시..