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

목차

3장

1. API가 무엇인지
2. 웹 기술 배경 지식
   1. HTTP
   2. 가상화 기술과 클라우드 컴퓨팅
   3. SOA
   4. 웹 API의 구성 요소
   5. 리소스
   6. 액션
   7. 도메인
   8. DNS
   9. 엔드포인트
   10. ROA
3. 클라우드를 제어할 수 있는 사용자 인터페이스
   
   1. API
   2. CLI
   3. SDK
   4. 콘솔

4장

1. 물리적 서버 vs 서버 가상화
2. 서버 가상화 vs 클라우드

---

3장

API(Application Program Interface, 애플리케이션 프로그램 인터페이스)

어떤 소프트웨어에서 다른 소프트웨어를 제어하기 위해 미리 약속된 인터페이스나 규약을 의미한다.

• API를 사용하면 똑같이 반복되는 소스 코드의 중복을 없애면서 표준화를 꾀할 수 있다.
• 소스 코드의 재사용성을 높여 개발 생산성을 올리는 효과를 내기도 한다.

웹 API

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

웹 기술 발전으로 아마존, 구글, 야후, 이베이와 같은 기업들은 자신들이 가진 정보를 제3자가 효과적으로 활용할 수 있도록 웹 API를 공개했다.

ex) 아마존의 Product Advertising API (아마존에서 판매하는 상품 데이터베이스에 접근하는 API)

아마존은 API를 공개함으로써 개발자들의 참여를 끌어 모았고, 다양한 애플리케이션에서 아마존의 전자상거래 사이트로 연결되도록 유도, 자사 서비스를 더욱 확대하는 큰 성과를 거두었다.
최근에는 페이스북이나 트위터를 포함해 많은 인기 서비스 업체들이 자신의 서비스 API를 외부에 공개하는 것이 대세가 되었다. API를 공개해야 경쟁에 살아남는 새로운 환경이 만들어지고 있다.

광고 API를 성공시킨 아마존은 사용량이 폭주하는 자사 전자상거래 사이트를 안정적으로 운영할 필요를 느낌. → 컴퓨팅 리소스를 API를 통해 제어할 수 있는 관리 체계 구축(오늘날의 EC2, S3 - 클라우드 컴퓨팅의 탄생)

클라우드 컴퓨팅의 두 가지 특징에 주목

1. 인터넷을 통해 서버나 스토리지를 시간제로 임대하여 사용할 수 있다.
2. 인터넷 서비스가 제공하는 웹 API를 통해 사용자가 원하는 시점에 원하는 만큼 컴퓨팅 리소스를 할당받을 수 있다.
   (이 책은 후자에 무게를 두고 있음)

클라우드 컴퓨팅을 제공하는 대부분의 회사는 아마존, 구글, 세일즈포스, 마이크로소프트와 같은 인터넷 기업들이 대부분이다. 이러한 기업들이 클라우드 컴퓨팅과 웹 API 관련 기술을 이끌고 있어 클라우드와 웹 API의 관계는 점점 견고해지고 있다.

AWS에서는 API 호출 이력을 관리하는 AWS CloudTrail과 리소스의 구성 형태와 설정의 변경 이력을 관리하는 AWS Config라는 서비스가 있다.

 

웹 기술 배경 지식

1. HTTP(Hypertext Transfer Protocol)
   • 웹 서버의 HTML 데이터를 웹 브라우저가 받아 화면에 표시하기 위해 정의됨
   • 이후 HTML안에 스크립트를 넣을 수 있는 자바스크립트, 자바, .NET 등이 웹을 지원하게 되었으며 비동기 방식으로 XML 데이터를 주고 받을 수 있는 Ajax 같은 기술들이 도입되며 정적인 웹사이트는 복잡하고 동적인 웹 애플리케이션으로 변모하며 웹 기술이 크게 발전하게 되었다.
