본문 바로가기

MSA해설80

이러한 이유로 MSA를 도입하면 안된다 https://microservices.io/post/architecture/2025/02/18/wrong-reasons-to-adopt-microservices.html The wrong reasons to adopt microservicesMicroservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.microservices.io 2025. 2. 19.
Solving distributed data problems in a microservice architecture https://www.youtube.com/watch?v=AEbJgpamZ4w2021.06.18  위의 내용에서 발췌, 설명  Loosely coupled microservicesDistributed data challenges in a microservice architectureTransactions in a microservice architectureQuerying in a microservice achitecture  Some coupling is inevitable (불가피한, 필연적인) BUT You must design services to be loosely coupled              Order Service에서 최초 Order 등록 시 상태는 PENDINGCustomer Se.. 2025. 2. 19.
공통 서비스 조직, 사용자, 권한, 공통코드 등 대부분의 업무 서비스에서 사용하는 데이터를 어떻게 관리할까? Batch Job 또는 CDC 솔루션을 이용할 수도 있다. 하지만 대량의 데이터를 주기적으로 전송하기 보다는 추가/변경되는 그 시점, 그때 그때 Event를 발행하면 어떨까? 원본 시스템에서 조직 추가가 완료된 후 그 Event를 발행하고, 또 다른 원본 시스템에서 권한이 변경이 완료된 후 그 Event를 발행하면 필요한 각 업무 서비스에서는 구독해서 저마다 필요한 형태로 사용하면 된다.  이러면 굳이 Batch나 CDC등의 솔루션이 필요없지 않을까? 주간이든 야간이든 Batch Job에 대한 부담도 없고. 조직 또는 사원과 같은 인사정보를 제공하는 기존 HR Legacy등이 당장 Event를 발행할수 없는 .. 2024. 12. 23.
병원정보시스템과 MSA Microservice architectures and open platforms for health care information systems https://www.linkedin.com/pulse/microservice-architectures-open-platforms-health-care-pablo/ 위의 내용중 발췌, 요약 EHR, LIS, RIS, PACS, Pharmacy 등 여러 clinical software는 개별적인 작동뿐 아니라 서로 영향을 주고 받으며 함께 운영되어야 하는데, 매우 복잡 그러므로 health care 영역에서의 good architecture design은 더이상 선택사항이 아님 MSA란 - 각 Component(Microservice)들이 Loosely Coup.. 2023. 6. 30.
배달 관련 간단 시나리오 배달앱을 실행한다. 오랫동안 주문을 안해서 그런지 본인인증을 먼저해야했다. 한식, 분식, 치키 등 음식 카테고리를 선택한다. 해당 카테고리에 조회된 가게중 하나를 선택한다. 최소주문금액, 리뷰 등이 적절한지보고 사진, 가격 등을 바탕으로 메뉴를 선택한다. 해당 메뉴의 옵션(매운맛, 토핑 등) 선택하고 장바구니에 담는다. 장바구니 내용을 확인 후 주문하기 버튼을 누른다. 내가 사용할 수 있는 포인트는 없었지만 5% 할인 쿠폰은 사용할 수 있었다. 배달정보에 내 전화번호, 요청사항, 결제금액을 확인후 결제하기 버튼을 누른다. 신용카드 결제수단을 선택후 결제한다. (PG(Payment Gateway, 전자결제지급대행)사를 통해 신용카드결제) 주문일시, 주문번호, 가게, 메뉴, 배달주소 등의 정보로 카카오톡 알.. 2023. 3. 13.
Microservice와 DB 요약 아키텍처 상의 특별한 제약(Cloud 제약, License제약 등)이 없는 한 서비스별로 분리해야 함 그렇지 않으면 Monolith의 단점이 지속됨 즉 MSA의 장점(독립성, 확장성, 장애격리 등)을 얻기 어려움 서비스별로 DB가 분리되면 타 서비스의 DB를 직접 접근할 수 없고 API, Publisher, Subscriber 와 같은 통신을 해야 함 설계의 어려움, 개발 생산성 등 당장의 현실적인 어려움으로 select 조회만 일부를 허용하기도 하지만 타 MSA 프로젝트에서도 select는 grant 부여 허용함에 따라 아래와 같은 일이 이어서 일어남 - select query에 포함된 function, sequence, procedure 등 나머지 객체도 조금씩 grant 부여 허용 - 결국 기존 M.. 2023. 2. 15.
간단한 외래 재활치료 시나리오 대학병원과 같은 큰 종합병원의 병원정보시스템을 OCS(Order Communication System) 라고도 부른다. 의사가 내는 처방(Order)을 간호, 약국, 원무과 등 여러곳에 전달한다는 의미에서 처방전달시스템이라고한다. 대략 아래와 같은 업무구분으로 구성되어있다. - 진료 : 처방, 간호, 진료의뢰 등 - 진료지원 : 약국, 영상의학, 의무기록, 영양, 감영, 치료방사선, 항암, 재활 등 - 원무 : 환자, 내원, 외래, 입원, 응급, 제증명, 자격, 미수 등 발목을 다친 어떤 환자가 외래 진료를 위해 다음과 같은 흐름을 가질 수 있다. 환자가 홈페이지를 통해 외래진료예약을 하려니 회원가입이 필수였다. 회원가입 후 진료과, 날짜, 시간, 진료의 등을 선택하고 외래진료를 예약했다. 예약시간에 맞.. 2023. 2. 14.
MSA 도입 https://youtu.be/SUtQnCxkCw0 2023. 1. 6.
Monolith와 Microservices https://www.youtube.com/watch?v=SR53SKIUYPA 위의 내용에서 발췌 Monolith는 이러한 이슈에 직면할 수 있다 수요에 따른 트래픽 증가 -> 응답이 느리거나 다운 여러 형태의 Front end 대응 가능 여러 팀에 걸친 다양한 기술 스택 여러 팀이 서로 다른 시점에 배포 2022. 12. 28.
쿠버네티스가 왜 필요한가 https://kubernetes.io/ko/docs/concepts/overview/ 쿠버네티스란 무엇인가? 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하 kubernetes.io 2022. 12. 28.
왜 굳이 도커(컨테이너)를 써야 하나요? https://www.44bits.io/ko/post/why-should-i-use-docker-container 왜 굳이 도커(컨테이너)를 써야 하나요? - 컨테이너를 사용해야 하는 이유 컨테이너는 서버 애플리케이션을 배포하고 서버를 운영하는 표준적인 기술이 되어가고 있습니다. 하지만 처음 사용해본다면 그 장점이 잘 와닿지 않을 수도 있습니다. 왜 굳이 도커 컨테이너를 www.44bits.io 2022. 12. 28.
Kafka 개념, 특징 https://unit-15.tistory.com/135 [Kafka] 카프카 기본 개념_1 (브로커, 프로듀서, 컨슈머, 메시지 + 주키퍼) [Kafka] 카프카 기본 개념 및 간단한 설명 카프카란? 카프카(Kafka) 또는 카프카 클러스터(Kafka Cluster)는 분산 스트리밍 플랫폼으로써, 여러 대의 브로커를 구성한 클러스터를 의미한다. 카프카는 링 unit-15.tistory.com 위의 사이트에서 발췌 그리고 특징 https://soft.plusblog.co.kr/3 [Kafka] #1 - 아파치 카프카(Apache Kafka)란 무엇인가? 데이터 파이프라인(Data Pipeline)을 구축할 때 가장 많이 고려되는 시스템 중 하나가 '카프카(Kafka)' 일 것이다. 아파치 카프카(Apac.. 2022. 12. 23.
전통적인 방식, VM, Container 그리고 Kubernetes https://smoh.tistory.com/348 [Kubernetes] 쿠버네티스가 왜 필요하고 무엇을 할 수 있나? 요즘 개발 후 배포할 때 빠지지 않고 등장하는 주제 중 하나가 도커입니다. 도커 하면 뒤이어 따라 나오는 것이 쿠버네티스입니다. 이 글에선 쿠버네티스가 대체 무엇인지, 왜 필요한지 그리고 smoh.tistory.com [Kubernetes] 쿠버네티스가 왜 필요하고 무엇을 할 수 있나? 요즘 개발 후 배포할 때 빠지지 않고 등장하는 주제 중 하나가 도커입니다. 도커 하면 뒤이어 따라 나오는 것이 쿠버네티스입니다. 이 글에선 쿠버네티스가 대체 무엇인지, 왜 필요한지 그리고 smoh.tistory.com https://subicura.com/2019/05/19/kubernetes-basi.. 2022. 12. 23.
SOA vs MSA https://wiki.webnori.com/display/devbegin/SOA+VS+MSA https://wiki.webnori.com/display/devbegin/SOA+VS+MSA SOA VS MSA - DevBegin - WebNORI wiki.webnori.com 위의 내용에서 발췌 SOA(Service Oriented Architecture) MSA(MicroService Architecture) 공유할 수 있는건 최대한 공유 서비스들의 재사용에 중점 가능한 공유하지 않고 최대한 독립적/스스로 운용될 수 있도록 디자인 서비스들의 독립을 추구 2022. 12. 14.
서비스별 데이터에 대한 책임 분산 (서비스별) 데이터에 대한 책임을 분산 (스키마) 업데이트 관리에 영향을 미침 분산 트랜잭션은 구현하기 어려움 -> 최종 일관성 (일시적인 데이터) 불일치를 관리하기로 선택하는 것은 많은 개발 팀에게 새로운 도전이지만 종종 비즈니스 관행과 일치 종종 기업은 수요에 신속하게 대응하기 위해 어느 정도의 불일치를 처리하는 동시에 실수를 처리하기 위해 일종의 반전 프로세스 https://martinfowler.com/articles/microservices.html Microservices Defining the microservices architectural style by describing their nine common characteristics martinfowler.com 2022. 12. 13.
시스템 복잡성과 생산성(Monolith, Microservices) https://martinfowler.com/bliki/MicroservicePremium.html bliki: MicroservicePremium The microservice architectural style is useful for handling complex systems, but brings its own complexity so should not be used for simpler environments. martinfowler.com 2022. 12. 13.
CSP, MSP CSP(Cloud Service Provider) https://blog.lgcns.com/2204 클라우드 서비스 제공 업체(CSP)와 그 특징은? 클라우드로 전환을 결심하고 나면 기업은 다양한 질문과 고민거리를 마주하게 됩니다. 그중에서도 기업들이 먼저 하게 되는 질문은 ‘어떤 CSP(Cloud Service Provider, 클라우드 서비스 제공 업체)를 blog.lgcns.com MSP(Managed Service Provider) https://www.samsungsds.com/kr/insights/public_cloud_msp.html 퍼블릭 클라우드 효과를 배가시켜 주는 MSP[Managed Service Provider] 퍼블릭 클라우드 효과를 배가시켜 주는 MSP[Managed Servi.. 2022. 12. 13.
Topic 및 Subscriber https://learn.microsoft.com/ko-kr/azure/service-bus-messaging/service-bus-queues-topics-subscriptions#topics-and-subscriptions Azure Service Bus 메시징 - 큐, 토픽 및 구독 - Azure Service Bus 이 문서에서는 Azure Service Bus 메시징 엔터티(큐, 토픽 및 구독)에 대한 개요를 제공합니다. learn.microsoft.com 2022. 12. 9.
Publisher/Subscriber 예 https://learn.microsoft.com/ko-kr/dotnet/architecture/dapr-for-net-developers/publish-subscribe Dapr 게시 & 구독 문서 블록 문서 블록을 구독하는 & Dapr 게시 및 적용 방법에 대한 설명 learn.microsoft.com 위의 내용에서 발췌 Publish-Subscribe Pattern Messaging Pattern 이 패턴의 주요 이점 : Loosely coupled, 느슨한 결합 분산 Application 에서 사용 메시지(게시자, Provider, Producer)를 보내는 서비스와 메시지(구독자, Subscriber, Consumer)를 사용하는 서비스가 분리됨 게시자와 구독자 모두 서로를 인식하지 못함 (할 .. 2022. 12. 9.
확장 가능한 DB WAS(또는 Application Server)는 Container로 구성하여 Microservice로 분리한 효과를 높이고 있는데 DB는 VM, 고정된 Spec으로 구성하면 MSA의 큰 장점 중 하나인 개별 확장, Auto Scaling 가능할까? Container https://ijnuemik.tistory.com/3 Traffic이 증가해서 WAS가 확장해도 결국은 DB에서 그 Traffic이 모두 몰리지 않는가? WAS의 Request가 VM DB병목에 걸리므로 대기해야하는가? 이러한 구조가 어떻게 MSA의 확장성이 높아졌다고 할 수 있겠는가? DB를 꼭 VM에 해야하나? RBD는 그럴 수 밖에 없는가? DBMS 종류에 따라 다른 방법이 많이 있을텐데 잘 사용되지 않는지? 경험이 없어서? 내재화가.. 2022. 12. 9.
AM, CNA, DT 요즘 위의 개념들이 여러 곳에서 등장하는데, 대략 위와 비슷하려나 ... App Modernization(AM) https://kooangelo.tistory.com/142 Cloud Native Application (CNA) https://kooangelo.tistory.com/140 Digital Transformation(DX 또는 DT) https://aws.amazon.com/ko/what-is/digital-transformation/ 2022. 12. 9.
20년 MSA적용 사례 ASIS업무, TOBE방향성, MSA, 관련 각종 설계/개발까지 잘 알고 있는 PL 또는 핵심 분석설계자 부족 -> 업무과중 -> 미숙련 사원 투입 -> 히스토리 모른채 빈칸만 채우는 수준 -> 과부하, 흥미없음 -> 전배 퇴사 -> 사람 부족 악순환 SM조직에서, SI 그것도 대규모 차세대, 그것도 MSA 차세대 프로젝트를 SM조직이 겸해서 하긴 어렵다. SM 실무자 뿐 아니라 관리자도 철저히 분리해야한다. 그렇지 않으면 이도저도 안된다 PM, 응용총괄, 아키총괄 역할의 중요성 MSA Full stack 을 만족하는 인력 투입 기대 실무자의 의견이 부족한 이행전략 계획수정, 시행착오, 내재화 어려움 답정너 MSA뿐 아니라 DDD 전략 전술. Agile. JPA. Test Code. UML. MDD. C.. 2022. 12. 8.
EDA로 가라 https://v.daum.net/v/20221202184016008 아마존 CTO "이벤트 드리븐 아키텍처로 가라" (지디넷코리아=김우용 기자)[라스베이거스(미국)=김우용 기자] “실제 세계는 비동기적(asynchronus)이다. 동기적(synchronus)인 것은 하나도 없다. 많은 일이 항상 일어나고 있다. 자연은 비동기식으 v.daum.net 2022. 12. 6.
서비스간 연관관계(연관도) 파악 전 공유할 내용 실시간도 아니라는데 굳이 비동기 통신을 해야하나요? https://kooangelo.tistory.com/148 데이터 정합성은 어떻게 맞추는가? https://kooangelo.tistory.com/199 Domain Event, CQRS 적용 예 (배민) https://kooangelo.tistory.com/126 분산 시스템은 근본적으로 다르다? https://kooangelo.tistory.com/164 Event Driven Architecture 정의 https://kooangelo.tistory.com/200 2022. 12. 2.
Event Driven Architecture 정의 https://en.wikipedia.org/wiki/Event-driven_architecture Event-driven architecture - Wikipedia Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events. Overview[edit] An event can be defined as "a significant change in state".[1] For example, when a consumer purc en.wikipedia.org 위의 내용에서 발췌 Event-driven archit.. 2022. 12. 2.
데이터 정합성은 어떻게 맞추는가? MSA 도입 전 따져봐야 할 3가지 - 투이 컨설팅 https://www.youtube.com/watch?v=X4kXKOf4AnM 위의 내용에서 발췌 Microservice Architecture를 적용하면 하나의 통합 DB는 사라진다. 데이터는 각각의 Microservice가 따로 갖는다. 각 Microservice는 다른 Microservice와 데이터를 공유하지 않는다. 스스로 업무처리의 완결성을 갖기 위해서이다. 하지만 데이터는 중복된다. (금융) 시스템은 데이터 값의 정확성이 매우 중요하다.(쇼핑몰의 주문과 결제 데이터는? 의료의 환자와 처방 데이터는?) 전통적 금융시스템에서는 데이터를 통합해 운영함으로써 모든 Application에서 하나의 값만 존재하도록 강제했다. 데이터의 중복이 허용되는 .. 2022. 12. 2.
Microservice는 어떻게 찾는가? MSA 도입 전 따져봐야 할 3가지 - 투이 컨설팅 https://www.youtube.com/watch?v=X4kXKOf4AnM 위의 내용에서 발췌 Microservie의 특징 - 다른 서비스와 영향을 주고받지 않아야 한다. 자율적으로 개발, 배포, 운영, 확장할 수 있어야 한다. - 각 서비스는 전문성을 가져야 한다. 자신의 문제를 해결하는데 중점을 두어야 한다. -> Single Responsibility 금융 시스템은 규모가 크다. 트랜잭션은 서로 연계되어 있다. DB는 천 개 이상의 테이블로 구성되어 있다. 기존 Application은 Microservice 단위로 개발 또는 운영되고 있지 않다. 이런 금융 시스템에서 Microservice를 어떻게 정의할 수 있을까? (위와 같은 특징은 금융 .. 2022. 12. 2.
2002년, Amazon 설립자 Jeff Bezos의 명령 All teams will henceforth expose their data and functionality through service interfaces. 모든 팀은 이제부터 서비스 인터페이스를 통해 데이터와 기능을 공개합니다. -> Iceberg Microservice Teams must communicate with each other through these interfaces. 팀은 이러한 인터페이스를 통해 서로 통신해야 합니다. -> API, Domain Event(Publish/Subscribe) There will be no other form of inter-process communication allowed : no direct linking, no direct reads of a.. 2022. 11. 30.
공통 업무 고려사항 공통코드 메뉴, 화면, 버튼, 접근이력 조직, 사용자, 권한 결재 로그인, 로그인 이력, 메인화면 즐겨찾기 게시판 우편번호, 주소 메시지 도움말 Notification (SMS, Email, 알림톡 등) 첨부파일 ... 2022. 11. 29.
21년 MSA적용 사례 발주사의 적극적 참여 분석단계 서비스 정의 워크샾 때 부터 발주사의 파트별 업무 전문가 뿐 아니라 IT담당자까지 적극 참여해서 의견을 주었고 지속적/적극적인 참여로 서로 공감하는 결과를 얻었다. 워크샾 초반에는 생각 차이가 커서 조율하는데 시간이 좀 걸렸지만, 매를 먼저 맞은 것처럼 오히려 나중엔 큰 문제가 없었다. 워크샾 결과를 발주사 의사결정자에게 보고하는 자리에서도 발주사 IT 담당자들이 직접 설명할 만큼 수행사와 이견이 없었다. 이를 보면서 다시 한번 느낄수 있었다. 서비스 정의 워크샾은 반드시 발주사의 업무 전문가(도메인 전문가, 현업), IT 전문가, 수행사의 PL, 분석설계자, 모델러, 유지보수 담당자까지 이해관계자가 모두 모여서 진행해야 효과적이다. 19년도 프로젝트에서는 발주사의 IT담당.. 2022. 11. 29.