[DevOps] Spring 모놀리식 서버 & Cloud MSA 서버 Kubernetes 배포 가이드

이지연·2026년 3월 16일

DevOps

목록 보기
24/24

개요

Spring Boot 모놀리식 서버와 Spring Cloud MSA 서버를 AWS EKS에 배포하는 전체 과정을 실습 중심으로 정리하였다.
CI/CD 자동화, 오토스케일링, ArgoCD, 모니터링까지 포함하여 프로덕션 수준 배포 환경을 구축 예정

Spring 모놀리식 서버 배포

아키텍처

  • k8s기반 spring multi pod 및 multi 인스턴스 구성
  • rds를 통한 DB구축 및 redis pod실행
  • github actions를 통한 CI/CD 자동화

배포 절차

1. 인프라 자원 사전 생성

  • mysql rds DB 생성 및 3306 보안그룹 추가
    • db 퍼플릭엑세스 허용
    • 스키마 생성
    • 인코딩셋 utf8로 변경
      ALTER DATABASE ordermsa CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
  • redis pod/svc 생성
  • ecr레파지토리 생성

2. 이미지 빌드 및 업로드(수동)

  • application.yml파일 prod로 설정 변경
  • 로컬에서 ecr 로그인
    aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin 346903264902.dkr.ecr.ap-northeast-2.amazonaws.com/bradkim/ordersystem
  • 로컬에서 도커 이미지 빌드 및 push
    docker build -t 346903264902.dkr.ecr.ap-northeast-2.amazonaws.com/bradkim/ordersystem:latest -f ./2.ordersystem/Dockerfile ./2.ordersystem
docker push 346903264902.dkr.ecr.ap-northeast-2.amazonaws.com/bradkim/ordersystem:latest

3. 쿠버네티스 자원 생성

Secret 생성

  • k8s의 보안 정보 관리 서비스
  • Secret 생성
    kubectl create secret generic <secret명>
ex) kubectl create secret generic ordersystem-secrets --from-literal=DB_HOST=<your-db-host> --from-literal=DB_USERNAME=<your-db-username> --from-literal=DB_PW=<your-db-username> --from-literal=AT_SECRET_KEY=xxxx --from-literal=RT_SECRET_KEY=yyyy -n my-namespace
  • Secret 조회
    kubectl get secret <secret명> -o yaml 또는 콘솔에서 조회
    • 해당 내용은 인코딩 되어있으므로, 디코딩 필요
  • Secret 삭제
    kubectl delete secret ordersystem-secrets
  • Secret 정보를 스프링 pod에 적용
    • 스프링 서버의 중요 secret값들을 Secret자원으로 생성
    • deployment의 env설정과 application.yml에서 ${} 변수 세팅을 통해 Secret 적용
    • 스프링 이미지가 빌드되는 시점에는 빠져있던 중요 secret값들이 pod가 실행되는 시점에 Secret자원으로부터 주입

spring서버 pod/svc 적용
Ingress 자원 적용

4. https 통신을 위한 인증서 관련 작업

암호화 원리, SSL(TLS) 인증서

인증서 발급 흐름

  • 우리 서버에서 공개키와 비밀키를 생성
  • 공개키와 서버 정보로 CSR(인증서서명요청서)를 생성
  • CA(인증기관)에 CSR을 제출한 후에, CA에서 도메인 소유 여부를 검증한 후에 디지털 서명을 하여 우리 서버로 인증서를 발급

cert-manager 생성

  • cert-manager는 Kubernetes에서 Certificate자원을 인지하고, TLS 인증서를 자동으로 발급, 갱신 및 관리하는 컨트롤러

  • cert-manager를 위한 namespace 생성

    kubectl create namespace cert-manager

  • cert-manager CRDs 설치

    • cert-manager가 제대로 작동하기 위한 기반 구조 구성(Issuer, ClusterIssuer등의 리소스)
    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.5.0/cert-manager.crds.yaml

  • cert-manager 배포

    • cert-manager 컨트롤러 자체(Pod, Deployment 등)를 설치
    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.5.0/cert-manager.yaml

ClusterIssuer 생성

  • 어떤 인증 기관(CA)에서 인증서를 발급받을지
  • 어떤 인증서의 종류 등을 사용할지를 정의

