MSA 프로덕션 레디 서비스 - 보안, 공통환경, 모니터링 (MSA-7)

MSA 보안 서비스

일반적으로 monlithic 환경 에서는 세션기반으로 보안 서비스가 구동되지만, 세션이 분리되어있는 MSA 환경 에서는 세션기안 보안 서비스를 사용하기가 어렵습니다.

일반적으로 MSA 환경 에서는 API Gateway에서 OAuth 2.0을 활용 해 각 서비스들에게 인증 토큰을 전달하는 방식으로 모든 서비스들에 보안을 적용 시키는 방법을 사용합니다.

OAuth 2.0의 구조에 대해 아래 그림을 통해 간략하게 설명드리도록 하겠습니다.

1

  1. 인증 서버 (Authorization server) : 사용자 인증 및 토큰 획득 API 제공
  2. 리소스 서버 (Resource server) : 액세스 토큰으로 접근 허가하는 대상이 되는 서비스
  3. 클라이언트 (Client) : 리소스 서버에 접근하려는 클라이언트

위의 OAuth 2.0은 MSA 환경에서 아래 그림과 같이 사용되어집니다.

2

API Gateway는 여러 서비스들을 묶어줌과 동시에 인증/인가 서비스 또한 담당하게 되는 것 입니다.


MSA 공통환경 프로퍼티 서비스

여러 서비스에서 공통적으로 사용하는 환경설정들이 있을것입니다.

  • DB 네트워크 주소
  • 메세지 서비스 네트워크 주소
  • 자격 증명 (ID/PW)

위의 내용들이 바뀔때마다 여러 서비스들을 모두 하드코딩으로 바꿔주는것은 여간 비효율적인 일이 아닐 것 입니다. 이를 해결하기 위해 여러 서비스들이 공통적으로 사용 할 수 있는 공통 환경 프로퍼티를 구성해두고 사용하는것이 좋습니다.

이를 구성하는 방법은 첫째로, 배포 환경에서 공통된 환경변수를 통해 서비스에 전달하는 푸시 모델 방법이 있으며 둘째로는, 서비스 인스턴스 구동시 필요한 구성값들을 특정 서비스에 접속하여 가지고오는 풀 모델이 있습니다. Spring 진영에서는 일반적으로 Spring cloud config를 활용해 프로퍼티를 공통으로 사용합니다.


MSA 모니터링 서비스

MSA환경에서 여러 서비스의 모니터링을 할 때 필요한 수집 목록들은 다음과 같습니다.

  • 헬스 체크
  • 로그 수집
  • 분산 추적
  • 예외 추적
  • 애플리케이션 지표
  • 감사 로깅

헬스 체크

각 서비스들은 모니터링 서버가 해당 서비스가 현재 살아있는지 확인 할 수 있도록 헬스체크 API를 제공해야 합니다. 해당 헬스체크 api는 모니터링 서버가 정기적으로 호출하며 서비스 정상 동작 여부 상태를 모니터링 하게 됩니다.

Spring boot actuator를 사용한다면 '/actuator/health' api 를 통해 기본적으로 healthCheck api가 제공됩니다.

로그 수집

여러 서비스들에서 발생하는 로그들을 중앙에 수집하여 확인 할 수 있어야 합니다.
일반적으로 로그 파이프라인을 구성하여 집계하게 되는데, ELK 스택 (ElasticSearch, Logstash, Kibana)가 주로 이용됩니다.

분산 추적

분산된 서비스 환경에서 서비스의 흐름을 추적하는것은 쉽지 않은 일 입니다.
이를 확인 할 수 있도록 하기 위해 외부 요청이 들어 올때마다 UUID를 부여하여 각 서비스 흐름을 중앙 서비스에 기록하여 시각화/분석 기능을 제공합니다.

애플리케이션 지표

운영환경에서 자원의 활용률 (CPU, Memory, disk usage …) 혹은 서비스 요청 실행 수, 오류 응답수 등의 지표들을 수집해두고 모니터링하는 일은 중요한 일입니다.
위와 같은 측정 지표들을 정기적으로 수집하여 중앙 서비스에 기록해두고 모니터링시 사용합니다.

예외 추적

예외들을 수집하고 사용자에게 알림을 보낼 수 있어야 합니다.

감사 로깅

사용자들의 액션을 기록하고 추적하는데 사용 할 수 있도록 해야합니다.
이전 포스팅에서 언급하였던 이벤트 소싱 패턴을 통해 구현 할 수 있습니다.


마이크로 섀시, 서비스 메시

MSA 를 구성한다고 하면 위와 같이 많은 프로덕션 레디 서비스들이 필수로 함께 구성이 되어야 합니다. 이것들을 물론 개발자들이 직접 구성 할 수도 있겠지만, Spring의 경우 Spring cloud를 활용해 서비스와는 분리된 프로덕션 레디 서비스들을 처리해주는 마이크로 섀시 프레임워크를 구성 할 있습니다.

3

마이크로서비스 섀시는 위 그림과같이 실제 서비스 동작코드 와는 분리되어 서비스 디스커버리, 분산 추적, 로깅등의 기능을 제공해준다는 큰 장점이 있습니다.

다만, MSA 환경은 사용 언어에 구애받지 않는 폴리글랏한 서비스가 구성 될 수 있는데, 이러한 경우 마이크로 섀시가 정상적으로 호환이 되지 않을 수 있습니다. 따라서 사용되는 언어에 따라서 여러개의 마이크로서비스 섀시 사용이 필요 할 수 있습니다.

위와 같을때 서비스 메시를 이용 할 수 있습니다. 기능들을 모두 서비스 섀시에 넣는것이 아닌, 공통으로 사용되는 기능들은 외부의 서비스 메시에 구현하여 사용하는 패턴을 말합니다.

4

서비스 메시를 통해서 마이크로서비스 섀시는 각 서비스에서 필요한 헬스체크, 로깅과 같은 처리만 진행 해 주면 되기 때문에 훨씬 단순해 질 수 있습니다.