[MSA] Microservice와 Spring Cloud 소개

[소프트웨어 아키텍처]

• 2010년대 이후부터 IT 시스템은 Antifragile 혹은 클라우드 네이티브 아키텍처 형태로 발전됨.

ANTIFRAGILE

• 다른 개발 시스템이나 환경보단 시스템 변화가 적어 변화에 바로 적응할 수 있다.

Antifragile의 특징

• Auto scaling (자동 확장성)
  • Auto scaling이란 CPU, 메모리, 네트워크, 데이터베이스의 사용량이나 조건에 따라서 자동으로 처리할 수 있는 개념
  • 시스템을 구성하는 인스턴스를 하나의 Auto scaling 그룹으로 묶은 다음, 그룹에서 유지돼야 하는 최소 인스턴스를 지정 가능
  • 사용량에 따라 자동으로 인스턴스 증가 가능
  • ex) 온라인 쇼핑몰과 같이 특수한 이벤트가 있는 달에는 서버의 운영 갯수를 늘리고, 비수기와 같을 때는 서버의 운영 갯수를 다시 줄이는 작업에 비유할 수 있다.

• Microservcies
  • 기존 시스템들이 하나의 거대한 형태로 구축되어서 서비스 되었다. 반면, 마이크로 서비스는 전체 서비스를 구축하고 있는 개별적인 모듈이나 기능을 독립적으로 개발, 배포, 운영할 수 있도록 세분화된 서비스 → 작게 분리된 독립적인 서비스
  • 마이크로 서비스는 클라우드 네이티브 아키텍처, 클라우드 네이티브 애플리케이션의 핵심
• Chaos engineering
  • Chaos engineering이란 시스템이 급격하고 예측하지 못한 상황이라도 견딜 수 있고, 신뢰성을 쌓기 위해 운영 중인 소프트웨어 시스템에 실험하는 방법이나 규칙
  • 시스템의 어떤 변동이나 예견되지 않은 불확실성에 대해서도 안정적인 서비스를 제공할 수 있도록 구축되어야 한다.
• continuous deployments
  • CI / CD등의 배포 파이프라인으로 시스템의 통합적인 관리와 운영을 위해 사용
  • 마이크로 서비스처럼 하나의 애플리케이션을 구성하는 수백개의 서비스들을 일일이 빌드, 테스트, 서버에 배포하는 데에 있어서 자동화된 시스템을 구축하고 하나의 작업에서 다른 작업으로 연계되는 과정을 파이프라인으로 연결

 

---

[Cloud Native Architecture]

Q. 기존의 로컬 환경이나 사내에서 구축하고 운영했던 시스템을 클라우드 환경으로 전환하기 위해 어떤 아키텍처를 가져야 할까 ?

Cloud Native Architecture의 특징

• 확장 가능한 아키텍처
  • 시스템의 수평적 확장에 유연 → 더 많은 사용자의 요청을 처리할 수 있게 됨.
  • 확장된 서버로 시스템의 부하 분산, 가용성 보장
  • 시스템 또는, 서비스 애플리케이션 단위의 패키지 (컨테이너 기반 패키지)
  • 모니터링
• 탄력적 아키텍처
  • 서비스 생성-통합-배포, 비즈니스 환경 변화에 대응 시간 단축
    • 애플리케이션을 구성하는 각 기능을 하나의 분리된 서비스로 개발하고 분리되어 개발된 서비스들을 통합하고 배포하기까지 걸리는 시간을 CI/CD를 통해 처리함으로써 시스템 환경에 적용되는 시간을 단축
  • 분할된 서비스 구조
  • 무상태 통신 프로토콜
  • 서비스의 추가와 삭제 자동으로 감지
    • 다른 서비스들이나 외부에 연결돼있는 타 시스템에서도 해당 서비스를 검색하고 사용할 수 있게 하기 위함
    • 마이크로 서비스들의 존재는 Discovery Service라는 곳에 등록되고 삭제되는 작업
  • 변경된 서비스 요청에 따라 사용자 요청 처리 (동적 처리)
• 장애 격리 (Fault isolation)
  • 특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않음.
    • 여러 개로 분리되어 개발되고 있는 마이크로 서비스들은 하나의 독립적인 작은 단위의 애플리케이션과 같음.
    • 하나의 마이크로 서비스에 생기는 문제점이나 오류사항은 다른 쪽 서비스로의 영향을 최소화할 수 있음.
    • 특정 서비스만 배포할 수 있기 때문에 다른 시스템에 영향을 주지 않을 수 O

