6. Choosing a Microservices Deployment Strategy - 02 Multiple Service Instances per Host Pattern

Nginx/01. MicroServiceArchitecture 2017/04/14 14:44 용비

Multiple Service Instances per Host Pattern
(호스트별 다중 서비스 인스턴스 패턴)

Microservice를 배포하는 한가지 방법은 하나의 Host에 여러 개의 서비스 인스턴스를 배포하는 패턴이다. 이 패턴을 사용할 때, 하나 이상의 실제 혹은 가상 호스트를 준비하고, 각 호스트에 여러 개의 서비스 인스턴스를 실행한다. 여러 면에서, 이것은 Application을 배포할 때 전통적인 접근법이다. 각 서비스 인스턴스는 하나 이상의 호스트에서 잘 알려진 포트로 동작한다. 호스트 컴퓨터는 마치 애완 동물처럼 다루어진다.

다음 다이어그램은 이 패턴의 구조를 보여준다.

사용자 삽입 이미지


이 패턴 기반 몇 가지 변형 패턴이 있다. 한가지 변형 패턴은 각 서비스 인스턴스가 하나의 프로세스나 프로세스 그룹이 되는 것이다. 예를 들면, Apache Tomcat 서버에 웹 어플리케이션으로 Java service instance를 배포할 수 있다. Node.js 서비스 인스턴스는 하나의 부모 프로세스와 하나 이상의 자식 프로세스로 구성될 수 있다.

다른 변형 패턴은 동일한 프로세스나 프로세스 그룹에서 여러 개의 서비스 인스턴스를 실행하는 것이다. 예를 들면, 하나의 Apache Tomcat 서버에 여러 개의 Java Web Application을 배포할 수 있다. 또는 동일한 OSGI 컨테이너에 여러 개의 OSGI 번들을 실행할 수도 있다.

Multiple Service Instance per Host 패턴에는 장단점이 모두 있다. 한가지 주요 장점은 리소스 사용이 상대적으로 효율적이라는 것이다. Multiple Service Instance가 서버와 OS를 공유한다. 프로세스나 프로세스 그룹이 여러 개의 서비스 인스턴스를 실행하는 경우에 훨썬 더 효율적이다. (예를 들어, 동일한 Apache Tomcat Server와 JVM을 여러 개의 웹 어플리케이션이 공유하는 경우)

이 패턴의 또다른 장점은 서비스 인스턴스를 상대적으로 빠르게 배포하는 것이다. 간단히 서비스를 호스트에 복사하고 시작하면 된다. 만약 서비스를 Java로 개발했다면, JAR나 WAR를 복사한다. Node.js나 Ruby와 같은 다른 언으로 개발했다면, 소스 코드를 복사한다. 어느 경우라도, 네트워크를 통해서 복사된 바이트 수는 상대적으로 작다.

또한 오버헤드가 없기 때문에, 서비스를 시작하는 것은 일반적으로 굉장히 빠르다. 서비스가 자체적으로 프로세스인 경우, 시작하기만 하면 된다. 그렇지 않을 경우에, 만약 서비스가 동일한 컨테이너 프로세스나 프로세스 그룹에서 실행되는 여러 개의 인스턴스 중 하나라면, 컨테이너에 동적으로 배포하거나 컨테이너를 재시작한다.

이러한 장점의 호소에도 불구하고, Multiple Service Instance per Host 패턴에는 몇 가지 중요한 단점이 있다. 한가지 주요 단점은 각 서비스 인스턴스가 분리된 프로세스가 아니라면, 서비스 인스턴스의 격리가 거의 혹은 전혀 없다는 것이다. (서로 영향을 주고 받아서 한가지 서비스 인스턴스의 오류가 인해 전체가 영향을 받음) 각 개별 서비스 인스턴스의 리소스 사용율을 정확하게 모니터링 할 수 있으나, 각 인스턴스가 사용하는 리소스를 제한할 수는 없다. 잘못 동작하는 서비스 인스턴스가 호스트의 전체 메모리나 CPU를 사용할 수도 있다.

여러 개의 서비스 인스턴스를 동일한 프로세스에서 실행하는 경우에는 격리가 전혀 없다. 예를 들면, 모든 인스턴스들은 동일한 JVM Heap을 공유한다. 오동작하는 서비스 인스턴스는 동일한 프로세스내 실행되고 있는 다른 서비스들을 쉽게 중단시킬 수 있다. 또한, 각 서비스 인스턴스가 사용하는 리소스를 모니터링할 방법도 없다.

