마이크로서비스의 정의

  • 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의
  • 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식.

API란 무엇인가

Application Programming Interface

  • 애플리케이션 소프트웨어를 빌드하고 통합하기 위한 정의 및 프로토콜 세트
  • 어떤 서버의 특정한 부분에 접속해서 그 안에 있는 데이터와 서비스를 이용할 수 있게 해주는 소프트웨어 도구

사용자 인터페이스 : 컴퓨터와 인간을 연결

  • API : 컴퓨터나 소프트웨어를 서로 연결 → 컴퓨터 프로그래머가 사용할 수 있는 도구 및 서비스의 역할

목적

  • 시스템이 동작하는 방식에 관한 내부의 세세한 부분은 숨기고 일정하게 관리할 수 있는 부분들만 노출 시키는 것 ex. 도서 유통업체 : 서점직원이 유통업체의 도서 재고를 확인
  • 애플리케이션은 비용과 시간이 많이 들고 플랫폼의 제약을 받을 수 있으며 지속적인 유지관리가 필요함 → 대안으로 재고 확인용 API 제공. → 한 곳에서 재고 통합 가능 → 고객에게 영향을 미치지 않고 내부 시스템 변경 가능

장점

  • 구현 방식을 알지 못하는 제품 또는 서비스와 통신 가능
  • 애플리케이션 개발 간소화 → 시간 비용 절약
  • ex. Cloud Native Application : Cloud 환경에 최적화되어 서비스 되도록 개발한 애플리케이션. 최소의 상태 컴포넌트들이 격리된 상태의 마이크로서비스로 구성. 각각의 서비스 분산 → 탄력적 수평적 확장적 시스템으로 구성.

API보안

  • 효과적인 API 관리를 위해 API Gateway를 이용해 액세스 권한을 어떻게, 누구에게 제공할 지 여부를 결정할 수 있음
  • 액세스 권한을 어디까지 허용할 것인지에 따라 아래 세 가지로 나눌 수 있음.

API Release 정책

  • 프라이빗 : 내부에서만 사용. 기업이 API를 최대한으로 제어 가능
  • 파트너 : API를 특정 비즈니스 파트너와 공유. 품질 저하없이 추가 수익원 창출 가능
  • 퍼블릭 : 모두에게 제공. 제3자가 API와 상호작용하는 애플리케이션을 개발하여 혁신을 만들어낼 수 있음.

유형 : SOAP, REST

  1. SOAP
    • 유형 : 프로토콜
    • 기능 : 기능 위주, 구조화된 정보 전송
    • 데이터 포맷 : XML만 사용 ← 단점
    • 대역폭 : 상대적으로 많은 리소스와 대역폭이 필요
    • 데이터캐시 : 사용 불가
    • 페이로드 처리 : 엄격한 통신 규약을 갖고 있으며 모든 메시지는 보내기 전에 알려져야 함.
  2. REST
    • 유형 : 아키텍처 스타일
    • 기능 : 데이터 위주, 데이터를 위해서 리소스 접근
    • 데이터 포맷 : 일반텍스트, HTML, XML, JSON등 다양한 포맷 허용
    • 대역폭 : 상대적으로 리소스가 적게 필요하고, 무게가 가벼움
    • 데이터캐시 : 사용 가능
    • 페이로드 처리 : 공식적인 표준이 없어 미리 알릴 필요 없음.
    • REST 아키텍처의 제약 조건을 준수하는 웹 API = RESTful API
    • SOAP보다 더 많이 사용

API의 두 가지 아키텍처 접근 방식

Monolithic 아키텍처

  • 하나의 통합된 유닛
  • 소프트웨어 프로그램의 전통적인 모델.
  • 모든 비즈니스 관련 사항을 함께 결합하는 하나의 코드 베이스를 갖춘 대규모의 단일 컴퓨팅 네트워크.
  • 애플리케이션 변경 시, 코드 베이스에 액세스하고 서비스 측 인터페이스의 업데이트된 버전을 구축 및 배포하여 전체 스택을 업데이트해야함 → 제한이 많고 시간이 오래 걸림.
  • 장점
    1. 애플리케이션이 하나의 코드 베이스에 기반을 두어서 단순하기 때문에 개발 속도가 빠름.
    2. 실행 파일 또는 디렉토리가 하나여서 손쉬운 배포.
    3. 중앙 집중식 코드 베이스는 하나의 API만으로 여러 API가 수행하는 것과 동일한 기능 수행 가능.
    4. 분산된 애플리케이션보다 테스트 간소화.
    5. 모든 코드가 한 곳에 있어 간편한 디버깅
  • 규모가 커지고 확장이 어려워지면 효과적이지X : 하나의 기능을 조금만 변경하려고 해도 전체 플랫폼을 컴파일하고 테스트해야하기 때문.
  • 단점
    1. 대규모 어플리케이션에서의 복잡하고 느린 개발 속도
    2. 개별 컴포넌트 확장 불가
    3. 모듈에 오류 발생 시, 애플리케이션 전체의 가용성에 영향 → 낮은 안전성
    4. 기술 채택의 장벽 : 언어 변경 시 전체에 영향. 비용과 시간 많이 소모
    5. 약간만 변경하는 경우에도 전체 모놀리스를 다시 배포해야함.

