[MSA] MicroService와 SpringCloud의 소개

특징

확장 가능한 아키텍처

• 시스템의 수평적 확정에 유연
• 확장된 서버로 시스템의 부하 분산, 가용성 보장
• 시스템 또는, 서비스 애플리케이션 단위의 패키지(컨테이너 기반 패키지)

탄력적 아키텍처

• 서비스 생성 - 통합 - 배포, 비즈니스 환경 변화에 대응 시간 단축
• 분할된 서비스 구조 
• 무상태 통신 프로토콜

장애 격리

• 특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않음

---

CI/CD

• 지속적인 통합 CI
  • 통합 서버, 소스 관리, 빌드 도구, 테스트 도구
• 지속적 배포
  • Continuous Delivery
  • Continuous Deployment
  • Pipe line

DEVOPS

배포 운영 QA의 교집합

지속적으로 끊임없이 지속배포운영해나가는 것!

 

서비스 단위를 작은 단위로 나눔으로써, 더 자주 배포 테스트 할 수 있게됨

---

Container 가상화

기존의 하드웨어 가상화에 비해서 적은 리소스를 사용하여 서비스를 구축할 수 있다

 

기존 방식 -> 가상화 배포 -> 컨테이너 배포

---

12 Factors

1. CodeBase

애플리케이션의 1개의 코드 베이스(Git, SVN)를 통해 관리되어야 하며, 동일한 코드로 운영/개발에 배포하여야 한다.

• 애플리케이션은 1개의 코드 베이스를 가진다
• 애플리케이션은 1개의 코드 베이스를 통해 운영/개발용으로 배포한다
• CodeBase 항목은 이어지는 타 항목을 준수기 위해 기본적으로 준수해야 하는 항목이다
• CodeBase 항목은 SVN, Git과 같은 코드 관리 시스템 사용으로 준수할 수 있다

2. Dependencies

애플리케이션의 모든 종속성을 명시적으로 선언하여 사용한다. 애플리케이션이 필요로 하는 라이브러리를 dependency manifest 파일에 (Gemfile, POM 등) 명시적으로 선언하여 사용한다. SaaS는 상황에 따라 다양한 환경(window, mac, linux)에 배포될 수 있다. Gemfile, pom 등을 사용하여 다양한 환경에서도 SaaS가 정상 동작할 수 있음을 보장할 수 있다. 예를 들어 curl 등을 사용하여 lib를 사용할 경우 os에 따라 오동작 할 수 있다.

 

3. Config

모든 설정 정보는 코드로부터 분리된 공간에 저장되어야 하고, 런타임에서 코드에 의해 읽혀야 한다. SaaS는 동일한 코드를 여러 환경(운영/개발)에 배포한다. 이를 위해 환경마다 달리 사용되어야 하는 정보를 분리한다.

분리되어야 할 정보

• 데이터베이스나 다른 백업 서비스를 처리하는 리소스
• 외부 리소스(S3, Twitter 등)의 인증 정보
• 각 배포마다 달라지는 값(cononical hostname..)
• dev,test,stage,prod의 배포 단계마다 다를 수 있는 어떤 값들

설정정보를 저장하면 안되는 곳

• code
• properties file
• build : one build, many deploy니까
• app server(jndi database 같은 정보)

Config 항목 준수 방법

• 배포 환경(개발/운영)용 설정파일을 작성
• Spring Cloud Config 사용

 

4. Backing services

백엔드 서비스를 연결된 리소스로 취급한다. SaaS의 리소스는 자유롭게 배포에 연결되거나 분리할 수 있고, 코드 수정 없이 전환이 가능해야 한다. 예를 들어 DB를 MySQL에서 Amazon RDS로 전환할 때 코드 수정 없이 가능해야 한다.

백엔드 서비스

• 네트워크을 통해 이용하는 모든 서비스
• DB, Cache, SMTP, Messaging/Queueing system

준수 방법

• Config에 백엔드 서비스의 URL이나 Locator를 저장하고, 코드에서는 설정을 읽어서 사용
• Factor3. Config 기능 사용

 

5. Build, Release, Run

코드 베이스는 build > release > run의 단계를 거쳐 배포로 변환되며, 각 단계는 엄격하게 분리되어야 한다.

준수 방법

• 빌드 단계는 개발자, 배포 단계는 배포툴, 실행 단계는 프로세스 매니저에 의해 시작

 

6. Process

실행 환경에서 앱은 하나 이상의 프로세스로 실행되며, 각 프로세스는 stateless로 아무것도 공유하지 않아야 한다. SaaS는 여러 개의 인스터스로 배포될 수 있다. 각 인스턴스는 메모리 파일 등을 공유할 수 없으며, 인스턴스가 재실행 될 때 local file, session과 같은 상태 정보는 모두 초기화된다.

 

준수 방법

• 메모리/파일을 사용할 경우 단일 트랜잭션 내에서 읽고, 쓰고 등의 모든 작업을 처리.
• 세션 상태 데이터의 경우 Memcached 또는 Redis와 같은 데이터 저장소에 저장

 

