클라우드 오케스트레이션과 이뮤터블 인프라스트럭처(3)

인프라 엔지니어라면, 특정 클라우드 인프라에 종속되지 말자! (3)

참고 자료

위에 자료들을 보고 공부하며 정리한 내용입니다. 혹시 수정이 필요한 내용이 있으면, 댓글 달아주시면 감사하겠습니다 😊

목차

[오케스트레이션]
- 스택
- 템플릿
- 장점과 단점
- API
[멀티클라우드]
- 전용 네트워크
- CDN
[이뮤터블 인프라스트럭처]
- 기존 인프라 환경의 문제점: 생명주기
- 이뮤터블 인프라스트럭처
- 마이크로서비스
- 컨테이너

오케스트레이션

  • DevOps 오케스트레이션(자동화Task)
    → 조직의 DevOps 프로세스를 자동화 툴의 태스크로 만듦
    → API 로 제어되는 클라우드 관리 플랫폼 상에 구현된다
  • DevOps 오토메이션(자동화)
    → 지속적 통합을 위해 CI 툴을 사용하여 소프트웨어 빌드
    (미들웨어 같은 소프트웨어도 설정 관리 방식으로 자동화)
  • 클라우드 인프라 오케스트레이션(자동화Task)
    → 네 가지 기능 레이어
    1) API 포털 액세스 레이어
    2) 서비스 관리 레이어
    3) 오케스트레이션 레이어
    4) 리소스 관리 레이어
  • 클라우드 인프라 오토메이션(자동화)
    → 클라우드 툴로 자동화
    1) 베어메탈 서버에 가상 서버 디플로이
    2) 운영체제 설치
    3) 네트워크 구축 및 설정 작업
    4) 애플리케이션 설치 및 설정 작업

[ ROA(Resource Oriented Architecture) ]

  • 오케스트레이션: 리소스의 집합체를 정의하는 기술
  • 오케스트레이션의 도입
    → 기존에 Action에 해당하는 API를 중심으로 처리하던 방식에서 리소스의 그룹을 중심으로 처리하는 방식으로의 패러다임의 전환
  • 스택: 리소스의 집합체인 템플릿을 JSON 형식으로 만든 템플릿, 이벤트 포함
  • 템플릿: 오케스트레이션 근간, 리소스를 정의할 때 사용

템플릿

  • 멱등성: 몇번을 실행해도 같은 결과를 재현할 수 있는 특성

[ 오케스트레이션 접근 방법 ]

  • 선언형 툴
    → Application에 최적화된 인프라 상태를 템플릿 형태로 정의하고 관리
  • 절차형 툴(Chef, Puppet, Ansible)
    → Application 설치나 설정 순서를 열거한 다음, 그것들을 자동화
    → 구성과 설정정보를 관리하는 서버와 그 설정을 적용하는 클라이언트

[ 시스템을 Deploy하는 과정 ]

  1. 네트워크 및 블록 스토리지 준비 [선언형 툴]
  2. 이미지를 사용한 서버 기동 [선언형 툴]
  3. OS 설치 [절차형 툴]
  4. Application 설치 [절차형 툴]

[ 템플릿 구성 요소 ]

  • 템플릿 버전, 디스크립션, 메타 데이터, 매핑, 컨디션
  1. 리소스
    → 템플릿 중에서 가장 핵적인 부분, 클라우드에서 사용하는 서버 리소스를 기술
  2. 파라미터
    → 리소스 안에서 사용할 변수를 파라미터 형태로 정의할 수 있다
  3. 아웃풋
    → 오케스트레이션이 완료된 후의 출력을 제어

장점과 단점

  • 액션 지향에서 리소스 지향으로의 패러다임 전환과 디자인 패턴
    → 운영자가 시스템 접근 방식을 액션 지향에서 리소스 지향으로 전향할 수 있는지?
    → 이 전향에 대해 개발자도 공감하고 있는지?

