08. 오케스트레이션

[오케스트레이션?]
>> 컴퓨터 시스템과 애플리케이션, 서비스의 자동화된 설정, 관리, 조정을 의미

>> 리소스들의 관계를 정의하고 구성을 자동화함으로써 사람의 판단과 수작업을 덜어주는 기능

(AWS Cloud Formation, 오픈스택 Heat)

 

[DevOps 오케스트레이션(자동화Task)]

>> 소프트웨어 개발의 자동화를 위해 태스크를 만드는 작업
>> 조직의 DevOps 프로세스를 자동화 툴의 태스크로 만듦
>> API 로 제어되는 클라우드 관리 플랫폼 상에 구현된다

 

[DevOps 오토메이션(자동화)]

>> CI(지속적 통합) 툴을 사용해서 빌드나 소스 코드 정적 검사를 자동화하는 작업
>> 지속적 통합을 위해 CI 툴을 사용하여 소프트웨어 빌드
(미들웨어 같은 소프트웨어도 설정 관리 방식으로 자동화)

 

[클라우드 인프라 오케스트레이션(자동화Task)]
>> 네 가지 기능 레이어
1) API 포털 액세스 레이어
2) 서비스 관리 레이어
3) 오케스트레이션 레이어
4) 리소스 관리 레이어

 

[클라우드 인프라 오토메이션(자동화)]
>> 클라우드 툴로 자동화
1) 베어메탈 서버에 가상 서버 디플로이
2) 운영체제 설치
3) 네트워크 구축 및 설정 작업
4) 애플리케이션 설치 및 설정 작업

 

[오케스트레이션 및 오토메이션의 접근 방법]

1) 프로그래밍 언어처럼 애플리케이션 설치나 설정 순서를 열거한 다음, 그것들을 자동화하도록 절차형 툴을 사용한 방법

2) 애플리케이션에 최적화된 인프라 상태를 템플릿 형태로 정의하고 이것을 관리하는 선언형 기능을 사용한 방법

 

[시스템을 Deploy하는 과정]

>> 네트워크 및 블록 스토리지 준비 [선언형 툴]

>> 이미지를 사용한 서버 기동 [선언형 툴]

>> OS 설치 [절차형 툴]

>> Application 설치 [절차형 툴]

 

 

[오케스트레이션]

>> 리소스의 집합체를 정의하는 기술

>> (기존에 액션에 해당하는 API를 중심으로 처리하던 방식)에서 (리소스의 그룹을 중심으로 처리하는 방식)으로의 패러다임의 전환

>> ROA의 관점에서 시스템을 설계하고 조작하는 접근 방식 의미

* 개별 리소스를 다룰 시

>> 개별 리소스에 대한 API를 실행함

* 오케스트레이션 사용 시

>> 리소스의 집합체를 템플릿에서 불러들인 후, '스택(stack)'이라는 리소스의 집합체에 대해 API를 실행함

>> 오케스트레이션에서 각종 제어를 할 때 '스택'을 기본 단위로 함

 

[템플릿]

 

템플릿

>> 오케스트레이션의 근간이 되고 리소스를 정의할 때 사용

 

[ 템플릿 구성 요소 ]

 

1) 템플릿 버전

템플릿에는 버전이 있어서 버전이 다르면 파라미터의 옵션이 호환되지 않기도 함

템플릿을 작성할 때는 사용 가능한 파라미터를 확인하여 이를 지원하는 버전을 선택해야 함

 

2) 디스크립션

해당 템플릿이 어떤 용도의 것인지 설명을 적음

이 내용은 오케스트레이션 동작에는 전혀 영향을 주지 않기 때문에

사람이 알아보기 쉬운 내용으로 자유롭게 기재하면 됨

 

3) 메타 데이터(AWS CloudFormation만 해당)

템플릿에 관한 정보를 JSON 형식으로 추가할 수 있음

 

4) 매핑(AWS CloudFormation만 해당)

리소스와 아웃풋 섹션에서 사용할 검색 테이블을 key, value 형식으로 지정 가능

 

5) 컨디션(AWS CloudFormation만 해당)

특정 리소스에 대해 생성할지 말지를 결정할 수 있는 조건을 지정할 수 있음

예를 들어 운영 환경에서는 리소스 A를 사용하고 테스트 환경에서는 리소스 B를 사용하는 것과 같이 상황에 따라 다른 정의가 가능함

 

6) 리소스

템플릿 중에서 가장 핵심적인 부분으로 클라우드에서 사용하는 서버 리소스를 기술함

 

7) 파라미터

리소스 안에서 사용할 변수를 파라미터 형태로 정의할 수 있음

 

8) 아웃풋

오케스트레이션이 완료된 후의 출력을 제어함

오케스트레이션된 결과를 표시한다거나, 완성된 시스템에 접근하기 위한 정보, 가령 웹 시스템에서는 관리자 화면으로 접근하기 위한 URL과 초기 사용자의 계정, 비밀번호 등을 표시할 수 있습니다.

 

* AWS와 오픈스택 양쪽에서 사용할 수 있는 최소한 알아둬야 할 공통 요소

>> 리소스, 파라미터, 아웃풋

 

[기존 리소스에서 템플릿 자동 생성하기]

 

AWS CloudFormation에서는 이미 만들어진 기존 환경의 리소스 정보를 메타 데이터로 수집한 후, 템플릿을 변환할 수 있는 CloudFormer라는 기능을 제공

 

CloudFormer

>> 기존 리소스 정보를 내부적을 추출한 다음, 화면에 각 컴포넌트순으로 리소스 목록을 표시함

 

