MSA

기존 서비스 + 온라인 기술 = 새로운 서비스 창출 (feedback -> business)서비스를 변경하는 속도가 매우 빠르다.서비스 변경 빈도가 많다는 것은 변화된 비즈니스 환경에 민첩하게 대응 인프라는 애플리케이션이 운용되는 바탕, 하부구조 (서버, 네트워크, O

모노리스 시스템 애플리케이션이 한 덩어리로 구성 단일 프로세스 실행한꺼번에 수정, 배포하나가 실패 -> 모두 실패 모노리스를 클라우드 인프라에서 활용스케일 아웃시 모노리스 한덩어리가 됨, 확장성 탄력성이 보장은 되나 비용적으로 비효율적 그에 비해 마이크로서비스는 애플리

MSA는 마이크로서비스 기반 아키텍처 아케텍처에는 정답은 없다. 각기 상황에 따라 최선의 선택을 하고 그 선택에는 항상 tradeoff 발생클라우드 애플리케이션 전환은 좌측 -> 우측 = 점진적인 변화하는 과정, 많은 시간이 소요, 리스크가 큼 Cloud infra 도

특성 : 가용성, 신뢰성, 확장성, 보안, 민첩성, 탄력성, 복구성, 성능, 배포, 학습 (시스템이 가져야 할 특성)결정 : 제약조건, 개발자가 해도 되는 것과 하지 말아야 할 것 정의 (청사진) 설계 원칙 : 아키텍처 결정을 만족시키는 가이드라인 시스템 구조 : 아키

통합 DB 보다는 저장소, 격리 -> 저장소를 공유 -> Service 묶임. & Service 독립 확장 MSA는 여러개 서비스간의 연계를 통해, 시스템을 구축하는 SOA 범주에 있음 여러개 서비스의 효과적 운용 관리 자원을 위한 Outer Architecture 비

인프라 플랫폼(IaaS): AWS EC, Azure VMs컨테이너 플랫폼 (CaaS): AWS ECS,EKS,AKS,GKE 어플리케이션 플랫폼(PaaS,aPaaS): Heroku,PCF,CloudFondy함수 플랫폼(FaaS): Lambda,Azure Functions

하나의 호스트 머신에서 도커 엔진을 구동 -> CPU, 메모리, 디스크용량과 같은 같은 자원이 부족하면??\-> 서버 클러스트링으로 자원을 병렬 (하나의 Machine 위에서 Docker container 구축, if 컨테이너 상태 안좋으면, 해당 컨테이너 가져다 버림

Automatic bin packing : Container를 적절히 배분Self-Healing : Conatiner 죽으면 알아서 생성Horizontal scaling : 수평 확장 기능 설정 Service discovery and Load balancing : co

CI - continuous integration & CD = Continuous Development지속적 융합 & 지속적 배포 빌드 : 컴파일, 테스트, 정적 분석 수행배포 : 개발/테스트/스테이징/운영 환경에 배포애자일 프렉티스에서 유래, 지속적 통합, 배포자동

클아우드 서비스 제공업체다양한 컴퓨팅 서비스가 운영관리를 위한 패턴을 지원가상네트워크, 스토리지, 가상서버, 자체 컨테이너 서비스, 다양한 Backing(DB message) 서비스, Devops 서비스, 모니터링, 추적 로깅업로드중..

안에는 큰 한덩어리 -> 내부가 쪼개진 case분산 트랜잭션 Failure of Service\-> Casacading Faliure한곳에서 문제가 발생하면 다른 곳까지 문제가 퍼짐 Spring Cloud BFF Backend for FrontEnd API gatewa

서비스가 올라가는 컨테이너의 Ip 정보가 고정 X, 서비스 이름과 IP 정보를 Mapping, 보관할 저장소 필요 (= Service Registry)여러 서비스 인스턴스 생성 시 새로 생성된 인스턴스의 발견과 없어진 서비스의 감지 레지스터리서비스가 DNS 역할, 서비

인증(Authentication) , 내가 누구인가?인가(Authorization), 내가 어떤 권한을 가지고 있는가?중복 도메인 접속 불가 Latency 증가, 인증인 해결되나, 인가는 각 서비스가 비즈니스에 따라 해결API G/W, 인증 인가가 통합된 토큰 발행(S

종속성을 없애기 위한 External Configuration 패턴 12 Factors -> 어떤 infra에 올라가더라도 최소한의 변경 (클라우드에서 돌아갈 애플리케이션은 하드웨어나 컨테이너 종속된 정보를 소유 X) 설정파일 변경에 따라 별도 빌드/배포 필요 없음 C

log를 Local에 쌓으면 안되고, Container는 Immuatble 하기 때문에, volume 같은 것을 만들어 별도 file에 저장해야 함 로컬 로깅 X, 중앙 집중형 로깅 Log aggregation , Exception tracking모니터링 추적 (어떤게

Service instance 증가 -> 서비스간 통신 증가 단일 애플리케이션 프랫폼Infra가 제공하는 Pattern 넷플릭스 + Spring Cloud비즈니스 로직 + 별도 라이브러리 추가 서비스 메쉬 (ISTIO)Pod를 하나로 묵어서 처리 서비스 로직과 통신의

MS를 적용할 경우 애플리케이션 부분까지 고려해야 하지만, 그렇지 않은 경우 플렛폼과 인프라만 고려! 클라우드 아키텍처 작용만으로도 충분한 경우 많음CSP(AWS, Azure, CSP), laas, Paas, 쿠바네티스, Devops, Application Modern

frontEnd 조각으로 분리, BackEnd 저장소를 격리 탄력과 확장성를 고도화, 난이도 복잡성 높음 ACID 트랜잭션이 종료 -> 일관적이고 안정적으로 디스크에 저장 즉시 일관성, 정확도 중요. 관계형 DBBASE가용성, 어떤 상황에서도 데이터를 빠르게 전달, 약

MVC 패턴이 백엔드 아키텍처 전부인 것처럼 오해되고 있음 MSA는 유연셩과 확장성을 강조하지만 이런 구조에서는 유연하다고 할 수는 없다. 티어(물리적)와 레이어(논리적)보편적으로 많이 사용되는 레이어 호출방향은 위에서 아래로, 아래서 위로는 불가 인접 레이어만 접근,

애자일 방법론 적용 마이크로서비스 설계DDD를 중심으로 MSA를 설계 (전략, 전술) 전략 : Bounded Context == MSA 경계와 일치전술 : Domain Model == 핵사고날