마이크로서비스 : 기반 서비스의 종류 : 두번쨰 이야기

인증, 인가

API 게이트웨이에서 인증 인가를 처리할 수 있습니다. 그런데 그것은 자체 기능으로 처리하지 않고 OAuth 서비스를 사용합니다. OAuth는 각각의 리소스 서비스가 자체적으로 인증 인가를 처리하는 것이 비효율적이고 독립성을 떨어뜨리기 때문에 등장한 서비스입니다.

동작 메커니즘을 살펴보면 우선 사용자가 API 게이트웨이를 통해 OAuth에게 각 서비스 리소스에 액세스할 권한이 있는지 요청합니다. 그럼 OAuth 서비스는 인증된 사용자인지 이 리소스에 권한이 있는지 확인하고 그것이 확인됐다면 리소스에 접근 가능한 증명서인 액세스 토큰을 발급해 줍니다.

그러면 API 게이트웨이는 다시 요청을 준비하고 각각의 리소스 서비스는 이런 리퀘스트가 액세스 토큰이 있는지 판단하여 리소스를 허용하는 것입니다.

 

 

장애 격리

다음은 장애 격리를 위한 서킷브레이크에 대해 살펴보도록 하겠습니다. 서비스 수가 많아지면 이들 간 관계를 관리해야 합니다. 즉 상황에 따라 서비스를 동적으로 증가시켜 과부하나 오류 상황에서도 지속 가능한 서비스가 가능하도록 관리해야 합니다.

특정 서비스에 문제가 생겼을 때 자연스럽게 다른 정상적인 서비스로 요청 흐름의 변경도 가능합니다. 그렇게 하기 위해서 서비스 상태는 항상 실시간으로 관리되어 시각화하고 모니터링 할 수 있어야 합니다. 여기서 서비스에 문제가 생겼을 때 이러한 장애가 다른 서비스로 전이되지 않도록 하는 방법이 반드시 필요합니다.

 

 

전기회로 차단기와 비슷하다 하여 서킷브레이크 패턴이라고 합니다. A라는 서비스가 B라는 서비스를 호출하여 자신의 서비스를 제공하는데 B 서비스 장애가 발생되면 이런 동기 requesting 성격상 A는 계속 기다리게 됩니다.

이러한 상황은 A라는 서비스까지 장애인 것처럼 사용자가 느끼게 됩니다. 이런 경우에 B 서비스 호출에 대한 연속 실패 횟수가 임계값을 초과하면 회로 차단기가 작동하여 시간 초과 기간 동안 서비스를 호출하려는 모든 시도를 즉시 실패하게 만드는 것입니다.

폴백 처리를 지정해 놓으면 폴백 메소드가 대체 처리를 진행하게 됩니다. 그럼 사용자는 특정 서비스가 장애인지 모르게 되고 나중에 장애가 복구되었을 때 다시 호출을 정상화시키면 됩니다. 이런 서킷브레이크 패턴을 스프링 클라우드에서 제공하는 기반 서비스가 히스트릭스라는 서비스입니다.

 

 

모니터링 서비스

다음과 같이 모든 마이크로서비스들을 실시간으로 모니터링 하게 됩니다. 그리고 이렇게 모니터링 상황을 시각적으로 보여주는데 대시보드도 제공해 줍니다.

그러다가 성능에 문제가 발생하면 여기 적색으로 서킷이 오픈하게 됩니다. 그럼 서킷브레이크가 발동된 것입니다. 이렇게 모든 마이크로서비스를 모니터링 하다가 적절한 조치를 취할 수 있게 해주는 것입니다.

 

 

Log aggregation, Exception tracking

 로그 처리를 위한 ELK 스택입니다. ELK는 ElasticSearch, Logstash, Kibana, 세 개의 오픈 소스를 가지고 데이터 분석 환경을 구성한 것입니다. 우선 ElasticSearch는 분석 엔진입니다. Logstash는 서버 쪽 로그 집합기입니다. 그리고 Kibana는 시각적으로 보여주는 대시보드입니다.

여러 개의 마이크로서비스로 구성된 시스템의 경우 각각의 마이크로서비스가 자신의 로그를 관리하게 되면 운영자 입장에서는 각각의 서비스를 살펴봐야 하므로 매우 효율적이지 않습니다. 따라서 로그 수집을 중앙화하여 실시간으로 살펴볼 도구가 필요합니다.

이 ELK를 사용하면 각 서비스의 인스턴스 로그를 집계해서 중앙에서 집중 관리할 수 있으며 쉽게 특정 로그를 검색, 분석할 수 있습니다. 또한 특정 메시지가 로그에 나타나거나 특정 예외가 날 때 운영자나 개발자에게 보고할 수도 있습니다.

각각의 서비스에 Logstash가 설치되어 각 로그를 수집해서 레지스트리 저장소에 보내고 있습니다. 그 다음 하나의 서비스에서는 ElasticSearch와 Kibana로 로그 중앙 관리 저장소와 대시보드 서비스를 구축하게 됩니다.

그럼 레디스 서비스에 설치된 Logstash가 이 중앙 관리 저장소에 로그를 보내게 되고 이 로그 저장소에 ElasticSearch 엔진이 로그를 인덱싱하고 그 로그 정보가 Kibana로 시각화되어 보여주게 됩니다.

 

 

Distributed Tracing

모니터링과 함께 각각의 서비스 트랜잭션의 호출을 추적하면 운영에 매우 유용합니다. 분산된 서비스 간의 호출이나 지연 구간별 장애 포인트를 확인할 수 있습니다.

서비스 API를 선택해 보면 이렇게 각 API가 다른 API를 어떻게 호출하는지 호출 시의 반응 시간이나 지연 구간 등을 확인할 수 있습니다. 그리고 이렇게 정적인 다이어그램도 제공하여 전체적인 API 호출 빈도도 확인할 수 있습니다.

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