마이크로 서비스 개요
. 역사적으로 SOA는 비즈니스 재사용을 통해 비즈니스 민첩성을 확보했지만 MSA는 신속한 배포를 통해 비즈니스 민첩성을 확보했습니다.
. Mainframe -> CS -> WEB -> CLOUD로 시스템 환경 변경
. 사용자 폭증 / 새로운 요구 / 새로운 비즈니스 기회 / 시스템 장애에 신속하게 대응하기 위해 여러 아키텍처 스타일이 있으며 MSA는 CLOUD에 가장 적합한 아키텍처입니다.
. 모놀리식 시스템이 주로 화면접근제어(웹) 업무 데이터이고 유지관리될 때 이를 작은 서비스 단위로 나누어 마이크로서비스를 설계한다.
. 서비스 단위의 구분은 과거에 응용 프로그램을 잘 구성하는 방법(객체지향 방법론, CBD, EJB 등)이 있었고 MSA도 이를 잘 구분하기 시작했습니다.
즉, DDD(Domain Driven Design)에 의해 Bounded Context와 Shared Kernel로 구분된다.
마이크로 서비스 아키텍처의 구성
구조적으로 내부/외부로 구분됨(Gatner 정의)
– 대외 : AP의 운영, 관리, 실행에 주력
– Inner : 좋은 분할을 통한 AP의 설계/개발에 집중
MSA는 외부 관점에서 접근하고 광범위하게
. API Gateway(외부 액세스를 위해 내부에 연결)
. Service Mesh(내부 서비스 간 호출)
. 컨테이너 관리(서비스 실행, CI/CD 연계)
. Backing 서비스(서비스 간 이벤트 관리, Queue/Cache, DB)
. CI/CD(빌드 테스트 배포 자동화).
. Telemetry(진단/모니터링 – 로그 등의 상태 확인, 공정 관련 업무)
MSA의 외부 아키텍처
(API 게이트웨이)
단일 접점 확보 + 오케스트레이션(네트워크 지연 감소, 액세스 도메인 단일화), 통합 모니터링 및 통화 제어, 인증과 같은 반복적인 공통 기능 적용 및 클라이언트와 서비스 간의 중복 감소를 통한 효율적인 관리(좋은 매핑 필요)
1. 주요 기능 (구현하는 APIM도 있습니다.
포털, API 사양 관리, 서비스 관리, 사용자 인증 관리, API 개발 가이드 등의 화면 제공)
. API Routing, LB: 가중치에 따라 균형을 이루고, 최대한 구현하고, 오버헤드가 적은 HTTP 헤더 또는 URL에 라우팅 필드를 구현했습니다.
. API 인증/권한 부여: OAuth2.0 GrantType 및 SAML 인증 방법
. 네트워크 수준 암호화(SSL 통신을 통한 HTTPS 기본 지원)
. Common Logic Processing – 공통 기능(인증, 모니터링, 로깅 등)을 API GW로 오프로드
. 커스터마이징 기능(중재) : 중간에 다양한 프로토콜을 커스터마이징 및 조정(JSON)<->XML, 비동기<->동기화 등) -> Kafka와 같은 MQ로 구현
. API Aggregation: 여러 API를 하나의 API로 통합 관리
. 트래픽 제어(Rate-Limit): Leaky Buchet, Fixed Window, Sliding Log, Sliding Window 등으로 제어하며 API 요청을 계층별로 제어하거나 SLA(Service Level Agreement)를 사용자 정의할 수 있습니다.
. Logging, Metering: API 사용현황, 응답시간, 오류 로깅으로 모니터링 가능
2. API 게이트웨이 아키텍처 패턴
. 구현 전용: 작은 서비스별 API가 있는 경우 클라이언트 측 포크를 호출합니다(무엇이든 문제가 될 수 있음).
. 단일 API 게이트웨이: 약간 고급형, 사용자 – API GW – 다중 LB – 다중 서비스
. 백엔드에서 프런트엔드로 – 클라이언트 장치 기반: 여러 분산 API GW, 여러 사용자 – 유형별 API 게이트웨이 * 여러 LB – 서비스
. 프런트엔드용 백엔드 – 서비스 기반: 서비스 기반 API GW 구성, 클라이언트 – 여러 API GW – 서비스별 LB – 서비스
3. 제품
AWS Amazon API Gateway, Google Apigee, MS API Management 등 모두 좋고 장점도 많지만.. API Gateway 정전이 발생하면 전체 서비스가 영향을 받습니다.
(서비스 메쉬)
내부 서비스 간의 호출을 효율적으로 만들기 위한 느슨한 결합.
SpringCloud의 일반적인 Neflix는 Discovery-Load-Balancing-Circuit-Breaker와 같은 기능을 각 요구 사항에 대한 코드 수준 라이브러리로 구현합니다.
-> 개발 언어에 따라 다르므로 덜 의존적인 Istio 솔루션을 조심하십시오.
대표적인 SideCar 방식은 프록시를 구현하고자 하는 서비스와 동일한 레벨에 별도로 두고 이를 발견하여 서비스로 만드는 메쉬(Mesh) 방식이다.
1차 제품
스프링클라우드 Netflix
장점 – 필요한 도구만 타겟에 맞게 사용 가능하며, 기능은 앱에 바로 적용되기 때문에 유연하게 사용할 수 있습니다.
단점 – Java 언어에 의존하므로 설계/구현 복잡성이 높으며 서비스는 도구 간의 종속성을 식별하여 설계됩니다.
이스티오
장점 – 인프라 영역에서와 같이 애플리케이션 종속성이 없고 개발 언어와 독립적임
단점 – 프록시로 인한 오버헤드가 각 서비스에 추가됨
2. 구조
서비스 옆에 간단한 프록시를 배치하고 컨트롤러가 이를 관리하도록 구성되어 있기 때문에 데이터 플레인과 컨트롤 플레인으로 나뉩니다.
. Data Plane은 설정에 따라 트래픽을 제어하고 서비스 인스턴스 간의 네트워크 트래픽을 관리하는 부분입니다.
서비스 대신 프록시 호출로 캡슐화됩니다.
서비스 식별, 상태 확인, 인증/권한 부여 및 모니터링(일반적으로 Envoy 프록시)
. 컨트롤 플레인은 패킷이나 요청을 직접 제어하지 않습니다.
데이터 플레인 정책 구성을 제어하고 프록시 설정을 저장, 관리 및 전달하는 컨트롤러 역할만 하며 경로 테이블 및 LP 풀과 같은 기본 구현을 관리합니다.
3. 주요기능
. 서비스 검색: 클라이언트측 식별 방법 – 서비스 인스턴스는 자신의 위치를 서비스 레지스트리에 등록하고 서비스 레지스트리는 서비스 호출 가능 여부를 주기적으로 확인합니다.
API endpoint 제공) 연결/서버 측 서비스 식별 방식 – 유통 인프라는 서비스 식별 처리, 플랫폼은 서비스 등록, 서비스 검색 및 요청 라우팅 정보 제공, LB는 서비스 등록을 참조하여 서비스 연결
. 구성: 동적으로 생성/수정/삭제된 서비스 인스턴스는 공유 저장소의 구성 정보를 참조합니다.
. 라우팅, 로드 밸런싱: API GW를 통해 수신된 요청은 직접 또는 LB를 통해 전달될 수 있습니다.
. 회로 차단기: 장벽
. 암호화: 내부의 HTTP 멤브레인과 끝의 HTTPS에 의해 캡슐화되고 처리되기 때문에 내부에 암호화 신경이 없습니다.
. 인증/인정
* Spring Cloud Neflix로 구현할 때 검색 및 로드 밸런싱. 로드 밸런싱
* 문제 해결: 오류 발생 시 정의된 작동 모드에서 작동할 수 있도록 회로 차단기를 구현합니다.
4. 건축
. 라이브러리 방식: Spring Cloud Netflix, 소스 수준 구현이므로 반드시 서비스 메시일 필요는 없음
. 노드-에이전트(호스트-프록시) 방식 : 각 노드(서비스, 호스트 엔터티)에 링커드(Linkerd)라는 에이전트(프록시)를 배치해 서비스 간 통신을 제어하고 에이전트 장애 시 컨테이너를 해당 노드에 배치 종료
. Linkerd는 서비스 중 요청의 다양한 속성을 기록하고 이를 기반으로 노드를 판단하고 전달 요청을 중앙 집중식으로 관리합니다.
. Sidecar Proxy 방식: Istio는 사이드카 패턴으로 서비스 옆에 배치되어 서비스 간의 통신을 제어하는 간단한 프록시로, 단일 서비스 엔터티에서 통신 제어가 가능하므로 호스트의 다른 일반 인스턴스에는 영향을 미치지 않습니다.
(단위: AWS ECS의 Task, K8S의 Pod 또는 AWS의 EKS)
5. Service Mesh 사용의 장단점
. 장점 :
자동 확장 서비스 연결을 동적으로 관리
서비스 간의 효율적인 통신
네트워크 오류의 효율적인 처리
서로 다른 서비스 간의 안정적인 요청 및 응답 전송
완벽한 성능과 안정성 제공
애플리케이션 런타임에 대한 가시성과 제어를 제공하여 애플리케이션 전반에 걸쳐 일관된 기능 제공
. 불리:
시스템의 런타임 인스턴스 수를 크게 늘립니다(최소 2배).
서비스 간 통신을 위한 네트워크 영역 추가
이것은 새로운 기술이기 때문에 구현이 릴리스되기까지 다소 시간이 걸릴 것입니다.
(컨테이너 관리)
MSA 환경에는 여러 서비스 제공 패턴이 있을 수 있지만 컨테이너당 서비스 방식이 가장 일반적입니다.
1. 컨테이너 구성 요소
. 이미지 등록
. API/CLI/GUI
. 클러스터 관리를 위한 오케스트레이션 계획
. 모니터링 및 로그 관리
. 보안 검사
. 컨테이너 런타임(레지스트리에서 이미지 가져오기 및 실행 네트워크 및 저장 장치와 관련된 수명 주기 제공)
. 네트워크 및 로드 밸런싱
2. 주요 기능
. 로드 밸런싱(변경된 서버 정보 검색 및 들어오는 요청 분산)
. Scheduling(노드 또는 인스턴스 장애 시 지정된 수의 복제를 유지하는 서비스)
. 자원 관리
. 컨테이너의 자동 배포 및 복제(YAML 및 JSON에 특정 애플리케이션 구성 정보를 미리 스크립트로 작성하고 이를 기반으로 로드)
. 컨테이너 장애 조치
. 클러스터 외부에 서비스 노출
. 컨테이너를 추가하거나 제거하여 확장 및 축소
. 컨테이너 서비스와 네트워크 포트 노출 제어 간의 인터페이스 연결
3. 제품
Amazon EKS, MS AKS, Google GKE, Kubernetes, Docker Swarm
(백킹 서비스)
서비스별로 데이터를 개별적으로 분산 관리할 경우 DB 연결 시 함께 사용(message queue)하거나, 공유(cache)하거나, 비동기적으로 처리하되 다른 서비스(topic)에서 처리해야 한다.
시간 보고 데이터(보고 서비스 관리)
1. 서비스 구분
. 데이터 BS: 지속적인 데이터 관리, 장애 조치, 확장성 및 편리한 액세스를 위해 사용(Amazon RDS, DynamoDB, Cassandra, MongoDB)
. 메시지 BS: 분산 서비스 간에 주고받는 메시지는 Queue 기반 브로커를 통해 비동기식으로 전달, 비동기식 약한 결합, 탄력적, 서비스 장애 시 재처리, Queue가 존재할 경우 최소 1회 처리 보장, Queue for many requests 설정에 의해 확장 가능 다중(Amazon SQS, SNS, Kafka, RabbitMQ)
2. 건축
. 점대점 패턴
. 경쟁적인 소비자 행동
. 게시/구독 패턴
. Pub/Sub 라우팅 패턴 추가
. 건축 패턴 테마
. RPC 패턴
3. 구성 고려 사항
. 데이터 연속성: 대기열에 문제가 있는 경우에도 데이터 연속성을 보장하도록 구성됩니다.
B. 처리 요청 시 확인/오류 메시지 전송. 마이크로서비스에서 모든 서비스에는 롤백 이벤트를 처리하는 서비스가 필요합니다.
. 프로토콜: 각 메시징 솔루션에 대해 서로 다른 프로토콜이 사용됩니다.
AMQP MQTT REST XMPP SNOMP 등 선택 및 구성
. 내결함성: 내구성을 보장하기 위해 메시지를 메모리, 디스크, 데이터베이스 등의 어디에 저장해야 합니까? 비용, 속도, 다운타임 등을 고려하여 구성 하이브리드 방식(Lazy Queue 등)도 있음
. 보안: Queue에 접근할 수 있는 서비스, 허용되지 않는 서비스, IP 관리, SSL 적용, 인증/권한 제어 등에 대한 보안 정책이 필요합니다.
기타.. 메시지 수명 주기, 필터링, 재전송, 전달, 일괄 처리, 비용, 부인 방지 등
4. 제품
단순 Q 방법: Amazon Simple Queue Service(SQS), Google Tasks, Azure Storage Queue
Pub/Sub 방법: Amazon Simple Notification Service(SNS), Google Pub/Sub, Azure Service Bus
(원격 측정)
1. 주요 기능
분산 서비스. 모니터링, 알림, 로깅, 추적, 분석위한 아키텍처 필요(모놀리식의 경우 서버에 직접 요청)
서로 다른 API, 서로 다른 시스템의 로그를 수집+정규화+가시화로 관리하는 것이 기본 개념이며 관련 솔루션도 제공된다.
기존의 단순 로깅과 비교하여 서비스 간의 호출 관계 추적 관계 분석이 필요합니다.
TID는 응답 시간 및 처리 상태를 확인할 수 있도록 배치됩니다.
몇 가지 관련 오픈 소스(Zipkin 등)가 있습니다.
2. 건축
중앙 로깅 : 모든 로그 수집 및 분석, 트랜잭션 시작-종료, 누적 정보로 분석 및 예측 가능, 로그는 외부에서 로드,
잔디 방법 : 모니터링 서버는 서비스(Prometheus)에서 메트릭을 수집합니다.
푸시 방식 : 서비스 에이전트가 설치되고 메트릭이 서버(Graphite)로 전송됩니다.
3. 제품
로깅: AWS Cloudwatch, OSS Prometheus, ElasticSearch, Logstash, Kibana, Datalog
추적: AWS X-Ray, OSS Zipkin Jaegerm Spring Cloud Sleuth
4. 현금의 사용
데이터베이스 캐싱
CDN Content Delivery Network – 비디오 이미지, 웹 페이지와 같은 웹 리소스는 가까운 서버에서 로드되고 동적 리소스만 원본 서버로 전송됩니다.
DNS 캐싱
HTTP 등의 세션 관리 – 로그인 자격 증명, 방문 기록, 사용자 환경 설정 등 UX 전달에 필요한 정보 관리를 중복 캐시 서버로 구성 가능
API – API에서 결과를 캐싱하여 백엔드 요청을 더 적게 보냅니다.
웹 캐싱 – 서버 측 웹 캐싱은 방문자의 브라우저 기반 캐싱을 통해 로드 대기 시간을 줄이기 위해 웹 프록시를 사용합니다.
(CI/CD)
1. 영업기법
. 롤링 업데이트: 한 번에 하나씩 배포하고 문제가 있는 경우 한 번에 하나씩 복원합니다.
롤링 배포 방법은 처리하는 데 너무 오래 걸립니다.
. Blue-Green Distribution: 새로운 소스를 별도의 영역에 배포하고 V1에 요청이 들어오는 동안 V2에서 유입을 전환하고 문제가 발생할 경우 트랜잭션 V1으로 전환합니다.
완벽한)
. 카나리아 분배 : 5%만 새 V2로 보내주고, 정상이면 유입경로를 새것으로 바꿔서 최종 확정되면 다들 차차 V2로 갈아타게 됩니다.
Server Cache 등의 차이로 같은 V1′ V2 V1도 5:5:90으로 체크, 소스 영향 파악이 필요할 때 사용)
* 일반적으로 위 흐름을 yaml 파일로 정의
* 이 외에. HTTP와 조건에 따른 흐름 정의 가능
2. 분포 패턴
. HOST당 멀티서비스 – 하나의 호스트에 여러 서비스를 배포하는 기존 방법
. VM당 단일 서비스 – 각 서비스는 VM으로 패키징되거나 VM 이미지를 사용하여 인스턴스를 배포(예: EC2 인스턴스 생성)하거나 OS를 포함하므로 시간이 오래 걸리고 MSA에 적합하지 않음
. 컨테이너별 서비스 – 컨테이너 이미지로 패키징 및 배포(코드, 런타임, 시스템 라이브러리, 구성 등과 같은 자체 포함된 경량 엔터티)
. 서버리스 배포 – 서비스가 AWS Lambda와 관련된 모든 상태를 저장할 수 없도록 주의하면 다른 AWS 서비스(S3, DB, 네트워크, APIGW 등)가 자동으로 실행됩니다.
사용 사례
마이크로서비스 아키텍처 적용
3rd Party Use Case 1 쇼핑몰 (리눅스 기반 – 컨테이너 X)
– API 게이트웨이: Hystrix(리본, 유레카 클라이언트), Zuul
– API 관리: Swagger
– 통화 추적: zipkin
– 모니터링: 마이크로미터
– 서비스 식별 : 유레카 서버
-캐시: 레디스
-CI/CD: 젠킨스, 힘내
타사 사용 사례 2 Fintech 회사(Linux 기반 – Container X)
– API 게이트웨이: Hystrix(리본, 유레카 클라이언트), Zuul + Spring Cloud
– API 관리: Swagger
– 통화 추적: zipkin
– 감시 : 경비
– 서비스 식별 : 유레카 서버
-캐시: 레디스
– CI/CD: 젠킨스, 힘내
– 로그 수집: EFK(Elasticsearch + Fluentd + Kibana), FileBeat 및 Kafka 조합
아키텍처를 정의할 때…
– 클라우드 기반 MSA를 구성할 때 고객의 요구에 대응하여 각 클라우드 회사에서 제공하는 요소 기술로 구성할지, OSS를 전체적으로 적소에 배치할지를 고려한다.
– Spring Cloud 및 Zuul은 Spring Boot에 최적화되어 있으므로 종속성 문제가 발생할 수 있습니다.
– 최근 API Gateway의 역할이 줄어들고 Service Mesh가 이를 대신하고 있음(Eureck, Ribbon 등)