조대협의 블로그

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

도커는 컨테이너로 기동하기 때문에 네트워크를 통해서 도커의 IP를 접근하거나 또는 도커에서 호스트의 IP를 접근하기위해서는 별도의 설정이 필요하다. 시간을 많이 소요한 부분이 MAC 환경이 다름을 인지 못했기 때문인데, 도커에는 네트워크 모드중에 host 모드(docker run --net="host" )로 설정하고 기동하면 된다.라는 것이 있다. 이 경우 도커의 네트워킹이 host 머신의 네트워크를 그대로 사용하기 때문에, host의 ip와 port가 그대로 도커와 연결이 되지만, 이 host 모드는 MAC에서는 작동을 하지 않는다. MAC의 경우에는 이 Host 모드가 동작하지 않는다.다음과 같은 시나리오가 있다고 보자 -->0.0.0.0:8087 (docker) --> 0.0.0.0:8081 (ho..

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

docker ps 로 컨테이너 ID 확인docker exec -i -t {Container Id} /bin/bash

Stack driver profiler 조대협 (http://bcho.tistory.com) 얼마전에 구글 클라우드의 모니터링 솔루션인 stack driver에서 profiler 기능이 발표되었다. (https://cloud.google.com/profiler) 우리가 일반적으로 생각하는 성능 분석을 위한 profiling 도구로, 구글 클라우드 뿐만 아니라, 여러 서버에서 동작하는 Java/node.js/Go 애플리케이션의 성능을 모니터링할 수 있다.(파이썬은 곧 지원 예정) 장점은 코드 수정없이 간단하게 에이전트만 추가함으로써 프로파일러 사용이 가능하고, 프로파일링된 결과를 stackdriver 웹 콘솔에서 바로 확인이 가능하다는 것이다. JDB등 전통적인 프로파일러가 있기는 하지만 보통 프로파일러가..

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

Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #3Stackdriver를 zipkin으로 사용하기 조대협 (http://bcho.tistory.com) 앞의 예제에서는 간단하게 Zipkin 서버를 메모리 스토리지를 이용해서 올렸는데, 운영환경에서는 적절하지 않다. 실 운영환경에서는 대규모 트래픽 저장 및 쿼리를 위해서 Cassandra나 Elastic Search 등을 사용해야 하는데, 설정과 운영이 어렵다.이에 대한 대안으로 구글 클라우드에는 분산 트렌젝션 추적을 위한 Stack driver trace (https://cloud.google.com/trace/) 라는 기능이 있다. 자체적인 SDK를 이용하여 트렌젝션을 추적하는 것도 가능하지만, 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조대협 (http://bcho.tistory.com) 개념분산 트렌젝션이랑 여러개의 서비스를 걸쳐서 이루어 지는 트렌젝션을 추적하는 기능을 정의한다.마이크로 서비스 아키텍쳐 (이하 MSA)와 같은 구조에서는 하나의 HTTP 호출이 내부적으로 여러개의 서비스를 거쳐서 일어나게 되는데, 그러면 어느 구간에서 병목이 생기는지 추적하기가 어려워진다.아래 그림을 보면 클라이언트가 Service A를 호출하고, Service A 가 Service B,D 를, Service B가 Service C를 호출한다. 이렇게 트렌젝션이 여러 컴포넌트의 조합을 통해서 발생하기 때문에 Jennifer와 같은 전통적인 APM (Application Performance..

Apt.ly를 이용한 데비안 리포지토리 생성 조대협 (http://bcho.tistory.com) 앞의 글에서 Jenkins + Maven 조합을 통해서 애플리케이션 설치 파일을 데비안 패키지로 패키징하는 방법에 대해서 알아보았다. 이제 이 패키지를 서버에 설치하는 방법을 살펴본다.패키지를 설치하는 방법은 간단하게 데비안 패키지 파일을 설치하고자 하는 서버에 복사해놓은 다음에, sudo apt-get install을 이용해서 설치하는 방법도 있지만, 설치하고자 하는 서버마다 복사하기가 번거롭기 때문에 조금 더 쉬운 접근을 위해서 데비안 패키지 서버를 올리는 방법이 있다. 우리가 JDK나 node.js 등 다양한 유닉스 패키지를 apt-get 을 이용하여 설치가 가능한것은 미리 데비안 패키지 리파지토리 서..