개요
MSA 환경에서 개발하면서 전체 아키텍처를 봤을때는 분명 MSA 였지만 백엔드 상에서는 MSA의 특징을 느끼지 못했었다.
그 이유는 진짜 서버를 목적에 따라 분리하기만 했을 뿐 MSA의 가장 큰 특징은 놓치고 있었기 때문인 것 같다.
누군가가 MSA를 사용한 이유가 뭔가요? MSA의 특징이 뭔가요? 라고 물었을 때
- 서비스간의 결합도를 낮추기 위해서
- 한 서비스의 장애가 전체로 확산되지 않기 위해서
- 서비스별로 다른 언어나 프레임워크를 선택하기 위해서 (폴리글랏 프로그래밍)
등등..
면접 답변 처럼 튀어나왔지만 다 완성하고 보니 이런것에 대한 고려를 하지 않았던 것 같다. (특히 2번)
AWS Lambda Authorizer 적용기
식당 리뷰 프로젝트에서 AWS Lambda Authorizer 를 이용하여 중앙 집중화된 인증 시스템을 구축했었다.
목적은 MSA 환경에서 중복개발을 줄이고 일관성을 유지하기 위해서 였다.
하지만 "이 지점이 단일 장애 지점(SPOF)이 될 수 있고 그건 내가 말한 MSA를 사용한 이유에 어긋나지 않냐?" 라는 질문을 받았다.
이에 대해 고민해본 과정과 해결책을 기록하기 위해 글을 작성하였다.
(질문에 대한 답은 맨 마지막에 내 생각을 정리했다)
SPOF 방지
SPOF(단일 장애 지점, Single Point Of Failure)는 시스템 내에서 장애가 발생했을 때 전체 시스템의 가용성에 영향을 줄 수 있는 단일 장애 지점이다.
SPOF가 문제가 생기면 전체 시스템이나 서비스가 중단될 수 있다.
따라서 고가용성이 중요한 서비스에서 주의있게 관리되어야 하고 이것들을 최소화하기 위한 여러가지 방법이 존재한다.
크게 인프라 단계와 어플리케이션 단계에서 취할 수 있는 방법으로 나뉘어서 정리해보면 다음과 같다.
인프라 단계
1. 고가용성 설계
멀티 리전 배포 및 멀티 AZ 배치
다중지역에 배포하여 하나의 지역에 장애가 발생하더라도 다른 지역에서 서비스가 계속 운영될 수 있도록 하여 전체 시스템의 가용성을 높인다.
단일 리전 내의 다중 가용 영역(Availability Zones, AZ)에 걸쳐 서비스를 배포한다.
스케일링 전략
트래픽 증가에 따라 자동으로 확장하여 과부하로 인한 장애를 방지한다.
2. 장애 복구 전략
장애 조치(failover) 매커니즘
DNS 서비스를 사용하여 트래픽을 자동으로 건강한 엔드포인트로 전환하는 장애 조치 설정을 구성한다.
건강 검사와 모니터링
시스템의 건강 상태를 지속적으로 모니터링하고, 문제가 발생했을 때 즉각적인 알림을 받는다.
재해 복구(DR) 계획
해 발생 시 시스템을 신속하게 복구할 수 있는 계획을 수립하고, 주기적으로 테스트하여 계획의 효율성을 검증한다.
3. 데이터 중복성 및 복구
데이터 복제
중요 데이터는 여러 위치에 복제하여 저장함으로써 하나의 데이터 센터에 장애가 발생해도 데이터의 손실 없이 서비스를 지속할 수 있도록 한다.
정기적인 백업 및 복원 테스트
중요 데이터에 대해 정기적으로 백업을 수행하고, 백업 데이터의 신뢰성을 검증하기 위해 주기적으로 복원 테스트를 실시한다.
4. 네트워크 다양화 및 보안 강화
멀티 경로 네트워킹
단일 네트워크 경로에 의존하지 않고, 여러 인터넷 서비스 제공업체(ISP)를 통해 네트워크 연결을 다양화하여, 특정 ISP의 장애가 전체 시스템에 영향을 미치지 않도록 한다.
DDoS 방어 메커니즘
분산 서비스 거부(DDoS) 공격으로부터 시스템을 보호하기 위해, 트래픽 필터링, 속도 제한, 그리고 클라우드 기반 DDoS 방어 서비스 등의 방어 메커니즘을 구축한다.
5. 인프라 코드화 및 자동화
Infrastructure As Code(Iac)
인프라 구성을 코드로 관리하여, 인프라 변경 사항을 자동화하고 버전 관리할 수 있도록 한다. 이를 통해 인프라 설정의 일관성을 유지하고, 장애 발생 시 빠른 복구가 가능하다.
지속적인 통합 및 배포(CI/CD)
애플리케이션의 변경 사항이나 업데이트를 자동으로 테스트하고 배포하여, 장애를 빠르게 발견하고 수정할 수 있도록 지속적인 통합 및 배포 파이프라인을 구축한다.
어플리케이션 단계
1. 모듈화 및 마이크로서비스 아키텍처
모듈화
애플리케이션을 작고 독립적인 모듈로 분리하여 개발함으로써, 하나의 모듈에 문제가 발생해도 전체 시스템에 미치는 영향을 최소화 한다.
마이크로서비스 아키텍처
각각의 서비스가 하나의 작업 또는 기능을 담당하도록 설계하여, 서비스 간의 결합도를 낮추고, 각 서비스의 독립적인 배포 및 확장을 가능하게 한다.
2.Stateless 디자인
Stateless 애플리케이션
애플리케이션의 상태를 클라이언트 측이나 중앙 데이터 스토어에 저장함으로써, 어떤 서버로 요청이 들어가도 동일한 응답을 제공할 수 있다.
이는 시스템의 확장성과 장애 복구 능력을 향상시킨다.
3. 코드 내 장애 대비 로직
리트라이 메커니즘과 시간 초과 설정
외부 서비스 호출 실패 시 재시도 로직을 구현하고, 적절한 시간 초과(timeout) 값을 설정하여 무한 대기 상태를 방지한다.
서킷 브레이커 패턴
연속된 요청 실패 시 일정 시간 동안 후속 요청을 차단하고, 시스템이 회복될 때까지 대기함으로써, 지속적인 오류로 인한 시스템 다운을 방지한다.
4. 데이터 일관성과 복구 메커니즘
분산 데이터 스토리지
데이터를 여러 서버에 분산하여 저장함으로써, 단일 데이터 스토리지의 실패가 전체 시스템에 미치는 영향을 최소화한다.
트랜잭션 관리와 롤백
데이터 일관성을 유지하기 위해 트랜잭션을 적용하고, 오류 발생 시 롤백을 수행하여 데이터의 정합성을 보장한다.
5. 테스트와 모니터링
자동화된 테스트
단위 테스트, 통합 테스트, 부하 테스트 등을 포함한 광범위한 자동화된 테스트를 수행하여, 코드 변경으로 인한 잠재적인 문제를 사전에 발견하고 수정한다.
실시간 모니터링과 알림
애플리케이션의 성능과 건강 상태를 실시간으로 모니터링하고, 이상 징후가 감지되면 즉각적인 알림을 받아 신속하게 대응할 수 있도록 한다.
결론
"중앙 집중화된 인증 시스템이 단일 장애 지점(SPOF)이 될 수 있고 그건 내가 말한 MSA를 사용한 이유에 어긋나지 않나?"
개요에서의 질문에 대한 답변을 지금 다시 말해본다면 이렇게 대답할 것 같다.
SPOF는 LoadBalancer, Router, API Gateway,외부 시스템 등
어디서든 생길 수 있고 완벽히 방지할 수는 없다고 생각한다.
그러므로 실패할 가능성을 염두하고 이중화, 스케일링 전략, 모니터링, DR 등을
통해서 방지하고 최소화 해야한다.
인프라적인 대응을 하고 애플리케이션 레벨에서 서킷 브레이커 패턴 등을 통해 장애를 격리한다.
이러한 방법으로 장애 발생 시 시스템의 영향을 최소화하고
서비스의 연속성과 복원력을 크게 향상시킬 수 있다.
실제 우리 서비스에 비용적인 문제를 고려해서 적용해본다면 CloudWatch를 통한 모니터링,
API Gateway 캐싱, 오토스케일링, 대체 인증 메커니즘.. 같은걸 고려해볼 수 있을 것 같다. 진정한 MSA를 위해 고민을 해볼 수 있는 좋은 질문이었던 것 같다.
근데 외부 시스템을 모두 제어할 수 없으므로 AWS의 인프라 구성을 잘하면 인프라 적인 요소에서 SPOF 가능성은 배제해도 되지 않을까?
MSA 너무 어렵다..
