마이크로서비스아키텍처 - cloud.or.kr§ˆ이크로서비스... · 1) ejb 기반의분산서비스아키텍처구성도 리모트호출(필수) + 분산트랜잭션(많음)

Copyright © 2017 T3Q Co., Ltd. All Rights Reserved.

마이크로서비스 아키텍처Microservice Architecture

2

마이크로서비스 아키텍처

마이크로서비스 아키텍처 개요

마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 나누어 변경과 조합이

가능하도록 만든 아키텍처

UI 프론트엔드

회원

관리

상품

관리 회원관리 상품관리 주문관리

UI 프론트엔드

상품데이터

회원데이터

주문데이터

주문

관리

사용자데이터

상품데이터

주문데이터

표준 API/Protocol을 통한 데이터 통신

Monolithic Architecture Microservice Architecture

3



모노리틱 아키텍처와 마이크로서비스 아키텍처의 확장성


모든 기능의 전체 프로세스 복제 필요한 프로세스만 복제

4



모노리틱 아키텍처와 마이크로서비스 아키텍처의 요청 처리 구조


Web UI

ApplicationServer

Database

회원관리

상품관리

주문관리

재고관리

배송관리

Web UI

- 단순한 아키텍처

- 특정 서비스 변경 시 모든 코드의 수정 필요

- Web UI 클라이언트가 모든 서비스의 호스트 정보를 필요

- 서비스 개수가 늘어나면 응답 속도가 늦어짐

- 요청 처리를 위한 클라이언트의 코드가 매우 복잡해짐

- 모든 서비스의 프로토콜이 서로 일치하지 않을 수 있음

5



모노리틱 아키텍처와 마이크로서비스 아키텍처의 특징 비교

전체 어플리케이션을 하나의 통합된 패키지로 개발, 배포 어플리케이션을 개별서비스 단위로 개발, 배포

배포, 테스트, 표준화된 방식으로 관리 용이

- 서비스 단위의 신속한 개발, 확장 용이

- 특정 서비스의 오류가 다른 서비스에 영향을 주지 않음

- 서비스 별로 다른 언어로 개발 가능

서비스 복잡도, 규모 증가에 따른 문제점 증가

- 배포 시간의 증가

- 부분적 스케일 아웃의 어려움

- 안정성의 감소

- 분산시스템에 따른 추가적인 복잡도 증가

- 분산 환경에서의 Transaction 보장, 테스트, 배포,

관리의 어려움

- 서비스 간의 코디네이션이 필요


6



마이크로서비스 아키텍처 도입의 주요 목적

개발 생산성

배포 유연성

정교한 확장성

서비스를 작은 단위로 나누어 독립적으로 개발

해당 비즈니스 로직에만 집중 가능

연관 마이크로서비스만 테스트 수행

개발, 테스트, 배포 일정의 단축 가능

모노리틱 방식에서는 일부 변경에도 전체 테스트, 배포 필요

개별 서비스 단위로 개발, 패키징, 빌드, 테스트, 배포 가능

각 서비스 별 로드맵에 따라 유연한 스케줄 계획 가능

시스템의 확장 방법에는 전체 시스템 복제, 데이터 분리에 따른

접근성 확장, 기능(서비스) 분리에 따른 독립적 확장이 있는데

MSA는 서비스 단위 별 확장으로 리소스의 효율적 활용이 가능

서비스 분산 아키텍처

8서비스 분산 아키텍처

1. 자동화된 원격 배포 관리가 되어야 한다.2. End To End Monitoring이 되어야 한다.3. 권한/인증이 관리 되어야 한다.4. 세션 클러스터링을 지원해야 한다.5. 분산 트랜잭션을 지원해야 한다.6. 가상서버 관리가 가능하거나 관리가 편하도록 구성되어야 한다.7. 태넌트 관리가 되어야 한다.

분산 아키텍처가 갖추어야 할 기본 요건

정적 웹

서비스 클러스터

WEB 2

WEB N

A 서비스

WEB 1

동적 웹

WebApp 2

WebApp N

WebApp1

서비스 컨테이너 1

B 서비스

서비스 컨테이너 2

A 서비스

서비스 컨테이너 N

B 서비스

분산 클러스터

분산 코디네이터분산 코디

네이터

n

n

nL4 분산

(HAProxy)

n

n

<Node Read , Event> <Node Write>

n

EJB 서비스콜

분산 코디네이터

1) 서비스 분산 아키텍처 개념도


1

N

Sca

le-in

/out


