Microservice 와 Spring Cloud 의 소개

[choboss00]

소프트웨어 아키텍처

IT 시스템의 발전 과정

1960 ~ 1980년대 : 하드웨어 중심 ( Mainframe ) 1990 ~ 2000년대 : 시스템 안정화, 분산 시스템 2010년대 ~ : 탄력적, 클라우드 네이티브 시스템 구축

Antifragile 특징

• Auto scaling : 자동 확장성을 가짐, 사용환경에 따라 자동으로 인스턴스를 늘릴 수 있음
• Microservices : 클라우드 네이티브 시스템 핵심, 전체 서비스를 구축하고 있는 모듈, 기능을 세분화한 서비스
• Chaos engineering : 시스템의 불확실성에 대해서도 안정적인 서비스를 제공하도록 구축할 필요가 있음
• CI/CD : 지속적 통합, 지속적 배포

[choboss00]

Cloud Native Architecture

확장 가능한 아키텍처

• 시스템의 필요에 따라 확장할 수 있어야 함
• 시스템 부하 분산, 가용성 보장
• 서버 가상화, 컨테이너 가상화

탄력적 아키텍처

• 어플리케이션을 구성하는 각 기능을 CI/CD 로 처리, 시간 단축 ( 자동화 )
• 도메인의 특성에 따라 서비스를 잘 구분해야 함
• Discovery Service 라는 곳에 등록, 삭제됨

장애 격리 ( Fault isolation )

• 특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않음
• 특정 서비스만 배포하면 되기 때문에 다른 시스템에 영향을 주지 않음

[choboss00]

Cloud Native Application

위에 적혀있는 내용들을 토대로 구현된 것

Microsrvices, CI/CD, DevOps, Containers ( 클라우드 환경 )

CI/CD

• 지속적인 통합, CI : 통합된 코드를 빌드, 테스트하는 과정
• 지속적 전달, 배포, CD

패키지화되어있는 결과물을 수작업으로 실행 환경에 배포 : 지속적 전달 ( Continuous Delivery ) 관리자의 개입 없이 자동으로 실행 환경에 배포 : 지속적 배포 ( Continuous Deployment )

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

DevOps

• Development, QA, Operations
• 고객의 요구사항에 맞는 에러 없는 완성물을 만들기 위한 과정

Container 가상화

• 클라우드 환경으로 이전해서 적은 비용으로 탄력성있는 시스템을 구축하는 과정

• 전통적인 개발 시스템 : 하드웨어 위에 운영체제를 두었음

• 가상화 개발 시스템 : 하드웨어 위에 운영체제위에 Hypervisor 를 둔 뒤 여러대의 가상머신을 돌릴 수 있음 하지만 호스트 운영체제에 많은 부하를 주게 됨

• 컨테이너 가상화 개발 시스템 : 컨테이너 가상화에서는 공통적인 라이브러리나 리소스를 공유해서 사용함 즉 필요한 부분만 독립적으로 사용하니, 부하가 덜하고 작동하는 서비스는 빠르게 동작할 수 있게 됨

[choboss00]

12 Factos

클라우드 네이티브 어플리케이션을 개발, 서비스할 때 고려해야 할 목록

Base code

• 버전을 제어하기 위한 목적
• 형상관리를 위해 코드를 한 곳에서 배포하는 것이 목적 ( 코드의 통일적인 관리 )

Dependency Isolation ( 종속성 )

• 각 마이크로서비스는 전체 시스템에 영향을 주지 않은 채로 변경될 수 있어야 함

Configurations ( 구성 정보 )

• 시스템 코드 외부에서 마이크로서비스에 필요한 작업 제어

서비스 지원

• 마이크로서비스가 가져야 할 기능들을 추가로 지원할 수 있는 것
• 코드 의존성을 갖지 않은 상태로 작업할 수 있어야 함

빌드, 릴리즈, 실행 환경 분리

프로세스

• 실행 중인 다른 서비스와 분리된 채 다른 프로세스에서 운영될 수 있어야 함
• 필요한 자원이 있다면, DB, 캐시 등으로 데이터를 교환하는 형태

포트 바인딩

• 마이크로서비스는 자체 포트에서 노출되는 인터페이스 기능
• 마이크로서비스와의 격리 가능

동시성

