클라우드 리소스와 제어 방법(1)

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

참고 자료

오픈 스택을 처음 공부하는 사람이라면, 아래 책을 꼭 읽어봤음 좋겠다!
→ 많은 도표로 쉽게 잘 설명되어 있다!! 강력 추천~

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

🤔 이 글은 다음 질문으로 시작되었습니다

[ 가상화된 온-프레미스 환경 → 클라우드 리소스와 API 를 사용한 서버 ]
이런 형태의 인프라 전환이 이루어지고 있는 이유는 무엇일까 ?

목차

[IT 인프라의 변화]
- 물리적 환경
- 서버 가상화 환경
- 클라우드 환경
[IT 인프라 리소스]
* 구성요소
* API의 역할
* API 동작원리
1. 서버 리소스
2. 블록 스토리지
3. 네트워크 리소스
+ 더 알아보기: 분산시스템 기초

IT 인프라의 변화

물리적 환경

  1. 성능, 가격, 확장성 등의 요구사항을 따져 사양을 선택함
  2. 랙(rack) 에 장비 탑재
    (빈 공간, 네트워크 스위치의 포트, 케이블 배선, 전원 용량 허용 범위, IP 주소)
  3. OS 와 어플리케이션 설치, 환경 설정 작업
    (App 개발 팀이 요청한 설정 내용에 따라 작업 계획서 작성)
  4. 설계대로 잘 구축 되었는지 테스트

→ 필요한 계정이나 권한 정보 App 개발팀에 전달
→ 새로 도입한 서버에 대한 정보를 자산 관리 대장에 갱신

서버 가상화 환경 [ 물리적인 작업 자동화 ]

  1. 가상 서버를 실제로 배치할 물리적인 호스트의 사양을 선택
  2. 가상 네트워크의 구성 정보를 확인하면서 사용가능한 IP 주소를 할당
    → 애플리케이션 개발 팀이 요청한 설계에 따라 작업 계획서 작성
  3. 기존 템플릿 에서 가상 서버를 복제하여 구동
  4. 작업 계획서에 따라 각종 SW 설치 및 설정 작업을 하고 최종 확인 테스트

→ 물리적인 작업이 없어짐: 서버 설치 및 랙 작, 케이블 배선 작업
→ 서버 가상화로 고려 사항이 바뀜: 가상 서버에 할당할 리소스를 선택
→ 가상 서버를 물리서버에 할당하는 방식: 가상 서버가 필요로 하는 사양에 따라 달라짐 (소프트웨어적인 요구사항을 고려하여 작업하는 방식)
→ 서버 가상화로 작업 방식이 달라짐: OS 설치 DVD 를 넣고 설치와 환경 설정 작업 (기존 물리 환경) → 필요한 소프트웨어가 미 설치되고 기본적인 설정까지 완료돤 템플릿을 복제

  • 서버 가상화를 위한 기반 인프라를 한번 구축해두면, 향후 발생할 물리적인 작업량이 전체적으로 줄어든다.
  • 물리적인 작업잉 소프트웨어 작업으로 대체되는 부분을 제외하면, 그 이전에 필요한 준비 작업의 양은 줄어들지 않음

클라우드 환경 [ 사람의 판단과 수작업 자동화 ]

  1. 인스턴스 유형 [Flavor] 선택
    → Flavor : CPU 의 개수나 메모리, 가상 디스크의 용량 등 미리 설정한 것
    (서버 사양의 템플릿)
    → 사양을 정하기 위한 의사결정 속도가 빨라진다. [서버 리소스 단가와 의사결정 인건비의 Trade-Offs]
    → 가상 서버가 자동으로 배치[배치할 호스트를 정할 필요 없음]
    → 동적 DNS와 같은 메커니즘으로 IP 주소를 추상화. 동적으로 IP 주소가 할당되더라도 도메인을 통해 연결이 가능. [IP 주소 할당과 회수의 자동화]
  2. 설정 스크립트: 최초 기동시에 일괄 처리
    → 스크립트가 또 다른 구성 관리 툴을 실행하거나 설정 내용에 문제가 없는지 테스트하는 툴을 실행하기도 함
    → 반복해서 재현 가능 및 실수 없이 작업(자동화된 검증 툴)
  3. 가상 서버를 생성하는 명령 실행