+) 시스템 확장을 의미하는 스케일링은 scale-up, scale-out으로 나눌 수 있음. scale-up : 하드웨어의 사양을 높이는 작업으로, 우리가 가지는 시스템의 CPU나 메모리의 스펙을 높이는 작업 scale-out : 같은 사양의 서버 즉, 인스턴스를 여러 개 배치함으로써 동시에 더 많은 사용자의 요청을 처리할 수 있도록 하는 것

• 클라우드 네이티브 아키텍처에서는 클라우드 서비스를 제공하는 업체로부터 가상의 서버, 가상의 스토리지, 가상의 네트워크 등을 빌려서 사용함으로써 비용을 최소화시켰고 양쪽으로 증가되었던 시스템을 더 이상 사용하지 않을 경우에는 빌렸던 리소스를 반납해서 비용을 낮출 수 있게 되었다.
• 클라우드 네이티브에서는 가상 서버의 기술이 핵심적으로 필요 → 기존의 서버 가상화 방식과 더불어 컨테이너 방식의 가상화를 같이 사용

---

[Cloud Native Application]

개념

• 클라우드 네이티브 아키텍처에 의해 설계되고 구현되는 애플리케이션

특징

• 마이크로 서비스로 개발됨.
• 마이크로 서비스들은 CI/CD 시스템에 의해 자동으로 통합되고, 빌드, 테스트, 배포하는 과정을 거치게 됨.
• 마이크로 서비스에 문제가 발생했을 경우 바로바로 수정해서 다시 배포하는 과정을 반복할 수 있는 특징을 가지게 됨. 이러한 특징을 DevOps라고 하는데, DevOps에서는 처음에 시스템이 기획이 되고, 구현되고, 테스트되고, 배포되는 과정을 시스템이 종료될 때까지 무한 반복해줌으로써 고객이 원하는 최선의 결과물을 만드는데 목적을 두고 있음.
• 하나의 애플리케이션을 구성하는 마이크로 서비스들을 클라우드 환경에 배포하고 사용하기 위해 컨테이너 가상화 기술 사용

---

Cloud Native Application - CI / CD

• 지속적인 통합, CI
  • 지속적인 통합이란 하나의 애플리케이션을 여러 팀이나 여러 개발자를 위해서 함께 개발하고 있는 경우에 결과물을 통합하기 위한 형상관리 혹은 통합된 코드를 빌드하고 테스트하는 과정 자체
  • Git과 같은 형상관리 시스템과 연동해서 사용
  • CI 시스템의 파이프라인을 잘 연동하게 되면 개발자가 어떤 코드를 작성한 후 Git과 같은 형상관리 시스템에 해당 코드를 업로드, commit함과 동시에 빌드, 테스트, 실행을 해서 다른 쪽의 코드와 문제가 발생하는지 여부를 바로 확인 가능
  • 통합 서버, 소스 관리 (SCM), 빌드 도구, 테스트 도구
  • ex) Jenkins, Team CI, Travis CI
• 지속적 배포
  • Git과 같은 소스 저장소에 업로드 된 코드를 가져와서 패키지화 된 코드의 결과물을 실행환경에 어떻게 배포하는지에 따라 달라짐.
    • Continuous Delivery (지속적 전달) 패키지화되어 있는 결과물을 실행 환경에 수작업으로 배포하는 과정이 필요하면 Continuous Delivery
    • Continuous Deployment (지속적 배포) 운영자라든지 어떤 관리자의 개입 없이 실행 환경까지 완벽하게 자동화되어 있는 배포를 사용한다면 Continuous Deployment
    • pipe line
• 카나리 배포와 블루그린 배포
  • 전체 사용자의 95%는 이전 버전의 서비스를 계속 사용하도록 하고 5%의 사용자만이 새로운 버전의 서비스를 사용하게 하는 것
  • 사용자 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전시키는 방법 등을 선택 가능
  • 가장 중요한 것은 시스템의 정상적인 운영, 그 다음으로는 다운타임을 최소화하는 것 → 변경된 시스템을 무조건 새로 반영하기보다는 기존 시스템과 같이 운영해줌으로써 사용자에게 발생할 수 있는 이질감, 문제점들을 최소화하는 것이 필요

---

Cloud Native Application - DevOps

DevOps

• Development + 운영을 뜻하는 Operation
• 즉, 개발 조직과 운영 조직의 통합을 의미
• 이러한 통합으로 고객의 요구사항을 빠르게 반영하고 만족도 높은 결과물을 제시하는 것에 목적을 두고 있음.
• 고객의 요구사항이 바로 반영하고 필요할때마다 바로 수정할 수 있는 구조가 좋다.
• 따라서, 자주 테스트하고 자주 피드백을 받고 자주 업데이트하는 과정을 거쳐 전체 개발 일정이 완료될 때까지 지속적으로 끊임없이 진행해 가는 것을 DevOps
• 클라우드 네이티브 애플리케이션은 DevOps 환경에 맞춰 서비스의 구조를 작은 단위로 분할할 수 있게 함으로써 더 자주 통합, 테스트, 배포할 수 있는 구조가 될 수 있다.

