8장. 분산 시스템의 골칫거리

결함과 부분 장애

단일 컴퓨터

• 하드웨어가 올바르게 동작하면 같은 연산은 항상 같은 결과를 낸다(결정적).
• 하드웨어 문제(메모리 오염, 헐거운 커넥터)가 있으면 보통 시스템이 완전히 실패하는 결과를 낳는다.
• 좋은 소프트웨어가 설치된 각각의 컴퓨터는 보통 완전하게 동작하거나 전체 장애가 발생하지 그 중간 상태가 되지 않는다.

분산 시스템

• 부분 장애(partial failure) : 시스템의 어떤 부분은 잘 동작하지만 다른 부분은 예측할 수 없는 방식으로 고장날 수 있다.
• 부분 장애는 비결정적이라서 어렵다.
• 여러 노드와 네트워크와 관련된 뭔가를 시도하면 어떨 때는 동작하지만 어떨 때는 예측할 수 없는 방식으로 실패한다.
• 메시지가 네트워크를 거쳐 전송되는 시간도 비결정적이기 때문에, 뭔가 성공했는지 아닌지 알지 못할 수도 있다.

 

클라우드 컴퓨팅과 슈퍼컴퓨팅

• 대규모 컴퓨팅의 한쪽 끝에는 고성능 컴퓨팅이 있고, 다른 극단에는 클라우드 컴퓨팅이 있다.
• 슈퍼 컴퓨터는 분산 시스템보다는 단일 노드 컴퓨터에 가까우며, 부분 장애를 전체 장애로 확대하는 방법으로 처리한다.
• 분산 시스템이 동작하게 만들려면 부분 장애 가능성을 받아들이고 소프트웨어에 내결함성 메커니즘을 넣어야 한다. 바꿔 말하면 신뢰성 없는 구성 요소를 사용해 신뢰성 있는 시스템을 구축해야 한다.

 

신뢰성 없는 네트워크

• 분산 시스템은 비공유 시스템, 즉 네트워크로 연결된 다수의 장비를 의미한다.
• 네트워크는 이 장비들이 통신하는 유일한 수단으로, 각 장비는 자신만의 메모리와 디스크를 갖고 있으며 다른 장비의 메모리나 디스트에 접근할 수 없다고 가정한다.
• 비공유 시스템을 구축했을 때 장점
  • 특별한 하드웨어가 필요하지 않아서 상대적으로 저렴하다.
  • 상품화된 클라우드 서비스를 활용할 수 있다.
  • 지리적으로 분산된 여러 데이터센터에 중복 배치함으로써 높은 신뢰성을 확보할 수 있다.
• 비동기 패킷 네트워크(asynchronous packet network) 
  • 인터넷과 데이터센터 내부 네트워크
  • 노드는 다른 노드로 메시지(패킷)를 보낼 수 있지만 네트워크는 메시지가 언제 도착할지 혹은 메시지가 도착하기는 할 것인지 보장하지 않는다.
  • 요청을 보내고 응답을 기다릴 때 여러가지가 잘못될 수 있다.(ex. 요청 손실/지연 전송, 노드 장애, 응답 손실/지연 전송)
  • 이런 문제를 다루는 흔한 방법으로 타임아웃이 있다. 얼마 간의 시간이 지나면 응답 대기를 멈추고 응답이 도착하지 않는다고 가정한다.

 

현실의 네트워크 결함

• 네트워크 상으로 통신할 때마다 실패할 가능성이 있다.
• 네트워크 결함의 오류 처리가 정의되고 테스트되지 않는다면 나쁜 일이 생길 수 있다.
• 반드시 네트워크 결함을 견뎌내도록 처리할 필요는 없지만, 소프트웨어가 네트워크 문제에 어떻게 반응하는지 알고 시스템이 그로부터 복구할 수 있도록 보장해야 한다.

 

결함 감지

• 많은 시스템은 결함 있는 노드를 자동으로 감지할 수 있어야 한다.
  • 로드 밸런서는 죽은 노드로 요청을 그만 보내야 한다.
  • 단일 리더 복제를 사용하는 분산 데이터베이스에서 리더에 장애가 나면 팔로워 중 하나가 리더로 승격돼야 한다.
