본문 바로가기

2018
itworld

Jonathan Freeman, Martin Heller, Peter Wayner, Serdar Yegulalp | InfoWorld / 2018-10-03

 

 

예전에는 "어떤 컨테이너 오케스트레이션 플랫폼을 사용할 것인가?"가 중요한 문제였다면, 이제는 "어떻게 쿠버네티스를 구동할 것인가?"가 중요해지고 있다. 지난 한 해 동안 주요 클라우드 서비스 업체 3곳 모두가 "K8" 클러스터를 제공하고, 생태계에 많은 혁신이 일어나면서 쿠버네티스는 그 지배적인 위치를 공고히 했다. 2018년 최고의 오픈소스 소프트웨어 대상 클라우드 컴퓨팅 부문 수장작들은 바로 이런 클라우드 네이티브 애플리케이션의 새로운 시대를 이끌어 갈 장본인들이다. editor@itworld.co.kr

 

Kubernetes

쿠버네티스(Kubernetes)

컨테이너 오케스트레이션에 쿠버네티스 외에 다른 옵션들을 고려하던 때도 있었다. 그러나 이제 분산형 컨테이너 애플리케이션의 실행에 관해서는 쿠버네티스가 지배적 위치를 차지하고 있다. AWS, 애저, 구글 클라우드 플랫폼은 물론 플라이빗 클라우드까지 확장 가능한 새로운 서비스를 구축하려 한다면, 쿠버네티스를 이야기하지 않고는 어려울 것이다. 컨테이너 인프라를 구축하는 것은 하드웨어, 소프트웨어 및 네트워크 장치의 전체 생태계를 지원힌다는 의미이다. 1.11 릴리즈를 통해 쿠버네티스는 이제 IPVS 인클러스터 로드 밸런싱 및 CoreDNS(플러그형 DNS 서버)를 지원하게 되었다. 이에 앞서 올해 초에는 주요 보안, 스토리지 및 네트워킹을 강화하기도 했다.

 

Docker

도커(Docker)

도커를 사용하면 소프트웨어를 "컨테이너"로 패키징하고 OS 수준 VM으로 실행할 수 있다. VM웨어 및 기타 유명 가상화 기술과 달리 도커는 전체 컴퓨터를 가상화하는 데 CPU를 비롯한 자원을 낭비하지 않으며, 각 "게스트"마다 추가 OS가 필요하지도 않다. 불과 5년 만에 도커는 컴퓨팅에서 가상화가 작동하는 방식을 완전히 바꾸어 놓았다. 쿠버네티스가 상승세를 타면서, 컨테이너 배포 방식으로 도커를 선택하지는 사람이 예전만큼 많지는 않다. 그러나 여전히 도커는 컨테이너 클러스터를 관리할 수 있는 유효한 대안으로 기능하고 있으며, 많은 이들이 도커를 통해 개별 컨테이너를 생성, 운영하고 있다.

 

Istio

이스티오(Istio)

이스티오는 컨테이너 배치 퍼즐의 중요한 조각임이 서서히 증명되고 있다. 물론 노마드(Nomad)나 쿠버네티스와 같은 플랫폼은 컨테이너 오케스트레이션에 많은 기능을 제공하지만, 이들은 단순히 서비스를 정의하는 기본적 사항만을 제공할 뿐 기업의 다양한 서비스 간에 발생하는 여러 가지 난해한 요구를 해결하지는 못한다. 이스티오는 오케스트레이션 플랫폼 위에 서비스 메시를 제공해 검색, 로드 밸런싱, 장애 복구, 메트릭 및 모니터링과 같은 풍부한 운영 요구사항을 처리하고 관계를 정의할 수 있도록 지원한다. 2017년 구글에서 처음 출시했으며, 올해 초 1.0버전을 릴리즈했다. 이스티오는 구글의 쿠버네티스 엔진에서 대규모 프로덕션 배치를 담당하고 있으며, 향후 더 넓은 쿠버네티스 생태계의 중요한 부분이 될 것으로 보인다.

 

Envoy

엔보이(Envoy)

리프트(Lyft)에서 만든 엔보이는 그 성능을 인정받아 심지어 최대의 경쟁자인 우버마저도 사용하고 있다. 엔보이는 서비스 검색, 상태 점검, 로드 밸런싱, 그리고 어떤 유형의 애플리케이션 서버에서도 사용하기 쉬운 프로세스 외(out-of-process) 설계 아키텍처 등의 강점을 앞세워 빠르게 쿠버네티스 생태계의 핵심으로 자리 잡았다. 엔보이는 이스티오의 서비스 메시 시스템의 중심에 위치해 있을 뿐만 아니라 전 세계 쿠버네티스 클러스터에 별도로 배치되어 있다. 엔보이는 또한 여전히 더 새롭고 더 세련된 언어임을 보여주는 최신 C++ 애플리케이션의 훌륭한 예시이기도 하다.

 