7. Port Binding

배포된 SaaS 애플리케이션을 타 애플리케이션에서 접근할 수 있도록 포트 바인딩을 통해 서비스를 공개한다. 앱도 백엔드 서비스처럼 URL을 제공하고, 라우팅 레이어가 외부에 공개된 호스트 명의로 들어온 요청을 포트에 바인딩 된 웹 프로세스에 전달한다. Factor4. Backing services의 확장으로, 포트 바인딩에 의해 공개되는 서비스는 HTTP뿐만 아니라 ejabberd나 Redis 같은 모든 종류의 서버 소프트웨어가 해당된다.

준수 방법

• 보통 dependency에 웹서버 라이브러리를 추가해서 구현

 

8. Concurrency

앱은 수평으로 확장할 수 있어야 하고, Factor6. Processes에 의해 동시성을 높일 수 있다.

준수 방법

• 모든 일을 처리하는 하나의 프로세스 대신 기능별로 분리된 프로세스 실행(micro service)
• 프로세스가 데몬형태가 아니어야 함
• OS 프로세스 관리자/분산 프로세스 매니저/Foreman 같은 툴에 의존해서 output stream을 관리하고, 충돌이 발생한 프로세스에 대응, 재시작과 종료를 처리해야 함

 

9. Disposability

프로세스는 shut down 신호를 받았을 때 graceful shut down 해야 한다. SaaS는 요청에 의해 Scale up/down이 빈번히 발생한다. Disposability를 준수함으로써 이러한 사용에 안정성을 얻을 수 있다. 예를 들어 Scale down 시점에 graceful shut down 이 아니라면 db lock 등으로 인해 타 프로세스에 영향을 주게 된다.

 

10. dev/prod parity

development, staging, production 환경을 최대한 비슷하게 유지한다. SaaS 애플리케이션은 개발 환경과 production 환경의 차이를 작게 유지하여 지속적인 배포가 가능하도록 디자인되어야 한다.

준수 방법

• 시간의 차이를 최소화: 개발자가 작성한 코드는 몇 시간 또는 몇 분 후에 배포되어야 함
• 담당자의 차이를 최소화: 코드를 작성한 개발자들이 배포와 production에서의 모니터링에 깊게 관여함
• 툴의 차이를 최소화: 개발과 production 환경을 최대한 비슷하게 유지

 

11. Logs

로그를 이벤트 스트림으로 취급하여 로그를 로컬에 저장하지 않는다. SaaS는 언제든지 인스턴스가 생성/삭제될 수 있다. 이때 로컬에 저장된 로그는 초기화되기 때문에 로그는 스트림으로 취급하여 별도의 저장소에 보관해야 한다.

준수 방법

• 스트림을 버퍼링 없이 stdout, stderr 로 출력함
• 별도의 로그 저장소를 사용

 

12. Admin Process

admin/maintenance 작업을 일회성 프로세스로 실행해야 한다.

일회성 프로세스

• 데이터베이스 마이그레이션
• 일회성 스크립트 실행

준수 방법

• 관리/유지보수 작업은 release와 함께 실행
• release와 동일한 환경에서 실행하고, 같은 코드 베이스와 config를 사용
• admin 코드는 동기화 문제를 피하기 위해 애플리케이션 코드와 함께 배포

---

Monolith VS Microservice Architecture

모놀리식 아키텍처 (Monolithic Architecture)

장점

1. 어떤 기능(서비스)이든지 개발되어있는 환경이 같아서 복잡하지않다.

2. 쉽게 고가용성 서버 환경을 만들 수 있다. ( 같은 어플리케이션으로 하나더 만들면 됨)

3. End-to-End 테스트가 용이하다. (MSA의 경우 테스트에 필요한 서비스들을 모두 동작시켜야함)

단점

1. 한 프로젝트의 덩치가 너무 커져서 어플리케이션 구동시간이 늘어나고 빌드,배포 시간도 길어진다.

2. 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다.

3. 많은 양의 코드가 몰려있어 개발자가 모두를 이해 할 수 없고 유지보수도 힘들다.

4. 일부분의 오류가 전체에 영향을 미친다.

5. 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다롭다.

Micro service architecture

장점

1. 기능별로 마이크로서비스를 개발하고, 작업 할당을 서비스 단위로 하면 개발자가 해당 부분을 온전히 이해할 수 있다.

2. 새로 추가되거나 수정사항이 있는 마이크로서비스만 빠르게 빌드, 배포가 가능하다.

3. 해당 기능에 맞는 기술, 언어 등을 선택하여 사용할 수 있다.

4. 일부분의 오류가 있으면 해당 기능에만 오류가 발생하고 그 부분만 빠르게 고쳐서 정상화가 가능하다.

 

단점

1. 관리가 힘들다. 작은 여러 서비스들이 분산되어있기 때문에 모니터링이 힘들다.

