[컴퓨터월드]

클라우드 최적화 서비스들

클라우드 기반 애플리케이션에서 최근 자주 언급되면서 사용되는 구조에는 넷플릭스 도구의 콘셉트가 반영된 것들이 많다. 대표적인 예로 세 가지를 들자면, 서킷 브레이커, 서비스 디스커버리 그리고 외부 설정 참조 등이다.

이들은 넷플릭스에서 각각 히스트릭스(Hystrix), 유레카(Eureka), 아카이어스(Archaius)로 명명된 도구로서, 오픈소스로 공개 되어 있다. 이 도구들은 컴퓨터월드 이전 기고문에서 자세하게 설명되어 있다.

이 도구들은 모두 서비스를 사업의 요구에 맞게 변경하면서도 다운타임을 0에 가깝도록 하는데 그 목적이 있다. 이렇게 소프트웨어의 구조에 직접 반영해 사용되는 도구들은 각각의 애플리케이션이 클라우드가 제공하는 장점을 최대한 사용할 수 있는 하나하나의 톱니바퀴처럼 동작한다.

넷플릭스가 이런 도구들을 직접 만들어 사용하는데, 다른 회사와는 조금 다른 데브옵스의 구조를 가지고 있기 때문에 가능하다. 이 조직과 관련된 내용 역시 지난호를 살펴보면 더 자세한 정보를 얻을 수 있다. ‘풀 사이클 개발자’라는 콘셉트는 개발팀이 사용하는 IDE 도구에 운영 관련 도구들을 끼워 넣어 사용할 수 있는 형태로 제공해 각 개발팀이 운영으로서의 역할도 가능하도록 지원한다는 점이다.

어렵게 생각할 것 없이, 이 도구들은 스프링 부트 애플리케이션에서 pom.xml에 필요한 의존성을 주입하면 동작하는 이치와 같다. 보통 개발자들은 JDBC를 지원하는 JPA와 같은 의존성 추가에는 익숙하지만, Actuator나 서비스 디스커버리 등을 추가하는 것에는 생소할 것이다. 이런 도구들이 바로 다운타임 없는 서비스 운영과 관련된 것으로, 개발자는 그것이 어떻게 동작하는지 완벽히 이해하지 않더라도 플랫폼 팀에서 만들어준 이런 도구들을 의존성에 추가하는 것만으로 자신의 애플리케이션이 거대한 마이크로서비스의 일부로서 동작하고, 모니터링 되도록 하는 형태로 구현할 수 있는 것이다.

이와 같은 콘셉트들은 그동안 많은 매체와 전문가들로 부터 소개되어 왔지만, 넷플릭스가 만들어낸 도구들은 도구들 사이의 의존성과 분야에 대한 지식이 상당히 많이 필요한 관계로 많은 회사에서 적극적으로 도입하는 것은 매우 어려운 일이었다.
 

Resilience4j

Resilience4j는 아래와 같은 핵심 모듈과 애드온 모듈을 제공한다.

