여러 HA Architecture를 통해서 HA는 달성했지만 여전히 active namenode에 부하를 주는 문제가 발생한다. 이 부하를 해결하지 못하면 failover가 되더라도 새로운 namenode도 똑같이 부하로 죽을 수 있기에 연쇄적으로 계속 이용 못할 수 있다.
Hadoop은 대부분 use case가 write-once-read-many access model을 따르기 때문에 read 부하를 분산해주는 것만으로도 부하를 많이 낮출 수 있다.
Hadoop version 3부터는 Active, Standby, Observer로 3가지 상태를 가진다.
여기서 observer - standby 끼리만 전환 가능하며 active에서 observer가 되거나 그 반대는 안된다.
Consistency
read-after-write consistency를 유지하기 위해 state ID가 RPC header에서 사용된다. State ID는 namenode의 transaction ID를 이용해서 구현된다.
Client가 active namenode를 이용해서 write를 수행하면, state ID를 namenode의 latest transaction ID를 이용해서 업데이트한다. 이후 read operation에서 observer namenode는 자신의 state id와 client로 받은 state ID로부터 도출한 transaction ID를 비교한다.
확인 결과 같다면 observer namenode는 요청된 read를 수행하고 결과를 리턴하고 같지 않다면 아직 sync가 되지 않은 것이므로 sync 먼저 진행한다.
이 방식으로 하면 read your own writes semantic을 보장한다.
Edit Log Tailing
latency를 줄이기 위해서 L7인 HTTP 대신 L4인 TCP 위에서 도는 RPC based tailing을 사용한다. 그리고 빠르게 sync하기 위해 in-memory cache를 사용한다.
Client-side Proxy Provider
client가 read 요청을 하면 proxy provider가 먼저 observer namenode로 read를 시도한다. 이후 모두 실패했을 때 active namenode로 요청을 보내 분산시킨다.
Maintaining Client Consistency
write를 확정받지 않은 상황에서 hadoop이 아닌 다른 클라이언트가 조회를 요청할 때 이를 읽을 수 있을지 없을지 보장되지 않는다. (내가 저장했으니까 너가 조회해봐 와 같은 상황)
msync() 기능으로 active namenode에 대한 업데이트 이후 요청하는 어떤 read던지 msync()지점까지 consistent를 보장한다.
