Advent Calendar記事なのですが、大遅刻しました。ごめんなさい。
Observer NameNode 概略
HDFSではActive NameNodeがread, writeなど全てのリクエストを受け付けるというアーキテクチャになっていますが、readリクエストはActive NameNodeじゃなくても(条件付きで)処理できるので、特別なStandby NameNode(以降、Observer NameNode)を用意してそれにオフロードさせましょう、というデータベースでよく見かけるタイプの機能です。HDFSでは、一般的な使い方をしていればreadリクエストが圧倒的多数になるはずなので、これによりActive NameNodeの負荷を大幅に削減することが期待されます。
Observer NameNodeを利用する場合は、もともとActive NameNodeとStandby NameNodeがいたところに新しくObserver NameNodeを追加するという形になります。ActiveとStandby、StandbyとObserver間は直接遷移しますが、ActiveからObserverに、ObserverからActiveにという遷移はしません。そのため、ActiveとObserverだけの構成はできないことに注意が必要です。
Observer NameNodeについては公式ドキュメントの "Consistent Reads from HDFS Observer NameNode" に詳しく記載されているので、英語が得意な方は読んでいただけると大体どういうものかがわかると思います。
公式ドキュメントのタイトルに"Consistent Reads"とあるとおり、Client Consistencyを保つように(簡単に言うと、あるクライアントが書いたデータを直後に同じクライアントが読んだときにデータが存在しない、ということがないように)実装されています。公式ドキュメント or/and @hayanige さんの発表資料に説明があるので、実装の詳細は省きます。
Observer NameNodeの現状の課題
ここからが本題です。
readリクエストと思っていたものがActive NameNodeで処理されてしまう
HDFSではaccess time(以下atime)を保持しているため、atimeを有効にしている場合はreadリクエストでもfsimageが更新されます。よって、Active NameNodeで処理されます。見も蓋もない話ですが、atimeは無効にするしかありません。atimeをアクセス解析目的などで利用している場合には注意が必要で、HDFSのaudit logをパースするなどの仕組みが別途必要となります。
JIRA: https://issues.apache.org/jira/browse/HDFS-14870
そもそもatimeの更新自体がfsimageのwrite lockを取る重い処理なので、atimeが不要であれば、Observer NameNodeを利用する前にatimeを無効にするチューニングをしてもいいかもしれません。
Router-based Federationに未対応
Observer NameNodeを活用しても、1つのNamespaceが巨大になるとNameNodeのヒープも巨大になることには変わりありません。そのため Router-based Federation と組み合わせて導入してみたいのですが、まだ対応しておりません。
JIRA: https://issues.apache.org/jira/browse/HDFS-13522
そもそもRead-only DFSRouterを用意したほうがいいのではないか? という議論になったりしていて、あまり進捗していない状況です。
おわりに
Router-based Federationを検証環境に導入するついでにObserver NameNodeも同時に導入できないかいろいろと試したのですが、上記2つ以外にもいろいろと踏んでいて現状ではかなりつらい感じです。今後の進捗に期待。自分も見ているだけでなくて開発、議論など頑張りたいところですが、Router-based Federationの方が業務上の優先度が高いのであまり手を付けられていない感じでごめんなさい、といったところです。