250
2
부
시스템 설계
으면 매우 복잡해진다. 예를 들어 불안정한 릴리스를 롤백하다가 보안 취약점이 재발할 수도
있다. 보안 취약점을 패치하는 새로운 릴리스를 롤아웃하다가 신뢰성 이슈가 발생하기도 한다.
이렇게 위험을 내포한 완화 작업은 더 세세한 절충으로 가득하다. 예컨데 얼마나 자주 변경을
배포할 것인지 결정하는 경우 신속하게 롤아웃하면 공격자와의 경합에서 우위에 설 수 있지만
반대로 해당 배포를 충분히 테스트하지 못하기도 한다. 결국 시스템의 상당 부분에 새로운 코
드를 배포한 후에야 심각한 안정성 버그가 있음을 알게 되기도 한다.
긴박한 보안이나 신뢰성 장애 상황에서 이런 세세한 부분(과 시스템이 이를 처리할 준비가 되
어 있지 않은 것 )까지 신경쓰는 것은 이상적인 방법과는 거리가 멀다. 이런 점을 미리 고려해
설계를 결정해야만 복구에 필요한 다양한 조건을 시스템이 자연적으로 지원하는 데 필요한 신
뢰성과 유연성을 가질 수 있다. 이번 장에서는 조금 더 편하게 복구가 가능한 시스템을 효율적
으로 준비할 수 있는 몇 가지 설계 원칙을 설명한다. 이 중 상당수의 원칙은 범지구적 규모의
시스템부터 개별 머신의 펌웨어에 이르기까지 다양한 규모에 적용할 수 있다.
9.1
어떤 상태로부터 복구하는가?
용이한 복구를 위한 설계 전략에 앞서 시스템을 복구해야 하는 몇 가지 시나리오에 대해 먼저
살펴보자. 이 시나리오는 랜덤 에러, 실수에 의한 에러, 악의적인 공격 그리고 소프트웨어 에러
등으로 분류할 수 있다.
9.1.1
랜덤 에러
분산 시스템은 ...