---

Cloud Native Application - Container 가상화

1. 전통적인 방식의 개발 시스템

• 하드웨어 시스템 위에 운영체제를 설치하고, 애플리케이션을 운영

   2. 가상화를 통한 개발 시스템

• 운영체제 위에 Hypervisor 기술을 통한 가상 머신을 기동
• 가상머신은 시스템이(Host System)가지고 있는 물리적인 하드웨어를 쪼개서 사용하는 개념으로서 하나의 가상 머신은 독립적인 운영체제를 가지고 실행될 수 O 즉, 각각의 가상 머신에 애플리케이션을 운영할 수 O But, 가상 머신에서 작동되는 애플리케이션은 호스트 운영체제에 많은 부하를 주게 되고, 시스템 확장에 한계

   3. 컨테이너 가상화 기술

• 기존의 하드웨어 가상화 또는 서버 가상화에 비해 적은 리소스를 사용하여 가상화 서비스 구축 가능
• 운영체제 위에 컨테이너 가상화를 기동하기 위한 소프트웨어 서비스를 작동
• 컨테이너 가상화에서는 공통적인 라이브러리나 리소스 같은 것들을 공유해서 사용
• 각자 필요한 부분에 대해서만 독립적인 영역에 실행할 수 있는 구조
• 즉, 기존의 하드웨어 가상화 기술보다는 더 적은 리소스 사용하게 될 수 O, 컨테이너 가상화 위에서 작동되는 서비스들은 가볍고 빠르게 운영될 수 O

---

[12 Factors]

개념

• 클라우드 서비스 중 PaaS(Platform as a Service)를 제공하는 Heroku라는 개발 회사에서 제시한 12가지 항목으로서 클라우드 네이티브 애플리케이션을 개발하거나 서비스를 운영할 때 고려해야 될 항목
• 코드 통합, 종속성의 배제, 환경 설정의 외부 관리, 백업 서비스의 분리, 개발 환경과 테스트 운영 환경의 분리, 상태 관리, 포트 바인딩 동시성, 서비스의 올바른 상태 유지와 개발과 운영 환경의 통일, 그리고 로그의 분리, 관리 프로세스에 대해 소개

1. 코드 베이스

• 자체 레포지토리에 저장된 각 마이크로 서비스에 대한 단일 코드 베이스를 의미
• 버전을 제어하기 위한 목적
• 형상관리를 위해 코드를 한곳에서 배포하는게 주요 목적
• 이후에 배포하기 위해 개발환경, 스테이징, 프로덕션에 배포하기 위해 코드의 통일적인 관리가 필요하기 때문에 가장 중요한 항목으로 꼽힘.

2. 종속성

• 각 마이크로 서비스는 자체 종속성을 가지고 패키지되어 있어서 전체 시스템에 영향을 주지 않은 상태에서 변경되고 내용을 수정할 수 있어야 한다는 뜻

3. 구성 정보

• 시스템 코드 외부에서 구성 관리 도구를 통해 마이크로 서비스에 필요한 작업들을 제어함으로써, 동일한 배포가 올바른 구성에 적용된 환경에서 전파될 수 있게 함

4. 서비스 지원

• DB, 캐시, 메시징 서비스, 브로커 등을 이용하여 마이크로 서비스가 가져야 할 특정 기능들을 추가로 지원
• 응용 프로그램 자체에서 필요한 백킹 시스템 리소스를 분리하게 됨으로써 서로 상호 가능한 서비스 자체를 코드 종속성을 갖지 않은 상태에서 작업할 수 있게 됨

5. 빌드, 릴리즈와 실행 환경을 각각 분리

• 각각은 고유한 아이디로 태그를 가지고 있어야 되고, 이전 상태로 돌아가는 롤백 기능을 지원해야 함.
• CI/CD 시스템을 완벽하게 이용해서 자동화된 시스템을 구축하는게 좋음

6. 프로세스

• 각각의 마이크로 서비스는 실행 중인 다른 서비스와 분리된 채 자체 프로세스에서 운영될 수 있어야 함 (독립성)
• 필요한 자원이 있다면 캐시 등의 데이터 저장소와 같은 형태를 이용해서 외부와 데이터 동기화

7. 포트 바인딩

• 각각의 마이크로 서비스는 자체 포트에서 노출되는 인터페이스링 기능과 함께 자체에 포함되어 있는 기능이 있어야 함
  • 다른 마이크로 서비스와의 격리가 가능하게 되기 때문