Certificate 생성

  • 공개키, 도메인정보를 조합하여 CSR 생성
  • 인증서를 받기 위해서는 반드시 해당 도메인에 대한 소유 인증이 필요하므로, route53에 alb등에 대한 정보 사전 등록 필요
  • Secret에 발급받은 인증서와 비밀키를 저장(key:value 형태)
  • Certificate 리소스가 성공적으로 인증서를 발급받았고, 해당 인증서가 지정된 Secret에 저장되면 Certificate status값이 True로 변경
    kubectl describe certificate <Certificate이름> -n <Namespace이름>
  • Ingress가 해당 Secret을 참조하여 HTTPS(443)를 자동 활성화

5. github actions를 통한 CI/CD 자동화

  • .github경로에 스크립트 적용

k8s배포 자동화 스크립트

  • github레포를 본인 repo로 업로드

    • github private 레포 생성
    • .git폴더 삭제
    • git init
    • git remote add origin new레포주소

  • github secret에 중요 정보 추가

  • 코드 github에 push

    git add .
git commit -m "메시지"
git checkout -b main
git push origin main

오토스케일링

Pod 오토스케일

  • 컨테이너 자동확장
  • Kubernetes에서 Deployment의 자동 확장(autoscaling)을 설정하려면 Horizontal Pod Autoscaler (HPA)를 사용
  • HPA는 CPU 사용량이나 사용자 정의 파라미터에 기반하여 파드의 수를 자동으로 조정

적용절차
1. deployment 설정

  • pod에 resource 사전 제한 설정 필요
  • pod가 생성/삭제되는 과정에서도 cpu가 튈수도 있으므로 hpa와 resource limit의 cpu 여유롭게 세팅

  1. 메트릭 서버 설치

    kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.3/components.yaml
    • 기 존재 하는 메트릭서버 사전 삭제 후 설치 권장
      kubectl delete -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.3/components.yaml
    • 메트릭 서버의 역할은 HPA가 파드(Pod)의 리소스 사용량을 모니터링하고, 이를 기반으로 자동 확장을 수행할 수 있도록 필요한 메트릭 데이터를 제공

  2. HPA 스크립트 생성 후 적용

hpa스크립트

메트릭 서버와 HPA를 통한 pod 현황 조회

kubectl get hpa brad-order-backend-hpa -n bradkim -w
  • -w는 --watch 옵션을 의미

부하 테스트

  • pod 접속
    kubectl exec -it 파드명 -- /bin/sh
  • curl 없는 경우 설치
    apk add --no-cache curl
  • 서버 api요청을 통한 서버부하
    while true; do curl -s http://brad-order-backend-service/product/list; done
  • 부하 중단시 pod 감소

EC2 오토스케일

  • 원리
    • cluster-autoscaler는 Kubernetes 클러스터에서 노드의 수를 자동으로 조절해주는 프로그램
    • cluster-autoscaler는 자원사항을 인지하고 Node(EC2) 개수를 AWS EC2 Auto Scaling Group에 노드 수 증가/감소 요청

작업 진행 개요

  • NodeGroup(ASG)에 태그 추가
  • eks, asg 등에 접근할수 있는 iam 역할 생성 및 autoscaler pod에 역할 부여
  • cluster-autoscaler pod 실행

작업 진행

  1. NodeGroup(ASG)에 태그 추가

    • k8s.io/cluster-autoscaler/enabled → true
      • 해당 ASG가 클러스터 오토스케일러의 관리 대상이라는 것을 표시
    • k8s.io/cluster-autoscaler/<클러스터이름> → owned
      • 클러스터 이름을 명시하여, 이 ASG가 특정 클러스터에 속해 있고 해당 클러스터의 오토스케일러가 관리함을 표시

  2. ID 제공업체 추가

    • ID 제공업체는 AWS가 신뢰할 수 있는 주체가 누구인지를 알아볼 수 있게 해주는 요소이고, 제공업체로 추가함으로서 신뢰할수 있는 주체에게 role을 사용할 수 있게 해줌
    • 즉, 이 절차는 eks내의 요소가 role을 사용할 수 있게 해주는 과정
    • OpenID Connect 추가
      • eks 클러스터 들어가서 OpenID Connect 공급자 URL을 확인 후 입력
      • 대상에 sts.amazonaws.com 값 추가
        • AWS의 보안 토큰 서비스(STS)
        • AssumeRole, AssumeRoleWithWebIdentity 같은 임시 보안 자격 증명 발급을 담당하는 서비스
        • cluster-autoscaler 같은 Pod는 STS에 Role 사용 요청

  3. iam에 역할 생성

    • IAM Role을 생성하고 이를 cluster-autoscaler Pod에 부여함으로서, EKS 및 EC2 ASG에 접근하여 노드를 자동으로 증감시킬 수 있도록 설정

    • 신뢰할 엔터티 선택에서 신뢰할 엔터티 직접 설정

      • 신뢰 정책이란 누가 이 역할을 사용할 수 있는가를 결정
      • 아래 신뢰 정책 부여
        {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<YOUR_EKS_OIDC_PROVIDER>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<YOUR_EKS_OIDC_PROVIDER>:sub": "system:serviceaccount:kube-system:cluster-autoscaler"
        }
      }
    }
  ]
}
        • cluster-autoscaler라는 이름의 ServiceAccount를 사용하는 Pod가 이 IAM Role을 assume(사용)할 수 있도록 허용해주는 설정
        • 위의 AWS_ACCOUNT_ID에는 AWS 계정 ID(숫자 12자리)를 입력
        • 위의 YOUR_EKS_OIDC_PROVIDER에는 OIDC값을 https:// 떼고 입력

    • 역할에 아래 정책 추가

      • AmazonEKSClusterPolicy
      • AutoScalingFullAccess
      • AmazonEC2FullAccess

  4. cluster-autoscaler pod 실행

    • 아래 yml 파일 다운로드

      https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

    • yml파일 주요 수정사항

      • role 부분에 위에서 만든 iam을 annotations부분에 추가

        apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-addon: cluster-autoscaler.addons.k8s.io
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
  namespace: kube-system
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::148761635844:role/autoscale-role

      • 이미지버전변경, cluster-name이름 추가, env 추가

        containers:
