2018.04.12

크로스 클라우드 도입한 애저와 이를 활용하는 방법

Simon Bisson | InfoWorld
2000년대 초반, IT 컨설팅 업체에서 아키텍트로 일할 당시 필자는 SOA(Service Oriented Architectures)가 제안하는 밝은 미래에 매료됐다. 애플리케이션 개발에 API 우선 접근 방식을 택하는 것이나, 애플리케이션 통합에 메시지 및 이벤트 중심 접근 방식을 택하는 것 모두 상당히 합리적으로 느껴졌다.

그러나 그 꿈은 갈수록 심화되는 복잡한 표준의 미로 속에서 사라지고 말았다. 점점 늘어나는 WS-* 프로토콜 군에 이런저런 기능이 추가되면서 비교적 단순한 SOAP의 원격 프로시저 호출 체계는 모습을 감췄다.

그렇게 보면 현재 클라우드 네이티브 플랫폼 세계에서 일어나는 일 대부분이 필자에게 익숙하게 느껴지는 것도 놀랍지 않다. 지금 우리는 쿠버네티스(Kubernetes)와 같은 플랫폼 위에서 마이크로서비스 아키텍처 구축의 일부로 다수의 동일한 개념을 사용하고 있다.

SOAP와 마찬가지로 기반 개념은 하나의 퍼블릭 클라우드에서 작동하면서 온프레미스 시스템에서 퍼블릭 클라우드로, 그리고 클라우드에서 클라우드로 애플리케이션과 서비스를 연결할 수 있는 개방형 툴 집합이다. 그 가운데서도 가장 흥미로운 점은 크로스 클라우드(cross-cloud) 옵션이다. 3대 퍼블릭 클라우드 업체 각기 다른 강점이 있으니, 애저와 AWS, 구글 클라우드 플랫폼의 장점만 취하는 애플리케이션을 만들면 좋지 않겠냐는 개념이다.

오픈 서비스 브로커란 무엇인가
이 크로스 클라우드 환경을 실현하기 위한 핵심 기술 가운데 하나는 오픈 서비스 브로커(Open Service Broker, OSB)다. 서비스 브로커의 SOA 개념을 기반한 오픈 서비스 브로커 API는 가용한 서비스 플랫폼 목록에서 정보를 취하고 서비스 가입 프로세스를 자동화하고 프로비저닝하고 애플리케이션을 연결하는 수단을 제공한다.

또한 그 역방향 작업도 처리할 수 있으므로 더 이상 서비스 사용을 원하지 않을 경우 애플리케이션 인스턴스에서 연결을 없애고 서비스를 디프로비전(deprovisions)하면 된다.

피보탈(Pivotal), 구글을 포함한 여러 클라우드 네이티브 플랫폼 업체의 인력으로 구성된 팀이 클라우드 파운드리(Cloud Foundry), 쿠버네티스, 오픈 시프트(Open Shift)와 같은 일반적인 플랫폼을 위한 구현을 개발했다. 마이크로소프트는 코스모스(Cosmos) DB, 애저 SQL, 애저 컨테이너 인스턴스, 애저 서비스 버스를 포함한 몇 가지 주요 애저 서비스를 지원하는 자체 오픈 서비스 브로커(OSB) 구현을 개발 중이다.

애저, OSB 도입
깃허브(GitHub)에서 제공되는 애저용 오픈 서비스 브로커(Open Service Broker for Azure, OSBA)는 오픈 서비스 브로커를 지원하는 모든 플랫폼에 설치되며 어디서나 실행된다. 이는 AWS의 쿠버네티스 구현에서 실행되는 애플리케이션 또는 온프레미스 클라우드 파운드리에서 코스모스 DB와 같은 툴을 이용하고자 하는 개발자에게 큰 이점이다. 애저의 기존 서비스 브로커를 마이크로소프트 내부가 아닌 공개적으로 개발된 하나의 공통 툴로 대체한다.

MIT 라이선스에 따라 공표된 OSBA는 현재까지 340건의 커밋과 8개의 릴리스가 나올 만큼 활발한 프로젝트다. 프로덕션에서 사용 가능한 수준에 근접한 알파 코드지만 아직 개발 단계이므로 릴리스 간에 단절적인 변화(breaking change)가 생길 가능성이 있다.

애저용 오픈 서비스 브로커를 사용하기는 쉽다. 빠른 시작을 돕기 위한 여러 가지 문서가 있다. 샘플에는 로컬 미니큐브(Minikube) 테스트 인스턴스, 클라우드 파운드리 설치 및 AWS 쿠버네티스 클러스터, 그리고 마이크로소프트 자체의 애저 컨테이너 인스턴스에서의 작업이 포함된다. 마이크로소프트 OSBA는 데이스(Deis) 팀의 작업, 특히 헬름(Helm) 패키지 관리자를 기반으로 한다. 따라서 쿠버네티스 클러스터에서 헬름을 설치하는 것부터 시작해 서비스 카탈로그와 OSBA를 설치할 준비를 해야 한다.