2. 가상화 기술과 클라우드 컴퓨팅
   • 물리적인 서버나 스토리지를 직접 확보하는 방식은 장비를 수배하고 설치하는 과정에서 적지 않은 시간이 소요됨
   • 반면, 가상화 환경에서는 물리적인 자원을 수배하지 않고 API 호출하는 것만으로도 필요한 컴퓨팅 리소스를 바로 조달할 수 있다.
     • 가상화 기술 보급이 활발해지면서 클라우드 컴퓨팅의 약진도 두드러지게 되었다.
       • 컴퓨팅 리소스를 즉시 이용할 수 있게 되었고
       • 하드웨어 리소스의 자원 활용도가 높아져 클라우드 컴퓨팅 방식이 수익 모델 측면에서도 긍정적 결과를 낳았기 때문
   • 한편, IaaS 관점에서는 리소스를 효율적으로 쓸 수 있다는 면에서 가상화가 필요할 수 있지만
   • PaaS나 SaaS 관점에서는 효율적인 리소스 사용보다 성능을 우선할 수도 있기 때문에 가상화가 반드시 필요하지는 않다.
   • 즉, 가상화 기술이 클라우드 컴퓨팅의 발전에 기여한 것은 맞지만 클라우드 컴퓨팅의 본질이라고 보기 어렵다.
     • 성능이나 보안이 더 중요한 경우 물리적인 리소스를 직접 사용할 수도 있기 때문
   • 클라우드의 본질은 컴퓨팅 리소스의 가상화 여부가 아니라 인터넷을 통해 필요한 자원을 제어할 수 있는 API 방식에 있다는 것을 알 수 있다.
3. SOA(Service Oriented Architecture)
   • 애플리케이션들의 기능을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재조합한 후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만드는 소프트웨어 아키텍처(과거 웹 서비스)
   • SOA vs 웹 API
     • SOA가 폐쇄적인 네트워크 안에서 사내 정보 시스템을 연계하고 제한된 사용자가 이용하는 용도로 많이 활용되었다면,
     • 웹 API는 인터넷과 같은 개방된 네트워크 안에서 누구나 사용할 수 있도록 기능의 처리 로직이나 데이터 구조를 간결하게 만들어 제공하는 경향이 강하다.
4. 웹 API의 구성 요소(3요소)
   1. 인증 처리 : API 관점에서 액터에 해당하며 액터를 식별하는 처리 과정이 인증 처리이다.
      • 클라우드 서비스가 제공하는 독자적인 인증 기능을 사용(9장)
   2. 제어할 대상 : API 관점에서 리소스에 해당하며 URI로 표현
      • URI는 크게 네트워크 부분과 경로(Path) 부분으로 구성된다.
   3. 제어 행위 : API 관점에서 액션에 해당하며 HTTP 메소드로 표현
      • HTTP 메소드나 헤더를 조합해서 만들어진다.
5. 리소스
   • 클라우드의 대표적인 컴포넌트인 서버, 스토리지, 네트워크 등이 리소스이다.
   • 서버에서는 인스턴스, 이미지, 키 페어 등이 리소스이고,
   • 네트워크에서는 라우터, 서브넷, 시큐리티 그룹 등이 리소스에 해당한다.
   • 리소스들은 다른 리소스들과 구분되도록 고유한 식별 키가 필요한데 크게 두 가지 유형이 있다.
     • 두 가지 키 유형 중에서 어떤 방식이 사용되는지는 컴포넌트 단위로 결정된다. 컴포넌트 문서 확인하면 된다.
     1. UUID
        • 랜덤으로 부여됨.
        • 인스턴스나 서브넷을 생성하면 UUID 역할을 하는 인스턴스 ID나 서브넷 ID가 만들어진다. 특정 인스턴스를 지정해야 할 때 UUID를 사용하면 된다.
     2. 이름
        • 오브젝트 스토리지를 담는 버킷(컨테이너) 안에 들어 있는 오브젝트(파일)을 지정할 때는 버킷 이름과 오브젝트 이름을 사용한다.
   • 리소스 중에서는 고유한 키를 가지는 속성 정보가 있는데 이를 프로퍼티라고 한다.
     • ex) 가용 영역, 이미지 ID
   • URI(Uniform Resource Identifier)에는 URL(Uniform Resource Locator)과 URN(Uniform Resource Name)이 포함되어 있다.
     • URL : 네트워크 부분(도메인)과 경로 부분( 네트워크 부분 이후(/ 이후)의 계층적 경로)으로 나뉜다.
       • 네트워크 부분 : '스키마명(프로토콜), 인증 정보, FQDN, 포트 번호' 로 구성된다. 클라우드의 컴포넌트, 혹은 서비스를 가리킴
       • 경로 부분 : 디렉터리 경로와 파일 이름이 사용되는데 쿼리 파라미터나 프래그먼트 식별자를 추가하기도 한다. 구체적인 리소스의 경로에 해당한다.
         • 쿼리 파라미터는 조건을 지정하고 싶을 때 '/?q=***' 형태로 사용한다.
         • 프래그먼트 식별자는 웹 페이지 내용이 길어져 전체 내용을 파악하기 어려울 때 '#' 문자를 사용하여 특정 위치로 이동하도록 만든다.
     • URN : 네트워크에 상관없이 리소스의 이름을 BNF(Backus-Naur from) 배커스-나우르 표기법으로 정의한다. ':'나 '<', '>' 문자를 조합하여 표기하는데 구성 요소의 관계나 문법을 표현할 때 사용한다.
       • AWS Amazon 리소스 이름이나 리소스 프로퍼티타입이 대표적인 예시이다.
       • 네트워크와 상관없이 내부 기능에 필요한 리소스를 가리키는데 사용된다.
