Seunghan Lee

Seunghan Lee

Deep Learning, Data Science, Statistics

( 참고 : “당신이 지금 알아야 할 AWS” )

[ Data Engineering ]

8장. 마이크로서비스로 번역 웹 서비스 만들기

Contents

  1. 새로운 도전, 마이크로서비스
    1. 마이크로서비스
    2. 소프트웨어 아키텍처 구축의 역사
    3. 마이크로서비스 특징
  2. HTTP 서비스
    1. GET 방식
    2. POST 방식
    3. RestfulAPI
    4. API
  3. HTTP 응답과 상태 코드
    1. 상태 코드
  4. API 게이트웨이
    1. API 게이트웨이 아키텍쳐
    2. API 게이트웨이 & Lambda
  5. 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)

figure2

실습

  • 1) API 게이트웨이 용 Lambda 함수 생성
    • 람다 함수 생성
    • 람다 함수 실행 역할 생성
  • 2) API 게이트웨이 용 Lambda 이벤트 구성
  • 3) Lambda 함수 소스코드 작성
  • 4) DynamoDB 서비스 실행 권한을 위한 IAM 정책 설정
    • 정책 생성 및 검토
    • 역할 생성
  • 5) Dynamo DB 생성
  • 6) Lambda 함수 수정
  • 7) DynamoDB GET 확인


You May Also Enjoy

less than 1 minute read

2 minute read

4 minute read

1 minute read