8. 동시성

• 하나의 서비스가 여러가지 인스턴스에 동일한 형태로 복사돼서 운영됨으로써 부하 분산을 이뤄냄 → 동일한 서비스가 여러 pc, 즉 여러 인스턴스에 나눠서 서비스 되고 있기 때문에 동시성을 가지고 있어야 함

9. Disposability

• 서비스 인스턴스 자체가 삭제가 가능해야 함
• 확장성 기회를 높여야 하고 정상적으로 종료할 수 있는 상태가 되어야 함’

10. 개발 단계와 프로덕션 단계 구분

• 운영 프로그램의 수명 주기 전반에 걸쳐 최대한 서비스를 직접 액세스하는 기능을 방지
• 환경 자체를 최대한 다른쪽의 작업과 중복되지 않고 종속되지 않은 상태로서 서비스를 유지해야 함

11. 로깅 시스템

• 마이크로 서비스에 의해 생성된 로그를 이벤트 스트림으로 처리해야 함
• 로그 또는 이벤트 집계를 사용하기 위해 별도의 추가적인 서비스 혹은 모니터링 도구를 사용할 수 있음

12. 관리 프로세스

• 현재 운영되는 모든 마이크로 서비스들이 어떠한 상태로 사용되고 있으며 리소드들이 어떻게 현재 사용되고 있는지 등을 파악하기 위해 적절한 관리 도구 필요
• 리포팅, 데이터 정리 및 분석하는 기능 포함

---

[Monolithic VS MSA]

• 애플리케이션을 개발하는 방법에는 여러 방법론, 프로세서 존재하는데, 그 중에서도 시스템을 구축하고 운영하는 방식 중에서 Monolithic 방식과 마이크로 방식에 대해 알아보자.

Monolithic 방식 개념

• 애플리케이션을 개발함에 있어서 필요한 모든 요소를 하나의 커다란 소프트웨어 안에 전부 포함시켜 개발하는 방법
• DB 관련 로직, 비즈니스 로직뿐만 아닐차 화면을 처리해주는 프론트엔드 기술 등의 모든 서비스의 내용들이 하나의 애플리케이션에서 유기적으로 연결되어 작동하고 있고, 배포되기 위해 서로 의존성을 가진 채 패키징되고 운영 서버에 배포됨

MSA 방색 개념

• 애플리케이션을 구성하는 각각의 구성 요소 및 서비스의 내용을 분리해서 개발하고 운영하는 방식 (각각의 용도에 맞는 컨테이너를 모아서 사용하는 서비스 개념)
• 하나의 큰 덩어리에서 개발되어지는 Monolithic 방식에 비해 유지보수나 변경사항을 적용하는데 훨씬 유리
• 비즈니스 로직에 해당하는 어떠한 서비스의 프로세스가 변경되어 새로 개발, 배포돼야 한다고 가정했을 때, 분리된 서비스가 다른 서비스에 영향을 주지 않거나 최소화하면서 독립적으로 배포가 가능하게 됨 → 애플리케이션 전체가 다운타임 되는 현상 방지

Monolithic과 MSA 방식의 가장 큰 차이

• 하나의 서비스를 구성하고 있는 크기 즉, 서비스의 크기가 도메인의 특징을 고려해서 경계를 구분해야 하고, 구분된 서비스들은 독립적인 언어와 독립적인 DB를 사용 가능
  • 각각의 서비스별로 특색에 맞게 최적화 되어 있는 언어와 DB 사용을 권장

Monolithic 방식

• 모든 업무 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스
• 애플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태

 

• 일반적으로 애플리케이션에서 사용하는 DB 자체도 하나의 저장소에서 집중 되어서 저장
• 세가지 서비스가 있는 애플리케이션이라고 가정 시에 해당 애플리케이션에서 하나의 공통적인 DB를 쓰고 있는 형식

Monolithic 방식 - 단점

• 하나의 시스템에 애플리케이션을 구성하고 있는 모든 서비스와 요소들을 패키징 되어서 서비스 되어야 하기 때문에 시스템의 일부만 수정한다 하더라도 전체 애플케이션을 다시 빌드, 테스트, 패키징 해야 한다는 단점

MSA

MSA 방식이란 ?

• HTTP 통신을 이용해서 리소스 API에 통신할 수 있는 작은 규모의 여러 서비스들의 묶음이 모여서 하나의 애플리케이션을 구성
• 이러한 서비스들은 비즈니스 기능을 중심으로 구축돼야 함 완전하게 자동화 된 배포 시스템 사용해야 함 (CI/CD)
• 각각의 서비스들은 최소한의 중앙 집중식 관리가 돼야 함
• 각각의 서비스들은 서로 다른 프로그래밍 언어와 서로 다른 데이터 저장 기술을 사용할 수 O
  • 서비스의 종류와 기능에 맞춰 개발 언어를 선택하고, 각각의 서비스들은 자신이 제공해야 하는 서비스나 데이터를 API를 통해 제어할 수 O

