Service Mesh 알아 보기

지난 몇년간 Micro Service Architecture는 많이 발전되어 왔습니다. 그리고 현 시점에 몇 가지 새로운 개념과 패턴이 등장하고 있습니다. 이 중 “Service Mesh” 개념은 많은 인기를 얻고 있습니다. 본 글에서는 Service Mesh와 관련된 주요 개념에 대해서 설명합니다.

Service Mesh의 등장 배경

현재까지 대부분의 사람들은 마이크로 서비스가 SOA/ESB와 같은 이전 아키텍처에서 가진 문제점들의 해답이라고 생각합니다. 그러나 실제 마이크로 서비스를 구현할 때, ESB가 지원하는 대부분의 기능들이 마이크로 서비스 수준에서 구현 가능하다는 것을 알 수 있습니다.

예를 들어서 여러 가지 다운 스트림 서비스를 호출하고 이 기능을 다른 서비스로 노출해야 하는 시나리오가 있습니다. 위의 그림에서 볼 수 있듯이 ESB 아키텍처(왼쪽)를 사용하면 서비스 간 통신 중에 Circuit Breaker, Timeout 및 Service Discovery등과 같은 기능을 구축하기 위해 ESB내에 내장된 기능을 쉽게 활용 할 수 있습니다.

Micro Service를 사용하여 동일한 시나리오는 구현한다고 하면, 중앙 집중 방식의 ESB가 아니라 Code Level에서의 마이크로 서비스가 제공됩니다. 따라서 마이크로 서비스를 하기 위해서는 이러한 모든 기능이 구현되어야 합니다.

위의 그림과 같이 상호간 통신하는 마이크로 서비스는 다음과 같이 구성됩니다.

• Business Logic, Process 및 서비스 구성
• Network Functions: OS의 네트워크 스택위에 구축(본 기능을 통해 기본 서비스 호출, 탄력성 및 안정성 패턴 적용, Service Discovery등을 적용)

ESB 대비하여 위의 그림처럼 마이크로 서비스를 구현하기 위해서 필요한 노력을 생각해보면 생각보다 심플하지 않습니다. 비즈니스 로직에 초점을 맞추기보다는 서비스 간 통신 기능을 구현하는 데 많은 시간을 투자해야 합니다. 또한 Polyglot 형태의 여러 프로그래밍 언어를 지원해야 할 경우에는 각 언어별로 노력을 들여야 하기 때문에 다중 기술을 사용하여 마이크로 서비스를 구현하는 것은 쉽지 않습니다.

마이크로 서비스 아키텍처 구현에서 가장 복잡한 부분은 서비스 자체를 구축하는 것이 아니라 서비스 간의 통신입니다.

마이크로 서비스간 커뮤니케이션의 요구 사항은 매우 일반적이기에 이러한 모든 작업을 다른 Layer에서 Offloading 하는 것에 대해서 생각해 볼 수 있습니다. 그래서 “Service Mesh”가 등장했습니다.

Service Mesh란 무엇인가?

Service Mesh는 서비스간 커뮤니케이션 인프라입니다. Service Mesh를 사용하게 되면 아래의 특징을 가질 수 있습니다.

• 마이크로 서비스는 다른 마이크로 서비스와 직접 통신하지 않습니다.
• 모든 마이크로 서비스간 통신은 Service Mesh(or Sidecar Pattern)를 통하게 됩니다.
• Service Mesh는 탄력성, Service Discovery등과 같은 일부 네트워크 기능을 기본적을 지원 합니다.
• Service Mesh를 이용하면 개발자는 비즈니스 로직에 더 집중 할 수 있으며 네트워크 통신과 관련된 대부분의 작업은 Service Mesh로 Offloading 하게 됩니다.
• 예를 들어서, 마이크로 서비스가 다른 서비스를 더이상 호출하지 않을 때 Circuit Breaker에 대해 걱정할 필요가 없습니다. 이 또한 Service Mesh의 일부로 제공되고 있습니다.
• Service Mesh는 프로그래밍 언어에 제약을 받지 않습니다. 마이크로 서비스는 항상 HTTP1.x/2.x, gRPC등과 같은 표준 프로토콜을 사용하기 때문에 이를 기반으로 마이크로 서비스를 작성 할 수 있습니다.

