Spring Cloud로 개발하는 마이크로서비스 애플리케이션_Microservice와 Spring Cloud의 소개_1

 

 

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)

소프트웨어 아키텍처

Software Architecture 발전 과정

• 1960 ~ 1980년대 - 메인 프레임
  • 하드웨어 중심. 하드웨어의 사양이나 성격에 맞춰서 서비스 구축
  • 하드웨어가 고가였기 때문에 서비스의 기능을 수정하기 어려웠음
  • Fragile : 깨지기 쉬운 시스템
• 1990 ~ 2000년대 - 분산
  • Robust, Distributed. 시스템이 안정화 됨
  • 분산 덕분에 서비스의 변화가 발생하더라도 안전성있고 성능이 높은 서비스를 유지 가능
• 2010 ~ 현재 
  • Resilient(탄력적), Cloud Native
  • 시스템은 로컬 → 클라우드로 이전
  • 확장성과 안전성이 더욱 강화.
  • 지속적인 개선 및 변경 사항이 생겨도 시스템을 탄력적으로 운영할 수 있도록 구축
  • Anti-Fragile
    • Fragile의 반대
    • Anti-Fragile로 인해 DevOps, Cloud Native 생겨남
    • 타 시스템이나 환경보다는 시스템 변화가 적고 변화에 바로 적응할 수 있고, 비용도 저렴
• Anti-Fragile 특징
  • Auto scaling
    • 시스템을 구성하고 있는 인스턴스들을 하나의 그룹(Auto Scaling group)으로 묶은 다음 그룹에서 유지되어야 하는 최소 인스턴스를 지정할 수 있고 사용량의 따라 자동으로 인스턴스를 증가시킴
    • ex) 사용자가 많이 유입되는 특정 이벤트 때 서버의 개수를 늘리거나 하는 등 → 사람이 수동적으로 하는게 아니고 자동적으로 수행
  • Microservices
    • Cloud Native Architecture, Cloud Native Application의 핵심
    • 기존 시스템들이 하나의 거대한 형태를 이루어져 서비스 되었다고하면, 마이크로 서비스는 전체 서비스를 구축하고 있는 개별적인 모듈이나 기능을 독립적으로 개발, 배포, 운영할 수 있는 서비스이다.
  • Chaos engineering
    • 시스템이 급격하고 예측하지 못한 상황에서라도 견딜 수 있고 신뢰성을 쌓기 위해 소프트웨어 시스템의 실행 방법이나 규칙
    • 예견된 불확실성이나 예견되지 않은 불확실성에도 안전하게 서비스를 제공할 수 있도록 구축되어야 한다는 의미
  • Continuous deployments
    • CI/CD : 지속적인 통합, 지속적인 배포란 의미

 

 

Cloud Native Architecture

• 확장 가능한 아키텍처
  • 시스템의 수평적 확장에 유연함
  • 확장된 서버로 인한 시스템의 부하 분산, 가용성을 보장함
  • 시스템 또는, 서비스 어플리케이션 단위의 패키지(컨테이너 기반 패키지)
  • 모니터링
• 탄력적 아키텍처
  • 서비스 생성 - 통합 - 배포를 CI/CD를 통해 비즈니스 환경 변화에 대응 시간을 단축시킴
  • 분할된 서비스 구조
  • 무상태 통신 프로토콜
  • 서비스의 추가와 삭제를 자동으로 감지
  • 변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리)
• 장애 격리(Fault isolation)
  • 특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않음

 

 

Cloud Native Application

• Cloud Native Architecture에 의해 설계되고 구현되는 어플리케이션을 Cloud Native Application이라고 함
• Cloud Native Application 특징
  • 마이크로서비스로 개발됨
  • CI/CD를 통해 자동으로 통합, 빌드, 테스트, 배포 과정을 거침
  • 마이크로 서비스에 에러가 발생하면 그 즉시 수정해서 다시 배포하는 과정을 무한 반복하는 특징을 데브 옵스라고 함
  • 컨테이너 가상화 기술 사용