→ 클라우드 API 의 본질: 사람의 판단과 수작업을 대체 (자동화, 효율화)

1. 서버 리소스

구성 요소

  • 타입: 크기나 속성을 몇가지 유형으로 정리한 것
    (오픈스택 Nova — Flavor, Azure, AWS: 인스턴스 유형)
  • 이미지: 서버의 기동 이미지
    (오픈스택 Glance, AWS AMI)

API 의 역할

  • 오픈 스택에서 모든 관리 대상 객체에 고유한 UUID 가 부여
  1. 인증
    [ POST ] 사용자 정보 → Token, Endpoint 에 대한 정보
  2. 템플릿 이미지의 유효성 검증
    [ GET ] Nova 의 접속 정보, tenant_id, image_id → 사전검증
  3. 가상 서버의 생성
    [ POST ] 생성할 가상 서버의 조건 정보 → UUID
    (API 로 생성 요청을 접수하는 처리와 요청에 따라 실제로 가상 서버를 생성하는 처리가 비동기적으로 분리되어 실행)
  4. 생성된 가상 서버의 상태 확인
    [ GET ] UUID → 가상 서버에 대한 상세 정보
가상 서버의 수명주기 [ 출처: 클라우드 인프라와 API 의 구조 (로드북 출판) ]
  • 가상 서버 환경 설정에 필요한 데이터
    → 메타 데이터: 서버 관리 정보, 사용자가 임의로 정한 데이터
    (서버 별로 따로 만들어짐. 자동화 스크립트, 구성 관리 정보)
    → 사용자 데이터: 가상 서버에 액션을 실행해야 할 때 사용
    (ex. 쉘 스크립트, Cloud-init 으로 Rule 기반으로 정의)
  • 이미지
    → 디스크 포맷이나 디바이스 매핑과 같은 구성 정보
    → 공개 여부 속성

API 동작 원리

  • 오픈스택 내부에서 모든 처리가 메시지 큐를 통해 비동기로 이루어짐
    [ AMQP(Advanced Message Queue Protocol) ]
  1. 가상 서버 생성 요청 메시지를 [메시지 큐]에 넣은 후, 구성관리DB 에 현재 상태를 기록 (status: ‘BUILDING’)
  2. [스케줄러]에 요청 전달: 큐에서 요청메시지 꺼냄, 가상 서버 생성 준비
    → 호스트들이 상태를 확인하고 가상 서버를 생성할 곳을 결정
    [상태관리DB ← 주기적으로 호스트 리소스의 사용 현황을 통보]
    ( → 스케줄러 프로세스를 다중화하여 처리하여 가용성을 높임)
  3. 가상 서버를 기동할 호스트 결정 및 서버 기동 지시
    1) 서버를 생성할 호스트를 지정하고 가상 서버 생성 요청 메시지를 큐에 넣음 [스케줄러 → 메시지큐]
    2) 가상 서버를 만들기로 한 호스트가 큐에서 요청 메시지를 꺼내고 가상서버 기동 [메시지큐 → 호스트(하이퍼바이저)]
  4. 메시지 수신과 가상 서버의 생성
    → 다양한 작업: 기동할 템플릿 이미지를 가져오고 가상 서버에 할당할 IP 주소를 확보, 지정한 네트워크에 접속하기 위한 준비 등
  5. 구성관리 DB 갱신(status: ‘ACTIVE’)