• 네트워크에 관한 불확실성 때문에 노드가 동작 중인지 아닌지 구별하기 어렵다.
• 특정한 환경에서는 뭔가 동작하지 않는다고 명시적으로 알려주는 피드백을 받을 수도 있다.
• 뭔가 잘못되면 스택의 어떤 수준에서 오류 응답을 받을지도 모르지만 일반적으로 아무 응답도 받지 못할 것이라고 가정하고, 몇 번 재시도한 후 타임아웃이 만료되기를 기다렸다가 타임아웃 내에 응답을 받지 못하면 마침내 노드가 죽었다고 선언할 수 있다.

 

타임아웃과 기약 없는 지연

• 타임아웃 기준은?
  • 타임아웃이 길면 노드가 죽었다고 선언될 때까지 기다리는 시간이 길어진다.
  • 타임아웃이 짧으면 결함을 빨리 발견하지만 노드가 일시적으로 느려졌을 뿐인데도 죽었다고 잘못 선언할 위험이 높아진다.
• 비동기 네트워크는 기약 없는 지연(unbounded delay)이 있고(패킷을 가능한 한 빨리 보내려고 하지만 패킷이 도착하는 데 걸리는 시간에 상한치는 없다), 서버 구현은 대부분 어떤 최대 시간 내에 요청을 처리한다고 보장할 수 없다.
• 시스템이 대부분의 시간에 빠르다는 것은 장애 감지에 충분하지 않고, 타임아웃이 낮으면 왕복 시간이 순간적으로 급증해 시스템의 균형을 깨뜨릴 수 있다.

 

네트워크 혼잡과 큐 대기

• 컴퓨터 네트워크에서 패킷 지연의 변동성은 큐 대기 때문인 경우가 많다.
  • 여러 다른 노드가 동시에 같은 목적지로 패킷을 보내려고 하면 네트워크 스위치는 패킷을 큐에 넣고 한 번에 하나씩 목적지 네트워크 링크로 넘겨야 한다. 네트워크 링크가 붐비면 패킷은 슬롯을 얻을 수 있을 때까지 잠시 기다려야 할 수 있다.(네트워크 혼잡)
  • 패킷이 목적지 장비에 도착했을 때 모든 CPU 코어가 바쁜 상태라면 네트워크에서 들어온 요청은 애플리케이션에서 처리할 준비가 될 때까지 운영체제가 큐에 넣어 둔다.
  • 가상 환경에서 실행되는 운영체제는 다른 가상 장비가 CPU 코어를 사용하는 동안 수십 밀리초 동안 멈출 때가 흔하다. 이 시간 동안 가상 장비는 네트워크에서 어떤 데이터도 받아들일 수 없으므로 가상 장비 모니터가 들어오는 데이터를 큐에 넣어서 네트워크 지연의 변동성을 증기시킨다.
  • TCP는 흐름 제어를 수행한다. 노드가 네트워크 링크나 수신 노드에 과부하를 가하지 않도록 자신의 송신율을 제한하는 것으로, 데이터가 네트워크로 들어가기 전에도 부가적인 큐 대기를 할 수 있다.
• 네트워크 지연의 변동이 큰 환경에서는 실험적으로 타임아웃을 선택해야 한다.
• 지연의 변동성이 얼마나 되는지 알아내려면 긴 기간동안 여러 장비에 걸쳐서 네트워크 왕복 시간의 분포를 측정해야 한다.
• 그 후 애플리케이션의 특성을 고려해서 장애 감지 지연과 너무 이른 타임아웃의 위험성 사이에서 적절한 트레이드오프를 결정할 수 있다.
• 더 좋은 방법으로는 고정된 타임아웃을 설정하는 대신 시스템이 지속적으로 응답 시간과 그들의 변동성을 측정하고 관찰된 응답 시간 분포에 따라 타임아웃을 자동으로 조절하게 하는 것이다.(파이 증가 장애 감지기 사용)

 

동기 네트워크 VS 비동기 네트워크

• 동기식 네트워크는 데이터가 여러 라우터를 거치더라도 큐 대기 문제를 겪지 않는다.(ex. 전화 네트워크)
• 큐 대기가 없으므로 네트워크 종단 지연 시간의 최대치가 고정돼 있고, 이를 제한 있는 지연(bounded delay)이라고 한다.
• 전화 네트워크 회선은 TCP 연결과 매우 다르다.
  • 회선은 만들어져 있는 동안 다른 누구도 사용할 수 없는 고정된 양의 에약된 대역폭이다.
  • TCP 연결의 패킷은 가용한 네트워크 대역폭을 기회주의적으로 사용한다. TCP 연결이 유휴 상태에 있는 동안은 어떤 대역폭도 사용하지 않는다.

 

