클라우드 오케스트레이션과 이뮤터블 인프라스트럭처(3)
참고 자료
오픈 스택을 처음 공부하는 사람이라면, 아래 책을 꼭 읽어봤음 좋겠다!
위에 자료들을 보고 공부하며 정리한 내용입니다. 혹시 수정이 필요한 내용이 있으면, 댓글 달아주시면 감사하겠습니다 😊
목차
[오케스트레이션]
- 스택
- 템플릿
- 장점과 단점
- API
[멀티클라우드]
- 전용 네트워크
- CDN
[이뮤터블 인프라스트럭처]
- 기존 인프라 환경의 문제점: 생명주기
- 이뮤터블 인프라스트럭처
- 마이크로서비스
- 컨테이너오케스트레이션
리소스들의 관계를 정의하고 구성을 자동화함으로써 사람의 판단과 수작업을 덜어주는 기능(오픈스택 Heat, AWS의 Cloud Formation) → 스택으로 구성
- DevOps 오케스트레이션(자동화Task)
→ 조직의 DevOps 프로세스를 자동화 툴의 태스크로 만듦
→ API 로 제어되는 클라우드 관리 플랫폼 상에 구현된다 - DevOps 오토메이션(자동화)
→ 지속적 통합을 위해 CI 툴을 사용하여 소프트웨어 빌드
(미들웨어 같은 소프트웨어도 설정 관리 방식으로 자동화) - 클라우드 인프라 오케스트레이션(자동화Task)
→ 네 가지 기능 레이어
1) API 포털 액세스 레이어
2) 서비스 관리 레이어
3) 오케스트레이션 레이어
4) 리소스 관리 레이어 - 클라우드 인프라 오토메이션(자동화)
→ 클라우드 툴로 자동화
1) 베어메탈 서버에 가상 서버 디플로이
2) 운영체제 설치
3) 네트워크 구축 및 설정 작업
4) 애플리케이션 설치 및 설정 작업
[ ROA(Resource Oriented Architecture) ]
- 오케스트레이션: 리소스의 집합체를 정의하는 기술
- 오케스트레이션의 도입
→ 기존에 Action에 해당하는 API를 중심으로 처리하던 방식에서 리소스의 그룹을 중심으로 처리하는 방식으로의 패러다임의 전환 - 스택: 리소스의 집합체인 템플릿을 JSON 형식으로 만든 템플릿, 이벤트 포함
- 템플릿: 오케스트레이션 근간, 리소스를 정의할 때 사용
템플릿
[ InfraStructure as Code ]
클라우드 인프라나 시스템의 상태를 표현할 때 텍스트 파일로 정의
→ 오케스트레이션 툴이나 API, 각종 스크립트 언어, 혹은 오토메이션 툴들이 이 텍스트 파일을 입력받아 과거에 인간의 판단과 수작업으로 처리했던 작업들을 자동으로 처리
- 멱등성: 몇번을 실행해도 같은 결과를 재현할 수 있는 특성
[ 오케스트레이션 접근 방법 ]
- 선언형 툴
→ Application에 최적화된 인프라 상태를 템플릿 형태로 정의하고 관리 - 절차형 툴(Chef, Puppet, Ansible)
→ Application 설치나 설정 순서를 열거한 다음, 그것들을 자동화
→ 구성과 설정정보를 관리하는 서버와 그 설정을 적용하는 클라이언트
[ 시스템을 Deploy하는 과정 ]
- 네트워크 및 블록 스토리지 준비 [선언형 툴]
- 이미지를 사용한 서버 기동 [선언형 툴]
- OS 설치 [절차형 툴]
- Application 설치 [절차형 툴]
[ 템플릿 구성 요소 ]
- 템플릿 버전, 디스크립션, 메타 데이터, 매핑, 컨디션
- 리소스
→ 템플릿 중에서 가장 핵적인 부분, 클라우드에서 사용하는 서버 리소스를 기술 - 파라미터
→ 리소스 안에서 사용할 변수를 파라미터 형태로 정의할 수 있다 - 아웃풋
→ 오케스트레이션이 완료된 후의 출력을 제어
장점과 단점
[ 시스템 관리에 대한 접근 방법 ]
- 액션 지향에서 리소스 지향으로의 패러다임 전환과 디자인 패턴
→ 운영자가 시스템 접근 방식을 액션 지향에서 리소스 지향으로 전향할 수 있는지?
→ 이 전향에 대해 개발자도 공감하고 있는지?
[ 장점 ]
- 인프라 환경 구축: 작업의 효율화
- 인프라 환경 운영: 구축 기간의 단축(실수 방지) [오토힐링]
- 재사용 템플릿을 활용한 환경 복제 방식
- CI(Continuous Integration)
- 구성관리: 시스템의 구성 정보나 변경 이력 등을 관리하면서, 향후 시스템 변경이 필요할 때, 영향도를 분석하는 용도로 활용
(클라우드 환경 도입전에는 CMDB나 문서 형태로 관리) - 리버스 엔지니어링: 기존의 시스템 환경이나 프로그램에서 시스템 구성도나 설계서를 자동으로 생성하여 분석이나 문서화를 효율적으로 지원하는 기법
→ 원본 템플릿 정보를 확인하여 현 시스템의 구성 정보를 알아낼 수 있다.
[ 주의사항 ]
- 스택으로 생성한 리소스는 개별 액션 API를 사용해서 변경하지 않는다.
→ 원래 템플릿의 설정 내용과 변경된 스택의 설정 상태에 차이가 생겨 정합성이 깨진다. - 스택 반영 후 각 리소스에 정상 반영되었는지 결과 확인한다.
- 오케스트레이션 기능을 지원하지 않는 컴포넌트와 리소스를 미리 식별한다.
[ 스택의 분리 및 중첩 ]
- 시스템 설계상 공통 요소와 서브 시스템으로 분리
- 종속관계가 느슨한 아키텍처로 만들어져, 서브 시스템 간의 의존도가 낮아지고 릴리즈 속도가 더 빨라진다.
- 파라미터와 아웃풋: 분리된 스택 사이에서 정보 전달을 하는 방법
API
- 템플릿을 등록하면 기재된 리소스의 정보를 보고 스택을 생성
- Heat 엔진에서 Heat API를 거쳐 가가 리소스의 API로, 원하는 구성 형태가 되도록 필요한 지시를 내림
- 각 리소스의 API들과 상호작용하면서 템플릿에서 정의된 형태르르 만들어낸다.
→ 단, 이 과정에서 리소스가 부족하면 스택 생성이 실패 - 모든 API들과의 상호작용이 끝나고 템플릿에 정의한 형태가 완성된 후, 의도했던 상태가 된 것이 확인되면 리소스는 정상적이라고 판단한다.
- Heat 엔진이 정기적으로 상태를 확인하고 이상 징후가 보이면, 해당 리소스에게 이상 상태에 대응하는 필요한 조치를 취하게 한다.
멀티클라우드
[ 도입 목적 ]
- 이식성과 호환성을 고려해야 하는 경우
→ 특정 클라우드 환경의 기능이나 요금 체계에 락인(lock-in)되거나 종속되지 않도록 여러 클라우드 시스템들을 조합하고 이질감 없게 만들어서 서로 다른 클라우드 환경을 상호 운영하고 싶은 경우 - 이식성이 요구되지 않는 경우
→ 각 클라우드의 고유한 컴포넌트를 조합해서활용하는 경우
→ 여러 개의 클라우드 중 각각에서 우수한 컴포넌트들을 골라 이들을 조합해서 최적의 클라우드 환경을 만들어 사용하고 싶은 경우
[ 고려사항 ]
- 클라우드 간의 네트워크 접속 방식
→ 전용성, VPN, CDN 등을 이용
(클라우드 간의 데이터 전송 뿐만 아니라 API 실행을 위한 엔드포인트까지의 통신경로도 고려해야 한다) - API 의 호환성
→ 차이점을 내부에 은폐시키고 차이점을 와눙 시켜주어야 한다.
(실행할 API의 명령, 인증, 엔드포인트가 서로 다를 수 있다)
전용 네트워크: 클라우드 간의 네트워크 접속 방식
- 리전과 가용 영역이 어디에 위치하는지가 중요
- 네트워크로 연결하기 위한 두가지 방법
1) 통신 사업자나 클라우드 벤더가 제공하는 전용 네트워크를 사용
2) 공개된 인터넷을 활용
[ WAN 구성 방법 ]
- WAN: AS(Autonomous System, 고유한 AS 번호를 가지고 있음) 라고 부르는 네트워크들의 집합
- BGP: AS가 다른 AS들과 통신할 때 사용하는 프로토콜. 이 프로토콜을 사용해 라우팅함(Border Gateway Protocol) [ EGP ]
→ BGP는 CIDR을 지원하고 있어서 한 클라우드 환경에 정의된 네트워크의 CIDR을 다른 클라우드로 전달할 수 있다. - Peering: BGP를 이용해서 AS끼리 연결하는 것
- 전용회선: 클라우드를 전용회선으로 연결하려면 크게 두가지 작업이 필요
1) 전용회선의 종류를 선택하고 신규 회선이면 회선 부설과 물리적 결선
→ 거점 간 전용 회선, 광역 이더넷
2) 네트워크 API를 사용해서 클라우드 측의 게이트웨이와 논리적 결선 - 인터클라우드: 퍼블릭-프라이빗-하이브리드 클라우드 간의 글로벌 상호 연결
- 인터넷 VPN: 인터넷 회선을 활용하는 방법
→ 성능은 다소 떨어지더라도 통신 비용을 절감할 수 있음
CDN
HTTP 통신에 최적화되어 있고, 사용자와 가장 가까운 엣지 서버를 통해 캐시 기능을 제공하고, 네트워크 라우팅 기능은 물론 보안 기능까지 두루 갖추고 있다보니, 국제적으로 서비스하려는 시스템에 반드시 필요한 구성요소
- 인터넷을 고속화하기 위한 기술
→ 리소스를 적재적소에 분배하고 가가운 분배지로 통신 경로를 연결하는 방법 [ 라우터에 가장 가까운 서버 ] (DNS, 라우팅 정보 관리, 캐시 관리와 같은 기능이 있음)
[ CDN을 구성하는 컴포넌트 ]
- Edge: 캐시 서버가 존재하는 데이터 센터
- 오리진: 콘텐츠를 보관할 서버가 필요
→ CDN에서는 HTTP 통신을 하기 때문에 오리진은 HTTP 서버로 구성해야 함. 오브젝트 스토리지를 중심으록 구성 - Distribution: CDN은 DNS와 Origin 사이에 위치하고 있어 사용자는 CDN의 존재를 의식하지 못함
→ CDN에 있는 최적의 엣지를 구성할 수 있도록 각종 규칙을 정의하는 논리적인 단위 - Behavior: Distribution에 정의하는 내용으로 사용자 요청을 오리진과 연결하고 오리진의 응답을 사용자에게 연결해주는 기능(디스트리뷰션이 FQDN이라고 비유한다면, Behavior는 URI의 경로 부분에 해당한다고 볼 수 있는데, 경로 부분의 내용에 따라 어떤 오리진을 연결할건지 정해지기 때문)
- CDN은 L7에서 제어(HTTP에 특화된 네트워크): 헤더 필터, Error 페이지, SSL 인증서
[ CDN의 캐시 제어 방식 ]
- CDN의 디스트리뷰션 설정: 캐시의 수명을 제어하는 TTL
- HTTP 헤더: Cache-Control(캐시가 유효한 기간, 우선시), Expires(캐시가 무효화되는 시점)
- HTTP 헤더: Forward Cookies로 캐시 여부 확인
[ CDN의 라우팅 ]
어느 경로가 가장 빠르지 CDN의 에지 서버가 수시로 확인한다.
네트워크의 혼잡이 확인되면 가장 최적의 경로를 찾아 라우팅한다.
이뮤터블 인프라스트럭처
기존 인프라 환경의 문제점: 생명주기
- 하드웨어, 소프트웨어, 아키텍처의 생명주기는 시스템의 생명주기에 직접적으로 많은 영향을 준다.
- 시스템 구성 정보를 문서 형태로 관리하다보니, 변경 사항이 제대로 반영되지 않는 등, 현행 시스템 정보의 관리가 어렵다.
이뮤터블 인프라스트럭처
- 비즈니스 상황에 따른 생명주기
→ 하드웨어 수명이 시스템의 생면주기에 영향을 주던 제약사항 최소화: 초기 투자비용이나 감가상각에 신경쓰지 않아도 된다. - 멱등성: 몇번을 실행해도 결과는 달라지지 않는다.
- 서버와 코드를 쉽게 폐기할 수 있다.
- 시스템을 변경해야 할 때, 이미 구축된 환경을 파괴하고 수정하는 대신,
구축된 환경을 파괴하고 수정된 방향으로 다시 구축 - Infrastructure as Code: 인프라 환경의 구성 정보를 코드 형태로 정의한 후, 시스템 구축을 자동화 하여 언제든 인프라 환경을 재구성할 수 있게 만들어야 함
[ Blue Green 디플로이먼트 ]
시스템 다운 타임을 최소한으로 줄이면서, 인프라 환경을 교체하는 방법
- 인플레이스 업그레이드: 이미 동작하고 있는 실행 환경에 새로운 애플리케이션 모듈을 배포하는 법
→ 단점) 사용자 요청을 일시적으로 못받는다, 정합성의 문제 - 변경할 애플리케이션과 실행환경을 포함하여 인프라를 새롭게 구성한 다음, 실제 동작까지 테스트를 완료하고 이상이 없으면, 현재 사용중인 시스템의 URL로 교체하는 방법
- 네트워크 교체 방식: DNS, CDN, 로드 밸런서, 리버스 프록시 서버
마이크로 서비스
비즈니스 특성상 추가되거나 변경이 필요한 시기를 예측하기 어렵고, 경우에 따라서 비즈니스의 요구와 상관없이 공통 기능이나 애플리케이션 프레임워크 수준에서의 변경도 발생할 수 있다.
마이크로서비스: 독립해서 디플로이할 수 있는 서비스 단위로 설계된 어플리케이션
→ 비즈니스 수행력을 고려한 개발 조직, 시스템 구성과 디플로이의 자동화, 간결한 엔드포인트의 정의, 분산된 데이터 등과 같이 조직과 아키텍처, 개발 방법론까지 아우르는 특징들이 반영되 애플리케이션 형태
- 마이크로 서비스
*컴포넌트 — 서비스 형태로 정의, 공개된 인터페이스로 접근
*서비스 인터페이스 — REST/HTTP
*데이터관리 — 서비스별로 데이터베이스 관리
*애플리케이션 변경 — 서비스를 점진적으로 개선함
*장애 대응 방식 — Design for Failure
*인프라 환경 구축 — 자동 구축, 자동 디플로이, 자동 테스트, 서로 다른 프로세스로 서비스를 기동
*거버넌스 — 서비스별로 거버넌스, 적용기술도 서비스별로 선택
*조직 — cross functional 한 팀이 하나의 서비스를 개발하고 관리함
*조직의 생명주기 — 서비스, 상품의 생명주기를 따름 - 마이크로 서비스가 아닌 경우
*컴포넌트 — 라이브러리 형태로 정의됨, 인메모리 함수 호출로 접근함
*서비스 인터페이스 — 웹서비스
*데이터 관리 — 통합된 형태로 데이터베이스 관리
*애플리케이션 변경 — 릴리즈할때까지 변경사항을 모아서 개선함
*장애 대응 방식 — 가용성 설계
*인프라 환경 구축 — 전체를 하나로 구성, 테스트, 디플로이까지 하나의 프로세스로 여러 개의 서비스를 기동
*거버넌스 — 전체를 거버넌스, 애플리케이션 전체에 표준화한 기술 적용
*조직 — DBA, UI, 미들웨어 등 전문화된 팀으로 분화, 애플리케이션 전체게 여러 팀이 협업하며 1개의 조직을 구성
*조직의 생명주기 — 프로젝트의 생명주기를 따름
컨테이너 가상화 기술
- 하이퍼바이저형 가상화 기술: 하나의 하이퍼 바이저 혹은 호스트 OS 위에 여러개의 가상 서버를 만들고, 그 안에 게스트 OS가 탑재된 형태
- 컨테이너형 가상화 기술: 하나의 호스트 OS위에 독립된 가상 서버에 해당하는 컨테이너를 여러개 만드는 형태 → 하나의 컨테이너 안에는 애플리케이션 실행 환경을 패키징해서 넣을 수 있음. 인프라 담당자가 관리하는 OS 영역과 애플리케이션 실행 환경의 경계를 명확히 할 수 있고, 서로의 책임 영역과 역할도 분리할 수 있다.
- 컨테이너형 가상화 기술을 사용하면 OS를 기동하거나, OS를 설정하는 작업을 할 필요가 없다. 또한 애플리케이션 실행 환경을 이미지로 패키지화해두면, 필요한 라이브러리 모듈을 업그레이드하거나 애플리케이션만 배포하면 되기 때문에, 애플리케이션의 기동 시간을 더 단축시킬 수 있다.
- 컨테이너 이미지를 사용해서 사전에 설치된 OS위에 새로운 컨테이너를 기동
- Chef 등의 구성 관리 툴을 조합하여 인프라 구성 코드를 기반으로 애플리케이션 실행 환경을 구축하고 애플리케이션을 배포
- 네트워크 설정을 바꾸거나 로드 밸런서를 사용해서 운영환경으로 전환
[ 컨테이너 기술과 마이크로 서비스 ]
- 마이크로 서비스를 사용하면 개발 조직은 애플리케이션과 실행환경까지 포함된 컨테이너를 관리하고, 서비스의 엔드포인트는 URL 로 공개
[ 도커의 구현 기술 ]
도커는 리눅스에서 사용하는 여러 기술들을 응용해서 컨테이너 가상화 구현
→ 리눅스의 호스트 머신 상에서 동작하는 프로세스를 커널 기술을 사용해서 격리하고 있다
→ 프로세스를 포함한 컨테이너를 하나의 이미지로 만들어 또 다른 OS의 도커 환경에 이식할 수 있다.
- Namespaces: 사용자가 이용하는 공간을 분리하고 글로벌 리소스를 사용자 자신만 가지고 있는 것처럼 격리시켜주는 기능 → PID, MNT, IPC, NET, UTS
- Cgroups(control groups): cpu(CPU의 사용량), cpuset(CPU 코어 개수), memory(메모리 상한), device(사용 가능한 디바이스) 등, 그룹화된 프로세스의 리소스 제어
- Storage: 착탈 가능한 스토리지 드라이버
→ device mapper, btrfs, aufs, vfs 중에서 선택 가능 - Networking: 네트워크 디바이스를 짝지워 컨테이넌와 호스트 사이의 통신 가능하게 하는 veth, 가상 브릿지를 만들어 컨테이너 간의 통신을 가능하게 하는 bridge, 컨테이너 간의 통신 가능 여부를 제어하는 iptables
→ 컨테이너 안의 프로세스 동작 제어 - Security: 프로세스 권한을 관리하는 Capability, 컨테이너의 프로세스 동작을 컨테이너 내부에만 제한하는 SELinux, 프로세스가 실행하는 시스템 호출을 제한하는 seccomp와 같은 커테이너 내부 프로세스들을 제어
