( 참고 : “당신이 지금 알아야 할 AWS” )
[ Data Engineering ]
8장. 마이크로서비스로 번역 웹 서비스 만들기
Contents
- 새로운 도전, 마이크로서비스
- 마이크로서비스
- 소프트웨어 아키텍처 구축의 역사
- 마이크로서비스 특징
- HTTP 서비스
- GET 방식
- POST 방식
- RestfulAPI
- API
- HTTP 응답과 상태 코드
- 상태 코드
- API 게이트웨이
- API 게이트웨이 아키텍쳐
- API 게이트웨이 & Lambda
- API 게이트웨이 & 데이터베이스 (GET)
8.1. 새로운 도전, 마이크로서비스
8.1.1. 마이크로서비스
마이크로서비스 = “소프트웨어를 구축하기 위한 아키텍처 (새로운 방식)”
비교
- 전통적인 모노로틱 (Monolothic) 접근 방식 : 모든 요소를 하나의 애플리케이션에 구축
- 마이크로서비스 : 모든 요소가 독립적 & 동일한 작업을 수행하기 위해 함께 작동
클라우드의 가장 큰 장점 : “확장성” ( = 트래픽 증가 시, 유연하게 확장해 대응 OK )
-
BUT, 만약 서비스가 한 덩어리고 구성돼 있으면, 애플리케이션 전체를 늘려가는 식으로 확장해야!
ex) 추석 연휴에 homepage 폭주 시, 특정 부분만 복제해서 병렬 처리하지 못하는 구조라면, 웹사이트 전체를 계속 늘려야! ( 클라우드 자원을 더 쓰게 됨 …. 비용 증가! )
-
클라우드 네이티브 (Cloud Native) :
- before ) “모든 기능이 단일 소스로 통합된 기존 개발방법론”(Monolothic)
- now ) 작은 서비스(Micro)로 전환
컨테이너 서비스 : 이러한 마이크로서비스 방법론을 개발한 애플리케이션을 효과적으로 배포/활용할 기술
-
영역별/기능별/담당자별로 “분할”해 개발
( 분할 = 개발을 담당하는 조직 크기가 작아진다는 뜻 )
-
따라서 의사결정 Faster, 보안 강화 수월
8.1.2. 소프트웨어 아키텍처 구축의 역사
(1) 초창기 개발 : 모놀로틱 방식
-
거대한 단일 소스
-
(단점) 이미 개발한 기존 애플리케이션을 수정할 때 문제가 됨
( 기존 소스의 재활용 불가, 처음 부터 다시 만들어야 )
(2) 객체지향개발 (CBD)
-
기능 단위 로직으로 분할하여 개발
-
로직과 DB가 따로 떨어져 있어서, 둘을 함께 복제해야만 작동할 수 있음
( 모놀로틱과 큰 차이가… )
(3) 마이크로 서비스 (Micro Service)
-
클라우드에 최적화된 “클라우드 네이티브”
-
거대한 DB를 두는게 아니라,
마이크로서비스 컴포넌트별로 DB를 만들고, 작은 DB와 작은 서비스가 서로 묶여있는 구조
-
하나 하나가 완벽하게 “독자적”으로 작동
8.1.3. 마이크로서비스 특징
-
분산형 개발을 통해 업무 능력 향상!
-
동일한 애플리케이션 개발에 더 많은 개발자들이 동시 참여 OK & 개발 소요 시간 단축
(1) 편리한 엑세스
- 하나의 큰 애플리케이션을 더 작은 조각으로 분할
(2) 향상된 개방성
- 다중 언어 지원 API를 통해, 필요한 기능에 맞는 최적의 언어/기술 선택 가능
(3) 간단한 배포
- 더욱 모듈화 & 작아진 규모
- 더 많은 협업이 필요하지만, 몇 배로 향상된 결과 도출
8.2. HTTP 서비스
Client & Server
- Client : 데이터를 요청(request)하는 쪽
- Server : 데이터를 응답(Response)하여 보내주는 쪽.
요청 message & 응답 message
- 둘 다 Message Header와 Message Body로 구성
- Message Header의 구성 요소
- 1) 요청 방식
- 2) URL (Path)
- 3) 프로토콜 버전
- 4) Header Field
Message 요청 방식
- 1) GET : URL에 데이터를 “명시 O”
- 2) POST : URL에 데이터를 “명시 X”
.
8.2.1. GET 방식
- 데이터를 전달할 떄, Query Parameter를 통해 전달할 수 있음
- Query Parameter
- ? ~ # 사이의 값
- Key=Value 형태로 구분
- 2개 이상의 복수 데이터를 전달할 경우 “&”로 구분
8.2.2. POST 방식
-
GET 방식의 문제점 : 1000줄이 넘는 게시글을 작성하면…? URL의 길이는…?
-
이를 해결하기 위해..
데이터의 제한이 없고, 눈에 보이지 않는 POST 방식을 사용
-
장문 or 중요한 정보 전달 시 사용
8.2.3. RestfulAPI
-
GET과 POST 방식을 확장한 개념
-
GET : “어떠한 데이터를 가져올 때”
POST : “서버에 어떠한 값이나 상태를 변경할 때”
-
RestfulAPI는 이러한 POST의 개념을 더 세분화하여, PUT과 DELETE를 추가
| Method | 역할 |
|---|---|
| POST | 리소스를 생성 |
| GET | 리소스를 조회 |
| PUT | 리소스를 수정 |
| DELETE | 리소스를 삭제 |
8.2.4. API
API = Application Programming Interface
-
“데이터를 주고받기 위한 방법”
- 일종의 규격, 약속
- 구분 : Open API & 비공개 API
API가 필요하려면?
- 다른 사람에게 정보를 제공하려면 별도의 규격을 만들어야하고, 그에 대한 설명 문서또한 만들어야! 불편해!
- ex) 간편 로그인 API
- 너무 많은 사이트에 가입할 필요 X
8.3. HTTP 응답과 상태 코드
8.3.1. 상태 코드
-
지금까지는 “요청”하는 방법, 이제는 “응답”하는 방법
-
서버의 역할 = 응답 보내기
( 이 때 사용하는 방법이 HTTP 프로토콜 )
-
상태 코드 = “사용자가 요청한 데이터에 대한 상태”
HTTP 응답 형식
- Message Body를 통해 데이터를 전달
8.4. API 게이트웨이
8.4.1. API 게이트웨이 아키텍쳐
-
HTTP 프로토콜을 이용하여 API를 개발자가 손쉽게 구축할 수 있는 완전관리형 서비스
-
역할 : 중간 관문 ( 모바일 IoT 디바이스 & AWS 서비스 이어줌 )
-
미리 정의된 URL로, GET/POST 요청이 들어올 때마다,
lambda, S3등 AWS 주요 웹 서비스를 실행하고
결과를 상태코드와 함께 리턴
.
8.4.2. API 게이트웨이 & Lambda
- API 게이트웨이 & Lambda -> 마이크로 서비스 architecture로 유용하게 사용
- 일반적인 마이크로서비스로는,
- step 1) API 게이트웨이를 통해 HTTP 통신의 header & body를 받고,
- step 2) Lambda에서 데이터를 처리한 후
- step 3) JSON으로 변호나하여
- step4 ) 다시 API 게이트웨이에서 HTTP 프로토콜에 맞게 응답 메세지를 보냄
8.5. API 게이트웨이 & 데이터베이스 (GET)
실습
- 1) API 게이트웨이 용 Lambda 함수 생성
- 람다 함수 생성
- 람다 함수 실행 역할 생성
- 2) API 게이트웨이 용 Lambda 이벤트 구성
- 3) Lambda 함수 소스코드 작성
- 4) DynamoDB 서비스 실행 권한을 위한 IAM 정책 설정
- 정책 생성 및 검토
- 역할 생성
- 5) Dynamo DB 생성
- 6) Lambda 함수 수정
- 7) DynamoDB GET 확인