신뢰성 없는 시계

• 분산 시스템에서는 통신이 즉각적이지 않으므로 시간은 다루기 까다롭다.
• 메시지가 네트워크를 거쳐서 한 장비에서 다른 장비로 전달되는 데 시간이 걸린다.
• 메시지를 받은 시간은 항상 보낸 시간보다 나중이지만 네트워크의 지연의 변동성 때문에 얼마나 나중일지 알 수 없다.
• 네트워크에 있는 개별 장비는 자신의 시계를 갖고 있고, 이는 하드웨어 장치로 보통 수정 발진기다.
• 각 장비마다 시간 개념이 있으며, 다른 장비보다 빠를수도 느릴수도 있다.
• 네트워크 시간 프로토콜을 사용해 시간을 어느 정도 동기화할 수 있다.

 

단조 시계 VS 일 기준 시계

• 컴퓨터는 최소 두 가지 종류의 시계를 갖고 있다.
  • 일 기준 시계(time-of-day clock)
  • 단조 시계(monotonic clock)
• 둘 다 시간을 측정하지만 다른 목적으로 사용되므로 구별이 중요하다.

 

일 기준 시계

• 어떤 달력에 따라 현재 날짜와 시간을 반환한다.(벽시계 시간이라고도 함, wall-clock time)
• 보통 NTP로 동기화된다. 한 장비의 타임스탬프는 다른 장비의 타임스탬프와 동일한 의미를 지닌다는 의미이다.
• 시간이 거꾸로 뛸 수도 있다(ex. 로컬 시계가 NTP서버보다 너무 앞서는 경우 강제로 리셋되어 과거 시점으로 거꾸로 뛰는 것처럼 보일 수 있다).
• 역사적으로 매우 거친(coarse-grained) 해상도를 가진다(ex. 오래된 윈도우 시스템에서는 10밀리초 단위로 흐른다).

 

단조 시계

• 타임아웃이나 서비스 응답 시간과 같은 지속 시간(시간 구간)을 재는 데 적합하다.
• 항상 시간이 앞으로 흐른다.
• 한 시점에서 단조 시계의 값을 확인하고 어떤 일을 한 후 나중에 다시 시계를 확인하면, 두 값 사이의 차이로 시간이 얼마나 흘렀는지 알 수 있다.
• 시계의 절대적인 값은 의미가 없다.
• NTP는 컴퓨터의 로컬 시계가 NTP 서버보다 빠르거나 느리다는 것을 발견하면 단조 시계가 진행하는 진도수를 조정할 수도 있다.(시계를 돌린다(slewing)고 한다). NTP는 시계 속도를 0.05%까지 올리거나 내리는 것을 허용하지만 단조 시계가 앞이나 뒤로 뛰게 할 수는 없다.
• 단조 시계의 해상도는 보통 상당히 좋다.(대부분의 시스템에서 시간 구간을 마이크로초나 그 이하 단위로 측정할 수 있다.)

 

시계 동기화와 정확도

• 단조 시계는 동기화가 필요없지만 일 기준 시계는 NTP 서버나 다른 외부 시간 출처에 맞춰 설정돼야 유용하다.
• 시계가 정확한 시간을 알려주게 하는 방법은 기대만큼 신뢰성 있거나 정확하지 않다.
  • 컴퓨터의 수정 시계는 아주 정확하지 않고, 더 빠르거나 느리게 실행되는 드리프트 현상이 생긴다.
  • 컴퓨터 시계가 NTP 서버와 너무 많은 차이가 나는 경우 동기화가 거부되거나 강제로 리셋될 수 있다.
  • 패킷 지연의 변화가 큰 혼잡한 네트워크에서는 정확도에 한계가 있다.
• 상당한 자원을 투입해 시계 정확도를 높일 수 있다.(ex. GPS 수신기, 정밀 시간 프로토콜(Precision Time Protocol, PTP)과 세심한 배포 및 모니터링을 사용)

 

동기화된 시계에 의존하기