6. 액션
   • 리소스에 대해 행하는 동작으로 CRUD(Create, Read, Update, Delete) 라고 표현하고 등록, 조회, 수정, 삭제가 대표적이다.
   • 리소스의 URI를 호출할 때 사용되는 HTTP 메소드와 쿼리 문자열 파라미터 정보를 활용한다.
   • 조회, 수정, 삭제에 해당하는 제어는 제어 대상을 식별하기 위한 키가 필요하고, 등록에 해당하는 제어는 기존에 없는 리소스를 만드는 것이기 때문에 생성 조건을 지정하되 키는 필요하지 않다.
7. 도메인
   • 네트워크상에서 자원의 위치를 표현할 때 IP 주소와 같은 숫자 형태가 아니라 사람이 식별하기 쉬운 문자 형태로 표현하며, 해당 호스트의 의미를 알 수 있는 단어들이 점으로 구분된 형태로 구성된다.
   • 도메인 트리 : 오른쪽에서 왼쪽으로 역순으로 읽으면 일종의 계층 구조처럼 표현되도록 구성되어 있다. 맨 마지막 부분이 리소스(호스트명이 됨).
   • FQDN(Fully Qualified Domain Name, 정규화된 도메인) : 호스트명과 도메인이 하나로 연결된 전체 이름
8. DNS(Domain Name System)
   • 도메인과 IP 주소 사이의 변환 기능을 해주는 것을 DNS라고 한다.
     • DNS 질의 혹은 DNS 쿼리라고 부르는 질의 과정을 거쳐서 변환한다.
       • 상위 도메인 DNS가 하위 도메인 DNS에 위임하고, 질의한 측(DNS 캐시 서버)은 다시 위임 받은 하위 도메인 DNS 서버로 IP 주소 정보를 물어본다.
       • 연쇄적으로 반복
     • 정방향 : 도메인 → IP
     • 역방향 : IP → 도메인
   • FQDN : IP = 1 : N - 부하 분산, DNS round robin
     • 대규모 시스템에서 활용되는 관계. 하나의 IP 주소로 제대로 대응하지 못하여 DNS에서 FQDN에 대응하는 IP주소를 여러 개 등록하는 방법을 쓴다.
     • 이렇게 하면 DNS가 순차적으로 IP 주소를 돌려쓰기 때문에 하나의 서버가 모든 요청을 받는 때보다 부하를 줄일 수 있다. 이것을 DNS 라운드 로빈이라고 한다.
     • 클라우드에서는 CDN이나 로드밸런서에서 DNS 라운드 로빈 기능을 활용하여 확장성을 높이고 있다.
     • 사용자 관점에서 IP 주소 변경 사실을 은폐하는 역할을 하기도 한다.
   • FQDN : IP = N : 1 - 가상 호스트
     • 서버 리소스를 보다 효율적으로 활용하고 싶을 때 사용한다. 이를 잘 활용하고 있는 것이 가상 호스트이다.
     • DNS에서 여러 FQDN이 같은 IP 주소에 매핑되도록 하면 된다.
