The DevOps story: Building for the rigors of runtime

🚀 DevOps 관점에서의 마이크로서비스 운영 전략

🎯 마이크로서비스 운영의 핵심 원칙

DevOps 엔지니어링에서 마이크로서비스를 설계할 때 중요한 것은 서비스의 운영 및 유지보수입니다.
코드를 작성하는 것보다 서비스를 안정적으로 운영하는 것이 더욱 어렵기 때문에, 다음 네 가지 원칙을 따르는 것이 중요합니다.

1️⃣ 마이크로서비스는 독립적으로 배포 가능해야 한다.

• 서비스는 자급자족(self-contained) 되어야 하며, 독립적으로 배포할 수 있어야 한다.
• 단일 소프트웨어 아티팩트(JAR 등)로 여러 인스턴스를 실행 및 종료 가능해야 한다.

2️⃣ 마이크로서비스는 설정이 가능해야 한다.

• 서비스가 시작될 때 중앙 저장소에서 환경 설정을 읽거나, 환경 변수로 설정을 전달받아야 한다.
• 서비스 설정을 위해 사람이 직접 개입해서는 안 된다.

3️⃣ 마이크로서비스는 클라이언트에게 위치가 투명해야 한다.

• 클라이언트는 서비스의 물리적 위치를 몰라도 된다.
• 서비스는 서비스 디스커버리(agent) 를 통해 동적으로 검색되어야 한다.

4️⃣ 마이크로서비스는 자신의 상태를 보고해야 한다.

• 서비스 인스턴스는 실패할 수 있으며, 디스커버리 에이전트는 장애가 발생한 인스턴스를 제외하고 라우팅해야 한다.
• Spring Boot Actuator 등을 사용하여 서비스의 상태를 실시간으로 모니터링해야 한다.

이러한 원칙들을 DevOps 환경에서 서비스의 운영 생명주기에 적용하면 다음과 같은 4단계로 구성됩니다.

출처 : Spring Microservices in Action 2nd Edition

🛠️ 마이크로서비스 운영 생명주기

📌 1단계: 서비스 패키징 및 배포 (Assembly)

🔹 목표: 일관된 방식으로 마이크로서비스를 빌드 및 패키징하여 반복 가능하고 안정적인 배포 보장

✅ 개발자가 소스 코드를 저장소에 커밋하면,
✅ 빌드/배포 엔진이 Spring Boot의 Maven 스크립트를 실행하여 JAR 파일을 생성
✅ 실행 가능한 JAR에는 애플리케이션 코드와 런타임 컨테이너(예: Tomcat)가 함께 포함됨

mvn clean package && java -jar target/licensing-service-0.0.1-SNAPSHOT.jar

✅ 이 방식은 기존의 애플리케이션 서버와의 분리에서 벗어나, JAR 파일만으로 실행 가능한 독립적인 서비스 배포 가능

 

📌 기존 방식: 애플리케이션과 WAS를 따로 운영
📌 Spring Boot 방식: 실행 가능한 JAR에 내장된 WAS 포함 (Tomcat 등)

🔹 결과물: 실행 가능한 단일 JAR 파일이 생성됨

 

출처 : Spring Microservices in Action 2nd Edition

📌 2단계: 서비스 부트스트래핑 (Bootstrapping)

🔹 목표: 서비스가 시작될 때 환경 설정을 중앙화된 저장소에서 자동으로 불러오도록 함

✅ 서비스가 시작되면, 설정 저장소(Configuration Repository) 에서 환경 설정을 가져옴
✅ 설정은 환경 변수로 전달되거나, 중앙 집중식 설정 저장소에서 읽힘
✅ 설정 변경이 발생하면 서비스를 재시작하지 않고도 동적으로 반영 가능

🔹 구성 요소

• 설정 저장소 (예: Spring Cloud Config Server)
• 환경 변수 및 중앙화된 설정 관리

📌 중앙 구성 저장소의 필요성

