[Spring Cloud로 개발하는 마이크로서비스 애플리케이션] 1. Microservice 소개

Microservice 소개

0. Software Architecture

Antifragile

• Auto scaling
  • 리소스 사용량이나 조건에 따라 인스턴스나 리소스를 자동으로 확장/축소할 수 있는 개념

• Microservices
  • 전체 서비스를 구축하고 있는 개별적인 모듈이나 기능을 독립적으로 개발하고 배포하고 운영할 수 있도록 세분화된 서비스

• Chaos engineering
  • 변동, 예견된 불확실성, 예견되지 않는 불확실성, 카오스 불확실성에서도 안정적인 서비스를 유지

• Continuous deployments
  • 지속적인 통합과 지속적인 배포환경 구성

 

---

 

1. Cloud Native Architecture

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

 

---

 

2. Cloud Native Application

Cloud Native Architecture 에 의해 설계되고 구현되는 Application

CI/CD

• 지속적인 통합, CI(Continuous Integration)
  • 통합 서버, 소스 관리(scm), 빌드 도구, 테스트 도구
  • ex) Jenkins, Team CI, Travis CI
• 지속적 배포
  • Continuous Delivery
  • Continuous Deployment
  • Pipe line

• 카나리 배포와 블루그린 배포

DevOps

자주 테스트하고, 피드백받고, 업데이트하는 과정을 거쳐 전체 개발일정이 완료될때 까지 지속적으로 끊임없이 진행해 가는 것

Cloud Native Application은 데브옵스 환경에 맞춰서 서비스의 구조를 작은 단위로 분할할 수 있게 함으로써 통합, 테스트, 배포를 자주할 수 있는 구조가 될 수 있다

Container 가상화

공통적인 라이브러리나 리소스를 공유해서 사용하므로
각자 필요한 부분에 대해서만 독립적인 영역에 실행할 수 있는 구조
하드웨어 가상화보다 더 적은 리소스를 사용한다
컨테이너 가상화 위에서 작동되는 서비스들은 가볍고 빠르게 운영할 수 있다

 

---

 