[ 장점 ]

  • 인프라 환경 구축: 작업의 효율화
  • 인프라 환경 운영: 구축 기간의 단축(실수 방지) [오토힐링]
  • 재사용 템플릿을 활용한 환경 복제 방식
  • CI(Continuous Integration)
  • 구성관리: 시스템의 구성 정보나 변경 이력 등을 관리하면서, 향후 시스템 변경이 필요할 때, 영향도를 분석하는 용도로 활용
    (클라우드 환경 도입전에는 CMDB나 문서 형태로 관리)
  • 리버스 엔지니어링: 기존의 시스템 환경이나 프로그램에서 시스템 구성도나 설계서를 자동으로 생성하여 분석이나 문서화를 효율적으로 지원하는 기법
    → 원본 템플릿 정보를 확인하여 현 시스템의 구성 정보를 알아낼 수 있다.

[ 주의사항 ]

  1. 스택으로 생성한 리소스는 개별 액션 API를 사용해서 변경하지 않는다.
    → 원래 템플릿의 설정 내용과 변경된 스택의 설정 상태에 차이가 생겨 정합성이 깨진다.
  2. 스택 반영 후 각 리소스에 정상 반영되었는지 결과 확인한다.
  3. 오케스트레이션 기능을 지원하지 않는 컴포넌트와 리소스를 미리 식별한다.

[ 스택의 분리 및 중첩 ]

  • 시스템 설계상 공통 요소와 서브 시스템으로 분리
  • 종속관계가 느슨한 아키텍처로 만들어져, 서브 시스템 간의 의존도가 낮아지고 릴리즈 속도가 더 빨라진다.
  • 파라미터와 아웃풋: 분리된 스택 사이에서 정보 전달을 하는 방법

API

  1. Heat 엔진에서 Heat API를 거쳐 가가 리소스의 API로, 원하는 구성 형태가 되도록 필요한 지시를 내림
  2. 각 리소스의 API들과 상호작용하면서 템플릿에서 정의된 형태르르 만들어낸다.
    → 단, 이 과정에서 리소스가 부족하면 스택 생성이 실패
  3. 모든 API들과의 상호작용이 끝나고 템플릿에 정의한 형태가 완성된 후, 의도했던 상태가 된 것이 확인되면 리소스는 정상적이라고 판단한다.
  4. Heat 엔진이 정기적으로 상태를 확인하고 이상 징후가 보이면, 해당 리소스에게 이상 상태에 대응하는 필요한 조치를 취하게 한다.

멀티클라우드

  1. 이식성과 호환성을 고려해야 하는 경우
    → 특정 클라우드 환경의 기능이나 요금 체계에 락인(lock-in)되거나 종속되지 않도록 여러 클라우드 시스템들을 조합하고 이질감 없게 만들어서 서로 다른 클라우드 환경을 상호 운영하고 싶은 경우
  2. 이식성이 요구되지 않는 경우
    → 각 클라우드의 고유한 컴포넌트를 조합해서활용하는 경우
    → 여러 개의 클라우드 중 각각에서 우수한 컴포넌트들을 골라 이들을 조합해서 최적의 클라우드 환경을 만들어 사용하고 싶은 경우

[ 고려사항 ]

  1. 클라우드 간의 네트워크 접속 방식
    → 전용성, VPN, CDN 등을 이용
    (클라우드 간의 데이터 전송 뿐만 아니라 API 실행을 위한 엔드포인트까지의 통신경로도 고려해야 한다)
  2. 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

  • 인터넷을 고속화하기 위한 기술
    → 리소스를 적재적소에 분배하고 가가운 분배지로 통신 경로를 연결하는 방법 [ 라우터에 가장 가까운 서버 ] (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 디플로이먼트 ]

시스템 다운 타임을 최소한으로 줄이면서, 인프라 환경을 교체하는 방법

  1. 인플레이스 업그레이드: 이미 동작하고 있는 실행 환경에 새로운 애플리케이션 모듈을 배포하는 법
    → 단점) 사용자 요청을 일시적으로 못받는다, 정합성의 문제
  2. 변경할 애플리케이션과 실행환경을 포함하여 인프라를 새롭게 구성한 다음, 실제 동작까지 테스트를 완료하고 이상이 없으면, 현재 사용중인 시스템의 URL로 교체하는 방법
  • 네트워크 교체 방식: DNS, CDN, 로드 밸런서, 리버스 프록시 서버

