Microservices Architecture (MSA) - 2

Microservices Architecture 를 번역한 내용입니다.
Microservices Architecture (MSA) - 1 에서 이어 설명합니다.

1. Microservices를 가능하게 만드는 기술과 도구

• Microservices는 아키텍처 패턴이다.

• Microservices는 트래픽에 대응하여 공급되고 확장될 수 있는 클러스터 내 컨테이너로 구축된다.

• Container 끼리는 API protocol을 이용하여 통신하며 각 객체로 여겨져 message queue가 message를 버퍼에 저장하여 서비스의 과부하를 막는다.

• 인증가 인가는 분리된 서비스에서 운영되어진다.

1) Containerization

• 기기에서 다른 소프트웨어와 독립되어 패키징된 소프트웨어를 복제가 쉽도록 만든 하나의 형태이다.

• 도커와 쿠버네티스와 같은 도구를 사용하여 쉽게 만들어진다.

• 도커는 당신이 소프트웨어를 운영하기 위해 필요한 요구사항을 정의하는 도구이다.
  • OS, runtime, source code와 같은 것들을 이미지화 한다.
  • Microservices는 Docker container로서 이용되어지며, 부하가 증가하면 자동으로 컨테이너가 복제될 수 있다.

• 쿠버네티스는 container orchestration tool 이다.
  • 얼마나 많은 컨테이너를 제공할 수 있을지, 네트워크에서 어떻게 스케일을 증가시킬 수 있을지에 관해 관리할 수 있다.

  • 쿠버네티스에서 자동으로 스케일을 증가하는 방법에는 3 가지 잘 알려진 방법이 있다.

    • Horizontal Pod Autoscaler (HPA)
    • Vertical Pod Autoscaler (VPA)
    • Cluster Autoscaler

2) Cloud Provider

• Microservices를 스케일 측면에서 재정적 부담을 줄여준다.

• 클라우드 제공자 덕분에, 회사는 따로 데이터 센터를 운영하거나, 인프라스트럭처를 스스로 관리할 필요가 없다.
  
  

3) Authentication Provider (인증 관리자)

• Okta 와 같은 인증 제공자를 사용하여 독립된 microservices에서 인증을 사용할 수 있다.
  
  

4) CI/CD

• Continuous Integration

• Continuous Deployment

• CI/CD는 빠르고 효과적인 방법으로 버그를 고치고 새로운 feature를 더하여 푸쉬할 수 있도록 돕는다.

• Jenkin, Travis CI 그리고 깃헙 등이 있다.
  
  

5) Infrastructure as Code (IoC)

• 그들의 infrastructure (인프라스트럭처) 관련 환경 설정 파일을 YAML 에 저장하여 microservices가 빠르게 돌아갈 수 있도록 돕는다.

• Terraform, Pulumi, Ansible 이 있다.

---

2. Microservices를 실행하는데 사용되는 패턴

1) API Gateways

• 하나의 그물망에서 microservices를 관리하기 위해 사용되는 패턴이다.

• 클라이언트는 공개된 IP를 통해 접근하지만 내부에서는 각자의 기능에 맞는 microservices에 매핑되어 연결되어 사용될 수 있다.

• 응답 캐싱, 재시도, IP 화이트 리스트, 로드 밸런싱 등을 쉽게 해줄 수 있다.

• 대표적인 예로는 Kong, Ambassador, 그리고 Ocelot이 있다.
  
  

2) Access Tokens

• 중심 auth provider를 두고 다른 서비스들이 인증을 제공해주는 특징을 가진다.

• 기관에서 microservices를 운영할 때 사용하는 방법이다.
  
  

3) Log Aggregation

• 다른 microservices로 부터 로그를 모아서 단일 로그 파일을 만들기 위해 사용한다.

• LogDNA, Apache Kafka 가 이 목적을 위해 사용된다.

• Log aggregation 이 필요한 이유는 microservice가 일반적 사용 후 삭제 컨테이너에 배포되기 때문에 서비스가 다시 시작하면 이전 로그를 읽을 수 없는, 즉 로그 손실이 되기 때문에 집계가 필요하다.

• 쿠버네티스나 ContainlQ를 사용한다면 이를 쉽게 관리할 수 있다.
  
  

4) Health Check APIs

• Health-check API란 microservice와 그것의 의존관계의 상태를 체크하는 API endpoint를 의미한다.

• 종속된 downstream을 예로 들자면, e-commerce application에서 주문과 배송 서비스를 이용한다고 가정하자.
  • 이 때, health-check란 주문과 동시에 배송 서비스의 상태를 확인하는 것이다.
  • 배송 서비스는 주문 서비스에 의존한다.

• 서비스의 데이터베이스 연결 상태를 확인하여 평균 응답 시간 내에 응답 가능하도록 체크할 수 있다.

• 평균 메모리 사용량을 측정하여 메모리 누수가 발생하지 않는지를 확인할 수 있다. 쿠버네티스와 같은 Orchestration tool은 health-check API로 부터 얻은 정보를 사용하여 서비스를 확장해야할지의 여부를 결정한다.

---

3. Microservices를 실행하는데 추천되지 않는 Pattern

1) 분산된 Monolithics를 만드는 것

• 한 서버에서 모든 것을 관장하는 Monolithic을 중복하여 서버를 여러대 만드는 것은 병목 현상을 해결하는 방법이 아니다.

• 공유된 데이터베이스를 사용하는 것

• 스키마 환경설정을 어느 서버에서나 동일하게 사용하는 것
  * 각 서버마다 다른 환경설정을 가질 수 있기 때문에 독립성이 보장되어야 한다.
  
  

2) 서버 사이 Spiky Loads

• 너무 많은 서비스가 메시지를 주고 받으면 microservice database에 부하를 줄 수 있다.

• 이를 방지하기 위해 API 게이트에이는 request buffer를 두어 queue에 메시지가 저장되어 처리될 수 있도록 한다.
  
  

3) IP와 Port를 하드코딩하는 것

• 서버가 늘다보면 랜덤으로 IP와 port를 받게하는 것이 하드코딩하여 IP와 Port를 배정하는 것보다 관리의 측면에서 우수할 수 있다.