2020.08.13

마이크로소프트 오픈 서비스 메시의 이해

Simon Bisson | InfoWorld
불과 몇 년 전에는 인프라에 대해 이야기한다면 곧 물리 인프라, 즉 서버와 메모리, 디스크, 네트워크 스위치, 그리고 이를 연결하기 위한 온갖 케이블 작업을 의미했다. 필자는 이런저런 숫자를 입력하면 수천, 수백만의 사용자를 지원할 수 있는 웹 애플리케이션을 구축하는 데 필요한 하드웨어의 사양이 출력되는 스프레드시트를 사용하곤 했다.

하지만 이제 바뀌었다. 먼저 이러한 물리 서버 랙 위에 위치하는 가상 인프라가 등장했다. 하이퍼바이저와 소프트웨어 정의 네트워크, 스토리지를 사용해서 애플리케이션의 컴퓨팅 요구사항을 지정하고 프로비저닝하면 물리 하드웨어 위의 가상 네트워크는 알아서 관리됐다. 지금은 하이퍼스케일 퍼블릭 클라우드에서 수직 확장과 수평 확장을 자동으로 관리해주는 오케스트레이션 프레임워크 위에 분산 애플리케이션을 구축한다.
 
ⓒ Getty Images Bank
 

서비스 메시를 사용하여 분산 애플리케이션 인프라 관리하기

새로운 애플리케이션 인프라에는 자동 확장에 대응하고 로드밸런싱과 서비스 검색을 처리하고 정책 기반 보안을 지원하기 위한 지능을 갖춘 자체 인프라 계층이 필요하다.

마이크로서비스 컨테이너 외부에 위치하는 애플리케이션 인프라는 서비스 메시로 구현되며, 각 컨테이너가 사이드카로 실행되는 프록시에 연결된다. 프록시가 컨테이너 간 통신을 관리하므로 개발팀은 호스팅하는 서비스와 API에 집중할 수 있고, 애플리케이션 운영팀은 이런 모든 요소를 연결하는 서비스 메시를 관리한다.

서비스 메시를 구현하는 누구나 직면하는 가장 큰 문제는 서비스 메시가 너무 많다는 것이다. 구글의 인기 있는 이스티오(Istio), 오픈소스 링커드(Linkerd), 해시코프(HashiCorp)의 컨설(Consul)을 비롯해 F5의 아스펜 메시(Aspen Mesh)와 같이 실험적인 툴까지 있다 보니, 하나를 선택하기는 어렵고 조직 전체에서 하나로 표준화하기는 더 어렵다.

현재 애저 쿠버네티스 서비스와 함께 서비스 메시를 사용하려면 AKS 문서의 지침을 참고해서 이스티오, 링커드 또는 컨설을 사용하는 것이 좋다. 이 방법은 서비스 메시와 AKS에서 실행되는 쿠버네티스 클러스터를 관리하기 위한 별도의 가상머신이 필요하므로 가장 쉬운 접근 방법은 아니다. 

현재 개발 중인 또 다른 접근 방법은 서비스 메시 인터페이스(SMI)다. SMI는 쿠버네티스를 서비스 메시와 연결하기 위한 표준 인터페이스 집합을 제공한다. 애저 쿠버네티스팀이 SMI 개발을 이끄는 가운데, 애저는 꽤 이전부터 SMI를 지원하고 있다.
 

SMI : 공통 서비스 메시 API 집합

SMI는 쿠버네티스와 같은 클라우드 네이티브 컴퓨팅 재단 프로젝트지만, 지금은 샌드박스 프로젝트일 뿐이다. 샌드박스 안에 있다는 말은 아직 안정적이지 않고, CNCF 개발 프로그램의 여러 단계를 거치면서 상당히 많이 바뀔 수 있음을 의미한다. 클라우드 및 쿠버네티스 솔루션 업체는 물론 SMI 개발을 후원하는 서비스 메시 프로젝트까지, SMI 개발의 지원군은 든든하다.

SMI는 쿠버네티스에서 SMI 준수 서비스 메시로 연결하기 위한 기본 API 모음을 제공하므로, 스크립트와 연산자가 하나의 제공업체에 종속될 필요 없이 모든 서비스 메시를 다룰 수 있다.

