[MicroService] MSA의 이해(BFF패턴, 인증/인가 패턴, 외부구성 저장소 패턴, 집계 패턴, 모니터링/추적패턴) 3장

◆ MSA 구성 요소 및 MSA 패턴

▶ Micro Service 운영과 관리를 위한 플랫폼 패턴

      ● BFF 패턴

          ⊙ 최근에는 PC뿐만 아니라 다양한 모바일 장비를 사용하기 때문에 다양한 클라이언트를 고려해야 함

          ⊙ 이처럼 다양한 클라이언트를 위해서는 특화된 처리를 위한 API 조합이나 처리가 필요한데 이를 위한 해결 방법으로 BFF(Backend for Frontend) 패턴이 있음

          ⊙ BFF 패턴은 API 게이트웨이와 같은 진입점을 하나로 두지 않고 Front End의 유형에 따라 각각 두는 패턴

          ⊙ Front End를 위한 Back End라는 의미로 BFF(Backend For Frontend)라고 부름

          ⊙ 웹을 위한 API 게이트웨이, 모바일을 위한 API 게이트웨이 등 클라이언트 종류에 따라 최적화된 처리를 수행할 수 있게 구성할 수 있는데 모바일을 위한 API만 선택해서 제공하거나 웹을 위한 API만 적절하게 제공할 수 있으며 또한 각 Front End에 대한 처리만 수행하는 BFF를 두고 이후에 통합적인 API 게이트웨이를 둠으로써 공통적인 인증/인가, 로깅 등의 처리를 통제하는 구조로 구성할 수도 있음

 

      ● 외부 구성 저장소 패턴

          ⊙ 클라우드 인프라와 같이 유연한 인프라를 사용하는 상황에서 데이터베이스 연결 정보, 파일 스토리지 정보 같은 내용을 애플리케이션에 포함하면 변경 시 반드시 재배포해야 하는데 이 경우 서비스를 중단해야 하고 여러 Micro Service가 동일한 구성 정보를 사용하는 경우에도 일일이 변경하기가 어렵고 변경 시점에 일부 Micro Service의 구성 정보가 불일치할 수도 있기 때문에 Micro Service가 사용하는 자원의 설정 정보를 쉽고 일관되게 변경 가능하도록 관리할 필요가 있음

          ⊙ 이를 위한 방법이 외부 저장소 패턴

          ⊙ 외부 저장소는 각 Micro Service의 외부 환경 설정 정보를 공동으로 저장하는 백업 저장소

          ⊙ PaaS 솔루션 개발사인 Heroku에서 발표한 Twelve-Factor라는 클라우드 네이티브 애플리케이션을 만들기 위한 체크리스트가 있는데. 여기서 컨피그(Config)라는 원칙을 언급했는데 이것은 애플리케이션이 배포되는 환경(스테이징, 프로덕션, 개발, 테스트 환경)이 매번 달라지기 때문에 코드에서 사용하는 환경 설정 정보는 코드와 완전히 분리되어 관리해야 한다는 원칙을 가리킴

          ⊙ 클라우드에서 운영되는 애플리케이션은 특정한 배포 환경에 종속된 정보를 코드에 두면 안 된다는 원칙으로 왜냐하면 이러한 정보를 애플리케이션에 두면 배포 환경이 변경됐을 때 애플리케이션 또한 변경해야 하기 때문

          ⊙ 분리해야 할 환경 정보로는 데이터베이스 연결 정보, 배포 시 변경해야 할 호스트명, Back End 서비스의 연결을 위한 리소스 정보 등이 있으며 또한 서비스가 기동되는 개발 서버, 테스트, 운영 서버의 IP 주소와 포트 정보 등을 분리해서 환경 변수로 사용

          ⊙ 스프링 클라우드 컨피그(Spring Cloud Config)를 이용하면 이러한 환경 정보를 코드에서 분리하고 컨피그 서비스를 통해 런타임 시 주입되게 할 수 있음

          ⊙ 환경 정보는 Git 같은 별도의 형상관리 리포지토리에 보관하고 컨피그 서비스는 해당 서비스에 특정 환경에 배포될 때 적절한 환경 정보를 형상관리 리포지토리에서 가져와 해당 서비스에 주입

          ⊙ 쿠버네티스에서는 이러한 외부 구성 저장소 패턴을 쿠버네티스 컨피그맵(ConfigMap)으로 제공

 

      ● 인증/인가 패턴

          ⊙ 각 서비스가 모두 인증/인가를 중복으로 구현한다면 비효율적

          ⊙ Micro Service 인증/인가를 처리하기 위해서는 일반적으로 다음과 같은 패턴을 활용

          ⊙ 중앙 집중식 세션 관리

               → 기존 모노리스 방식에서 가장 많이 사용했던 방식은 서버 세션에 사용자의 로그인 정보 및 권한 정보를 저장하고 이를 통해 애플리케이션의 인증/인가를 판단하는 것으로 Micro Service는 사용량에 따라 수시로 수평 확장할 수 있고 로드 밸런싱 처리가 되기 때문에 세션 데이터가 손실될 수 있기 때문에 Micro Service는 각자의 서비스에 세션을 저장하지 않고 공유 저장소에 세션을 저장하고 모든 서비스가 동일한 사용자 데이터를 얻게 하는데 이때 세션 저장소로 보통 레디스(Redis)나 멤캐시드(Memcached)를 사용

          ⊙ 클라이언트 토큰

               → 세션은 중앙 서버에 저장되고 토큰은 사용자의 브라우저에 저장되는 방식으로 토큰은 사용자의 신원 정보를 가지고 있고 서버로 요청을 보낼 때 전송되기 때문에 서버에서 인가 처리를 할 수 있는데 JWT(JSON Web Token)는 토큰 형식을 정의하고 암호화하며 다양한 언어에 라이브러리를 제공하는 공개 표준(RFC 7519)

          ⊙ API 게이트웨이를 사용한 클라이언트 토큰

               → 사용자 인증 프로세스는 토큰 인증 프로세스와 유사

               → 차이점은 API 게이트웨이가 외부 요청의 입구로 추가된다는 것 과 인증/인가를 처리하기 위한 별도의 전담 서비스를 만들어서 다른 서비스의 인증/인가 처리를 위임할 수 있음

               → 이러한 서비스를 인증 서비스(auth service)라 하는데 API 게이트웨이와 연동해서 인증/인가를 처리

               → 인증 서비스를 이용하면 각 리소스 서비스가 자체적으로 인증/인가를 처리하지 않고 업무 처리에 집중할 수 있음

 

          ⊙ API 게이트웨이를 사용한 클라이언트 토큰

               → 클라이언트가 리소스 서비스에 접근을 요청하면 API 게이트웨이는 인증 서비스에게 전달

               → 인증 서비스는 해당 요청이 인증된 사용자가 보낸 것인지(인증), 해당 리소스에 대한 접근 권한이 있는지(인가) 확인하고 모두 확인하고 나면 리소스에 접근 가능한 증명서인 액세스 토큰을 발급

               → 클라이언트는 다시 액세스 토큰을 활용해 접근을 요청

               → 각 리소스 서비스는 이러한 요청이 액세스 토큰을 포함하고 있는지 판단해서 리소스에 대한 접근을 허용

 

      ● 장애 및 실패 처리를 위한 서킷 브레이커 패턴

          ⊙ 여러 서비스로 구성된 시스템에서는 한 서비스에 장애가 발생했을 때 다른 서비스가 영향을 받을 수 있는데 이때 장애가 발생한 서비스를 격리해서 유연하게 처리할 수 있는 방법이 필요한데 이를 위한 한 가지 방법이 서킷 브레이커 패턴

          ⊙ 서비스의 수가 많아지면 장점도 있지만 단점도 있는데 예를 들면 사용자가 접하는 전체 시스템은 정상적인데 특정 기능을 선택하면 즉각 에러가 발생하지도 않고 한참 동안 대기하는 상황이 발생할 수 있음

          ⊙ 사용자는 이 같은 상황이 장애인지 아닌지 파악도 안 되고 단순히 시스템이 느 려졌다고 판단할 수도 있는데 이러한 상황은 정상적인 서비스가 장애가 발생한 서비스에 의존해서 서비스를 제공할 때 발생하는 상황으로서 장애가 다른 서비스로 전이된 상태

          ⊙ 시스템 과부하나 특정 서비스에 문제가 생겼을 때 자연스럽게 다른 정상적인 서비스로 요청 흐름이 변경되게 해야 하는데 그러자면 서비스 상태를 항상 실시간으로 관리해서 시각화하고 모니터링할 수 있어야 하고 특정 서비스에서 장애가 감지되면 장애가 다른 서비스로 전이되지 않게 하는 방법이 반드시 필요

          ⊙ 이를 전기회로 차단기와 비슷하다고 해서 서킷 브레이커 패턴이라고 함

          ⊙ A라는 서비스가 B라는 서비스를 호출해서 자신의 서비스를 제공하는데 B 서비스에서 장애가 발생하면 이러한 동기 요청(request)의 성격상 A는 계속 기다리 게 되는데 이 경우 A라는 서비스까지도 장애가 발생한 것처럼 사용자가 느끼게 됨

          ⊙ 서킷 브레이커 패턴은 이 같은 경우에 B 서비스 호출에 대한 연속 실패 횟수가 임곗값을 초과하면 회로 차단기가 작동해서 이후에 서비스를 호출하려는 모든 시도를 즉시 실패하게 만듬

          ⊙ 폴백(fallback) 메서드를 지정해 두면 장애가 발생했을 때 폴백 메서드가 자연스럽게 처리를 진행

          ⊙ 사용자는 특정 서비스에 장애가 발생했는지 눈치채지 못하고 시간이 흘러 장애가 복구됐을 때 다시 호출을 정상화하면 됨

 

      ● 모니터링 과 추적 패턴

          ⊙ 서킷 브레이커 패턴을 가능하게 하려면 각 Micro Service의 장애를 실시간으로 감지해야 하고 서비스 간의 호출이 어떤지 알아야 하는데 모니터링하고 추적하는 패턴이 필요

          ⊙ 스프링 클라우드에서는 히스트릭스라는 라이브러리를 제공하고 히스트릭스 라이브러리가 배포된 서비스를 모니터링할 수 있는 히스트릭스 대시보드(Hystrix Dashboard)를 제공함으로써 Micro Service의 요청을 실시간으로 모니터링 할수 있음

          ⊙ 각 요청이 차지하는 트래픽이 원형으로 표현되는데 원이 클수록 트래픽이 많다는 의미

          ⊙ 서비스 성능에 문제가 발생하면 서킷이 오픈되어 서킷 브레이커가 발동하고 적색으로 표현되는데 이를 통해 Micro Service를 모니터링 하다가 문제가 발생했을 때 적절한 조치를 취할 수 있게 됨

          ⊙ 모니터링과 함께 각 서비스 트랜잭션의 호출을 추적하면 Micro Service 운영에 매우 유용 – 분산 트레이싱 서비스

          ⊙ 트위터에서 공개한 집킨(Zipkin)이라는 오픈소스 프로젝트의 대시보드로서 분산된 서비스 간의 호출이나 지연 구간별 장애 포인트를 확인할 수 있음

          ⊙ 서비스 API를 선택하면 그림의 왼쪽과 같이 각 API가 다른 API를 어떻게 호출하는지 호 출 시의 반응 시간이나 지연 구간 등을 확인할 수 있다. 또한 정적인 다이어그램을 통해 전체적 인 API 간의 호출 빈도도 확인할 수 있음

          ⊙ 운영자가 이 다이어그램을 실시간으로 보다가 만약 호출 빈도가 너무 많은 API나 반응 시간이 높은 API가 있다면 이를 개선할 수 있을 것

      ● 중앙화 된 로그 집계 패턴

          ⊙ Micro Service가 사용량에 따라 탄력적으로 변화하면서 언제든지 인스턴스가 생성/삭제되는 과정에서 로컬 로그가 초기화될 수 있음

          ⊙ Twelve-Factor의 로그(Logs) 원칙을 보면 로그를 이벤트 스트림(event streams)으로 처리하라고 함

          ⊙ 로그는 시작과 끝이 고정된 것이 아니라 서비스가 실행되는 동안 계속 흐르는 흐름이라는 의미이고 서비스는 스트림의 전달이나 저장에 절대 관여하지 않아야 한다고 하는데 왜냐하면 로그를 전달 및 저장하는 메커니즘 자체가 특정 기술이나 인프라에 의존할 수밖에 없고 이러한 메커니즘을 직접 Micro Service에서 구현한다면 유연성이 떨어지기 때문인데 그래서 필요한 것이 중앙화된 로그 집계 패턴

          ⊙ 서비스에서 발생한 이벤트 스트림 형태의 로그를 수집하고 살펴볼 도구가 필요한데 대표적으로 많이 쓰이는 기술이 ELK 스택

          ⊙ ELK 스택은 엘라스틱서치(Elasticsearch), 로그스태시(Logstash), 키바나(Kibana)라는 세 가지 오픈소스 프로젝트를 기반으로 데이터 분석 환경을 구성한 것

          ⊙ 엘라스틱서치는 분석 엔진이고 로그스태시는 서버 측 로그 집합기이며 키바나는 시각적으로 로그 내역을 보여주는 대시 보드

          ⊙ ELK 스택을 이용하면 각 서비스의 인스턴스 로그를 집계해서 중앙에서 집중 관리할 수 있으며 손쉽게 특정 로그를 검색 및 분석할 수 있으며 또한 특정 메시지가 로그에 나타나거나 특정 예외가 발생할 때 운영자나 개발자에게 직접 통보하게 할 수도 있음

          ⊙ Micro Service의 로그 수집을 위한 ELK 스택 기반 아키텍처

               → 각 서비스에 로그 스태시가 설치되어 각 로그를 수집해서 레디스 저장소에 보내고 다른 서비스에서는 엘라스틱서치와 키바나로 로그 중앙 관리 저장소와 대시보드 서비스를 각각 구축

          ⊙ Micro Service의 로그 수집을 위한 ELK 스택 기반 아키텍처

               →  Micro Service에서 보낸 로그가 중앙 레디스에 쌓이면 레디스에서 중앙 관리 저장소에 로그를 보내고 이 로그 저장소에 엘라스틱서치 엔진이 로그를 인덱싱하고 해당 로그 정보가 키바나 대시보드를 통해 보여지는데 중간에 레디스 데이터베이스를 둔 까닭은 Micro Service의 로그스태시가 바로 로그 저장소에 로그를 보낼 수 있지만 로그 스트림이 너무 몰리면 로그 저장소 서비 스에도 성능 문제가 생기기 때문에 중간에 임시 저장소를 추가한 것