고가용성은 서버에 오류가 발생하더라도 서비스가 중단되지 않도록 설정하는 것을 의미해요!
단순히 나는 서버를 여러 개 운영하고 있으니까 괜찮겠지? 라는 생각을 하는 것은 잘못된 생각이에요.
실제로 서버를 운영할 때 운영 환경에서는 존재하는 단일 오류 지점을 발견하고 조치를 취하는 게 가장 중요합니다!
실제 장애 사례로 보는 SPOF 문제
초기 서비스 구조는 보통 이렇게 생겼어요.
- 단일 웹 서버
- 단일 DB 서버
- 단일 로드밸런서
로드밸런서에 오류가 발생하면 서버 서비스가 싹 다 중단돼요.
쉽게 말하면 특정 컴포넌트 하나가 전체 시스템의 가용성을 결정하게 되는 구조가 되는 거라는 말이에요.
그래서 트래픽 증가할 때나 오류가 발생할 때 매우 취약합니다.
SPOF 제거를 위한 핵심 설계 전략
로드밸런서 이중화
로드밸런서는 트래픽의 진입점이기 때문에 반드시 이중화가 필요해요.
- Active-Standby: 평소에는 대기 상태, 장애 시 전환
- Active-Active: 여러 노드가 동시에 트래픽 처리
Active-Active 방식은 가용성이 높지만 비용과 운영 난이도가 엄청 올라가요.
Active-Standby는 Active-Active 보다는 단순하지만 오류 전환 시간 동안 지연이 발생할 수 있습니당.
애플리케이션 스테이트리스 설정
서버를 더 키우려면 스테이트리스 설정을 하셔야해요.
- 세션 정보를 서버 내부에 저장하지 않음
- 외부 저장소(Redis, DB 등)에 세션을 저장
이땐 어느 한 서버가 종료되더라도 다른 서버에서 요청을 처리할 수 있어요!
서비스가 중간에 꺼지거나 그런 거 없이 계속 확장이 가능해지는 거예요.
데이터베이스 이중화
데이터베이스는 가장 중요한 SPOF가 될 수 있어요.
- Primary / Replica 구조 구성
- 읽기와 쓰기 트래픽 분리
다만 레플리카 지연이 될 수 있어서 설정 할 때 주의가 필요하다는 점 알고 계세요!
헬스 체크와 자동 장애 전환
이중화된 구조에서도 상태 감지와 전환 로직이 없으면 효과가 별로 없어요.
- Health Check: 주기적으로 서버 상태 확인
- Auto Failover: 장애 발생 시 자동 전환
헬스체크랑 오토 페일오버가 없으면 오류가 발생했을 때 일일히 수동으로 해야해서 복구 시간이 많이 길어져요.
실제 설정할 때 판단해야 할 것들
고가용성 설계는 단순하게 기술을 구현하는 것이 아니라 선택의 문제입니다!
모든 구성 요소를 완벽하게 이중화하면 비용이랑 난이도가 급상승하게 됩니다.
어떤 서비스를 할 거냐에 따라 우선순위가 달라져요.
- 금융 서비스: 데이터 일관성 우선
- 콘텐츠 서비스: 가용성 우선
서버를 운영할 때 어디까지 가용성을 확보할 건지에 대한 기준이 명확하게 필요해요!
비용과 안정성의 균형
- 인프라 비용
- 네트워크 비용
- 운영 난이도
고가용성을 높일수록 인프라, 네트워크 비용, 운영 난이도가 올라가요.
실제 현장 나가서 실무에서는 이런 기준으로 설계를 결정해요.
- SLA 목표 수준
- 장애 발생 시 비즈니스 영향도
- 운영 및 대응 가능 인력
마무리
고가용성 아키텍처의 본질은 오류가 났을 때를 전제로 설정하는 거예요.
가장 중요한 것을 정리하자면
- SPOF를 식별하는 능력
- 트레이드오프를 판단하는 기준
- 자동화된 장애 대응 구조
이 3개가 정말 중요한 역할을 해요.
실제 서비스의 안정성을 결정하는 것이니 꼭 확인하시기 바랍니다!
오늘도 글 읽어주셔서 감사드립니다! 궁금한 점 있으면 댓글 남겨주세요.