新春特別企画

Apache Kafkaにも注目 ―Hadoop, Spark,分散処理フレームワークをめぐる2019年

この記事を読むのに必要な時間:およそ 5 分

あけましておめでとうございます。

今年も大規模データ向けの分散処理フレームワークの展望についてご紹介します。例年Apache HadoopとApache Sparkを中心にお届けしておりましたが,今年はこれらに加えて,2018年に活用が広がりが認知された分散メッセージシステムのApache Kafkaについても 同様に取り上げたいと思います。

今年は,NTTデータに所属するエンジニアの中でも特にHadoop,Spark,Kafkaなどに深く取り組んでいる 岩崎正剛(Hadoopコミッタ)⁠猿田浩輔(Sparkコミッタ)⁠都築正宜(Sparkコントリビューター)⁠吉田耕陽,佐々木徹(Kafkaコントリビューター)⁠酒井遼平,田中正浩(Hadoopコントリビューター)というメンバーでディスカッションした内容をもとに構成しています。

Hadoop

Hadoopは2018年に入っても活発に開発が進められています。主に大規模ユーザ向けの改修が目立っており,YARN,HDFSともにより大きなクラスタを扱えるようにするためのフェデレーション機能の開発が進んでいたり,Hadoopクラスタ上でオブジェクトストレージを実装するOzoneに代表されるHDDS(Hadoop Distributed Data Storage)の開発が進められていたりします。

本稿では上述のHadoopの開発動向そのものよりも,Hadoopが成熟し,適用に広がりを見せていることを示すエピソードを2つほどご紹介したいと思います。

ディスカッション中の岩崎正剛氏

ディスカッション中の岩崎正剛氏

Hadoop 3系リリースとエコシステムとの互換性問題

2017年12月にHadoop 3.0.0がリリースされ,SparkやHiveといったエコシステムのプロダクトでもHadoop 3対応が進められました。その過程でHDFSのデフォルトのポート番号の変更(HDFS-9427)には,移行の妨げとなる部分があることがわかりました。

Hadoop 2系のHDFSでは,NameNodeやDataNodeといったサービスが50010や50070のようなポート番号を利用していました。これらはエフェメラルポートの範囲に含まれるため,同じ番号を一時的に利用している他のプロセスが存在すると,サービスの起動に失敗してしまいます。そのため,Hadoop 3.0.0ではポート番号のデフォルト値が,9800番台周辺に変更されました。

ここで問題となったのが,NameNodeの8020番が9820番に変更されたことです。HDFS上のファイルにアクセスする際,hdfs://nn01:8020/a/b のようなNameNodeのホスト名とポート番号を含むURIを指定することができます。そのため,Hadoop関連プロダクトのユニットテストや,ユーザが作成したスクリプトなど,8020がハードコーディングされている部分が,予想以上に多く存在したのです。とくに,既存のクラスタ内で利用されているHiveメタストアに8020番を含むURIが含まれているような場合,Hadoop 3への移行が難しくなります。

もともと8020番はエフェメラルポートの範囲外で本質的には変更不要であったことから,2018年3月にリリースされたHadoop 3.0.1では9820番への変更が取り消され,元の8020番に戻されました。

ポリシー上,互換性を損なう変更は,メジャーバージョンを上げる時にしか行わないことになっています。しかし,Hadoop 3への移行性に大きく影響することと,その時点でHadoop 3.0.0を商用利用しているユーザはまだいないとの判断から,例外的に互換性のない変更を含む3.0.1がリリースされ,3.0.0は非推奨バージョンとなりました。

昨年以前の本記事でも,Hadoopエコシステム内のプロダクト間の依存関係と互換性に言及しましたが,その難しさの一端を示すエピソードだと思います。

Hadoopに対する攻撃

2018年には,XbashやDemonBotと呼ばれる複数種類のマルウェアによる,Hadoopを対象とした攻撃が観測されました。インターネットからアクセス可能なHadoopクラスタを探し,ビットコインのマイニングやDDoS攻撃に利用するという内容です。

