Microservice Architecture (Service)

What is Microservice Architecture - Google Cloud

https://cloud.google.com/learn/what-is-microservices-architecture

https://cloud.google.com/learn/what-is-microservices-architecture

https://microservices.io/patterns/microservices.html

Microservices Pattern: Microservice Architecture pattern

 

 

N - Tier 아키텍처의 대표적인 예시 중의 하나인 Microservices Architrecture 은 현재 클라우드 환경과 컨테이너를 이해하기 위해 아주 중요한 개념이다.

Microservice 가 등장하게 된 배경은 기존의 전통적인 아키텍쳐 스타일인 모놀리식 아키텍처의 단점을 보안하고자 등장하게 되었다. 

 

 

 

 

모놀로식 아키텍쳐는 단일 코드 베이스 와  단일 배포 단위 로 구성된 아키텍처 스타일로

애플리케이션이 필요하는 모든 기능을 하나의 프로젝트 혹은 실행 파일 안에 포함하여 개발하고 베포하는 형태였다.

 

하지만 클라우드 서비스와 컨테이너 기술의 성장으로 기존의 확장성과 빌드 시간(CI/CD 블가능) 등의 문제를 보안하고자

Microservice Architecture 가 등장하게 되었고,

 

이는 작은 서비스 여러 개가 모여서 하나의 시스템을 제공하는 아키텍쳐 시스템이다.

 

Microservice Architecture 의 가장 큰 장점은 각 서비스가 작고 독립적으로 느슨하게 결합되어 있다는 것이다.

그래서 서비스들을 독립적으로 베포할 수 있으며, 전체 프로그램을 빌드한 뒤에도 재배치하지 않고도 기존 서비스에 추가적으로 서비스들을 업데이트 할 수 있다.

이러한 장점은 각각의 서비스 단위로 기능을 분리해서 구축할 수있는 클라우드 환경에서 애플리케이션을 최적화 시키기에 효율적이다.

 

정의: 

마이크로서비스 아키텍처는 애플리케이션이 서비스 모음으로 개발되는 애플리케이션 아키텍처의 한 유형입니다. 또한 마이크로서비스 아키텍처 다이어그램과 서비스를 독립적으로 개발, 배포, 유지관리할 수 있는 프레임워크를 제공합니다.

 

   

 

이는 AWS Well Architecture 의 6 가지 원칙에서도 확인할 수 있다.

https://aws.amazon.com/ko/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc

AWS Well-Architected - 안전하고 효율적인 클라우드 애플리케이션 구축

 

- 운영 우수성 원칙

독립적 베포:

   마이크로서비스는 각 서비스가 독립적으로 베포 운영되기 때문에 특정 서비스의 업데이트나 유지 보수가 편리하다

 

CI / CD 파이프라인: 

   마이크로서비스는 DevOps 및 CI / CD를 쉽게 구현할 수 있도록 설계되어, 자동화된 테스트,  베포,  모니터링이 용이하다.

 

운영 및 디버깅 개선:

   서비스가 독립적으로 로그를 생성하고 모니터링 되기 때문에 문제를 빠르게 식별하고 해결할 수 있다.

 

기존 모놀리식에서는 장애가 발생하면 모든 기능을 점검하고 수정해야했던 단점을 보안한다.

   

- 보안 원칙

최소 권한 원칙:

   각 서비스에 대한 필요한 권한만을 갖도록 구성 할 수 있다. 

 

서비스 간 인증:

   서비스 간 통신에 인증 및 암호화(TLS, OAuth) 를 사용하여 보안을 강화한다

 

격리된 서비스:

   보안 취약점이 발견되어도 서비스가 격리되어 있기 때문에 영향이 제한적이다.

 

모놀리식에서는 한 부분의  보안 취약점이 생기면 전체 어플리케이션으로 확산 도리 수 있었다. 

 

- 안정성 원칙

장애 격리:

   서비스 간의 독립성 덕분에 특성 서비스에서 문제가 발생해도 나머지 서비스는 정상적으로 작동한다

ex) Cricuit Breaker 패턴을 사용한 실패한 서비스와 상호작용 차단

 

수평 확장:

   필요한 서비스만 확장하여 트래픽 증가 시에도 안정성을 유지할 수 있다.

 

베포 실패 최소화:

   Canary 배포나 블루 / 그린 배포 방식을 쉽게 구현하여 안정적인 배포가 가능하다.

 

하나의 오류가 전체 애플리케이션을 중단시키던 기존의 한계점을 보안함  

 

- 성능 효율성 원칙

서비스별 최적화:

   각 서비스가 독립적으로 확장되기 때문에 리소스를 필요한 곳에만 효율적으로 할당 할 수 있다.