1. 유동적인 시스템의 트래픽은 자동으로 Scale-in/out 되어야 한다.2. 한정된 하드웨어/소프트웨어 자원을 효율적으로 사용하기 위해서리소

스 모니터링을 통한 유동적인 리소스 분배가 가능해야 한다.

서비스 분산의 필요성

3. 서비스에 문제가 발생시 Failover/Failback이 자동으로 동작하여, 오류타임을 최소화 하여야 한다.

4. 모든 어플리케이션의 로그는 통합 로그서버로 표준화되어 수집되고 자동분석/알림이 가능해야 한다.

2) 서비스 분산의 필요성

언론사 ,포털,증권사

수신

제작

배부

편집

제작트래픽

편집트래픽

대외 배부

인터넷 배부

차세대 CMS

수신트래픽

웹 트래픽

모바일 트래픽

뉴스사이트

사진판매 사이트

모바일 웹/앱

외부 API 서비스

트래픽 분산1

트래픽 분산1

합리적 리소스 분배2

오류 자동복구및 오류타임의 최소화3

통합 어플리케이션 로그 모니터링4

차세대 미디어 플랫폼



3) 분산 코디네이터(주키퍼) 구성도

이벤트 흐름주키퍼

주키퍼 클러스터 ZooKeeper Watcher

• 분산된 시스템간의 정보 공유/상태체크 지원• 서비스의 위치 투명성 보장, 서비스 생명주기 모니터링• ZooKeeper( 일반 용도로 가장 많이 쓰이고 안정성이 검증)• 이중화를 위한 클러스터 구성은 필수• 노드라는 데이터 모델을지원

주키퍼 서버의 모든 이벤트는 와처를 통해모든 클라이언트로 전파된다.

/root/node1

/node2/node3

/node4

/root/node1

/node2/node3

/node4

/root/node1

/node2/node3

/node4

zkServer(leader)

zkServer

zkServer

계층구조메타저장

동기화

동기화

Client

watcher

zk Client

Client

watcher

zk Client

Client

watcher

zk Client

zkServer(leader)

zkServer

zkServer

동기화

동기화

zk Client

Client

zk Client

Client

zk Client

Client

이벤트

정보 변경

Watcher 등록1

정보 변경2

3

이벤트4


11


서비스 요건에 따른 아키텍처 유형

1) EJB 기반의 분산 서비스 아키텍처 구성도

리모트 호출(필수) + 분산 트랜잭션(많음) + 안정성(중요) 시 Distributed Container : EJB Container (Weblogic, JBoss 등) IoC 및 AOP 지원 : EJB Container Remote Call Tech : EJB Distributed 2PC Transaction : Container Managed Tx

EJB 기반의 분산 서비스 아키텍처

ControllerView

WEB

부하 분산/Failover

Web Container (Tomcat)

…

1

N

Sca

le-in

/out

등록전파

R

S S

분산 코디네이터(Zookeeper)

R

S S

R

S S

JVMService

EJB

DAO

EJB Container (JBoss)

JVM

SERVICE

Service

EJB

DAO

EJB Container (JBoss)

JVM

SERVICE

통합 관리 체계 구축(최소 모니터링 및 최소 제어)

Pool

S

S S

RemoteManager EJB Call

Spring MVC

12



2) 경량 컨테이너 기반의 분산 서비스 아키텍처 구성도

ControllerView

WEB


…

1

N

Sca

le-in

/out

등록전파

JVMService

Thrift Server

DAO

Tomcat/JBoss

JVM

SERVICE

Service

Thrift Server

DAO

Tomcat/JBoss

JVM

SERVICE


Pool

S

S S

RemoteManager

Thrift Client

R

S S


R

S S

R

S S

리모트 호출(필수) + 분산 트랜잭션(비중 낮음) + 안정성(비교적 덜 중요) 시 Distributed Container : Thrift Container Remote Call Tech : Thrift IoC 및 AOP 지원 : Spring Distributed 2PC Transaction(필요시) : JTA 구현체 (Atomikos TransactionsEssentials 등)

경량 컨테이너 기반의 서비스 분산 아키텍처 (Thrift + Spring)

Spring MVC


Thrift Call

13



3) RESTful 기반의 분산 서비스 아키텍처 구성도

ControllerView

WEB


…

1

N

Sca

le-in

/out

등록전파

JVMService

Servlet/JSP (HTTP기반)

DAO

Tomcat/JBoss

JVM

SERVICE

Service

Servlet/JSP (HTTP기반)