위의 그림에서 언급된 서비스 상호 작용 및 책임에 대해서 설명합니다.

비즈니스 로직

서비스 구현에 필요한 기능을 의미합니다.

기본 네트워크 기능

대부분의 네트워크 기능을 Service Mesh로 Offloading 할지라도 특정 서비스는 Service Mesh / Sidecar Pattern Proxy와 연결하기 위해 기본적인 네트워크 상호 작용 기능을 포함해야 합니다. 따라서 서비스 구현은 주어진 네트워크 라이브러리(ESB와 다르게 간단한 추상화를 사용)를 사용하여 네트워크 호출을 해야 합니다. (Service Mesh 전용)

어플리케이션 네트워크 기능

Circuit Breaker, Timeout, Service Discovery등과 같이 네트워크에 밀접하게 결합된 어플리케이션 기능이 존재합니다. 초기 마이크로 서비스를 구현할 경우에는 ESB Layer에서 제공되는 네트워크 기능을 무시하고 각 마이크로 서비스 수준에서 모든 기능을 처음부터 구현했습니다. 현 시점에서 분산형 Mesh와 비슷한 공유 기능을 갖는 것이 중요하다는 사실을 깨닫기 시작했습니다. 즉 서비스 코드/비즈니스 로직과 명시적으로 분리된 Service Mesh의 기능을 사용 할 수 있도록 합니다.

Service Mesh 제어 기능

모든 Service Mesh Proxy는 Control Plane에 의해 중앙에서 관리됩니다. Access 제어, Service Discovery등과 같은 Service Mesh 기능을 지원할 때 매우 유용합니다.

Service Mesh 기능

Service Mesh는 어플리케이션 네트워크의 기능을 제공하는 반면 일부 네트워크 기능은 여전히 마이크로 서비스 수준 자체로 구현됩니다. Service Mesh에서 어떤 기능이 제공되어야 하는지에 대한 규칙은 없습니다. 아래는 Service Mesh에서 가장 일반적으로 제공되는 기능입니다.

• Resiliency for inter communications: Circuit Breaker, Timeouts, Retries, Fail injection, fault handling, load balancing, failover
• Service Discovery: 전용 Service Registry를 통해 Service Endpoint를 검색
• Routing: 서비스 비즈니스 기능과 관련된 라우팅 제공
• Observability: Metrics, monitoring, distributed logging, distributed tracing 제공
• Security: TLS 제공 및 Key 관리
• Access Control: Blacklist/Whitelist 기반 Access 제어
• Deployment: Container 배포 지원
• Interservice communication protocols: HTTP1.x, HTTP2, gRPC 제공

Servie Mesh 구현체

Linkerd 및 Istio와 같은 오픈소스 구현체가 존재합니다. 여기에서 둘 간의 차이를 확인하세요.

Service Mesh 장단점

장점

• 마이크로 서비스 코드 외부에서 구현되기에 다양한 프로그래밍 언어도 지원하고 재사용 가능합니다.
• Ad-hoc 솔루션을 사용한 마이크로 서비스 아키텍처의 대부분의 문제를 해결합니다: Distributed tracing, logging, security, access control등
• 다양한 프로그래밍 언어 지원: 특정 언어가 네트워크 어플리케이션 기능을 구축 할 수 있을지 또는 라이브러리가 지원되는지에 대해 걱정이 없습니다.

단점

• 복잡성: Service Mesh를 사용하면 런타임 인스턴스 수가 증가합니다.
• Extra hop 추가: 각 서비스 호출은 Service Mesh의 Sidecar Proxy를 통해서 호출되어야 합니다.
• Service Mesh는 서비스 간 통신 문제를 다루지만 복잡한 라우팅, Mediation등의 기능을 제공하진 않습니다.

결론

Service Mesh는 마이크로 서비스 아키텍처의 구현과 관련하여 주요 과제중 일부를 해결 합니다. 그리고 다양한 마이크로 서비스 구현 기술 집합을 선택할 수 있고 서비스 간 네트워크 기능을 지원해주므로써 개발자는 비즈니스 로직에 더 집중 할 수 있습니다. 그러나 Service Mesh는 비즈니스 로직과 관련된 서비스 통합 문제를 해결하지는 못합니다.