2. 블록 스토리지

  • 과거 물리적 스토리지를 설계할 때는 디스크 영역을 확보하기 위해 LUN(Logical Unit Number이 필요) → RAID 구성이나 LUN 을 매핑하는 과정이 필요, 장비마다 제조사의 독자적인 기능이나 설정을 사용하기 위해 사람의 판단과 수작업이 필요
  • 클라우드를 사용할 때는 볼륨 용량과 접속할 가상 서버를 지정하기만 하면 된다. 볼륨을 제공할 물리적인 스토리지 장비의 선택부터 볼륨을 생성하고 가상 서버와 연결하기까지의 모든 작업이 자동화 되어 있기 때문
  • 과거
    서버) 볼륨과의 연결 방식, OS에서의 인식 방식
    볼륨) 볼륨의 생성 방법, 할당할 LUN(Logical Unit Number), 매핑할 WWN(World Wide Name)

구성 요소

  • 볼륨: 실제로 서버에 연결되는 디스크
    → 휘발되지 않고 영속적으로 보관.
    → 휘발성 디스크(ephemeral disk)도 있음
    → cf. ephemeral disk: 서버 리소스 안에 기본적으로 포함되어 있고, 가상 머신 이미지에 용량이 정의되어 있다.
  • 스냅샷: 볼륨을 복제한 것
    → 서버에 사용하려면 일단 스냅샷을 다시 볼륨으로 복제한 후, 연결

구성요소

  • 볼륨 타입: 디스크의 특성과 설정 & I/O 특성
  • 볼륨 사이즈: GB, OS 에서 파일시스템으로 인식되는 용량까지 사용 가능
    → 볼륨은 디바이스 단위로 연결되기 때문에 OS에서 여러 디바이스를 사용한 소프트웨어 RAID를 구성할 수 있다.

API 의 역할

[ 볼륨 ]

  • Cinder Scheduler: 백엔드 스토리지를 결정 → 필터(타입으로 필터링) & 백엔드 스토리지의 남은 용량에 가중치를 적용한 값을 사용
  1. 볼륨의 생성[ Cinder ]
    [ POST ] 볼륨 용량 및 다양한 옵션 → 생성된 볼륨의 UUID 정보
  2. 볼륨과 가상 서버의 연결(attach)
    [ POST ] Nova의 접속 정보, 가상 서버 ID, 볼륨의 UUID → 비동기 처리
  • 가상 서버에서 블록 스토리지까지 연결되는 네트워크 성능도 중요
    → Throughput(초당 전송 대역), IOPS(초당 Input과 Output의 횟수)
    → 백엔드 스토리지의 성능이나 네트워크의 물리적인 사양이 뒷받침
  • 보통 SSD 타입에서 IOPS를 올리고 싶다면, 용량을 많이 할당하여 IOPS를 높이는 방법을 씀
    → 3TB를 넘어서면, IOPS가 상한에 이르러 더 이상 늘어나지 않음
    → 이미 3TB 까지 늘린 상태라면 볼륨을 분할하는 것이 IOPS면에서 유리
  • SR-IOV(Single Root I/O Virtualization): 하이퍼바이저에서 발생할 수 있는 병목을 제거 → PCI(Peripheral Component Interconnect)디바이스 처리 (NIC에서 오는 명령을 PCI 가 하드웨어 수준에서 병렬 처리)

[ 스냅샷, 백업, 클론 ]

  • 스냅샷: 특정 시점에 볼륨에 기록된 블록 단위의 데이터를 보존하는 것
    (저장 속도가 상당히 빠름)
  • 백업: 볼륨에 저장된 데이터를 내구성이 높은 오브젝트 스토리지에 보존
  • 클론: 볼륨을 직접 복제하는 것

API 동작 원리(가상 서버와 볼륨 연결)

스토리지를 제어하는 에이전트가 메시지 큐에서 요청 메시지를 꺼낸 후, 작업

  1. 가상 서버와 블록 스토리지의 연결 요청
    [ 가상 서버 API → 메시지큐(스케줄러) → 하이퍼 바이저(오픈스택 에이전트)]
  2. 블록 스토리지와의 연결 준비
    [ 블록 스토리지 API → 메시지큐(스케줄러) → 블록 스토리지(오픈스택 에이전트)]
    → 협상 과정이 필요
    1) 볼륨 예약: 락(Lock)을 거는 것과 같음(이중으로 연결 막기)
    → 볼륨 상태: ‘available’ → ‘attaching’
    2) 볼륨의 연결 준비를 요청
    3) 실제 접속 처리
    4) 연결 성공 통보 → 볼륨 상태 ‘attaching’ → ‘in-use’
  3. 실제 연결 처리