Microservice 아키텍처

  • 독립적으로 배포할 수 있는 소규모 서비스 모음
  • 주요 비즈니스, 도메인별 문제를 별도의 독립적인 코드 베이스로 분리
  • 작업이 서로 독립적으로 작동하고 전체에 기여하는 더 작은 프로세스로 분리하여 복잡성을 눈으로 볼 수 있고 관리하기 쉽게 만듬.
  • REST API등을 통하여 서비스들의 기능을 제공하고 사용
  • 장점
    1. 대규모 어플리케이션의 관리 용이. 빠른 개발 속도
    2. 개별 컴포넌트 확장 가능
    3. 오류를 격리시킬 수 있어 탄력성 증가 → 높은 안전성
    4. 각 도메인에 적합한 프레임워크/도구/언어 선택 가능
    5. 독립적으로 개발/배포 가능

+) Netflix 사례

2009년, 빠르게 성장하는 동영상 스트리밍 서비스에 대한 수요를 인프라가 따라갈 수 없어 성장통을 겪던 넷플릭스가 모놀리식 아키텍처를 마이크로서비스 아키텍처로 대체하기로 결정. 잘 알려져 있지 않았던 구조.

Netflix는 모놀리식에서 클라우드 기반 마이크로서비스 아키텍처로 성공적으로 마이그레이션한 최초의 유명 기업 중 하나.

마이크로서비스를 구성하기 위한 핵심 요소

서비스

  • 각 컴포넌트는 서비스라는 형태로 구현되고 API를 이용하여 타 서비스와 통신
  • 서비스 경계는 구문 또는 도메인(업무)의 경계를 따름

DevOps

  • 개발, 테스트, 배포를 모두 자동화 시켜 개발 사이클이 끊임없이 순환되도록 함으로써 개발의 속도를 최대화 시키는 ..
  • 배포가 서비스의 수만큼 이루어지게 될 뿐만 아니라 테스트 또한 각각의 서비스가 연동되어 발생하는 집합체의 수만큼 필요하게 되므로 필연적으로 필요
  • 프로세스 자동화를 목표로 개발자와 운영자가 협업, 짧은 주기내 신뢰성 있는 소프트웨어 생성, 테스트, 릴리즈 할 수 있는 문화와 환경

데이터 분리

  • 서비스 별로 필요에 따라 별도의 데이터 베이스를 사용
  • 서비스가 API에서부터 데이터베이스까지 분리되는 수직분할원칙에 따름
  • 데이터베이스의 종류 자체를 다르게 하거나 같은 데이터 베이스를 사용하더라도 스키마를 나누는 방법 사용

API Gateway

  • 모든 api에 대한 end point를 통합하고 몇가지 추가적인 기능을 제공하는 미들 웨어
  • api서버 앞단에서 모든 api 서버들의 엔드 포인트를 단일화하여 묶어주고 api에 대한 인증과 인가 기능에서부터 메세지에 따라 여러 서버로 라우팅하는 고급기능까지 많은 기능을 담당.
  • 주요 기능
    • 인증/인가에 관련된 기능
      • API 토큰 발급
      • 엔드 포인트별 API 호출 인증
      • 엔드 포인트별 API 요청 인가
    • API 라우팅
      • 백엔드 API 서버로의 로드 밸런싱
      • 서비스와 클라이언트 별 엔드 포인트 제공
      • 메시지 또는 헤더기반 라우팅
    • Mediation 기능
      • 메시지 포맷 변환
      • 프로토콜 변환
      • Message Exchange Pattern
      • Aggregation
    • Logging/미터링
      • API 호출 로깅
      • API 미터링 & 차징
      • 사용 고객의 등급에 따른 서비스 레벨 조정

마이크로서비스 활용

  • Desktop Application : 특정 플랫폼이나 device에서 사용되도록 개발된 애플리케이션.
  • Web Application : 표준 web기술을 사용하여 플랫폼이나 device에 상관없이 사용되도록 개발된 애플리케이션. 프로그램은 원격 서버에 저장되고 인터넷을 통해 웹 브라우저에서 실행.
  • Cloud Native Application : Desktop + Web application
    • 클라우드 환경에서 실행되는 애플리케이션 프로그램
    • desktop app 과 같이 응답 속도가 빠르고 오프라인에서도 작업 가능
    • web app과 같이 특정 기기에 종속될 필요 없고 온라인으로 쉽게 업데이트 가능
    • 최소상태의 컴포넌트들이 격리된 상태의 마이크로서비스로 구성되며, 각각의 서비스는 분산되고, 탄력적이며 수평적 확장성 있는 시스템으로 구성됨.
    • 애플리케이션과 각각의 독립적인 배포 단위는 클라우드 중심의 디자인 패턴들과 셀프서비스 가능한 탄력적인 플랫폼에서 운영되도록 설계되어있음.
profile
숭실대학교 컴퓨터학부 21

0개의 댓글