12장 마이크로서비스 배포

Posted Oct 6, 2024 Updated Jan 25, 2025

By marshmallow

16 min read

12장 마이크로서비스 배포

12장 마이크로서비스 배포
12.1 서비스 배포: 언어에 특정한 패키징 포맷 패턴
__12.1.1 언어에 특정한 패키징 포맷 패턴의 장점
__12.1.2 언어에 특정한 패키징 포맷 패턴의 단점
12.2 서비스 배포: 가상 머신 패턴
__12.2.1 가상 머신 패턴의 장점
__12.2.2 가상 머신 패턴의 단점
12.3 서비스 배포: 컨테이너 패턴
__12.3.1 서비스를 도커로 배포
__12.3.2 컨테이너 패턴의 장점
__12.3.3 컨테이너 패턴의 단점
12.4 FTGO 애플리케이션 배포: 쿠버네티스
__12.4.1 쿠버네티스 개요
__12.4.2 쿠버네티스 배포: 음식점 서비스
__12.4.3 API 게이트웨이 배포
__12.4.4 무중단 배포
__12.4.5 배포와 릴리스 분리: 서비스 메시
12.5 서비스 배포: 서버리스 패턴
__12.5.1 aws 람다를 이용한 서버리스 배포
__12.5.2 람다 함수 개발
__12.5.3 람다 함수 호출
__12.5.4 람다 함수의 장점
__12.5.5 람다 함수의 단점
12.6 REST 서비스 배포: aws 람다 및 aws 게이트웨이
__12.6.1 음식점 서비스를 aws 람다 버전으로 설계
__12.6.2 ZIP 파일로 서비스 패키징
__12.6.3 서버리스 프레임워크로 람다 함수 배포
12.7 마치며

정리 전략?

전부 정리는 NO
핵심중에서 꼭 적고 가야겠다 싶은 것만!
나의 생각을 섞어서 적을것..!
떠오르는 것 먼저 간단하게..!

내용

OSGi (Open Service Gateway initiative - 개방형 서비스 게이트웨이 이니셔티브) 프레임워크는 모듈형 소프트웨어 프로그램과 라이브러리를 개발 및 배포하기위한 자바 프레임 워크이다. 각 번들은 강하게 결합하고, 동적으로 로딩이 가능한 class, jar 그리고 명시적으로 외부 종속성을 선언하는 환경설정파일의 모음이다. 쉽게 이야기해서 OSGI는 번들 단위로 관리하고 실행할 수 있는 프레임워크를 말한다.

12.1 서비스 배포: 언어에 특정한 패키징 포맷 패턴

언어에 종속된 패키징 포맷 패턴으로 배포하는 것은 추천하지 않음.

**12.1.1 언어에 특정한 패키징 포맷 패턴의 장점

빠르다

**12.1.2 언어에 특정한 패키징 포맷 패턴의 단점

리소스를 제한하기 어려움.
오토스케일링을 한다거나 그런 것을 적용하기 어려움.
여러 서비스 인스턴스가 동일 머신에서 실행될 경우 서로 격리할 수 없음
- 하나가 오작동하면 다른 하나 영향 받음
서비스 인스턴스를 어디에 둘지 자동으로 결정하기 어려움
- CPU/메모리 리소스는 한정되어 있고 각 서비스에서 효율적으로 활용하는 방향으로 배정해야 하는데, 이러한 점들을 자동으로 결정하기 어렵다. VM 기반의 클라우드 및 컨테이너 오케스트레이션 프레임워크는 이런 일을 자동으로 처리한다.

12.2 서비스 배포: 가상 머신 패턴

가상머신 virtualBox같은 것을 이용하는 것임.
가상 머신 패턴: 서비스를 VM 이미지로 묶어 프로덕션에 배포한다. 각 서비스 인스턴스가 하나의 VM 이다.

**12.2.1 가상 머신 패턴의 장점

고립성.

**12.2.2 가상 머신 패턴의 단점

무겁다.
실행이 컨테이너 배포에 비해 상대적으로 느림.

12.3 서비스 배포: 컨테이너 패턴

컨테이너 패턴: 서비스를 컨테이너 이미지로 묶어 프로덕션에 배포한다. 각 서비스 인스턴스가 곧 하나의 컨테이너다.

**12.3.1 서비스를 도커로 배포

**12.3.2 컨테이너 패턴의 장점

가상 머신 패턴보다 배포가 빠르다.
고립성.

**12.3.3 컨테이너 패턴의 단점

그래도 서버를 관리해줘야하는 이슈가 있다.

12.4 FTGO 애플리케이션 배포: 쿠버네티스

**12.4.1 쿠버네티스 개요