References: https://medium.com/microservices-in-practice/service-mesh-for-microservices-2953109a3c9a

Read More

GraphQL로 BFF 대체하기

 

위의 그림에서 BFF의 목적은 Orchestration, Business Logic을 공유하고 Backend 서비스가 제공하는 것보다 UI에 친화적인 모델을 제공하는 것입니다. 그래서 각 클라이언트별로 BFF가 존재하게 됩니다. Netflix는 Client Adapter라는 이름으로 SoundCloud는 BFF라는 이름으로 UI에 친화적인 Backend 서비스를 제공하고 있는데, 이런 BFF에도 문제점이 존재합니다.

• 업무 조직간 교차 관리가 어렵습니다.
• Traffic에 대한 용량 사이징을 예측하기 어렵습니다.
• 단일 실패 지점이 될 가능성이 존재합니다.
• 추가적인 아키텍처 복잡성이 발생합니다.

다른 접근 방법은 클라이언트가 서비스를 제공하거나 Backend와 직접 상호 작용을 하는 것입니다.

위의 그림처럼 BFF를 걷어내면 심플해보이는 장점이 있지만, 여전히 BFF와 공통된 문제점이 존재합니다. Application Server는 PC, Mobile의 데이터 요구를 구별해야 하며 각 클라이언트별로 API가 달라질 가능성이 존재합니다.

GraphQL을 써보자

이러한 상호 작용을 깔끔하게 하고 최종 사용자에게 더 나은 서비스를 제공하기 위해서 GraphQL을 사용해 볼 계획을 가지고 있습니다. GraphQL은 API Graph에서 구성 요소를 관리하는 복잡성에 대처할 수 있도록 Facebook에서 개발했습니다.

GraphQL을 사용하면 UI가 데이터와 선언적으로 상호 작용할 수 있으며 서버에서 UI를 분리 할 수 있습니다. UI에서 필요한 데이터를 지정하기에 UI에 친화적인 API를 구축하는 것에 대해 고민할 필요가 없습니다. 또한 GraphQL은 일반적인 AJAX 요청보다 더 쉽게 최적화되기에 Request 개수가 줄어들게 됩니다.

앞으로는 GraphQL이 주류가 될 것입니다. Amazon의 AppSync 혹은 Graphcool 같은 서비스가 주류가 되는데에 일조 할 것으로 보여집니다.

Read More

Simple Work., 단순하게 일하기

 

애플의 스티브 잡스와의 회의는 힘든 여정이었다고 합니다. 회의 가 끝난 후 안좋은 표정으로 회의실을 나서는 직원들에게 무슨일이 있냐고 물어보면 “Simple Stick으로 맞았다.”라고 얘기한다고 합니다. 스티브 잡스는 비효율적인 회의, 프로젝트라고 판단될 경우 바로 중단을 시키거나 없애버렸다고 합니다. 이런 스티브 잡스의 Simple Stick이 오늘의 Apple을 만든 원동력이라고 평가되고 있습니다. 모든 업무를 단순화 하여 “세상을 바꿀 수 있는 제품과 서비스를 만들자”라는 핵심 가치에 다가서기 때문입니다.

아마존의 사명은 “클릭 한번이면 된다.”입니다. 사실 클릭이 몇 번 필요하긴 하지만 제프 베조스는 이 문장으로 고객이 얻을 수 있는 가치를 설명하고 있습니다.

이러한 회사들의 사명 혹은 리더들의 스타일은 해당 기업의 조직 문화로 이어지게 됩니다. 조직 문화는 추상적으로 받아들여지기 쉽지만, 추상적이라기 보다는 직원들이 이해하고 달성하기 위해 함께 노력해 나가는 것입니다. 이 문화를 이루기 위해 직원들을 설득 하고 이끌어 나가는 것이 리더의 역할입니다.

