2018.08.09

미리 보는 애저 쿠버네티스 컨테이너 패턴의 미래

Simon Bisson | InfoWorld
애저(Azure)는 수 년 동안 발전했다. 처음에는 다양한 애저 서비스를 이용하는 애플리케이션용 호스트(Host)였다. 이후 빅데이터와 저장소를 위한 클라우드 호스팅 툴을 지원하는 가상화 인프라용 호스트가 됐고, 지금은 컨테이너와 쿠버네티스(Kubernetes) 같은 관리 툴을 이용한 클라우드 네이티브 분산형 애플리케이션 개발까지 지원한다.



초기 버전에서는 새로운 프로그래밍 기술이 그리 필요치 않았다. 심지어 국경에 상관없이 기존의 여러 닷넷 기술을 이용해 앱을 개발하고 배치할 수 있었다. 하지만 쿠버네티스 등에서 구동하는 분산형 시스템은 다르다. 기존의 툴과 기법을 이용해 앱을 개발할 수도 있지만, 기본적인 아키텍처와 디자인 패턴에서 차이가 있다.

쿠버네티스 프로젝트의 초기 창립자 중 한 명인 브렌든 번즈는 현재 애저팀의 핵심 엔지니어다. 그는 아키텍트와 개발자가 분산형 애플리케이션 개발 세계에 뛰어드는데 도움이 되는 쿠버네티스 기반 애플리케이션용 디자인 패턴을 만들고 있다. 그는 최근 열린 2018 오라일리(O'Reilly) 오스콘(Oscon) 컨퍼런스에서 이에 대해 발표했다.

컨테이너용 패턴 언어
번즈에 따르면, 프로그램의 역사는 추상화의 진화와, 개발자를 안내하는 툴과 패턴의 발전으로 요약할 수 있다. 어셈블리(Assembly) 언어 프로그래밍에서 포트란(Fortran)을 거쳐 도널드 E. 크누스의 '컴퓨터 프로그래밍의 미학(The Art of Computer Programming)'까지 애플리케이션이 커지고 객체 지향성과 디자인 패턴에 관한 개념이 추가됐다.

오늘날에는 애저 같은 플랫폼을 이용해 분산형 시스템을 대규모로 개발할 수 있다. 이를 위해 쿠버네티스 같은 툴이 있긴 하지만, 여전히 크누스 또는 GoF(Gang of Four) 등은 이를 제대로 지원하지 못한다. 이 때 번즈의 업적(그리고 앞으로 출시될 저서)이 도움이 된다. 그는 컨테이너 애플리케이션 개발과 배치의 반복적인 패턴에 천착해 생각해 왔으며 이런 패턴 중 일부에 이름을 붙여 정리하는 단계까지 나아갔다.

번즈의 패턴 분류에서 기본적인 배치 단위는 컨테이너다. 컨테이너 안에서 코드가 얼마나 실행되는지는 상관없으며, 서비스 엔드포인트가 아키텍처 패턴을 정의하는 경계선이 된다. 이런 쿠버네티스 모델을 기반으로 개발된 개별 컨테이너는 팟(Pod)으로 그룹화되며, 각 팟은 클러스터와 클라우드에서 더 높은 수준의 배치 포인트가 된다.

단일 노드(Node) 패턴
가장 단순한 패턴은 단일 노드를 사용하는 것이다. 여기에는 명시적인 병렬 작업이 없다. 애플리케이션 대부분은 단일 컨테이너 안에서 실행된다. 전통적인 마이크로서비스 배치와도 비슷하다. 여러 컨테이너를 통해 애플리케이션을 확장할 때까지는 컨테이너 경계선이 큰 의미가 없다.

사이드카(Sidecar) 패턴. 사실 기본 코드는 로컬 및 공유 저장소가 있어 확장을 위한 디자인이 필요없다. 번즈는 "사이드카를 사용해 해당 코드를 가져다 다른 컨테이너를 부착해 초기 컨테이너를 '강화 및 확장'해 새로운 기능을 추가할 수 있다"라고 말했다. 사이드카는 연장하는 앱의 세부사항을 알 필요가 없고, 파일에만 액세스하면 된다.

대표적인 예가 기존 로깅 로컬 저장소와 클라우드 저장소 서비스 사이에 로그 전달 컨테이너가 위치한 컨테이너화된 웹 서버다. 컨테이너 내부의 원본 코드는 S3 버켓(Bucket) 또는 애저 블롭(Blob)과 호환될 필요가 없고, 이런 API는 적절한 경우 사이드카가 처리한다. 로그 파일은 정상적으로 작성되며 사이드카는 이를 적절한 저장소로 전달한다.

앰배서더(Ambassador) 패턴. 앰배서더 패턴을 사용하려면 기본 앱 컨테이너에 대한 더 상세한 설정이 필요하다. 앰배서더는 나머지 세계에 원본 애플리케이션을 대변하며 API 해독을 처리하거나 분산된 저장소에서 파편화된 데이터를 지원 및 관리하기 위해 프록시(Proxy)를 실행한다. 앰배서더는 사이드카와는 달리 해독 및 변환을 효과적으로 처리하기 위해 기본 앱을 세부적으로 정의해야 한다.

어댑터(Adapter) 패턴. 최종적인 단일 노드 패턴은 어댑터다. 앰배서더와 마찬가지로 마이크로서비스와 외부 세계 사이의 연결점 역할을 한다. 하지만 여기에서는 프로토콜을 해독하는 툴이다. 코드가 내부 API를 사용하고 있고 이를 외부 서비스와 연결할 때, 어댑터가 이 연결을 서비스 내부와 외부에서 처리한다.


멀티노드(Multinode) 패턴
단일 노드 분산형 애플리케이션 패턴은 상대적으로 간단하다. 이것들은 기존의 애플리케이션을 더 넓은 세계에서 사용할 수 있도록 목적을 다시 부여해 코드에 대해 적용할 변경사항을 최소화한다. 하지만 멀티노드 패턴은 욱 복잡하며 분산형 시스템 디자인에 관해 생각할 때를 고려하는 것과 더 관련돼 있다.

복제된 서비스 패턴. 번즈의 첫 멀티노드 패턴은 익숙한 복제된 서비스였다. 로드 밸런서 기기를 이용해 같은 기본 서비스의 여러 복제본(Replica)을 배치할 수 있으며, 새로운 복제본이 배치되거나 필요에 따라 중복된 복제본이 배치된다. 이것은 고밀도 웹 서버를 대규모로 구축해 배치하는 방법과 같다. 새로운 서비스 툴을 통해 프로그램 서비스 배치에 기여하는 모델이기도 한대 대표적인 것이 번즈의 metaparticle.io 또는 풀루미(Pulumi)에 있는 마이크로소프트 출신이 개발한 시스템 등이 있다. 이를 통해 다양한 애저 구역 또는 여러 클라우드에서 코드를 배치할 수 있다.

파편화된 시스템 패턴. 더 복잡한 멀티노드 패턴에는 로드 밸런서 기기 이면의 경로 서비스 계층이 서비스 상태를 표준 데이터 저장소로 전달하는 파편화된 시스템이 있다. 이 접근방식은 복제된 시스템에 속도와 민첩성을 더해주며 스스로 여러 번 복제할 수 있다.

미래의 핵심은 코드다
분산형 시스템을 반복 가능한 패턴으로 분할하면 서비스를 설계 및 배치를 더 수월하게 할 수 있다. 같은 패턴을 이용해 애플리케이션에 사용되는 마이크로서비스를 정의할 수 있고, 추가 기능을 기존 분산형 애플리케이션에 신속하게 추가할 수도 있다. 또한, 이를 이용해 쿠버네티스에서 조정 및 파이프라인을 관리하고 코드를 개발하는 계층으로 처리할 수 있다.

아직은 클라우드 네이티브 애플리케이션 개발이 활발한 것은 아니다. 이때 코드화된 일련의 디자인 패턴을 이용하면 새로운 개발자를 교육하고 코드를 대규모로 개발, 관리하기가 더 쉬워진다. ciokr@idg.co.kr 
2018.08.09

미리 보는 애저 쿠버네티스 컨테이너 패턴의 미래

Simon Bisson | InfoWorld
애저(Azure)는 수 년 동안 발전했다. 처음에는 다양한 애저 서비스를 이용하는 애플리케이션용 호스트(Host)였다. 이후 빅데이터와 저장소를 위한 클라우드 호스팅 툴을 지원하는 가상화 인프라용 호스트가 됐고, 지금은 컨테이너와 쿠버네티스(Kubernetes) 같은 관리 툴을 이용한 클라우드 네이티브 분산형 애플리케이션 개발까지 지원한다.



초기 버전에서는 새로운 프로그래밍 기술이 그리 필요치 않았다. 심지어 국경에 상관없이 기존의 여러 닷넷 기술을 이용해 앱을 개발하고 배치할 수 있었다. 하지만 쿠버네티스 등에서 구동하는 분산형 시스템은 다르다. 기존의 툴과 기법을 이용해 앱을 개발할 수도 있지만, 기본적인 아키텍처와 디자인 패턴에서 차이가 있다.

쿠버네티스 프로젝트의 초기 창립자 중 한 명인 브렌든 번즈는 현재 애저팀의 핵심 엔지니어다. 그는 아키텍트와 개발자가 분산형 애플리케이션 개발 세계에 뛰어드는데 도움이 되는 쿠버네티스 기반 애플리케이션용 디자인 패턴을 만들고 있다. 그는 최근 열린 2018 오라일리(O'Reilly) 오스콘(Oscon) 컨퍼런스에서 이에 대해 발표했다.

컨테이너용 패턴 언어
번즈에 따르면, 프로그램의 역사는 추상화의 진화와, 개발자를 안내하는 툴과 패턴의 발전으로 요약할 수 있다. 어셈블리(Assembly) 언어 프로그래밍에서 포트란(Fortran)을 거쳐 도널드 E. 크누스의 '컴퓨터 프로그래밍의 미학(The Art of Computer Programming)'까지 애플리케이션이 커지고 객체 지향성과 디자인 패턴에 관한 개념이 추가됐다.

오늘날에는 애저 같은 플랫폼을 이용해 분산형 시스템을 대규모로 개발할 수 있다. 이를 위해 쿠버네티스 같은 툴이 있긴 하지만, 여전히 크누스 또는 GoF(Gang of Four) 등은 이를 제대로 지원하지 못한다. 이 때 번즈의 업적(그리고 앞으로 출시될 저서)이 도움이 된다. 그는 컨테이너 애플리케이션 개발과 배치의 반복적인 패턴에 천착해 생각해 왔으며 이런 패턴 중 일부에 이름을 붙여 정리하는 단계까지 나아갔다.

번즈의 패턴 분류에서 기본적인 배치 단위는 컨테이너다. 컨테이너 안에서 코드가 얼마나 실행되는지는 상관없으며, 서비스 엔드포인트가 아키텍처 패턴을 정의하는 경계선이 된다. 이런 쿠버네티스 모델을 기반으로 개발된 개별 컨테이너는 팟(Pod)으로 그룹화되며, 각 팟은 클러스터와 클라우드에서 더 높은 수준의 배치 포인트가 된다.

단일 노드(Node) 패턴
가장 단순한 패턴은 단일 노드를 사용하는 것이다. 여기에는 명시적인 병렬 작업이 없다. 애플리케이션 대부분은 단일 컨테이너 안에서 실행된다. 전통적인 마이크로서비스 배치와도 비슷하다. 여러 컨테이너를 통해 애플리케이션을 확장할 때까지는 컨테이너 경계선이 큰 의미가 없다.

사이드카(Sidecar) 패턴. 사실 기본 코드는 로컬 및 공유 저장소가 있어 확장을 위한 디자인이 필요없다. 번즈는 "사이드카를 사용해 해당 코드를 가져다 다른 컨테이너를 부착해 초기 컨테이너를 '강화 및 확장'해 새로운 기능을 추가할 수 있다"라고 말했다. 사이드카는 연장하는 앱의 세부사항을 알 필요가 없고, 파일에만 액세스하면 된다.

대표적인 예가 기존 로깅 로컬 저장소와 클라우드 저장소 서비스 사이에 로그 전달 컨테이너가 위치한 컨테이너화된 웹 서버다. 컨테이너 내부의 원본 코드는 S3 버켓(Bucket) 또는 애저 블롭(Blob)과 호환될 필요가 없고, 이런 API는 적절한 경우 사이드카가 처리한다. 로그 파일은 정상적으로 작성되며 사이드카는 이를 적절한 저장소로 전달한다.

앰배서더(Ambassador) 패턴. 앰배서더 패턴을 사용하려면 기본 앱 컨테이너에 대한 더 상세한 설정이 필요하다. 앰배서더는 나머지 세계에 원본 애플리케이션을 대변하며 API 해독을 처리하거나 분산된 저장소에서 파편화된 데이터를 지원 및 관리하기 위해 프록시(Proxy)를 실행한다. 앰배서더는 사이드카와는 달리 해독 및 변환을 효과적으로 처리하기 위해 기본 앱을 세부적으로 정의해야 한다.

어댑터(Adapter) 패턴. 최종적인 단일 노드 패턴은 어댑터다. 앰배서더와 마찬가지로 마이크로서비스와 외부 세계 사이의 연결점 역할을 한다. 하지만 여기에서는 프로토콜을 해독하는 툴이다. 코드가 내부 API를 사용하고 있고 이를 외부 서비스와 연결할 때, 어댑터가 이 연결을 서비스 내부와 외부에서 처리한다.


멀티노드(Multinode) 패턴
단일 노드 분산형 애플리케이션 패턴은 상대적으로 간단하다. 이것들은 기존의 애플리케이션을 더 넓은 세계에서 사용할 수 있도록 목적을 다시 부여해 코드에 대해 적용할 변경사항을 최소화한다. 하지만 멀티노드 패턴은 욱 복잡하며 분산형 시스템 디자인에 관해 생각할 때를 고려하는 것과 더 관련돼 있다.

복제된 서비스 패턴. 번즈의 첫 멀티노드 패턴은 익숙한 복제된 서비스였다. 로드 밸런서 기기를 이용해 같은 기본 서비스의 여러 복제본(Replica)을 배치할 수 있으며, 새로운 복제본이 배치되거나 필요에 따라 중복된 복제본이 배치된다. 이것은 고밀도 웹 서버를 대규모로 구축해 배치하는 방법과 같다. 새로운 서비스 툴을 통해 프로그램 서비스 배치에 기여하는 모델이기도 한대 대표적인 것이 번즈의 metaparticle.io 또는 풀루미(Pulumi)에 있는 마이크로소프트 출신이 개발한 시스템 등이 있다. 이를 통해 다양한 애저 구역 또는 여러 클라우드에서 코드를 배치할 수 있다.

파편화된 시스템 패턴. 더 복잡한 멀티노드 패턴에는 로드 밸런서 기기 이면의 경로 서비스 계층이 서비스 상태를 표준 데이터 저장소로 전달하는 파편화된 시스템이 있다. 이 접근방식은 복제된 시스템에 속도와 민첩성을 더해주며 스스로 여러 번 복제할 수 있다.

미래의 핵심은 코드다
분산형 시스템을 반복 가능한 패턴으로 분할하면 서비스를 설계 및 배치를 더 수월하게 할 수 있다. 같은 패턴을 이용해 애플리케이션에 사용되는 마이크로서비스를 정의할 수 있고, 추가 기능을 기존 분산형 애플리케이션에 신속하게 추가할 수도 있다. 또한, 이를 이용해 쿠버네티스에서 조정 및 파이프라인을 관리하고 코드를 개발하는 계층으로 처리할 수 있다.

아직은 클라우드 네이티브 애플리케이션 개발이 활발한 것은 아니다. 이때 코드화된 일련의 디자인 패턴을 이용하면 새로운 개발자를 교육하고 코드를 대규모로 개발, 관리하기가 더 쉬워진다. ciokr@idg.co.kr 
X