맞춤 리소스 정의 및 확장 API 서버 모음으로 구축된 SMI는 AKS와 같은 모든 인증된 쿠버네티스 배포판에 설치할 수 있다. 설치만 되면 익숙한 툴과 방법을 사용해서 애플리케이션과 서비스 메시 간의 연결을 정의할 수 있다. SMI는 애플리케이션을 이식 가능하게 해준다. 예를 들어 호환성에 대해 걱정할 필요 없이 SMI를 사용해서 이스티오로 로컬 쿠버네티스 인스턴스에서 개발하고, 모든 애플리케이션을 SMI 준수 서비스 메시를 사용하는 관리형 쿠버네티스로 가져올 수 있다. 

SMI는 그 자체로는 서비스 메시가 아니라는 점에 유의해야 한다. SMI는 서비스 메시가 공통적인 기본 기능 집합을 갖기 위해 구현해야 하는 사양이다. 서비스 메시에서 자체 확장과 인터페이스를 얼마든지 추가할 수 있지만, 추가된 것을 애플리케이션과 애플리케이션 운영팀이 사용하도록 하려면 그만큼 이점이 뚜렷해야 한다. SMI 프로젝트 개발자들은 서비스 메시의 정의가 발전하면서 사람들이 기대하는 기능 목록도 바뀌므로 SMI 사양으로 마이그레이션되는 새로운 기능에 대해서도 반대하지 않는다는 입장이다.
 

마이크로소프트의 SMI 구현, 오픈 서비스 메시

마이크로소프트는 최근 SMI 커뮤니티에서 해온 작업을 기반으로 하는 자체적인 첫 쿠버네티스 서비스 메시를 발표했다. 오픈 서비스 메시(Open Service Mesh, OSM)는 SMI 사양을 준수하는 가벼운 서비스 메시로, 깃허브에 호스팅되는 오픈소스 프로젝트다. 마이크로소프트는 OSM을 커뮤니티가 주도하는 프로젝트로 키우기를 원하며, 가능한 조기에 CNCF에 맡길 계획이다. OSM은 기존 서비스 메시 구성요소와 개념 위에 구축된, SMI의 기준 구현이라고 생각하면 된다.

마이크로소프트가 명확하게 밝히진 않았지만, 발표 내용과 문서에 애저에서의 서비스 메시 경험에 관한 내용이 나오는데, 운영자 측에 뚜렷한 초점을 두고 있다. 첫 블로그 글에서 미셸 누랄리는 OSM을 “쿠버네티스 운영자가 편하게 설치, 유지, 실행할 수 있다”고 설명했다. 합리적인 결정이다. OSM은 업체 중립적이지만, 결국 AKS를 위한 많은 서비스 메시 옵션 중 하나가 될 가능성이 높으므로 설치 및 관리하게 쉽게 만드는 것은 도입을 이끌기 위해 중요한 부분이다.

OSM은 다른 서비스 메시 프로젝트의 결과물을 기반으로 한다. 자체 제어 플레인이 있지만 데이터 플레인은 엔보이(Envoy) 기반이다. 이 부분 역시 실용적이고 합리적인 접근 방법이다. SMI의 핵심은 서비스 메시 인스턴스를 제어하고 관리하는 방법에 있다. 익숙한 엔보이를 사용해서 정책을 처리할 수 있다는 말은 OSM이 기존 스킬셋을 바탕으로 한다는 의미다. 즉, 어렵게 배울 필요가 없고 애플리케이션 운영자는 필요에 따라 제한된 SMI 기능 집합을 넘어 더 복잡한 엔보이 기능을 활용할 수 있게 된다.

현재 OSM은 공통 서비스 메시 기능 집합을 구현한다. 여기에는 트래픽 시프팅, 서비스 대 서비스 링크 보호, 액세스 제어 정책 적용, 서비스 관찰 가능성 처리에 대한 지원이 포함된다. OSM은 엔보이 사이드카 프록시를 자동으로 배포해서 새로운 애플리케이션과 서비스를 메시에 자동으로 추가한다.
 

OSM 배포 및 사용

OSM 알파 릴리스를 시작하려면 프로젝트의 깃허브 릴리스 페이지에서 명령줄 인터페이스인 osm을 다운로드한다. osm install을 실행하면 기본 네임스페이스 및 메시 이름과 함께 쿠버네티스 클러스터에 OSM 제어 플레인이 추가된다. 이는 설치 시 변경할 수 있다. OSM이 설치되어 실행되면 메시에 서비스를 추가하고 정책 정의를 사용해 쿠버네티스 네임스페이스를 추가하고 관리되는 네임스페이스의 모든 팟(pod)에 사이드카 프록시를 자동으로 추가할 수 있다.