이 접근법의 또다른 심각한 문제는 서비스를 배포하는 운영 팀이 어떻게 해야 하는지에 대한 상세한 세부 사항을 알고 있어야만 한다는 것이다. 서비스들은 다양한 언어와 프레임워크로 작성될 수 있기 때문에 개발팀이 운영팀과 공유해야만 하는 많은 세부사항들이 있다. 이러한 복잡성은 배포하는 동안 오류 발생 리스크를 증가시킨다. 보는 것처럼, 친숙함에도 불구하고 Multiple Service Instance per Host 패턴은 몇 가지 중대한 단점이 있다. 이제 이러한 문제들을 피하는 다른 Microservice 배포 방법에 대해 알아보자.
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/778

6. Choosing a Microservices Deployment Strategy - 01 Motivations

Nginx/01. MicroServiceArchitecture 2017/04/14 13:40 용비

Choosing a Microservices Deployment Strategy
(Microservice 배포 전략 선택)

이것은 Microservice로 Application을 작성하는 시리즈 중에서 여섯번째 글이다. 첫번째 글에서는 Microservice Architecture Pattern을 소개하고, Microservice 사용에 대한 장단점을 논의했다. 그 다음 글에서는 Microservice Architecture의 다양한 측면 : API Gateway 사용, 프로세스간 통신, 서비스 검색, Event-Driven 데이터 관리 등에 대해서 살펴보았다. 이번 글에서는 Microservice 배포 전략에 대해서 살펴보자.

Motivations
(동기)

Monolithic Application을 배포하는 것은 일반적으로 하나의 대용량 Application을 여러 개의 동일한 복사본으로 실행한다는 것을 의미한다. 일반적으로 N개의 서버(실제 혹은 가상)를 준비하고, 각 서버마다 M개의 Application 인스턴스를 실행한다. Monolithic Application 배포는 항상 전적으로 쉽지는 않지만, Microservice Application을 배포하는 것보다는 훨씬 간단하다.

Microservice Application은 수십 혹은 수백개의 서비스로 이루어진다. 서비스는 다양한 언어와 프레임워크로 작성된다. 각각의 서비스는 그 자체적인 배포, 리소스, 확장, 모니터링 요구사항을 가진 작은 응용프로그램(mini-application)이다. 예를 들어, 각 서비스에 대한 수요 기반으로 특정 개수의 서비스 인스턴스를 실행할 필요가 있다. 각 서비스 인스턴스는 적당한 CPU, Memory, I/O 리소스를 제공받아야 한다. 더 까다로운 것은 이러한 복잡성에도 불구하고, 서비스들의 배포는 빠르고, 안정적이고, 비용 효율적이어야 한다는 것이다.

몇 가지 다른 Microservice 배포 패턴이 있다. 먼저, Host별 다중 서비스 인스턴스 패턴(Multiple Service Instance per Host pattern)에 대해서 살펴보자.

TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/777

5. Event-Driven Data Management for Microservices - 04 Summary

Nginx/01. MicroServiceArchitecture 2017/04/14 13:05 용비

Summary
(요약)

Microservice Architecture에서는 각 마이크로서비스가 자체적으로 데이터 저장소를 가지고 있다. 다른 Microservice들은 서로 다른 SQL 및 NoSQL 데이터베이스를 사용할 수 있다. 이러한 데이터베이스 아키텍처는 상당한 장점이 있지만, 분산 데이터를 다루는데 있어서 관리 문제가 발생한다. 첫번째 과제는 여러 서비스들 간에 데이터 일관성을 유지하는 비즈니스 트랜잭션을 어덯게 구현하느냐는 것이다. 두번째 과제는 여러 서비스에서 데이터를 검색하는 쿼리를 어떻게 구현하는가이다.

많은 Application에서 해결책은 Event-Driven Architecture를 사용하는 것이다. Event-Driven Architecture를 구현하는데 있어서 한 가지 문제는 상태를 원자적으로 업데이트하고 이벤트를 게시하는 것이다. 데이터베이스를 메시지 큐로 이용하는 방법, 트랜잭션 로그 마이닝으로 이용하는 방법, 이벤트 소싱으로 이용하는 방법등을 포함하여 몇 가지 방법이 있다.

앞으로의 블로그 글에서는 Microservice의 다른 측면에 대해서도 깊이 들여다 볼 것이다.
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/776

◀ 이전페이지 1 ... 35 36 37 38 39 40 41 42 43 ... 216 다음페이지 ▶