분산환경에서 Latency를 어떻게 처리할 것인가?
부분 실패
큰 계산에 하나 또는 몇 대의 기계가 있을 수 있다. 어떤 이유로 실패가 되면 예외가 throw된다. 마스터 노드와 해당 작업자 노드 사이의 네트워크가 다운될 수 있다. 갑자기 한 대의 기계를 더이상 사용할 수 없거나 더 이상 작업 부분을 기여할 수 없는 곳에서 무언가가 발생한다.
대기시간
특정 작업이 다른 작업보다 훨씬 높은 대기 시간을 가질 수 있다.
특히 네트워크 통신은 매우 비싸다. 분산 계산을 수행 할 때 노드간에 통신할 필요가 없다.
대기시간은 실제로 작업이 수행되는 속도에 영향을 줄 수 있다.
부분 실패는 실제로 작업을 완료할 수 있는지 여부에 영향을 줄 수 있다.
기계가 다운되고 그 기계가 작동하던 것을 복구할 방법이 없다면 어떻게 할 것인가?
메모리에서 1mb를 순차적으로 읽는 것
디스크에서 1mb를 순차적으로 읽는 것의 속도 차이는 크다
메모리에 있는 것을 참조하거나 네트워크를 통해 데이터의 조각을 보내는 데 걸리는 시간에 1백만배의 차이가 있음
L1 캐시 참조 > L2 캐시 참조 > 메인메모리 > SSD > HDD > NETWORK
(1초) (4.8년)
분산 시스템이나 대규모 데이터 처리에서 내결함성이 중요한 이유는 작업 중간에 하나의 노드가 실패하거나 네트워크 문제가 발생할 가능성이 매우 높기 때문에 몇 개의 노드가 실패하더라고 시스템은 손실된 데이터를 다시 계산하는 방법을 찾을 수 있기 때문이다.
하둡이 아닌 스파크를 사용하는 이유?
Latency 관점에서 하둡의 내결함성은 비용이 든다. 각 map과 reduce 단계 사이에서 잠재적인 장애를 복구하기 위해 하둡은 네트워크를 통해 데이터를 셔플하고 디스크에 중간 데이터를 기록한다. 따라서 많은 네트워크 및 디스크 작업을 수행하고 있다. 반면 스파크는 함수형 프로그래밍의 아이디어를 사용하여 대기 시간 문제를 처리하여 디스크에 많은 글을 쓰고 많은 네트워크 통신을 수행한다는 것이다. 가능한 계산에 필요한 모든 데이터를 메모리에 유지하려고 시도한다. 데이터는 항상 Immuntable하다. 변경 불가능한 데이터를 메모리에 보관할 수 있고. 스칼라 컬렉션에서 배운 것처럼 List에서 map을 실행하고 다른 list를 다시 가져오는 것과 같이 다양한 기능적 변환을 사용할 수 있다. 충돌할 수 있는 노드에서 데이터 조각을 다시 계산하는 방법을 알아내거나 그 노드에서 수행해야하는 작업을 다시 시작하기 위해 우리가 해야할 일은 불변 데이터로 수행된 변환을 기억하기만 하면 된다.
다른 노드나 동일한 노드에서 해당 데이터를 읽은 다음 원래 데이터 집합을 통해 해당 기능 변환을 재생한다. 이것이 스파크가 정기적으로 중간 결과를 디스크에 쓸 필요 없이 내결함성을 달성할 수 있는 방법이다. 모든 것이 메모리에 남아 있으며 오류가 발생할 때만 네트워크 통신이나 읽기 및 쓰기 작업이 실제로 수행된다.