OSBA를 사용해 서비스 인스턴스 관리하기
OSBA를 설치하면 쿠버네티스 명령줄 도구를 사용해 새로운 서비스 인스턴스를 추가할 수 있다. 한 가지 중요한 툴은 애저 CLI다. 이 툴은 컴퓨터에서 애저 리소스에 접속할 수 있게 해주며 맥OS, 윈도우, 리눅스를 지원한다.

설치하면 애저에 로그인해서 가용 리소스를 목록화하는 것부터 시작해 CLI를 사용해 OSBA 작업에 필요한 정보를 수집할 수 있다. 필수 로그인 정보 및 애저 서비스 프로비전을 처리하는 데 필요한 키에 대해 환경 변수를 만들면 도구 사용 과정을 간소화할 수 있으며, 이를 통해 애저 로그온 세부 정보를 공개적으로 저장하지 않고도 보다 쉽게 작업을 자동화할 수 있다.

이 정보를 확보하면 애저에서 실행되는 OSBA 서비스를 관리하거나 다른 곳에서 프로비전된 서비스가 정상 작동하는지 여부를 확인할 수 있다.

쿠버네티스에 대한 명령줄 접속을 통해 애플리케이션에 바인딩하기 전에 서비스 카탈로그에서 직접 애저 서비스를 프로비전할 수 있다. 이 프로세스는 비동기적이며 다소 시간이 걸릴 수 있으므로 애플리케이션을 배포하고 시작하기 전에 모든 자동화의 완료 여부를 잊지 말고 확인해야 한다. 쿠버네티스 시크릿(secret)이 서비스를 위해 연결 데이터를 저장하므로 애플리케이션에서 언제든 사용할 수 있다. 서비스 디프로비전도 같은 방식으로 가능하다. 즉, 먼저 바인딩을 해제한 다음 디프로비전한다.

똑 같은 프로세스가 퍼블릭과 프라이빗 클라우드 플랫폼에 걸쳐 작동하므로 코드가 실행되는 위치에 관계없이 애저 서비스를 다룰 수 있는 공통된 환경이 만들어진다. 현대 애플리케이션에서 클라우드 이식성(Cloud portability)은 중요한 요구 사항이다. OSBA를 사용해 어디서나 애저 서비스에 대한 접속을 프로비전하는 방법은 이를 실현하는 데 큰 역할을 하고 마이크로소프트의 클라우드 플랫폼 접근성을 더욱 높인다.

서비스 API, 제대로 처리하기
애저의 오픈 서비스 브로커 구현은 확실히 애저 서비스에 사용하기 위한 것이지만 범용 OSB를 설치해 자체 서비스와 사용해도 무방하다. 이 경우 자체 API를 구현하고 관리할 방법을 생각해야 한다. 쿠버네티스 매니페스트(Kubernetes manifests) 또는 헬름 차트(Helm charts)에 OSBA 호출을 포함하면 명령줄 하나로 범용 서비스 카탈로그에서 애플리케이션 배포하고 지원 서비스를 프로비전한 다음 애플리케이션을 실행할 수 있다. 이렇게 하면 MySQL 지원이 필요한 애플리케이션을 애저의 MySQL 서비스에서 실행할 수 있다.

이는 현대 애플리케이션에서 중대한 부분이다. 애플리케이션 설계 문제일 뿐만 아니라 애플리케이션 라이프사이클과 수명 문제이기도 하기 때문이다. 이렇게 되면 더 이상 자기 자신을 위한 코드를 쓰는 것이 아니라, 자신의 서비스를 사용할 모든 개발자를 위한 코드를 쓰게 된다. API 설계와 개발에 대해 생각하고 적절한 접근 방법을 선택하고(RESTful과 RPC, GraphOL 사이에서 선택) 버전 관리와 폐기(deprecation) 방법에 대해서도 생각해야 한다.

모든 API에는 각자 고유의 사용 사례가 있지만 API를 공개로 전환하고 나면 자신의 역할도 바뀐다. 개발자일 뿐만 아니라 관리인의 역할도 해야 한다. 오픈 서비스 브로커용으로 서비스를 게시한다는 것은 다른 누군가의 일정표에 따라 작업해야 함을 의미한다.

옥타의 키스 케이시가 말했듯이 "개발자는 뭔가 유용한 일을 하고자 하다가 집으로 간다." 따라서 서비스 카탈로그 및 오픈 서비스 브로커와 같은 툴을 통해 API를 제공하기에 앞서 API가 완전히 준비된, 견고한 상태가 되도록 해야 한다. editor@itworld.co.kr  

