2015 Electronics and Telecommunications Trends 2015 한국전자통신연구원 95

Size: px

Start display at page:

Download "2015 Electronics and Telecommunications Trends 2015 한국전자통신연구원 95"

미란 뇌
5 years ago
Views:

1 2015 Electronics and Telecommunications Trends 2015 한국전자통신연구원 95

Ⅰ. 서론오픈스택 (OpenStack) 은클라우드인프라를손쉽게구축할수있는플랫폼으로 2010 년에 Rackspace 와 NASA 의오픈소스프로젝트로시작되어현재전세계클라우드업계에서가장빠르게세력을팽창하고있는클라우드플랫폼프로젝트이다 [1].

오케스트레이션이란가상자원들의구성과설정을정해진방식과순서에맞게자동화하는로직을통해복잡한인프라의생성및관리를단순화하고효율적으로운영하도록하는기술이다.

현재 Heat 프로젝트는 Red Hat 을중심으로 Mirantis, Rackspace 등이적극적으로참여하고있다 [( 그림 1) 참조 ][4].

하지만, 공식적인프로젝트로진행되면서 HOT(Heat Orchestration Template) 라는자체템플릿을정의하였고점진적으로클라우드포메이션의색깔을벗고독자적인오케스트레이션서비스를제공하는방식으로발전해가고있다.

2 Ⅰ. 서론오픈스택 (OpenStack) 은클라우드인프라를손쉽게구축할수있는플랫폼으로 2010 년에 Rackspace 와 NASA 의오픈소스프로젝트로시작되어현재전세계클라우드업계에서가장빠르게세력을팽창하고있는클라우드플랫폼프로젝트이다 [1]. 오픈스택은그동안컴퓨팅이나네트워크, 스토리지등의기본적인기능을중심으로구현되어왔지만최근들어과금이나오케스트레이션, 대시보드등의기능들을추가하면서기술적인변곡점을맞이하고있다. 특히, 오케스트레이션은많은기업들이오픈스택기반의소프트웨어정의데이터센터를구축하기위한기반기술로써고려되고있다 [2]. 오케스트레이션이란가상자원들의구성과설정을정해진방식과순서에맞게자동화하는로직을통해복잡한인프라의생성및관리를단순화하고효율적으로운영하도록하는기술이다. Heat 는템플릿기반의오케스트레이션엔진을구현하기위한오픈스택프로젝트로 2012 년부터실험적프로젝트로진행되어왔고오픈스택 Havana 버전부터공식적인프로젝트로배포판에포함되기시작했다 [3]. 현재 Heat 프로젝트는 Red Hat 을중심으로 Mirantis, Rackspace 등이적극적으로참여하고있다 [( 그림 1) 참조 ][4]. 초기의실험적프로젝트에서 Heat 는아마존웹서비스 (AWS: Amazon Web Service) 의오케스트레이션서비스인클라우드포메이션 (CFN: CloudFormation)[5] 을벤치마킹하여 CFN 템플릿을기반으로하는오케스트레이션엔진을개발하였다. 하지만, 공식적인프로젝트로진행되면서 HOT(Heat Orchestration Template) 라는자체템플릿을정의하였고점진적으로클라우드포메이션의색깔을벗고독자적인오케스트레이션서비스를제공하는방식으로발전해가고있다. 본고에서는 Heat 구조에대한간략한소개와함께오케스트레이션서비스의중심에있는 HOT 템플릿의구조및구성요소들을정리하고템플릿간의참조관계를설명하는 Nested stack 개념을소개한다. Ⅱ. Heat 구조 Heat 는여타의오픈스택프로젝트와마찬가지로 Python 언어로구현되어있으며 CLI(Command Line Interface) 및 API(Application Programming Interface) 서버와같은사용자인터페이스와템플릿을기반으로가상자원들을구성하고설정하는로직인 Heat Engine 으로구성된다. ( 그림 2) 는 Heat 의기본구조를도시한다. 사용자는 API 를직접호출하여오케스트레이션서비스를요청하거나 CLI 를통해동일한작업을수행할수있다. CLI 역시사용자명령을 API 로변환하여처리하게된다. 현재 Heat API 서버에서지원하는 API 의종류는두가지로하나는아마존웹서비스의클라우드포메 96 전자통신동향분석제 30 권제 2 호 2015 년 4 월

