Computer ScienceInfra

클라우드를 제어하는 API의 작동 방식

클라우드와 API의 관계

API

API는 어떤 소프트웨어에서 다른 소프트웨어를 제어하기 위해 미리 약속된 인터페이스나 규약을 의미한다.
API를 사용하면 내부 구조를 자세히 몰라도 다른 소프트웨어를 무리 없이 사용할 수 있다.

웹 API

클라우드에서는 웹 API를 사용하는 것이 일반적이다.
웹 API는 HTTP(HTTPS) 같은 웹 프로토콜을 사용해서 네트워크를 통해 호출하는 API를 말한다.

아마존에서 시작도니 클라우드 컴퓨팅에서의 웹 API 적용

아마존은 특정 기간에 사용량이 폭주하는 경향이 있었다. 그래서 많은 서버와 스토리지를 구비해놓고 제어하는 웹 API를 구축했다.
아마존의 서버와 스토리지 같은 리소스 관리 방식은 AWS의 EC2와 S3의 기반이 된다.
이런 웹 API 기반 리소스 관리는 다음과 같은 이점이 있다.

  • 인터넷을 통해 서버나 스토리지를 시간제로 임대해서 사용할 수 있다.
  • API를 통해 사용자가 원하는 시점에 원하는 만큼 리소스를 할당받을 수 있다.

가상화 기술과 클라우드 컴퓨팅

물리적인 서버와 스토리지를 직접 확보하려면 장비를 구하고 설치하는 과정에서 많은 시간이 쓰인다.
물리적인 서버를 구하지 않고 가상화된 환경에서 API를 호출해서 필요한 리소스를 바로 구할 수 있다.

하지만 가상화가 클라우드 컴퓨팅의 본질은 아니다.
성능이나 보안이 중요한 경우, 물리적인 리소스를 직접 사용해야 하는 경우도 있기 때문이다.
클라우드의 본질은 리소스의 가상화 여부가 아닌 인터넷을 통해 필요한 자원을 제어할 수 있는 API 방식에 있다.

웹 API의 구성요소

웹 API에서는 인증 처리, 제어 대상, 제어 행동으로 구성된다.
제어 대상은 리소스를 의미하며 URI로 표현된다.
제어 행위는 액션에 해당하며 HTTP 메서드로 표현된다.

리소스와 URI

도메인, 도메인 트리, FQDN

URI는 크게 네트워크 관련 부분과 경로 관련 부분으로 나뉜다.
네트워크 부분에 서버 IP 주소를 사용하는 것보다는 도메인 주소를 사용하는 게 편리하다.(www.naver.com)

EC2 자원의 외부 DNS 호스트 이름인 ec2-54-10-10-10.ap-northeast-2.compute.amazonaws.com은 오른쪽부터 점을 기준으로 계층 구조를 나타낸다.
TLD(탑 레벨 도메인)인 com
2LD(세컨드 레벨 도메인)인 amazonaws
…

이런 식으로 상위 도메인에 하위 도메인이 포한되는 방식이다.
이런 모습이 마치 트리 구조로 형상화되어서 도메인 트리라고도 한다.
그리고 가장 왼쪽에 위치한 부분 ec2-54-10-10-10라는 호스트가 리소스에 해당하게 된다.
즉 호스트 명 + 도메인 명을 합친 전체 이름을 FQDN이라고 한다. FQDN은 세상의 수많은 호스트 중 하나를 지정할 수 있게 한다.

클라우드에서 도메인 계층 확장하기

클라우드 리소스에 접속할 때도 계층화된 도메인 명을 사용한다.
도메인 명을 정할 때는 일종의 규칙이 있다. AWS의 도메인 예시를 보면, ec2.ap-northeast-2.compute.amazonaws.com에서 ap-northeast-2는 리전을 의미하고, ec2는 서비스(컴포넌트)에 해당한다. (만약 서비스가 리전에 종속되지 않는 경우, 리전 계층에 서비스가 사용될 수 있다.)

이 규칙을 이해하면 다양한 리전에 다양한 서비스를 도메인 명으로 표현할 수 있다.

DNS, 가상 호스트, 레지스트리

도메인 명은 사람이 쉽게 식별할 수 있기 위한 내용이라 TCP/IP으로 통신하기 위해서는 도메인을 IP 주소로 바꿔야 한다.
도메인 주소와 IP 주소를 변환하는 역할을 DNS가 한다.