Apache Zipkin

아파치 집킨(Apache Zipkin)

갈수록 분산화되는 동시에 마이크로서비스 지향적으로 벼노하하는 아키텍처는 확장성, 복원력 및 개발자 생산성 측면에서 많은 이점을 제공한다. 그러나 디버깅에서는 큰 약점이 있다. 유동적 요소가 너무 많고, 서로 다른 위치로 인해 문제가 발생한 곳이 어디인가를 정확히 찾아내기 어려울 수 있다는 점이다. 원래 트위터에서 개발한 집킨(Zipkin)은 구글의 대퍼 페이퍼(Dapper paper)에서 설명한 개념에 기반한 추적 시스템으로, 사용자의 아키텍처를 통해 이동중인 요청을 매핑하여 지연시간이나 잠재적인 문제를 식별할 수 있다. 집킨은 이미 많은 개발자가 분산 디버깅에 사용하고 있는 솔루션이지만, 최근 아파치 인큐베이터 프로젝트로 채택됨에 따라 2019년에는 더욱 사용자가 늘어 날 전망이다.

 

Jaeger

예거(Jaeger)

예거(Jaeger) 예거는 쿠버네티스를 위한 분산형 추적시스템이다. 우버는 벌써 오래 전에 마이크로서비스를 기꺼이 받아들였다. 하지만, 그전에 기존의 획일적인 개발 방식(monolithic)에 대해 짚고 넘어가야 할 것이 있다. 기존에는 로그를 어딘가에 저장한 후 언제, 무엇을 하고 있었는지를 정확히 알 수 있다. 애플리케이션을 여러 조각으로 나누고 네트워크 전체에 배포하면 확장성과 적응성 측면에서 많은 이점을 얻을 수 있지만 동시에 무엇을, 언제 어디서 하고 있는지 알 수 없게 된다. 네트워크 일부가 이처럼 불확실해지면 오류가 어디서 시작되었는지 알 방법이 없어진다. 우버는 프로세스 및 서비스 전반의 요청을 추적할 수 있는 메타데이터를 기록, 수집 및 분석하는 툴을 개발해 이 문제를 해결했다. 이 툴은 누가 어디서, 언제, 어떤 작업을 했는지를 알려주어 지연의 근본 원인을 파악할 수 있다.

 

Prometheus

프로메테우스(Prometheus)

쿠버네티스 및 이스티오와 마찬가지로 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 프로젝트인 프로메테우스는 클라우드 상의 분산 애플리케이션에서 동작하도록 설계되었다. 프로메테우스는 고속 데이터 수집을 처리하도록 설계된 모니터링 및 알림 서비스를 제공하며, 자체 시계열 데이터베이스를 기반으로 한다. 프로메테우스의 클라이언트 라이브러리(고, 자바, 스칼라, 루비 등 기타 여러 언어에 사용 가능)로 코드를 측정하고 풀 또는 푸시를 통해 시계열 데이터를 수집할 수 있다. 또한 프로메테우스는 다른 CNCF 프로젝트와 함께 구성 요소로서 기능하는데, 이는 다시 말해 쿠버네티스 서비스 발견 기능을 사용할 수는 있지만 그럴 필요가 없다는 이야기다.

 

Kops

콥스(Kops)

콥스는 AWS, 구글 클라우드 및 VM웨어 vSphere에서 쿠버네티스 클러스터 프로비저닝을 자동화하는 올인원 커맨드라인 툴이며, 그 밖에 다른 대상 플랫폼에 대한 지원 역시 진행 중이거나 계획 중이다. 또한 콥스는 테라폼(Terraform) 구성을 생성하며 헤지코프(Hasicorp)의 인프라 매니저를 사용하여 쿠버네티스 클러스터를 배치할 수 있도록 한다. 또한 콥스는 초기 쿠버업(Kube-up) 툴에서의 이전을 지원하기도 한다.

 

Helm

헬름(Helm)

헬름은 쿠버네티스의 애플리케이션 설치 관리자이다. 컨테이너형 애플리케이션을 몇 가지 개발해 쿠버네티스 클러스터에 배포하고 나면, 이들의 매력은 빠르게 사라지고 만다. 네트워크, 스토리지, 제한 등 컨테이너 수명 주기에 국한되지 않는 구성은 무척 많고 다양하다. 항해 테마에 맞춰 비유하자면, 헬름은 이 모든 구성을 일종의 '해도'로 포장해 주는 기능을 한다. 여기서 해도는 패키지이고, 헬름은 그 패키지를 관리하는 매니저이다. 다만 컨테이너만 패키징하는 것이 아니라 차트가 포함하는 '다른 것들'까지 모두 패키징 한다는 점이 다르다.

 

Kube-bench

쿠버벤치(Kube-bench)

