280
2
부
시스템 설계
이라고 가정하는 부분을 찾아내서 해당 서비스를 복구할 때 두 번째 인스턴스를 생성하지 못하
는 상황을 미리 파악할 수 있다. 가능한 복구 시나리오를 모두 테스트해서 테스트 효율성과 프
로덕션의 실체 사이의 올바른 균형을 갖추는 것을 고려하자.
복구가 특히 어려운 상황에 맞춘 테스트의 진행도 고려해야 한다. 예를 들어 구글에서는 암
Arm
및
x86
CPU
,
UEFI
, 베어메탈 펌웨어, 마이크로소프트 비주얼
C
++(
MSVC
),
Clang
,
GCC
컴파일러 등 여러 환경에 따라 암호화 키 관리 프로토콜을 구현하고 있다. 우리는 이 로직의 장
애 모드를 모두 확인하는 것은 어려울 것이라는 점을 알고 있었다. 종단간 테스트에 상당한 투
자를 하더라도 실질적으로 하드웨어 장애나 통신 장애를 흉내내기가 어렵기 때문이다. 그래서
우리는 이식가능한 컴파일러 및 비트 폭에 중립적인 방식으로 한 번만 구현했다. 그후 이 로직
의 단위 테스트를 철저히 수행한 후 외부 컴포넌트에 추상화를 제공하기 위한 인터페이스 설계
에 특히 신경을 썼다. 예를 들어 가상의 개별 컴포넌트를 준비하고 장애가 난 상황을 연습하기
위해 암호화 키 스토리지이면서 성능 모니터링 요소도 기록하는 플래시 디스크의 바이트를 읽
고 쓰는 인터페이스를 만들었다. 이렇게 환경적 조건을 테스트하는 방법은 복구하려는 장애 등
급을 명시적으로 캡쳐할 수 있었기에 여전히 잘 사용하고 있다.
마지막으로 지속적인 검증을 통해 우리가 만든 복구 방법에 확신을 가질 수 있는 방법을 찾았 ...