▪︎ 이중화 기술
- 고가용성, 높은 신뢰성
- 시스템에 장애 발생할 것을 대비, 동일한 기능을 수행하는 예비 시스템을 동시에 운용하는 행위
- 안정적인 서비스 제공을 위해 네트워크를 포함 모든 인프라에서 반드시 갖추어야 할 요소
- SPoF(Single Point of Failure) 단일 실패점을 제거하기 위한 수단
- 물리 서버, 가상 서버, 인터페이스, 스위치, 방화벽, IGW, DC … 인프라의 대부분 모든 요소를
- → 서버 이중화, 회선 이중화, 방화벽 이중화, IGW 이중화, DC 이중화, 멀티 클라우드 …
▪︎ 동작방식
- Active - Active (A/A)
- 인프라 각 구성 요소가 동시에 운영 중인 상태로 동작
- 장애 발생 시 나머지 구성 요소들로 시스템 가동
- 장점
- 평상시에 처리 가능한 리소스 용량 증가
- 단점
- 장애 발생 시 평상시보다 처리 용량이 반으로 줄어 정상적인 서비스 제공 어려움
- 그래서 A/S보다 더 높은 처리량을 갖는 서버나 더 많은 대수로 구성 권장
- 초기 구성 어려움
- 운영 비용 높음
- Active - Standby (A/S)
- 하나의 구성 요소는 운영 상태이고 다른 하나는 대기 상태로 동작
- 장애 발생 시 대기 상태인 인프라가 운영 상태로 전환
- 장점
단점이 적은 것..?
- 단점
- 자원의 비효율성 발생
▪︎ 이중화 기술을 활용한 클라우드 아키텍처
이중화 스토리지 아키텍처 (A/S)
- 클라우드 스토리지 디바이스는 종종 네트워크 연결 장애, 컨트롤러/HW 장애, 보안 사고 등으로 사용 불능 상태가 되거나 저장된 데이터 손상될 수 있음
- 주 클라우드 스토리지 장치 + 보조 클라우드 스토리지 장치 (Active + Standby)
- 주기적인 데이터 동기화 : 주 스토리지 장치 ← → 보조 스토리지 장치
- 스토리지 서비스 게이트웨이 : 사용자의 요청을 어떤 스토리지로 전달할지 결정
- 주 스토리지 장치에 장애 감지 : 스토리지 서비스 게이트웨이를 통해 사용자 요청을 보조 스토리지로 전달
📌 장애 발생 시 스토리지를 이관하는 과정에서 소요되는 시간이 길어지기 때문에 이를 줄이기 위한 아키텍처
▪︎ 번외) 대표적인 고가용성을 위한 클라우드 아키텍처
무중단 서비스 재배치 아키텍처
100% 완벽한 이중화 구조는 아닌데 이중화 비스무리 느낌이라서 픽
when?
- (수평적 성능 확장 수행 X 인 경우) 요구 용량이 처리 용량을 초과하는 경우
- 유지 보수 업데이트 작업 수행인 경우
- 서비스 / VM 등을 신규 물리 서버 호스트로 영구적으로 이관하는 경우
how?
- 서비스 중단 방지, 서비스 지속
- (사전에 이중화 방식은 아닌) 사전에 정의된 이벤트 발생 시, 자동으로 클라우드 서비스를 복제 또는 이관하여 다운타임을 방지
- 서비스 재배치 방식
1. Listener Agent를 통해 부하량 및 서비스 상태 모니터링
2. 작업 부하량 임계치 도달 및 서비스 장애 발생
3. 서비스 재배치 신호를 VIM에게 전송
4. VIM은 가상 머신 이관 프로그램을 호출하여 가상 머신 이관 절차 수행
✔ 기존의 가상 머신은 계속 서비스 상태 유지
5. 하이퍼바이저가 가상 머신과 서비스 복제본을 물리 서버 B에 생성
✔ 아직 이관 작업 마무리 안 함
6. 가상 머신 및 서비스 이관 후, 두 개의 가상 머신 상태를 동기화
7. 기존의 가상 머신은 삭제
8. 작업 이후, 사용자 요청은 복제된 서비스로 전달
그럼 퍼블릭 클라우드에서 제일 쉽게 떠올려볼 수 있는 이중화 기술은?
▪︎ 가용 영역(AZ, Availibility Zone)
- 물리적으로 떨어져 있는 영역인 Availibility Zone을 운용
- 하나의 리전에서도 여러 가용 영역(AZ)에 자원을 복제함으로써 고가용성 보장
- ex) AZ-a, AZ-b, AZ-c, AZ-d
▪︎ 사용자 증가에 따른 AWS 아키텍처 진화
- 사용자 수 < 1,000
- 서버 이중화 구성 : VPC
- 리전 내 서로 다른 가용 영역에 인스턴스를 생성함으로써 더 높은 가용성 확보
- 사용자 수 > 1,000
- DB 가용성 확보 : Amazon RDS 다중 AZ 배포
- 한 가용 영역에 Master, 다른 가용영역에 Stand by 생성
- Master의 데이터를 Stand-by에 복제 후 동기화
- Master 장애 시, Stand-by를 Master로 자동 승격하여 대체
- 사용자 수 > 10,000
- 캐시 서버 가용성 확보 : Amazon ElastiCache 다중 AZ 배포
▪︎ 결론
- 사용자 증가에 따라 아키텍처에 이중화를 좀 더 고려하는 것을 볼 수 있다.
- 퍼블릭 클라우드에서 서버 구성 시, 멀티-AZ를 적극적으로 활용하여 이중화를 구성하는 것을 확인할 수 있다.
- 모든 계층에 이중화를 적용하고자 하는 것을 확인할 수 있다.