스티브 잡스와 제프 베조스같은 리더들은 괴짜처럼 보여지기도 하고 냉혹해보이기도 합니다. 이렇게 보이는 것은 그들이 지닌 가치관에 따라 결정하기 때문입니다. 이 가치관에 벗어나는 그 어떤 것에도 타협하지 않기 때문입니다. 작업 수준이 낮으면 다시 만들어야 하고 속임수를 쓰지 않습니다. 좋은 말로 사람을 현혹하지도 않습니다. 현실을 알고 그 상황을 객관적으로 판단 합니다. 남들의 기분을 생각해서 애매하게 말하지 않습니다. 이들은 좋고 싫고가 명확하고 일관성이 있습니다. 그래서 괴짜, 냉혹한으로 보여지기도 합니다.

그리고 이들은 직접 일을 챙기기 때문에 조직을 단순화 시켜 직접 챙기거나 적임자를 배치합니다. 적임자에게는 책임과 권한을 부여하여 철저히 믿고 일을 맡깁니다. 그리고 업무 프로세스를 최대한 단순화 합니다. 그리고 단순화된 업무 프로세스에서 일할 직원을 채용하는데에 심혈을 기울입니다.

스티브 잡스의 경우 직원을 뽑을 때, 엄청 공을 들인다고 합니다. 그의 평가 기준은 “세상을 변화 시킬 수 있는 사람인가”입니다. 그리고 면접자에게 질문을 한다고 합니다. “당신은 세상을 바꾸기 위해 무엇을 했습니까?” 그동안 해왔던 경력을 얘기하던 우리의 면접과정과는 많은 차이가 있지요.

이렇게 직원들을 뽑아 프로젝트에 투입하고 단순화된 프로세스내에서 업무를 수행합니다. 애플의 경우, 프로젝트의 결과물을 검증하지 않는다고 합니다. 우리는 일반적으로 시장에 제품을 내놓기 전에 무수히 많은 시험을 했는데 말이죠. (물론, 제품의 퀄리티를 위한 품질 관리, 테스트는 하겠지요;;) 결과물을 검증하지 않는다는 말의 의도는 이렇습니다. 할 수 있는 일이 아니기 때문이기 때문입니다. 시장이 검증해야 한다는 의미지요.

이런 단순함이 고객에게도 영향을 미칠까요? 만약 고객에게 많은 선택권을 주면 고객이 좋아 할까요? 좋아하지 않는다고 합니다. 옵션이 많을 수록 잘 결정한 것인지에 대해 의문을 갖게 만든다고 합니다. 그럼에도 많은 기업들은 많은 옵션을 내놓고 있습니다. 시장의 심리를 파악하기가 어렵기에 많은 선택권을 주는 것이지요. 반면 애플은 라인업이 간단합니다.

단순하게 일한다는 것은 일을 대충한다는 의미는 아닙니다. “똑똑한 소수 정예”들을 통해 구체적으로 일한다는 의미입니다. 그리고 조직 문화도 단순하게 세팅이 되어야 하고요.

물론, 단순함을 추구한다는 것은 더 적은 인력을 효율적으로 일한다는 것을 의미하기에 구조조정을 겪기도 합니다. 하지만 맞는 사람들을 적절히 배치한다는 점에서 기업이 성공 확률이 높아진다고 생각됩니다.

당신은 단순한 조직에서 단순하게 일하고 있습니까?

Read More

Netflix Vizceral

Vizceral은 Netflix Control Plain으로 유입되는 트래픽 상태에 대한 정보를 이해하는 방식을 변화 시켰다고 합니다. Netflix의 경우 전체 시스템의 상태에 기반한 의사결정을 내리기를 원했고 이를 위해서 전체 시스템의 상태에 대해 직관적으로 이해할 수 있는 도구가 필요했습니다. Netflix의 경우 데이터 구문 분석에 의존하는 대신 직관적인 방법을 적용하기로 했습니다. 장애로 인해 수백만명이 영향을 받는 시간을 최소화 하는 방안을 고려했고 이를 Intuition Engineering이라고 부르며 Vizceral이 그 대표적인 예입니다.

아래의 영상은 지역 간 트래픽 이동시 전체적인 모습을 시뮬레이션한 모습입니다.

Netflix의 트래픽 팀에서는 Intuition Engineering의 중요성을 입증 한 후 다양한 의견을 통해서 사회에 공헌 차원에서 오픈 소스 프로젝트로 유지 관리해야 한다는 결정을 했습니다. 그들이 공개한 소스는 아래와 같습니다.