→ 마이크로 서비스는 애플리케이션을 구성하는 다양한 서비스의 경계를 잘 분리하고 각각의 서비스의 상황과 기능에 맞춰 개발언어를 선택하고 각각의 서비스들은 Restful API와 같은 메커니즘을 통해 서로의 데이터를 제공해서 사용할 수 있도록 개발하게 됨.

---

Front & Back

• 모놀리식 방식과 마이크로 서비스 방식의 중간 정도의 개발 방식으로서 프론트엔드와 백엔드를 분리해서 개발하는 방식도 자주 사용됨.
• 하나의 애플리케이션의 모든 로직과 서비스가 포함되는 모놀리식 방식보다는 사용자에게 화면을 보여주고 어떤 액션을 처리받도록 하기 위한 프론트엔드 부분과 백엔드 또는 서버 사이드를 분리해서 개발하는 방식
• 이렇듯, 서버와 클라이언트를 분리해서 개발하게 되면 각각 최적화 되어있는 개발 환경을 독립적으로 유지하는게 가능하게 됨.

MSA

• 백엔드 안에서도 백엔드의 각 서비스로 서로 의미 있는 경계로 구분하고 O
  • 각각의 서비스가 독립적으로 구분되고, 비즈니스 로직과 DB 관련 로직을 개발하고 있음
• DB 부분도 하나의 통일된 DB를 사용하는 방식이 아니라 독립적인 서비스에 맞게 분리되고 사용되고 있음

 

정리

모놀리식

• 화면을 나타내는 UI, 웹 서비스, 비즈니스 로직, DB 로직을 하나의 구성요소로 보고 있음. 시스템의 DB를 포함해서 같이 구성

마이크로 서비스

• 다양한 형태의 스마트 디바이스도 고려해야 함 즉, 사용자의 요청 정보를 처리하는 서버 사이드 기술도 그에 맞게 다양한 형태로 서비스 필요
• 서버 사이드에서 개발해야 하는 각각의 기능들도 각 서비스의 경계에 맞는 형태로 개발, 테스트, 배포됨으로써 서로 다른 서비스들과 독립적으로 관리할 수 O
• 마이크로 서비스들을 관리하기 위한 기술도 같이 발전 필요
  • 서비스 요청에 대한 통일된 게이트웨이, 각각의 서비스들의 등록과 검색, 서비스들의 부하 분산, 서비스에 문제가 생겼을 때 대처가히 위한 방법, 분리된 서비스들의 데이터를 동기화하기 위한 메커니즘

---

[Microservice Architecture란?]

Microservice의 특징

1. Challenges
   • 마이크로 서비스 아키텍처는 기존의 개발 방식, 패러다임을 상당수 바꿔야하기 때문에 도전
2. Small Well Chosen Deployable Units
   • 독립적으로 배포 가능한 형태의 작은 서비스로 이루어져 있음
3. Bounded Context
   • 각각의 서비스들은 애플리케이션을 구성하고 있는 전체 도메인의 지식에 따라 서비스의 경계를 잘 구분해야 함.
4. RESTful
   • 각각의 서비스들은 상태에 대해 REST API 방식으로 통신하는 것 권장
5. Configuration Management
   • 마이크로 서비스들이 가지는 어떠한 환경에 대한 정보나 설정에 대한 정보는 외부에 있는 시스템을 통해 관리 (환경 설정 정보는 외부에서 관리하는 것 권장)
6. Cloud Enabled
7. Dynamic Scale Up and Scale Down
   • 서비스를 제공하는 인스턴스들은 부하 분산 처리나 스케일 업, 스케일 다운 등을 동적으로 처리할 수 있도록 구성될 수 있어야 함.
8. CI / CD
9. Visibility
   • 마이크로 서비스를 시각화해서 관리할 수 있어야 함

Q. 모든 것이 마이크로 서비스여야 할까 ? → X

• 다음의 항목들을 고려해서 결정해야함

1. Multiple Rates of Change (다중 변화율)
   • 어느정도 변화가 생길 것인가, 어느정도 공수를 고려하고 받아드릴수 있을것인가
2. Independent Life Cycles (독립 라이프 사이클)
   • 어플리케이션을 구성하고 있는 각각의 서비스들이 독립적으로 개발되고 운영될 수 있도록 서비스 경계가 잘 만들어져 있는가
