수업을 듣고 배운 내용과 연습한 내용을 정리하였습니다
개인 공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
잘못된 부분이 있거나 질문사항은 댓글로 남겨주시면 성심성의껏 답변해드리겠습니다. 감사합니다!
* 마이크로서비스의 이해
마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. 마이크로서비스 아키텍처에서 서비스들은 섬세(fine-grained)하고 프로토콜은 가벼운 편이다. 애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄력적으로 만들어 준다. 규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 한다. 또, 지속적인 리팩터링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용한다. 마이크로서비스 기반 아키텍처는 지속적 배포와 전개(디플로이)를 가능케 한다
- 출처 : 위키백과 -
* 마이크로서비스의 특징
- 편리한 액세스 : 하나의 큰 애플리케이션을 더 작은 조각으로 분할해서, 개발자들이 각 조각을 파악하고 업데이트하며 개선하기가 보다 편리해졌습니다. 이로 인해 애자일 방식과 결합할 경우 개발 주기를 더욱 가속화 할 수 있습니다.
- 향상된 개방성 : 다중 언어 지원 API를 사용해서, 개발자들은 필요한 기능에 맞는 최적의 언어와 기술을 자유롭게 선택할 수 있습니다.
- 간단한 배포 : 전통적인 모놀리식 애플리케이션에 비해 더욱 모듈화되고 규모가 작아져서 배포에 따르는 우려 사항들이 사라졋습니다.
* HTTP (HyperText Transfer Protocol)
- 하이퍼 텍스트 : 링크를 포함한 텍스트
- header : 요청에 대한 정보가 들어있음 ( 요청방식, 웹브라우저의 종류, 내용물의 크기, 내용물의 종류, 언어 등 )
- body : 내용물 ( 웹 페이지 : html, 이미지, 동영상 등 ) ---> 요청한 데이터
* URL과 URI의 차이
http://abc.com ---> URL
http://abc.com/?data=123 ---> URI
* HTTP 요청 방식
-GET 방식
->단순 페이지 요청 ( 가장 많이 사용 : 98%, body를 사용하지 않고, header만 사용해서 요청 )
->URI를 통해 데이터를 전달하기 때문에 같은 URI를 전달하면 서버에는 항상 데이터를 같이 전달합니다.
->URI 길이를 제한해야 하는 단점이 있고 로그인 사용자라면 쿼리 파라미터를 통해 사용자의 아이디와 비밀번호가 노출 될 위험이 있음 ---> 데이터의 제한이 없고 눈에 보이지 않는 POST 방식 사용
-POST
-> 내용물을 넣어서 서버에 전달 ( 게시판 글쓰기, 파일 업로드, 로그인 등 ----> header와 body를 사용 )
-> 주로 웹상에서 입력 폼과 같이 장문의 데이터나 회원 가입처럼 사용자의 중요한 정보를 전달하는 데 많이 사용함.
-RestfulAPI
-> GET과 POST 방식을 확장한 개념.
-> GET이라는 메서드 이름에서 유추할 수 있듯이 어떠한 데이터를 가져올 때 GET을 사용하고, 서버에 어떠한 값이나 상태를 변경하기 위해 POST 방식을 사용함.
-> RestfulAPI는 POST의 개념을 더 세분화하여 PUT(데이터의 수정)과 DELETE(데이터의 삭제)라는 메서드를 추가로 사용함.
* API ( Application Programming Interface )
어떠한 응용 프로그램에서 데이터를 주고받기 위한 방법.
응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다.
* HTTP 상태 코드
- 200 : 성공(success)
- 401 : unauthorized ( 권한 없음 -> 로그인하면 볼 수 있음 )
- 403 : forbidden ( 요청을 거부하는 경우 )
- 404 : Not Found ( 서버에서 찾을 수 없음 )
404코드는 Path를 통해 서버에 요청했지만 데이터를 찾을 수 없을 때, 서버가 클라이언트에게 알려주는 상태 코드입니다. 다시 말해, 사용자가 전달한 데이터는 받았지만 요청하는 데이터는 찾을 수 없다는 의미를 가지고 있는 것입니다.
*API 게이트웨이
- 미리 정의된 URL로 GET 혹은 POST 요청 등이 들어올 때 람다, S3등 AWS 주요 웹 서비스를 실행하고 결과를 상태 코드와 함께 리턴합니다.
- 람다의 함수 구조에서 입력인자를 맡는 서비스가 API 게이트웨이이고, 이는 사용자 요청을 받으면 정의된 서비스로 데이터를 전달합니다.
- 정해진 사용자만 접근을 인가해주고 사용 기록을 확인하며 모니터링할 수 있습니다.
- API 서버 앞에서 모든 API 서버들의 마지막 부분을 단일화하여 묶어주는 역할을 합니다.
- 간단하게 모든 서비스의 요청을 받은 후 해당 서비스로 이동시켜주는 기능을 하기 때문에 외부에서 접글할 수 있도록 공개적으로 열어두고 각 서비스들은 내부 IP에서만 접근할 수 있게 프라이빗 영역을 구축하게 해두면 보안상 도움이 됩니다.
'클라우드 > AWS' 카테고리의 다른 글
마이크로서비스 기반 번역 웹 서비스(POST) (2) | 2021.02.17 |
---|---|
API 게이트웨이와 데이터베이스(GET) (0) | 2021.02.17 |
Lambda 함수 기반 AWS 지출 요금 모니터링 (0) | 2021.02.17 |
Lambda 함수 기반 문자 알림 서비스 (0) | 2021.02.17 |
데이터베이스 종류 및 NoSQL 테이블 생성 및 쿼리 실습 (0) | 2021.02.16 |
댓글