클라우드 리소스와 제어 방법(2)
참고 자료
오픈 스택을 처음 공부하는 사람이라면, 아래 책을 꼭 읽어봤음 좋겠다!
위에 자료들을 보고 공부하며 정리한 내용입니다. 혹시 수정이 필요한 내용이 있으면, 댓글 달아주시면 감사하겠습니다 😊
🤔 이 글은 다음 질문으로 시작되었습니다
[ 가상화된 온-프레미스 환경 → 클라우드 리소스와 API 를 사용한 서버 ]
이런 형태의 인프라 전환이 이루어지고 있는 이유는 무엇일까 ?
목차
[클라우드를 제어하는 API의 동작방식]
- 인증처리
- 제어대상
- 제어행위[IT 인프라 리소스]
4. 인증과 보안
5. 오브젝트 스토리지
클라우드를 제어하는 API 의 동작방식
- 온프레미스 환경: API를 통해 관리한다는 개념 자체가 각 장비마다 필요한 명령들을 직접 실행해주어야 한다.
- 클라우드 환경: API의 엔드포인트가 컨트롤러 → 컨트롤러를 통해 관리
클라우드와 API
- API
어떤 소프트웨어에서 다른 소프트웨어를 제어하기 위해 미리 약속된 인터페이스나 규약 - 웹 API
일반 사용자들도 기업이 가진 정보를 웹 API 를 통해 이용할 수 있게 됨
→ API 경제
클라우드의 본질: 인터넷을 통해 필요한 자원을 제어할 수 있는 API 방식 - 웹 API와 HTTP
- 가상화 기술
물리적인 자원을 수배하지 않고 API 를 호출하는 것만으로도, 필요한 컴퓨팅 리소스를 바로 조달할 수 있다. + 하드웨어 리소스의 자원 활용도 ↑ - SOA(Service Oriented Architecture) 기술
현대적인 소프트웨어 또는 서비스 개발 패러다임 중 하나로서, 느슨하게 연결된 채, 필요에 따라 커뮤니케이션이 가능한 서비스의 집합
cf. 개발 패러다임의 변화: Procedural Oriented → Object Oriented → Component Oriented → Service Oriented
→ 가트너의 보고서에 따르면 SOA 도입에 따른 비용 절감, 비즈니스 민첩성 제고, IT 환경 변황에 대한 대응력 향상등의 장점이 강조되고 있다.
Actor를 식별 [ 인증처리 ]
리소스와 URI [ 제어 대상 ]
→ 리소스: UUID, Name, 고유한 키를 가지는 속성정보(프로퍼티)
→ URI: 네트워크 부분 + 경로 부분(엔드포인트를 가리킴. URL 형식으로 표시)
→ 엔드 포인트: 서비스를 제공하는 접점 혹은 API 호출을 받아 처리하는 접점
- [ 네트워크 상의 수많은 호스트들 중 원하는 하나를 지정하는 방법 ]
도메인: 네트워크 상에서 자원의 위치를 표현할 때 사용
도메인트리: 도메인을 오른쪽에서 왼쪽으로 읽어보면 TLD(Top Level Domain)이 2ndLD(2nd Level Domain)으로 연결되는데, 이것이 나무 모양의 구조로 형상화된다.
FQDN: 도메인과 호스트명이 하나로 연결된 전체 이름 - DNS: 도메인과 IP 주소 사이의 변환 가능을 해주는 것 (DNS 쿼리 과정)
→ DNS 라운드 로빈: DNS 에서 FQDN에 대응하는 IP주소를 여러개 등록하여 돌려씀
* 가상 호스트: 싱글 서버에서 여러 개의 도메인 이름으로 호스팅하기 위한 방법 → 서버 하나에 가상 호스트를 이용하여 여러개의 웹 서비스를 구축하는 방식
* 레지스트리: 최상위 도메인에 등록된 모든 도메인의 데이터 베이스 [ 상위 도메인의 DNS 가 하위 도메인의 DNS 로 위임할 때 이 정보를 사용 ]
* DNS 캐시 서버: 루트 DNS 서버에는 부하가 걸릴 수 있기 때문에 DNS 캐시 사용 → DNS 캐시 서버로 질의하는 것을 재귀적 질의라고 하고, DNS 캐시 서버 자신이 루트 DNS 서버나 다른 DNS 서버로 질의하는 것을 비재귀적 질의라고 한다. [ 도메인을 설계할 때, 비재귀적 질의를 많이 사용하도록 만드는 것이 중요 ]
* DNS 레코드: DNS 서버에서 IP 주소와 도메인을 짝 지은 설정정보
→ TTL: 캐시의 수명 시간을 결정하는 정보 (DNS 레코드 별로 설정할 수)
→ A: FQDN에 대한 IPv4 주소 정보
→ AAAA: FQDN에 대한 IPv6 주소 정보
→ CNAME: FQDN 별칭 정보
→ PTR: FQDN 역방향 질의 정보
→ TXT: 호스트의 부가 정보 - URL: Uniform Resource Locator(스키마명/FQDN/포트번호//파일경로/쿼리 파라미터)[네트워크 부분 + 경로설정(제어할 리소스 식별)]
URI: Uniform Resource Name(ARN 선언/클라우드명/컴포넌트명/리전명/어카운트ID/리소스명/리소스ID)[리소스 이름 + 리소스 프로퍼티 타입] - 엔드포인트: 클라이언트가 공개된 API를 실행하기 위해 접속하는 연결 접점. 엔드포인트는 FQDN 으로 표현되는데 API 의 접점으로 일종의 게이트웨이 역할을 한다. 엔드포인트 뒤편에는 클라우드를 제어하는 컨트롤러가 있는데, 클라우드의 실제 처리를 수행하게 된다.
→ 오픈 스택에서는 컨트롤러가 위치한 곳이 엔드포인트가 됨
→ 오픈스택 KeyStone은 외부에서 접속 가능한 FQDN과 엔드포인트를 매핑하는 역할 - 엔드포인트의 경로 설계와 버전 구분
경로 설계) 리소스 명을 사용하는 컴포넌트는 경로 정보를 계층화하여 표현하고 리소스 ID를 사용하는 컴포넌트는 쿼리 파라미터로 표현
버전) 정확하게 버전을 명시하는 것이 좋다. [ 기존 API 와 충돌하지 않도록 하위 호환성을 보장하면서 확장되어야 하지만, 행여 있을지 모르는 오동작을 막기 위해서 명시 ] - 리소스 명 & 리소스 프로퍼티 타입
액션과 HTTP [ 제어 행위 ]
- REST
- cURL: CLI에서도 HTTP 요청을 보낼 수 있다.
REST Client: REST 동작을 GUI 로 할 수 있다.
ROA(Resource Oriented Architecture)
REST API의 사상을 기반으로 리소스 중심적인 API를 사용하는 아키텍처
- REST기반 서비스를 위한 네가지 설계 지침
1) 상태를 가지지 않도록 만든다: 구현이 쉽고, 캐시를 사용할 수 있어 성능이 우수하다
2) URI는 디렉토리 구조처럼 계층적으로 만든다: URI의 가독성이 좋고 리소스의 구조를 이해하기 쉽다
3) HTTP 메소드를 명시적으로 사용한다: 리소스의 상태 변화를 HTTP 메소드를 활용하여 리소스 중심으로 처리하고 별도의 메소드를 사용해서 행위 중심으로 처리하지 않도록 한다.
4) 응답할 때 XML이나 JSON을 사용한다: 데이터 표현을 정규화해서 다른 언어나 기술 구조에서도 데이터를 활용할 수 있도록 한다. - REST API의 특징 중에서도 분산 환경을 제어할 때 이해해야 할 세가지 개념
1) 비동기: 응답이 지연될 수 있으므로 처리과정도 비동기로 처리
2) 멱등성: API를 몇번 호출하더라도 리소스에 변경이 발생하지 않는 한 같은 결과가 나옴(REST API는 상태가 없기 때문에)
→ 네트워크 성능이 좋지 않아 오류가 발생하더라도 다시 시도 가능
→ 최종 정합성 보장
3) 재시도 - UML과 ER 다이어그램으로 가시화
→ 액터와 액션은 UML의 유스케이스 다이어그램으로 표시할 수 있다
→ 리소스는 키를 중시믕로 과련된 메타데이터를 가지고 있기 때문에 ER 다이어 그램으로 표현할 수 있다(리소스를 제어해야 할 때, 연관 리소스 간의 정합성을 확인할 수 있기 때문에 상당히 유용)
사용자 인터페이스
- CLI: 명령줄로 제어를 할 수 있는 사용자 인터페이스
- SDK(Software Development Kit): 각종 프로그램 언어를 통해 클라우드 환경을 제어하도록 도와주는 개발 도구
- 콘솔: GUI 형태로 클라우드를 제어할 수 있는 사용자 인터페이스 → 웹 어플리케이션(손쉽게 최신 기능을 활용해 볼 수 있다)
IT 인프라 리소스
4. 인증과 보안
- 서명 프로세스: 사용자 인증 + TLS 프로토콜 사용(HTTPS)
구성요소
[ 인증 단위 ]
- 테넌트(KeyStone: 프로젝트)
- 사용자: API 를 실행하게 만드는 사람
→ 사용자도 리소스 로 관리됨 - 그룹: 사용자를 묶은 그룹
→ 정책 관리 효율적
[ 권한 제어 방식 ]
- 정책: 사용자나 그룹에 할당
→ 접근이나 실행 제한
→ AWS IAM: Effect(Allow or Deny), Action(액션 API), 리소스 - 인증키: 패스워드, 시크릿 액세스 키, 액세스 키
(클라우드 서비스, 사용자 인터페이스 방식에 따라서도 차이가 있음) - 토큰: 유효기간이 있는 임시 패스워드
- 서명: Http Header 의 ‘Authorization’
→ 서명값: 서명키와 서명 문자열을 HMAC 함수를 사용해서 얻어냄 (Hash-based message authentication Code)
→ 요청정보의 해시값과 시크릿 액세스 키를 조합해 전자서명 만듦 (SHA Secure Hash Algorithm 사용)
API 의 역할 및 동작 원리
- 정책: 사용자나 그룹에 할당
- IAM Role[from] 과 리소스 기반 정책[to]: Resource 에 정책 할당
→ IAM Role을 부여받은 리소스: IAM Role 을 할당하 과정에서 내부적으로 STS(Security Token Service)가 이미 사용되어 토큰을 발급
→ 리소스 기반 정책: 누가 제어를 당하는 대상[to]에게 권한이 있는지 - 복수 테넌트 에 대한 제어 권한
→ AWS: 정책을 통해 권한을 부여하면 여러 테넌트를 제어할 수 있다. - Federation: 토큰을 활용하여 제 3의 ID에 권한을 위임하는 방법
→ ID provider
→ SAML(Security Assertion Markup Language)
→ OIDC(OpenID Connect)
1) SAML/OIDC를 통해 ‘ID 프로바이더’ 로부터 인증 Assertion 취득
2) STS로부터 토큰 발급(Assume Role with SAML, WebIdentity)[ ‘ID 프로바이더’와 연계된 ‘IAM롤(권한정책)’이 적용]
3) Token 을 사용하여 API 실행
5. 오브젝트 스토리지
[오브젝트 스토리지가 HTTP 서버, 파일 시스템, 마운트 기능을 모두 포함]
- 파일 단위로 데이터를 관리
(블록 스토리지: 블록단위로 데이터를 인식) - 파일은 HTTP/HTTPS 프로토콜로 접근
(블록 스토리지: 웹 서버를 설치하는 등 과정이 필요) - API 로 파일을 제어할 수 있다 (파일자체를 클라우드에서 제어)
→ REST 아키텍처 적용 가능
(블록 스토리지: 서버 리소스의 파일 시스템에서 인식(OS 명령으로 제어)) - 여러 곳에 Replication 된다
(블록 스토리지: 백업, 원격지에 분산 저장&동기화, 스냅샷 활용한 백업) - 미리 용량을 산정 할 필요가 없다
(블록 스토리지: OS에 마운트 할 때 용량을 정해줘야 한다)
[ 활용 ]
- 정적인 웹 사이트
- 용량이 큰 동영상 파일 제공
- 데이터 양이 폭발적으로 늘어나서 분석이 쉽지 않은 로그 파일
[ Block Storage 가 유리한 경우 ]
- 안정적으로 높은 I/O 성능
- 파일의 정합성을 보장하기 위한 Lock 을 고려하는 경우
구성요소
- 어카운트: Tenant
- 버킷(컨테이너): 파일 시스템의 최상위 폴더와 같은 개념
→ 오픈 스택에서는 어카운트 범위 안에서만 이름이 고유하면 됨
→ AWS 에서 S3는 버킷 이름이 FQDN(Fully qualified domain name)으로 공개되기 때문에, 어카운트의 범위 밖에서도 고유해야 할 필요가 있다. - 오브젝트: 버킷 안에 저장되는 파일
→ 버킷 안에 버킷을 넣는 것은 불가능하지만, 프리픽스를 접두어로 하여 분류 체계를 만드는 것은 가능
→ 키: 프리픽스 + 파일명
API 의 역할
- 어카운트 제어와 버킷 목록 조회
[GET] 컨테이너 목록과 메타 데이터 정보
[HEAD] 메타 데이터 정보
[POST] 어카운트 설정 정보 수정 - 버킷 생성과 오브젝트 저장
→ CLI를 사용한 제어방식: 내부적으로 어떤 API가 호출되었는지 CLI 문서를 보거나 패킷을 분석하기 전엔 알 수 없다
→ API방식: [PUT] 컨테이너 생성 &파일 저장
→ 왜 PUT을 사용할까? 오브젝트 스토리지와 관련된 리소스들은 어카운트를 기준으로 트리 구조로 만들어짐. 트리의 루트가 되는 어카운트 입장에서는 컨테이너나 오브젝트를 ‘추가’의 의미로 받아들임 - 버킷과 오브젝트의 설정 정보 생성 및 변경
[POST] 메타 데이터 신규 설정
[PUT] 변경(HTTP의 확장 헤더 중 X-Container-Meta-{name} 사용)
[POST] 권한 삭제(헤더 중 X-Remove-Container-Meta-{name} 사용) - 오브젝트 복사
[PUT Object-Copy] (AWS S3) 내부적으로 GET 한 것을 PUT하는 방식(헤더 중 x-amz-copy-source 를 활용) - 멀티파트 업로드
오브젝트 스토리지는ㄴ 조작할 수 있는 파일의 크기에 제약이 있고, throughput을 향상 시킬 목적으로 파일을 분할한 후, 병렬처리 함
1) 오브젝트를 분할해서 파트를 생성
2) 생성된 파트를 업로드
3) 파트를 결합해서 원래 오브젝트를 생성 - Amazon S3 CLI
1) 유닉스나 리눅스의 파일 시스템처럼 오브젝트를 취급할 수 있는 CLI
2) API 를 사용하는 CLI
API 동작 원리 [2019 ver]
클라우드는 비교적 짧은 주기로 기능 업데이트가 진행 → 최신 API 문서 참고 권장
- ACL(Access Control List) 기능 활성화
- → 버저닝: 오브젝트가 변경될 때마다 이력으로 남겨 여러 버전 보관[버전 ID] (오픈스택: HTTP 헤더 X-Versions-Location)
→ 수명주기: 일정 기간 후에 오브젝트를 물리적으로 삭제하도록 규칙을 정할 수 있는 기능(AWS: 규칙 대상을 오브젝트(키 이름)로 정할지, 버전으로 지정할지 고르고, 이에 대해 수행할 액션을 삭제로 할지, 아카이브로 할지를 고름) - 암호화
1) 서버 측 암호화: 버킷 전체에 암호화를 적용하는 방법
→ 오브젝트를 버킷에 저장할 때 암호화하고, 사용자가 오브젝트를 가져갈 때 복호화(클라우드 환경에서 오브젝트를 안전하게 보호하고 싶을 때)
→ 오브젝트 단위로 PUT할 때 HTTP 헤더의 SSE에 암호키를 설정
→ HTTP 헤더의 SSE에 암호키를 설정한 후 다운로드하면 복호화 가능
2) 클라이언트 측 암호화: 클라이언트가 오브젝트를 암호화한 후 업로드 하는 방식(암호화키: 클라우드 안에서 메타 데이터로 관리)
→ 오브젝트 단위로 PUT 할 때 SDK 의 암호화 클라이언트에 암호 키를 제공해서 암호화
→ 다운로드하더라도 암호키를 모르면 복호화할 수 없다. - 웹 사이트 기능
→ 기본적인 웹 서버 기능 지원: 도큐먼트 루트, 커스텀 에러, 리다이렉트
→ CORS: XMLHttpRequest 가 서로 다른 도메인을 넘나들때 보안상 접근 제약되는 것을 해결하는 방법 → PUT Bucket cors 실행 (body 부분에 CORS를 위한 설정이 들어감)
오브젝트와 API
오브젝트 스토리지는 HTTP 프로토콜로 접근하고 내구성을 중시
→ 내구성을 높이는 과정: 시간 차에 의해 오브젝트의 상태가 예상과 달라 보이는 것
- 정합성: 오브젝트의 상태가 확정되면 그 상태를 확인할 때 모순없이 현재 상태 그대로가 재확인된다는 특성
→ 오브젝트 스토리지에서는 오브젝트를 생성한 후, 읽기를 할 때만 정합성이 보장된다. - 최종 정합성: 분산 환경에서 나타나는 특성으로 오브젝트의 상태가 확정되더라도 그 상태를 확인하는 시기에 따라 현재 상태가 아닌 이전 상태가 확인될 수도 있다.
→ PUT을 사용해서 파일을 변경할 때의 타임 스탬프는 클라이언트 측에서 실행된 시간이 아니라 변경 요청이 네트워크를 통과한 후 서버측의 시간을 따른다.
→ 순서를 보장하기 위해 락처리가 필요하다면, 별도로 직접 제어 로직을 구현해야 한다. - 멱등성: 몇번을 실행해도 같은 결과가 나온다. [ SOA, REST 설계 지침 ]
→ 단순한 형태로 최종 정합성을 구현 - REST
1) 상태를 가지지 않고
2) URI는 디렉터리 구조처럼 계층화
3) HTTP 메소드를 명시적으로 사용
4) JSON, XML 응답을 활용 - HTTP의 Etag 헤더: HTTP 응답에 이 Etag 값이 포함되어 있다면, HTTP 처리 뿐 아니라 오브젝트에 대한 처리까지 완료되어 파일이 정상적으로 반영되었다고 판단할 수 있다.
- 오브젝트 스토리지는 JSON이나 XML 응답을 활용하여 다른 컴포넌트들과 연계하는 대신 → AmazonS3의 이벤트 통보 기능을 사용해서 다른 컴포넌트 간의 연계성을 보완
오브젝트 스토리지 내부 구성
- 프론트: HTTP 요청을 접수하는 Access Tier(로드밸런서, 프록시 노드, 인증)
→ Ring 설정: 스토리지 노드에 대한 접근 제어 설정
(스토리지에 저장된 엔티티의 이름과 실제 물리적인 저장 위치를 연결)
(파티션 정보와 스토리지 노드의 존을 연결해주는 역할 → 파티션 정보에 MD5 해시 알고리즘을 적용해서 스토리지 노드의 존에 분산 배치하기 위한 매핑정보를 만듦)
[GET] Ring을 사용한 분산 부하 가능
[POST, PUT]한 존에 오브젝트를 생성하거나 변경 후, Ring 에 설정된 다른 존에 이 파일을 리플리케이션 - 백엔드: 오브젝트를 데이터로 저장하는 스토리지 노드(스토리지 노드)
→ 리플리케이션: 파일의 리플리케이션은 어카운트, 컨테이너(버킷), 오브젝트 각각의 파일에 대해 별도로 처리
→ 리플리케이터(파일 동기 프로세스): 확인, 복사 두 단계로 처리
→ 리플리케이터는 파일의 복사본이 Ring에 설정한 존에 제대로 잘 들어 있는지 확인하기 위해 정기적으로 각 파티션을 살펴봄(해시와 타임 스탬프 정보를 비교함)
[ 파티션과 타임 스탬프 ]
오픈스택 Swift 에서는 파티션과 존을 매핑할 때 해시 알고리즘을 사용
→ 해시 값은 내부적으로 파티션 번호를 사용해서 산출하는데, 오브젝트의 키 값을 사용
→ 리플리케이터는 해시 값과 타임 스탬프 정보를 보고 처리하기 때문에, 타임 스탬프 정보만 비교하게 된다.
[ 프리픽스와 분산 ]
Read 와 Write 할 때 여러 존으로 분산되어 처리
MD5 해시 알고리즘을 최적화할 수 있다면 파일을 각 존에 분산 할 때 좀 더 고르게 저장되도록 만들 수 있다.
→ 해시 값을 산출할 때 파티션 정보를 사용하는데, 그 정보에는 프리픽스가 포함되므로 결국 프리픽스를 잘 설계하는 것이 파일을 균일하게 분산하는 중요한 요소가 됩니다.
더 알아보기
클라우드는 분산 환경에서 이루어집니다. 따라서, 분산환경에 대한 기본적인 것들을 다루는 다음 시리즈 글을 추천합니다!