DAO

Tomcat/JBoss

JVM

SERVICE


RemoteManager

R

S S


R

S S

R

S S

Pool

S

S S

리모트 호출(필수) + 분산 트랜잭션(거의 없음) 시 Distributed Container : Servlet/JSP Container (HTTP 기반) Remote Call Tech : RESTful IoC 및 AOP 지원 : Spring Distributed 2PC Transaction (필요 시) : JTA 구현체 (Atomikos TransactionsEssentials 등)

RESTful 기반의 분산 서비스 아키텍처 / 로컬서비스 기반 ( Servlet/JSP Container + Spring)

Spring MVC


RESTfull Call

14


서비스 분산 아키텍처 사용 시나리오

a. 플랫폼 자체를 증가/확장 시켜야 할 경우

1) 서비스 분산 아키텍처 사용 시나리오

신생 미디어 업체가 연합뉴스의 서비스 구성

플랫폼( 수신, 제작, CMS, 배부, 서비스 시스

템 등 전체 구성)를 기반으로 최소한의 기간

과 비용으로 자신만의 뉴스미디어 시스템을

만들고자 할 때, 연합의 기술국은 어떻게 대

응할 것인가?

1. 하드웨어, 서버, OS, 미들웨어 (WAS,

DBMS 등)에 대한

Provisioning ( 반자동 혹은 수동)

IaaS와 PaaS를 제공하는 업체 서비스

(AWS, Azure) 계약을

체결하고 시나리오에 맞는 가상머신들

을 확보 후 필요한

OS, 미들웨어 설정을 마침

혹은 연합뉴스 자체 인프라를 제공할 수

도 있음

2. 서비스 배포 (자동 혹은 반자동)

뉴미디어 플랫폼을 구성하는 각 서비스

들에 대한 배포 정책 수립 및 재사용

정해진 서비스 배포 정책에 따라 배포엔

진을 통해 뉴미디어 플랫폼을 구성 하는

서비스를 배포

시나리오 대응전략

분산코디네이터

WebApplication Service

요청

뉴미디어 플랫폼



요청

뉴미디어 플랫폼

복제

Sca

le-in

/out

15



b. 플랫폼 내 서비스를 증가/확장 시켜야 할 경우

1) 서비스 분산 아키텍처 사용 시나리오

[2-1] 세계 3차 대전이 중국과 일본의 관계악화로 발생하였으며 이로 인해 일본 및중국에서 뉴스를 공급 받던 많은 통신사들이연합 뉴스를 통해 전쟁 관련된 신속한뉴스를 받고자 할 때 기존의 연합뉴스 발외국 통신사 전송이 급증했다. 이때 연합에서는 어떻게 대응할 것인가?

[2-2] 국내 연예인들이 이상 질병과 스트레스로 자살 사건이 발생하여 관련 뉴스에대한 서비스가 급증하며 시스템이 부하를감당하기 힘든 상황이 되었다.연합뉴스 에서는 어떻게 대응할 것인가?

[2-3] 현재 각 대학생 동아리 시스템을플랫폼으로 제공하고 있는데 전세계 학생뉴스 경진대회가 연합뉴스 주최로 치루어지게 되었습니다. 이에 따라 거의 사용되지않았던 대학교 동아리용 제작 및 편집시스템에 대한 부하가 급증하는 현상이발생하게 되었습니다. 연합뉴스에서는 어떻게 대응할 것인가?

[2-1] 배부 수신 시스템과 배부 시스템에대한 증대가 필요하기 때문에 수신/배부를담당하는 연계서비스에 대하여 실시간Scale-Out을 수행 함

[2-2] 연합뉴스 자체 서비스 폭증이기때문에 연합뉴스 자체 서비스 시스템을실시간으로 Scale-Out을 수행함

[2-3] 동아리용 제작 및 편집 시스템에 대한일정 기간 동안의 부하 증가이기 때문에동아리용 제작 및 편집 시스템과 향후 이를배부하기 위한 배부 서비스에 대하여Scale-Out을 수행함

시나리오 대응전략



부하증가

Sca

le-in

/out

16



a. 서비스 장애 시나리오 및 대응 전략

2) 서비스 분산 자체에 대한 시나리오

- 주말 아침 잘 동작 하던 서비스에 오류가 발생되어 서비스가 중지 되었다.

운영팀에서 확인해 보니 동작 중이던 서버의 파워 이상으로 시스템이 다운되었다.

- 하드웨어 수리및 예비하드웨어등으로 교체후 서버 OS를