- image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.29.0
  name: cluster-autoscaler
  command:
    - ./cluster-autoscaler
    - --v=4
    - --cluster-name=my-cluster
    - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster
  env:
  - name: AWS_REGION
    value: "ap-northeast-2"

    • 아래 yml파일 kubectl apply

    최종 변경 완료한 yml 파일

인스턴스 증가 감소 테스트

  • pod생성 부하 발생시 ec2 인스턴스 증가
  • pod생성 부하 감소시 약 10분뒤 인스턴스 감소

ArgoCD 활용 및 프로메테우스/그라파나를 활용한 모니터링

ArgoCD

개요

  • Argo CD는 GitOps 방식의 CD(Continuous Delivery) 도구
  • k8s의 상태를 Git 저장소로부터 가져와 자동으로 Kubernetes에 배포
  • github의 yml과 실제 클러스터가 sync가 안맞으면 argocd가 github기준으로 강제 sync
    • 원래 있던 리소스를 누가 수동으로 삭제하거나 변경하더라도 새롭게 생성하거나 github의 설정사항 유지
    • 다만, 이때 github에 없는 리소스를 누가 만들었다고해서 삭제하지는 않음

장점

  • 사람의 실수를 줄이고, 변경 이력 관리가 명확
    • 모든 Kubernetes 리소스 상태를 Git에서 관리하여 이력을 관리하고, 누군가 수동으로 클러스터 상태를 바꿔도 k8s자원 유지
  • 웹 UI를 통한 실시간 상태 모니터링
    • 웹 UI를 통해 애플리케이션 상태, 배포 이력, Sync 상태를 시각적으로 확인 가능

설치 및 환경구성

  1. argocd관련 네임스페이스 생성

    kubectl create namespace argocd

  2. argocd 자원생성

    • Argo CD의 pod등 핵심 컴포넌트들 설치
      kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

  3. argocd관련 application 자원 생성

    • Argo CD에게 어떤 Git 저장소의 어떤 경로에 있는 K8s 자원을 바라봐야 할지 알려주는 선언

    Application 자원 yml 파일

argocd 테스트

  • depl pod의 개수를 임의로 수정후 직접 apply
  • github에 정의된 depl pod의 개수로 원상복구되는지 확인

웹UI 접속

  • 로컬대시보드 접속

    kubectl port-forward svc/argocd-server -n argocd 8080:443
    • http://localhost:8080로 접속

  • public대시보드 접속

    • https 관련 스크립트 수정
      • argocd 서버는 내부적으로 https로 default 실행되므로 http로 변경
      • Ingress에서 백엔드까지 암호화된 채로 전달하는 HTTPS → HTTPS는 불가
    kubectl edit deployment argocd-server -n argocd

    • /usr/local/bin/argd-server 아래 줄에 --insecure 추가

            containers:
      - args:
        - /usr/local/bin/argocd-server
        - --insecure

    • 메모장 저장후 닫으면 argocd rollout 실행

    • ingress, https 적용

    • [https://argo.bradkim198.shop](https://argo.bradkim198.shop) 로 접속

  • 초기 계정 및 비밀번호 확인

    • 계정 : admin
    • 비밀번호
      kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}"
      • 위 명령어로 비밀번호 조회 후 decoding하여 사용