3. Independent Scalability (독립적인 확장성)
   • 각각의 서비스를 운영함에 있어서 서비스 유지보수 및 확장이 가능한가
4. Isolated Failure (격리된 오류)
   • 오류사항이 독립적인가
   • 즉, 마이크로 서비스에 부분적이 오류가 발생되었다 하더라도 해당 서비스만 영향 받도록 설계가 되었는지
   • 혹은 다른 마이크로 서비스들은 오류에 최소한의 영향을 받으면서 해당 서비스를 우회할 수 있는 대체 서비스가 준비 될 수 있는지를 고려
5. Simplify Interactions with External Dependencies (외부 종속성과의 상호 작용 단순화)
   • 시스템이나 서비스 간의 종속성을 최소화하고 응집력을 높일수 있도록 서비스 경계가 잘 구분되어 있는지
6. Polyglot Technology (다국어 기술)
   • 각각의 서비스들이 제공해야 하는 기능에 맞는 프로그램의 언어와 데이터베이스 운영 환경을 자유롭게 선택할 수 있고 지정할 수 있는가

• 마이크로 서비스들은 마이크로 서비스를 구성하는 서비스의 경계, 업무의 범위, 용도와 사용 시나리오 등에 따라서 하나의 비즈니스 로직이 하나의 서비스일 수도 O / 더 작은 서비스일 수도 O
• 하나의 서비스와 다른 분리된 서비스를 조합해서 새로운 영역의 서비스를 생성할 수도 O

---

[SOA vs MSA]

서비스의 공유 지향점

• SOA (Service Oriented Architecture) - 재사용을 통한 비용 절감
• MSA (Microservice Architecture) - 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응
  • 만약 회원가입이라는 마이크로 서비스에서 저장된 회원 목록 데이터가 결제라는 마이크로 서비스에서 사용되기 위해서는 두개의 서비스가 연결되거나, 결제 서비스에서 직접 회원가입 서비스의 DB에 접속해서 데이터를 사용하는 방식이 아닌 API를 통해서 데이터를 요청하고 사용해야 함

→ 둘 다 서비스를 지향한다는 점에서는 공통적

 

기술 방식에서의 차이점

• SOA - 공통의 서비스를 ESB에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
  • 공통으로 사용할 수 있는 서비스들을 서비스 버스라는 개념을 통해 한 대 모아서 비즈니스에 필요로 하는 하나의 서비스 형태로 만듦 → 모여진 서비스를 제공하는 방식
  • WSDL이나 ESB 등을 통해 서비스 간의 통신
• MSA - 각 독립된 서비스가 노출된 REST API를 사용
  • 각각의 독립된 비즈니스 서비스들이나 리소스는 데이터는 REST API를 이용해야 다른 서비스나 외부 시스템에서 사용 가능

RESTful Web Service

• Level 0 : 가장 간단한 웹 서비스 상태
• Level 1 : 리소스를 URI로 적절하게 표현한 상태
• Level 2 : HTTP 메소드가 같이 연동되는 상태
  • 우리가 제공하려는 리소스를 적절하게 용도와 상태에 따라 HTTP가 가지고 있는 메소드에 맞게 설계하고 서비스 하는 단계
  • HTTP 메소드를 이용해서 리소스의 상태를 구분하여 서비스함으로써 비슷한 이름의 URI라 하더라도 HTTP 메소드에 따라 다른 형태의 서비스를 제공할 수 있게 됨
• Level 3 : REST API에서 하나의 리소스를 사용함에 있어서 그 리소스가 추가적으로 다른 작업을 어떻게 넘어갈 수 있는지 나타낸 상태
  • Level 2 + HATEOAS

RESTful API를 이용하여 API 설계를 할 때 고려사항

1. API를 사용하는 소비자 입장에서 간단명료하고 직관적인 API 설계 필요
2. HTTP의 메소드와 request, response type, 헤더값 등과 같은 HTTP 장점을 최대한 살려서 개발 필요
3. Level2 방식 최대한 살려서 개발 필요 → 기존에 가진 리소스의 URI + 적절한 HTTP 메소드 연동 필요
4. 각각의 API 요청에 따라 적절한 HTTP 상태 코드 전달 필요
5. 제공하려는 데이터에 대해 복수 형태의 URI 값을 사용하여 제공
6. 모든 리소스는 가능하면 명사 형태로 표시하는게 좋음
7. 일관된 엔드포인트 사용
   • 일관적인 엔드포인트란 진입점을 단일화 시켜주는 엔드 포함 이러한 작업을 수행하기 위해 API Gateway 사용하여 처리 가능

SOA와 MSA의 가장 큰 차이