3 이션 API 이고, 또하나는 Heat 에서독자적으로정의한 API 이다. 두가지 API 모두 HTTP 프로토콜을활용하지만클라우드포메이션 API 는 Query API 방식이며 Heat API 는 Restful API 방식을따른다. 향후 Heat 에서는클라우드포메이션 API 는배제하고 Heat API 만을지원할것이라고한다. CLI 및 API 호출을통해전달된사용자의요청데이터및템플릿은 API 서버를통해수신되고 API 서버는 AMQP(Advanced Message Queueing Protocol) 규격기반의메시지통신을통해 Heat Engine 으로이를전달한다. Heat 에서 AMPQ 기반메시지통신은오픈소스인 RabbitMQ[6] 를활용하고있다. Heat Engine 은수신한템플릿과 API 의파라미터에포함된사용자요청데이터를기반으로인프라및클라우드애플리케이션을생성하기위하여 Nova API, Neutron API 등과같은오픈스택프로젝트들의 API 를호출한다. 이때 Heat Engine 은인프라및클라우드애플리케이션을구성하는가상자원들간의상호의존관계를파악하고어떠한가상자원을먼저생성해야할지의존성그래프 (dependency graph) 를도출한후이를기반으로오픈스택프로젝트 API 의호출순서를파악한다. Ⅲ. Heat Orchestartion Template Heat 는템플릿기반의오케스트레이션서비스를제공하는프로젝트로사용자가구성하고자할가상자원들을템플릿에명시하도록한다. 템플릿은 JSON(Java- Script Object Notation) 이나 YAML(YAML Ain t Markup Language) 과같이사람이쉽게읽고작성할수있는텍스트기반의데이터인코딩방식을이용한다. 아마존웹서비스의 CFN 템플릿이 JSON 기반의표현방식을사용하는반면 HOT 템플릿은 YAML 을인코딩방식으로사용한다. YAML 방식이 JSON 방식에비해파싱 (parsing) 의부하가좀더크지만 JSON 과달리멀티라인스트링을지원하고주석처리가용이하다는장점을갖는다. 본장에서는 HOT 템플릿에대한구조와간략 한예제템플릿을소개한다. 1. HOT 템플릿구조 HOT 템플릿은 ( 그림 3) 과같이두개의필수구성요소인 heat_template_version 필드와 resources 섹션, 그리고네개의선택적구성요소인 description 필드, parameter_groups, parameters, outputs 섹션으로구성된다 [7]. Heat_template_version 필드는해당템플릿이어떤버전인지명시한다. 버전은날짜형태로표현되며현재 과 같이두가지버전이정의되어있다 버전은오픈스택의 Icehouse 버전까지구현된사항들을포함하며템플릿내에서 Heat 자체 Intrinsic Functions 과함께일부 CFN intrinsic function 을지원한다 (Intrinsic Function 은 3절에서자세히설명한다 ) 버전은오픈스택 Juno 버전까지추가되거나삭제된사항들을포함하고 Fn::Select 를제외한모든 CFN Intrinsic Function 들을지원하지않고 Heat 자체 Intrinsic Function 만을지원한다. Resources 섹션은가상자원들을정의하는부분으로 HOT 템플릿에는적어도하나의가상자원이 Resources 섹션에정의되어야한다. Resources 섹션의세부구조는다음절에서소개한다. Description 필드는 전홍석외 / OpenStack 오케스트레이션기술분석 97