• 장비의 수정 시계에 결함이 있거나 NTP 클라이언트가 잘못 설정됐다면 시계는 드리프트가 생겨서 점점 실제 시간으로부터 멀어져가지만 대부분이 잘 동작하는 것처럼 보이기 때문에, 잘못됐다는 것을 눈치채기 어렵다.
• 소프트웨어의 어떤 부분이 정확히 동기화된 시계에 의존한다면 그 결과는 극적인 고장보다는 조용하고 미묘한 데이터 손실이 발생할 가능성이 높다.
• 동기화된 시계가 필요한 소프트웨어의 경우 필수적으로 모든 장비 사이의 시계 차이를 모니터링하거나, 다른 노드와 너무 차이나는 노드는 죽은 것으로 선언되고 클러스터에서 제거돼야 한다.

 

이벤트 순서화용 타임스탬프

• 최종 쓰기 승리(last write wins, LWW) : 다중 리더 복제와, 카산드라와 리악 같은 리더 없는 데이터베이스에서 널리 사용되는 충돌 해소 전략
• 문제점
  • 데이터베이스 쓰기가 불가사의하게 사라질 수 있다.
  • 순차적인 쓰기가 빠른 시간 내에 연속으로 실행되는 것과 진짜 동시에 쓰기가 실행되는 것을 구별할 수 없다.
  • 두 노드가 독립적으로 동일한 타임스탬프를 가진 쓰기 작업을 만들 수도 있다.
• 최근 값을 유지하고 다른 것들을 버림으로써 충돌을 해소할 때, 최근의 정의가 로컬 일 기준 시계에 의존하며 그 시계가 틀릴 수도 있다는 것을 알아야 한다.
• 논리적 시계(logical clock)는 진동하는 수정 대신 증가하는 카운터를 기반으로 하며 이벤트 순서화의 안전한 대안으로, 일 기준 시간이나 경과한 초 수를 측정하지 않고 이벤트의 상대적인 순서만 측정한다.
• 물리적 시계(physical clock)는 일 기준 시계와 단조 시계로 실제 경과 시간을 측정한다.

 

시계 읽기는 신뢰 구간이 있다.

• 시계 읽기는 어떤 신뢰 구간에 속하는 시간의 범위로 읽는 게 좋다.
• 예를 들어 어떤 시스템은 현재 시간이 해당 분의 10.3초와 10.5초 사이에 있다고 95% 확신할 수 있으나 그보다 더 정확히는 알지 못한다.

 

전역 스냅숏용 동기화된 시계

• 가장 흔한 스냅숏 격리 구현
  • 단조 증가하는 트랙잰션 ID가 필요하다.
  • 스냅숏보다 나중에 쓰기가 실행됐다면(스냅숏보다 큰 트랜잭션 ID로 쓰기를 실행한 경우) 그 내용은 스냅숏 트랜잭션에게 보이지 않는다.
  • 단일 노드 데이터베이스에서는 단순한 카운터가 트랜잭션 ID를 생성하는 데 충분하다.
  • 데이터베이스가 여러 데이터센터에 있는 여러 장비에 분산돼 있는 경우에는 사용하기 어렵다.