• vizceral: 그래프 데이터를 보고 상호 작용할 수 있는 기본 UI 구성 요소
• vizceral-react: 시각화를 쉽게 할수 있는 Wrapper
• vizceral-component: 웹 구성 요소를 사용하여 시각화를 돕는 Web Component Wrapper
• vizceral-example: 예제 프로젝트

이외에 Netflix는 내부적으로 Atlas 및 Salp로 부터 데이터를 수집하는 서비스를 제공하고 있고 이 서비스는 vizceral 구성 요소에 필요한 형식으로 데이터를 변환하고 웹 소켓을 이용해 UI를 업데이트 합니다.

아래는 특정 지역에 대한 세부 트래픽을 보여주는 영상입니다.

특정 지역을 클릭하면 해당 지역에서 운영되는 마이크로 서비스의 확대 보기가 나타납니다. 보기 좋게 하기 위해 노드간 연결을 단일 차선으로 최소화 하였고 황색과 빨간색 점이 서비스간에 오류 응답을 표시합니다.

서비스를 더 자세히 보고 싶으면 노드위에 마우스를 오버하여 입력 및 출력을 표시할 수 있습니다.

노드를 클릭하면 컨텍스트 패널이 보여지며 관련 정보를 입력 할 수 있습니다.

vizceral을 이용하는 방법은 vizceral-example 프로젝트의 지침을 따르는 것이 가장 빠릅니다.

Source: https://medium.com/netflix-techblog/vizceral-open-source-acc0c32113fe

Read More

MSA(마이크로 서비스 아키텍처)에서 단일 데이터베이스를 분리해야 하는 이유

기존 Monolithic 서비스를 분해하여 Micro Service 아키텍처를 사용할 경우 데이터베이스에 중점을 두는 것이 중요합니다. 어플리케이션과 연계된 데이터베이스를 여러개의 작은 데이터베이스로 분할하는 확실한 전략이 필요합니다.

즉, 기존에 사용하던 Monolithic의 통합 데이터베이스를 분리해야 합니다.

마이크로 서비스 아키텍처는 각 마이크로 서비스가 자체 도메인 데이터가 있는 별도의 데이터베이스를 가지도록 설계해야 합니다. 이렇게 해야 마이크로 서비스를 독립적으로 배포하거나 확장 할 수 있기 때문입니다.

기존 Monolithic 서비스에는 단일 데이터베이스가 있고 데이터는 다른 컴포넌트간에 공유됩니다. 데이터가 단일 저장소에 관리되기 때문에 개발이 더 간단하다는 장점이 있지만, 데이터베이스 설계에는 여러 가지 문제가 존재합니다.

단일 데이터베이스 설계의 문제점

위의 그림처럼 Monolithic 데이터베이스를 사용하는 설계는 서비스 변경 사항을 독립적으로 배포 할 수 없도록 상호간의 밀접한 결합 방식을 통해 무능력하게 만듭니다. 동일한 데이터베이스에 엑세스하는 여러 서비스가 있는 경우 모든 서비스간에 스키마 변경 사항을 조정해야 합니다.(어디서 어떤 데이터를 사용하는지 알 수 없기에…) 변경 사항을 적용 할 때 추가 작업에 대한 지연이 발생할 가능성이 큽니다.

단일 데이터베이스를 수평 확장 할 수 있는 옵션만 있기에 어플리케이션 단에서 개별 서비스를 확장하는 것이 어렵습니다.

어플리케이션 성능을 향상 시키고자 할때, 단일 데이터 베이스를 사용하면 여러 개의 큰 테이블을 조인하여 필요한 데이터를 가져와야 하기에 데이터 검색이 어려워집니다.

그리고 가장 큰 문제는 모든 어플리케이션에서 관계형 데이터베이스만 사용하도록 제한하게 됩니다. No-SQL 데이터베이스가 특정 서비스에 더 적합할 수 있어도 제한으로 인해 사용할 수 없게 됩니다.

마이크로서비스 아키텍처에서 데이터를 처리하는 방법

