2016.05.13

컨테이너 서비스 고도화 : 복잡성을 외부로 밀어내기

Jim Bugwadia | InfoWorld
가트너의 리서치 담당 디렉터 개리 올리페는 마이크로서비스 아키텍처 패턴으로 시스템 복잡성을 다루는 내용을 담은 "마이크로서비스 : 외부에 서비스 구축하기(Microservices : Building Services with the Guts on the Outside)"이라는 유익한 글을 올렸다. 개리는 마이크로서비스 스타일의 애플리케이션에서 가능한 단순성을 높여 개발자의 생산성을 극대화할 수 있도록 각 서비스를 디자인하는 방법을 소개하고 있다. 그러나 복잡성을 다른 장소로 옮겨야 한다. 마이크로서비스 방식의 경우, 이런 복잡성을 개별 마이크로서비스에서 공통 서비스 계층으로 옮긴다.

개리는 마이크로서비스는 내부 아키텍처를 단순화하고, 복잡성을 아키텍처 외부로 옮겨야 한다고 주장했다. 이는 컨테이너 서비스를 정의하는 틈새 모델을 제공한다.

복잡성 관리
복잡성을 애플리케이션 외부로 옮기면, 어디서 이를 다뤄야 할 것인가? 공통 서비스를 처리할 계층이 있어야 한다. 마이크로서비스에 필요한 '배관(Plumbing)'이라 할 수 있다.

이 새로운 플랫폼 계층 서비스를 전달하는 방법과 관련해 2가지 트렌드가 형성되어 있다.

- 애플리케이션 프레임워크 : 모든 주요 언어를 대상으로 마이크로서비스 프레임워크가 개발되고 있다. 자바는 NetflixOSS, 스프린트 부트(Spring Boot), 스프링 클라우드(Spring Cloud, NetflixOSS 구성요소의 일부를 추출)를 갖고 있다. Go는 Go-kit, Micro 등을 갖고 있다. 통상 이들 프레임워크는 언어에 특정 라이브러리 및 런타임 서비스 세트로 전달된다.

- 컨테이너 서비스 : 오픈 컨테이너 표준에 기반을 두며, 언어나 시스템에 대한 제약이 없다.

컨테이너 서비스
2015년 중반, 컨테이너 시장의 몇몇 업체가 리눅스 재단 아래 모여 OCI(Open Container Initiative)가 출범했다. 이 이니셔티브는 업체 오케스트레이션 스택과 구성체, OS에 특정 구성체를 컨테이너 기반에서 분리한다는 목표를 추구하고 있다.

애플리케이션 컨테이너는 애플리케이션 구성 요소에 포함될 요소를 설명하는 이미지 패키징 메커니즘인 동시에 애플리케이션 구성 요소를 런칭해 실행하는 방법을 규정한 애플리케이션 런타임이다. OIC는 두 가지 사양을 연구하고 있다. 애플리케이션 런타임에 관한 OCI 런타임 사양과 최근 발표한 애플리케이션 정의와 패키지에 대한 OCI 이미지 포맷 사양이다.

이제 OCI 표준을 이용, 컨테이너를 표준화된 운영 및 관리 단위로 활용하고, 이 컨테이너 주변에 공통 애플리케이션 서비스를 구현할 수 있다.


컨테이너 서비스는 오픈 컨테이너 표준에 기반을 두고 있으며, 컨테이너 외부에 공통 서비스를 제공한다.

다음은 컨테이너 서비스의 일부 예이다.

• 컨테이너 라이프사이클 관리
• 컨테이너 일정 예약 및 배치
• 로깅
• 모니터링
• 자동 복구
• 자동 확장(축소)
• 등록 및 발견
• 로드 밸런싱
• 요청 라우팅
• 네트워킹
• 스토리지 및 데이터 관리
• 애플리케이션 보안

마이크로소프트와 직접적인 관련이 없는 서비스도 있다. 또 서비스 발견 및 버전 인식 요청 라우팅 등의 서비스는 마이크로서비스 방식 애플리케이션을 구현할 때 반드시 필요한 서비스이다. 사실 클라우드 네이티브로의 여정에서 베스트 프랙티스는 애플리케이션을 기반 인프라에서 분리하는 것이다. 심지어는 컨테이너에 배포한 기존 애플리케이션도 이런 서비스가 큰 도움을 줄 수 있다.