이렇게 해서 선택한 정책이 구현되므로 배포를 시작하기 전에 설계된 SMI 정책 집합을 두는 것이 좋다. OSM 깃허브 리포지토리의 샘플 정책을 사용하면 시작하는 데 도움이 될 것이다. OSM에는 프로메테우스(Prometheus) 모니터링 툴킷과 그라파나(Grafana) 시각화 툴이 포함되므로 서비스 메시와 쿠버네티스 애플리케이션의 실행 상황을 신속하게 확인할 수 있다.

쿠버네티스는 현대의 클라우드 네이티브 애플리케이션을 위한 중요한 인프라이므로 그에 걸맞게 다뤄야 한다. 이를 위해서는 쿠버네티스에서 실행되는 애플리케이션과는 별도로 관리해야 한다. AKS, OSM, 깃, 애저 아크의 조합은 관리형 쿠버네티스 애플리케이션 환경을 위한 토대를 제공한다. 애플리케이션 인프라 팀은 AKS와 OSM을 관리하면서 애플리케이션과 서비스를 위한 정책을 설정하고, 깃과 아크는 애플리케이션 개발과 배포를 제어하고, 실시간 애플리케이션 지표는 OSM의 관찰 툴을 통해 전달된다.

이러한 모든 요소가 구체화되기까지는 얼마간의 시간이 필요하겠지만 마이크로소프트가 분산 애플리케이션 관리 및 이를 위해 필요한 툴에 상당한 공을 들이고 있음은 분명하다. 기반 요소인 AKS가 있고 OSM과 아크가 추가된 마당에 기다릴 필요가 없다. 지금 바로 실험실에서 OSM과 아크로 프로토타입을 만들고 엔보이를 서비스 메시로 사용해 애저에서 쿠버네티스를 빌드하고 배포하면서 프로덕션용으로 사용할 수 있는 시점을 준비할 수 있다. 그렇게 오래 기다리지 않아도 될 것이다. editor@itworld,co,kr


2020.08.13

마이크로소프트 오픈 서비스 메시의 이해

Simon Bisson | InfoWorld
불과 몇 년 전에는 인프라에 대해 이야기한다면 곧 물리 인프라, 즉 서버와 메모리, 디스크, 네트워크 스위치, 그리고 이를 연결하기 위한 온갖 케이블 작업을 의미했다. 필자는 이런저런 숫자를 입력하면 수천, 수백만의 사용자를 지원할 수 있는 웹 애플리케이션을 구축하는 데 필요한 하드웨어의 사양이 출력되는 스프레드시트를 사용하곤 했다.

하지만 이제 바뀌었다. 먼저 이러한 물리 서버 랙 위에 위치하는 가상 인프라가 등장했다. 하이퍼바이저와 소프트웨어 정의 네트워크, 스토리지를 사용해서 애플리케이션의 컴퓨팅 요구사항을 지정하고 프로비저닝하면 물리 하드웨어 위의 가상 네트워크는 알아서 관리됐다. 지금은 하이퍼스케일 퍼블릭 클라우드에서 수직 확장과 수평 확장을 자동으로 관리해주는 오케스트레이션 프레임워크 위에 분산 애플리케이션을 구축한다.
 
ⓒ Getty Images Bank
 

서비스 메시를 사용하여 분산 애플리케이션 인프라 관리하기

새로운 애플리케이션 인프라에는 자동 확장에 대응하고 로드밸런싱과 서비스 검색을 처리하고 정책 기반 보안을 지원하기 위한 지능을 갖춘 자체 인프라 계층이 필요하다.

마이크로서비스 컨테이너 외부에 위치하는 애플리케이션 인프라는 서비스 메시로 구현되며, 각 컨테이너가 사이드카로 실행되는 프록시에 연결된다. 프록시가 컨테이너 간 통신을 관리하므로 개발팀은 호스팅하는 서비스와 API에 집중할 수 있고, 애플리케이션 운영팀은 이런 모든 요소를 연결하는 서비스 메시를 관리한다.

