1. 누구나 쉽게 이해하는 MSA 첫걸음 (김민형, 강지나 | 네이버 클라우드)
1.1. Monolithic
: 애플리케이션 안에 모든 비지니스 로직이 다 들어가 있는 구조
1.2. MSA MicroServiceArchitecture
: 서비스를 비즈니스 경계에 맞게 세분화 하고, 서비스 간 통신은 네트워크 호출을 통해 진행하며 확장 가능하고 회복적이며 유연한 어플리케이션을 구성하는 것
<- 여러 기능이 뭉쳐 강하게 결합되어 있는 Monolithic 방법론의 문제점들에서 비롯함
> 마이크로서비스란?
서비스를 비즈니스 경계에 맞게 세분화 하고, 서비스 간 통신을 네트워크 호출을 통해 진행하며, 확장 가능하고 회복적이며 유연한 어플리케이션을 구성하는 것이다.
> 유저들이 MSA를 찾는 이유
1. 기존 Monolithic 방식은 소프트웨어의 모든 구성요소가 한 프로젝트에 합쳐져 있어, 큰 변화에 대한 대응이 어려우며, 새로운 기능 추가 및 업데이트에 어려움이 발생함
2. (여러 역할을 하는 시스템이 하나의 소프트웨어로 집합되어 있어,) 특정 부분에 문제 발생 시 큰 장애로 이어짐
3. (여러 역할을 하는 시스템이 하나의 서버에 함께 올라가 있기 때문에) Scale-Out 시 필요 없는 자원이 함께 증가됨
4. 민첩하고 손쉬운 배포 및 업데이트가 가능함 (Blue-Green 배포 방식)
2. MSA를 구성하기 위한 기반 기술 (김민형, 강지나 | 네이버 클라우드)
2.1. MSA를 구성하는 주요 Component
2.1.1. Config Management
서비스의 재빌드•재부팅 없이 설정사항을 반영(Netflix Archaius, Kubernetes Configmap)
2.1.2. Service Discovery
MSA 기반 서비스 배포 시 서비스 검색 및 등록(Netflix Eureka, kubernetes Service, Istio)
2.1.3. API Management
클라이언트 접근 요청을 일원화(Netflix Zuul, Kubernetes Ingress)
2.1.4. Centralized Logging
서비스별 로그의 중앙집중화(ELK Stack)
2.1.5. DIstributed Tracing
마이크로서비스 간의 호출 추적(Spring Cloud Sleuth, Zipkin)
2.1.6. Centralized Monitoring
서비스별 메트릭 정보의 중앙집중화(Netflix Spectator, Heapster)
2.1.7. Resilience & Fault Tolerance
MSA 구조에서 하나의 실패한 서비스가 체인에 연결된 전체 서비스들에 파급 효과를 발생시키지 않도록 하기 위한 계단식 실패 방지 구조(Netflix Hystrix, Kubernetes Health Check)
2.1.8. Auto-Scaling & Self-Healing
자동 스케일링, 복구 자동화를 통한 서비스 관리 효율화
※ (from Redhat) Microservices Concerns
: Config Management, Service Discovery & LB, Resilience & Fault Tolerance, API Management, Service Security, Centralized Logging, Centralized Metrics, Distributed Tracing, Scheduling & Deployment, Auto Scaling & Self Healing
2.2. MSA를 구현하는 기반 기술
: 마이크로서비스 간 통신을 위해 각 서비스를 식별(DIscovery)하고, 경로를 파악(Routing)하며, 로드밸런싱(Load-balancing)을 하고 전체 서비스의 장애 전파를 차단(Circuit Break)하며 Telemetry와 통합되어 로깅, 모니터링, 트래이싱 기능을 담당하는 Service Mesh에 대한 이해도 필요합니다.
Connect
+ 지능형 라우팅을 통해 서비스/엔드포인트 간의 트래픽과 API 호출 흐름을 제어합니다.
+ Service Mesh는 서비스 간 통신을 추상화하여 안전하고, 빠르고, 신뢰할 수 있게 만드는 아키텍처입니다.
Secure
+ 서비스 메쉬를 통해 서비스 간 안전한 통신이 가능합니다.
+ 커뮤니케이션을 허용하거나 거부하도록 정책을 적용 가능합니다.
Monitor
+ 서비스 메쉬를 사용하면 분산 마이크로 서비스 시스템을 쉽게 모니터링 할 수 있습니다.
+ Service Mesh는 Kubernetes의 경우 Prometheus 및 Jeager와 같이 시각화 도구들과 즉시 통합되므로 서비스, 트래픽 흐름, API 지연 시간 및 추적 간의 종속성을 발견하고 시각화 할 수 있습니다.
※ CCC : Cross-Cutting Concerns Ex. Traffic Metrics, Routing Retry, Timeout, Circuit Breaking, Encryption, Decryption, Authrization, ...
2.2.1. Service Mesh 서비스들
: Istio, Linkerd 2, Consul, Traefik mesh, Kuma, Open Service Mesh
2.3. Service Mesh 적용 시 고려사항
1. 복잡성
: 서비스 메쉬를 사용하면 런타임 인스턴스 수가 증가합니다.
2. 사이드카 컨테이너 수 증가
: 각 서비스는 서비스 메쉬의 사이드카 프록시를 통해 호출되므로 개별 프록시 수가 증가하게 됩니다. 이에 따른 부하로 서비스 운영에 문제가 발생할 가능성이 있는지에 대해 아키텍처 구조 측면에서 사전에 컴토해야 합니다.
3. 기술력의 미성숙
: 빠르게 발전하고 있으나 아직은 새롭고 미성숙한 기술에 속합니다. 또한 많은 기업이 서비스 메쉬에 대한 경험이 없는 실정입니다
> MSA를 구성하는 주요 Component
1. Config Management
2. Service Discovery
3. API Management
4. Centralized Logging
5.Distributed Tracing
6. Centralized Monitoring
7. Resilience & Fault Tolerance
8. Auto-Scaling & Self-Healing
> Service Mesh 적용 시 '복잡성', '사이드카 컨테이너 수 증가', '기술력의 미성숙'을 고려해야 한다.
3. MSA를 위한 쿠버네티스는 무엇일까? (김민형, 강지나 | 네이버 클라우드)
3.1. kubernetes Component - Pod
+ kubernetes 에서 생성하고 관리할 수 있는 배포가능한 가장 작은 단위 (*kubernetes 공식 정의)
+ 하나 이상의 실행 컨테이너를 포함하는 개념
+ 일반적으로 밀접하게 연결된 Application 이 올라간 컨테이너들을 Pod로 묶어서 배포
+ Deployment 혹은 Job과 같은 워크로드를 이용하여 생성
+ 애플리케이션 컨테이너, 스토리지 리소스, 고유 네트워크 ID 및 기타 구성을 캡슐화
+ Pod 생성 시, 휘발성 성지을 가진 IP를 자동으로 할당
3.2. kubernetes Components - Services
+ Service의 Cluster IP를 통해 유동적으로 생성되고 사라지는 Pod에 접근하기 위한 방법으로 사용
+ 여러 Pod를 묶어 Healthy한 Pod로 Traffic 라우팅하는 로드 밸런싱 기능 제공
+ 클러스터의 Service CIDR 중에서 지정된 IP로 생성 가능
+ ClusterIP / NodeIP / LoadBalancer 타입 제공
+ 기본 옵션은 클러스터 내부에서만 사용할 수 있는 Cluster IP
3.3. kubernetes components - Ingress
+ Service 는 L4 레이어로 TCP에서 Pod들을 밸런싱, URL Path에 따른 서비스간 라우팅이 불가능
+ 서비스간 Routing 위해 API Gateway(무거움) 사용, URL기반 라우팅 L7 로드밸런서(가벼움) 제공 가능
+ 쿠버네티스 HTTP(S)기반의 L7 로드밸런싱 기능을 제공하는 컴포넌트 = Ingress
+ 서비스 앞에서 L7 로드밸런서 역할을 하고, URL에 따라서 라우팅
3.4. kubernetes Components - Configmap
+ 컨테이너에 들어갈 애플리케이션의 설정 값을 외부에서 제어할 수 있도록 도와주는 오브젝트
+ Key: Value 값으로 선언
+ 일반적인 정보 값은 ConfigMap 로 생성
+ 민간한 기밀 정보 값은 Secret 로 생성 (인증키, 패스워드 등)
+ 컨테이너에서 두 오브젝트 값을 가져와 사용하면, 컨테이너 내부 코드를 변경할 필요 無
+ 두 오브젝트를 적절히 이용하면 개발/운영 환경에서 동일한 컨테이너 이미지 활용 가능
3.4.1. Liernal 방식
+ ConfigMap과 Secret에 직접 상수 값을 입력
+ Secret Value 값의 경우, Base64 인코딩이 되어있는 값을 넣어야 함
3.4.2. File 방식
+ file을 만들어 그 값으로 ConfigMap 및 Secret을 생성
+ file 이름이 Key, file 내용이 Value가 됨
+ File 방식의 경우, Base64 인코딩을 자동으로 지원해주기 때문에 따로 인코딩된 값을 넣을 필요 無
+ Kubernetes 노드에서 kubectl 명령어로 직접 생성 필요
3.4.3. Volume Mount 방식
+ Pod 생성 시, container에 mount 경로를 지정하여 해당 위치에 ConfigMap과 Secret을 마운트하여 사용
+ ConfigMap과 Secret의 Value가 중간에 변경되면, 변경된 값이 자동으로 반영
3.5. kubernetes Components - Monitoring
+ 오브젝트에서 정의한 개수 대로 Pod를 복제/관리하는 오브젝트
+ Replicaset을 단독으로 사용할 수 있으나 주로 Deployment의 spec으로 정의하는 것을 권장
+ 관리해야 하는 pod를 식별하기 위한 selector, 유지해야 하는 pod의 개수, pod template을 포함
3.5.1. 분산된 서비스에 통합 모니터링 구현을 위한 Monitoring target Layers
1. Host
: 노드에 대한 지표 모니터링에 해당
(노드의 CPU, 메모리, 디스크, 네트워크 사용량 등이 해당)
2. 컨테이너
: 컨테이너의 CPU, 메모리, 디스크, 네트워크 사용량 등을 관리
3. Application
: 컨테이너안의 구동되는 개별 애플리케이션 지표를 모니터링
4. 쿠버네티스
: 컨테이너를 컨트롤하는 쿠버네티스 자체에 대한 모니터링, 쿠버네티스의 자원인 서비스나 POD, 계정정보에 해당
> 쿠버네티스(Kubernetes) 서비스는 MSA 구성에서 필요한 컴포넌트를 제공할 뿐만이 아니라, 많은 기업들이 쿠버네티스를 채택하면서 사실상 MSA를 구현하는 표준이 되어가고 있다.
> 쿠버네티스를 구성하는 주요 Component
1. Pod
2. Object and Controller
3. Services
4. Ingress
5. ConfigMap
6. Monitoring
4. 서비스 매쉬의 필요성과 Istio 활용법 (강지나 | 네이버 클라우드)
4.1. Istio 아키텍처
+ 이스티오는 데이터 영역(Data Plane)과 제어 영역(Control Plane)으로 구성함
+ 데이터 영역(Data Plane)은 메시 내 서비스들 사이의 네트워크 트래픽이 관리됨
+ 트래픽은 네트워크 프록시 시스템에 의해 인터셉트되어 리다이렉트 됨
+ 이스티오의 경우 프록시는 오픈소스 프로젝트인 엔보이(Envoy)에 의해 제공됨
+ 컨트롤 플레인은 데이터 플레인에 배포된 Envoy를 컨트롤하는 부분으로 파일럿(Pilot), 믹서(Mixer), 시타델(Ciadel) 총 3개의 모듈로 구성되어 있음
4.1.1 Data Plane
: 실제 트래픽이 돌아다니는 영역
+ 엔보이(Envoy)
4.1.2. Control Plane
: 프록시가 트래픽을 라우팅할 수 있도록 관리하고 설정하는 역할
+ 파일럿(Pilot)
+ 믹서(Mixer)
+ 시타델(Citadel)
> Istio 아키텍처
1. 이스티오는 데이터 영역(Data Plane)과 제어 영역(Control Plane)으로 구성함
2. 데이터 영역(Data Plane)은 메시 내 서비스들이 네트워크 트래픽을 관리됨
3. 트래픽은 네트워크 프록시 시스템에 의해 인터셉트되어 리다이렉트 됨
4. 이스티오의 경우 프록시는 오픈소스 프로젝트인 엔보이(Envoy)에 의해 제공됨
5. 컨트롤 플레인은 데이터 플레인에 배포된 Envoy를 컨트롤하는 부분으로 파일럿(Pilot), 믹서(Mixer), 시타델(Citadel) 총 3개의 모듈로 구성되어 있음
'-01. E-Learning' 카테고리의 다른 글
| 네이버클라우드와 떠나는 Cloud 여행 -3 (26) | 2024.09.09 |
|---|---|
| 네이버클라우드와 떠나는 Cloud 여행 -2 (22) | 2024.09.07 |
| 네이버클라우드와 떠나는 Cloud 여행 -1 (29) | 2024.09.06 |