당신의 시스템에서 단일장애지점은 어디인가요?
시스템은 항상 예기치않게 장애가 발생한다
배경
이번 글에서는 필자가 기여하고있는 B2B SaaS 제품(이하 KOS)에서 단일 장애지점을 파악해보려한다. 이슈 지점에 대해 낙관적으로 바라보고 솔루션을 강구하지않으면 정말 ‘문제’가 되기때문에 솔직 담백하게 문제라고 생각되는 부분들을 정리해보고 항목 별로 액션 아이템을 도출해보려한다.
근데, 단일 장애 지점이 뭔가요?
단일 장애 지점(Single Point Of Failure, 이하 SPOF)은 시스템에서 하나의 구성 요소가 실패하면 전체 시스템이 중단되는 취약점을 의미한다. 마치 의존도가 높은 다리의 한 기둥이 무너질 경우, 다리가 전체적으로 무너질 위험이 있는것과 같다. 특정 구성 요소가 실패했을 때 대체하거나 복구할 수 없는 구조를 가진 경우 해당 요소가 단일 장애 지점으로 간주된다.
단일 장애 지점 식별하기
KOS 서비스는 Kubernetes 환경에서 서비스들이 오케스트레이션되는 구조이다. 즉, 스케일링과 회복성이 뛰어나다. 어플리케이션이 모종의 이유로 다운되더라도, ReplicaSet 설정에 따라 새로운 파드(pod)가 자동으로 생성된다.
그럼 현재 어플리케이션의 최대 처리량 및 가용 허용치는 어느정도인가?
현재 운영되고있는 서비스들의 정량적 가용 지표를 파악하고 있지않았다. 특정 중요 서비스들은 성능 테스트 도구가 아닌 매뉴얼로 스크립트를 만들어 레이턴시 측정은 진행된적이 있으나 서비스별로 부하 테스트를 통해 최대 처리량에 대한 지표측정이 필요하다.
왜 그동안 지표 측정을 안했나?
대규모 트래픽에 예민한 시스템이였다면 필수적으로 진행했겠으나, B2B 제품 특성상 스파크성 트래픽이 발생하지않아 데일리로 모니터링 도구를 통해 어플리케이션 CPU, Memory 지표등을 파악하여 스케일링을 하고있었다. 그러나 곧 정말 큰 규모의 고객이 두달내 입점할 예정이기에 이젠 코어 서비스들의 최대 처리량 파악을 통해 가시성을 올리는 액션 아이템이 필요할것같다.
[] 코어 서비스를 우선으로 스트레스 테스트 진행하기
[] 테스트를 통해 처리량 지표 파악하기
데이터베이스는 괜찮나?
현재 KOS는 MongoDB를 메인 데이터베이스로 사용하고있다.
MongoDB는 고가용성과 데이터 무결성을 보장하기위해 최소 3개의 노드(Primary-Secondary)를 구성해야한다. 따라서, Primary 노드가 죽더라도 Secondary 노드가 Primary로 승격되면서 페일오버가 진행한다.
그럼 데이터베이스는 SPOF가 아닌건가?
데이터베이스(Shared Database)는 단일 장애지점이 아닐 수 없다. (Shread Database 환경이라면 더더욱) 페일오버를 통해 회복탄력성이 빠르게 보장이 되는것뿐이지 승격되는 과정에서 데이터 유실이 발생할 수 있고, 특정 타이밍에 따라 복구가 불가능한 상황이 발생할수도 있다. 따라서 잠재적인 단일 장애 지점으로 볼 수 있다.
그러나 현재 초기단계의 제품 사이즈에서는 데이터베이스의 물리적 확장 방식인 샤딩이나 노드 수를 확장하는 전략을 취하기보다는 데이터 접근에 대한 쿼리에 대한 Observability에 더 집중하는게 맞다고 생각된다.
정상적인 인덱싱 작업이 되어있지않은 무거운 쿼리가 발생한다던가, 불필요한 쿼리(e.g. n+1)가 발생하고있다던가 등의 Query Observability를 확보하여 이를 어플리케이션에서 개선시키는 과정이 더 중요할것같다.
또한, 현재 Write, Query가 모두 Primary에서 이루어지고있는데, 강한 일관성이 필요하지않는 부분에 대해서 Query는 Secondary를 바라보도록 하는 Read Concern 설정을 통해 Query I/O를 분산하는 작업도 필요한 상황이다.
[] Read Concern을 통해 DB I/O 분산시키기
[] Database Observability 확보
API Gateway는 괜찮나?
KOS의 Gateway는 Spring Webflux로 이루어져있다. API Gateway Pattern을 기반으로 모든 도메인 서비스들의 프록시 역할과 인가 역할도 진행하며 BFF에 대한 책임도 갖고있다.
Gateway는 번역 그대로 ‘통로, 연결지점’의 역할을 지니고있기에 이 서비스가 다운되면 전면 장애는 피할 수 없는 사실이다.
그럼 어떻게 SPOF를 방지할 수 있을까?
Observability 도구를 통해 주기적인 점검과 지표에 맞는 스케일링을 통해 사전 예방을 하고있다. 또한 Kubernetes의 Liveness/ Readness Probe 설정을 통해 장애 감지 및 자동 복구가 진행된다.
그러나 다운스트림 서비스들로 라우팅할 때 특정 서비스가 정상적인 응답을 주지못하고 지연이 걸리거나 타임아웃등이 발생하면 Gateway Service에 또한 작업 스레드가 밀려 장애가 전파될 수 있다.
위 상황을 방지하기위해 Rate Limitting과 Circuit Breaker에 대한 Handling이 필요한 상황이라 생각한다. Circuit Breaker를 통해 다운 스트림 장애 시 원격 서비스 대상의 회복 시간을 제공하고, 요청을 차단하여 폴백을 통해 빠른 피드백을 전달하여 스레드를 오래 잡지않도록 할 수 있다.
또한, 어뷰저가 악의성을 갖고 과도한 요청(e.g. DoS)을 통해 Gateway Service를 과부하 상태로 만들 수 있다. 이는 Rate Limitting을 통해 방지할 수 있어야하겠다.
[] Circuit Breaker 구성
[] Rate Limitting 구성
마치며
기여하고있는 시스템에서의 단일 장애 지점을 식별하는 작업은 매우 중요하다 생각한다.
이번 글에서 나온 액션 아이템들은 (처절한..) 우선순위에 따라 하나씩 해결나갈 예정이고, 그 과정에서 공유할만한 트러블 슈팅이 생긴다면 꼭 남겨보도록 하겠다.