• 서비스 공유를 어디까지 하느냐
• 개발하는 방식에 있어 REST 방식을 주로 사용하는지 / 기존에 만들었던 웹 서비스라는 방식 (SOAP 등의 프로토콜) 사용하는지

 

SOA

• 각각의 서비스들은 ESB 곳에 모여진 후 외부에 공개됨
• 서비스 간의 통신은 DB 처리 로직, SOAP, HTTP, JMS, JDBC 같은 기술을 같이 사용할 수 O

MSA

• 서로 분리된 서비스들은 독립적으로 개발 프로세스를 가지고 O (독립적인 UI, 비즈니스 로직 ..)
• 각각의 서비스들은 자신의 데이터를 외부에 공개할 때 REST API를 통해 공개하는 것을 권장
• 이벤트 스트림 방식과 같은 메시징 서비스(예. KAFKA)를 이용하여 서로 간에 필요한 데이터를 동기화할 수 O
  • ex) Redis의 DB에서 어떠한 자료가 변경이 되면 이것을 카프카로 전달 카프카에서는 해당 데이터에 관심 있다고 등록했던 객체들(서브스크라이버)에게 지금 전달된 데이터를 배달 진행 Order, Shopping Cart 서비스는 변경된 사용자의 정보 요청사항의 데이터를 받은 후, 그 데이터 값을 자신이 가지는 각각의 DB에 업데이트 → 마이크로 서비스 안에 저장된 데이터들이 각각 분리된 DB에 저장돼있지만, KAFKA 등의 메시징 서비스를 통해 데이터 동기화 가능
• 서비스 간의 통신 자체가 REST API 방식, 카프카와 같은 메시징 시스템을 이용하여 처리하는 방식

---

[Microservcie Architecture Structures]

MSA 표준 구성요소

• 마이크로서비스는 독립적으로 배포되고 확장될 수 있는 서비스들을 조합해서 하나의 거대한 애플리케이션을 구성하는 아키텍처 패턴
• 마이크로 서비스를 지원하고 관리하기 위해 일반적으로 서비스 디스커버리, API Gateway, 오케스트레이션, context boundary 등의 서비스들을 연결해서 사용하게 됨

[그림 설명]

• 클라이언트, 마이크로 서비스들이 API Gateway라는 진입점을 통해 필요한 서비스의 요청을 함
• API Gateway로 수집된 클라이언트들의 요청은 서비스 라우터한테 어디로 가야 할지 질의 → 마이크로 서비스가 어디에 저장되어 있는지 서비스 디스커버리의 등록 서비스에 물어보게 됨
• 서비스가 분산된 형태로 구성돼있기 때문에 로드 밸런서에 의해 어떠한 서비스로 보내줄 것인지 결정 서비스 라우터 + 로드 밸런서를 하나의 시스템으로 묶어서 사용하는 경우도 O
• 마이크로 서비스 안에서 사용하고 있는 환경 설정 정보는 Config Store 서비스를 통해 외부 시스템에 저장시켜 사용하는게 일반적
• 마이크로 서비스는 컨테이너 가상화 기술을 통해 구성
• 백킹 시스템 : 마이크로 서비스에 저장되어있는 다양한 스토리지들을 모아서 사용할 수 있는 방법
• MOM : 메시징 처리 시스템을 통해 하나의 서비스와 다른 서비스가 같이 연결될 수 O
• 텔레메트리 기능 : 마이크로 서비스의 모니터링 기능, 진단 기능

남색 서비스가 마이크로 서비스 (여러개의 인스턴스들로 나뉘어져있음)

 

• CNCF (Cloud Native Computing Foundation)
  • 클라우드 관련된 기술들을 각각 잘 조합하게 되면 서비스 개발~운영, 배포, 모니터링하고 모든 것들을 조화롭게 쓸 수 있다는 일종의 가이드

Service Mesh Capabilities

• MSA 인프라 -> 미들웨어
  • 프록시 역할, 인증, 권한 부여, 암호화, 서비스 검색, 요청 라우팅, 로드 밸런싱
  • 자가 치유 복구 서비스
• 서비스간의 통신과 관련된 기능을 자동화

 

• 서비스 매시란 마이크로 서비스 아키텍처를 적용한 시스템의 내부 통신을 의미 즉, 서비스 매시를 통해 서비스 간의 통신을 추상화하고 안전하고 빠르고 신뢰성 있게 만들어주는 인프라 구조의 계층
• 추상화를 통해 복잡한 내부 네트워크 제어, 추적, 내부 네트워크에 관련된 로직을 추가함으로써 안전성, 신뢰성, 탄력성, 표준성, 가시성, 보안성 등을 확보할 수 O
• 서비스 매시는 URI 경로, 호스트 헤더, API 버전 또는 기타 응용 프로그램의 수준을 어떠한 응용 프로그램의 규칙을 기반으로 하는 네트워크 계층
• 서비스 매시의 구체적인 경량화 프록시를 통해 다양한 라우팅 기능 등의 공통 기능 설정 가능
• 서비스 매시는 설정 정보, 라우팅, 인증에 관련된 정보, 로드 밸런싱과 관련된 기능, 탄력성, 서비스에 대한 검색, 암호화 등을 통해 마이크로 서비스의 개발과 응용 지원

