마이크로서비스를 데브옵스라는 문화에 적용하기 위해선 네 가지 원칙이 필요하다.
✏️ 1. 마이크로서비스는 단일 소프트웨어 산출물을 사용해 여러 서비스 인스턴스를 시작하거나 제거할 수 있도록 자체 완비형이며 독립적으로 배포 가능해야 한다.
✏️ 2. 마이크로서비스는 구성 가능해야 한다. 서비스 인스턴스가 시작될 때 구성에 필요한 데이터를 중앙에서 읽어들이거나 환경 변수로 전달된 구성 정보를 받아야 한다. 서비스를 구성 시 사람의 개입은 없어야 함
✏️ 3. 마이크로서비스 인스턴스는 클라이언트가 위치를 알지 못하도록 투명해야 (transparent) 함. 대신 서비스 디스커버리 에이전트 (Service Discovery Agent)와 통신할 것
✏️ 4. 마이크로서비스 인스턴스들은 고장 날 수 있으므로 잘못된 서비스 인스턴스를 피해 라우팅할 수 있어야 한다. 따라서 마이크로서비스는 자신의 상태(health)를 전달해야 한다.
분산 시스템의 투명성 (transparency) 특징 중 위치 투명성 (location transparency)을 의미하며 분산된 자원의 물리적 위치를 모르더라도 서비스에 접근할 수 있어야 함
데브옵스 환경에선 이러한 네 가지 원칙을 표준 수명 주기 (lifecycle) 이벤트로 변환하여 관리함
-
⭐ 서비스 어셈블리(Service Assembly)
마이크로서비스의 패키징과 배포 -
⭐ 서비스 부트스트래핑(Service Bootstrapping)
마이크로서비스의 구성 관리 -
⭐ 서비스 등록 및 디스커버리(Service Registration/Discovery)
클라이언트가 마이크로서비스와 통신하는 법 -
⭐ 서비스 모니터링(Service Monitoring)
마이크로서비스의 상태 전달
⭐ 서비스 어셈블리(Service Assembly) - 마이크로서비스의 패키징과 배포
일관된 구축, 패키징과 배포를 하는 과정을 서비스 어셈블리라고 한다.
데브옵스 관점에서 애플리케이션 환경의 변화에 대응해 마이크로서비스의 여러 인스턴스를 신속하게 배포할 수 있어야 한다.
따라서 마이크로서비스는 필요한 의존성(런타임 엔진까지)을 모두 담아 단일 산출물로 패키징하고 설치될 수 있어야 한다. 그리고 이 산출물을 JDK가 설치된 서버에 배포한다.
⭐ 서비스 부트스트래핑(Service Bootstrapping) - 마이크로서비스의 구성 관리
서비스 부트스트래핑(Service Bootstrapping)은 마이크로서비스가 처음 가동할 때 시작하며 애플리케이션 구성 정보를 로드 (laod)한다.
구성 데이터는 단순한 편이고 일반적으로 자주 읽지만 쓰지는 않는다. 데이터베이스는 단순 키-값 짝보다 더 복잡한 데이터 모델을 관리할 목적으로 설계되었기 때문에 이 상황에서 관계형 데이터베이스를 사용하는 것은 과도하다.
1. 데이터는 정기적으로 액세스되지만 드물게 변경되므로 읽기 지연 시간이 짧아야 한다.
2. 데이터 저장소는 가용성이 좋아야 하고 읽기용 데이터 서비스에 근접해야 한다. 구성 데이터 저장소는 애플리케이션의 단일 장애 지점 (Single Point of failure)이 될 수 있으므로 완전히 중단할 수 없다.
⭐ 서비스 등록 및 디스커버리(Service Registration/Discovery) - 클라이언트가 마이크로서비스와 통신하는 법
마이크로서비스 소비자 관점에서 마이크로서비스는 위치 투명성을 가져야 한다. 클라우드 기반 환경에서 서버는 일시적(epherneral)이기 때문이다. 즉, 서비스 호스팅하는 서비스 수명이 기업 데이터센터에서 실행되는 서비스보다 더 짧다. 따라서 클라우드 기반 서비스는 실행될 서버에 완전히 새로운 IP 주소를 할당받고 신속히 시작하고 제거될 수 있어야 한다. 이를 통해 MSA는 많은 서비스 인스턴스를 실행하며 고수준의 확장성과 가용성을 가진다. 상황에 따라 신속하게 서비스에 대한 요구와 회복성을 관리할 수 있다. 그러나 서비스의 시작과 종료를 반복하는 상황에서 서비스를 직접 관리하면 장애가 발생할 수 있다.
따라서 마이크로서비스 인스턴스는 제 3자 에이전트에 스스로 등록해야하는데 이 등록 과정을 서비스 디스커버리(service discovery)라고 한다.
마이크로서비스 인스턴스를 서비스 디스커버리 에이전트에 등록할 때 인스턴스의 물리적인 IP 주소(또는 도메인 주소)와 애플리케이션이 서비스 검색에 사용할 논리적인 서비스 이름, 이 두 가지를 에이전트에 전달한다. 일부 서비스 디스커버리 에이전트는 상태 확인 (health check)를 하는 데 필요한 URL을 등록하려는 서비스에 요구하기도 한다. 상태 확인 후 서비스 클라이언트는 디스커버리 에이전트와 통신해 서비스 위치를 찾는다.
⭐ 서비스 모니터링(Service Monitoring) - 마이크로서비스의 상태 전달
서비스 디스커버리 에이전트는 클라이언트에 서빗스 위치 안내의 역할을 넘어 등록된 각 서비스 상태를 모니터링 한다. 그리고 클라이언트가 고장 난 서비스를 호출하지 않도록 자신의 라우팅 테이블에서 문제가 된 서비스 인스턴스를 제거한다.
마이크로서비스가 실행되면 service discovery agent는 해당 서비스가 가용한지 확인하기 위해 상태 확인 인터페이스(health check interface)를 계속 모니터링하고 핑(ping)한다.
특정 service instance에 문제를 발견하면 service discovery agent는 해당 instance를 정지시키거나 새로운 서비슬를 추가하는 등 조치를 취한다.
REST 기반 microservice 환경에서 health check interface는 일반적으로 JSON 페이로드와 HTTP 상태 코드를 반환하는 HTTP 엔드포인트를 노출하는 것이다.
스프링 부트 환경에서 엔드포인트를 노출하기 위해선 Spring Actuator 모듈만 추가하면 된다. Spring Actuator는 서비스 상태를 이해하고 관리하는 데 도움이 되는 엔드포인트를 기본 기능으로 제공한다.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