2018.04.12

크로스 클라우드 도입한 애저와 이를 활용하는 방법

Simon Bisson | InfoWorld
2000년대 초반, IT 컨설팅 업체에서 아키텍트로 일할 당시 필자는 SOA(Service Oriented Architectures)가 제안하는 밝은 미래에 매료됐다. 애플리케이션 개발에 API 우선 접근 방식을 택하는 것이나, 애플리케이션 통합에 메시지 및 이벤트 중심 접근 방식을 택하는 것 모두 상당히 합리적으로 느껴졌다.

그러나 그 꿈은 갈수록 심화되는 복잡한 표준의 미로 속에서 사라지고 말았다. 점점 늘어나는 WS-* 프로토콜 군에 이런저런 기능이 추가되면서 비교적 단순한 SOAP의 원격 프로시저 호출 체계는 모습을 감췄다.

그렇게 보면 현재 클라우드 네이티브 플랫폼 세계에서 일어나는 일 대부분이 필자에게 익숙하게 느껴지는 것도 놀랍지 않다. 지금 우리는 쿠버네티스(Kubernetes)와 같은 플랫폼 위에서 마이크로서비스 아키텍처 구축의 일부로 다수의 동일한 개념을 사용하고 있다.

SOAP와 마찬가지로 기반 개념은 하나의 퍼블릭 클라우드에서 작동하면서 온프레미스 시스템에서 퍼블릭 클라우드로, 그리고 클라우드에서 클라우드로 애플리케이션과 서비스를 연결할 수 있는 개방형 툴 집합이다. 그 가운데서도 가장 흥미로운 점은 크로스 클라우드(cross-cloud) 옵션이다. 3대 퍼블릭 클라우드 업체 각기 다른 강점이 있으니, 애저와 AWS, 구글 클라우드 플랫폼의 장점만 취하는 애플리케이션을 만들면 좋지 않겠냐는 개념이다.

오픈 서비스 브로커란 무엇인가
이 크로스 클라우드 환경을 실현하기 위한 핵심 기술 가운데 하나는 오픈 서비스 브로커(Open Service Broker, OSB)다. 서비스 브로커의 SOA 개념을 기반한 오픈 서비스 브로커 API는 가용한 서비스 플랫폼 목록에서 정보를 취하고 서비스 가입 프로세스를 자동화하고 프로비저닝하고 애플리케이션을 연결하는 수단을 제공한다.

또한 그 역방향 작업도 처리할 수 있으므로 더 이상 서비스 사용을 원하지 않을 경우 애플리케이션 인스턴스에서 연결을 없애고 서비스를 디프로비전(deprovisions)하면 된다.

피보탈(Pivotal), 구글을 포함한 여러 클라우드 네이티브 플랫폼 업체의 인력으로 구성된 팀이 클라우드 파운드리(Cloud Foundry), 쿠버네티스, 오픈 시프트(Open Shift)와 같은 일반적인 플랫폼을 위한 구현을 개발했다. 마이크로소프트는 코스모스(Cosmos) DB, 애저 SQL, 애저 컨테이너 인스턴스, 애저 서비스 버스를 포함한 몇 가지 주요 애저 서비스를 지원하는 자체 오픈 서비스 브로커(OSB) 구현을 개발 중이다.

애저, OSB 도입
깃허브(GitHub)에서 제공되는 애저용 오픈 서비스 브로커(Open Service Broker for Azure, OSBA)는 오픈 서비스 브로커를 지원하는 모든 플랫폼에 설치되며 어디서나 실행된다. 이는 AWS의 쿠버네티스 구현에서 실행되는 애플리케이션 또는 온프레미스 클라우드 파운드리에서 코스모스 DB와 같은 툴을 이용하고자 하는 개발자에게 큰 이점이다. 애저의 기존 서비스 브로커를 마이크로소프트 내부가 아닌 공개적으로 개발된 하나의 공통 툴로 대체한다.

MIT 라이선스에 따라 공표된 OSBA는 현재까지 340건의 커밋과 8개의 릴리스가 나올 만큼 활발한 프로젝트다. 프로덕션에서 사용 가능한 수준에 근접한 알파 코드지만 아직 개발 단계이므로 릴리스 간에 단절적인 변화(breaking change)가 생길 가능성이 있다.

애저용 오픈 서비스 브로커를 사용하기는 쉽다. 빠른 시작을 돕기 위한 여러 가지 문서가 있다. 샘플에는 로컬 미니큐브(Minikube) 테스트 인스턴스, 클라우드 파운드리 설치 및 AWS 쿠버네티스 클러스터, 그리고 마이크로소프트 자체의 애저 컨테이너 인스턴스에서의 작업이 포함된다. 마이크로소프트 OSBA는 데이스(Deis) 팀의 작업, 특히 헬름(Helm) 패키지 관리자를 기반으로 한다. 따라서 쿠버네티스 클러스터에서 헬름을 설치하는 것부터 시작해 서비스 카탈로그와 OSBA를 설치할 준비를 해야 한다.

