저번에 t아카데미에서 MSA에 관한 세미나에 참석하고 이번에 클라우드 네이티브 자바라는 책을 접하면서(완독은 못하고 일부 읽었다.)
퍼블릭 클라우드 서비스를 사용하고 컨테이너 기술을 사용하고 있다면 내가 공부한 내용을 실천해야겠다고 생각했다.
OOP의 단일책임원칙처럼 애플리케이션이 가급적 하나의 목적(하나의 도메인이라고 표현해야할지도 모르겠다...)을 가지고 기능하도록 서비스 컴포넌트로 분리하고자 했다.
스토리지를 서비스 컴포넌트마다 하나씩 두고 각 서비스 컴포넌트가 단일 인터페이스로 통신하는 형식으로 바꿔야 겠다는 생각을 했다.
사용자 로그를 현재 하나의 컨텐츠를 조회할 때만 기록하는데 사용자가 검색할 때 무엇을 검색했는지 기록에 남기는 요구사항이 있었다.
Firestore를 저장소로 사용하고 로직을 작성했다.
이 검색 사항을 로그로 남기는 서버는 클라이언트로 부터 Access token을 받아서 인증서버에서 유효한 토큰인지 검증하고 유저의 아이디(관계형 데이터베이스 테이블의 기본키)를 가져와서 저장소에 저장하도록 동작해야했다.
이 부분도 구현했으나 만약 이 서버의 문제가 아니라 의존하는 서버(인증 서버)에서 장애나 에러가 발생하면 어떻게 대응해야 할지 고민이었다. 일반적으로 사용하는 Exception Handling은 기본적으로 구현했지만 의존하는 컴포넌트에 대해서는 달리 방법이 생각안났다.
그러다가 Circuit Breaker가 생각났다.
MSA에서는 컴포넌트 중 하나라도 문제가 생기면 도미노처럼 시스템 전체에 문제가 생길 수 있다.
그래서 Circuit Breaker Pattern을 도입해서 다른 서비스에 대한 요청을 감싼다.
http 요청이 실패한다면 fallback method를 호출해서 장애에 관한 영향을 최소화할 수 있다.
(ex. 만약 사용자 맞춤 추천 서비스의 요청이 실패했다면 대체되는 어떤 리스트를 불러오는 형식)
그리고 요청 실패가 쌓여서 circuit open의 조건에 부합한다면 circuit open이 되어서 요청에 대해서 바로 fallback method를 호출하는 것이다.
Histrix는 넷플릭스에서 사용하는 circuit breaker로 spring과 연동되어서 간편하게 설정할 수 있다.
자세한 사항은 아래 링크를 참고하자
1. Hystrix를 도입하긴 했는데 JVM Error가 생기다.
Hystrix를 도입하는 건 매우 간단했다. 실행하는 것도 성공적이었다.
그런데 docker image로 만들고 실행하니깐 아래와 같은 에러가 발생했다.
구글링도 해봤지만 내 짧은 지식으로는 정확한 원인을 규명하기는 힘들었다.
hystix를 도입하고 생긴 에러이기 때문에 근본적인 원인은 확실했다.
스프링 버전을 낮춰보거나 했지만 너무 막막해서 고생했다.
그러다가 우분투에서는 어떨까 싶어서 우분투 컨테이너상에서 실행해보니 위와같은 에러가 발생하지 않았고 최종적으로
openjdk:8-jdk-alpine을 openjdk:8-jdk-slim-stretch라는 이미지로 바꾸니 실행이 되었다.
데비안이라서 이미지 크기에 대해서 걱정하기도 했는데 알파인이랑 크게 다르지는 않은 것같다.
Alpine 배포판이 가볍다는 장점이 있긴 하지만 안정성이 떨어지는 것같다.
가볍게 해결할 수 있는 문제였는데 전혀 모르는 영역의 문제라는 공포감에 휩싸여서 문제를 길게 끌고 간건 아닌가 싶다.
머리를 식히고 천천히 생각해보니 간단하게 해결할 수 있었다. 다행이다.
'백엔드 개발 > Spring' 카테고리의 다른 글
| [spring] redis로 caching해서 dbms의 부하 줄이기 - 3 (0) | 2018.11.26 |
|---|---|
| [spring] redis로 caching해서 dbms의 부하 줄이기 - 2 (0) | 2018.11.22 |
| [spring] redis로 caching해서 dbms의 부하 줄이기 - 1 (0) | 2018.11.20 |