스프링 부트에 익숙한 개발자라면 링크(https://github.com/RobWin/resilience4j-spring-boot-demo)에서 스프링 부트 애플리케이션에 적용한 예를 찾아볼 수 있을 것이다. 각각의 이름들에서 이 도구가 제공하는 기능들이 어떤 것인지 엿볼 수 있다. 더 자세한 사용 설명은 링크(http://resilience4j.github.io/resilience4j/)를 통해 열람이 가능하다.

클라우드 최적화 애플리케이션에서 자주 사용되는 패턴

최근 클라우드 기반 애플리케이션에서 ▲프록시 패턴과 ▲사이드카 패턴 두 가지가 자주 사용된다.

프록시는 일반적으로 ‘무엇을 대신 처리해’ 주는 역할을 말한다. 위키피디아에 보다 기술적으로 잘 정리된 설명이 있지만, 여기서는 다음의 그림을 살펴보는 것으로 대처한다. 아래의 그림이 소개된 페이지의 내용을 함께 읽어보는 것도 도움이 되리라 생각한다.

이 외에 Squid(http://www.squid-cache.org/)와 같은 도구들은 아주 오래전 인터넷이 지금에 비해 매우 느린 속도일 때(128/256kbps)와 다수의 클라이언트들이 동일한 페이지에 접근할 때, 이 페이지를 클라이언트 쪽에서 캐싱하기 위한 용도의 프록시로 사용되기도 했다.

코드 내에서 뿐만 아니라 서비스 구조적 측면에서의 프록시는 날이 갈수록 유용해 지고 있으며, 클라우드 시대에서 API 게이트웨이와 밸런싱의 역할을 처리할 수 있는 도구로 널리 사용되고 있다.

사이드카 패턴에서 사이드카는 모터사이클에 연결하는 보통 1인용 조수석을 의미한다.

<그림 5>를 보면, 주요 동력은 모터사이클의 엔진에만 존재한다. 옆에 붙어있는 바퀴 하나 더 달린 조수석은 간단한 브레이크와 사람이나 짐을 더 싣기 위한 공간, 그리고 바퀴가 달려있다. 이는 한사람을 더 탑승시킬 수 있는 공간을 제공하는 동시에, 모터사이클의 바퀴를 2개에서 3개로 늘림으로서 더 안전하게 주행할 수 있지만 기본적으로 이 3륜차의 동력은 모터사이클의 엔진에 존재한다.

애플리케이션 패턴에서의 사이드카가 가지는 의미도 유사하다. 하나의 가상머신 또는 서버에서 동작하는 주 애플리케이션이 있고, 그 옆에서 보조의 역할을 하는 애플리케이션이 또 있다. 이 두개의 애플리케이션은 보통 HTTP 통신을 수행한다. 보조 역할을 하는 애플리케이션의 주요 임무는 다른 애플리케이션들과의 연동이다.

일반적으로 마이크로 서비스와 같은 분산 시스템에서 하나의 호스트에서 동작하는 이 두개의 메인과 보조 애플리케이션은 서로 다른 언어나 프레임워크 기반으로 동작한다. 그리고 보조 애플리케이션의 역할은 전체 시스템에서 사용하는 공통 모듈과 동일한 언어나 프레임워크로 구성한다.

위에서 설명한 사이드카 패턴이 서비스 디스커버리인 유레카와 함께 동작하는 방식을 위의 그림에서 찾을 수 있다. 먼저 포스트그레스나 카프카, 그리고 JVM기반이 아닌 애플리케이션들은 JVM기반으로 유레카 클라이언트와 함께 동작하는 사이드카 애플리케이션을 가진다.

이때 유레카 클라이언트는 메인 애플리케이션이 아니라 사이드카에서 동작하며, 다른 호스트에서 동작하는 유레카 서버와 다른 클라이언트에 대한 정보를 공유하거나 자신이 구동하고 있는 애플리케이션의 정보를 제공한다. 메인 애플리케이션은 사이드카와 통신하며 플랫폼에서 제공하는 정보를 얻거나 내보낼 수 있다.

이 사이드카 패턴이 넷플릭스가 폴리글럿(Polyglot)을 처리하는 핵심이라고 볼 수 있다. JVM기반으로 이루어진 다양한 클라우드 플랫폼 서비스들과 통신하는데 JVM기반의 메인 애플리케이션이라면 라이브러리를 통해 쉽게 처리할 수 있겠지만, 그 외의 다른 언어 및 프레임워크를 사용하는 애플리케이션에서는 사이드카 패턴을 사용하는 것이다.

사이드카 패턴과 프록시 패턴의 통합 엔보이

엔보이(Envoy)는 클라우드 네이티브 컴퓨팅 파운데이션(Cloud Native Computing Foundation)에 의해 유지되고 있는 오픈소스 서비스다. 자동차 공유 서비스인 lyft에서 만든 이 도구는 기본적으로 L7 프록시다. 세상에는 다양한 L7 프록시가 존재하지만, 이 엔보이는 위에서 설명한 클라우드 최적화된 애플리케이션에서 필요로 하는 기능성들을 마치 사이드카처럼, 프록시 레벨에서 수행한다는 점이 다르다.

엔보이에 대해 더 자세하게 설명하기 전에, 다음과 같은 구조적 이미지를 떠올려 보기 바란다. 만약 애플리케이션이 동작하는 모든 컨테이너 또는 서버에, 엔보이와 같은 역할을 하는 프록시를 하나하나 넣어준다면 어떤 모습일까?

이것이 가장 간단하게 설명한 이스티오(Istio)의 장점이다. 이스티오는 쿠버네티스에 배포되는 여러분의 애플리케이션에 엔보이라고 불리는 프록시 겸 사이드카를 컨테이너와 함께 배포함으로서, 클라우드 최적화된 애플리케이션에 필요한 다양한 기능을 바탕으로 ‘다운타임 없는’ 서비스로의 목표를 보다 쉽게 이룰 수 있도록 지원한다. 심지어 이런 구조는 애플리케이션에 많은 변화를 적용하지 않더라도(즉 개발자들이 클라우드 최적화에 대한 개념을 심지어 모르더라도) 사용할 수 있는 장점을 제공한다.

이스티오의 구조적 핵심은 바로 엔보이에 있기 때문에, 이스티오 자체에 대한 설명은 다음호에 진행하기로 하고 먼저 엔보이가 제공하는 기능에 대해 살펴보도록 하자.

엔보이가 동작하는 위치는 기본적으로 애플리케이션과 다른 애플리케이션 사이다. 세상의 모든 프록시가 그렇듯이 이런 구간에서 동작하는 무엇은 상당히 고속의, 즉 낮은 지연시간을 가져야 한다. 따라서 엔보이는 최근의 C++11 기반으로 작성되었다. 그리고 존재하는 구간이 프록시의 영역이기 때문에, 다른 애플리케이션에 대한 의존성이 존재하지 않는다. 따라서 지원하는 프로토콜의 규격만 맞다면, 엔보이는 다음의 기능을 애플리케이션과 서비스에 추가할 수 있도록 돕는다.

이런 기능을 하는 프록시가 각각의 애플리케이션이 동작하는 컨테이너에 사이드카 역할을 하는 프록시로 추가되는 것이다. 따라서 동일한 기능을 하는 10개의 컨테이너는 10개의 엔보이를 가진다. 이때 10개는 서로의 존재에 대해 엔보이를 통해 공유하며, 서로 연결이 필요한 경우 역시 엔보이를 통해 연결된다. 이런 서비스 구조는 전통적으로 라우터-밸런서-웹 서버-데이터베이스의 수직적 구조 및 오토스케일링과 같은 수평적 확장 구조를 모두 지원할 수 있게 된다.

각각의 모듈을 별도로 확장하거나, 수직적으로 아키텍처를 그릴 필요가 없이 모든 부분에 있어 위아래좌우로 확장이 가능하다. 이 같은 확장 방법 때문에 ‘서비스 메쉬’라는 이름이 붙었다. 이는 피보탈의 이미지인 <그림 9>를 통해 더 쉽게 이해해 볼 수 있다.

피보탈과 구글은 강력한 파트너십을 바탕으로 쿠버네티스 기반의 서비스 메쉬 구현이 가능한 이스티오를 오픈소스로서 꾸준히 발전시키고 있다. 다음 호에서는 이스티오의 준비와 사용 등에 대해 살펴본다.