각 마이크로 서비스는 자체 데이터베이스를 가지고 있어야 하며 해당 마이크로 서비스와 관련된 데이터를 모두 포함해야 합니다. 이렇게 하면 각 서비스를 독립적으로 배포 할 수 있습니다. 각 서비스마다 독립적인 데이터베이스를 소유할 수 있게 됩니다.

마이크로 서비스의 설계 사상은 도메인 기반이어야 하며 한정된 컨텍스트를 가져야 합니다. 데이터 우선 접근 방식보다 코드 우선 접근 방식을 따라야 합니다. 따라서 가장 먼저 모델을 설계해야 합니다. 이 작업은 새로운 요구 사항이나 프로젝트를 시작할 때 데이터베이스 테이블을 먼저 설계하는 전통적인 사고 방식과는 근본적으로 다른 접근법입니다. 항상 비즈니스 모델의 무결성을 유지하려고 노력해야 합니다.

데이터베이스를 디자인할때 어플리케이션 기능을 살펴보고 관계형 스키마 필요 여부를 결정해야 합니다. No-SQL에 대한 가능성도 열어 두어야 합니다.

데이터베이스는 각 마이크로 서비스에 대해 개별적으로 취급되어야 합니다. 다른 마이크로 서비스는 다른 마이크로 서비스의 데이터베이스 내부에 저장된 데이터를 직접 수정할 수 없습니다.

아래의 그림에서 Order Service는 가격 데이터베이스를 직접 업데이트 할 수 없으며 해당 마이크로서비스의 API를 통해서만 엑세스가 가능해야 합니다. 이를 통해 서로 다른 서비스간에 일관성을 유지할 수 있습니다.

이벤트 중심 아키텍처는 서로 다른 서비스간에 데이터 일관성을 유지하는 패턴입니다. 작업을 완료하고 시스템 리소스를 차지하기 위해 ACID 트랜잭션을 기다리는 대신 메세지를 대기열로 Offload하여 어플리케이션을 보다 유용하고 효율적으로 만들 수 있도록 고려 해야 합니다. 이는 서비스 간의 Loosely Coupled를 제공합니다.

Queue에 대한 메시지를 이벤트로 처리 될 수 있으며 Pub-Sub 모델을 사용할 수 있습니다.

Monolithic에서 마이크로서비스로의 여정중 데이터베이스 변경 사항을 처리하는 것은 쉽지 않지만, 꼭! 넘어야 하는 부분입니다.

Source: https://dzone.com/articles/breaking-the-monolithic-database-in-your-microserv

Read More

Netflix OSS — Eureka 2.0

 

What is Eureka?

Eureka는 중간 계층 서버의 로드 균형 조정 및 장애 조치를 위한 REST기반 서비스이다. Eureka는 Java 기반 클라이언트 구성 요소인 Eureka Client가 함께 제공되므로 서비스와의 상호 작용이 훨씬 쉬워진다. 또한 클라이언트에는 기본 Round Robin 알고리즘 및 기본 제공 로드 밸런싱 알고리즘이 존재한다.

What is the need for Eureka?

AWS 클라우드에서는 IP 주소와 host name으로 작동하는 기존 로드 밸런서와 달리 서버 등록 및 등록 취소 작업을 정교하게 수행해야 하는 로드 밸런서가 필요하다. AWS는 미들 티어 로드 밸런서를 제공하지 않으므로 미드 티어 로드 밸런싱을 직접 구비할 필요가 있다.

How different is Eureka from AWS ELB?

AWS ELB는 최종 사용자의 웹 트래픽에 노출된 Edge Service용 로드 밸런싱 솔루션이다. Eureka는 미드 티어 로드 밸런싱용이다. 이론적으로 AWS ELB 뒤에 중간 계층 서비스를 배치 할 수 있지만 EC2 클래식에서는 AWS 보안 그룹의 모든 유용성을 잃어 버리고 외부 세계에 노출될 수 있는 문제점이 존재한다.

AWS ELB는 전통적인 Proxy 기반 로드 밸런서이기도 하지만 Eureka에서는 로드 밸런싱이 인스턴스/서버/호스트 수준에서 발생한다는 점이 차이점이다. 클라이언트 인스턴스는 연동할 모든 서버에 대한 정보를 알고 있어야 한다.

