웹서비스 재기동 최소화 설계방안

https://medium.com/cloud-native-daily/spring-cloud-config-externalizing-the-configurations-from-your-microservice-284e319f7056

 

ㅁ 서비스 반영 시, 재기동의 최소화를 고려한 MSA 아키텍처 기술스택

마이크로서비스 아키텍처(MSA)에서 재기동을 최소화하면서 유연하고 효율적으로 서비스를 운영하기 위해, Spring Boot, Spring Cloud와 같은 기술 스택을 사용하는 방법이 일반적입니다.

아래는 MSA를 위한 Spring 기반 아키텍처의 핵심 구성 요소입니다:

 

• Spring Boot
  • 독립적인 마이크로서비스 구축: 각 마이크로서비스는 Spring Boot를 사용하여 독립적으로 구축됩니다. 이는 각 서비스가 자체 내장 서버(Tomcat, Jetty 등)와 함께 독립적으로 실행될 수 있음을 의미합니다.
• Spring Cloud Config
  • 중앙화된 구성 관리: Spring Cloud Config를 사용하여 모든 마이크로서비스의 구성을 중앙에서 관리합니다. 이를 통해 서비스 재기동 없이 실시간으로 구성을 변경하고 적용할 수 있습니다.
• 버전 관리
  • 구성 파일은 Git과 같은 버전 관리 시스템에 저장하여 관리할 수 있습니다.
• Spring Cloud Netflix Eureka
  • 서비스 등록 및 발견: 마이크로서비스는 Eureka 서버에 자신을 등록하고, 다른 서비스를 찾기 위해 Eureka를 사용합니다. 이는 서비스 간의 연결을 간소화하고 유연하게 관리합니다.
• Spring Cloud Gateway 또는 Netflix Zuul
  • API 게이트웨이: 외부 요청을 적절한 마이크로서비스로 라우팅하는 중앙 집중식 API 게이트웨이 역할을 합니다.
• 로드 밸런싱과 보안
  • 요청의 로드 밸런싱, 인증 및 권한 부여를 처리합니다.
• Spring Cloud Bus
  • 메시지 브로커 연결: 메시지 브로커(RabbitMQ, Kafka 등)와 연결하여, 구성 변경과 같은 이벤트를 서비스 간에 효율적으로 전파합니다.
• Spring Session
  • 세션 정보의 중앙 관리: 세션 정보를 중앙에서 관리하고, 여러 인스턴스 간에 세션을 공유합니다. 이를 위해 Redis와 같은 외부 세션 저장소를 사용할 수 있습니다.

이러한 아키텍처는 각 마이크로서비스가 독립적으로 개발, 배포, 운영될 수 있도록 지원하면서, 동시에 전체 시스템의 일관성과 통합성을 유지합니다. 구성 변경, 새로운 기능 추가, 버그 수정 등이 필요할 때, 관련된 마이크로서비스만을 업데이트하면 되므로 전체 시스템의 재기동을 최소화할 수 있습니다.

---

ㅁ 서비스를 재기동하지 않고 변경사항을 적용하는 방법

- Java, JS, JSP, XML 기반의 웹서비스 운영 기준 

• Hot Swapping / Hot Deployment:
  • JVM 레벨: 일부 Java Virtual Machine(JVM)은 클래스 레벨에서 코드 변경을 허용하는 핫 스왑 기능을 지원합니다. 이를 통해 개발 중인 애플리케이션의 일부 코드를 변경하고, 서버 재시작 없이 즉시 반영할 수 있습니다.
  • 서버 레벨: Tomcat, JBoss와 같은 일부 애플리케이션 서버는 JSP 파일이나 특정 자원 파일들의 변경을 감지하고 자동으로 리로드하는 기능을 지원합니다.
• Spring Boot의 DevTools:
  • Spring Boot 프로젝트에서는 Spring Boot DevTools를 사용하여 코드 변경 시 자동으로 서버를 재시작합니다. 이는 전체 서버 재시작이 아니라, 빠른 재시작으로 개발 효율성을 높일 수 있습니다.