어떻게 선택해야 할까?
복잡성을 마이크로서비스 밖으로 밀어내자는 개리의 주장으로 돌아가면, 생각할 수 있는 방법 몇 가지가 있다.

1. 언어에 특화된 라이브러리와 런타임 구성 요소 및 전통적인 애플리케이션 프레임워크 방법
2. 오픈 컨테이너 이니셔티브에 기반을 둔 컨테이너 서비스.

옳은 방법도 틀린 방법도 없다. 그러나 두 방법의 장점과 단점을 이해하는 것이 중요하다. 또 컨테이너 오케스트레이션 및 관리 도구, 애플리케이션 프레임워크가 플랫폼 서비스를 다양한 수준으로 지원할 것이다. 마이크로서비스 방식 애플리케이션을 프로덕션 환경에 배포해 운영하기 위해 필요한 모든 사항들을 다루기 위해 애플리케이션 프레임워크와 컨테이너 서비스를 섞어 사용하는 사례가 많을 것이다.

다음은 두 방법을 간략하게 비교한 내용이다.





플랫폼 도구와 컴파일 타임을 통합하고, 호스트 인스턴스에 직접 실행되는 마이크로서비스를 설계할 수 있지만, 컨테이너를 이용하면 몇 가지 이점을 누릴 수 있다. 민첩성과 런타임 이동성이라는 이점을 갖고 있다. 또 컨테이너를 이용하면 표준 플랫폼 계층을 활용해 클라우드 네이티브 애플리케이션 구축, 배포, 운영에 수반되는 몇몇 과제를 극복할 수 있다.

더 나아가 많은 컨테이너 서비스를 하나의 시스템 컨테이너 세트로 배포해 조정할 수 있다. 이렇게 하면 관리, 다중 클라우드 애플리케이션 구현 및 관리가 더욱 용이해진다.

애플리케이션에 종속성을 추가할 때 주의를 기울여야 한다. 공통 서비스를 컴파일-인, 종속성과 버전, 업그레이드를 관리하는 것이 합리적인 경우가 있다. 그러나 가능한 외부 아키텍처 계층, 즉 애플리케이션 밖, 애플리케이션 컨테이너 밖으로 많은 것을 밀어낼 것을 권장한다.
 


2016.05.13

컨테이너 서비스 고도화 : 복잡성을 외부로 밀어내기

Jim Bugwadia | InfoWorld
가트너의 리서치 담당 디렉터 개리 올리페는 마이크로서비스 아키텍처 패턴으로 시스템 복잡성을 다루는 내용을 담은 "마이크로서비스 : 외부에 서비스 구축하기(Microservices : Building Services with the Guts on the Outside)"이라는 유익한 글을 올렸다. 개리는 마이크로서비스 스타일의 애플리케이션에서 가능한 단순성을 높여 개발자의 생산성을 극대화할 수 있도록 각 서비스를 디자인하는 방법을 소개하고 있다. 그러나 복잡성을 다른 장소로 옮겨야 한다. 마이크로서비스 방식의 경우, 이런 복잡성을 개별 마이크로서비스에서 공통 서비스 계층으로 옮긴다.

개리는 마이크로서비스는 내부 아키텍처를 단순화하고, 복잡성을 아키텍처 외부로 옮겨야 한다고 주장했다. 이는 컨테이너 서비스를 정의하는 틈새 모델을 제공한다.

복잡성 관리
복잡성을 애플리케이션 외부로 옮기면, 어디서 이를 다뤄야 할 것인가? 공통 서비스를 처리할 계층이 있어야 한다. 마이크로서비스에 필요한 '배관(Plumbing)'이라 할 수 있다.

이 새로운 플랫폼 계층 서비스를 전달하는 방법과 관련해 2가지 트렌드가 형성되어 있다.

- 애플리케이션 프레임워크 : 모든 주요 언어를 대상으로 마이크로서비스 프레임워크가 개발되고 있다. 자바는 NetflixOSS, 스프린트 부트(Spring Boot), 스프링 클라우드(Spring Cloud, NetflixOSS 구성요소의 일부를 추출)를 갖고 있다. Go는 Go-kit, Micro 등을 갖고 있다. 통상 이들 프레임워크는 언어에 특정 라이브러리 및 런타임 서비스 세트로 전달된다.

- 컨테이너 서비스 : 오픈 컨테이너 표준에 기반을 두며, 언어나 시스템에 대한 제약이 없다.