MSA 기반 기술

• Gateway
• Service Mesh
• Runtime(운영환경 관련된 기술)
• Framework
• Backing Service
• Automation
  • 개발이 완료된 마이크로 서비스를 위해 지속적인 통합과 배포를 위한 자동 기술이 필수
• Telemetry
  • 하나의 애플리케이션은 작게는 수십 개에서 수백 개에 이르는 마이크로 서비스로 구성됨 다수의 마이크로 서비스의 현재 상태를 모니터링 하기 위해 적절한 관리 도구가 필요
  • 시각화된 관리 도구를 통해 마이크로 서비스의 현재 상태에 대해 모니터링

---

[Spring Cloud란?]

• 2017년까지의 새로운 엔터프라이즈 Java 애플리케이션의 70% 이상은 기존의 앱 서버에서 작동, 배포되지 않을 것이다.
• 즉, 단일 앱 서버(모놀리식 방식)가 아닌 클라우드 상태로서 분리될 수 있는 마이크로 서비스 형태로 개발될 것이라고 예측
• 스프링 클라우드는 독립적으로 개발하기 위한 마이크로 서비스 아키텍처를 지원하기 위한 프레임워크

 

• 스프링 클라우드를 이용하면 환경 설정 관리, 서비스 검색, 회복성 처리, 라우팅, 프록시 등의 서비스를 사용함에 있어서 필요한 분산 시스템이 빠르게 애플리케이션을 개발하는데에 목적을 두고 스프링 클라우드가 만들어졌다.

• 스프링 클라우드를 사용하기 위해서는 스프링 부트가 필수
• 스프링 부트 + 스프링 클라우드가 연동해서 개발

스프링 클라우드 사용시 어떠한 내용을 구성해야 하는지

• Centralized configuration management, 중앙 집중식 구성 관리 : 환경 설정 관리를 위해 필요
  • Spring Cloud Config Server

[그림 설명]

다양한 마이크로 서비스에서 사용할 수 있는 정보를 config 서버를 통해 외부의 저장소에 환경 설정 정보를 넣을 수 O

Gateway IP, 서버가 가지고 있어야 할 토큰에 대한 기본 정보 등을 한 곳의 저장소에 모아놓고, 나머지 마이크로 서비스에서 해당 데이터 값을 참조해서 사용하는 방법

• Location transparency, 위치 투명성
  • Naming Server (Eureka) : 서비스 등록과 위치정보 확인, 검색 등 서비스를 위해 넷플릭스의 유레카 서버를 사용할 예정
• Load Distribution (Load Balancing), 부하 분산(부하 분산) : 서버에 들어왔던 요청 정보를 분산하기 위한 용도로서 로드 밸런싱 기능 / 게이트웨이 기능으로서 리본이나 스프링 클라우드 게이트웨이 사용할 예정
  • Ribbon (Client Side)
  • Spring Cloud Gateway (사용 권장)

 

[그림 설명]

외부의 클라이언트 정보나 서비스 정보가 게이트웨이(Ribbon)을 통과해서 가지고 있는 다른 마이크로 서비스로 진입점을 옮겨가는 것을 볼 수 O

마이크로 서비스뿐만 아니라 게이트웨이 서비스도 Naming Server에 등록해놓고 위치를 검색하는 용도로 사용

• Easier REST Clients, 더 쉬운 REST 클라이언트 : 각각의 마이크로 서비스 간의 통신을 위해서 REST 템플릿이나 Pain Client 등을 이용해서 데이터 통신
  • FeignClient
• Visibility and monitoring, 가시성 및 모니터링 : 시각화와 모니터링을 위해 분산 추적을 위한 집킨, 외부 모니터링 서비스를 연계해서 사용
  • Zipkin Distributed Tracing
  • Netflix API gateway
• Fault Tolerance, 내결함성 : 장애 발생 시 빠르게 복구하기 위한 회복성 패턴을 위해 넷플릭스의 Hystrix 제품을 사용해서 서비스 구현할 예정
  • Hystrix

참고자료

03. Monolithic vs MSA

03. Monolithic vs MSA

 

Microservice와 Spring Cloud의 소개

Microservice와 Spring Cloud의 소개