서비스 메시를 구현하는 누구나 직면하는 가장 큰 문제는 서비스 메시가 너무 많다는 것이다. 구글의 인기 있는 이스티오(Istio), 오픈소스 링커드(Linkerd), 해시코프(HashiCorp)의 컨설(Consul)을 비롯해 F5의 아스펜 메시(Aspen Mesh)와 같이 실험적인 툴까지 있다 보니, 하나를 선택하기는 어렵고 조직 전체에서 하나로 표준화하기는 더 어렵다.

현재 애저 쿠버네티스 서비스와 함께 서비스 메시를 사용하려면 AKS 문서의 지침을 참고해서 이스티오, 링커드 또는 컨설을 사용하는 것이 좋다. 이 방법은 서비스 메시와 AKS에서 실행되는 쿠버네티스 클러스터를 관리하기 위한 별도의 가상머신이 필요하므로 가장 쉬운 접근 방법은 아니다. 

현재 개발 중인 또 다른 접근 방법은 서비스 메시 인터페이스(SMI)다. SMI는 쿠버네티스를 서비스 메시와 연결하기 위한 표준 인터페이스 집합을 제공한다. 애저 쿠버네티스팀이 SMI 개발을 이끄는 가운데, 애저는 꽤 이전부터 SMI를 지원하고 있다.
 

SMI : 공통 서비스 메시 API 집합

SMI는 쿠버네티스와 같은 클라우드 네이티브 컴퓨팅 재단 프로젝트지만, 지금은 샌드박스 프로젝트일 뿐이다. 샌드박스 안에 있다는 말은 아직 안정적이지 않고, CNCF 개발 프로그램의 여러 단계를 거치면서 상당히 많이 바뀔 수 있음을 의미한다. 클라우드 및 쿠버네티스 솔루션 업체는 물론 SMI 개발을 후원하는 서비스 메시 프로젝트까지, SMI 개발의 지원군은 든든하다.

SMI는 쿠버네티스에서 SMI 준수 서비스 메시로 연결하기 위한 기본 API 모음을 제공하므로, 스크립트와 연산자가 하나의 제공업체에 종속될 필요 없이 모든 서비스 메시를 다룰 수 있다.

맞춤 리소스 정의 및 확장 API 서버 모음으로 구축된 SMI는 AKS와 같은 모든 인증된 쿠버네티스 배포판에 설치할 수 있다. 설치만 되면 익숙한 툴과 방법을 사용해서 애플리케이션과 서비스 메시 간의 연결을 정의할 수 있다. SMI는 애플리케이션을 이식 가능하게 해준다. 예를 들어 호환성에 대해 걱정할 필요 없이 SMI를 사용해서 이스티오로 로컬 쿠버네티스 인스턴스에서 개발하고, 모든 애플리케이션을 SMI 준수 서비스 메시를 사용하는 관리형 쿠버네티스로 가져올 수 있다. 

SMI는 그 자체로는 서비스 메시가 아니라는 점에 유의해야 한다. SMI는 서비스 메시가 공통적인 기본 기능 집합을 갖기 위해 구현해야 하는 사양이다. 서비스 메시에서 자체 확장과 인터페이스를 얼마든지 추가할 수 있지만, 추가된 것을 애플리케이션과 애플리케이션 운영팀이 사용하도록 하려면 그만큼 이점이 뚜렷해야 한다. SMI 프로젝트 개발자들은 서비스 메시의 정의가 발전하면서 사람들이 기대하는 기능 목록도 바뀌므로 SMI 사양으로 마이그레이션되는 새로운 기능에 대해서도 반대하지 않는다는 입장이다.
 

마이크로소프트의 SMI 구현, 오픈 서비스 메시

마이크로소프트는 최근 SMI 커뮤니티에서 해온 작업을 기반으로 하는 자체적인 첫 쿠버네티스 서비스 메시를 발표했다. 오픈 서비스 메시(Open Service Mesh, OSM)는 SMI 사양을 준수하는 가벼운 서비스 메시로, 깃허브에 호스팅되는 오픈소스 프로젝트다. 마이크로소프트는 OSM을 커뮤니티가 주도하는 프로젝트로 키우기를 원하며, 가능한 조기에 CNCF에 맡길 계획이다. OSM은 기존 서비스 메시 구성요소와 개념 위에 구축된, SMI의 기준 구현이라고 생각하면 된다.