컨테이너 서비스
2015년 중반, 컨테이너 시장의 몇몇 업체가 리눅스 재단 아래 모여 OCI(Open Container Initiative)가 출범했다. 이 이니셔티브는 업체 오케스트레이션 스택과 구성체, OS에 특정 구성체를 컨테이너 기반에서 분리한다는 목표를 추구하고 있다.

애플리케이션 컨테이너는 애플리케이션 구성 요소에 포함될 요소를 설명하는 이미지 패키징 메커니즘인 동시에 애플리케이션 구성 요소를 런칭해 실행하는 방법을 규정한 애플리케이션 런타임이다. OIC는 두 가지 사양을 연구하고 있다. 애플리케이션 런타임에 관한 OCI 런타임 사양과 최근 발표한 애플리케이션 정의와 패키지에 대한 OCI 이미지 포맷 사양이다.

이제 OCI 표준을 이용, 컨테이너를 표준화된 운영 및 관리 단위로 활용하고, 이 컨테이너 주변에 공통 애플리케이션 서비스를 구현할 수 있다.


컨테이너 서비스는 오픈 컨테이너 표준에 기반을 두고 있으며, 컨테이너 외부에 공통 서비스를 제공한다.

다음은 컨테이너 서비스의 일부 예이다.

• 컨테이너 라이프사이클 관리
• 컨테이너 일정 예약 및 배치
• 로깅
• 모니터링
• 자동 복구
• 자동 확장(축소)
• 등록 및 발견
• 로드 밸런싱
• 요청 라우팅
• 네트워킹
• 스토리지 및 데이터 관리
• 애플리케이션 보안

마이크로소프트와 직접적인 관련이 없는 서비스도 있다. 또 서비스 발견 및 버전 인식 요청 라우팅 등의 서비스는 마이크로서비스 방식 애플리케이션을 구현할 때 반드시 필요한 서비스이다. 사실 클라우드 네이티브로의 여정에서 베스트 프랙티스는 애플리케이션을 기반 인프라에서 분리하는 것이다. 심지어는 컨테이너에 배포한 기존 애플리케이션도 이런 서비스가 큰 도움을 줄 수 있다.

어떻게 선택해야 할까?
복잡성을 마이크로서비스 밖으로 밀어내자는 개리의 주장으로 돌아가면, 생각할 수 있는 방법 몇 가지가 있다.

1. 언어에 특화된 라이브러리와 런타임 구성 요소 및 전통적인 애플리케이션 프레임워크 방법
2. 오픈 컨테이너 이니셔티브에 기반을 둔 컨테이너 서비스.

옳은 방법도 틀린 방법도 없다. 그러나 두 방법의 장점과 단점을 이해하는 것이 중요하다. 또 컨테이너 오케스트레이션 및 관리 도구, 애플리케이션 프레임워크가 플랫폼 서비스를 다양한 수준으로 지원할 것이다. 마이크로서비스 방식 애플리케이션을 프로덕션 환경에 배포해 운영하기 위해 필요한 모든 사항들을 다루기 위해 애플리케이션 프레임워크와 컨테이너 서비스를 섞어 사용하는 사례가 많을 것이다.

다음은 두 방법을 간략하게 비교한 내용이다.





플랫폼 도구와 컴파일 타임을 통합하고, 호스트 인스턴스에 직접 실행되는 마이크로서비스를 설계할 수 있지만, 컨테이너를 이용하면 몇 가지 이점을 누릴 수 있다. 민첩성과 런타임 이동성이라는 이점을 갖고 있다. 또 컨테이너를 이용하면 표준 플랫폼 계층을 활용해 클라우드 네이티브 애플리케이션 구축, 배포, 운영에 수반되는 몇몇 과제를 극복할 수 있다.

더 나아가 많은 컨테이너 서비스를 하나의 시스템 컨테이너 세트로 배포해 조정할 수 있다. 이렇게 하면 관리, 다중 클라우드 애플리케이션 구현 및 관리가 더욱 용이해진다.

애플리케이션에 종속성을 추가할 때 주의를 기울여야 한다. 공통 서비스를 컴파일-인, 종속성과 버전, 업그레이드를 관리하는 것이 합리적인 경우가 있다. 그러나 가능한 외부 아키텍처 계층, 즉 애플리케이션 밖, 애플리케이션 컨테이너 밖으로 많은 것을 밀어낼 것을 권장한다.
 


X