스프링 클라우드

Spring Cloud는 마이크로서비스 아키텍처를 구축, 배포 및 운영하기 위한 여러 스프링 프레임워크 기반의 도구 및 라이브러리 모음입니다. 이는 분산 시스템 개발에 필요한 공통 패턴을 간편하게 구현할 수 있도록 지원합니다.

다음과 같은 것들이 있습니다.

1. 스프링 클라우드 컨피그
2. 스프링 클라우드 서비스 디스커버리
3. 스프링 클라우드 로드 밸런서와 Resilience4j
4. 스프링 클로우드 API 게이트웨이
5. 스프링 클라우드 스트림
6. 스프링 클라우드 슬루스
7. 스프링 클라우드 시큐리티

특징만 간단히 살펴보고 넘어가겠습니다.

특징

1. 스프링 클라우드 컨피그

• 애플리케이션 구성 데이터를 관리
• 구성 데이터는 배포된 마이크로서비스에서 완전히 분리

2. 스프링 클라우드 서비스 디스커버리

• 서비스를 소비하는 클라이언트에서 서버가 배포된 물리적 위치를 추상화
• 서비스 소비자는 물리적 위치가 아닌 논리적 이름을 사용하여 서버의 비지니스 로직을 호출
• 인스턴스 등록 및 등록 취소 처리

3. 스프링 클라우드 로드 밸런서와 Resilience4j

• 마이크로서비스 클라이언트 회복성 패턴에 사용
• 로드밸런서는 부하 분산 기능도 제공
• Resilience4j는 '회로 차단기', '재시도', '벌크헤드' 등 구현

4. 스프링 클라우드 API 게이트웨이

• 서비스 라우팅 기능 제공
• 서비스 호출의 중앙 집중화
• 보안 인가, 인증, 콘텐츠 필터링과 라우팅 규칙 등 표준 서비스 정책을 시행 가능

5. 스프링 클라우드 스트림

• 경량 메시지 처리 기능 제공
• 비동기 이벤트
• RabbitMQ, Kafka 같은 메시지 브로커

6. 스프링 클라우드 슬루스

• 고유한 추적 식별자를 요청(트랜잭션)에 통합
• 메시지 채널에도 통합 가능
• 상관관계 ID, 트레이스 ID, Tracking ID 등으로 불림
• ELK 스택
  • Elasticsearch: 검색 및 분석 엔진
  • Logstash: 데이터를 소비한 후 "stash"로 전송하기 위해 변환하는 서버 사이드 데이터 프로세싱 파이프라인
  • Kibana: 사용자가 전체 스택의 데이터를 질의하고 시각화할 수 있는 클라이언트 UI

7. 스프링 클라우드 시큐리티

• 인증 및 인가 프레임워크
• 토큰 기반

클라우드 네이티브 마이크로서비스

클라우드 네이티브가 무엇인지 알아보고, 구축 방법에 대해서 알아보기 전에 클라우드 애플리케이션 유형 두가지를 살펴보고 넘어갑시다.

1. 클라우드 레디(cloud-ready) 애플리케이션
2. 클라우드 네이티브(cloud-native) 애플리케이션

둘의 주요 차이점은 클라우드 환경에 대한 적용 수준입니다.
클라우드 레디 애플리케이션은 기존 애플리케이션을 클라우드에서 운영할 수 있도록 적응시키는 반면, 클라우드 네이티브 애플리케이션은 클라우드의 모든 기능을 극대화하여 설계 및 구축됩니다.
클라우드 네이티브 애플리케이션은 클라우드 환경에서 발휘할 수 있는 모든 장점(예: 높은 확장성, 유연한 리소스 관리, 빠른 배포 주기 등)을 완전히 활용하는 것을 목표로 합니다.

클라우드 레디 애플리케이션

클라우드 레디 애플리케이션은 클라우드 환경에서 운영될 수 있도록 설계된 애플리케이션입니다. 이러한 애플리케이션은 클라우드의 일부 기능을 활용하지만, 클라우드 네이티브 애플리케이션만큼 클라우드의 모든 기능과 서비스를 완전히 활용하지는 않습니다.

특징

• 호환성: 기존 온프레미스 애플리케이션을 클라우드로 마이그레이션할 때, 클라우드 레디 애플리케이션은 클라우드 환경에서도 호환되도록 만들어집니다.
• 스케일링: 수동 또는 제한적인 자동 스케일링 기능을 지원합니다.
• 리소스 관리: 클라우드 리소스를 활용하지만, 클라우드 네이티브 애플리케이션만큼의 효율성은 제공하지 않습니다.