4 템플릿에대해소개하는부분이다. Parameter_groups 섹션은사용자가템플릿에사용되는일련의파라미터들의입력순서를정의하고관련성있는파라미터들을그룹으로정의하기위한용도로사용된다. Parameter_groups 은해당그룹을지칭하는라벨과설명부분그리고해당그룹에포함된파라미터들의목록으로정의된다. Parameters 섹션은템플릿에서사용되는파라미터들의유형 (e.g. 문자열 (string)) 및의미, 기본값들을명시한다. Outputs 섹션은템플릿이실행된후, 그결과값으로제공할정보들을명시하는부분이다. Out-puts 섹션에서정의된결과값은 show stack Heat API 호출을통해사용자에게제공된다. Outputs 섹션에서결과값으로지정할수있는정보는생성된가상자원들의속성 (attribute) 들로각가상자원들의속성값에대한정의는웹상에공지된 OpenStack Resource Types[7] 을참조한다. 2. HOT Resources 섹션구조가상자원들은 HOT 템플릿 Resources 섹션에서두개의필수정보 (resource ID, type) 와네개의선택적정보 (properties, metadata, depends_on, update_policy, deletion_policy) 를통해정의된다. ( 그림 4) 의 Resources 섹션구조에서보듯이가상자원의정의는 Resource ID를명시하는것으로부터비롯 된다. Resource ID는가상자원을식별하기위한용도로템플릿내에서고유한값을가져야한다. Type 은정의하고자하는가상자원의유형을지정하는부분이다. 예를들어, 컴퓨팅유형의가상자원을정의하기위해서는 OS::Nova::Server 라는가상자원유형을지정하게된다. 실제가상자원들은오픈스택의여러하부프로젝트에서각각구현된것들로가상자원유형의표현은 OS:: 프로젝트 :: 가상자원 과같은형태로표기된다 ( 여기서 OS는 OpenStack 을의미함 ). ( 그림 5) 는오픈스택 Juno 버전까지정의된 67개의가상자원들의목록으로굵게표기된가상자원들은 Juno 버전에서새롭게추가된자원들이다. Properties 는가상자원의특성들을구체적으로설정하기위한부분이다. 선택된가상자원의유형별로설정할수있는특성들의목록은정의되어있다. 예를들어, OS::Nova::Server 가상자원유형을선택한경우, 서버의운영체제로사용할이미지 (image) 는설정해야할하나의특성이되고사용할이미지의 ID가해당특성의값이된다. 오픈스택가상자원별로정의된특성 (Properties) 들의정보는웹상에공지된 OpenStack Resource Types[8] 을참조한다. 메타데이터는상기지정된가상자원들이생성된이후가상자원에의해사용될메타데이터를정의하는부분이다. Depends_on 은가상자원들간에의존성을명시적으로정의하기위한정보로정의하고있는가상자원이다른특정가상자원에의존한다면, 해당특정가상자원의 Resource ID를 Depends_on 의값으로명시하면된다. Update_policy 는가상자원의업데이트정책을표현하는정보로 Heat Engine 이특정가상자원의업데이트를어떻게처리해야할지를정의하는부분이다. 하지만, 아직오프스택의가상자원들중에는 Update_policy 를사용하는자원은없다. 다만, 아마존웹서비스의 AWS::AutoScaling::AutoScalingGroup 가상자원에한정되어사용되고있다. Deletion_policy 는해당가상자원이삭제되는 98 전자통신동향분석제 30 권제 2 호 2015 년 4 월

5 경우에 적용될 정책을 나타내는 정보로 Delete, rinsic Function 이라고 한다. 오픈스택 Juno 버전까지 Retain, Snapshot 의 세가지 정책 중에 하나를 선택하 정의된 Intrinsic Function은 총 8개로 다음과 같다. 게 된다. 예를 들어, Deletion_policy, Retain 과 같이 정의된 경우에는 해당 가상 자원을 포함한 스택(stack) 이 삭제되는 경우에도 해당 가상 자원의 콘텐츠는 삭제 되지 않고 유지하게 된다. 가. Get_Attr 템플릿이 실행된 이후 생성된 가상 자원의 속성값을 얻기 위해 사용되는 내부함수로 해당 가상 자원의 Resource ID와 원하는 속성명을 명시하는 방식으로 사 3. Intrinsic Functions Heat에서 템플릿을 활용한다는 것은 기존에 정의된 템플릿을 재활용할 수 있다는 의미를 갖는다. 따라서 템 플릿에는 주로 정적인 정보를 명시하고 사용 목적에 따 용된다. 주로 HOT 템플릿의 outputs 섹션에서 생성된 가상 자원의 결과값을 도출하기 위해 사용된다. 나. Get_File 라 필요한 정보들은 사용자별 입력을 요구한다. 또한, 템플릿에 외부 파일을 참조하기 위한 내부함수이다. 가상 자원들이 실제 생성되기 이전에 가용하지 못한 값 파일은 URL(Uniform Resources Locator)이나 파일경 들은 템플릿 내부에서 동적으로 참조되어야 한다. HOT 로를 통해 참조되며 참조된 파일은 Heat API를 호출하 템플릿은 이렇게 동적으로 요구되는 정보를 처리하기 는 모듈(i.e., python-heatclient)에 의해 API Files 파 위한 내부함수를 정의하는데 이러한 내부함수를 Int- 라미터에 담겨 전달된다. 전홍석 외 / OpenStack 오케스트레이션 기술 분석 99

