마이크로서비스를 위한 컨테이너 플랫폼 Hyunsoo Kim(hykim@redhat.com) Red Hat

Monoliths and Microservices

3

마이크로서비스가 최고의 방법?

4

마이크로서비스 기반 설계는 좋은 애플리케이션 설계에 대해

우리가 배운 모든 것들의 궁극적인 표현1)

1) Cotton, Ben. "모놀리스에서 마이크로서비스로." 2017년 1월 3일 https://www.nextplatform.com/2017/01/03/from-monolith-to-microservices

그래서, 우리는 이렇게 질문합니다

5

모놀리식 애플리케이션을 마이크로서비스 애플리케이션으로

대체할 수 있습니까?

질문을 바꿔야 합니다

6

회사의 전략적 목표는 무엇이며, 이를 달성하기 위해 어떻게 해야 합니까?

의사소통 구조와 문화, 업무 역량, 그리고 필요한 워크플로우를 이해한 다음, 서비스들이 연결되는 방식, 이들 서비스의 라이프사이클,

그리고 마지막으로 애플리케이션 아키텍처를 파악해야 합니다

왜 마이크로서비스를 도입하려고 하나요?

7

Time to Market

without Failure

결론은

8

어떤 아키텍처 형태가 우리에게 가장 적합한가?

Monoliths vs Microservices

9

Monoliths Microservices 개발 •  보다 빠른 최초 개발

•  서비스 추가 또는 변경이 어려움 •  설계 기간 단축이 중요(설계가 매우 어려움) •  서비스 추가 또는 변경이 쉬움

애플리케이션워크플로우

•  손쉽게 애플리케이션을 워크플로우에 적용

•  단일 위치에서 기능(예를 들어 인증 또는 모니터링) 구축

•  보다 복잡한 워크플로우 내 서비스 할당 •  명확하지 않은 서비스 간의 상호 의존성 및 요구사항

•  DB Join 등 어려움

교육 및 유지 관리

•  단순한 아키텍처 •  환경 및 언어에 대한 엄격한 개발 요구 사항

•  유연한 아키텍처 •  더욱 복잡한 설계 •  표준화된 API 또는 통신을 위한 메시징 기능 필요

확장성 •  어려운 확장; 하드웨어 인프라에 따라 차이가 있음

•  한번의 서비스 수요 급증에 대비한 전체 애플리케이션 확장

•  전반적인 아키텍처에 영향을 미치지 않으면서 개별 서비스를 손쉽게 확장 가능

•  동적 대응을 위해 소프트웨어 정의 인프라 활용(컨테이너, 클라우드)

Monoliths vs Microservices

10

Monoliths Microservices 업데이트, 페일오버, 가동중지시간

•  모든 서비스가 종속적으로 연결 •  서비스들은 함께 업데이트 되어야 함; 버전 관리가 연결됨(마이크로서비스도 동일)

•  개별 서비스 장애시 시스템 장애가 발생하는 위험(마이크로서비스도 동일)

•  서비스들이 연결되지 않음 •  서비스는 독립적으로 추가 또는 업데이트될 수 있음

•  장애 위험은 소수의 서비스로 제한됨(Circuit Breaker 등의 기능 필요)

자동화 •  자동화는 대체로 불필요 •  자동화와 오케스트레이션이 필요

적용 대상 시스템

•  계정계 시스템 등에 적합 •  모바일 애플리케이션 등에 적합

마이크로서비스 적용시 고려 사항

11

•  분산 컴퓨팅의 허점 - 마이크로서비스가 모든 가동중단을 미스테리한 살인사건으로 만들어 버린다는

농담1)

•  트랜잭션 비용 및 지출 증가 - 필수적인 인프라 변화 및 새로운 직무 능력을 가진 인력 채용 및 재교육 등

•  복잡성 증가 - 마이크로서비스는 수백 개의 잠재적인 장애 지점을 가짐 - 상호의존성이 명확하지 않아서 복잡성 증가

•  시스템 사고(Systems thinking)와 설계 - 시스템에 대한 전반적인 이해가 이루어지지 않는다면, 모놀리스와 상당부분

유사해짐2)

1) @HonestStatusPage. Twitter, 2015년 10월7일, https://twitter.com/honest_update/status/651897353889259520?lang=en 2) Knoernschild, Kirk. "아키텍처 및 제공 민첩성 극대화를 위한 모놀리식 소프트웨어의 리팩터링(refactor)." Gartner Key insights, 2017년 5월 18일

Monoliths,Microservices + Container

12

Monoliths + Container Microservice + Container 확장성 •  컨테이너 적용시 보다 쉽게 확장 가능

•  오토스케일링 기능 적용으로 유연한 확장 가능

•  컨테이너 적용시 보다 쉽게 확장 가능 •  오토스케일링 기능 적용으로 유연한 확장 가능

업데이트, 페일오버, 가동중지시간

•  모든 서비스가 종속적으로 연결 •  서비스들은 함께 업데이트되어야 함; 버전 관리가 연결됨(마이크로서비스도 동일)