9. 엔드포인트
   • 클라이언트가 클라우드에 공개된 API를 실행하기 위해 접속하는 연결 접점을 엔드포인트라고 한다.
   • 리전과 제어할 컴포넌트도 다르다면, 접속할 엔드포인트도 달라진다.
   • 클라우드에서는 엔드포인트로 도메인을 사용한다. IP대신 도메인을 사용하는 이유는 사람이 알아보기 쉽기 때문이다. 또한, 사용자로부터 IP 주소를 은폐할 수 있다. IP 주소가 공개였다면 부하 분산을 위해 IP 주소를 바꾸려고할 때 어려움이 있다. 사용자가 바뀔 IP 주소가 무엇인지 알 방법이 없기 때문에.
   • 도메인을 활용함으로써, 스케일 아웃으로 대응할 수 있고, 반대로 사용량이 줄어들 때도 가용한 리소스를 다른 용도로 돌려 쓸 수 있다. 즉, DNS 라운드 로빈 방식이나 가상 호스트 방식을 사용하여 FQDN과 IP 주소를 1:N, N:1로 적절히 매핑 관계를 바꿔주면 엔드포인트를 수정하지 않더라도 환경적인 변화에 유연하게 대응할 수 있다.
   • 가용성과 확장성이 필요할 때 FQDN을 사용하는 것이 일반적이다. 그래서 DNS 역할이 중요하다.
10. ROA(Resource Oriented Architecture)
    • 리소스 지향 아키텍처란 REST API의 사상을 기반으로 리소스 중심적인 API를 사용하는 아키텍처를 말한다. 
    • REST(Representational State Transfer)
      
      • HTTP 프로토콜을 사용하여 리소스의 관계 정보를 URL의 경로에 계층 형태로 표현하는 방법
      • REST 특징을 잘 살린 API를 RESTful API, REST API 라고 한다.
      • 4가지 설계 지침
        1. 상태를 가지지 않도록 만든다 : 상태를 가지지 않으므로 구현이 쉽고 캐시를 사용할 수 있어 성능이 우수하다.
        2. URI는 디렉터리 구조처럼 계층적으로 만든다 : URI의 가독성이 좋고 리소스의 구조를 이해하기 쉽다.
        3. HTTP 메소드를 명시적으로 사용한다 : 리소스의 상태 변화를 HTTP 메소드를 활용하여 리소스 중심으로 처리하고 별도의 메소드를 사용하여 행위 중심으로 처리하지 않도록 한다.
        4. 응답할 때는 XML이나 JSON을 사용한다 : 데이터 표현을 정규화해서 다른 언어나 기술 구조에서도 데이터를 활용할 수 있도록 한다.
      • 행위 중심이 아닌 자원 중심으로 설계할 때 만드시 필요한 고려사항이라는 것을 알 수 있다.
    • 클라우드와 같은 분산 환경을 제어할 때 알아야 할 REST API 특징 세 가지
      1. 비동기
         • 인터넷 망을 사용하기 때문에 응답이 지연될 수 있다. 먼저 보낸 요청이 뒤에 보낸 요청보다 반드시 먼저 도착한다고 보장할 수 없고 리소스가 여러 곳에 분산되어 있으며 처리 과정도 비동기로 처리된다.
      2. 멱등성
         • 상태가 없기 때문에 같은 API를 몇 번을 호출하더라도 리소스에 변경이 발생하지 않는 한 같은 결과가 나온다.
      3. 재시도
         • 멱등성이 보장되면, 네트워크 상태가 좋지 않아 오류가 발생하더라도 HTTP 에러 코드를 보고 다시 한번 시도할 수 있다. 재시도 결과 응답으로 오는 메타 데이터는 멱등성에 의해 같은 값이 나오기 때문에 최종 정합성도 보장된다.

클라우드를 제어할 수 있는 사용자 인터페이스 4가지

• API : 앞에서 살펴봄
• CLI : 명령줄로 제어할 수 있는 사용자 인터페이스. 대부분 클라우드가 기본적으로 제공
• SDK : 프로그램 언어를 통해 클라우드 환경을 제어하도록 도와주는 개발 도구
• 콘솔 : GUI(Graphical User Interface) 형태로 클라우드를 제어할 수 있는 사용자 인터페이스. CLI, SDK 와 다르게 웹 애플리케이션 형태이기 때문에 서버 측이 업데이트 되어도 별다른 추가작업 없이 최신 기능을 사용할 수 있다.

 

4장