2. 개발의 까다로움. 서로를 호출하여 전체 서비스가 이루어지기 때문에 무조건 다른 서비스를 호출하는 코드가 추가된다. 

3. 통신관련 오류가 잦을 수 있다. 마이크로 서비스들 끼리 계속 서로 통신을 하다보니 모놀리식 아키텍쳐에 비해 통신관련 오류가 잦았다.

4. 테스트가 불편하다. 예로 End-to-End 테스트를 위해 UI, Gateway 등등 여러개의 마이크로 서비스를 구동시켜야 했었다. 

 

 

Everything should be a microservice

 

---

SOA와 MSA

• SOA(Service Oriented Architecture)
  • SOA는 서비스 단위로 개발을 하고, 개발된 서비스들을 공유함으로써 재가용성을 늘리고 유연성을 확보하는 것을 목표로 한다.
• MSA(Microservice Architecture)
  • MSA 또한 아주 작은 단위의 서비스로 소프트웨어를 구성함으로써 민첩하고 유연한 설계를 할 수 있도록한다.

• 재가용성

SOA는 서비스를 개발하고, 이를 최대한 재가용한다. 예를 들면, A 팀과 그 옆의 B 팀이 있을 때, A에서 개발한 서비스 a를 B에서도 그대로 사용하는 것이다. 이로써 개발된 서비스 단위로 재가용성을 늘리고, 필요에 따라 유연하게 사용함으로써 효율성을 증진시킬 수 있다.

하지만 MSA는 서비스가 공유되기보다 독립적으로 실행되는 것을 지향한다.

즉, 재가용성이 늘어나면 서비스간 결합도가 늘어나기 때문에 아주 작은 서비스 단위를 독립적으로 나누어 구성함으로써 탄력적이고 유연한 구조를 가질 수 있다. 그래서 MSA는 서비스를 공유하기보다 새로 개발하여 구성한다.

(SOA에서 언급되는 서비스보다 작은 아주 작은 서비스이기 때문에)

• 서비스간 통신 방식

서비스간 통신 방식이다.

SOA는 SOAP, WSDL, UDDI, ESB 등 서비스간 통합적이고 공통적인 방식으로 구성되고 통신한다. 그래서 서비스간 결합도가 증가한다.

하지만 MSA는 Restful API 방식으로 서비스 제공자가 외부로 나타낸 API를 통해 통신한다. 따라서 서비스간 결합없이 독립적인 환경과 통신이 가능하다.

 

 

RESTful API 

REST의 특징을 기반으로 서비스 API를 구현한것

REST API의 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것.

 

---

Service Mesh Capabilities

1. MicroService Architecture를 적용한 시스템의 내부 통신이 Mesh 네트워크의 형태를 띄는 것에 빗대어 Service Mesh로 명명되었습니다.
2. Service Mesh 는 서비스 간 통신을 추상화하여 안전하고, 빠르고, 신뢰할 수 있게 만드는 전용 InfraStructure Layer입니다.
   추상화를 통해 복잡한 내부 네트워크를 제어하고, 추적하고, 내부 네트워크 관련 로직을 추가함으로써 안정성, 신뢰성, 탄력성, 표준화, 가시성, 보안성 등을 확보합니다.
3. Service Mesh 는 URL 경로, 호스트 헤더, API 버전 또는 기타 응용 프로그램 수준 규칙을 기반으로하는 계층 7 네트워크 Layer 입니다.
   Service Mesh 의 구현체인 경량화 Proxy를 통해 다양한 Routing Rules, circuit breaker 등 공통기능을 설정할 수 있습니다. 이는 서비스 간 통신에 연관된 기능 뿐만 아니라, 서비스의 배포 전략에도 도움을 줍니다.

왜 Service Mesh 를 적용하는가?

Service Mesh 가 떠오르는 이유는 무엇일까요 ?

MicroService Architecture는 Monolitic Architecture의 단점 극복과 Cloud 환경에서 시스템을 운영할 때의 이점을 극대화하기 위해 많이 사용되고 있습니다.

이를 통해 많은 문제들이 해결되었지만, 또다른 문제점도 발생했습니다. 그것은 시스템의 런타임 복잡성 입니다.

https://medium.com/dtevangelist/service-mesh-%EB%9E%80-8dfafb56fc07

Service Mesh 란?

 

Service Mesh 구현

Service Mesh Architecture의 구현은 보통 서비스의 앞단에 경량화 프록시를 사이드카 패턴으로 배치하여 서비스 간 통신을 제어하는 방법으로 구현합니다.

서비스 간 통신은 사이드카로 배치된 경량화 Proxy를 통해서 동작합니다. 이 경량화 Proxy에 Routing rules, retry, timeout 등을 설정하고 로직을 작성하여 공통 기능을 기본 어플리케이션에서 분리시킬 수 있습니다.

 

 

---

Spring Cloud

 

Spring boot + Spring Cloud 

 

 

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