주의사항

  • 블록 스토리지 API 장점: 특정 스토리지 제품의 하드웨어나 소프트웨어의 차별성에 신경 쓰지 않아도 됨(추상화)
  • 블록 스토리지 API 단점: 특정 스토리지 제품만이 가진 고유의 기능 무시
  • 최근에는, 스토리지의 고도의 기능들은 OS 의 파일 시스템이나 논리 볼륨 기능으로 대체가 가능
  • API를 어떤 기능과 연계하면 더 안전하고 효율적인 시스템을 만들지,
    어떻게 자동화를 할 수 있는지 고민하고 설계해보는 노하우가 필요

3. 네트워크 리소스

  • 클라우드 환경에서도 네트워크는 기본적으로 TCP/IP 기반
  • L2 네트워크: 같은 네트워크에 속한 장비끼리 연결
  • L3 네트워크: L2네트워크 연결(클라우드의 내부와 외부를 연결하는 기능)
  • IP 주소 관리 기능 (ex. IP주소 할당 → DHCP 를 통해 할당)
    [ 서브넷을 식별할 수 있는 네트워크 부 + 서브넷 안에서 개별 통신 장비를 식별할 수 있는 호스트 부 ]
    (서브넷 마스크: 네트워크 주소의 비트 길이를 표시한 것)
    (CIDR: 고정 길이의 서브넷 마스크 결정 방식 대신 가변길이 결정 방식)
    (Classless Inter Domain Routing)
  • 기능 매핑: L2 서브넷 기능(가상 스위치) + 서브넷 연결하기 위한 라우팅 기능(가상 라우터) + 서버를 네트워크에 연결하는 논리포트 기능
  • AWS, Azure 는 한 테넌트에 가상 네트워크를 여러개 가능(논리적 구성)

구성요소

  1. 스위치와 서브넷
    가상 스위치: L3 네트워크에서 사용하는 IP 주소 범위를 ‘서브넷’이라는 이름으로 할당
    서브넷: 서브넷에 연결된 서버는 DHCP를 통해 IP 주소를 할당받고, 그 IP주소로 통신하게 된다. [ 고정 IP(할당된 IP 주소에만 통신 허용) ]
  2. 라우터
    1) 내부(클라우드) → 내부
    테넌트 내부 or VPC 내의 네트워크
    다른 테넌트의 네트워크와 통신: Peering, Neutron의 네트워크 공유 기능
    2) 내부 → 외부
    IP 마스커레이드(사설 IP 주소 → 공인 IP 주소)
    3) 외부 →내부
    플로팅 IP: 해당 IP를 자유롭게 할당하고 회수 할 수 있음
    (공인 IP를 address pool에 확보한 다음, 서버의 논리 포트에 할당)
    (NAT: network address translation → 공인IP의 주소 풀은 리전별로 관리)
  3. 포트
    Neutron 논리포트: 가상저인 스위치의 접점
    AWS Elastic Network Interface: 네트워크 연결을 위한 인터페이스 접점
    → 생성될 때, 자신이 소속된 가상 서브넷으로부터 IP 주소를 할당
    → 가상네트워크&가상라우터를 연결하기도 함(가상 서브넷 게이트웨이)
  4. 시큐리티 그룹
    가상 서버에 들어가고 나가는 트래픽(패킷)을 필터링
    → Stateful, 암묵적 접근 금지
  5. 네트워크 액세스 컨트롤 리스트(NACL)
    명시적으로 패킷 필터링을 하거나 권한을 분리
    → Stateless, 암묵적 접근 허가

API 의 역할

[ 네트워크 구성 ]

  1. [POST] 가상 네트워크 생성
  2. [POST] 서브넷 생성
  3. [POST] 논리 포트 생성 (미리 IP 주소 할당)
  4. [POST] 가상 라우터 생성
  5. [PUT] 가상 라우터와 서브넷을 연결
  6. [PUT] 가상 라우터와 외부 네트워크의 연결