OSBA를 사용해 서비스 인스턴스 관리하기
OSBA를 설치하면 쿠버네티스 명령줄 도구를 사용해 새로운 서비스 인스턴스를 추가할 수 있다. 한 가지 중요한 툴은 애저 CLI다. 이 툴은 컴퓨터에서 애저 리소스에 접속할 수 있게 해주며 맥OS, 윈도우, 리눅스를 지원한다.

설치하면 애저에 로그인해서 가용 리소스를 목록화하는 것부터 시작해 CLI를 사용해 OSBA 작업에 필요한 정보를 수집할 수 있다. 필수 로그인 정보 및 애저 서비스 프로비전을 처리하는 데 필요한 키에 대해 환경 변수를 만들면 도구 사용 과정을 간소화할 수 있으며, 이를 통해 애저 로그온 세부 정보를 공개적으로 저장하지 않고도 보다 쉽게 작업을 자동화할 수 있다.

이 정보를 확보하면 애저에서 실행되는 OSBA 서비스를 관리하거나 다른 곳에서 프로비전된 서비스가 정상 작동하는지 여부를 확인할 수 있다.

쿠버네티스에 대한 명령줄 접속을 통해 애플리케이션에 바인딩하기 전에 서비스 카탈로그에서 직접 애저 서비스를 프로비전할 수 있다. 이 프로세스는 비동기적이며 다소 시간이 걸릴 수 있으므로 애플리케이션을 배포하고 시작하기 전에 모든 자동화의 완료 여부를 잊지 말고 확인해야 한다. 쿠버네티스 시크릿(secret)이 서비스를 위해 연결 데이터를 저장하므로 애플리케이션에서 언제든 사용할 수 있다. 서비스 디프로비전도 같은 방식으로 가능하다. 즉, 먼저 바인딩을 해제한 다음 디프로비전한다.

똑 같은 프로세스가 퍼블릭과 프라이빗 클라우드 플랫폼에 걸쳐 작동하므로 코드가 실행되는 위치에 관계없이 애저 서비스를 다룰 수 있는 공통된 환경이 만들어진다. 현대 애플리케이션에서 클라우드 이식성(Cloud portability)은 중요한 요구 사항이다. OSBA를 사용해 어디서나 애저 서비스에 대한 접속을 프로비전하는 방법은 이를 실현하는 데 큰 역할을 하고 마이크로소프트의 클라우드 플랫폼 접근성을 더욱 높인다.

서비스 API, 제대로 처리하기
애저의 오픈 서비스 브로커 구현은 확실히 애저 서비스에 사용하기 위한 것이지만 범용 OSB를 설치해 자체 서비스와 사용해도 무방하다. 이 경우 자체 API를 구현하고 관리할 방법을 생각해야 한다. 쿠버네티스 매니페스트(Kubernetes manifests) 또는 헬름 차트(Helm charts)에 OSBA 호출을 포함하면 명령줄 하나로 범용 서비스 카탈로그에서 애플리케이션 배포하고 지원 서비스를 프로비전한 다음 애플리케이션을 실행할 수 있다. 이렇게 하면 MySQL 지원이 필요한 애플리케이션을 애저의 MySQL 서비스에서 실행할 수 있다.

이는 현대 애플리케이션에서 중대한 부분이다. 애플리케이션 설계 문제일 뿐만 아니라 애플리케이션 라이프사이클과 수명 문제이기도 하기 때문이다. 이렇게 되면 더 이상 자기 자신을 위한 코드를 쓰는 것이 아니라, 자신의 서비스를 사용할 모든 개발자를 위한 코드를 쓰게 된다. API 설계와 개발에 대해 생각하고 적절한 접근 방법을 선택하고(RESTful과 RPC, GraphOL 사이에서 선택) 버전 관리와 폐기(deprecation) 방법에 대해서도 생각해야 한다.

모든 API에는 각자 고유의 사용 사례가 있지만 API를 공개로 전환하고 나면 자신의 역할도 바뀐다. 개발자일 뿐만 아니라 관리인의 역할도 해야 한다. 오픈 서비스 브로커용으로 서비스를 게시한다는 것은 다른 누군가의 일정표에 따라 작업해야 함을 의미한다.

옥타의 키스 케이시가 말했듯이 "개발자는 뭔가 유용한 일을 하고자 하다가 집으로 간다." 따라서 서비스 카탈로그 및 오픈 서비스 브로커와 같은 툴을 통해 API를 제공하기에 앞서 API가 완전히 준비된, 견고한 상태가 되도록 해야 한다. editor@itworld.co.kr  

X