MSA를 이용해 구현하는 고가용/고확장 서비스 정리

MSA를 이용해 구현하는 고가용/고확장 서비스

MSA 등장 배경

• 비즈니스는 갈 수록 복잡해지고(요구사항이 많아짐) 기술 수명은 점점 짧아지며, 이러한 이유로 신/구(레거시) 기술이 공존하는 상황이다.

• 이러한 상황에서 성능이 가장 큰 문제점으로 부상하게 되는데 반도체 기술이 한계에 부딪혀서 인스턴스를 늘리는 방식(클라우드, 람다 아키텍처)이 각광 받고 있다. 이러한 인스턴스 늘리는 방식 중 최근 대두되고 있는 것이 마이크로 서비스이다.

• 마이크로서비스(MSA)란 독립적이고 단순한 서비스로 전체 서비스를 구성할 수 있게하는 아키텍처이다.  

• 참고 : 마이크로 서비스의 아홉가지 특징

• http://martinfowler.com/articles/microservices.html

마이크로서비스 설계시 고려사항들

• 하나의 서비스를 어떻게 설계할 것인가가 가장 중요하다. 전체적인 큰 그림을 그려봐야한다.

Monolithic Architecture

• 장점 : 심플한 구조, 간편한 코드 관리, 간편한 트랜젝션 관리, 설계/테스트가 간편

• 단점 : 고장에 대응하기 쉽지 않다. 개발/운영이 어려워짐, 확장성의 경우 스케일업 외엔 대응 방식이 없음, 신기술의 도입이 어려움

SOA와의 연관성

• Monolithic Architecture의 단점을 보완하기 위해 Service Orientation Architecture 등장

• msa는 soa와 개념적으로 크게 다르지 않고, 동일한 목표점을 갖고 있다.

• soa와 구분되기 위해 마케팅적 필요에 의한 선긋기를 위해 마이크로서비스라 이름 지었다고 한다. msa에는 soa의 성공, 실패의 노하우가 녹아있다.

Agile개발과 궁합이 잘 맞음

• 짧은 개발 주기

• 작은 개발팀의 중요성 - 창의적인 작업 시에 가장 적합하다.

• 10명 이상의 팀에서는 무임승차하는 사람이 생기기 쉽다

• 자율적인 팀 운영

• 아키텍처 선정

• 배포 주기

DDD(Domain-Driven Design) - 도메인 주도 설계

• 마이크로서비스를 구현하기에 앞서 설계하기 위해 필요한 유용한 개념 DDD.

• 추천 도서 : “Eric Evans의 Domain Driven Design”, 도메인 주도 설계

• DDD에서 얻을 수 있는 해법(책에서 다루는 내용)

• 어떤 단위로 서비스를 구성할 것인가

• 서비스의 결합

• 변화에 강한 설계

• 레거시 시스템을 단계적 폐기

• 리팩터링 전략

• Domain Model 정제과정의 예

• http://agiledata.org/essays/agileDataModeling.html

Docker

• 마이크로 서비스 설계시 고려사항들 중 성능 효율성, 신뢰성, 유지보수성이 도커와 직접적으로 관련이 있음

• 마이크로 서비스의 구성 예 (Netflix)

• VMs의 문제점

• 가상환경 서버라고는 해도 환경변수나 언어버전, 라이브러리 버전이 달라 어플리케이션이 동작을 하지 않는다.

• 개발 환경에서는 잘 움직이다가도 프로덕션 환경에서 제대로 움직이지 않는다.

• 기존환경의 가동을 중단시키지 않으면서도 새로운 어플리케이션이나 기능을 추가하는데 제약이 있다. (OS 업데이트시에 인스턴스 reboot가 필요)

• 가장 큰 문제는 VMs 자체가 오버헤드가 크다는 점이다.

• Docker란 VMs가 가진 문제점을 해결하기 위해 개발된 기술

• Linux Containers 호환 가상화 기술

• 컨테이너를 구동하기 위한 플랫폼

• 컨테이너란?

• 프로그램이 작동하기 위한 최소한의 요소들을 묶은 패키지

• Go 언어로 작성

• 다양한 통합 지원(대부분의 클라우드 서비스에서 지원)

• 도커 vs Vms 벤치마크 결과

• http://www.slideshare.net/Flux7Labs/performance-of-docker-vs-vms

• 기동과 종료시간에서 가장 큰 차이

• 도커는 1초 이내의 기동/종료

• VMs는 기동시 최소 30초 이상, 종료시 5초 이상의 시간이 걸림

• I/O 에서도 큰 차이

• SQL - 도커의 경우 네이티브에 근접한 속도

Docker의 이점

• 어플리케이션 중심으로 개발 할 수 있다.

• 한번의 빌드로 모든곳에서 동일한 작동을 보장한다.

• Git와 닮아 있는 이미지 버전 관리 기능

• 편리한 툴을 이용한 자동화(command line interface등)

• Docker Hub를 이용해 이미지를 자유롭게 공유

• https://hub.docker.com

Docker 맛보기

• Boot2Docker 설치(windows나 맥 사용 시 )

• https://github.com/boot2docker/windows-installer

• Virtual box를 이용해서 가상 머신을 띄우는 방식