6 다. Get_Param 템플릿의입력파라미터를참조하기위한내부함수이다. 본내부함수를통해명시된파라미터들의값은템플릿이실행될시에입력되어야한다. 예를들어템플릿에서 OS::Nova::Server 유형의가상자원이갖는특성 (properties) 들중 flavor 값을 get_param 로참조한경우에는해당템플릿이실행될때, 사용자가 flavor 값을입력해야한다. 라. Get_Resource 템플릿내에서다른가상자원을참조하기위해사용하는내부함수이다. 참조할가상자원은동일한템플릿내에정의된자원으로한정하며참조대상의해당 Resource ID를이용하여참조한다. 마. List_Join 오픈스택 Juno 버전에서처음소개된내부함수로 버전의 HOT 템플릿부터적용된다. 본내부함수는지정한구분문자 (delimiter) 로문자열들을구분하기위해사용되는데예를들어, list_join: [ -, [ one, two, and three ]] 의경우에는구분문자 - 를사용하여주어진문자열목록을 one- two-and three 형태로표현하게된다. 바. Resourc_Facade Provider template 에정의된가상자원이 Parent template 에정의된가상자원의데이터를찾아가져오기위한내부함수이다. Provider template 과 paraent template 에대한자세한내용은 IV장에서소개한다. 사. Str_Replace 원하는문자열을동적으로생성하기위해사용하는내부함수이다. 사용방법은동적으로입력받아야할파라미터를 params 변수에할당하고상기파라미터를포 함한문자열을 template 변수에입력한다. 예를들어, ( 그림 6) 과같이동적으로할당되는서버의 IP 주소를포함한 URL를만들기위해서는상기서버의 IP 주소를 host 라는이름의파라미터로정의하고이를 params 변수에할당한후상기 host 파라미터를포함한문자열 을 template 변수에입력하면된다. 아. FN::Select FN::Select 내부함수는아마존웹서비스의 CFN 템플릿에서사용되던함수로인덱스값을이용하여객체목록들중에서한객체를반환하기위한함수이다. 예를들어, { Fn::Select : [ 1, [ apples, grapes, oranges, mangoes ]]} 의경우, apples, grapes, oranges, mangoes 라는객체목록들중에서인덱스값 1에해당하는 grapes 를반환하게된다. 참고로목록에대한인덱스값으로서수를사용하는경우에인덱스값의범위는 0부터 n-1 의값을갖게된다 (n은객체의개수 ). 반면객체목록이 name: value 형태의목록으로표현되는경우는인덱스값으로서수가아닌 name 을지정할수있다. 예를들어, OS::Neutron::Pool 가상자원의특성 (properties) 중하나인 vip는 name:value 형태의목록으로정의되는데 vip 의목록들중에서 port_id name 에해당하는 value 를반환하기위해서 FN::Select 내부함 100 전자통신동향분석제 30 권제 2 호 2015 년 4 월

7 수를사용하면다음과같다. {'Fn::Select': ['port_id', {get_attr: [pool, vip]}]}. 4. HOT 템플릿예제 ( 그림 7) 은가상자원으로컴퓨팅자원과네트워크포트자원을생성하는 HOT 템플릿을보여준다. 상기 HOT 템플릿은 버전의템플릿이 며총 5개파라미터 (name, instance_type, private_net_id, private_subent_id, image_id) 를정의하고있다. 5개의파라미터는 General parameters 라는이름의파라미터그룹으로분류하고있고사용자의파라미터입력순서를 name, image_id, instance_type, private_net_id, private_subent_id 순서로정의하고있다. Resources 섹션에생성할가상자원으로는서버와네트워크포트자 heat_template_version: description: Template (HOT) example parameter_groups: - label: General parameters description: General OpenStack parameters parameters: - name - image_id - instance_type - private_net_id - private_subnet_id parameters: name: description: sever name image_id: description: ID of the image to use for the instance to be created. default: centos-6.5-x86_64-cfntools instance_type: label: Instance Type description: Type of instance (flavor) to be used default: m1.medium private_net_id: description: ID of private network into which servers get deployed private_subnet_id: description: ID of private sub network into which servers get deployed resources: nova_instance: type: OS::Nova::Server properties: name: { get_parm: name } image: { get_param: image_id } flavor: { get_param: instance_type } key_name: { get_param: key_name } networks: - port: { get_resource: nova_instance_port } nova_instance_port: type: OS::Neutron::Port properties: network_id: { get_param: private_net_id } fixed_ips: - subnet_id: { get_param: private_subnet_id } outputs: nova_instance_private_ip: description: IP address of server1 in private network value: { get_attr: [ nova_instance, first_address ] } 전홍석외 / OpenStack 오케스트레이션기술분석 101

원을정의하고있으며각각의자원유형및특성값들을명시하고있다. 상기가상자원들의특성값들은 Intrinsice Function 을이용하여템플릿실행시에사용자의입력을받거나동적으로다른자원들을참조하도록하고있다. 템플릿실행후에받을결과값으로는 get_attr Intrinsic Function 을이용하여서버에할당된사설 IP 주소를정의하고있음을알수있다. Ⅳ.