1. 물리적 서버 vs 서버 가상화
   • p. 157 그림 참고
   • 서버의 반입, 랙에 탑재하는 작업, 케이블 배선과 같은 물리적인 작업이 필요없어졌다.
   • 서버를 선택할 때 제품 카탈로그를 사양을 선택했던 반면, 가상 환경에서는 리소스(가상 CPU의 개수나 가상 메모리 용량)를 선택하는 방식으로 바뀌었다. 서버를 랙에 탑재했던 작업도 가상 서버를 물리 서버에 할당하는 방식으로 대체되었다.
   • 이렇게, 소프트웨어적인 요구 사항을 고려하여 작업을 하는 방식으로 인프라 구축 방식이 바뀌며 물리적인 작업량이 전체적으로 줄어들었지만, 소프트웨어 작업으로 대체되는 부분을 제외하면 그 이전에 필요한 작업의 양이 줄지 않는다.
   • 줄어든 작업량을 얼마 되지 않음.
   • 제한된 인력으로 얼마나 어떻게 효율적으로 작업을 줄일 수 있느냐가 풀어야할 과제이다. 이러한 문제를 해결하는데 클라우드를 사용하는 것이 하나의 해결 방법이 될 수 있다.
2. 서버 가상화 vs 클라우드
   • 물리적인 작업량을 효율적으로 줄여주는 클라우드 API의 활용이 큰 역할을 한다.
   • p. 161 그림 참고
   • 클라우드(오픈스택) 환경에서는 작업이 크게 세 부분으로 나뉘어진다.
     1. 플레이버
        • 생성할 가상 서버의 사양을 선택하는 것과 같다. (인스턴스 유형)
        • 플레이버란 가상 CPU의 개수나 메모리, 가상 디스크의 용량 등을 미리 설정하여 언제든지 재사용할 수 있도록 준비해둔 것으로 '서버 사양 템플릿'으로 이해하면 된다.
        • 클라우드 환경에서는 미리 준비된 플레이버를 선택하기만 하면 된다.
        • 선택의 폭을 제한함으로써 의사결정 속도가 월등히 빨라짐 → 효율성을 높임
     2. 설정 스크립트 작성
        • 가상 서버가 기동된 직후에 수행되는 설정 작업을 스크립트 형태로 만든 것으로 최초 기동 시에 일괄 처리하기 위해 만들어진다.
        • 패키지 설치나 설정, 각종 서비스의 자동 실행과 같은 내용이 포함된다. 테스트하는 툴을 실행하기도 한다.
        • 몇 번이든 재현할 수 있을 뿐 아니라 실수 없이 작업된다는 장점이 있다.
     3. 가상 서버를 생성하는 명령 실행
        • 오픈스택의 nova 명령을 사용하여 가상 서버를 기동한다.
        • aws의 경우 'aws ec2 run-instances'를 사용한다.
   • 클라우드 환경의 또 다른 장점
     • 사양 선택이 잘못되거나 요구 사항이 바뀌는 상황에서도 시스템을 재구축하는 것이 쉽다.
     • IP 주소 할당 작업도 자동화할 수 있다. 가상 서버가 제거되면 회수하여 재사용한다.
     • 물리적인 장비에 필요한 작업이 완전히 제거됨
     • 이렇게 클라우드 API는 과거에 사람이 직접 했던 작업들을 프로그램이 대신하게 되어 작업 효율을 높이는 역할을 한다.
   • 효율화의 핵심은 '사람의 판단과 수작업'을 얼마나 줄일 수 있느냐에 달렸다. 클라우드 환경에서는 사람의 판단과 수작업을 자동화해서 프로그램이 대행하도록 하거나 애당초 그러한 판단 자체를 불필요하게 만들어 효율화를 꾀한다.

 

마무리하며

클라우드 API의 본질을 이해하지 못하고 과거와 같은 방식으로 시스템을 운영한다면 클라우드를 도입하더라도 효용을 제대로 누리지 못할 수 있다. 클라우드를 사용하면서도 IP 주소를 할당하기 위해 관리 대장을 만들어서 관리한다거나, 자동으로 설정할 수 있는 내용을 작업 계획서에 하나하나 기재하고 수작업으로 처리하는 경우를 예로 들 수 있다.

클라우드 API를 제대로 활용하려면 과거와는 다른 방식으로 생각하고 접근해야 한다.

 

참고문헌

그림으로 배우는 클라우드 인프라와 API의 구조 [신상재, 로드북]