3. 12Factors(https://12factor.net)

Heroku 에서 제시한 12가지 항목
Cloud Native Application 을 개발하거나 서비스를 운영할때 고려해야되는 항목을 정리
Cloud 서비스 시에 발생했던 문제점과 개선점, 시행착오들을 바탕으로 가이드라인을 만듬

• 1. 코드 통합
  • 형상 관리를 위해 코드를 한 곳에서 배포하는 것이 주 목적
• 2. 종속성 배제
  • 각 Micro Service는 자체 종속성을 가지고 패키징 되어있음 전체 시스템에 영향을 주지않는 형태에서 변경 되어야 함
• 3. 환경설정의 외부 관리
  • 코드의 외부에서 관리 도구를 통해 Micro Service에 필요한 작업들을 구성할 수 있어야함
• 4. 백업 서비스의 분리
  • 응용프로그램 자체에서 필요한 백업 서비스를 분리하게 됨으로서 서로 상호가능한 서비스 자체를 종속성 없는 상태에서 작업 가능
• 5. 개발 환경과 테스트 운영 환경의 분리
  • 빌드,릴리즈,실행환경을 분리
  • 개발 서버에서 만들어진 코드 배포 하기위해 실행단계 까지 옮기는 환경을 엄격하게 관리
• 6. 상태관리
  • 프로세스 각각의 Micro Service들은 실행되는 서비스와 분리된 채, 프로세스에서 운영가능해야 함(독립성과 일치)
• 7. 포트 바인딩
  • 다른 Micro Service와 격리를 위해 각각의 Micro Service는 자체 포트에서 노출되는 인터페이스 및 자체에 포함되는 기능이 있어야 함
• 8. 동시성
  • 하나의 서비스가 여러가지 인스턴스에 동일한 형태로 복사되면서 운영됨으로서 부하 분산이 가능
• 9. 서비스의 올바른 상태 유지
  • 서비스의 인스턴스 자체가 삭제가 가능 하며 확장성을 높이고 정상적으로 종료 될 수 있는 환경이 되어야 함
• 10. 개발과 production단계 구분
  • 환경자체를 최대한 다른 쪽에 있는 작업과 중복되지 않고 종속되지 않는 상태로서 서비스를 유지할 수 있어야
• 11. Log의 분리
  • Log를 출력시키는 Logic은 기존에 있었던 Application Logic과 분리 되어서 Application 자체가 실행되지 않는 상태라 해도 Logging만은 정상적으로 작동해야 함
• 12. 관리 프로세스
  • 현재 운영되고 있는 모든 Micro Service들이 어떤 상태이며 어떤 리소스로 구성되어있는지 파악하기 위해 관리 도구가 필요
  • 이러한 작업에는 리포팅할 수 있는 기술이 포함되어 있어야 하고 데이터 정리 및 데이터를 분석하는 기능이 포함될 수 있음

Pivotal 추가 항목

• API first
  • 가지고 있는 모든 서비스들은 API 형태로 제공되어아 햔다
  • API를 구축함에 있어서 사용자 측에서 어떠한 형태로 쓸것인가 먼저 고민해서 개발해야된다
• Telemetry
  • 모든 지표는 수치화, 시각화되서 관리 되어야 한다
• Authentication and authorization
  • API를 사용함에 있어서 인증작업은 필수

 

---

 

4. Monolithic vs Microservice

Monolith Architecture

Application을 개발함에 있어 모든 요소들을 하나의 거대한 Software안에서 전부 포함시켜 개발하는 방법

따라서 Application을 구성하는 서비스들 간 의존성을 가짐
이는 즉, 시스템 일부만 수정을 하여도 전체 시스템을 다시 패키징 하고 빌드-테스트-배포 해야하는 과정을 거쳐야함

Microservices Architecture

Application을 구성하는 구성 요소 및 Service를 분리하여 운영하는 방식

유지보수 및 변경사항이 적용이 쉬워짐
변경이 필요할 때 필요한 부분만 변경하게 되고 다른 Service에 영향을 끼치지 않고 독립적으로 Service 가능
따라서 Application 자체가 down되는 현상을 없앨 수 있음

심지어 각각의 Service들은 최소화된 중앙집중된 관리만 필요하고 서로 다른 언어 및 서로 다른 Database를 사용가능 하기 까지도 함
각각의 Sevice들은 제공해야하는 Service를 restAPI를 통해서 제공 가능 및 다른 Micro Service들과 통신 가능

Trend

최근에는 Application 개발 시 Smart Device를 고려해야 함
이제는 Web Browser 뿐 아니라 스마트 워치,스마트 폰,태블릿,노트북과 같은 Device들도 고려 해야 함 -> 사용자가 요청하는 형태로 응답이 가능 해야 한다는 뜻
이를 위해, RestAPI를 사용

Monolith vs Front & Back vs Microservice Architecture

• Monolithic

• Microservice

 

---

 

5. Microservice Architecture란?

AMAZON에서 시작된 MSA ( 제프 베조스, 아마존의 CEO )

• 모든 팀들은 데이터와 기능들을 서비스 인터페이스로 연결해라
  팀들은 인터페이스로만 연락해야한다
• 다른 어떤 커뮤니케이션 방법도 안된다
  직접링크를 보내거나 다른 팀의 스토리지에 직접 엑세스 하는건 안된다
  공유메모리, 백도어도 안된다
• 어떤 기술을 쓰든 상관없다 HTTP, Cobra, Pubsub, 독자 프로토콜... 그건 상관없다
• 모든 서비스 엔터페이스는 예외없이 외부에서 이용가능하게 만들어져야 한다
  외부 개발자들이 인터페이스를 이용할 수 있게 해야한다
  ( MSA의 가장 본질적인 부분... )

2006년 아마존 웹 서비스(AWS) 릴리즈 - 내부에서 사용한 것과 똑같은 플랫폼

넷플리스조차 AWS를..

• 2008년 데이터 베이스에 문제 발생 ( DVD를 고객에게 보낼 수 없음 )
• scale-up 확장만 가능한 인프라 스트럭쳐와 단일 장애지점 (SPOF)이라는 한계에서 벗어나길 선언
• 그 시작은 아파치 카산드라 데이터베이스
  2009년 AWS로 이관 시작
• 확장성(Scalability), 성능(Performance), 가용성(Availability) 세가지 목표에 집중
  '자체 보유 인프라와 솔루션으로는 이렇게 급증한 트래픽을 감당할 수 있는 확장성을 확보할 수 없었을 것'

Microservice 특징

1. challenges

• 개발 방식 및 패러다임을 상당히 바꾸어야 함
  2. small Well chosen Deployable Units
• 독립적으로 개발 가능한 형태의 작은 서비스
  3. Bounded Context
• 각각의 서비스들은 어플리케이션을 구성하고 있는 전체 도메인의 지식에 따라 서비스 경계를 잘 구분 해야 경계로 인해 하나의 서비스가 여러개, 여러개가 단일화 될 수 있음
  4. Restful
• 상태에 대해서 restapi로 통신 json포맷 이용 서버의 리소스 및 상태 표시에 최적화
  5. Configuration management
• 마이크로 서비스들이 갖고 있는 설정 및 환경 정보는 코드 내에 갖고 있지 않고 외부에 시스템을 통해 관리
  6. cloud enabled
• 클라우드 네이티브 기술을 최대한 활용
  7. dynamic scale up and down
  8. CI/CD
  9. visibility
• 마이크로서비스 기술들은 시각화 할 수 있는 관리도구 들을 가지고 있어야 함

But! 무조건 Micro Service Application만 만들어야 할까요?!

처한 환경 및 기존 Application에서 MSA로 전환 혹은 Application개발 시,생기는 이익에 대하여 생각을 해야 합니다

1. Multiple Rates of Change(다양한 변화율)

• 변화로 인해 생기는 이익이 어느 정도 이상이 되어야 Micro Service Application으로 전환을 할 것인지 봐야함
  2. Independent Life Cycles(독립 라이프 사이클)
• Application을 구성하고 있는 각각의 서비스들이 독립적으로 개발되고 운영될 수 있도록 서비스 경계가 잘 만들어져 있는가?
  3. Independent Scalability(독립적인 확장성)
• 유지 보수 및 확장성에 대처가 가능한지 확인
  4. Isolated Failure(격리된 오류)
• 오류를 격리시킬 수 있는지 오류가 독립적인지
  5. Simplify Interactions with External Dependencies(외부 종속성과 상호 작용을 단순화)
• 서비스간의 종속성을 최소화하고 응집력을 높일 수 있도록 서비스 경계가 잘 구분되어 있는 가를 고려
  6. Polyglot Technology(다국어 기술)
• 여러가지 프로그래밍 언어,스토리지 기술을 지원 할 수 있는지 확인

마이크로서비스 팀 구성

• 서비스는 소규모 팀이 (two pizza : 6–10명) 개발하고 테스트 할 수 있을 만큼 작아야 함
• 각 팀은 자율적이어야 하고 다른 팀과 최소한의 협업을 통해 서비스를 개발하고 배포하여야 함
  OOD(Object Oriented Design), SRP(Single Resposibility Priciple), CCP(Common Closure Principle)
• 새롭고 변경된 요구 사항이 단일 서비스에만 영향을 미치도록 분해함
• 각 서비스는 구현을 캡슐화하는 API로 느슨하게 결합되어야 한다
  클라이언트에 영향을 주지 않고 구현을 변경해야 함
• 각 서비스는 테스트 가능해야 함

 

---

 

6. MSA 표준 구성요소

2018년 가트너 시장조사 기관에서 발표한 내용

넷플릭스, 아마존, 트위터, 나이키등에서 채택한 아키텍처로서 소개되면서 주목을 받음
지금까지도 널리 다른 서비스들에서 참조되고 있는 아키텍처

Service Mesh Capabilities

Service Mesh: 마이크로서비스 아키텍처를 적용한 시스템 내부 통신

서비스간의 통신을 추상화하고 안전하고 빠르고 신뢰성있게 만들어주는 인프라스트럭쳐의 레이어

복잡한 내부 네트워크를 제어하고 추적하고 내부 네트워크에 관련된 로직을 추가함으로써
안정성, 신뢰성, 탄력성, 표준성, 가시성, 보안성등을 확보할 수 있게 됨

URI 버전, 호스트헤더, API 버전, 기타 응용 프로그램의 규칙을 기반으로하는 네트워크 레이어

서비스메시의 구체적인 경량화 Proxy를 통해서 다양한 라우팅 기능이나 서킷브레이커와 같은 공통기능을 설정할 수 있다

서비스간의 통신에 연관된 기능뿐만 아니라 서비스 배포 전략에도 도움을 줄 수가 있다

아래와 같은 서비스들을 통해서 안정적이고 효율적으로 마이크로서비스의 개발과 운영을 지원하고 있다

• Configuration(설정정보)
• Routing(라우팅)
• Instrumentation(수단)
• AuthN/AuthZ(인증관련정보)
• Discovery(서비스검색)
• Load Balancing(로드밸런싱)
• Resiliency(탄력성)
• Encryption(암호화)

CNCF(Cloud Native Computing Foundation)

https://landscape.cncf.io

Cloud Native 를 구축함에 있어서 상호연관될 수 있는 서비스들이 어떤 것들이 있는지 표시하고 있음

MSA 기반 기술