복수 IP와 가상호스트

일반적으로 FQDN과 IP가 1대1 매핑되지만 필요에 따라서 1:N, N:1 매핑이 가능하다.
1:N은 대규모 시스템에 활용된다. 하나의 FQDN으로 많은 요청이 오면 하나의 IP로 대응하지 못할 수 있다.
이럴 때 여러 IP를 매핑해서 DNS가 순차적으로 IP를 돌려써서 부하를 줄일 수 있다. (DNS 라운드 로빈)

클라우드에서는 CDN이나 로드 밸런서에서 DNS 라운드 로빈 기능을 활용하여 대규모 트래픽에 대응할 수 있다.
DNS 라운드 로빈은 사용자 입장에서 주소 변경 없이 확장 할 수 있다.

반면 N:1은 서버 리소스 더 효율적으로 사용하고 싶을 때 사용한다.

도메인과 IP 주소 변환 방법

클라이언트 쪽에서 IP 주소로 변환하려고 하면 스텁 리졸버를 통해 캐시 DNS 서버에 해당 도메인 정보가 있는 지 확인한다.(이 과정을 로컬 쿼리, 재귀적 질의라고 함)
만약 없으면 루트 도메인부터 최하위 도메인까지 각 도메인의 네임 스페이스를 관리하는 DNS에게 물어본다. (이를 반복적 질의, 비재귀적 질의라고 함)
이렇게 되면 루트 도메인에 상당한 부하가 생기는 데, 이를 방지하기 위한 것이 캐시 DNS 서버이다.
(캐시 DNS 서버는 클라이언트 컴퓨터에서 네트워크 설정에서 지정된 DNS 서버이다.)

비재귀적 질의를 많이 사용하는 URL

URL을 설계할 때는 비재귀적 질의가 많이 사용되도록 하는 게 좋다. 비재귀적 질의가 많이 사용되는 URL은 다양한 DNS를 거쳐서 IP 주소를 찾도록 하는 것이다. 즉 서버의 특성에 따라 잘 계층화하면 확정성을 확보할 수 있다. ec2-north-east-amazon.com은 계층화가 잘 이뤄지지 않았고 비재귀적 질의가 적다. (루트DNS - com DNS - ec2... DNS)
반면 ec2.north-east.amazon.com과 같이 잘 계층화 된 URL은 비재귀적 질의가 많이 사용됐고 각 DNS가 목적에 따라 확장에 더 유리해졌다. (루트 DNS - com DNS - amazon DNS - north-east DNS - ec2 DNS)
물론 이런 설계 방법이 성능에는 약간의 손해를 볼 수 있으나 DNS 캐시 서버의 존재 때문에 이런 손해는 줄일 수 있다.

자신이 등록한 도메인 사용하기

자신의 도메인에 CNAME을 등록하면 된다.
일반적으로 클라우드 서비스를 제공하는 업체에서는 DNS 서비스를 제공한다. AWS도 Route 53이란 기능을 제공한다.

도메인 레코드

IP 주소와 도메인을 짝 지은 설정정보를 DNS 레코드라고 한다.

  • A : FQDN에 대한 IPv4 주소 정보
  • AA : FQDN에 대한 IPv6 주소 정보
  • CNAME : FQDN 별칭 정보
  • PTR : FQDN 역방향 질의 정보
  • SOA : DNS 영역에 대한 권한 정보
  • NS : DNS 서버 정보
  • MX : 이메일 서버 정보
  • SPF : 이메일 발신자 자격 증명 정보
  • SRV : 프로토콜, 포트 번호 등 ㅈ어보
  • TXT : 호스트의 부가 정보

URI

웹 API에서 리소스를 지정하는 식별자를 URI라고 한다. URI에는 URL과 URN이 포함된다.

URL

URL은 네트워크 상에 있는 리소스의 위치를 알려줄 때 사용한다.
URL은 네트워크 부분과 경로 부분으로 나눌 수 있다.
스키마, 인증정보, FQDN, 포트번호까지 네트워크 경로이고, 네트워크 부분 이후를 경로 부분이라고 한다.

엔드포인트

클라이언트가 공개된 API를 실행하기 위해 접속하는 연결 접점을 엔드포인트라고 한다.
웹 API에서는 URI가 엔드포인트로 일종의 게이트웨이 역활을 한다. 엔드 포인트 뒤편에는 컨트롤러가 실제 처리를 수행하게 된다.