클라우드 네이티브 애플리케이션

클라우드 네이티브 애플리케이션은 클라우드 환경에서 최적으로 작동하도록 처음부터 설계되고 구축된 애플리케이션입니다. 이러한 애플리케이션은 클라우드의 모든 장점을 최대한 활용하여, 높은 가용성, 확장성 및 유연성을 제공합니다.

특징

• 마이크로서비스 아키텍처: 각 기능이 작고 독립적인 마이크로서비스로 분리되어 구축됩니다.
• 컨테이너화 및 오케스트레이션: 컨테이너(Docker 등)을 사용하여 애플리케이션을 패키징하고, Kubernetes 같은 오케스트레이션 도구를 통해 관리합니다.
• 데브옵스 및 CI/CD: 지속적 통합 및 배포를 위한 자동화된 파이프라인을 구축합니다.
• 자동 스케일링: 클라우드의 자동 스케일링 기능을 이용하여 트래픽 변화에 따라 자동으로 리소스를 조절합니다.
• 네이티브 서비스 활용: 클라우드 제공자가 제공하는 다양한 서비스(예: 데이터베이스, 메시징 시스템)을 적극적으로 활용합니다.

12팩터 앱

12 팩터 앱은 클라우드 네이티브 마이크로서비스를 만들때 참고할 수 있는 모범 사례 지침입니다.

이 방법론은 분산 서비스를 구축할 때 동적인 확장과 기본 사항에 관한 개발 및 설계 지침의 모음입니다.

🚨 저 같은 경우 이것을 보고 이런 것이 있다라는 정도로만 이해하고 넘어갔습니다. 하지만 최종적으로 저희 프로젝트에서 문제가 되었던 부분이 있는데 그것이 코드 베이스 설계를 잘못했다는 점입니다.

단순히 보고 넘어갈 것이 아닌 설계 단계에서 꼼꼼하게 체크를 해줄 필요가 있습니다. 1번의 코드 베이스쪽에 문제가 발생한 시점에 더이상 수정하기 어려운 환경이 만들어 졌고 만약, 실제 배포를 고려한 프로젝트였다면 치명적인 문제가 되었을 것입니다.

1. 코드 베이스: 각 마이크로서비스는 소스 제어 가능한 단일 코드베이스를 가진다.

2. 의존성: 자바에서는 메이븐이나 그레이들 같은 빌드 도구로 사용하여 의존성 선언(버전 번호 주의)

3. 구성 정보: 소스 코드에 구성 정보를 추가하는 것이 아닌, 구성 정보를 배포할 마이크로서비스와 완전히 분리해서 관리하는 것이 최선입니다.

4. 백엔드 서비스: 애플리케이션 코드의 변경 없이 로컬 및 써드 파티와 연결하는 데 배포 구현체를 교체할 수 있는지 확인해야 합니다.

5. 빌드, 릴리스, 실행: 애플리케이션 배포 단계, 즉 빌드, 릴리스, 실행 단계가 철처히 분리되어야 한다.

6. 프로세스: 마이크로서비스는 항상 무상태가 되어야 하며 요청받은 트랜잭션을 수행하는 데 필요한 정보만 포함해야 합니다.

7. 포트 바인딩: 특정 포트로 서비스를 게시하는 것을 의미합니다.

8. 동시성: 모범 사례는 클라우드 네이티브 애플리케이션이 프로세스 모델을 사용해서 확장해야 한다고 설명한다. 수직 확장(Scale up)대신 더 많은 인스턴스를 시작해서 수평 확장(Scale out)

9. 폐기 가능: 다른 서비스에 영향을 주지 않고 새로운 인스턴스로, 실패한 인스턴스를 제거할 수 있다는 의미입니다.

10. 개발 및 운영 환경 일치: 가능한 유사한 여려 환경(개발, 스테이징, 운영 환경 등)을 갖게 된다는 것을 나타냄. 환경에는 항상 유사한 버전의 인프라 및 서비스뿐 아니라 배포된 코드도 포함되어야 합니다.

11. 로그: 로그는 이벤트 스트림입니다. 출력된 로그를 수집하고 중앙 저장소에 기록하는 로그스태시(Logstash)나 플루언트디(Fluentd)와 같은 도구로 관리해야 합니다.

12. 관리 프로세스: 데이터 이전이나 변환 같은 서비스 관리 작업은 임시변통해서는 안되며 소스 코드 저장소에서 관리 및 유지되는 스크립트로 수행되어야 합니다.