Ambari Meetup TokyoでLTとパネルディスカッションしてきた

Hadoopソースコードリーディング第20回で発表してきました - wyukawa’s blogで話が出ていたAmbari MeetupがYahoo! JAPANさんのご尽力で実現しました。しかも美味しい食事とビール付きでした。なんて素晴らしいイベントなんでしょう。関係者のみなさまありがとうございました。

僕のLTスライドはこちら

My ambariexperience from wyukawa

当日は残念ながらHortonworks関係者の方がいらっしゃらなかったので[AMBARI-15418] hive.server2.authentication.pam.services and hive.server2.custom.authentication.class are required at NOSASL - ASF JIRAを早く見てよってプレッシャーをかける目論見は外れましたが、楽しいイベントでした。

Yahoo! JAPANさんの大規模事例を聞いたり他の方と話してて感じるのは現時点のAmbariで数百台の規模を運用するのは厳しいということ。

てっきりAmbariって大規模向きなのかと思ってたけどそうでもないみたい。台数が多くなるとAmbariのWeb UIが重いなどいろいろ問題が出てくるらしい。

あとAmbari Metrics使わずに結局Ganglia/Nagiosを使っているというような話を聞いて、僕が小規模クラスタでAmbariを使っていてかつAmbari Metricsをインストールしていないのはだいぶ正解なんじゃないかと思えてきた。

たしかにAmbariが競合のCloudera Managerの背中を追う宿命を負っていることや、サードパーティのモニタリングシステムを使わずに自分達でコントロールするためにAmbari Metricsを自作するのは理解できます。Prestoを担がずにHive LLAPを担ぐのも同じ理由でしょう。

でも現時点ではAmbariがCloudera Managerの劣化コピーの道を歩んでいる気がして一ユーザとしては危惧を覚えているのが正直なところです。

僕としてAmbariに望んでいるのはもっとベーシックな機能が安定して動くことです。upgrade時にバグに遭遇しないとかね。

なので正直モニタリングやアラートはなくて良いと思ってます。それはこっちで別システム使ってやるから。

AmbariがもっとリッチになってAnsibleとか使わなくても良いようにしてほしいという意見もあって、確かにツールが増えるのは辛いからそういう意見も理解できるけど、僕としてはまあどうせAnsibleは必要だから別にそれはなくてもいいかなって思ってます。

おそらくAmbariにさける開発パワーはそれほど多くないと思うので、本当に必要な機能に絞って開発してほしいなと思ってます。