Cloud Native & Microservices

Cloud Naive Architecture

*확장 가능한 아키텍처

- 시스템의 수평적 확정에 유연

- 확장된 서버로 시스템의 부하 분산, 가용성 보장

- 시스템 또는 서비스 애플리케이션 단위의 패키지

- 모니터링

 

*탄력적 아키텍처

- 서비스 생성 - 통합 - 배포, 비즈니스 환경 변화에 대응 시간 단축

- 분활 된 서비스 구조

- 무상태 통신 프로토콜 > 종속을 최소화 해야함

- 서비스의 추가와 삭제 자동으로 감지

- 변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리)

 

*장애 격리

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

 

Cloud Native Application

*Microservices, CI/CD, DevOps, Containers

 

**CI/CD

- 지속적인 통합

( 결과물을 통합하기 위한 형상 관리, 통합 된 코드를 테스트/실행 ) > Jenkins, Team CI, Travis CI

-  지속적인 배포

Continuous Delivery(수작업 배포), Continuous Deployment(완벽한 자동화된 배포), Pipe line

 

**DevOps

개발 조직과 운영 조직의 통합 > 만족도 높은 결과를 제시를 목표

고객의 요구사항에 맞춰서 도메인 분석, 시스템 설계, 구현, 배포

피드백 > 업데이트 > 배포

 

**Container 가상화

기존의 하드웨어 가상화, 서버 가상화에 비해서 적은 리소스를 사용

프로세스를 격리된 환경에서 실행 

하나의 서버에서 다수의 컨테이너를 실행 > 독립적

CPU 또는 메모리를 제한할 수 있으며 호스트 디렉토리에 마운트하여 내부 디렉토리로 사용

 

컨테이너는 하나의 리눅스 커널을 여러 개의 독립된 환경처럼 사용

*커널 : OS의 핵심, 하드웨어와 직접 소통

 

컨테이너 : 운영 체제 수준의 가상화로 작동 > 리눅스 커널을 공유하며서 독립적으로 실행되는 애플리케이션 환경

- 네임스페이스 : 프로세스, 네트워크, 파일 시스템 등을 격리

                         각 컨테이너는 별도의 독립적인 환경처럼 동작

- croups : 컨테이너가 사용하는 CPU, 메모리, 디스크, 네트워크 등의 자원을 제한

 

[*하이퍼바이저(여러 가상 머신을 관리) 가상화]

하나의 컴퓨터에서 하나의 OS만 운영하는 방식을 해결

> 하나의 컴퓨터에서 다수의 독립적인 OS를 운영

   하이퍼바이저는 하나의 컴퓨터에서 여러 OS를 동시 실행하기 위한 소프트웨어

물리적 서버 위에 HOST OS(물리 서버의 운영 체제)가 존재하고 그 위에 다수의 독립적 OS가 가상으로 돌아갈 수 있도록 하는 것

 

[참고]

https://velog.io/@yenicall/Docker-%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80-VS-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EA%B0%80%EC%83%81%ED%99%94

 

12 Factors

BASE CODE 

> 하나의 버전 관리 시스템을 사용

> 동일한 코드베이스에서 여러 배포 환경

> 동일한 코드로 여러 인스턴스를 실행

DEPENDENCY ISOLATION
> 시스템 영향주지 않고 애플리케이션 환경을 독립적으로 구성

CONFIGURATION
> 환경 설정은 코드와 분리

LINKABLE BACKING SERVICES
> 백엔드 서비스의 연결성
> 데이터베이스, 메시지 큐, 이메일 섭스와 같은 모든 외부 서비스를 백엔드 서비스로 간주
   애플리케이션에서 동적으로 연결 가능해야함

STAGE OF CREATION (BUILD, RELEASE, RUN)
> 버전 관리를 효율적으로 하고, 문제 발생 시 롤백이 쉬움

STATELESS PROCESSES
> 자체 프로세스에서 운영 가능해야 함 (마이크로 서비스끼리 독립)
> 애플리케이션 프로세스는 상태를 저장하지 않음, 상태는 항상 외부 저장소에 저장

PORT BINDING - 자체 포함 기능
> 자체적으로 HTTP 서비스를 제공

CONCURRENCY 
> 작업 단위를 개별 프로세스로 나누고, 이를 확장 가능하도록 설계
> 작업을 큐에 넣고 병렬 처리

DISPOSABILITY
> 프로세스는 언제든 종료되거나 재시작될 수 있어야 함

DEVELOPMENT & PRODUCTION PARITY
> 개발 환경, 테스트 환경, 운영 환경은 최대한 동일하게 유지

LOGS
> 표준 출력(stdout)으로 스트림처럼 처리
> 로그 수집하기 쉬움

ADMIN PROCESSES FOR EVENTUAL PROCESSES
> 데이터베이스 마이그레이션, 크론 작업 등은 애플리케이션의 프로세스와 별개로 관리

+ API FIRST
> API 설계는 애플리케이션 개발 초기부터 중심이 되어야 하며, UI 및 클라이언트는 API 위에 구축

+ TELEMETRY
> 애플리케이션 상태(사용량, 성능, 에러 등)를 원격으로 모니터링

+ AUTHENTICATION & AUTHORIZATION

 

** Monolithic vs MSA

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

 

**Spring Cloud

- Centrailized configuration management

> Spring Cloud Config Server

 

- Location transparency

> Naming Server

 

- Load Distribution (Load Balancing)

> Ribbon, Spring Cloud Gateway

 

- Easier REST clients

> FeignClient

 

- Visibility and monitoring

> Zipkin Distributed Tracing

   Netflix API gateway

 

- Fault Tolerance

> Hystrix