그리고 Parent stack 을정의한템플릿을 Parent template, Nested stack 을정의한템플릿을 Provider template 이라한다. Nested stack 을통해서사용자가정의한가상자원들의구성을사용자정의형가상자원으로활용할수있다. 즉, 가상자원들의복잡한구성으로이루어진구조를하나의논리적그룹으로정의하고이를새로운가상자원유형으로활용할수있다.

yaml 템플릿은 Provider template 이고이를통해생성된스택은 Nested stack 이라부른다. Parent template 은 Provider template 을 URL이나파일경로정보를통해참조할수있고만일해당 Provider template 을새로운가상자원유형 (e.g.

8 원을정의하고있으며각각의자원유형및특성값들을명시하고있다. 상기가상자원들의특성값들은 Intrinsice Function 을이용하여템플릿실행시에사용자의입력을받거나동적으로다른자원들을참조하도록하고있다. 템플릿실행후에받을결과값으로는 get_attr Intrinsic Function 을이용하여서버에할당된사설 IP 주소를정의하고있음을알수있다. Ⅳ. Nested Stack Heat 에서템플릿을통해생성된가상자원들의집합을스택 (stack) 이라고부르며스택이별도의스택을참조하는경우에참조한스택을 Parent stack 이라하고참조된스택을 Nested stack 이라한다. 그리고 Parent stack 을정의한템플릿을 Parent template, Nested stack 을정의한템플릿을 Provider template 이라한다. Nested stack 을통해서사용자가정의한가상자원들의구성을사용자정의형가상자원으로활용할수있다. 즉, 가상자원들의복잡한구성으로이루어진구조를하나의논리적그룹으로정의하고이를새로운가상자원유형으로활용할수있다. ( 그림 8) 을참조하면 top.yaml 템플릿에서가상자원을정의할때가상자원의유형으로 my_server.yaml 을지정하고있다. 따 라서, top.yaml 템플릿은 Parent template 이며이를통해생성된스택은 Parent stack 이된다. 또한 my_ server.yaml 템플릿은 Provider template 이고이를통해생성된스택은 Nested stack 이라부른다. Parent template 은 Provider template 을 URL이나파일경로정보를통해참조할수있고만일해당 Provider template 을새로운가상자원유형 (e.g. My::Custom::Server) 으로환경변수에등록하게되면 resources 섹션의 type 에서상기등록된사용자정의형가상자원유형을지정하면된다. Provider template 에명시된 parameters 와 outputs 섹션은각각 Parent template 에해당하는사용자정의가상자원의특성 (properties) 과속성 (attribute) 으로대응된다. V. 결론가상인프라구축을통해더쉬운관리와낮은유지비용을기대하지만오히려관리가복잡해지는아이러니한상황이발생하곤한다. 가상머신의생성이너무간단하고편리하여가상머신의수가부지불식간에폭증하는경우가있기때문이다. 이것이바로오케스트레이션기능이가상인프라구축을위해필수적으로요구되는이유이다. 이러한측면에서 Heat 는오픈스택의일반사용자보다기업사용자들에게더많은가치를전해주는기술로발전해갈것으로기대된다. 약어정리 AMQP API AWS Advanced Message Queueing Protocol Application Programming Interface Amazon Web Service 102 전자통신동향분석제 30 권제 2 호 2015 년 4 월

9 CFN CLI HOT JSON URL YAML 참고문헌 CloudFomration Command Line Interface Heat Orchestration Template JavaScript Object Notation Uniform Resources Locator YAML Ain t Markup Language [1] OpenStack Project, [2] 디지털데일리, 대기업클라우드표준노리는오픈스택, [3] Welcome to the Heat Developer Documentation, [4] Stackalytics, project_type=openstack&release=all&module=heatgroup [5] AWS CloudFormation, rmation/ [6] RabbitMQ, [7] Heat Orchestration Template (HOT) Specification, uide/hot_spec.html [8] OpenStack Resource Types, g/developer/heat/template_guide/openstack.html 전홍석외 / OpenStack 오케스트레이션기술분석 103

이도경, 최덕재 Dokyeong Lee, Deokjai Choi 1. 서론

이도경, 최덕재 Dokyeong Lee, Deokjai Choi 1. 서론 2. 관련연구 2.1 MQTT 프로토콜 Fig. 1. Topic-based Publish/Subscribe Communication Model. Table 1. Delivery and Guarantee by MQTT QoS Level 2.1 MQTT-SN 프로토콜 Fig. 2. MQTT-SN