[Spring Microservice] 자세한 정리 - 1

  마이크로서비스 아키텍처에서 각 기능은 독립적인 소프트웨어 컴포넌트로 개발된다. 그리고 각 컴포넌트는 자체 데이터 저장소가 있고 다른 컴포넌트와는 명확한 API를 통하여 통신한다. Java와 스프링 프레임워크로 개발된 컴포넌트는 WAR 파일로 패키징되어 apache tomcat과 같은 웹 컨테이너에 배포된다. 이 글은 이런 마이크로 서비스에 대해서 자세하게 정리한 글이다.

 

 

독립 소프트웨어 컴포넌트의 장점

• 컴포넌트를 개별적으로 배포 및 업그레이드 가능
• API를 통하여 기존 시스템과 통합 가능
• 기능의 일부를 기존의 기능으로 대체 가능
• 다른 컴포넌트와 상관 없이 여러 서버로 scale-out 가능

 

수직 스케일링의 한계

수직 스케일링(vertical scaling)이란?

scale-up과 같은 말. 서버의 성능 개선을 위해 기존의 하드웨어를 더 높은 사양으로 업그레이드하는 것.

💡 수평 스케일링(horizontal scaling)?
scale-out과 같은 말. 서버의 성능 개선을 위해 하드웨어를 추가하는 것.

 

  수직 스케일링은 비용 문제와 장비의 한계로 인해 서버를 확장하는데 한계가 있다. 따라서 이런 수직 스케일링의 한계로 인해, 수평 스케일링을 사용한다. 애플리케이션을 작은 컴포넌트로 나누고 앞단에 로드밸런서를 배치하여 소형 서버에 작은 컴포넌트를 배포하는 방법으로 수평 스케일링을 한다. 클라우드에 배포하는 경우 가상 서버를 필요한 만큼 계속 추가하여 무한대로 확장할 수 있다는 장점도 있다.

 

 

독립 소프트웨어 컴포넌트의 문제

• 새 컴포넌트 인스턴스를 추가할 때 수동으로 로드밸런서를 구성 및 설정
• 통신하는 다른 시스템에서 오류 발생시 플랜폼으로 전이 (chain failure)
• 컴포넌트를 최신 상태로 유지할 때 반복적인 수작업이 자주 발생하여 품질 문제가 발생
• 상태 모니터링이 복잡
• 컴포넌트의 수를 모를 때, 로그 파일 수집 및 컴포넌트 로그 이벤트를 상호 연관시키는 것이 어려움

⇒ 이런 문제점들은 자체적인 개발도구와 수동 처리를 위한 문서화된 지침을 통하여 해결이 가능하다

 

마이크로서비스 정의

두 가지 목표를 달성하기 위하여 일체형 애플리케이션을 작은 컴포넌트로 나누는 것

 

마이크로서비스 아키텍처의 두 가지 목표

• 빠르게 개발해 지속적으로 배포할 수 있어야 한다
• 수동 혹은 자동으로 쉽게 스케일링 할 수 있어야 한다

 

  마이크로서비스는 기본적으로 독자적인 업그레이드와 스케일링이 가능한 독립 소프트웨어 컴포넌트이다. 마이크로서비스는 여러 개의 작은 서버에 배포할 수 있고, 업그레이드나 교체가 쉽다. 이런 이유로 애플리케이션을 쉽게 확장할 수 있고 빠르게 개발할 수 있다는 장점이 있다. 이런 독립적인 컴포넌트로 동작하기 위해서는 다음과 같은 기준을 충족하면 된다.

• 데이터베이스의 데이터를 공유하지 않는, 아무것도 공유하지 않는 아키텍처를 유지
• 명확한 인터페이스를 통해서만 통신
• 도커 컨테이너와 같이 독립된 런타임 프로세스로 실행
• 마이크로서비스 인스턴스는 상태가 없이 요청을 처리

 

마이크로 서비스의 규모

  마이크로서비스는 일체형 애플리케이션을 컴포넌트로 "나누는" 것인데 컴포넌트의 규모는 다음을 고려해서 생각하면 된다.

• 개발자가 다룰 수 있는 크기여야 한다
• 성능이나 데이터 일관성을 해치치 않아야 한다 (다른 마이크로서비스에 저장된 데이터와 SQL 외래키를 맺으면 안 된다)

 

마이크로서비스를 위한 도구와 프레임워크

• Spring Cloud
• Container Engine
• Container Orchestrator
• Service Mesh

 

마이크로서비스의 문제

  마이크로서비는 좋은 점도 있지만, 다른 문제점도 있고 문제점은 다음과 같다.

• chain failure
• 다수의 소형 컴포넌트를 최신 상태로 유지하는 것의 어려움
• 컴포넌트가 많을 시 추적이 어려움
• 컴포넌트의 자원 사용량 분석이 어려움
• 컴포넌트를 수동으로 구성하고 관리하는 것은 비용이 많이 발생하고 오류가 발생하기 쉬움

 

  애플리케이션을 컴포넌트의 그룹으로 나누기 때문에 분산 시스템을 형성하게 된다. 분산 시스템 8가지 오류 (8 fallacies of distributed computing)와 같은 잘못된 가정을 기반으로 마이크로서비스를 구축하게 되면 해당 서비스는 불안정해진다. 따라서 시스템 환경에는 문제가 발생할 수 있다는 것을 인지하고 아키텍처를 설계해야 한다. 문제를 감지하고, 문제가 발생한 컴포넌트는 재시작을 하고, 문제가 발생한 컴포넌트에 클라이언트가 요청을 보내지 않고 다시 요청을 보내도록 설계한다.

 

8 Fallacies of Distributed Computing

1. The network is reliable. (네트워크는 신뢰할 수 하다)
2. Latency is zero. (네트워크 지연은 0이다)
3. Bandwidth is infinite. (대역폭은 무한하다)
4. The network is secure. (네트워크는 안전하다)
5. Topology doesn't change. (토폴로지[링크, 노드 등과 같은 컴퓨터 네트워크의 요소들을 물리적으로 연결해 놓은 것]은 변하지 않는다)
6. There is one administrator. (관리자는 1명이다)
7. Transport cost is zero. (전송 비용은 0이다)
8. The network is homogeneous. (네트워크는 균일하다)