컨테이너 오케스트레이션 관련 프레임워크.
컨테이너들이 상호작용 하는 것을 돕는다.
리소스 관리: 여러 머신을 CPU, 메모리, 스토리지 볼륨을 묶어 놓은 하나의 리소스 풀로 취급
스케줄링: 컨테이너를 실행할 머신 선택, 유사성 찾아서 여러 컨테이너를 같은 노드에 배치하거나 반대 실행
서비스 관리: 마이크로서비스에 직접 매핑되는 서비스를 명명하고 버저닝, 롤링 업데이트가 가능해 롤백도 가능
마스터는 다음 컴포넌트를 실행한다.
- API 서버: kubectl CLI에서 사용하는 서비스 배포/관리용 REST API
- etcd: 클러스터 데이터를 저장하는 key-value
- 스케줄러: 파드를 실행할 노드 선택
- 컨트롤러 관리자: 컨트롤러 실행, 컨트롤러는 클러스터가 원하는 상태가 되도록 제어(인스턴스 개수 등)
노드는 다음 컴포넌트를 실행한다.
- kubelet: 노드에서 실행되는 파드를 생성/관리
- kube-proxy: 여러 파드에 부하를 분산하는 등 네트워킹 관리
- Pod: 애플리케이션 서비스
쿠버네티스 핵심 개념
- pod: 기본 배포 단위. IP 주소, 스토리지 볼륨을 공유하는 하나 이상의 컨테이너로 구성
- deployment: 항상 파드 인스턴스를 원하는 개수만큼 실행시키는 컨트롤러
- service: 클라이언트에 정적 네트워크 위치 제공. 서비스 디스커버리 형태를 따름
- config map: 외부화 구성이 정의된 key-value

**12.4.2 쿠버네티스 배포: 음식점 서비스

deployment 정의

deployment: 항상 파드 인스턴스를 원하는 개수만큼 실행시키는 컨트롤러

서비스 생성

**12.4.3 API 게이트웨이 배포

API 게이트 웨이는 외부 노출 포인트가 있음. nodePort 형태로 배포. 위에서 작성한 쿠베 서비스는 클러스터 내부에서만 접근 가능하다. API 게이트웨이는 클러스터 외부에서도 접근 가능해야 한다.
NodePort 서비스는 광역 클러스터 포트를 통해 클러스터의 모든 노드에 접근할 수 있다. 어떤 클러스터 노드라도 광역 클러스터 포트를 경유한 트래픽은 모두 백엔드 pod로 부하 분산 처리된다.

… type: NodePort ports:

nodePort: 30000 port: 80 targetPort: 8080 selector: app: ftgo-api-gateway
클러스터 내부: http://ftgo-api-gateway, 외부: http://:30000
NodePort 서비스를 구성한 후, 인터넷에서 들어온 요청을 노드에 부하 분산하도록 aws ELB를 구성하면 된다.

**12.4.4 무중단 배포

롤아웃이라는 이력을 관리하기에 다음 커맨드로 이전 버전으로 롤백할 수 있다.
무중단 배포를 위하여 배포와 릴리스를 분리하는 전략 사용 가능. -> 서비스 매시로 이스티오 예시가 뒤에 이어짐.

**12.4.5 배포와 릴리스 분리: 서비스 메시

배포: 서비스를 프로덕션에서 작동시키는 것
릴리스: 운영 트래픽을 처리할 수 있게 만드는 것
이스티오를 예시로 줌.
컨트롤 플레인: 데이터 플레인이 트래픽을 라우팅하도록 구성하는 등의 관리 역할
- 파일럿, 믹서로 구성됨
- 파일럿: 하부 인프라에서 배포된 서비스 관련 정보 추출, 서비스와 정상 파드 조회
- 믹서:엔보이 프록시에서 텔레메트리를 수집하고 정책 집행
데이터 플레인: 서비스 인스턴스별 엔보이 프록시로 구성
- 엔보이: 통신하는 서버

12.5 서비스 배포: 서버리스 패턴

서버관리도 필요없는 서버리스 패턴이 있음.
aws 람다가 대표적임.

**12.5.1 aws 람다를 이용한 서버리스 배포

**12.5.2 람다 함수 개발

RequestHandler 라는 인터페이스를 구현하면 됨.

**12.5.3 람다 함수 호출

호출에 4가지 방법이 있음.

HTTP 요청 처리 aws API 게이트웨이가 HTTP 요청을 람다 함수로 라우팅 API 게이트웨이는 람다 함수를 HTTPS 끝점으로 표출하고 HTTP 요청이 들어오면 이를 람다 함수로 전달해 HTTP 응답 객체를 반환하는 HTTP 프록시 역할
aws 서비스에서 생성된 이벤트 처리 S3 버킷에 객체 생성, DB 테이블의 데이터 항목이 생성/수정/삭제, SES를 통해 이메일 수신 등 이벤트가 생성되면 람다 함수가 처리되도록 트리거
람다 함수 스케줄링 크론 같은 스케줄러를 람다 함수가 주기적으로 호출되도록 설정
웹 서비스를 요청해 람다 함수 호출 웹 서비스를 요청할 때 람다 함수명과 입력 이벤트 데이터를 지정하고, 람다함수를 호출한다.