설치하고 서비스를 셋팅하여 서비스를 기동한다.

( 1~수일이 소요)

- 설정된 백업 서버가 있을 경우 환경설정등을 수정하여

소스 재컴파일 하여 서비스를 기동한다. (수시간 소요 )

시나리오

AS-IS 대응전략

- EJB 서비스와 연계된 주키퍼 서버는 세션종료를 파악하고 ,

모든 클라이언트에 이벤트를 보낸다.

이벤트를 받은 WebApplication 은 문제의 EJB를 서비스에서

배재한다. ( 1~5초 소요 )

분산 아키텍처 적용시

17



b. 특정 서비스 코드 오류(ex.무한루프) 발생으로 인한 해당 서비스및 타서비스 장애 시나리오 및 대응전략


- 새로 입사한 김모 개발자는 새로운 기능을 추가하였다.

하지만 소스분석을 충분히 하지 못했던 그는 다른 업무와 연동되는 로직을 제대로 확인하지 못하고 새 기능을 배포 하였다.

배포 후 연동로직이 제대로 동작하지 않는 탓에 프로세스가 무한 대기에 빠지고, 해당 서버의 모든 서비스가 무한루프에

빠지는 현상이 발생 되었다.

- 단순 포트 모니터링에서는 해당 오류를 빠르게 캐치할 수

없을 수 있다.

- 버그 소스를 추적하여 해당 버그를 수정하여 재배포한다.

( 수시간~수일이 소요)

- 버그 소스의 정확한 위치나 배포 관리가 되고 있을 경우는

서비스를 롤백하여 장애 시간을 줄일 수도 있다.

시나리오

AS-IS 대응전략

- 특정 EJB 서비스의 무한루프 발생시 EJB 서비스를 별도의

프로세스로 동작하므로 타 서비스와 영향을 최소화 한다.

- 무한 루프는 모니터링을 통해서 이벤트를 받은

WebApplication 은 문제의 EJB를 서비스에서 배재한다.

( 1~5초 소요 )

- 통합 모니터링을 통해 서비스 이상을 관제에 알림을 보내고,

관제 담당자는 비정상 프로세스를 재시작/롤백 등으로

대응한다


18



c. 존재 하지 않던 추가 서비스를 신규 서버 혹은 기존 서버에 배포해야 하는 시나리오 및 대응 전략


- 평온한 일요일 아침 군사분계선 남측으로 북한군의 전투기 1대가 남쪽으로 넘어왔다.

이 내용은 긴급 속보로 보도 되었고, 이 기사로 인해 순간 트래픽이 평상시의 5배로 상승하면서 서버응답 딜레이 현상이

발생하였다.

- 추가적으로 서버가 필요할 경우는 새로운 서버를 도입하여

OS 설치및 환경설정 과정이 선행 되어야 한다. (1~수일 소요)

- 새로운 서버에 서비스를 배포하고, 서비스가 연동 될 수

있도록 설정코드를 수정하여 재컴파일 후 배포한다.

(1~수시간 소요)

시나리오

AS-IS 대응전략

- 새로운 서비스를 추가하거나 기존 서비스의 추가적 배포가

필요한 경우 운영자는 관리자메뉴를 통해 대상 서비스와

배포서버/포트 등의 정보를 입력하여 EJB서비스를 시작한다.

( EJB서비스는 자동으로 분산 코디네이터에 서비스를

등록하고, 분산 코디네이터로 부터 이벤트를 받은

WebApplication은 새로운 정보를 사용하여 서비스 한다.)


19



d. 기존에 있던 서비스와 이를 변경한 신 서비스로 교체가 필요한 경우 시나리오와 대응 전략


- 관리자 최모씨는 사이트 부분 리뉴얼로 일부 새로 개발한 모듈을 기존 모듈과 교체배포 하여야 한다.

- 개발자 김모씨는 기존 모듈에 버그를 발견하고 수정한 버전을 개발 하여, 수정 모듈로 교체 하려고 한다.

- 작업 공지를 띄우고 심야 시간에 2~수시간 준비된 새로운

모듈로 교체작업/테스트 후 아침부터 서비스 한다.

시나리오

AS-IS 대응전략

- 새로운 서비스를 서비스가 가능하도록 EJB 서버에 배포하여

분산코디네이터 에 등록한다.

이용자가 적은 시간을 이용해 새로운 WebApplication 을

배포하여 신규서비스를 동작시킨다. ( 수분 소요)


20



