Home API, 클라우드
Post
Cancel

API, 클라우드

API (Application Programming Interface)

API는 둘 이상의 컴퓨터 프로그램이 서로 통신하는 방법이자 컴퓨터 사이에 있는 중계 계층을 의미한다. (WEB API 기준)

http냐 https냐, get이냐 post냐, json이냐 xml이냐 등등이 정의되어 있다.

즉 프로토콜, 메서드, 데이터 타입 등이 정의되어 있다.

ex) 업비트 API - 업비트 내부 구성이 어떻게 되어있는지 모르는데 거래가능한 마켓정보 등을 요청하면 JSON 형식으로 알려줌.

Interface?

서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이다. 이를 통해 해당 컴퓨터의 내부서버가 어떻게 구현되어 있는지는 상관없이 인터페이스를 통해 통신이 가능하다.

ex) 네이버 웹툰 - 서버나 DB가 어떻게 구성되어있는지 모르는데 웹툰 서비스를 이용할 수 있음.

API의 장점

  1. 제공자는 서비스의 중요한 부분을 드러내지 않아도 된다. 예를 들면 DB구조나 드러내고 싶지 않은 DB 테이블 정보, 서버의 상수값 등등..
  2. 사용자는 해당 서비스가 어떻게 구현되는지 알 필요 없이 필요한 정보만 받을 수 있다.
  3. OPEN API의 경우 앱 개발 프로세스를 단순화 시키고 시간과 비용을 절약할 수 있다. ex) 네이버 로그인 API를 통한 구현
  4. 내부 프로세스가 수정되었을 때 API를 매번 수정하는 것이 아닌 API가 수정이 안되도록 만들 수 있다. 이를 통해 내부 DB, 서버의 로직이 변경되어도 매번 사용자가 앱을 업데이트하는 일이 줄어들 수 있다. ex) DB 튜닝(성능향상)은 사용자에게 알릴 필요가 없음. -> API가 가로막고 있기 때문에 유저의 업데이트는 필요 없음.
  5. 제공자는 데이터를 한 곳에 모을 수 있다. 예를 들어 해당 사이트에 방문하는 방문자, 어떤 특정한 것을 클릭하는 사용자에 대한 이벤트를 집계하고 싶을 때 해당 API를 만들고 해당 이벤트가 발생하면 해당 API를 호출되도록 하면 데이터를 한 곳에 모을 수 있다.

API의 종류

  • private

내부적으로 사용된다. 주로 해시키를 하드코딩해놓고 이를 기반으로 서버와 서버간의 통신에 사용한다. 비즈니스 파트너와 해시키를 공유해 비밀스럽게 통신한다.

  • public

모든 사람이 사용할 수 있다. 많은 트래픽을 방지하기 위해 하루 요청수의 제한, 계정당 몇개 등으로 관리하게 된다.

Node.js를 이용한 간단한 API 예시

파일이 수정되어도 API가 수정되지 않도록 하는 서버의 예시.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//json
{
	"name" : "lee",
	"weight" : 90
}

//js
const express = require('express') // 웹프레임워크
const app = express()
const port = 3000
const fs = require('fs')
//get요청을 받으면. (127.0.0.1/lee)
app.get('/lee', (req, res) => {
	const f = JSON.parse(fs.readFileSync("a.json",
		encoding: "utf-8"
	}))
	const data = {
		"name" : f.name
	}
	res.send(data) //json에 name에 해당하는 부분을 보낸다.
})

app.listen(port, () => {
	console.log('http://127.0.0.1:${port}')
}

위의 코드에서 json의 weight를 수정시켜도 name만 보여주게 되기 때문에 사용자는 내부에서 weight가 변경되었는지 알 수 없다.

API를 이런 느낌으로 작성하게 되면 내부에서만 update를 할 수 있는 것이다.

클라우드(가상머신)

  • 전통적인 배포 방식

물리적인 컴퓨터 한 대에 하나의 OS를 깔고 여러가지 프로그램을 설치하는 방식. 계정을 나누어 여러명의 사용자가 이용할 수 있도록 할 수 있지만 어떤 프로그램을 설치했을 때 다른 앱에 영향을 미친다.

  • 가상화 배포방식

가상머신을 기반으로 배포하는 것. 가상머신은 컴퓨터의 하드웨어를 소프트웨어적으로 구현한 것이다.

즉 계정을 나누는 방식이 아닌 한 대의 컴퓨터를 가지고 여러 개의 OS를 돌릴 수 있게 되며 CPU와 RAM과 같은 부분 또한 물리적으로 갈아끼울 필요 없이 설정만으로 수행할 수 있어 독립적이게 만들 수 있다.

한 대의 하드웨어로 여러명의 사용자들에게 독립적으로 클라우드 서비스를 할 수 있는 것이 장점이고, 단점은 가상머신 위에 일일이 OS를 따로 설치해주어야 한다는 점이다.

오프프레미스(off-premise) / 온프레미스(on-premise)

  • 오프프레미스방식

내가 아닌 다른 회사의 공급자가 호스팅하고 인터넷을 통해 사용자에게 제공되는 인프라, 플랫폼 또는 소프트웨어를 이용하는 것.

이를 이용하면 자체 인프라나 하드웨어 설치 없이도 애플리케이션과 리소스를 쉽고 싸게 이용 가능하다.

ex) AWS

  • 온프레미스 방식