마이크로소프트가 명확하게 밝히진 않았지만, 발표 내용과 문서에 애저에서의 서비스 메시 경험에 관한 내용이 나오는데, 운영자 측에 뚜렷한 초점을 두고 있다. 첫 블로그 글에서 미셸 누랄리는 OSM을 “쿠버네티스 운영자가 편하게 설치, 유지, 실행할 수 있다”고 설명했다. 합리적인 결정이다. OSM은 업체 중립적이지만, 결국 AKS를 위한 많은 서비스 메시 옵션 중 하나가 될 가능성이 높으므로 설치 및 관리하게 쉽게 만드는 것은 도입을 이끌기 위해 중요한 부분이다.

OSM은 다른 서비스 메시 프로젝트의 결과물을 기반으로 한다. 자체 제어 플레인이 있지만 데이터 플레인은 엔보이(Envoy) 기반이다. 이 부분 역시 실용적이고 합리적인 접근 방법이다. SMI의 핵심은 서비스 메시 인스턴스를 제어하고 관리하는 방법에 있다. 익숙한 엔보이를 사용해서 정책을 처리할 수 있다는 말은 OSM이 기존 스킬셋을 바탕으로 한다는 의미다. 즉, 어렵게 배울 필요가 없고 애플리케이션 운영자는 필요에 따라 제한된 SMI 기능 집합을 넘어 더 복잡한 엔보이 기능을 활용할 수 있게 된다.

현재 OSM은 공통 서비스 메시 기능 집합을 구현한다. 여기에는 트래픽 시프팅, 서비스 대 서비스 링크 보호, 액세스 제어 정책 적용, 서비스 관찰 가능성 처리에 대한 지원이 포함된다. OSM은 엔보이 사이드카 프록시를 자동으로 배포해서 새로운 애플리케이션과 서비스를 메시에 자동으로 추가한다.
 

OSM 배포 및 사용

OSM 알파 릴리스를 시작하려면 프로젝트의 깃허브 릴리스 페이지에서 명령줄 인터페이스인 osm을 다운로드한다. osm install을 실행하면 기본 네임스페이스 및 메시 이름과 함께 쿠버네티스 클러스터에 OSM 제어 플레인이 추가된다. 이는 설치 시 변경할 수 있다. OSM이 설치되어 실행되면 메시에 서비스를 추가하고 정책 정의를 사용해 쿠버네티스 네임스페이스를 추가하고 관리되는 네임스페이스의 모든 팟(pod)에 사이드카 프록시를 자동으로 추가할 수 있다.

이렇게 해서 선택한 정책이 구현되므로 배포를 시작하기 전에 설계된 SMI 정책 집합을 두는 것이 좋다. OSM 깃허브 리포지토리의 샘플 정책을 사용하면 시작하는 데 도움이 될 것이다. OSM에는 프로메테우스(Prometheus) 모니터링 툴킷과 그라파나(Grafana) 시각화 툴이 포함되므로 서비스 메시와 쿠버네티스 애플리케이션의 실행 상황을 신속하게 확인할 수 있다.

쿠버네티스는 현대의 클라우드 네이티브 애플리케이션을 위한 중요한 인프라이므로 그에 걸맞게 다뤄야 한다. 이를 위해서는 쿠버네티스에서 실행되는 애플리케이션과는 별도로 관리해야 한다. AKS, OSM, 깃, 애저 아크의 조합은 관리형 쿠버네티스 애플리케이션 환경을 위한 토대를 제공한다. 애플리케이션 인프라 팀은 AKS와 OSM을 관리하면서 애플리케이션과 서비스를 위한 정책을 설정하고, 깃과 아크는 애플리케이션 개발과 배포를 제어하고, 실시간 애플리케이션 지표는 OSM의 관찰 툴을 통해 전달된다.

이러한 모든 요소가 구체화되기까지는 얼마간의 시간이 필요하겠지만 마이크로소프트가 분산 애플리케이션 관리 및 이를 위해 필요한 툴에 상당한 공을 들이고 있음은 분명하다. 기반 요소인 AKS가 있고 OSM과 아크가 추가된 마당에 기다릴 필요가 없다. 지금 바로 실험실에서 OSM과 아크로 프로토타입을 만들고 엔보이를 서비스 메시로 사용해 애저에서 쿠버네티스를 빌드하고 배포하면서 프로덕션용으로 사용할 수 있는 시점을 준비할 수 있다. 그렇게 오래 기다리지 않아도 될 것이다. editor@itworld,co,kr


X