• 스패너의 스냅숏 구현
  • 트루타입 API가 보고한 시계 신뢰 구간을 사용한다.
  • 각각 가장 이른 타임스탬프와 가장 늦은 타임스탬프를 포함하는 두 개의 신뢰 구간(A = [A_earliest, A_latest], B = [B_earliest, B_latest]이 있고, 두 구간이 겹치지 않는다면(A_earliest < A_latest < B_earliest < B_latest) B는 A보다 나중에 실행된 것을 확신할 수 있다. 구간이 겹칠 때만 어떤 순서로 실행됐는지 확신할 수 없다. 
  • 트랜잭션 타임스탬프가 인과성을 반영하는 것을 보장하기 위해 읽기 쓰기 트랜잭션을 커밋하기 전에 의도적으로 신뢰 구간의 길이만큼 기다린다. 이러면 해당 데이터를 읽을지도 모르는 트랜잭션은 충분히 나중에 실행되는 게 보장되므로 신뢰 구간이 겹치지 않는다.
  • 대기 시간을 가능하면 짧게 유지하기 위해 시계 불확실성을 가능하면 작게 유지해야 한다.

 

프로세스 중단

• 분산 시스템의 노드는 어느 시점에 실행이 상당한 시간 동안 멈출 수 있다.
• 멈춰 있는 동안 외부 세계는 계속 움지이며 멈춘 노드가 응답하지 않으서 죽었다고 선언할 수도 있다.
• 멈춘 노드는 다시 실행되겠지만 얼마 후 시계를 확인할 때까지 중단됐다는 것을 알아채지 못한다.

 

응답 시간 보장

• 명시된 시간 안에 응답하는 데 실패하면 심각한 손상을 유발할 수 있는 환경에서 실행되는 소프트웨어의 경우 응답해야 하는 데드라인이 명시된다.
• 데드라인을 만족시키지 못하면 전체 시스템의 장애를 유발할 수 있는데, 이를 엄격한 실시간 시스템(hard real-time)이라고 한다.
• 시스템에서 실시간 보장을 제공하려면 소프트웨어 스택의 모든 수준에서 지원이 필요하다.
  • 프로세스가 명시된 간격의 CPU 시간을 할당받을 수 있게 보장되도록 스케줄링해주는 실시간 운영체제 필요
  • 라이브러리 함수는 최악의 실행 시간을 문서화 해야함.
  • 동적 메모리 할당은 제한되거나 완전히 금지될 수 있다.
  • 막대한 양의 테스트와 측정 필요
• 안전이 필수인 임베디드 장치에서 흔히 사용

 

지식, 진실 그리고 거짓말

• 분산 시스템에서는 공유 메모리가 없고 지연 변동이 큰 신뢰할 수 없는 네트워크를 통해 메시지를 보낼 수 있을 뿐이며 부분 장애, 신뢰성 없는 시계, 프로세스 중단에 시달릴 수 있다.
• 분산 시스템은 한 노드에만 의존할 수 없다. 노드에 언제든 장애가 나서 잠재적으로 시스템이 멈추고 복구할 수 없게 될 수도 있기 때문이다.
• 여러 분산 알고리즘은 정족수(quoarum), 즉 노드들 사이의 투표에 의존한다. 특정한 노드 하나에 대한 의존을 줄이기 위해 결정을 하려면 여러 노드로부터 어떤 최소 개수의 투표를 받아야 한다.

 

리더와 잠금

• 어떤 노드가 스스로를 선택된 자(파티션의 리더, 잠금을 획득한 자, 사용자명을 차지하는 데 성공한 사용자의 요청 처리기)라고 믿을지라도 노드의 정족수도 반드시 동의하는 것은 아니다.
• 노드의 과반수가 어떤 노드가 죽었다고 선언했음에도 그 노드가 선택된 것처럼 계속 행동한다면 신중하게 설계되지 않은 시스템에서는 문제를 유발할 수 있다.
• 분산 잠금의 잘못된 구현
  1. 임차권을 가진 클라이언트가 오랫동안 멈춰있어 임차권이 만료됨.
  2. 다른 클라이언트가 같은 파일에 대한 임차권을 획득해서 쓰기 시작
  3. 멈췄던 클라이언트가 되돌아왔을 때 임차권이 여전히 유효하다고 생각해서 저장소에 있는 파일에 쓰기
  4. 클라이언트들의 쓰기가 충돌되고 파일이 오염됨

 

펜싱 토큰(fencing token)

• 잠금이 승인될 때마다 증가하는 숫자
• 잠금 서버가 잠금이나 임차권을 승인할 때마다 펜싱 토큰도 반환한다고 가정하면, 클라이언트가 쓰기 요청을 저장소 서비스로 보낼 때마다 자신의 현재 펜싱 토큰을 포함하도록 요구할 수 있다.
  1. 클라이언트1이 33번 토큰으로 임차권 획득 후 중단돼서 임차권 만료
  2. 클라이언트2가 34번 토큰으로 임차권을 얻은 후 저장소 서비스로 34번 토큰을 포함한 쓰기 요청을 보냄
  3. 클라이언트1이 되살아 난 후 저장 서비스로 33번 토큰을 포함한 쓰기 요청을 보냄
  4. 저장소 서버는 더 큰 토큰 번호(34번)를 가진 쓰기를 이미 처리했으므로 요청을 거부
• 잠금 서비스로 주키퍼를 사용하면 트랜잭션 ID나 노드 버전을 펜싱 토큰으로 사용할 수 있다.

 

비잔틴 결함

• 어떤 노드가 실제로는 받지 않은 특정 메시지를 받았다고 주장하는 것처럼 노드가 거짓말을 하는 경우를 비잔틴 결함(Byzantine fault)라고 하며, 신뢰할 수 없는 환경에서 합의에 도달하는 문제를 비잔틴 장군 문제(Byzantine Generals Problem)라고 한다.
• 일부 노드가 오동작하고 프로토콜을 준수하지 않거나 악의적인 공격자가 네트워크를 방해하더라도 시스템이 계속 올바르게 동작한다면 이 시스템은 비잔틴 내결함성을 지닌다.
• 시스템이 비잔틴 내결함성을 지니도록 만드는 프로토콜은 매우 복잡하고 내결함성을 지닌 임베디드 시스템은 하드웨어 수준의 지원에 의존한다. 즉, 비용이 커서 실용적이지 않다.

 

약한 형태의 거짓말

• 하드웨어 문제, 소프트웨어 버그, 잘못된 설정 때문에 유효하지 않는 메시지로부터 보호해주는 메커니즘을 소프트웨어에 추가하는 것이 좋다.
• 완전한 비잔틴 내결함성을 지니지는 않지만, 나은 신뢰성으로 향할 수 있다.

 

시스템 모델과 현실

타이밍 가정에서 사용되는 시스템 모델

• 동기식 모델
  • 네트워크 지연, 프로세스 중단, 시계 오차에 모두 제한이 있다고 가정한다.
  • 시계가 정확하게 동기화된다거나 네트워크 지연이 없다고 암시하는 것은 아니고, 어떤 고정된 상한치를 초과하지 않을 것임을 안다.
  • 기약 없는 지연과 중단이 발생하기 때문에 현실적인 모델은 아니다.
• 부분 동기식 모델
  • 시스템이 대부분의 시간에는 동기식 시스템처럼 동작하지만 때때로 네트워크 지연, 프로세스 중단, 시계 드리프트의 한계치를 초과하는 것을 의미한다.
  • 많은 시스템에서 현실적인 모델
  • 가끔 어떤 타이밍 가정이 산산조각 날지도 모른다는 사실을 고려해야 하고, 이 때 네트워크 지연, 중단, 시계 오차가 커질 수 있다.
• 비동기식 모델
  • 타이밍에 대한 어떤 가정도 할 수 없다.
  • 시계가 없을 수도(타임아웃을 쓸 수 없을 수도) 있다.

 

노드용 시스템 모델

• 죽으면 중단하는(crash-stop) 결함
  • 노드에 장애가 발생하는 것은 죽는 것 뿐이라고 가정한다.
  • 노드가 어느 순간에 갑자기 응답하기를 멈추면 이후로 그 노드는 영원히 사용할 수 없고 결코 되돌아오지 않는 것을 의미한다.
• 죽으면 복구하는(crash-recovery) 결함
  • 노드가 어느 순간에 죽을 수 있지만 알려지지 않은 시간이 흐른 후에는 아마도 다시 응답하기 시작할 것이라고 가정한다.
  • 노드는 메모리에 있는 상태는 손실되지만 죽어도 데이터가 남아있는 저장소가 있다고 가정한다.
  • 유용한 모델
• 비잔틴(임의적인) 결함
  • 노드는 다른 노드를 속이거나 기만하는 것을 포함해 무슨 일이든 할 수 있다.

 

알고리즘의 정확성

• 알고리즘이 정확하다는 게 어떤 의미인지 정의하기 위해 알고리즘의 속성을 기술할 수 있다(ex. 정렬 알고리즘은 왼쪽 요소가 오른쪽 요소보다 작다는 속성이 있다).
• 알고리즘은 시스템 모델에서 발생하리라고 가정한 모든 상황에서 그 속성들을 항상 만족시키면 해당 시스템 모델에서 정확하다.

 

안전성과 활동성

• 안전성은 흔히 나쁜 일은 일어나지 않는다라고 하고, 활동성은 좋은 일은 결국 일어난다라고 정의된다.
• 안전성 속성이 위반되면 그 속성이 깨진 특정 시점을 가리킬 수 있다. 안전성 속성이 위반된 후에는 그 위반을 취소할 수 없다. 이미 손상된 상태이다.
• 활동성 속성은 반대로 어떤 시점을 정하지 못할 수 있지만 항상 미래에 그 속성을 만족시킬 수 있다는 희망이 있다.
• 분산 알고리즘은 시스템 모델의 모든 상황에서 안전성 속성이 항상 만족되기를 요구하는 게 일반적이다. 즉, 모든 노드가 죽거나 네트워크 전체에 장애가 생기더라도 알고리즘은 잘못된 결과를 반환하지 않는다고 보장해야 한다.
• 활동성에 대해서는 경고를 하는 게 허용된다. 예를 들어 노드의 다수가 죽지 않고 네트워크가 중단으로부터 결국 복구됐을 때만 요청이 응답을 받아야 한다고 할 수 있다.