e. WebApplication 장애 대응 시나리오및 대응 전략


- 운영팀 최모씨는 서비스 중이던 WebApplication 서버가 파워 이상으로 전원이 나가면서 서비스오류가 발생되는 것을

확인 하였다.

- 서버팀 박모씨는 서버작업중 서버 라벨링을 잘못 확인하여 서비스 중이던 WebApplication 서버를 종료 시켰다.

- 일요일 새벽 운영중이던 WebApplication 서버가 보안결함으로 인한 외부 공격으로 다운되었다.

- 문제의 WebApplication의 원인을 파악하여 서버를

셋팅하여 서비스를 기동한다. ( 1~수일이 소요)

- L4스위치등을 통한 이중화가 되어 있는 경우는 자동으로

우회 하여 서비스는 동작 하지만 세션문제로 인해 기존

사용자는 오류가 발생 할 수도 있다.

(수초 내 우회 동작은 하나 하드웨어 기반 고비용 구조)

시나리오

AS-IS 대응전략

- WebApplication 서버 이상시 HAProxy 를 통해 장애 서버를

우회하게 되고 장애서버의 세션은 세션클러스터링을 통해

다른 서버에서도 오류 없이 동작한다.

(수초 내 동작하는 오픈 소프트웨어 기반 저비용 구조)


21



f. 분산 코디네이터 장애 시나리오 및 대응전략


- 서버팀 박모씨의 서버작업중 실수로 뒤에 있던 분산코디네이터 서버의 파워선이 뽑혀 버렸다.

- 운영팀 최모씨는 OS 보안패치등 유지관리를 위해 분산코디네이터 서버를 재부팅 하려고 한다.

- (분산코디네이터 사용안함)

시나리오

AS-IS 대응전략

- 서비스 중이던 분산코디네이터 서버의 연결이 종료되면

분산코디네이터 그룹은 장애로 판단 해당 서버를 서비스에서

자동으로 배재한다. ( 1~수초 소요)



시연

Thrift를 이용한 분산 어플리케이션 개발

IDL File (Text) 정의( App Service, Data Def.)

자동으로 생성된 코드(C/C++, Java, Php, …)

DTO, InterfaceClient, Processor

Code Generation(Thrift.exe)

App. Server

Thrift App. Server Code

Biz Logic Code(Handler- App. Imple)

Thrift Library

App. Client

Thrift App. Client Code

Thrift Library

Thrift Concept

Use <DTO, Client, In/Out Parameters> Use <DTO, Processor, Interface)

Remote Call

1

3

2

4

6

7

Start Server 5


App. Server GroupApp. Client


4. 시연 - Zookeeper를 이용한 신속한 Scale-out, Scale-In / 분산 코디네이션

Zookeeper Architecture (zookeper App. Server Management cluster)

Client

zk clientlib

Client

zk clientlib

Client

zk clientlib

zkserver1

Replicated withEventual Consistency

Data operation(create, delete)

Node event

zkServer2(leader)

zkserver3

zkserver4

zkserver5

App. Server #1

zk clientlib

App. Server #2

zk clientlib

App. Server #3

zk clientlib

Service Call

Connect Zookeeper

Connect Zookeeper

App. Server Group


Zookeeper Architecture (zookeper service cluster)

Client

zk clientlib

zkserver1

Replicated withEventual Consistency

Data operation(create, delete)

Node event

zkServer2(leader)

zkserver3

App. Server #1

zk clientlib

App. Server #2

zk clientlib

App. Server #3

zk clientlib

Service Call

Connect Zookeeper

Connect ZookeeperNode event

시연 - Zookeeper를 이용한 신속한 Scale-out, Scale-In / 분산 코디네이션

26


참고자료

http://zigispace.net/884

https://www.joinc.co.kr/w/man/12/MicroserviceArchitecture

http://blog.lgcns.com/1278

http://couplewith.tistory.com/88

http://guruble.com/?p=951

http://bcho.tistory.com/948

http://www.popit.kr/why-microservice/

http://zigispace.net/884

https://www.joinc.co.kr/w/man/12/MicroserviceArchitecture

http://blog.lgcns.com/1278

http://couplewith.tistory.com/88

http://guruble.com/?p=951

http://bcho.tistory.com/948

http://www.popit.kr/why-microservice/

감사합니다.

Documents

마이크로서비스아키텍처 - cloud.or.kr§ˆ이크로서비스... · 1) ejb 기반의분산서비스아키텍처구성도 리모트호출(필수) + 분산트랜잭션(많음)