본문 바로가기
  • 클라우드야 나랑 친해지자!
클라우드/AWS

마이크로서비스의 개념과 이해

by 정민규 2021. 2. 17.
반응형

수업을 듣고 배운 내용과 연습한 내용을 정리하였습니다

개인 공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.

 

잘못된 부분이 있거나 질문사항은 댓글로 남겨주시면 성심성의껏 답변해드리겠습니다. 감사합니다!


* 마이크로서비스의 이해

마이크로서비스(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에서만 접근할 수 있게 프라이빗 영역을 구축하게 해두면 보안상 도움이 됩니다.
반응형

댓글