쿠버벤치는 인터넷 보안 센터(Center for Internet Security)의 업계 표준 벤치마크인 CIS 쿠버네티스 벤치마크와 비교해 쿠버네티스 배치의 보안 상태를 테스트하는 고(Go) 애플리케이션이다. 275쪽에 달하는 쿠버네티스 '모범 사례 및 보안 권고 사항' 가이드를 기반으로 광범위한 자동화 점검을 제공하기 때문에 수백 시간에 달하는 수작업의 수고를 피할 수 있다. 테스트 진행 시 쿠버벤치는 CIS 쿠버네티스 벤치마크의 각 섹션에 대하여 통과, 낙제, 또는 경고 메시지를 출력해 준다. 또한 반복적인 자동화, 다른 툴과의 통합 및 보안 문제 완화를 위한 JSON 출력을 지원한다. 쿠버벤치의 테스트는 YAML 포맷으로 구성되므로 CIS 벤치마크가 발전함에 따라 쉽게 업데이트할 수 있다.

 

시스딕(Sysdig), 팔코(Falco), & 인스펙트(Inspect)

시스딕(Sysdig), 팔코(Falco), & 인스펙트(Inspect)

행위 모니터링 및 이상 징후 감지는 수십 년 동안 기업 네트워크에 잘 적용되어 왔다. 시스딕은 이러한 기능을 컨테이너 플랫폼으로 가져오려는 시도이다. 널리 사용되는 시스딕 시스템 호출 캡처 툴과 시스딕의 이벤트 필터링 언어로 표현된 사용자 지정 규칙을 바탕으로, 시스딕 팔코는 리눅스 컨테이너 및 컨테이너 호스트에서 발생하는 보안 정책 위반 및 비정상적인 동작을 탐지해 낸다. 위반 사항이 발견될 경우 시스딕 인스펙트을 사용하여 시스딕으로 캡처한 시스템, 네트워크 및 애플리케이션 데이터에 대해 심층적인 조사를 수행할 수 있다. 인스펙트를 사용하면 시스템 호출 및 퍼포먼스 메트릭의 시각화 외에도 프로세스, 파일 시스템 작업, 네트워크 연결 및 페이로드에 대한 세부 정보를 자세히 살펴볼 수 있다. 파일에 기록된 데이터 하나 하나가 표시되기 때문에 멀웨어 탐지 및 문제 대응 조사가 수월하다.

 

OpenFaaS

OpenFaaS

서버리스(serverless) 방식은 여러 가지 이유로 매력적이다. 가장 표면적인 장점으로는 온디맨드 인프라와 관련된 비용 절감 효과가 있다. 게다가 이 서버리스 패러다임은 모든 것의 서비스화(anything-as-a-service)를 구현, 유지할 수 있는 방법처럼 느껴지기까지 한다. 사용량에 따른 결제 모델의 이점 때문에 공급업체에 종속되는 기업이 아직도 많다. 하지만 굳이 둘 중 하나를 포기하지 않아도 된다면 어떨까? OpenFaaS는 쿠버네티스 클러스터에 도커 컨테이너의 기능을 구현하는 서버리스 모델이다. 이러한 쿠버네티스 클러스터를 배치하면, 더 이상 서비스 업체 종속에 대해서는 아무런 걱정도 할 필요가 없을 것이다. 물론 쿠버네티스의 클러스터의 자동 확장 없이는 비용 절감 효과를 얻지 못하겠지만, 새로운 프로그래밍 패러다임을 사용하면서 배치의 유연성을 확보할 수는 있을 것이다.

 

Serverless Framework

서버리스 프레임워크(Serverless Framework)

서버리스 프레임워크(Serverless Framework) 서버리스 아키텍처는 지난 몇 년 동안 전 세계를 지배해 왔다. 하지만, 일반적으로 이 방식은 공급업체에 대한 종속을 야기한다. 여러 기능을 수행하거나 "람다(lambdas)"를 이행하는 클라우드 서비스 업체는 다른 클라우드 서비스 업체로의 이전을 어렵게 만드는 구현 및 배치에 대한 세부사항을 요건으로 제시하곤 한다. 그러나 서버리스 프레임워크를 통하면 이런 차이점을 추상화하면서 동시에 기능을 테스트하고 배치하는 편리한 방법도 얻을 수 있다. CLI를 통해 서버리스 프레임워크와 상호 작용할 경우 다양한 클라우드 서비스 업체에 대한 부팅스트랩 및 배치 기능을 지원하고 공통 YAML 파일을 통한 구성 업데이트를 이용할 수 있다. 즉 업체 종속 방지를 포함해 서버리스 프레임워크가 제공하는 3가지 편리함 때문에라도 이 방식은 눈 여겨 볼 가치가 있다.

 

※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지

[원문출처 : http://www.itworld.co.kr/slideshow/110942]

맨 위로
맨 위로