これらはセキュアでない設定のHadoopクラスタを標的にするもので,Hadoopの脆弱性を突いたというものではありません。セキュリティ機能を有効化していないHadoopクラスタでは,容易に別のユーザ権限で処理を実行可能です。このようなクラスタをインターネットからアクセス可能な状態に置くことは,当然避けるべきミスというべきですが,クラウドサービス上で気軽にHadoopを利用できるようになった昨今,攻撃対象となりうるクラスタも増えているのかもしれません。良くも悪くも,Hadoopが広く利用されていることを示す事例であると感じます。

また,セキュリティ機能を有効にし,クローズドなネットワーク内でHadoopを運用しているとしても,Zip Slipによるコードインジェクション(CVE-2018-8009)のような脆弱性が発見されることもあります。不特定多数のユーザがHadoopを利用するような環境では,セキュリティアップデートに注意を払う必要があります。

Hadoopディストリビュータの合併

今年Hadoop界隈を大きく騒がせたニュースが,Hadoopのパッケージを提供するディストリビュータの2大巨頭であるCloudera社とHortonworks社の合併です。2019年に合併されることが,2018年10月に発表されました。

2018年にはHadoop 3をベースとして,ClouderaがCDH 6を,HortonworksがHDP 3をそれぞれリリースしている状況であり,双方ともに積極的な開発が続いています。

Hadoop 開発者の目線で見たときに,Hadoopおよびエコシステムのプロダクトは,コミュニティベースで開発されるオープンソースソフトウェアなので,合併したとしてもそこが変わるわけではありせん。もともと技術者間の交流もあるため,そこは継続されるでしょう。

とはいえ,主要開発者の所属企業として,ClouderaとHortonworksが占める割合は大きく,Hadoopエコシステムに供給されるエンジニアリングリソースが,合併によってどう変化するのかは,気になるところです。

また,Hadoopの利用者目線で見たときに,類似の機能を持つプロダクトを,ClouderaとHortonworksそれぞれが主導して開発するような競争関係があるケースについても,変化が起こると予想されます。執筆時点ではどのようにマージされていくかについてはアナウンスはありませんが,この動向については注視しておく必要があるでしょう。

2019年のHadoop

Hadoop 3.0.0がリリースされた後も,開発は継続して行われています。冒頭で述べたような開発以外にも,Amazon S3上のデータにアクセスするためのS3AFileSystemの継続的な改善や,HDFS外に格納されたデータをHDFSと連携させるPROVIDEDストレージ機能(HDFS-9806)などは,大規模データ処理におけるストレージの選択肢が増え,多様化したことを反映しているという印象です。周辺プロダクトやクラウドサービスの動向と合わせて,動向をフォローするとよいでしょう。

酒井遼平氏(左)と田中正浩氏

酒井遼平氏(左)と田中正浩氏

著者プロフィール

岩崎正剛(いわさきまさたけ)

株式会社 NTTデータ

Hadoopをはじめとするオープンソースソフトウェアの技術的ななんやかやに従事。NO RICE, NO LIFE. 麺類も好きです。


猿田浩輔(さるたこうすけ)

株式会社 NTTデータ

2009年からHadoopをはじめとしたOSSの並列分散処理基盤の導入支援や技術開発などを行い,2014年からはHadoopを補完するプロダクトの候補としてSparkに取り組みはじめる。技術調査や案件支援などを経て明らかになったSparkの課題に取り組み,コミュニティへのフィードバックを続けてきた。2015年6月に日本人最初のApache Sparkコミッタに就任。


佐々木徹(ささきとおる)

株式会社 NTTデータ

これまでに大規模クラスタでのApche Sparkの性能検証などに関わった。OSSコミュニティでの開発活動も行っており,これまでにApache Hadoop,Apache Spark,Apache Kafkaに貢献してきた。


下垣徹(しもがきとおる)

株式会社 NTTデータ

PostgreSQLを中心としたオープンソースのDBMSに取り組む。本体拡張機能の開発を経て,Oracle DatabaseからPostgreSQLへの移行案件に従事し,ミッションクリティカルな商用システムへの適用を実現してきた。近年,大規模なデータを処理するニーズに応えるかたちでHadoopに取り組み始め,DBMSとHadoopの両者の特徴を活かした効果的な組み合わせの実現に注力する。共著に『Hadoop徹底入 門』(第1版,第2版),『Apache Spark入門』『Apache Kafka分散メッセージングシステムの構築と活用』。

コメント

コメントの記入