• 외부 설정 파일 사용:
  • XML 및 기타 구성 파일을 외부에서 관리하고, 애플리케이션에서 이 파일들을 동적으로 읽어들이도록 합니다. 이를 통해 설정 변경 시 애플리케이션을 재시작하지 않고도 변경사항을 적용할 수 있습니다.
• Feature Toggles / Feature Flags:
  • 코드 내에 조건부 로직을 구현하여, 특정 기능을 켜고 끌 수 있는 플래그(Feature Toggles)를 사용합니다. 이 방식을 사용하면 새로운 기능을 배포 후에도 활성화 여부를 제어할 수 있습니다.
• Load Balancer 사용:
  • 로드 밸런서를 사용하여 트래픽을 여러 인스턴스에 분산시킵니다. 변경사항을 적용할 때 한 인스턴스씩 순차적으로 업데이트하고 재시작하여, 전체 서비스에 영향을 주지 않고 업데이트를 진행할 수 있습니다.
• Containerization (Docker/Kubernetes):
  • 컨테이너화를 통해 애플리케이션을 독립된 환경에서 실행합니다. 변경사항이 있을 때 새로운 컨테이너 이미지를 생성하고, 롤링 업데이트를 통해 서비스를 재시작 없이 업데이트할 수 있습니다.

---

ㅁ 비즈니스 로직과 설정/데이터 파일의  분리 

XML 파일을 외부에서 관리하는 것은 설정이나 데이터를 애플리케이션 코드와 분리하여 유연하게 관리하고자 할 때 유용합니다.

이를 통해 서비스 재시작 없이 설정 변경이 가능해집니다. 구체적인 방법은 다음과 같습니다:

• 외부 저장소 설정:
  • XML 파일을 서버의 파일 시스템, 데이터베이스, 또는 클라우드 기반 스토리지(예: AWS S3, Google Cloud Storage) 등 외부 저장소에 저장합니다.
  • 저장소의 위치는 보안을 고려하여 적절하게 선택합니다.
• 접근 방법 정의:
  • 애플리케이션에서 XML 파일에 접근하기 위한 로직을 구현합니다. 예를 들어, 파일 시스템에 저장된 경우, Java의 File I/O를 사용하거나, 웹 서버를 통해 접근할 수 있습니다.
  • 클라우드 저장소를 사용하는 경우 해당 서비스의 API를 활용하여 XML 파일을 읽고 쓰는 로직을 구현합니다.
• 동적 로딩 메커니즘 구현:
  • 애플리케이션에서 XML 파일의 변경을 감지하고, 자동으로 다시 로드할 수 있는 메커니즘을 구현합니다. 이를 위해 파일 시스템의 이벤트를 감지하거나, 정기적으로 XML 파일을 확인하는 스케줄러를 사용할 수 있습니다.
• 캐싱 및 성능 최적화:
  • 외부 저장소에서 파일을 읽는 작업은 비용이 발생할 수 있으므로, 캐싱 메커니즘을 구현하여 성능을 최적화합니다.
  • XML 파일의 내용이 변경되지 않았을 경우, 캐시된 데이터를 사용하여 불필요한 I/O 작업을 줄일 수 있습니다.
• 보안 고려사항:
  • 외부 저장소에 저장된 XML 파일에 접근할 때 보안을 고려해야 합니다. 적절한 인증 및 권한 관리를 통해 무단 접근을 방지합니다.
  • 민감한 데이터를 포함하는 경우, 암호화를 고려합니다.
• 환경별 설정 관리:
  • 개발, 테스트, 프로덕션 등 다양한 환경에 맞게 XML 파일을 관리할 수 있습니다. 환경별로 다른 설정 파일을 사용하거나, 파일 내부에서 환경별로 다른 설정을 구분하여 사용합니다.

이러한 방법을 통해, XML 파일의 변경이 필요할 때 애플리케이션을 재시작하지 않고도 설정을 업데이트할 수 있으며, 운영 환경의 유연성과 효율성을 향상시킬 수 있습니다.