•  컨테이너의 Scale-out 을 통해 확장하여 장애 발생에 대비 가능

•  개별 서비스 장애시 시스템 장애가 발생하는 위험 – 컨테이너 적용 시 빠르게 rollback 하여 장애 최소화 가능

•  서비스들이 연결되지 않음 •  서비스는 독립적으로 추가 또는 업데이트될 수 있음

•  장애 위험은 소수의 서비스로 제한됨(Circuit Breaker 등의 기능 필요)

•  컨테이너의 Scale-out 을 통해 확장하여 장애 발생에 대비 가능

•  개별 서비스 장애시 시스템 장애가 발생하는 위험 – 컨테이너 적용시 빠르게 rollback 하여 장애 최소화 가능

자동화 •  컨테이너에 자동화 및 오케스트레이션 기술을 적용하면 보다 빠른 릴리즈 가능

•  컨테이너에 자동화 및 오케스트레이션 기술을 적용하면 보다 빠른 릴리즈 가능

컨테이너

13

l  OS 가상화 기술 (vs. HW 가상화 기술 a.k.a. VM) l  HW 가상화 기술보다 더 경량화

l  컨테이너 기술의 종류 l  LXC

l  OpenVZ

l  Solaris/HPUX

l  CoreOS rkt

l  OCI Container - Open Industry Standard Container

표준 컨테이너 기술

14

Established in June 2015

Create Open Industry Standards

around Container Formats and Runtime

https://www.opencontainers.org/

CoreOS rkt

15

VM vs. Container

16

1.  Hypervisor나 GuestOS로 인한 overhead 없음 2.  Guest OS 관리 부분의 부담이 없음 3.  빠른 startup 4.  인스턴스 증가시, 추가적인 설정작업 없이 서비스 제공

VIRTUAL MACHINES CONTAINERS

virtual machines are isolated apps are not

containers are isolated so are the apps

VM

OS Dependencies

Kernel

Hypervisor

Hardware

App App App App

Hardware

Container Host (Kernel)

Container

App

OS deps

Container

App

OS deps

Container

App

OS deps

Container

App

OS deps

VM vs. Container

17

Container Host

Container

Application

OS dependencies

Virtual Machine

Application

OS dependencies

Operating System

VM Isolation Complete OS Static Compute Static Memory High Resource Usage

Container Isolation Shared Kernel Burstable Compute Burstable Memory Low Resource Usage

VM vs. Container

18

Container Host

Container

Application

OS dependencies

Dev

IT Ops Infrastructure

Virtual Machine

Application

OS dependencies

Operating System

IT Ops (and Dev, sort of)

Infrastructure

Clear ownership boundary between Dev and IT Ops drives DevOps adoption

and fosters agility

Optimized for stability

Optimized for agility

Virtual machines are NOT portable

19

Virtual machines are NOT portable across hypervisor and do NOT provide portable packaging for applications

VM Type X

Application

OS dependencies

Operating System

VIRTUALIZATION BARE METAL

Application

OS dependencies

Operating System

PRIVATE CLOUD

VM Type Y

Application

OS dependencies

Operating System

PUBLIC CLOUD

VM Type Z

Application

OS dependencies

Operating System

LAPTOP

Guest VM

Application

OS dependencies

Operating System

Containers are portable

20

RHEL Containers + RHEL Host = Guaranteed Portability Across Any Infrastructure

LAPTOP

Container

Application

OS dependencies

Guest VM

RHEL

BARE METAL

Container

Application

OS dependencies

RHEL

VIRTUALIZATION

Container

Application

OS dependencies

Virtual Machine

RHEL

PRIVATE CLOUD

Container

Application

OS dependencies

Virtual Machine

RHEL

PUBLIC CLOUD

Container

Application

OS dependencies

Virtual Machine

RHEL

Red Hat OpenShift Container Platform

21

An Open-source Framework For Managing Containerized Applications

At Scale

Deployment Automation

22

Automatic Deployment of Containers on Any Infrastructure

NODE NODE NODE

Laptop | Bare-metal | Virtualization | OpenStack Amazon Web Services | Microsoft Azure | Google Cloud

Infrastructure as Code

23

NODE NODE

LB

YAML JSON

Declarative Container Infrastructure

Immutable Infrastructure

24

APP

Mutable Infrastructure Leads to Fragile Hard-to-Reproduce Snowflakes

Immutable Infrastructure

25

App Image

App

CONTAINER

Starting From the Same Validated State Each Time

Immutable Infrastructure

26

App Image

App

CONTAINER

Starting From the Same Validated State Each Time

Immutable Infrastructure

27

App Image

App

CONTAINER

App

CONTAINER

Starting From the Same Validated State Each Time

Environment Consistency

28

App App Image

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

App

CONTAINER

LOCAL DEV TEST STAGE PROD

Build Once, Deploy into Production-like Environment Everywhere

Continuous Delivery Pipeline

29

