Microservices Architecture (MSA) - 2

jungedlin·2022년 10월 24일
0

Tech Talk

목록 보기
7/9
post-thumbnail

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가 빠르게 돌아갈 수 있도록 돕는다.


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


1) API Gateways

  • 하나의 그물망에서 microservices를 관리하기 위해 사용되는 패턴이다.
  • 클라이언트는 공개된 IP를 통해 접근하지만 내부에서는 각자의 기능에 맞는 microservices에 매핑되어 연결되어 사용될 수 있다.
  • 응답 캐싱, 재시도, IP 화이트 리스트, 로드 밸런싱 등을 쉽게 해줄 수 있다.

2) Access Tokens

  • 중심 auth provider를 두고 다른 서비스들이 인증을 제공해주는 특징을 가진다.
  • 기관에서 microservices를 운영할 때 사용하는 방법이다.

3) Log Aggregation

  • 다른 microservices로 부터 로그를 모아서 단일 로그 파일을 만들기 위해 사용한다.
  • 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를 배정하는 것보다 관리의 측면에서 우수할 수 있다.
profile
담대하게 도전하고 기꺼이 실패를 받아들이는 개발자

0개의 댓글