마이크로서비스의 설계, 구현, 유지 보수 과정이 잘 관리되지 않으면 문제를 신속하게 발생시킬 수 있다. 따라서 마이크로서비스 솔루션을 도입할 때는 성능 문제나 병목 현상, 운영상의 문제를 방지하기 위해 아키텍처를 효율적이고 확장 가능하게 유지하는 것이 중요하다. 이를 위해 모범 사례를 적용하는 것이 필수적이며, 이러한 모범 사례를 준수하면 시스템에 대한 이해가 필요한 새로운 개발자들이 더 빠르고 쉽게 적응할 수 있다.
시스템이 더 많이 분산될수록 실패할 곳은 더 많아진다.
마이크로서비스 아키텍처는 단일 모놀리스 애플리케이션과 달리 여러 개발 서비스가 상호작용하는 복잡한 생태계를 구성하기 때문에 더 많은 실패 지점이 존재할 수 있다. 이는 개발자가 마이크로서비스 애플리케이션이나 아키텍처를 구축할 때 다양한 관리 업무와 동기화 문제, 실패 지점에 직면하는 주요 원인이다. 이러한 문제를 최소화하려면 실패 지점을 피할 수 있는 방법을 강구해야 한다. 이를 해결하는 방법 중 하나가 스프링 클라우드를 사용하는 것이다. 스프링 클라우드는 최소한의 구성으로 마이크로서비스 아키텍처를 빠르게 구축할 수 있는 기능들을 제공한다. 예를 들어, 서비스 등록, 디스커버리, 회로 차단기, 모니터링 등 다양한 기능을 통해 마이크로서비스의 안정성을 높이고 효율적으로 관리할 수 있다.
2.1 스프링 클라우드란?
스프링 클라우드는 VMWare, 하시코프, 넷플릭스 등 여러 오픈소스 회사의 제품을 바탕으로 마이크로서비스 애플리케이션을 구축하는 데 유용한 도구 집합을 제공한다. 이 도구는 애플리케이션의 설정 및 구성을 단순화하고, 가장 흔히 사용되는 패턴에 대한 해결책을 스프링 애플리케이션에 쉽게 적용할 수 있도록 돕는다. 덕분에 개발자는 마이크로서비스 애플리케이션을 만들고 배포하는 데 필요한 모든 인프라스트럭처 구성에 대한 복잡한 세부사항을 신경 쓸 필요 없이, 오직 애플리케이션 로직에 집중하여 코드를 작성할 수 있다.
2.1.1 스프링 클라우드 컨피그
스프링 클라우드 컨피그는 애플리케이션의 구성 데이터를 중앙에서 관리할 수 있게 해준다. 특히 환경별로 구성 데이터를 분리하여, 여러 마이크로서비스 인스턴스를 실행할 때에도 일관된 구성을 유지할 수 있도록 보장한다. 이 시스템은 배포된 마이크로서비스와 구성을 완전히 분리시켜, 구성이 변경될 때마다 서비스들을 일관되게 유지할 수 있게 도와준다. 또한 스프링 클라우드 컨피그는 자체적인 프로퍼티 관리 저장소를 제공하지만, 다음과 같은 여러 오픈소스 프로젝트와도 통합될 수 있다.
- 깃 (Git): 모든 테스트 파일의 변경 사항을 관리하고 추적할 수 있는 오픈 소스 버전 제어 시스템이다, 스프링 클라우드 컨피그는 깃 백엔드 저장서와 통합되어 저장소의 애플리케이션 구성 데이터를 읽는다.
- 콘솔 (Console): 서비스 인스턴스가 서비스에 등록되도록 만드는 오픈 소스 서비스 디스커버리다. 서비스 클라이언트는 콘솔에 질의해서 등록된 서비스 인스턴스의 위치를 찾을 수 잇다. 콘솔에는 애플리케이션 구성 데이터를 저장하는 용도의 키-값 저장소 데이터베이스도 포함되어 있다.
- 유레카 (Eureka): 콘솔과 마찬가지로 우사한 서비스 디스커버리 기능을 제공하는 넷플릭스 오픈 소스 프로젝트다. 유레카에도 스프링 클라우드 컨피그와 함께 사용 가능한 키-값 데이터베이스가 있다.
2.1.2 스프링 클라우드 서비스 디스커버리
스프링 클라우드 서비스 디스커버리를 사용하면 클라이언트가 서비스의 물리적 위치(IP 주소나 서버 이름)를 알 필요 없이 논리적 이름을 통해 서버의 비즈니스 로직에 접근할 수 있다. 또한, 서비스 인스턴스가 시작되거나 종료될 때 자동으로 등록 및 등록 취소가 이루어진다. 이를 통해 물리적 위치에 구애받지 않고 서비스의 위치를 관리할 수 있다.
스프링 클라우드 서비스 디스커버리는 콘솔, 주키퍼 (Zookeepr), 유레카 (Eureka)로 구현할 수 있다.
2.1.3 스프링 클라우드 로드 밸런서와 Resilience4j
스프링 클라우드는 여러 오픈 소스 프로젝트와 잘 통합되어 마이크로서비스 클라이언트 회복성 패턴을 효율적으로 구현할 수 있도록 돕는다. 예를 들어, 스프링 클라우드는 Resilience4j 라이브러리와 스프링 클라우드 로드 밸런서 프로젝트를 포함하여 마이크로서비스 내부에서 쉽게 사용할 수 있도록 제공한다. Resilience4j 라이브러리는 회로 차단기, 재시도, 벌크헤드와 같은 서비스 클라이언트 회복성 패턴을 신속하게 구현할 수 있게 한다.
스프링 클라우드 로드 밸런서 프로젝트는 유레카와 같은 서비스 디스커버리 에이전트와의 통합을 간소화하며, 서비스 소비자 호출에 대한 클라이언트 부하 분산 기능을 제공한다. 이로 인해 서비스 디스커버리 에이전트가 일시적으로 가용하지 않더라도, 클라이언트 서비스는 계속해서 호출을 진행할 수 있다.
2.1.4 스프링 클라우드 API 게이트웨이
API 게이트웨이는 마이크로서비스 애플리케이션에서 서비스 라우팅을 담당하는 역할을 한다. 이름에서 알 수 있듯이, 서비스 요청을 프록싱하고 대상 서비스가 호출되기 전에 모든 호출이 이 게이트웨이를 통과하도록 한다. 이를 통해 서비스 호출을 중앙 집중화하고, 보안 인가, 인증, 콘텐츠 필터링, 라우팅 규칙과 같은 표준 서비스 정책을 시행할 수 있다. 스프링 클라우드 게이트웨이를 사용하면 API 게이트웨이를 구성할 수 있다.
2.1.5 스프링 클라우드 스트림
스프링 클라우드 스트림은 마이크로서비스에 경량 메시지 처리 기능을 쉽게 통합할 수 있는 기술로, 애플리케이션에서 발생하는 비동기 이벤트를 활용하여 지능형 마이크로서비스를 구축하는 데 도움을 준다. 또한, RabbitMQ나 Kafka와 같은 메시지 브로커와 마이크로서비스를 빠르게 통합할 수 있다.
2.1.6 스프링 클라우드 슬루스
스프링 클라우드 슬루스는 고유한 추적 식별자를 애플리케이션에서 사용되는 HTTP 호출과 메시지 채널(RabbitMQ, Kafka 등)에 통합한다. 이러한 추적 식별자, 즉 상관관계 ID나 트레이스 ID를 활용하면 애플리케이션 내 여러 서비스를 통과하는 트랜잭션을 추적할 수 있다.
스프링 클라우드 슬루스의 진정한 가치는 ELK 스택과 같은 로깅 집계 도구나 집킨과 같은 추적 도구와 결합될 때 발현된다. 오픈 집킨은 스프링 클라우드 슬루스에서 생성한 데이터를 받아, 단일 트랜잭션과 연결된 서비스 호출 흐름을 시각화하는 데 도움을 준다.
ELK 스택은 아래의 세 가지 오픈 소스 프로젝트의 준말이다.
- 일렉스틱서치 (Elasticsearch)는 검색 및 분석 엔진이다.
- 로그스태시(Logstash)는 데이터를 소비한 후 스태시 (stash)로 전송하기 위해 변환하는 서버 사이드 데이터 프로세싱 파이프라인이다.
- 키바나(Kibana)는 사용자가 전체 스택의 데이터를 질의하고 시각화할 수 있는 클라이언트 UI다.
2.1.7 스프링 클라우드 시큐리티
스프링 클라우드 시큐리티는 서비스에 접근할 수 있는 사용자와 사용자가 서비스에서 수행할 수 있는 작업을 제어하는 인증 및 인가 프레임워크이다. 이 프레임워크는 토큰 기반 인증 시스템을 사용하여, 서비스 간에 통신할 때 인증 시스템에서 발급한 토큰을 통해 서로 신원을 확인하고 권한을 검증한다. 또한, 스프링 클라우드 시큐리티는 JWT를 지원하며, JWT는 OAuth2 토큰 형식을 표준화하고, 생성된 토큰에 대한 서명을 정규화하여 보안을 강화한다.
2.2 스프링 클라우드 예제
예제 생략
@EnableEurekaClient 어노테이션은 마이크로서비스 애플리케이션이 유레카 서비스 디스커버리 에이전트에 등록되도록 활성화하는 역할을 한다. 이 어노테이션을 사용하면 애플리케이션은 자신을 유레카 서버에 등록하고, 이를 통해 원격 REST 서비스 엔드포인트를 조회할 수 있게 된다. 또한, 유레카 서버의 위치나 포트 번호와 같은 구성 정보는 일반적으로 애플리케이션의 프로퍼티 파일에 설정된다.
@EnableEurekaClient 어노테이션은 스프링 부트 애플리케이션에서 유레카 클라이언트를 활성화하는 역할을 한다. 하지만, 만약 pom.xml 파일에 spring-cloud-netflix-eureka-client 의존성을 추가했다면, 사실 이 어노테이션은 선택사항임을 알 필요가 있다.
스프링 클라우드 버전 1.4 이상에서는 @EnableEurekaClient를 명시적으로 선언하지 않더라도, spring-cloud-starter-netflix-eureka-client 의존성만 추가하면 자동으로 유레카 클라이언트 기능이 활성화된다. 즉, @EnableEurekaClient를 명시적으로 사용하지 않아도, 스프링 부트 애플리케이션이 유레카 서버와 통신하고 서비스 디스커버리 기능을 활용할 수 있다.
클라이언트가 서비스를 호출할 때마다 중앙 집중식 로드 밸런서를 거치지 않고, 대신 각 클라이언트가 직접 라운드 로빈 방식으로 서비스 인스턴스를 호출하도록 하는 방식이다. 이 방식은 클라이언트가 서비스 디스커버리를 통해 서비스 인스턴스의 목록을 얻고, 해당 목록에서 하나씩 선택하여 호출하게 한다. 이를 통해 중앙 집중식 로드 밸런서가 필요 없어지고, 로드 밸런서 다운과 같은 장애 지점도 제거된다.
이 방식은 서비스 소비자가 서비스 인스턴스에 직접 접근하는 형태로, 장애 지점의 위험을 줄이고, 시스템을 더욱 분산적이고 탄력적으로 만들어 준다. 또한, 서비스 인스턴스가 추가되거나 삭제될 때 클라이언트가 자동으로 이를 인식하여 호출을 조정할 수 있다.
2.3 클라우드 네이티브 마이크로서비스 구축 방법
클라우드-레디 (cloud-ready) 애플리케이션은 원래 컴퓨터나 온프레미스 서버에서 실행되던 애플리케이션을 클라우드 환경에 적응시킨 것이다. 클라우드 시대가 열리면서 이러한 애플리케이션은 고정된 환경에서 동적이고 유연한 클라우드 환경으로 전환되었다. 예를 들어, 클라우드-언레디 (cloud-unready) 애플리케이션은 데이터베이스 설정이 고정된 로컬 기반으로 각 환경(개발, 스테이징, 운영)에 맞게 수동으로 설정을 변경해야 했다.
반면, 클라우드 레디 애플리케이션은 구성 정보를 외부화하여 소스 코드를 수정하지 않고도 다양한 환경에 신속히 적용할 수 있다. 이를 통해 애플리케이션은 한 번 빌드된 상태에서 여러 환경에서 실행될 수 있는 유연성을 갖추게 된다.
클라우드 네이티브 (cloud-native) 애플리케이션은 클라우드 컴퓨팅의 모든 이점과 서비스를 최대한 활용하도록 설계된 애플리케이션이다. 이 애플리케이션은 기능을 확장 가능한 마이크로서비스로 분할하여 컨테이너 환경에서 여러 서버에 분산 실행할 수 있도록 만들어진다.
이후, 이러한 마이크로서비스는 지속적 전달 (CD) 워크플로를 지원하는 데브옵스 프로세스를 통해 관리된다. 이를 통해 가상화된 인프라스트럭처에서 서비스의 배포, 운영, 유지보수를 보다 효율적으로 수행할 수 있다.
클라우드 레디 애플리케이션은 클라우드 환경에서 바로 작동할 수 있도록 설계되어, 추가적인 변경이나 변환이 필요하지 않다는 점이 중요하다. 이러한 애플리케이션은 특정 하위 컴포넌트가 비가용 상태가 되더라도 이를 처리하고 정상적으로 동작할 수 있도록 설계된다. 이는 클라우드 환경에서의 높은 가용성과 복원력을 보장하기 위해 필수적인 요소다.
- 데브옵스(DevOps)는 개발(Development)과 운영(Operations)의 합성어로, 개발자와 IT 운영 팀 간의 협업, 소통, 통합을 강조하는 소프트웨어 개발 방법론을 의미한다. 데브옵스의 핵심 목표는 소프트웨어 전달 프로세스와 인프라스트럭처 변경을 자동화하여 비용을 절감하고 효율성을 높이는 데 있다. 이를 통해 소프트웨어 개발 및 배포 속도를 가속화하고, 품질과 안정성을 동시에 확보할 수 있다.
- 마이크로서비스는 작고 느슨하게 결합된 분산 서비스로 구성된다. 이를 통해 대규모 애플리케이션을 관리하기 쉬운, 명확하게 정의된 책임을 가진 컴포넌트로 나눌 수 있다. 이렇게 분해하면 대규모 코드베이스에서 흔히 발생하는 복잡성 문제를 완화하고, 각 서비스가 독립적으로 개발, 배포, 확장될 수 있도록 지원한다.
- 지속적 전달 (continuous delivery)은 소프트웨어 개발 관행 중 하나로, 소프트웨어 전달 프로세스를 자동화하여 운영 환경으로의 배포를 신속하게 수행할 수 있도록 지원한다. 이를 통해 개발된 기능을 짧은 주기로 안정적으로 배포할 수 있다.
- 컨테이너는 마이크로서비스를 배포하는 방식으로 가상 머신 (VM) 이미지를 사용하는 방법의 자연스러운 확장이다. 많은 개발자는 이제 하나의 VM 전체에 서비스를 배포하는 대신, 도커와 같은 컨테이너 기술을 활용하여 클라우드 환경에 서비스를 배포한다.
12 팩터 앱은 클라우드 네이티브 마이크로서비스를 설계하고 구축하는 과정에서 발생하는 어려움을 극복하기 위해 활용할 수 있는 헤로쿠의 모범 사례 지침이다. 이 방법론을 따르면 고품질의 클라우드 네이티브 애플리케이션, 즉 마이크로서비스를 효과적으로 개발할 수 있다. 12 팩터 앱은 분산 서비스의 동적 확장과 기본 원칙에 초점을 맞춘 개발 및 설계 지침의 집합이다.
2002년에 헤로쿠의 개발자들이 제안한 12 팩터 앱 방법론은 마이크로서비스를 구축하기 위한 12가지 모범 사례를 제시하는 데 목적이 있다. 이 방법론은 현대 애플리케이션 개발에서 자주 직면하는 문제들을 다루기 위한 일반적인 용어를 정의하며, 동시에 이러한 문제들을 효과적으로 해결할 수 있는 실용적인 해결책을 제공한다.
팩터 애플리케이션의 모범 사례
- 코드베이스
- 의존성
- 구성 정보
2.3.1 코드베이스
각 마이크로서비스는 하나의 소스 코드 저장소를 기반으로 하며, 코드베이스의 변경 사항은 버전 관리 (version control) 시스템을 통해 추적된다. 이 때, 서버 프로비저닝 정보는 코드베이스 내에 포함되지 않으며, 모든 설정과 관련된 정보는 외부에서 관리된다.
코드베이스는 각 배포 환경 (개발, 테스트, 스테이징, 운영 등)에 맞게 독립적으로 존재하며, 다른 마이크로서비스와 공유되지 않는다. 여러 환경에 걸쳐 코드베이스를 공유하게 되면, 서로 다른 릴리스 버전이 혼합될 수 있어 문제가 발생할 수 있기 때문에 이를 분리하여 관리하는 것이 중요한 지침이다.
2.3.2 의존성
이 사례는 애플리케이션에서 메이븐 (Maven)이나 그레이들 (Gradle)같은 자바 빌드 도구를 사용하여 의존성을 명확히 선언하는 방법을 강조한다. 예를 들어, 써드파티 라이브러리의 JAR 파일을 사용할 때 각 의존성에 대해 특정 버전 번호를 명시하면, 마이크로서비스가 항상 동일한 라이브러리 버전으로 빌드될 수 있다. 이렇게 버전 번호를 고정하면, 빌드 환경 간의 일관성을 유지할 수 있으며, 나중에 발생할 수 있는 호환성 문제를 예방할 수 있다. 예를 들어, 개발과 테스트 환경에서 동일한 버전의 라이브러리가 사용되므로, 배포 환경에서도 예상치 못한 오류가 발생할 확률이 줄어든다.
2.3.3 구성 정보
애플리케이션의 구성 정보, 특히 환경별 구성 정보를 저장하는 방식에 관한 사례다. 구성 정보를 절대로 소스 코드에 포함시키지 말고, 구성 정보를 배포할 마이크로서비스와 완전히 분리해서 관리하는 것이 최선이다.
100개로 확장된 특정 마이크로서비스의 구성 정보를 업데이트하는 시나리오를 가정한다. 만약 구성 정보가 마이크로서비스 내부에 포함되어 있다면, 구성 정보를 변경하려면 100개의 인스턴스를 모두 재배포해야 한다. 하지만 마이크로서비스가 외부 구성 정보를 가져오거나 클라우드 서비스를 사용한다면, 마이크로서비스를 재시작하지 않고 실행 중인 상태에서 구성 정보를 갱신할 수 있다.
2.3.4 백엔드 서비스
마이크로서비스는 일반적으로 데이터베이스 API, RESTful 서비스, 다른 서버, 메시징 시스템 등과 네트워크를 통해 통신한다. 이 경우, 애플리케이션 코드의 변경 없이 로컬 및 서드파티와의 연결을 유지하면서 배포 구현체를 교체할 수 있는지 여부를 확인해야 한다.
2.3.5 빌드, 릴리스, 실행
이 모범 사례는 애플리케이션의 배포 단계 (빌드, 릴리스, 실행)가 명확히 분리되어야 한다는 점을 강조한다. 즉, 마이크로서비스는 실행 환경에 독립적으로 구축되어야 하며, 코드가 빌드된 후에는 런타임에서 발생하는 변경 사항이 빌드 프로세스를 거쳐 재배포되어야 한다. 따라서 빌드된 서비스는 이후에는 변경될 수 없어야 한다.
릴리스 단계는 빌드된 서비스와 해당 서비스가 실행될 환경 구성 정보를 결합하는 역할을 한다. 각 단계를 명확히 분리하지 않으면, 코드 변경 사항을 추적하는 데 어려움이 생기거나, 문제가 발생할 수 있다. 예를 들어, 운영 환경에서 이미 배포된 서비스를 변경했다면, 이 변경 사항이 저장소에 기록되지 않아 새 버전에서 변경 사항이 누락되거나, 변경 사항을 새 버전에 다시 복사해야 하는 문제가 발생할 수 있다.
2.3.6 프로세스
마이크로서비스는 항상 무상태 (stateless)이어야 하며, 요청된 트랜잭션을 처리하는 데 필요한 최소한의 정보만을 포함해야 한다. 이러한 특성 덕분에 마이크로서비스는 서비스 인스턴스가 손실되어도 데이터 손실에 대한 걱정 없이 언제든지 중단되거나 교체될 수 있다. 만약 상태를 저장해야 하는 특별한 요구 사항이 있다면, 레디스(Redis)와 같은 메모리 캐시나 백업 데이터베이스를 활용하여 상태를 관리할 수 있다.
2.3.7 포트 바인딩
포트 바인딩은 서비스를 특정 포트에 게시하는 것을 의미한다. 마이크로서비스 아키텍처에서 각 마이크로서비스는 독립적으로 실행되며, 서비스 실행 파일에 필요한 런타임 엔진이 포함되어 있다. 이로 인해 별도의 웹 서버나 애플리케이션 서버 없이 서비스가 실행될 수 있다. 서비스는 명령줄에서 시작되며, 노출된 HTTP 포트를 통해 외부에서 바로 액세스할 수 있어야 한다.
2.3.8 동시성
동시성의 모범 사례는 클라우드 네이티브 애플리케이션이 확장을 위해 프로세스 모델을 사용해야 한다고 설명한다. 이는 중요한 프로세스를 하나 크게 만드는 대신, 여러 개의 프로세스를 생성하여 서비스의 부하를 분산시키거나 애플리케이션을 여러 프로세스에 나누어 처리하는 방식이다. 이렇게 하면 애플리케이션의 확장성과 복원력을 높일 수 있다.
수직 확장(scale up)은 하드웨어 인프라스트럭처, 예를 들어 CPU나 RAM을 늘리는 방식이다. 반면, 수평 확장(scale out)은 애플리케이션 인스턴스를 추가하는 방식이다. 확장이 필요할 경우, 수직 확장보다는 여러 인스턴스를 추가하는 수평 확장을 선택하는 것이 더 효율적이다. 이는 클라우드 환경에서 리소스를 더 유연하게 관리하고, 애플리케이션의 복원력을 높이며, 장애 발생 시 더 쉽게 대처할 수 있게 만든다.
2.3.9 폐기 가능
마이크로서비스는 폐기 가능(disposable)해야 하며, 탄력적으로 확장이 가능해야 한다. 이를 통해 애플리케이션 코드나 구성 변경 사항을 신속하게 배포할 수 있으며, 필요에 따라 서비스 인스턴스를 시작하고 중지할 수 있다. 이상적으로, 마이크로서비스는 시작 명령이 실행된 순간부터 요청을 받을 준비가 완료될 때까지 몇 초 정도의 시간이 소요되도록 설계되어야 한다. 이를 통해 빠르게 확장하고, 필요 없을 때는 즉시 폐기할 수 있어 효율적인 리소스 관리가 가능해진다.
폐기 가능하다는 것은 마이크로서비스 인스턴스를 다른 서비스에 영향을 주지 않으면서 새 인스턴스로 교체하거나 실패한 인스턴스를 제거할 수 있음을 의미한다. 예를 들어, 내부 하드웨어 고장으로 특정 마이크로서비스 인스턴스가 실패하더라도 다른 서비스에 영향을 미치지 않고 해당 인스턴스를 종료하고, 필요에 따라 새로운 인스턴스를 시작하여 서비스 중단 없이 문제를 해결할 수 있다. 이 방식은 시스템의 가용성과 신뢰성을 높이며, 장애에 대한 복원력을 강화한다.
2.3.10 개발 및 운영 환경 일치
이 모범 사례는 가능한 한 유사한 여러 환경(개발, 스테이징, 운영 환경 등)을 유지해야 한다는 원칙을 강조한다. 각 환경에는 인프라와 서비스의 버전이 일관되게 유지되어야 하며, 배포된 코드 또한 동일해야 한다. 이러한 일관성을 확보하는 데 있어 지속적 배포(Continuous Deployment)는 중요한 역할을 한다. 지속적 배포를 통해 배포 프로세스를 자동화하면, 마이크로서비스를 짧은 시간 안에 여러 환경에 배포할 수 있어 효율적이고 일관된 서비스 운영이 가능해진다.
코드가 커밋되면 즉시 테스트를 거쳐 개발 환경에서 운영 환경까지 빠르게 이동해야 한다. 이를 통해 배포 오류를 최소화할 수 있다. 유사한 개발 및 운영 환경을 유지하는 것은 중요하며, 이렇게 함으로써 애플리케이션을 배포하고 실행하는 동안 발생할 수 있는 다양한 시나리오를 예측하고 통제할 수 있다. 이를 통해 애플리케이션의 안정성을 보장하고, 배포 후 발생할 수 있는 문제들을 사전에 예방할 수 있다.
2.3.11 로그
로그는 이벤트 스트림으로, 애플리케이션이나 시스템에서 발생한 중요한 이벤트들을 기록하는 방식이다. 마이크로서비스는 내부 동작 메커니즘에 관여하지 않고, 단순히 표준 출력(stdout)으로 로그를 기록해야 한다. 이를 통해 로그의 관리 및 수집을 외부 도구에 맡길 수 있다. 예를 들어, 로그스태시(Logstash)와 같은 도구를 사용하여 출력된 로그를 수집하고 중앙 저장소에 기록함으로써 로그 데이터를 관리하고 분석할 수 있다. 이런 방식은 마이크로서비스의 독립성을 유지하면서도 로그의 중앙 집중화를 통해 효율적인 모니터링과 추적을 가능하게 한다.
2.3.12 관리 프로레스
개발자는 종종 데이터 변환이나 이전과 같은 관리 작업을 수행해야 한다. 이러한 작업은 임시 방식으로 처리되어서는 안 되며, 소스 코드 저장소에 관리되고 유지되는 스크립트를 통해 수행되어야 한다. 스크립트는 모든 환경에서 재사용 가능하고, 변경되지 않으며, 특정 환경에 맞춰 수정되지 않아야 한다. 마이크로서비스가 실행될 때 고려해야 할 작업 종류를 정의하는 것이 중요하며, 여러 마이크로서비스와 관련된 스크립트가 있을 경우 수동 개입 없이 자동으로 모든 관리 작업을 처리할 수 있다.
2.4 적절한 예제 도입
실습 예제용 설명 생략
2.5 스프링 부트와 자바로 마이크로서비스 만들기
실습 예제 생략
'스프링 마이크로서비스' 카테고리의 다른 글
| 6장. 서비스 디스커버리 (2) | 2024.12.12 |
|---|---|
| 5장. 스프링 클라우드 컨피그 서버로 구성 관리 (0) | 2024.12.12 |
| 4장. 도커 (0) | 2024.12.11 |
| 3장. 스프링 부트로 마이크로서비스 구축하기 (1) | 2024.12.10 |
| 1장. 스프링, 클라우드와 만나다 (4) | 2024.12.09 |