Eureka를 사용하여 로드 밸런싱과 Proxy기반의 로드 밸런싱을 차별화하는 또 다른 측면은 사용 가능한 서버에 대한 정보가 Client에 Cache되므로 어플리케이션이 로드밸런싱 장애에 대해 복원력을 가질 수 있다라는 점이다.

How different is Eureka from Route 53?

Route 53은 DNS 레코드를 호스팅 할 수 있는 DNS 서비스이다. Eureka는 내부 DNS와 유사하지만 전 세계 DNS서버와 관련이 없다. Eureka는 다른 AWS 지역의 서버에 대해 알지 못한다.(지역 분리) 정보를 보유하는 유일한 목적은 한 지역내의 로드 밸런싱을 위한 것이다.

미드 티어 서버를 Route 53에 등록하고 AWS 보안 그룹을 사용하여 공용 엑세스에서 서버를 보호 할 수 있지만 미드 티어 서버 ID는 여전히 외부 세계에 노출되어 있다. 또한 Traffic이 건강하지 않거나 존재하지 않는 서버로 라우팅 될 수 있는 전통적인 DNS 기반 로드 밸런싱은 단점이 존재한다. (서버가 언제든지 사라질 수 있는 클라우드의 경우)

How is Eureka used at Netflix?

Netflix에서 Eureka는 미드 티어 로드 밸런싱에서 중요한 부분을 차지하지만 다음과 같은 목적으로 사용된다.

• Netflix Asgard를 사용하는 red/black 배포의 경우 Eureka는 Asgard와 상호 작용하여 문제가 발생했을때 신속하고 원할하게 이전/신규 릴리즈 전환이 가능하다.
• 여러가지 이유로 서비스에 대한 추가 어플리케이션 관련 메타 데이터를 전달하는 용도로도 사용한다.

High level architecture

위의 아키텍처는 Eureka가 Netflix에서 어떻게 사용되는지를 보여 주는 일반적인 방법이다. 해당 지역의 인스턴스에 대해서만 알고 있는 Eureka Cluster가 하나 존재한다. 어플리케이션 서비스를 Eureka에 등록한 다음 30초마다 갱신하기 위해 Heartbeat를 보낸다. 클라이언트가 임대를 몇 번 갱신 할 수 없으면 약 90초내에 서버 레지스트리에서 제거된다. 등록 정보와 갱신은 클러스터의 모든 유레카 노드에 복제된다. 모든 영역의 클라이언트는 레지스트리 정보(30초마다 발생)를 찾아 해당 서비스를 찾고 원격 호출을 할 수 있다.

Non-Java services and clients

Java 기반이 아닌 서비스의 경우 서비스 언어로 Eureka의 클라이언트 부분을 구현 할 수 있고 등록을 처리하는 Eureka 클라이언트가 내장된 Java 프로그램을 실행 할 수 도 있다. Java가 아닌 클라이언트는 REST를 사용하여 다른 서비스에 대한 정보를 Query할 수 있다.

Configurability

Eureka를 사용하면 클러스터 노드를 즉시 추가하거나 제거 할 수 있다. 시간 제한 부터 Thread pool까지 내부 구성을 조정할 수 있다.

Monitoring

Eureka는 성능, 모니터링 및 경고를 위해 Servo를 사용하여 클라이언트와 서버 모두에서 정보를 추적한다. 데이터는 JMX 레지스트리에서 사용할 수 있으며 AWS Cloud Watch로 보낼 수 있다.

Architecture Overview

Eureka 2.0은 클라우드 구축을 위해 설계된 Service Discovery Framework이다.

아래 그림은 일반적인 Eureka 2.0의 주요 구성 요소를 나타낸다.

Write Register는 Client 등록을 처리하고 내부 서비스 Registry를 관리하고 유지하는 상태 저장 시스템이다. Registry의 내용은 모든 Write Server Node간에 일관성 있게 복제된다. Write Registry의 내용은 Eureka Client가 사용하는 Read Cluster에서 읽게된다.

Read Cluster는 Cache 계층이기 때문에 Traffic Volume에 따라 쉽게 빠르게 확장 및 축소될 수 있다. Write Cluster는 Peak time의 Traffic을 처리할 만큼 충분한 용량을 미리 산정해서 준비해야 한다.