[오케스트레이션의 장점]

 

인프라 환경 구축 단계에서의 장점

 

>> 환경 구축을 자동화 하는 것을 도와주고, 운영에 필요한 작업을 최적화해주는 효과

>> 실제로 리소의 종류나 개수가 늘어나더라도 API의 호출 횟수가 늘어나는 것을 억제해주고, 사용자의 실수로 인한 장애도 줄여줌

>> 그 외에도 리소스의 상태 관리 방법도 보다 효율적을 할 수 있게 됨

 

인프라 환경 운영 단계에서의 장점

 

1) 리소스 간의 의존 관계 정의

2) 오토스케일링과 오토 힐링

>> 오케스트레이션 엔진을 감시 서버나 감시 API와 연계하면 시스템의 이상 증상이 나타났을 때, 자동으로 리소스를 재배치하도록 만들 수 있음

>> 오토스케일링 : 미리 설정해둔 조건에 따라 서버 대수를 자동으로 늘리거나 줄일 수 있는 기능

>> 오토 힐링 : 미리 설정된 조건에 따라 서버를 자동으로 정상 상태로 되돌려 놓는 기능

 

재사용 템플릿을 활용한 환경 복제 방식에서의 장점

 

오케스트레이션 기능을 사용할 때, 환경 정보를 정의하는 템플릿은 JSON 파일 형식으로 만들어짐

이 JSON 파일은 일부 변경이 필요한 부분을 파라미터로 치환하도록 만들어 재사용 가능

CtreateStack API를 호출하면서 필요한 파라미터를 전달해주면 기존과 유사한 환경을 손쉽게 복제 가능

 

오케스트레이션을 활용한 지속적 통합의 장점

 

1) 애플리케이션 릴리즈와 인프라 변경 병행 작업

2) 업무량 예측을 통한 리소스 튜닝

3) 클라우드의 최신 기능 적용

 

구성 관리, 리버스 엔지니어링에서의 장점

 

구성 관리

>> 시스템의 구성 정보나 변경 이력 등을 관리하면서, 향후 시스템 변경이 필요할 때 영향도를 분석하는 용도로 활용

>> 오늘날 클라우드 환경에서는 템플릿으로 사용하는 JSON 파일이 리소스들의 집합체이자 구성 정보의 집합체 역할을 함

 

리버스 엔지니어링

>> 기존의 시스템 환경이나 프로그램에서 시스템 구성도나 설계서를 자동으로 생성하여 분석이나 문서화를 효율적으로 지원하는 기법

>> 원본 템플릿 정보를 확인하여 현 시스템의 구성 정보를 알아낼 수 있음

 

액션 지향에서 리소스 지향으로의 패러다임 전환과 디자인 패턴

 

오케스트레이션을 적용할지에 대한 판단 기준

>> 운영자가 시스템 접근 방식을 액션 지향에서 리소스 지향으로 전향할 수 있는가?
>> 이 전향에 대해 개발자도 공감하고 있는가?

 

 

[오케스트레이션의 주의사항]

 

>> 스택으로 생성한 리소스는 개별 액션 API를 사용해서 변경하지 않음
(별도의 API로 조작을 하게 되면 원래 템플릿의 설정 내용과 변경된 스택의 설정 상태에 차이가 생겨 정합성이 깨짐)

 

>> 스택 반영 후 각 리소스에 정상 반영되었는지 결과 확인

 

>> 오케스트레이션 기능을 지원하지 않는 컴포넌트와 리소스를 미리 식별

 

[스택의 분리 및 중첩]

 

>> 시스템 설계상 공통 요소와 서브 시스템으로 분리하는 것이 가장 일반적인 방법

 

>> 이 서브 시스템이 클라우드에 올라가면 종속관계가 느슨한 아키텍처로 만들어져, 서브 시스템 간의 의존도가 낮아지고 릴리즈 속도가 더 빨라짐

 

>> 파라미터와 아웃풋 : 분리된 스택 사이에서도 정보 전달이 필요한데 이때 연계 방법으로 활용됨

 

 

[오케스트레이션의 제어를 위한 기본 API]

 

오케스트레이션 API와 다른 리소스들의 API 사이에서 내부적으로는 어떤 일들이 벌어지는가

 

<템플릿을 등록한 후부터의 Heat의 동작 방식과 순서>

 

1) 템플릿을 등록하면 기재된 리소스의 정보를 보고 스택을 생성

 

2) Heat 엔진에서 Heat API를 거쳐 가가 리소스의 API로, 원하는 구성 형태가 되도록 필요한 지시를 내림

 

3) 각 리소스의 API들과 상호작용하면서 템플릿에서 정의된 형태를 만들어 냄
(단, 이 과정에서 리소스가 부족하면 스택 생성이 실패)

 

4) 모든 API들과의 상호작용이 끝나고 템플릿에 정의한 형태가 완성된 후, 의도했던 상태가 된 것이 확인되면 리소스는 정상적이라고 판단

 

5) Heat 엔진이 정기적으로 상태를 확인하고 이상 징후가 보이면, 해당 리소스에게 이상 상태에 대응하는 필요한 조치를 취하게 함

 

 

[오케스트레이션 리소스의 컴포넌트]

 

오케스트레이션 관점에서 보면 스택 자체가 리소스가 됨

>> 스택 안에 있는 속성에 이벤트나 템플릿이 들어가는 형태로 표현됨

 

최근 애플리케이션이나 컴퓨터 리소스에서 API를 제공하는 것이 당연한 추세가 되고 있음