• 마이크로서비스 환경에서는 수백~수천 개의 서비스가 실행될 가능성이 있음
• 모든 인스턴스를 개별적으로 설정하는 것은 비효율적이며, 장애 위험 증가
• 따라서 설정을 중앙화하고 동적으로 관리하는 것이 중요

 

출처 : Spring Microservices in Action 2nd Edition

📌 3단계: 서비스 디스커버리 (Discovery)

🔹 목표: 서비스가 동적으로 배포될 수 있도록 서비스 위치를 자동으로 찾을 수 있게 함

✅ 서비스가 시작되면 서비스 디스커버리 에이전트(예: Eureka, Consul 등)에 자신을 등록
✅ 서비스 클라이언트는 특정 서비스의 실제 IP를 몰라도 서비스 디스커버리 에이전트를 통해 위치를 확인
✅ 서비스가 중단되거나 새로운 인스턴스가 추가될 경우 자동으로 반영됨

🔹 구성 요소

• 서비스 인스턴스
• 서비스 디스커버리 에이전트 (예: Spring Cloud Eureka)
• 서비스 클라이언트

📌 클라이언트가 직접 특정 IP에 접근하는 것이 아니라, 디스커버리 서버를 통해 동적으로 서비스 인스턴스를 찾음

 

출처 : Spring Microservices in Action 2nd Edition

📌 4단계: 서비스 모니터링 (Monitoring)

🔹 목표: 서비스의 상태를 지속적으로 확인하고, 장애 발생 시 자동으로 감지하여 대응

출처 : Spring Microservices in Action 2nd Edition

✅ 서비스 디스커버리 에이전트는 주기적으로 등록된 서비스의 헬스 체크(Health Check) 수행
✅ 서비스가 정상적으로 응답하지 않거나 장애가 발생하면 라우팅에서 제거
✅ Spring Boot에서는 Spring Boot Actuator를 사용하여 자동으로 서비스 상태를 확인 가능

🔹 서비스 상태 확인 방법
1️⃣ Actuator 활성화 (pom.xml)

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

 

2️⃣ Actuator 엔드포인트 호출

GET http://localhost:8080/actuator/health

 

3️⃣ 응답 예시

{
    "status": "UP",
    "components": {
        "diskSpace": {
            "status": "UP",
            "details": {
                "total": 1002732253184,
                "free": 673821245440,
                "threshold": 10485760,
                "path": "C:\\development\\Workspace\\codes\\spring_boot3\\springmsinaction\\ch02\\licensing-service\\.",
                "exists": true
            }
        },
        "ping": {
            "status": "UP"
        },
        "ssl": {
            "status": "UP",
            "details": {
                "validChains": [],
                "invalidChains": []
            }
        }
    }
}

✅ 장애가 발생한 서비스는 서비스 디스커버리 에이전트가 자동으로 제거
✅ 서비스 상태 정보를 기반으로 자동 스케일링 및 장애 대응 가능

 

🎯 정리

단계	목적	핵심 구성 요소
1️⃣ 서비스 패키징 (Assembly)	서비스 빌드 및 배포 자동화	Spring Boot, Maven, JAR 파일
2️⃣ 서비스 부트스트래핑 (Bootstrapping)	설정을 중앙화하여 동적 관리	Config Server, 환경 변수
3️⃣ 서비스 디스커버리 (Discovery)	서비스 위치 자동 검색 및 로드밸런싱	Eureka, Consul, 서비스 레지스트리
4️⃣ 서비스 모니터링 (Monitoring)	장애 감지 및 자동 복구	Actuator, Health Check

 

이 네 가지 단계는 마이크로서비스 운영을 DevOps 관점에서 체계적으로 관리하는 핵심 프로세스입니다.
Spring Boot 및 Spring Cloud의 다양한 기능을 활용하면 운영의 복잡성을 줄이고, 자동화된 DevOps 환경을 구축할 수 있습니다! 🚀

 

💡 이제 DevOps 기반의 마이크로서비스 운영을 체계적으로 구축해보세요! 😊