프로메테우스/그라파나

개요

  • Prometheu는 CPU 사용률, 메모리 등 시스템 정보 수집 시스템
    • 각종 자원을 수집해주는 exporter들(process-exporter, nginx-exporter 등)과 연결하여 사용
    • 대표적으로 Node Exporter는 노드(서버) 리소스 상태를 수집하여 Prometheus가 읽을 수 있게 변환해주는 프로그램
  • Grafana는 Prometheus 등의 데이터 소스로부터 시각화를 제공하는 대시보드 도구

작업절차

  1. 관련 자원 생성

    kubectl create namespace monitoring
    • 프로메테우스, node exporter, graphana 관련 yml적용

  2. 로컬대시보드 접속

    kubectl port-forward svc/grafana 3000:3000 -n monitoring

  3. 대시보드 로그인

    • Grafana에 로그인 (ID: admin, PW: admin)

  4. Grafana에서 Prometheus 연동

  5. 대시보드 설정

    • Dashboard → Import → 대시보드 템플릿 ID(1860) 사용
    • 대시보드 ID는 grafana에서 제공해주는 템플릿 ID(원하는 템플릿의 URL을 통해 확인)

Spring Cloud MSA 서버 배포

로컬환경에서의 MSA

핵심요소

  • Gateway (API 게이트웨이)

    • Spring Cloud Gateway는 시스템의 입구 역할을 하는 API 게이트웨이
    • 모든 클라이언트 요청은 gateway의 단일 진입점을 통해 각 서비스로 라우팅
    • cors처리, 인증처리 등 서버 공통 사항을 단일 진입점에서 처리하여 중복 방지

  • eureka(서비스디스커버리 )

    • Eureka 서버는 모든 마이크로서비스의 위치 정보를 가지고 있으며, 마이크로서비스의 위치를 탐색하는 서비스디스커버리(서비스레지스트리) 역할 수행

  • 모듈간 동기통신과 비동기 통신

    • 동기통신
      • 반드시 응답을 기다려야 하는 종류의 API요청의 경우 동기통신
      • msa 아키텍처에서 서비스 간의 통신을 간편하게 할 수 있도록 도와주는 feignclient활용(또는 resttemplate등)
    • 비동기통신
      • 반드시 응답을 기다릴 필요가 없거나 응답이 오래걸리는 API요청의 경우
      • kafka를 활용하여 이벤트기반 비동기 통신

로컬환경에서 msa 실행시 필요 프로그램

  • mysql에 스키마 생성

    create database ordermsa;

  • redis 실행

  • kafka 실행

    • 아래 docker-compose.yml 파일을 docker-compose up -d 명령어로 실행

    docker-compose.yml

프로그램 실행

  • 개별 프로젝트를 intellij로 open후 eureka, gateway, 각모듈을 순차적으로 실행
  • 회원가입, 로그인, 상품등록, 주문하기 테스트

Spring Cloud MSA 배포작업

아키텍처

방법1

  • 라우팅 흐름 : ingress-controller(ingress) → api gateway → 각 서비스 모듈
  • 서비스 디스커버리 방식
    • 유레카를 제외하고 k8s의 서비스디스커버리(service) 이용
    • gateway에서 k8s의 service를 이용해 로드밸런싱

방법2

  • 라우팅 흐름 : ingress-controller(ingress) → 각 서비스 모듈

배포 작업 절차

  • rds에 스키마 생성
  • 각 프로젝트별 ecr 레포지토리 생성
  • redis, kafka pod실행
  • apigateway 모듈
    • apigateway로의 라우팅을 위한 ingress 적용
    • yml에서 라우팅을 위한 모듈별 service uri 추가
    • dockerfile 생성
    • depl, svc 자원 생성 및 적용
  • 각 서비스 모듈
    • 모듈간 호출시 feign 설정에서 k8s service를 통한 호출로 코드 변경
    • dockerfile 생성
    • depl, svc 자원 생성 및 적용
  • github actions 스크립트 추가 및 적용

이 가이드를 통해 모놀리식 → MSA 전환, GitOps, 오토스케일링, 모니터링까지 완전한 프로덕션 환경을 구축할 수 있습니다!

profile
이지연
Eazy하게
이전 포스트

[DevOps] Kubernetes 주요 요소별 실습 가이드

0개의 댓글