ex) CPU 집약적인 서비스와 메모리 집약적인 서비스를 각각 최적화

 

분산 처리:

   병렬 처리와 분산아키텍처를 통해 성능을 극대화한다.

 

 서비스별 기술 선택:

   특정 서비스에 가장 적합한 기술 스택을 선택할 수 있다.

ex) 데이터 집약적 서비스에 NoSQL, 트랜잭션 서비스에 RDBMS 사용

 

모놀리식에서는 모든 기능이 하나의 인스턴스에서 실행되므로  특정 기능의 성능 요구 사항이 전체 시스템에 부담을 줄 수 있다.

    

- 비용 최적화 원칙

서비스별 비용 관리:

    각 서비스 비용을 개별적으로 측정하고 최적화 할 수 있다.

서비리스 서비스를 활용해 사용량 기반 과금 구현  

 

리소스 효울성:

   자주 사용되지 않은 서비스는 작은 인스턴스에서 실행하거나 서버리스로 전환

 

필요한 한만큼만 확장:

   리소스 낭비를 방지

 

 - 지속 가능성 원칙

기술스택의 지속 가능성

   특성 서비스에 적합한 최신 기술을채택하여 적용시킬 수 있다.

 

 작은 단위로 재사용 가능

   기존 마이크로 서비스를 재사용하여 리소스 절약이 가능하다

 

 

 

** 마이크로 서비스의 단점 **

1) 시스템 복잡성 증가

- 서비스 간 통신, 데이터 일관성, 베포 관리 등 복잡성을 크게 증가시킨다.

- 분산 시스템 특성상 네트워크 실패, 서비스 간 의존성 관리 등 추가적인 문제가 발생할 수 있다.

 

ex)

여러  서비스가 API 로 통신하는 데 네트워크 지연이나 장애가 시스템 전반에 영향을 미칠 수 있다.

 

2) 배포 및 운영 부담

- 서비스가 많아질수록 배포와 운영 관리가 복잡하다

- 각 서비스마다 별도의 CI / CD 파이프라인, 모니터링, 로그 관리가 필요하다

 

ex) 

50 개의 마이크로서비스를 운영한다면, 각각의 서비스에 대해 개별적인 배포 전략과 모니터링 대시보드를 설정해야한다.

 

 

3) 데이터 일관성 문제

- 각 서비스가 독립적인 데이터베이스를 가질 경우 일관성을 유지하기 어렵다

 

클라우드 환경에서 NOSQL 데이터도 많이 쓰기 때문에 데이터 일관성 및 동기화 문제로 인한 복잡성 증가

 

 

4) 성능 오버헤드

서비스 간 통신이 HTTP, gRPC 등 네트워크를 통해 이루어지기 때문에 모놀리식 보다 느리며,

네트워크 지연, 데이터 직렬화 / 역직렬화, 프로토콜 오버헤드 등이 추가된다.

 

5) 서비스 간 의존성 관리

서비스가 증가하면 서비스 간 의존성 관리가 어려워짐

특히 API 변경 및 버전 관리가 복잡하다

 

ex) A 서비스가 B 서비스의 특정 버전을 사용 중인데, B 서비스가 업데이트되면 A 서비스도 업데이트가 필요할 수도 있다.

 

위와 같이 의존성 관리 실패 시 전체 시스템이 비효율적으로 동작할 수 있음

 

 

6)  초기 도입 부담

DevOps 및 클라우드 인프라 활용 준비가 안 된 팀은 마이크로서비스로의 전환이 어려울 수 있음

 

7) 보안 문제 증가

서비스 간 통신, 데이터 전송, 인증 및 권한 관리가 많아지면서 보안 위협이 증가합니다.

각 서비스마다 보안 구성을 별도로 적용해야 하므로 관리가 복잡해집니다

 

ex)

각 서비스 간 API 요청에 인증/인가를 추가해야 하며, 데이터 암호화를 적용해야 함

 

8) 디버깅 및 모니터링의 복잡성

ex)

서비스 A에서 시작된 요청이 B와 C로 전달된 후 장애가 발생하면, 문제의 원인을 추적하는 데 시간이 많이 걸릴 수 있음.

 

9) 팀 조직과 협업의 어려움

팀 간 명확한역할 분담이 필수적인데

서비스 간 협업 증가로 인해 커뮤니케이션 문제가 발생 할 수 있다.

 

10) 테스트 복잡성

마이크로서비스는 단위 테스트(Unit Test)뿐만 아니라 서비스 간 통합 테스트(Integration Test)도 중요한데

통합 테스트 및 서비스 간의 테스트가 어려움

 

 

 

ex) 

A, B, C 세 서비스가 서로 통신하는 경우, A 서비스의 업데이트가 다른 서비스에 미치는 영향을 테스트해야 함.