- 용어
- Partial Failure: 여러 node에 걸친 작업인 경우 발생 가능
- nondeterministic: network fault등 확실한 원인 분석 불가한 경우
- Large-scale computing systems
- HPC: high-performance computing.
- Node fail 시 전체 cluster 멈춤.
- Shared memory, RDMA(remote direct memory access) 등으로 node 간 통신
- 특수한 network topology와 H/W 사용하기도 함
- Cloud Computing
- Internet-related applications
- Reliability
- 무선 통신에 의한 간섭 등으로 node 자체 reliability보다 unreliable해지기도 함
- Cluster 수준에서 reliability 보완도 가능(circuit break 등)
- Shared-nothing: 특수 hardware 불필요
- bounded delay
- Synchronous network환경에서 적용
- queueing이 없어 발생하는 고정적 delay
- Knowledge
- Truth: 다수가 옳다고 생각하는 정보
- GC로 인한 long pause, asymmetric fault, semi-disconnect 등으로 다수와통신 불가 시 통신이 끊겼다고 판단
- Quorums. 투표 방식
- 실제로 crash가 생겼는지, 어떤 문제인지는 truth 결정 단계에서는 중요하지 않음
- Fencing token: 오류가 생긴 node가 lock을 잡고 있더라도 fencing token으로 덮어쓸 수
- 있음
- fencing token은 계속해서 증가하는 정수 값.
- Lies
- Byzantine Fault: Byzantine generals problem에서 유래
- node가 현재 상태와 다른 값을 보내는 경우를 고려한 문제 상황
- Malfunction이나 attacker에 의해 발생
- Byzantine fault-tolerant protocol
- 자체 bug나 injection 공격 등은 방어 어려움
- 여러 node 중 하나의 node에서만 발생하는 경우
- Checksum 활용
- input value에 대한 verifying
- NTP 관련: 여러 서버에 질의
- safety: nothing bad happens
- Liveness: something good eventually happens
- Networks
- Asynchronous packet network
- 발생 가능한 faults: timeout이 가장 일반적인 대처 방안. 경험적으로 설정
- Request lost/delay
- switch의 queue가 찰 경우 packet drop 발생
- node의 모든 CPU가 busy 상태면 delay 발생
- TCP의 flow control로 인한 delay
- 지리적으로 인접한 node에서 traffic을 잡을 경우 delay
- Remote node fail/temporary stop
- Response lost/delay
- Detecting faults
- Circuit break
- Failover
- Process listening fault: RST, FIN등의 reply
- Process crash: timeout or expire
- Switches alive: link failure 검색 가능.
- IP unreachable: router에서 reply.
- Error 메시지조차 받지 못하는 상황도 상정해야 함
- Timeout: 지나치게 짧으면 불필요한 반복과 추가적인 load 발생
- 패킷 전송 시간과 작업 시간을 고려해 설정
- 여러 요인들을 모두 고려하기 어려움. 경험적으로 설정할 필요
- 관측된 response time을 바탕으로 동적 설정: Phi Accural failure
- detector(Akka,Cassandra)
- TCP retransmission timeout도 이처럼 작동
- Packet-switched(<>circuit-switched)protocol은 delay 예측이 어려움
- network의 효율적 사용
- ATM의 경우 두 방식을 적절히 섞기도 함.
- multi-tenant data center에는 적용 힘듬.
- link congestion 등에 delay 있음
- Clock
- 절대 시간
- 사용하지 않는 것이 좋음
- node 간 sync가 맞지 않을 경우 다양한 concurrency 문제 발생
- LWW와 연계 시 치명적
- 동일한 timestamp에 여러 값이 겹칠 경우 tie-breaker 로직 추가되어야 함
- node 간 통신에 걸리는 시간을 고려하면 크게 의미가 없는 값
- NTP 기반의 시간도 생각보다 일정하게 흐르지 않음
- 경우에 따라 NTP 자체에서 second leap 발생
- NTP와의 통신이 멈추면 커다란 오차 발생
- virtual machine의 경우 한 단계 통신을 더 거쳐 오차가 커짐
- Clock에 문제가 생겨도 당장 오류가 나지 않아 문제를 키울 가능성
- Process pause 관련 문제: 절대 시간의 차를 통해 시간을 산정 시 치명적 오류 생성
- GC에 의한 pause
- VM/end-user suspend
- Switch context
- Slow disk I/O operation
- Swapping
- hard real-time system
- Embedded system 등에서 사용(RTOS. Real-time OS)
- 특정 시각 전까지 완료되지 않으면 cluster fail
- deadline을 맞추기 위한 추가적 resource 투입 필요
- GC가 node 별로 돌아가며 실행되도록 설정하기에 함
- GC를 막기 위해 오래된 pod는 강제 재시작하기도 함
- 시간 범위 사용
- NTP 서버 자체 오차와 network round-trip time 고려
- Google’s TrueTime API가 드물게 현재 시각을 범위로 제공(7ms 이내 오차)
- Snapshot isolation
- commit 전 시각의 오차 범위를 넘어서도록 조정
- 상대 시간(Monotonic clock)
- System Model: H/W나 S/W 설정에 지나치게 의존하지 않도록 구성
- Clock 관련
- Synchronous model: bounded network delay 사용.