17. MSA 와 JWT

MSA (Micro Service Architecture)

 

단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법이다.
MSA 를 온라인 쇼핑몰에 적용한 예시는 아래와 같다.

각 컴포넌트는 서비스 형태로 구현되고 API 를 이용하여 타 서비스와 통신하게 된다. 각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기 때문에 독립된 배포를 하게된다. 또한 각 컴포넌트가 독립된 서비스로 개발되어있기 때문에 부분적인 확장이 가능하다.
온라인 쇼핑몰에서 주문 서비스에 트래픽이 증가한다면 해당 서버만 확장을 해주면 된다.

다만, Monolithic Architecture 가 서비스 간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만
MSA 의 경우 서비스 간 호출을 API 통신을 이용하기 때문에 속도가 느리고, 통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생하기도 한다.

http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/

 

# 일반적인 MSA 와 OpenStack 에서 제공하고 있는 MSA 는 구조적으로 약간 다르다.

 

MSA on Cloud Native

 

Cloud Native 에서 현재 추진하고 있는 MSA 기반 개발 등에 대한 내용이다.

 

• 기존 Micro Service Architecture 는 사용자의 요청을 API Gateway 를 통해 관리하도록 하고 있다.
• API Gateway 는 인증에 관련된 내용 확인과 URL 요청에 따른 Dispatcher 도 이루어진다.

# 실행 흐름 : Client 가 HTTP 프로토콜을 통해 API Gateway 로 인증 Token 을 보내면 Auth Service 에서 검증 한다.

이후, API Gateway 에서 URL 의 패턴에 따라서 각 Service 에 이관을 한다. 이때 각 Service 끼리도 호출이 발생할 수 있는 구조이다.

https://fastcampus.co.kr/courses/204729/clips/

 

MSA on OpenStack

 

OpenStack 에서 모듈 간 처리를 위해서 제공되고 있는 MSA 의 처리 방식이다.

 

• OpenStack 에서의 MSA 는 별도의 API Gateway 가 존재하지 않는다.
• 각 서비스 (혹은 모듈) 에서 직접 요청(Request) 를 받고 Keystone 을 두고 요청에 대한 인증 및 인가 정보를 확인한다.

# 실행 흐름 : Client 가 HTTP 프로토콜로 각 Service (혹은 모듈) 에 요청을 하면 각 Service 는 Token 을 발췌해서 Keystone (Auth Service) 검증을 요청한다. Keystone 이 검증을 해주면 각 Service 에서 요청에 맞는 액션을 실행한다. 만일 이때 Service 에서 네트워크 정보를 읽어 와야하는 상황이 오면 이 Service 에서 다른 Service 로 Token 을 통해 요청을 하게 되고, 그 요청을 받은 Service 는 Token 을 가지고 Keystone 에 인증을 요청한다. Keystone 에서 검증을 하고 다시 처음 요청을 했던 Service 로 정보를 전달해준다.  

https://fastcampus.co.kr/courses/204729/clips/

 

# Keystone 기반의 사용자 인증 방식 : OpenStack 에서는 Token 기반의 인증을 제공하고 있으며, Unscoped Token 과 Scoped Token 을 통해 인증을 수행하고 있다.

• Unscoped Token (인증을 위해 제공되는 토큰) 
• Scoped Token (액션을 위해 제공되는 토큰)

 

Unscoped Token

 

FE 에서 인증 요청을 하면 BE 에서 Unscoped Token 발급을 Keystone 에게 요청한다. 이때 Keystone 은 Unscoped Token 을 발급해주면 BE 에서는 이 Token 을 세션에 저장한다. 그리고 이 세션을 기반으로한 Response 를 FE 에게 전달한다.

 

이때 중요한 것은 Token 을 직접 Response 에 담아 전달하는 것이 아니라, 세션에 저장한 후 그 세션을 Response 한다는 것이다. (보안상) 

 

https://fastcampus.co.kr/courses/204729/clips/

 

Scoped Token (Keystone 기반의 사용자와 모듈, 모듈과 모듈 API 연동)

 

이미 인증된 사용자가 BE 로 VM 생성을 요청하고, BE 에서는 세션 정보 조회를 통해 Unscoped Token 을 조회한다.

이 Unscoped Token 을 활용해서 Keystone 에게 Scoped Token 을 요청한다. 그러면 Keystone 에서는 Unscoped Token 을 검증한 후 Scoped Token 을 발급해준다.

 

그럼 BE 에서는 Scoped Token 을 통해 Nova 에게 VM 생성을 요청하고, Scoped Token 을 받는 Nova 는 다시 Keystone 에게 검증을 요청한다. 검증이 완료되면 Nova 가 VM 을 생성하여 전달해준다. 

https://fastcampus.co.kr/courses/204729/clips/

 

OpenStack 에서의 인증 Token 처리 및 내용

 

1. Fernet Tokens

• 암호 인증 방법으로 양방향 키 암호화이며, 기본 토큰 제공자이다.
• PK 와 복구를 위한 키 중에 키 목록이 존재하여 이를 기반으로 암복호화가 이루어진다.

 

• Fernet Token 의 크기는 250 byte 이하로 제한하여 제공하고 있다.
• Fernet 암호화를 위해 사용되는 KeyFile
  • 256 bit 로 구성된 Key 가 존재한다. (SHA256 HMAC Signing Key:128 bit + AES Encrypt Key:128 bit)

https://fastcampus.co.kr/courses/204729/clips/

 

• Key File 의 관리 방식 (Type of Key)
  1. Primary Key
     • Encrypt, Decrypt
     • Key file named with the Highest Index (차수)
  2. Secondary Key
     • Only Decrypt
     • Lowest Index < Secondary Key File Name < Highest Index
  3. Staged Key
     • Decrypt and Next In Line to become Primary (다음 번에 진행되는 Primary Key)

 

https://fastcampus.co.kr/courses/204729/clips/

 

JWT (JSON Web Token)

 

JWT 는 JSON 형태의 데이터를 Token 으로 제공하고 관리하는 하나의 방법이다.

OpenStack 에서는 이 또한 제공자 (Provider) 로 제공하고 있으나 기본 설정은 아니다.

 

# JW-S.T.E.A.K : JSON Web-Signature, Token, Encryption, Algorithms, Key 등의 구성으로 보안적인 강화 및 설정을 할 수 있다.

 

---

출처 : http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/

마이크로서비스 아키텍처(MSA) 개념 소개 - CLIPSOFT