• CI/CD
  • 지속적인 통합(CI, Continuous Integration)
    • 통합 서버, 서버 소스 관리(SCM), 빌드 도구, 테스트 도구
    • ex) Jenkins, Tream CI, Travis()d
  • 지속적인 배포
    • Continous Delievry
      • Comtinuous Deployment
  • 카라니 배포와 블루그린 배포
    • 95%의 사용자는 기존 서비스를 이용하고 5% 정도의 사람들만 새로운 서비스를 사용하게 한다던가
    • 이전 버전의 사용자 트래픽을 이전 버전과 비슷한 새 버전으로 이전시키는 것도 선택할 수 있음.
•  DevOps
  • 개발 조직과 운영 조직의 통합을 의미
  • 이러한 통합으로 고객의 요구사항을 빨리 반영하는 것을 목적로 둠
• Container 가상화
  • Cloud Native Architecture의 핵심
  • 로컬 환경에서 운영했던 시스템을 클라우드 환경으로 이전해서 적은 비용, 탄력성 있는 시스템을 구축

 

 

12 Factors

• Cloud Native Application을 구축함에 있어 고려해야 할 12가지 항목

• Codebase
  • 자체 Repository에 저장된 각 마이크로서비스에 대한 단일 코드 베이스
  • 버전을 제어하기 위한 목적
  • 형상 관리를 위해 코드를 한 곳에서 배포하는게 목적
  • 다양한 환경에서 배포하기 위해 코드의 통일적인 관리가 필요하기 위해 가장 중요한 항목으로 꼽힘
• Dependencies
  
  • 마이크로서비스는 자체 종속성을 가지고 패키지 되어 있어 전체 시스템에 영향을 주지 않는 상태에서 변경 및 수정이 되어야한다는 의미
• Config
  • 하드 코딩된 설정 정보가 아니라 시스템 코드 외부에서 구성 관리 도구를 통해 마이크로서비스에 필요한 작업들을 제어
• Backing services
  • 백엔드와 관련된 서비스. 데이터베이스, 메시지 큐잉 시스템, SMTP 서비스, 캐시 시스템 등을 이용해서 마이크로 서비스가 가져야할 기능들을 추가적으로 지원하는 걸 의미함
• Build, release, run
  • 빌드, 릴리즈, 실행 환경을 각각 분리하는 것을 의미한다.
  • 롤백 기능을 지원해야 함
  • CI/CD를 이용해 자동화 시스템을 구축하는게 좋음
• Processes
  • 각각의 마이크로서비스 실행 중인 다른 서비스와 분리된 채 자체 프로세스에서 운영될 수 있어야 함
• Port binding
  • 각각의 마이크로 서비스는 자체 포트에서 외부로부터 요청 및 응답이 가능하다. 그래야지 다른 서비스와 상호작용할 수 있기 때문이다.
• Concurrency
  • 마이크로 서비스는 많은 수의 서비스를 복사해서 확장해나가게 된다.
  • 동일한 서비스가 여러 인스턴스에 나뉘어 서비스 되고있기 때문에 동시성을 가지고 있어야 함
• Disposabilty
  • 서비스의 인스턴스 자체는 삭제 가능해야한다. 
  • 확장성을 높여야하고 정상적으로 종료가 될 수 있는 상태여야한다.
• Dev/Prod parity
  • 개발 단계와 Production 단계가 분리되어 있어야 함
• Logs
  • 마이크로 서비스에 의해서 생성된 로그들은 이벤트 스트림으로 처리해야 함
• Admin Processes
  • 마이크로 서비스들의 상태 및 리소스 현황을 관리할 수 있는 도구가 필요함

 

+3

다른 회사에서 12 Factors에 3가지를 더 얹었다.

• API first
  • 모든 마이크로 서비스는 API 형태로 제공되어야 함
• Telemetry
  • 모든 지표는 수치화해서 관리할 수 있어야 함
• Authentication and authorization
  • API를 사용함에 있어서 적절한 인증 작업이 필요함

 

 

 

---

- 출처 : 인프런 Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) 강의