네트워크 선, 서버, DB를 직접 설치해 사용하는 것.

비용이 비싸지만 사용에 제약이 없고 보안 문제가 없다.

ex) 네이버의 데이터센터

laaS, PaaS, SaaS

IaaS (Infrastructure as a Service)

인프라형 클라우드 서비스.

클라우드가 단지 인프라를 제공한다. node.js, MongoDB 등을 개발자가 직접 설치해야 하는 대신 특정 서비스에 종속되지 않는다.

빈 방을 주고 / 그 방 안에 node.js MongoDB 등을 직접 설치해야 된다고 생각하면 쉽다.

ex) AWS의 EC2, NCP 등

AWS의 EC2를 이용할 때 가상머신 위의 리눅스에 들어가 검정 CI 화면속에서 명령어를 통해 직접 설치하고 다 해주어야 한다.

Paas (Platform as a Service)

플랫폼형 클라우드 서비스.

클라우드가 플랫폼을 제공한다. node.js, MongoDB 등이 설치되어있으며 그저 클릭을 통해 해당 서비스를 이용할 수 있다. 모니터링, CI/CD가 제공된다.

ex) heroku

Heroku는 명령어없이 웹에서 클릭을 통해 서비스를 이용할 수 있다.

SaaS (Software as a Service)

서비스형 클라우드 서비스.

완전한 서비스를 클라우드 서비스로부터 제공받아 사용한다.

ex) Google Docs

구글 독스는 문서 서비스를 클라우드를 통해 바로 제공받아 저장하고 이용할 수 있다.

IaaS와 PaaS의 비교

면접에서는 주로 이 두 개의 비교를 자주 묻는다.

 IaaSPaaS
유연성높음낮음
이식성높음낮음
운영비 효율낮음높음

서버가 터져서 다른 서버로 이전해야하는 상황을 가정했을 때 다른 서버로 옮기는 과정이 IaaS는 쉽다.

PaaS는 빌트인 형식과 비슷하게 컴포넌트들이 플랫폼에 종속되어 있기 때문에 다른 서버로 옮길 때 빌트인 된 냉장고 등을 옮긴다에 비유해 다른 서버로 옮기는 것이 어렵다고 생각할 수 있다. 유연성도 직접 설치하는 것에 비해 당연히 좀 낮다.

운영비는 모니터링, CI/CD를 PaaS는 제공해주는 경우가 많아 따로 구현할 필요도 없고 설치할 필요도 없어 비용이 들지 않는다. IaaS는 그렇지 않기 때문에 당연히 운영비 효율은 PaaS가 높다.

결론 : 유연성과 이식성이 IaaS가 높고, 운영비 측면에서 PaaS가 효율적이다.

컨테이너와 도커

  • 컨테이너

애플리케이션이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 빠르고 안정적으로 실행되도록 코드와 모든 종속성을 패키징하는 소프트웨어의 표준 단위이다.

컨테이너는 OS를 공유하기 때문에 빠르고, 경량화되어있으며 격리성도 훌륭하다. 그러나 OS에 문제가 생기면 다른 앱에도 영향을 미칠 수 있다.

(가상머신 방식은 OS를 따로따로 설치해주어야 했지만 이것은 일일이 설치할 필요 없다. 그래서 OS에 문제가 생기면 영향을 미칠 수 있다.)

이 서버에서는 되었던 것이 다른 서버에 그대로 설치하려 하면 힘들 때 ->

그 설정을 그대로 옮길 수 있도록. (DB의 설치, 이 외 환경설정 등등)

  • 도커

컨테이너 배포에 필요한 거의 모든 기능을 제공하는 플랫폼.

유연성, 이식성, 운영비 효율이 모두 좋다.

여러가지 설정을 컨테이너로 만들어 배포하기 때문.

도커의 과정

  1. 도커파일 : 패키지, 환경변수설정 등을 기록한 파일이다. 이를 빌드해 도커이미지로 변환한다.
  2. 도커이미지 : 컨테이너 실행에 필요한 파일과 설정값, 데이터 등을 포함한 상태값이며 불변한다. 하나의 이미지에서 여러개의 컨테이너를 생성할 수 있으며 컨테이너의 상태와는 무관하게 이미지는 그대로 존재한다.
  3. 도커 컨테이너 : 컨테이너가 실행되면 도커 이미지에 설정된 프로그램, 데이터 등이 실제 컴퓨팅 자원과 연결된다.
This post is licensed under CC BY 4.0 by the author.