MSA의 Demo Day

MSA 다룰 때 카오스엔지니어링은 중요하다. 하나의 서비스 장애가 전체 시스템 장애로 퍼지는 일이 흔하기 때문이다.
MSA로 아키텍처를 구성하면, 어느 한 서비스가 장애 시간이 점점 쌓여서 Timeout이 계속 나는 상황이 되면.. 이거에 연관된 모든 서비스가 점점 느려지다가 전체 서비스가 한순간에 확 다운된다. 2차 함수 처럼 그래프가 한번에 확 올라간다.
느려지기 시작하는 지점을 엘보우 포인트라고 부르며, 이걸 빠르게 캐치하는게 중요하다.

그래서 프로덕션 전에 일부로 서비스 장애를 일으키고 이를 해결하기 위한 플레이북을 만들어 나가는 과정이 중요하다.

이때 서비스를 모두 띄워놓고 하나씩 죽여보는 날을 잡는데, 이걸 Demo Day 라고 부른다.

예를 들어 서비스에서 DB 요청 했는데 Timeout이 난다고 하면, Backoff & Jittering 하고 재시도 하는 방법을 쓸 수 있다.

이게 서비스가 작을때는 문제가 안되는데 대규모 서비스에서는 이렇게 하면 시스템 전체가 큰일 날 수 있다. 차라리 P99, P50 같은 정책을 두고 일부 사용자를 빠르게 Unavailable로 두는 것이 좋다. Timeout이 계속 나는 상황에서 서비스가 트래픽을 받으려고 하면 오히려 문제가 생긴다. 이럴 때는 차라리 에러 메세지를 캐쉬(네거티브 캐쉬)에 넣어놓고, 캐쉬가 사라지기 전에는 서비스에 접근 못하도록 하는게 더 좋을 수 있다. 엔보이 프록시를 쓰는 경우 엔보이 프록시에 서킷 브레이크를 넣어서 처리 해도 된다.

중간 팁 : Lambda의 경우 X-Ray같은걸로 레이턴시 계산
P50 : 50%가 1초 미만에 처리된다. 보통 외부에 공개할때는 이렇게 함
P99 : 99%가 1초 미만에 처리된다. 내부 지표

예를 들어 일부 서비스에서 Timeout이 났다고 해보자.

절대 죽으면 안되는 서비스의 경우 Timeout 난 순간 캐쉬를 한다. 바로 Unavailable로 만든다는 의미이며 바로 장애 상태로 전환 시킨다는 의미다. 장애인지도 모르게 두면 안된다. 이렇게 해서 서비스로 Request가 가지 않도록 한다.

어느정도의 장애를 허용해도 되는 서비스의 경우 Timeout이 두번 난다던지 하면 Unavailable 로 만들면 되겠다.

참고로 게임 같은 경우는 사용자가 아이템을 깠는데 5초 정도 안까진다고 해서 게임을 끄지 않는다. 웹 사용자는 5초 걸리면 큰일 난다. 그래서 이러한 관리는 비지니스 상황에 맞게 하는게 중요하겠다.

 

추가로 오늘 순차처리. 코리오그래피. 스텝펑션 등에 대해서도 공부했는데 까먹기 전에 그냥 이 글 말미에 적어놔야겠다.