CHANGE BUILD TEST DEPLOY VERIFY RELEASE GO LIVE

Zero Downtime Deployment

30

service

App v1 CONTAINER

App v1 CONTAINER

client

Safe Rolling Updates Without Disrupting The Production Traffic

Zero Downtime Deployment

31

Safe Rolling Updates Without Disrupting The Production Traffic

service

App v1 CONTAINER

App v1 CONTAINER

client

App v2 CONTAINER

Zero Downtime Deployment

32

Safe Rolling Updates Without Disrupting The Production Traffic

service

App v1 CONTAINER

client

App v2 CONTAINER

Zero Downtime Deployment

33

Safe Rolling Updates Without Disrupting The Production Traffic

service

App v1 CONTAINER

client

App v2 CONTAINER

App v2 CONTAINER

Zero Downtime Deployment

34

Safe Rolling Updates Without Disrupting The Production Traffic

service

client

App v2 CONTAINER

App v2 CONTAINER

Auto Scaling

35

Container Autoscaling Without Human Interaction

Auto�Scaling�

SERVICE

app=payroll role=frontend

POD

app=payroll

role=frontend

POD

app=payroll

role=frontend

Name: payroll-frontend IP: 172.10.1.23 Port: 8080

version=1.0 version=1.0

POD

app=payroll

role=frontend

POD

app=payroll

role=backend version=1.0

Red Hat Discovery Session 소개 Hyunsoo Kim(hykim@redhat.com) Red Hat

디스커버리 세션 배경

37

•  디지털 트랜스포메이션 •  빅데이터, AI, 블록체인, IoT 등 IT 트렌드

•  Cloud, Container, NFV/SDN •  마이크로 서비스 아키텍처 기술 복잡도

•  사람 – 프로세스 – 기술 변화 필요 •  전략적이고 조직을 넘나드는 협업 필요 DevOps

디스커버리 세션 개념

38

디스커버리 세션이란?

고객의 디지털 트랜스포메이션으로 전환을 위한 "여행"을 위해, 고객의 목표와 요구사항들을 사전 정의하고 구조화된 방식으로 범위를 지정하고, 고객의참여와 토론을 통해 고객의 개선안을 도출함으로써, 고객의 디지털 트랜스포메이션을 도와드리는, 레드햇의 방법

목표와 과제 도출

양방향의 전략 토론 방식

핵심 이해관계자 참여

고객의 기술/조직역량 파악

실행 가능한 개선안 도출

디스커버리 세션 제안 항목

39

구분 디스커버리 세션 세부 항목 제품 기준

Applications

App Migration and Modernization JBoss EAP OpenShift Container Platform

Containerized Application Delivery OpenShift Container Platform Microservice Architecture

Cloud &

Infrastructure

Ansible Automation Ansible Ansible Tower

Cloud Infrastructure OpenStack Cloud Forms Ceph Storage

디스커버리 세션 진행 절차

40

1. 고객 Needs -  디스커버리 세션 관련 고객 필요 또는 요청

-  세일즈로 문의

2. 미팅 -  고객 환경 및 요청 사항 관련 미팅

-  일정/참석자/세부주제 등 협의

3. 세션 준비 -  미팅 이후 관련 세션의 질문지 전달

-  질문지 피드백 기준의 세션 준비

5. 세션 결과 보고서 전달 -  세션시 도출된 내용을 토대로 최종 결과 보고서 작성

-  1~2주 소요 -  최종 결과 보고서 전달 -  추가 컨설팅 또는 사업에 대한 협의

4. 세션 진행 -  세션 목적 및 방향성 제시 -  고객요구사항/개선사항/ 로드맵 및 향후 계획 등

협의 -  상호 질의 응답 및 토론 형태 -  도출 내용에 대한 Wrap-Up

디스커버리 세션 아젠다

41

Session Duration Lead Description Point

소개 30분 레드햇 참석자 소개와 디스커버리 세션 개요 소개

Why 비지니스 개요 1시간 고객 고객의 비즈니스 개요 프레젠테이션 및 이에 대한 질문과 답변

시장 개요 30분 레드햇 레드햇 솔루션 및 관련 사례 등에 대한 세션 진행 How

현재 고객 상황 (AS-IS) 1 - 2 시간 양방향 주요 설계 아키텍처, 사용 사례, 현재 환경 상태, 기존 과제 및

비즈니스 관련 내용

What 향후 목표 (TO-BE) 1 - 2 시간 양방향 현재 상태에서 미래 상태로의 전환 및 유스케이스에 우선순위를

두는 고급 아키텍처, 관련 Red Hat 솔루션 및 접근 방식 논의

로드맵과 다음 단계 1 시간 레드햇 주요 사항 리뷰와 다음 단계 일정을 위한 Wrap-up세션

디스커버리 세션 단계

42

Project (Paid)

Discovery Workshop

(Paid)

Discovery Session

(Non-Paid)

감사합니다 Hyunsoo Kim(hykim@redhat.com) Red Hat