물리적인 장비를 사용하는 온프레미스 환경에서는 직접 장비를 설치한 후 장비의 어드레스에 접속해서 제어를 해야 한다.
만약 인프라 환경이 커지면 이런 방식은 운영하기 어려워진다. 특히 다른 리전에 있는 리소스를 제어해야 할 경우 어렵다.
API의 엔드포인트를 통한 제어는 일관되고 효율적인 작업이 가능하다.

엔드포인트와 도메인

AWS 엔드포인트는 IP가 아닍 도메인으로 접속하게 된다.
그 이유는 일단 사람이 알아보기 쉽고, 사용자로부터 IP 주소를 숨길 수 있기 때문이다.

IP 주소는 데이터 센터 장비를 옮기거나 부하 분산을 위해 변경될 수 있다. 이런 변경이 사용자에게 노출되지 않기 위해 도메인으로 접속하도록 한다.

ROA (리소스 지향 아키텍쳐)

리소스 지향 아키텍처란 REST API의 사상을 기반으로 리소스 중심적인 API를 사용하는 아키텍처를 말한다.

REST 기반 서비스

REST는 프로토콜이 아니라 사고방식이다. REST에는 네가지 설계 지침으로 요약될 수 있다.

  1. 상태를 가지지 않는다. : 사태를 가지지 않으므로 구현이 쉽고 캐시를 사용할 수 있고 성능이 우수.
  2. URI는 디렉터리 구조처럼 계층적 구조를 가진다. : 가독성과 리소스 구조 이해가 쉬움.
  3. HTTP 메서드를 명시적으로 사용 : 리소스 상태 변화를 HTTP 메서드를 통해 리소스 중심으로 표현.
  4. 응답은 XML이나 JSON 사용 : 데이텨 표현을 정규화해서 다양한 언어와 기술에도 데이터가 활용될 수 있음.

비동기 멱등성, 재시도

클라우드에서 REST API를 사용할 때는 비동기, 멱등성, 재시도 개념을 알아두자.
AWS같은 퍼블릭 클라우드 서비스는 인터넷으로 REST API를 제공한다. 수많은 요청을 처리할 때 반드시 순서대로 처리하지 않고 내부에서 비동기로 요청을 처리한다.
멱등성은 여러번 동일한 요청을 날려도 리소스에 변경이 없는 특성을 의미한다. 이런 특성은 네트워크 문제로 오류가 발생하더라도 재시도 했을 때 리소스의 정합성에 문제가 생기지 않는다는 사실을 보장하는 근거가 된다.

클라우드 API 활용 예시

특정 네트워크에 연결된 서버를 기동하되, IP 주소는 공인 IP를 할당하고 해당 IP 주소에 대한 도메인을 DNS에 설정

  1. 사설 IP 주소를 확보하기 위해 서브넷을 만듬 -> POST로 서브넷 생성 요청하고 서브넷 ID 반환
  2. 서버에 사설 IP 주소를 할당 -> POST로 서브넷 ID를 함께 사설 IP 할당 요청하고 서버 ID 반환
  3. 서버에 공인 IP 주소를 할당 -> PUT으로 서버 ID를 함께 해당 서버의 퍼블릭 IP 할당 요청하고 공인 IP 주소 반환
  4. 해당 공인 IP 주소에 대한 DNS 레코드를 설정 -> POST로 DNS 레코드에 공인 IP 주소를 A 레코드에 할당.

API 이력 확인하기

AWS에서는 AWS CloudTrail로 API 호출 이력을 모니터링할 수 있다.
AWS에서는 AWS Config로 리소스의 구성 형태와 설정의 변경 이력을 관리한다.

독자적인 API 구성하기

독자적으로 만든 API를 게이트웨이처럼 두어 실제 클라우드 엔드포인트나 API를 외부에서 보이지 않도록 구성할 수 있다.
독자적으로 구성한 IaaS 상이나 독자적으로 개발한 애플리케이션과 기존 클라우드를 연계할 때, 여러 다양한 클라우드를 조합해야 할 때 사용한다.

AWS에서는 Amazon API Gateway를 사용해서 독자적인 API를 구성할 수 있다. 독자적인 API를 정의하고 백엔드에서 오리지널 API를 펑션으로 정의해서 연동할 수 있다.

Share