[클라우드 인프라와 API의 구조] 3. 클라우드를 제어하는 API의 동작 방식

1. 클라우드와 API의 관계

1-1. API

API란 Application Program Interface로 어떤 소프트웨어에서 다른 소프트웨어를 제어하기 위해 미리 약속된 인터페이스.

• 똑같이 반복되는 소스 코드의 중복을 없애면서 표준화를 꾀할 수 있음.
• 소스 코드의 재사용성을 높여 개발 생산성을 올릴 수 있음.
• 그 소프트웨어의 내부 구조를 자세히 모르더라도 그 소프트웨어를 무리 없이 사용할 수 있는 효과.

 

1-2. 클라우드 컴퓨팅에서의 웹 API 적용

아마존에서는 서버나 스토리지와 같은 컴퓨팅 리소스를 API를 통해 제어할 수 있는 관리 체계를 구축.

2006년 이르러 그간 축적된 컴퓨팅 리소스 관리 방식을 외부로 공개했는데, 이것이 AWS EC2, S3.

특징

• 인터넷을 통해서 서버나 스토리지를 시간제로 임대하여 사용할 수 있음.
• 웹 API를 통해서 사용자가 원하는 시점에 원하는 만큼의 컴퓨팅 리소스를 할당 가능.

 

1-3. 가상화 기술과 클라우드 컴퓨팅

물리적인 서버나 스토리지를 직접 확보하는 방식은 장비를 수배하고 설치하는 과정에서 많은 시간 소요.

 

반면 가상화 환경에서는 물리적인 자원을 수배하지 않고 API를 호출하는 것만으로도 필요한 컴퓨팅 리소스를 바로 조달할 수 있음.

가상화 기술을 통해 컴퓨팅 리소스를 즉시 이용할 수 있을 뿐만 아니라, 하드웨어 리소스의 자원 활용도가 높아짐.

 

하지만, IaaS 관점에서는 리소스를 효율적으로 쓸 수 있다는 점에서 가상화가 필요할 수 있지만, PaaS, SaaS의 관점에서는 효율적인 리소스 사용보다 성능을 우선할 수 있기 때문에 가상화가 반드시 필요한 것은 아님.

또한 클라우딩 컴퓨팅이라도 성능이나 보안이 더 중요한 경우 가상화된 리소스가 아닌 물리적인 리소스를 직접 사용해야 할 수도 있음.

⇒ 클라우드의 본질은 컴퓨팅 리소스의 가상화 여부가 아니라 인터넷을 통해 필요한 자원을 제어할 수 있는 API 방식에 있음.

 

1-4. 웹 API의 구성 요소

웹 API는 크게 인증 처리, 제어할 대상, 제어 행위의 3요소로 구성됨.

 

인증 처리

• 액터로, 액터를 식별하는 처리 과정

 

제어 행위

• 액션으로, HTTP의 메소드나 헤더를 조합하여 만들어짐

 

제어할 대상

• 리소스로, 웹 API의 URI로 표현되며, 크게 네트워크 부분과 경로 부분으로 구성됨.
• 클라우드에서는 대표적인 컴퓨턴트로 서버, 스토리지, 네트워크 등이 리소스.

 

2. 리소스와 URI

엔드포인트

• API를 공개하여 서비스를 제공하는 접점 혹은 API 호출을 받아 처리하는 접점

 

2-1. 도메인, 도메인 트리, FQDN

도메인

• 네트워크상에서 자원의 위치를 표현
• 오른쪽에서 왼쪽으로 역순으로 읽으면 일종의 계층 구조처럼 표현됨.
• 상위 도메인에서 볼 때 한 단계 아래에 위치하는 도메인을 서브 도메인이라고 한다.
• 도메인과 호스트명이 하나로 연결된 전체 이름을 FQDN이라고 하며, 이 FQDN으로 네트워크 상의 수많은 호스트들 중 원하는 하나를 지정할 수 있음.

 

2-2. DNS, 가상 호스트, 레지스트리

FQDN과 IP주소가 1:N 관계

• 대규모 시스템에서 활용
• DNS가 순차적으로 IP주소를 돌려쓰기 때문에 하나의 서버가 모든 요청을 받는 때보다 부하를 줄일 수 있으며이를 DNS 라운드 로빈이라고 함.
• 클라우드에서는 CDN이나 로드밸런서에서 DNS 라운드 로빈 기능을 활용하여 확장성을 높이고 있음.
• 부하 분산을 위해 여러 서버를 사용하더라도 사용자 관점에서는 IP주소를 변경하지 않도록 IP주소의 변경 사실을 은폐하는 역할을 함.

 

2-3. 도메인과 IP주소의 변환 방법

DNS에서 IP주소를 서로 변환하는 방식

• API를 호출하는 클라이언트에서는 스텁 리졸버라는 이름 변환 요청을 대행하는 프로그램을 통해서 캐시 DNS 서버에 도메인에 해당하는 IP주소 정보를 물어본다.
• 캐시 DNS 서버에서 찾는 도메인이 없다면 루트 도메인부터 시작해서 최하위 도메인까지 각 도메인의 네임스페이스를 관리하는 DNS에 되물어봄.
• 상위 도메인 DNS 서버는 도메인 변환 처리를 하위 도메인 DNS로 위임한 것이며 질의한 측은 다시 위임받은 하위 도메인 DNS 서버로 IP 주소 정보를 물어보며 이러한 과정은 최하위 도메인의 DNS 서버에 이르기까지 연쇄적으로 반복되며 이 과정을 DNS 쿼리라고 부름.
• 이 방식은 상위 DNS 서버에 몰릴수 있는 부하를 경감해주기 위해 DNS 캐시 서버를 필요로 함.

 

재귀적 질의

• 클라이언트에서 DNS 캐시 서버로 질의하는 것

 

비재귀적 질의

• DNS 캐시 서버 자신이 루트 DNS 서버나 다른 DNS 서버로 질의하는 것.

 

도메인을 설계할 때는 가능하면 비재귀적 질의를 많이 사용하도록 만드는 것이 중요한데 AWS 엔드포인트의 경우, 같은 리전에 있는 같은 서비스라면 같은 도메인 범위에 들어가기 때문에 비재귀적 쿼리를 많이 할 수 있음.

이와 같은 클라우드에서는 FQDN을 사용한 네트워크 접근이 많기 때문에 DNS 캐시가 큰 역할을 수행.

 

2-4. 엔드포인트

클라이언트가 클라우드에 공개된 API를 실행하기 위해 접속하는 연결 접점.

과거의 물리적인 온프레미스 환경에서는 인프라 자원을 제어하기 위해 물리적인 장비에 직접 접속했어야 했음.

반면 클라우드 환경에서는 인프라 컴포넌트를 제어하기 위해 엔드포인트에 접속.