Client Registration

Eureka Client는 Registration, Heartbeat 및 Update를 통해 Discovery 되도록 할 수 있다. Registration에는 검색 가능한 식별자 및 서비스 상태 그리고 자유로운 메타 데이터가 포함된다. 이러한 작업을 담당하는 Eureka 2.0 서버는 Write Cluster로 구성된다.

단일 Client는 여러 서비스 인스턴스를 등록할 수 있다. 가상화된 환경에서 Network stack을 100% 신뢰할 수 없기 때문에 연결의 유효성을 결정하는데에 Heatbeat를 사용한다. 연결이 끊어지면 Write Cluster Registry의 등록 항목이 추출 대기열에 들어가고 궁극적으로 Registry에서 제거됩니다. 정상 동작인 Client는 연결을 해제하기 위해서는 항상 등록 취소 요청을 보내야 한다. 등록 후에 Client는 인스턴스 데이터를 변경하면서 원하는 수의 업데이트 요청을 전송 할 수 있다.

Registry Discovery

Eureka Client는 세트에 가입할 수 있다. 성공적인 Subscription 후에 모든 변경 사항이 서버에 의해 Client에 push된다. 이러한 작업을 담당하는 Eureka 서버는 Read Cluster를 구성한다.

Service registry data model

Eureka 2.0은 서로 다른 클라우드 공급자 및 데이터 센터에서 작동하도록 설계되었고 현재 또는 미래의 배치를 수용할 수 있도록 기본 데이터 모델을 확장하도록 설계되었다. 기본 데이터 센터 모델 및 Amazon AWS / VPC 클라우드가 지원된다.

사전 정의 된 서비스 인스턴스 속성 세트는 메타 데이터 맵에 추가 할 수 있는 Key / Value 구조의 사용자 정의 세트를 통해 확장할 수 있다. Network Topology는 미리 정의되지 않는다. 따라서 간단한 공용/개인 IP 모델이 AWS 배포에 제공되지만 VPC에는 다중 NIC/ENI가 지원된다.

Interest subscription model

구독 모델은 사전 정의된 클래스 집합으로 구성된다.

• application interest — 주어진 어플리케이션에 속한 모든 서비스 인스턴스
• vip interest — 특정 Eureka 가상 주소(vip)에 속한 모든 서비스 인스턴스
• instance id — 지정된 ID를 가지는 특정 인스턴스
• full registry — Registry의 모든 항목을 나타내는 특수한 관심 유형(대규모 레지스트리의 경우 막대한 트래픽을 생성할 수 있으므로 거의 사용하지 않아야 함)

어플리케이션/VIP/Instance ID interest에는 연결된 운영 Rule이 있어야 하며 허용되는 값은 다음과 같다.

• Equals — 정확히 제공한 값과 일치
• Like — 관심 값을 정규 표현식으로 취급

Dashboard

Eureka 2.0 Dashboard는 Eureka Cluster 관리/모니터링을 위한 선택적 구성 요소이다. 특정 인스턴스로 드릴 다운하여 쉽게 문제를 해결하거나 시스템 진단을 수행할 수 있는 수준의 Dashboard를 제공한다.

CAP theorem

CAP 정리 관점에서 Eureka의 Write Cluster는 AP 시스템이고(고가용성 및 파티션 허용). 이 선택은 클라우드 기반 검색 서비스의 기본 요구 사항에 의해 결정됩니다. 클라우드에서 특히 대형 배치의 경우 장애는 항상 발생한다. 이것은 Eureka 서버 자체, 등폭된 클라이언트 또는 네트워크 파티션에서 문제가 발생한 것일 수 있다. 이러한 모든 상황에서 Eureka는 Registry 정보를 제공하고 사용 가능한 각 노드에서 새등록을 격리하여 사용할 수 있어야 한다. Eureka는 가용성을 선택하기 때문에 이러한 시나리오의 데이터는 노드간에 일관성이 없다. 이 모델은 레지스트리 데이터가 항상 일정 수준 이상 유지되도록하기 때문에 적절한 클라이언트 측 로드 균형 조정 및 장애 조치 매커니즘으로 보완되어야 한다.(e.g. Ribbon)

sources: https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

Read More