• 도커이미지를 띄울 수는 있지만 빌드는 못함 ( 맛보기 용으로 사용)

• Vagrant를 이용한 Docker 이미지 실행

• Vargrant란? VM 관리용 툴 (VM판 maven)

Spring Boot

• Spring Framework를 이용해 어플리케이션을 간단하게 만들기 위한 플랫폼

• Rails의 영향을 받아 Spring에서 시작한 프로젝트, (Spring Roo, Spring Boot)

• Roo는 인기가 사그라들고 있는 상태

• Boot는 성공을 거두어가고 있는 상태

• 모던 Java 어플리케이션을 통해 간단하게 구축 가능

• 장점

• 미리 준비된 모던자바 어플리케이션 조합을 사용가능

• 짜여진 템플릿

• 의존 라이브러리를 포함시키는 것 만으로도 자동적으로 설정이 정해짐

• Spring, SQL, NoSQL, JMS …

• 임베디드 톰캣을 내장하여 간편하게 실행이 가능

• Production Jar 생성 기능 - 자동으로 실행 가능한 jar

• 간편하고 빠르게 작은 규모의 어플리케이션을 빠르게 개발/배포하는데 특화되어 있다.

• 톰캣보다 임베디드 톰캣을 사용하면 메모리 사용량을 적게 구성할 수 있다.

• maven, gradle을 통해 Spring boot 설정 가능

• @EnableAutoConfiguration - 마법의 어노테이션

• 자동으로 설정을 활성화

• 독립적인 웹서비스 구성

• 번거로운 Configuration을 간편하게 해줌

• Spring Boot 사용예 : Spring Cloud Config

• https://github.com/spring-cloud/spring-cloud-config

• 클라우드의 경우 많은 인스턴스들이 생성되기 떄문에 Configation을 파일로 관리하기엔 번거로움이 있어서 이러한 설정을 서버에서 가져오도록 하는 프로젝트

API gateway pattern

• 레거시 시스템과의 통합

• 로드밸런싱

• 테스트/목업

• 고장/예외/로깅 공통화

• API Aggregation(몇가지 서비스를 묶어서 하나의 서비스로 구성)

• 검증된 다양한 제품군(오픈소스, 상용소스 등)

• 제약사항 파악이 중요

• 성능, 트랜잭션 등에 제약사항이 있으므로 확인이 필요

• 참고 : http://microservices.io/patterns/apigateway.html

Reactive Microservices Architecture

• Functional Programming과 밀접한 관련이 있다.

• 동시성을 부작용 없이 다루는 기술

• 확장성과 깊은 관련을 가짐

• 동시성 프로그래밍에 스레드가 많이 사용되지만 공유데이터 등 여러 부작용이 생김.

• 관찰하기도 힘들고 재현하기도 힘듦 - 대응하기가 어려움

• Actor는 스레드보다 안전하게 동시성을 구현하기위해 제안된 모델

• 메시지를 자신 또는 다른액터에 전송

• 다른 액터를 생성

• 다른 액터에게 데이터 뿐만 아니라 행위 자체를 넘겨줄 수 있다.

• 액터는 메시지를 수신하기 위해 하나의 사서함을 가진다.(큐와 비슷, 하지만 들어온 순서대로 처리되는 것은 아님) 메시지는 액터에 직접 전달되지 않고 사서함에 간접적으로 전달된다. 사서함은 버퍼링 기능이 있으나 메시지는 FIFO로 처리되는 것은 아니다.

• 액터가 메시지를 받으면 일단 잠금상태가 된다. 잠기면 메시지는 처리 되지 않는다. 다음 액터가 become이 되면 새로운 후계 액터가 동일한 사서함에서 메시지를 읽고 처리를 계속한다.

• 이러한 이벤트들은 리얼타임에서 끊임없이 발생하고 있기 때문에 하나의 스트림으로 처리되게 된다.

• Optimizing the Netflix API

• Netfilx에서 reactive programming 에 대한 노하우를 게시

• http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

• Hystrix (넷플릭스에서 제공하는 오픈소스)

• Circuit Breaker 패턴

• 장애가 발생한 서비스에 계속 접속할 경우, 다른 서비스에도 장애가 전이되는 것을 막기 위해 일정시간 에러나 타임아웃이 지정한 수치를 넘어 발생하는 서비스에 대하여 서킷 브레이커를 발동시켜 사용 불가상태로 전환함

• 관련 프로젝트 : Reactive Extention (RX)

MSA 정리

• 설계의 어려움

• 대부분이 비동기로 처리되기 때문에

• 레거시 시스템과의 공존, 인터페이스 연계문제 ( 이를 해결하기 위한 해법으로 API gateway 사용)

• 운영오버헤드

• DevOps/NoOps (사람의 손으로는 끝이 없다. 자동화 되어야 한다. )

• 코드 중복

• 폴리그랏 프로그래밍으로 개발 할경우 발생할 수 있음.(JVM 또는 .NET상의 언어를 이용)

• 데이터 중복

• 분산시스템의 복잡성과 비동기성

• Reactive architecture, API gateway가 해법으로 제공될 수 있음

• 테스트의 까다로움

• API gateway, SOA Testing Techniques 를 참고