마이크로 서비스 아키텍쳐 12

MSA에서 Service discovery 패턴

MSA에서 Service discovery 패턴의 이해 조대협 (http://bcho.tistory.com) MSA와 같은 분산 환경은 서비스 간의 원격 호출로 구성이 된다. 원격 서비스 호출은 IP 주소와 포트를 이용하는 방식이 되는다. 클라우드 환경이 되면서 서비스가 오토 스케일링등에 의해서 동적으로 생성되거나 컨테이너 기반의 배포로 인해서, 서비스의 IP가 동적으로 변경되는 일이 잦아졌다. 그래서 서비스 클라이언트가 서비스를 호출할때 서비스의 위치 (즉 IP주소와 포트)를 알아낼 수 있는 기능이 필요한데, 이것을 바로 서비스 디스커버리 (Service discovery)라고 한다. 다음 그림을 보자 Service A의 인스턴스들이 생성이 될때, Service A에 대한 주소를 Service regi..

Circuit breaker 패턴을 이용한 장애에 강한 MSA 서비스 구현하기 #2 - Spring에서 Circuit breaker 구현

Circuit breaker 패턴을 이용한 장애에 강한 MSA 서비스 구현하기 #2Spring을 이용한 Circuit breaker 구현 조대협 (http://bcho.tistory.com) 앞의 글에서는 넷플릭스 Hystrix를 이용하여 Circuit break를 구현해보았다.실제 개발에서 Hystix로 개발도 가능하지만, 보통 자바의 경우에는 Spring framework을 많이 사용하기 때문에 이번 글에서는 Spring framework을 이용한 Circuit breaker를 구현하는 방법을 알아보도록 한다. 다행이도 근래에 Spring은 넷플릭스의 MSA 패턴들을 구현화한 오픈 소스들을 Spring 오픈 소스 프레임웍안으로 활발하게 합치는 작업을 진행하고 있어서 어렵지 않게 구현이 가능하다. 구현..

Circuit breaker 패턴을 이용한 장애에 강한 MSA 서비스 구현하기 #1 - Circuit breaker와 넷플릭스 Hystrix

Circuit breaker 패턴을 이용한 장애에 강한 MSA 서비스 구현하기 #1 Circuit breaker와 넷플릭스 Hystrix조대협 (http://bcho.tistory.com)MSA에서 서비스간 장애 전파마이크로 서비스 아키텍쳐 패턴은 시스템을 여러개의 서비스 컴포넌트로 나눠서 서비스 컴포넌트간에 호출하는 개념을 가지고 있다. 이 아키텍쳐는 장점도 많지만 반대로 몇가지 단점을 가지고 있는데 그중에 하나는 하나의 컴포넌트가 느려지거나 장애가 나면 그 장애가난 컴포넌트를 호출하는 종속된 컴포넌트까지 장애가 전파되는 특성을 가지고 있다. 이해를 돕기 위해서 아래 그림을 보자 Service A가 Service B를 호출하는 상황에서 어떤 문제로 인하여 Service B가 응답을 못하거나 또는 응답 ..

Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #2 - Spring과 Zipkin을 이용한 추적

Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #2 Spring Sleuth를 이용한 Zipkin 연동 조대협 (http://bcho.tistory.com) 앞글에 이어서 이번에는 실제로 어플리케이션에서 분산 로그를 추적해보도록 한다.스프링 부트 애플리케이션을 Zipkin과 연동하기 위해서는 Sleuth라는 라이브러리를 사용하면 된다.구조우리가 구현하고자 하는 예제의 구조는 다음과 같다. API Client는 User 서비스를 호출하고, User 서비스는 Item 서비스를 호출하여 사용자의 Item 정보를 리턴 받아서 리턴 받은 내용을 API Client에 호출한다.User와 Item 서비스는 모두 Spring Boot 1.5 버전으로 개발하였다. Spring 2.0은 아직 나온지가 얼마되지..

Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #1

Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #1조대협 (http://bcho.tistory.com) 개념분산 트렌젝션이랑 여러개의 서비스를 걸쳐서 이루어 지는 트렌젝션을 추적하는 기능을 정의한다.마이크로 서비스 아키텍쳐 (이하 MSA)와 같은 구조에서는 하나의 HTTP 호출이 내부적으로 여러개의 서비스를 거쳐서 일어나게 되는데, 그러면 어느 구간에서 병목이 생기는지 추적하기가 어려워진다.아래 그림을 보면 클라이언트가 Service A를 호출하고, Service A 가 Service B,D 를, Service B가 Service C를 호출한다. 이렇게 트렌젝션이 여러 컴포넌트의 조합을 통해서 발생하기 때문에 Jennifer와 같은 전통적인 APM (Application Performance..

다양한 라우팅 기능을 제공하는 구글의 클라우드 로드 밸런서

구글 클라우드 로드밸런서 소개조대협 (http://bcho.tistory.com) 클라우드 플랫폼에서 가장 필요한 기능중의 하나가 로드밸런서이다.그중에서 구글 클라우드의 로드밸런서는 L7 스위치 이상의 기능을 가지면서 로드밸런서와 api gateway의 일부 기능을 수행할 수 있는데, 어떤 특징이 있는지 살펴보자. (개인적인 생각이지만 이게 정말 물건이다..)HTTP 프로토콜 지원TCP,UDP 뿐 아니라 HTTP 레이어의 로드밸런싱을 지원한다. HTTPS Termination을 당연히 지원하고 HTTP 모드로 부하분산을 할 경우 HTTP URI에 따라 다양한 라우팅을 할 수 있다.No warming다른 클라우드 로드밸런서와는 달리 트래픽이 갑자기 많이 들어오더라도 별도의 워밍업작업 없이 트래픽을 받을 수..

사람이 최대한 관계를 유지할 수 있는 숫자는 150명이다. (Dunbar's law)

Dunbar’s law - 인간의 인맥은 150명 까지 가능하다. 조대협 (http://bcho.tistory.com) 어제 API 아카데미의 Amunsen의 강의중에, MSA 아키텍쳐에서 적절 팀 사이즈에 대해서 재미있는 학문적인 근거가 언급되어서 기록해놓는다. 던바의 법칙 (Dunbar’s law)이라는 건데, 던바는 옥스퍼드 대학의 인류학자로 인간의 사교성을 연구하던중, 인간이 맺을 수 있는 인간관계의 수에 대한 연구이다.http://terms.naver.com/entry.nhn?docId=2847498&cid=56774&categoryId=56774 이 연구에 따르면, 인간관계에 대해서 사람은 친밀도에 대해서 크게 4가지 단계로 인간관계가 분류된다.Intimate friends 5Trusted f..

비지니스 2016.02.25

마이크로서비스 아키텍쳐(MSA)는 선택이 아니라 필수다

마이크로서비스 아키텍쳐에 대한 소고 간만에 낚시성 제목을 달아봤는데, MSA (마이크로 서비스 아키텍쳐)가 필수라는 이야기는 꼭 틀린말이라고 볼 수 는 없습니다. 특히나 개발팀의 규모가 큰 경우나, 지리적으로 개발팀이 나눠져 있는 경우에는 서비스 단위로 나눠서 각 팀이 서비스를 개발하고, 독립된 기술과 개발 체계를 가지면서 빠르게 개발해 나가는게 효율적이기 때문에, 규모가 어느정도 되는 팀에서는 효율성이 높습니다. 중앙에서 통제할 필요 없이, 각자가 알아서 설계하고, 만들고, 테스트 하고 운영하기 때문입니다.이것을 분산 거버넌스라고 하는데, 관리나 의사결정의 권한을 중앙의 팀이 중앙 통제하지 않고, 각자의 팀에 자율적으로 맏기고, 책임도 맏긴다는 이야기 입니다. 그러면 분산 거버넌스를 하면,중앙 거버넌스..

MSA 아키텍쳐 구현을 위한 API 게이트웨이의 이해 (API GATEWAY) #2 - API 게이트웨이 기반의 디자인 패턴

MSA 아키텍쳐 구현을 위한 API 게이트웨이의 이해 #2 API 게이트웨이 기반의 디자인 패턴조대협 (http://bcho.tistory.com) API 게이트 웨이는 여러개의 엔드포인트를 설정하고, 각 엔드포인트 마다 메세지 흐름을 워크 플로우 엔진 설정을 통해서 API 에 대한 Mediation, Aggregation 설정을 할 수 있는 미들웨어 이다. 쉽게 말하면 설정과 프로그래밍이 가능한 툴일 뿐이다. 그래서, API 게이트 웨이를 도입한다고 게이트웨이가 재 역할을 하는 것이 아니라, 게이트웨이 를 이용하여 적절한 게이트 웨이 아키텍쳐를 설계해야 한다. 여기서는 API 게이트 웨이를 이용한 아키텍쳐 설계시 참고할 수 있는 디자인 패턴에 대해서 소개 한다. ※ 이 패턴들은 예전에 ESB 기반으로 ..

2015년 개발 트랜드-조대협

2015년 개발 트랜드 조대협입니다. 2015년 개발 트렌드에 대해서 간략하게 정리해봅니다. 여러 기술들을 보고 정리한 개인적인 생각이며, 앞으로 저도 집중하려고 하는 분야이기도 합니다. 애자일 및 협업 문화애자일 과 수평 조직 기반의 개발 문화에 대한 현상은 올해에도 쭈욱 지속될 듯 합니다. 기존의 워터폴이나 경직된 조직 문화와 방법론으로는 현대의 빠른 서비스 개발을 따라갈 수 가 없져애자일은 워낙 오래전 부터 언급되고 나온거라서 별도로 언급을 하지 않겠습니다만, 왜 이 부분을 2015년의 트랜드로 잡았느냐 하면, 국내 기업의 경우 애자일 프로세스만을 도입하는 것이 아니라, 조직의 구조나 문화 자체를 애자일 사상으로 옮겨가는 경우가 많이 보이기 때문입니다. 기존에 무늬만 애자일이었다면, 작년부터 올해까..