• 수많은 서비스를 복사, 확장해나가게 됨
• 부하 분산

Disposability

• 서비스 인스턴스 자체가 삭제가능해야 함

개발단계와 프로덕션 단계의 구분

• 환경 자체를 최대한 다른 작업과 중복되지 않고, 종속적이지 않은 형태로 서비스를 유지

로깅

• 로그, 이벤트 집계를 위한 추가적인 서비스, 모니터링 도구 사용

프로세스

• 모든 마이크로서비스들을 어떤 상태로 사용중이며, 리소스가 어떻게 쓰이는지 확인할 수 있는 관리도구가 필요함
• 리포팅, 데이터 정리, 데이터 분석 기능

12 Factors + 3

API first

• API 형태 구축, 서비스 제공

Telemetry

• 개발 시각화, 수치화 항목

Authentication and authorization

• 인증 작업

[choboss00]

Monolithic vs Microservice

Monolith

• 하나의 커다란 소프트웨어 안에서 전체를 관리
• 서로 의존성을 가지고 배포됨
• 일부 기능만 수정하더라도, 전체를 다시 배포해야 함

Microservice

• 서비스의 내용을 분리해서 개발하는 방식
• 유지보수, 변경 가능성 Good
• 독립적 배포 가능
• 어플리케이션 전체가 다운되는 경우 X

Front & Back

• 프론트 부분과, 백엔드 부분을 나눠서 처리
• 대표적으로 모바일 부분에서 많이 볼 수 있음
• 각각 최적화된 개발환경을 독립적으로 운용할 수 있음

도식화

[choboss00]

Microservice Architecture 란?

Microservice 의 특징

Microservice 도입할 때 고려할 부분

[choboss00]

SOA vs MSA

서비스를 지향한다는 공통점

SOA ( Service Oriented Architecture )

• 재사용을 통한 비용 절감
• 공통의 서비스를 서비스 버스에 모아서 하나의 서비스 형태로 만듬

MSA

• 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응
• 독립된 비즈니스 서비스, 리소스, 데이터들은 REST API 를 통해서만 다른 서비스에서 사용할 수 있음

REST API

• 기존 리소스를 웹서비스 상태로 제공하기 위한 URL 매핑 형태 ( 0단계 )
• 리소스를 의미있고 적절한 형태로 URL 작성, HTTP 의 메소드별로 서비스 구분 X ( 1단계 ) --> method 를 GET, POST 로만 처리한다던지 등
• level 1 + HTP Methods, 리소스를 적절하게 용도와 상태에 따라 설계하는 것 ( 2단계 )
• level 2 + HATEOAS, 데이터를 가지고 그 다음 작업에서 어떠한 액션을 할 수 있는지 상태 정보를 넘겨줌 ( 3단계 )
• -> 그 다음 URI 값들을 함께 넘겨줌

RESTful Web Service 고려 사항

• 소비자 입장에서 간단명료하고 직관적인 API 설계
• HTTP 메소드, 리퀘스트, 리스폰스 등 장점을 최대한 살리기
• 적절한 상태코드 전달
• 사용자의 비밀번호와 같은 크리티컬한 정보를 암호화해야 함
• 제공하려는 데이터는 복수의 형태로 URI 값을 설정하는 것이 좋음
• 모든 리소스는 가능하면 명사형태로 표현하는 것이 더 직관적임
• 일괄적인 엔드포인트 사용

참고

• HATEOAS 설명과 예시

[choboss00]

Microservice Architecture Structures

Service Mesh Capabilites

• 서비스간의 통신을 추상화, 안전하고 신뢰성있게 통신할 수 있게끔 한 레이어
• 응용 프로그램의 규칙을 기반으로 하는 네트워크 레이어
• 하나의 제품, 서비스를 지칭하는 것이 추상적인 개념

CNCF ( Cloud Natvie Computing Foundation )

• 일종의 서비스 가이드

[choboss00]

Spring Cloud 란?

독립 개발 환경인 마이크로서비스 환경을 지원 제공해주는 다양한 서비스들을 활용해서 서비스 구축할 계획

• Spring Cloud Config Server
• Naming Server ( Eureka )
• Ribbon, Spring Cloud Gateway
• FeignClient
• Zipkin Distribute Tracing, Netfilx API gateway
• Hystrix