**12.5.4 람다 함수의 장점

서버 관리를 필요성이 없음.
호출한 만큼만 요금을 낼수도 있음.

**12.5.5 람다 함수의 단점

서버를 관리해야하는 상황에서 적절하지 않음.
long-tail latency
- 람다는 코드를 동적으로 실행하므로 aws가 인스턴스를 프로비저닝하고 애플리케이션을 시동하기까지 오랜 시간이 걸린다. 따라서 요청에 따라 많이 지연되는 경우도 있다.
제한된 이벤트/요청 기반 프로그래밍 모델
- 서드파티 메시지 브로커에서 유입된 메시지를 소비하는 서비스와 같이 실행 시간이 긴 서비스를 배포할 용도는 아니다.

12.6 REST 서비스 배포: aws 람다 및 aws 게이트웨이

**12.6.1 음식점 서비스를 aws 람다 버전으로 설계

**12.6.2 ZIP 파일로 서비스 패키징

**12.6.3 서버리스 프레임워크로 람다 함수 배포

12.7 마치며

참고

https://velog.io/@jimin3263/msa-12.-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%B0%B0%ED%8F%AC
https://taehoon9393.tistory.com/m/406

코드는

  
apiVersion: v1
kind: Service
metadata:
  name: ftgo-consumer-service
spec:
  ports:
    - port: 8080
      targetPort: 8080
  selector:
    svc: ftgo-consumer-service
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ftgo-consumer-service
  labels:
    application: ftgo
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        svc: ftgo-consumer-service
        application: ftgo
    spec:
      containers:
        - name: ftgo-consumer-service
          image: msapatterns/ftgo-consumer-service:latest
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
              name: httpport
          env:
            - name: JAVA_OPTS
              value: "-Dsun.net.inetaddr.ttl=30 -Xmx192m"
            - name: SPRING_DATASOURCE_URL
              value: jdbc:mysql://ftgo-mysql/ftgo_consumer_service
            - name: SPRING_DATASOURCE_USERNAME
              value: ftgo_consumer_service_user
            - name: SPRING_DATASOURCE_PASSWORD
              value: ftgo_consumer_service_password
            - name: SPRING_DATASOURCE_DRIVER_CLASS_NAME
              value: com.mysql.jdbc.Driver
            - name: EVENTUATELOCAL_KAFKA_BOOTSTRAP_SERVERS
              value: ftgo-kafka:9092
            - name: EVENTUATELOCAL_ZOOKEEPER_CONNECTION_STRING
              value: ftgo-zookeeper:2181
            - name: EVENTUATE_DATABASE_SCHEMA
              value: ftgo_consumer_service
          livenessProbe:
            httpGet:
              path: /actuator/health
              port: 8080
            initialDelaySeconds: 60
            periodSeconds: 20
          readinessProbe:
            httpGet:
              path: /actuator/health
              port: 8080
            initialDelaySeconds: 60
            periodSeconds: 20
---

Software Development, Software Design

msa 마이크로서비스 패턴 크리스 리처드슨

This post is licensed under CC BY 4.0 by the author.

12장 마이크로서비스 배포

목차

정리 전략?

내용

12.1 서비스 배포: 언어에 특정한 패키징 포맷 패턴

**12.1.1 언어에 특정한 패키징 포맷 패턴의 장점

**12.1.2 언어에 특정한 패키징 포맷 패턴의 단점

12.2 서비스 배포: 가상 머신 패턴

**12.2.1 가상 머신 패턴의 장점

**12.2.2 가상 머신 패턴의 단점

12.3 서비스 배포: 컨테이너 패턴

**12.3.1 서비스를 도커로 배포

**12.3.2 컨테이너 패턴의 장점

**12.3.3 컨테이너 패턴의 단점

12.4 FTGO 애플리케이션 배포: 쿠버네티스

**12.4.1 쿠버네티스 개요

**12.4.2 쿠버네티스 배포: 음식점 서비스

deployment 정의

서비스 생성

**12.4.3 API 게이트웨이 배포

**12.4.4 무중단 배포

**12.4.5 배포와 릴리스 분리: 서비스 메시

12.5 서비스 배포: 서버리스 패턴

**12.5.1 aws 람다를 이용한 서버리스 배포

**12.5.2 람다 함수 개발

**12.5.3 람다 함수 호출

**12.5.4 람다 함수의 장점

**12.5.5 람다 함수의 단점

12.6 REST 서비스 배포: aws 람다 및 aws 게이트웨이

**12.6.1 음식점 서비스를 aws 람다 버전으로 설계

**12.6.2 ZIP 파일로 서비스 패키징

**12.6.3 서버리스 프레임워크로 람다 함수 배포

12.7 마치며

참고

코드는

Trending Tags