마이크로 서비스

마이크로서비스: 독립해서 디플로이할 수 있는 서비스 단위로 설계된 어플리케이션
→ 비즈니스 수행력을 고려한 개발 조직, 시스템 구성과 디플로이의 자동화, 간결한 엔드포인트의 정의, 분산된 데이터 등과 같이 조직과 아키텍처, 개발 방법론까지 아우르는 특징들이 반영되 애플리케이션 형태

  • 마이크로 서비스
    *컴포넌트 — 서비스 형태로 정의, 공개된 인터페이스로 접근
    *서비스 인터페이스 — REST/HTTP
    *데이터관리 — 서비스별로 데이터베이스 관리
    *애플리케이션 변경 — 서비스를 점진적으로 개선함
    *장애 대응 방식 — Design for Failure
    *인프라 환경 구축 — 자동 구축, 자동 디플로이, 자동 테스트, 서로 다른 프로세스로 서비스를 기동
    *거버넌스 — 서비스별로 거버넌스, 적용기술도 서비스별로 선택
    *조직 — cross functional 한 팀이 하나의 서비스를 개발하고 관리함
    *조직의 생명주기 — 서비스, 상품의 생명주기를 따름
  • 마이크로 서비스가 아닌 경우
    *컴포넌트 — 라이브러리 형태로 정의됨, 인메모리 함수 호출로 접근함
    *서비스 인터페이스 — 웹서비스
    *데이터 관리 — 통합된 형태로 데이터베이스 관리
    *애플리케이션 변경 — 릴리즈할때까지 변경사항을 모아서 개선함
    *장애 대응 방식 — 가용성 설계
    *인프라 환경 구축 — 전체를 하나로 구성, 테스트, 디플로이까지 하나의 프로세스로 여러 개의 서비스를 기동
    *거버넌스 — 전체를 거버넌스, 애플리케이션 전체에 표준화한 기술 적용
    *조직 — DBA, UI, 미들웨어 등 전문화된 팀으로 분화, 애플리케이션 전체게 여러 팀이 협업하며 1개의 조직을 구성
    *조직의 생명주기 — 프로젝트의 생명주기를 따름

컨테이너 가상화 기술

  • 컨테이너형 가상화 기술: 하나의 호스트 OS위에 독립된 가상 서버에 해당하는 컨테이너를 여러개 만드는 형태 → 하나의 컨테이너 안에는 애플리케이션 실행 환경을 패키징해서 넣을 수 있음. 인프라 담당자가 관리하는 OS 영역과 애플리케이션 실행 환경의 경계를 명확히 할 수 있고, 서로의 책임 영역과 역할도 분리할 수 있다.
  • 컨테이너형 가상화 기술을 사용하면 OS를 기동하거나, OS를 설정하는 작업을 할 필요가 없다. 또한 애플리케이션 실행 환경을 이미지로 패키지화해두면, 필요한 라이브러리 모듈을 업그레이드하거나 애플리케이션만 배포하면 되기 때문에, 애플리케이션의 기동 시간을 더 단축시킬 수 있다.
  1. 컨테이너 이미지를 사용해서 사전에 설치된 OS위에 새로운 컨테이너를 기동
  2. Chef 등의 구성 관리 툴을 조합하여 인프라 구성 코드를 기반으로 애플리케이션 실행 환경을 구축하고 애플리케이션을 배포
  3. 네트워크 설정을 바꾸거나 로드 밸런서를 사용해서 운영환경으로 전환

[ 컨테이너 기술과 마이크로 서비스 ]

  • 마이크로 서비스를 사용하면 개발 조직은 애플리케이션과 실행환경까지 포함된 컨테이너를 관리하고, 서비스의 엔드포인트는 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와 같은 커테이너 내부 프로세스들을 제어

I will be a software architect.