[ 네트워크 안에 서버 할당 ]

  1. [POST] 하나의 가상 네트워크를 지정하고 가상 서버를 구동
  2. [GET] 가상 서버 생성 준비
  3. [POST] 논리 포트 생성 요청(IP주소 할당)
    → 가상 서버 준비
    → 가상 서버 연결 준비(IP 스푸핑 대책 설정, 시큐리티 그룹 설정)
  4. [POST] 논리포트 연결 준비 완료 통보(다른 리소스와의 연계처리)
  5. 가상 서버 구동

API 동작 원리: 클라우드 환경에서 네트워크 제어 방법

  • 가상 네트워크를 제어하는 프로세스
    사용자는 컨트롤러 노드에 가상 서버나 가상 네트워크에 대한 제어 요청을 보내고, 컨트롤러 노드에서는 접수한 요청에 대해 nova-api, neutron-server, 다른 오픈스택 프로세스들과 연계하면서 컴퓨트 노드를 제어
  • 네트워크 식별
    가상 서버에서 전송되는 패킷은 연결된 가상 인터페이스를 보고, 자신이 어떤 네트워크에 속해 있는지 알 수 있습니다.
    → VLAN ID를 패킷에 할당
    → OVS의 브릿지: br-init(리눅스의 가상 인터페이스로 연결), br-tun(노드 사이에서 패킷을 전송하는 역할: 패킷을 보낼 때 VXLAN 이 사용(L3 네트워크 상에 논리적인 L2 네트워크 구성하는 터널링 프로토콜))

주의점

  • 물리적 인프라 환경과 클라우드 환경간의 변화 폭이 큼
  • 대역이나 MTU(패킷 사이즈) 등을 고려한 설계나 트러블 슈팅도 고려할 필요가 있음

SDN(Software Defined Networking)

  • 구성요소: 네트워크 컨트롤러, 네트워크 오케스트레이터, 네트워크 장비
  • 제어 담당인 컨트롤러와 전송을 담당하는 데이터 플랜을 서로 분리하여 API를 통해 이들을 제어
  • 네트워크 장비: 외부에서 장비를 제어할 수 있도록 드라이버에서 API 제공
  • 네트워크 오케스트레이터: 네트워크 장치를 통합적으로 제어해서 가상화
  • 네트워크 컨트롤러
    1) 사용자에게 일관된 API 모델 제공
    2) 가상 네트워크를 동작시키기 위해 태스크 컨트롤러
    → 컴퓨트 등의 다른 크라우드 리소스와의 연계
    → 테넌트의 권한 관리
오픈스택 컴포넌트의 리소스 관계도 [ 출처: 클라우드 인프라와 API 의 구조 (로드북 출판) ]
  • Image와 Snapshot: 직접적인 관계가 없는 것처럼 보이지만, 속성으로 연결
    → Image를 사용해서 서버 기동: 서버를 기동할 때 사용 ( 여러개의 스냅샷을 함께 다루며, 블록 디바이스와의 매핑 관계도 정의할 수 있다 )
    → Snapshot을 사용해서 서버 기동: 볼륨을 기동할 때 사용
  • NFS 서비스: 여러 대의 서버가 하나의 볼륨을 공유하는 형태
    → 다른 Region의 스토리지는 연결할 수 없다
    → NFS 프로토콜로 마운트 하는 방식: 접속 인터페이스, managed share storage 제공

더 알아보기

클라우드는 분산 환경에서 이루어집니다. 따라서, 분산환경에 대한 기본적인 것들을 다루는 다음 시리즈 글을 추천합니다!

[ Foundations of Distributed Systems ]

  1. 분산시스템의 특징
  2. 시스템 모델
  3. 네트워크와 인터네트워킹
  4. Communication aspects of middleware ( Interprocess Communication, Remote Invocation, Indirect Communication)
  5. Operating System Support

I will be a software architect.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store