Failover 이론

Faliover

• A서버에 장애가 일어났을 때, A 서버의 장애를 회복시키기 위해 B서버가 A서버의 기능을 가져가는 것. 
• ex) 웹 서버라면, 다른 웹 서버가 트래픽을 가져가는 것. DB 서버라면 DB서버에서 데이터를 주고 받는 기능을 위해 다른 DB서버가 그 데이터의 IO를 처리해주는것.
• Active 한 시스템에 장애가 발생했을때 StandBy 서버가 Active로 전환해 서비스가 계속 운영되게 하는 것을 말한다.
  • 서비스 가용성High Availabilty를 제공하기 위해 사용한다. 

 

간단한 시나리오

• 장애 발생시, 개발자가 직접 설정을 변경해 배포한다.

이 시나리오의 문제점

• 누군가 계속 장애를 모니터링 하다가, 장애가 발생한 시점에 설정을 바꾸고 재배포 해야한다.
  • 담당자가 해당 문제를 확인하지 못한다면?

 

자동화된 Failover방식이 필요하다

• Coordinator를 이용한 방식이 있다
  • service discovery 형태  
  • coordinator와의 연동이 필요하다.
  • 이미 coodinator를 쓰고 있는 서비스라면 적용하기 쉽다.
  • 기존에 coordinator와 연결성이 없는 곳이라면, 적용이 복잡할 수 있다.
    • 외부에 서비스를 제공해아 한다면, 적용 못 할 수도 있다. 외부 서비스가 우리의 특정 코디네이터에 붙어서 데이터를 받아가는 것은 위험한 방식이다.  또한 외부 서비스에서 우리를 위해 코디네이터를 이용한 방식으로 수정하는 것도 어렵다. 

사용자 입장에서 조금 더 명확한 transparent 방법이 필요하다.

-> VIP 와 DNS를 이용하는 방법

 

AWS에서 제공하는 Failover 방식

• Aws에서 시버스의 기본적인 failover는 DNS 방식을 이용해 제공한다.
  • ELB의 Failover
  • ElasticCache의 endpont failover
  • RDS의End point Failover
• 기본적으로 multi-AZ를 사용해야 한다.
• 어느 수준까지 failover를 제공해야하는지도 고민해봐야 한다.
  • 서비스의 복구 비용, 운영 비용의 차이
  • 서비스 복구 비용은 유저 이탈도 고려해야 한다.

 

Aws Elastic Cache 의 Failover

• dns 기반의 auto-failover 를 제공한다.
  • primary 노드가 장애가 나더라도, 기존 DNS로 다시 액세스 하면 새로운 primary 노드에 접속 하게 된다. 

 

DNS를 이용하는 방식에서 주의할 점

•  DNS는 TTL이 존재한다
  • DNS를 이용한 Failover는 DNS TTL을 짧게 설정한다.
  • 이것은 DNS 서버에 부하를 많이 줄 수 있다는 이야기
• 특정 어플리케이션은 DNS를 영구 캐시하는 솔루션도 있을 수 있으므로, 이런 종류의 솔루션에서도 제대로 동작하지 않는다.