SOA(Service Oriented Architecture)
•
네트워크에서 공통의 통신 언어를 사용하는 서비스 인터페이스를 활용하여 소프트웨어 구성 요소를 다시 사용할 수 있게 만드는 소프트웨어 설계 유형
•
SOA는 엔터프라이즈 서비스 버스(ESB)라는 중앙화된 구성 요소를 사용하고 ESB와 백엔드 시스템을 통합한 다음 이를 서비스 인터페이스의 형태로 제공한다.
•
SOA는 서비스 단위로 개발을 하고, 개발된 서비스들을 공유함으로써 재가용성을 늘리고 유연성을 확보하는것을 목표로 한다.
MSA(Micro Service Architecture)
•
작은 단위의 서비스로 소프트웨어를 구성함으로써 민첩하고 유연한 설계를 할 수 있도록 한다.
•
어플리케이션이 여러 개의 조각으로 구성되어 각 서비스가 프로세스 위에 별도로 올라간다. 즉, 여러 개의 서비스 프로세스가 모여 하나의 비즈니스 어플리케이션을 구성한다.
•
확장 시에는 특정 기능별로 독립적으로 확장할 수 있고 특정 서비스의 변경이 필요하면 그 서비스만 빌드, 배포하면 된다. 또 각 서비스가 독립적이기 때문에 서로 다른 언어의 개발도 가능하다.
SOA vs MSA
SOA
•
SOA는 전사적인 아키텍처 접근 방식이다.
•
SOA는 구성 요소끼리 통신할 때 ESB를 사용한다.
•
SOA는 서비스를 개발하고, 이를 최대한 재가용하는 것을 목표로 한다.
MSA
•
MSA는 애플리케이션 개발 팀 내의 구현 전략이다.
•
MSA는 구상 요소끼리 언어 제약이 없는 API를 통해 stateless 방식으로 통신한다.
•
MSA는 서비스가 공유되기보다는 독립적으로 실행되는 것을 지향한다.
Service Mesh
•
서비스 메쉬 아키텍처는 MSA의 트래픽 문제를 보완하는 마이크로서비스 간 커뮤니케이션 인프라입니다.
•
서비스 메쉬를 사용하면 마이크로서비스 간에는 직접 통신을 하지 않게 됩니다.
•
대신 모든 통신은 애플리케이션 네트워크 기능을 제공하는 서비스 메쉬를 통해 이루어집니다.
Service Mesh의 적용방안
1) REST API 호출 방식으로 서비스를 결합시키는 스프링 클라우드(Spring Cloud) 기반 넷플릭스 OSS
2) 쿠버네티스(Kubernetes) 기반 클라우드 네이티브(Cloud Native) 서비스
3) 사이드카 프록시(Sidecar Proxy) 패턴의 쿠버네티스 기반 이스티오(Istio) 솔루션
이스티오(Istio)
•
사이드카 패턴의 프록시를 배치하여 통신하는 서비스 메쉬 기술의 대표적인 구현체이다.
•
Spring Cloud Netflix와 많은 유사점이 있습니다. 하지만 Java에 국한된 Spring Cloud Netflix와 달리 플랫폼 영역에서 동작하기 때문에 개발 언어와 무관하게 사용할 수 있습니다.
Istio의 부하분산과 트래픽 관리
•
이스티오는 파일럿과 사이드카 프록시인 Envoy를 통해 트래픽을 제어하고 관리합니다.
•
파일럿을 통해 서비스를 디스커버리하고 로드밸런싱합니다. 서비스 상태를 주기적으로 체크하여 비정상적인 인스턴스는 자동으로 제거합니다.
•
믹서는 파일럿을 이용하여 서비스 버전별 트래픽 양을 분산하거나 요청 콘텐츠에 따라 특정 버전별로 트래픽을 분할하여 전송할 수 있습니다.
Istio의 보안관리
•
이스티오는 모든 서비스의 트래픽이 Envoy를 통해 이뤄지며 TLS(Transport Layer Security)를 이용하여 서비스 간 통신이 암호화됩니다. TLS 통신을 위한 인증서와 키는 시타델에서 관리합니다.
•
서비스 간 인증, 서비스와 엔드 유저(클라이언트) 간 인증이 가능하고 역할 기반 접근 제어(RBAC, Role Based Authentication Control) 기능으로 서비스 접근 권한을 통제합니다.
사이드카 패턴 (Sidecar Pattern)
•
모든 응용 프로그램 컨테이너에 사이드카 컨테이너를 추가하여 배포하는 패턴이다.
•
사이드카는 서비스에 들어오거나 나가는 모든 네트워크 트래픽을 처리한다.
•
비즈니스 로직이 포함된 실제 서비스와 사이드카가 병렬로 배치되기 때문에 서비스가 타 서비스를 직접 호출하는 것이 아니라 프록시(proxy)를 통해서 호출한다
Netflix OSS(Open Source Software)
Netflix는 오픈소스 애플리케이션 개발 프레임워크인 스프링 프레임워크(Spring Framework)에 넷플릭스 OSS를 통합한 Spring Cloud Netflix를 제공하여 손쉽게 마이크로서비스를 구현할 수 있도록 하였다. 하지만 넷플릭스 OSS는 Java로 개발된 관계로 이를 사용하기 위해서는 라이브러리를 포함하고 코드에 관련된 컴포넌트를 추가해야 하는 등의 제약이 있습니다.
Eureka (서비스 디스커버리 패턴)
•
각마이크로서비스의 주소들을 관리하는 서비스 registry이다.
•
Eureka는 서비스들의 목록들을 자동으로 관리해 준다.
•
서비스들은 서비스가 기동할때 Eureka 서버에에 자기 정보(IP 정보 등)을 노티하게 되며, Eureka는 등록된 서버들에게 일정 시간동안 heartbeat를 보내며, 서비스가 정상적인지 죽었는지 확인한다. 각 서비스들은 Eureka에서 정상 작동 서비스 목록들을 가져와서 사용하게 된다.
Ribbon
•
Ribbon은 클라이언트 사이드 로드 밸런서이다.
•
Ribbon은 물론 정적 서버 리스트를 가지고 부하 분산을 할 수도 있으며, Eureka와 연동하여,동적으로 리스트를 관리하면서 부한 분산이 가능하다. 부하 분산 방식도 라운드 로빈, 3회 연속 호출 실패 시 30초 동안 목록에서 제외하는 Availability filtering 등 여러가지 설계가 가능하다.
API GateWay & Zuul
API GateWay
•
MSA는 여러 서비스의 엔드포인트를 관리해야 하는 어려움이 있으며 각 서비스의 API에서 공통적으로 필요한 기능을 중복으로 개발해야 하는 문제가 있다.
•
API Gateway를 이용하면 통합적으로 엔드포인트와 REST API를 관리 할 수 있으며, 모든 클라이언트는 각 서비스의 엔드포인트 대신 API Gateway로 요청을 전달한다.
•
API Gateway는 즉 라우터 및 reverse proxy 기능뿐 아니라, 엔드포인트 서버에서 공통으로 필요한 인증, 접근 제어등 공통적인 부분도 구현이 가능하다.
Zuul
•
Netflix OSS에서 제공하는 API Gateway의 구현체이다.
•
Zuul은 인증요구 식별, 라우팅, 스트레스 테스팅 등 여러 기능을 제공한다.
Hystrix (서킷 브레이커 패턴)
•
Hystrix는 대기 시간 허용 오차 및 내결함성 논리를 추가하여 이러한 분산 서비스 간의 상호 작용을 제어하는 데 도움이되는 라이브러리이다.
•
Hystrix는 서비스 간 액세스 지점을 격리하고 여러 서비스에서 계단식 오류를 방지하며 대체 옵션을 제공하여 시스템의 전반적인 복원력을 향상시킬수 있다.
•
어떠한 특정 서비스에서의 응답이 지연되어 정의된 임계값을 넘게 되면,기다리는 대신 사용자가 정의한 풀백(fallback) 메서드 실행하여 응답값을 클라이언트에게 전달하게 된다. 그리고 새롭게 들어오는 다음 request는 장애가 난 서비스에 컨택하지 않고 정의된 fallback 메서드를 즉시 실행하며, 장애가 복구되면 hystrix는 모니터링 하고 있다가 정상화된 서비스에 다시 연결시켜 준다.
참고자료 :
