2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「DEVDAY2021 アフターインタビュー」では、発表内容をさらに深堀りし、発表では触れられなかった内容や裏話について登壇者たちにインタビューします。今回の対象セッションは「大規模なHDFS Erasure Codingにおける技術的課題」です。
LINEのData Platform室では、LINEのさまざまなサービスのデータをApache HDFS（以下、HDFS）に格納しています。HDFSクラスターに保存されているデータ量は、合計で数百ペタバイトと極めて膨大。だからこそ、データの保管にかかるインフラコストを削減することは、Data Platform室の重要な役割のひとつです。
HDFSにはErasure Codingという機能があります。これはHDFS3.0で導入された比較的新しい機能であり、デフォルトのレプリケーション方式と比べて、はるかに少ないストレージスペースでデータを格納できるという利点があります。そのためData Platform室でも、特定のデータにErasure Codingを適用しています。
しかし、Erasure Codingには特定の条件下で発生する不具合があり、LINEでもその事象に直面しました。Data Platform室のエンジニアたちは原因を特定しコード修正をすることで、OSSへのコントリビューションを行いました。セッションで語られた内容の裏話を、Data Platform室の内田早俊が解説します。
Erasure Codingのリコンストラクションに生じていた不具合
――Data Platform室の役割や内田さんの業務内容を教えてください。
Data Platform室はLINEという会社全体をデータドリブンな組織にするために、Information Universe（以下、IU）というセルフサービスなデータプラットフォームを開発・運用している組織です。私はその中のIU Tech Forwardチームに所属しており、IU全体の技術的な改善をミッションとして業務に従事しています。
――「LINE DEVELOPER DAY 2021」のセッション内で内田さんは、2020年末にデータコラプションの問題が発生したことを解説されていました。この概要について教えてください。
最初は、ユーザーからの報告を受けたことをきっかけとして問題が発覚しました。この事例は、ユーザーがErasure CodingされたORCファイルをHiveから読み込もうとしたときに、エラーが発生したというものでした。
ユーザーから報告された内容だけでは、HiveやORC、Erasure Codingといった各コンポーネントのどの箇所で問題が起きているのかが判別できなかったため、Erasure Codingされたすべてのファイルを調査することにしました。幸いにも、同様のエラーが発生するErasure CodingされたORCファイルのなかにバックアップが残っているものがあったため、そのファイルの9つあるブロックを一つひとつ比較しました。
すると、特定のブロックだけビット列が異なっていることが判明しました。ブロックの履歴をデータノードのログから辿ったところ、過去にリコンストラクションされており、かつ直前のリコンストラクションでNullPointerExceptionが発生していたことがわかりました。
これらの情報をもとに、Erasure Codingのリコンストラクションの処理に問題がありそうだと判断したのです。さらに調査を進めたところ、HDFSのコミュニティが管理しているJira上に、私たちの事象と非常に類似したOpen Issueがあるのを発見しました。
――どのようなIssueだったのでしょうか？
HDFSにおいて、データノード上でのリコンストラクションのメインロジックを担っているStripedBlockReconstructorというクラスは、スタティックに持っているバッファープールをリコンストラクションの際に使っています。
このIssueには、特定の条件下でバッファープールが汚染されてしまうことと、汚染されたバッファープールが原因でリコンストラクションされたブロックが壊れてしまう問題があることが記述されており、私たちの調査に役立ちました。
――この調査において原因を究明するために工夫されたことはありますか？
この事例に限らず、何か問題が起きた際にはまず原因の仮説を立てることになります。そして、仮説を立てるためにはさまざまな情報が必要です。データを収集するための方法を検討するところから、調査がスタートしました。
Data Platform室ではHadoopだけでも2,000台以上のサーバーを管理・運用しています。もともと、それらのサーバーのデーモンログをアーカイブしてはいたものの、分析できる状態にはなっていませんでした。そこで、分析可能なフォーマットにログを整形して、その情報をもとに壊れたブロックの履歴情報を追いました。
このような手順を踏んで、調査には非常に時間がかかりましたが、その甲斐あって原因を特定し修正パッチを当てることができました。エラー発生原因の詳細やコード修正の内容などはセッションの動画で解説していますので、よろしければご覧ください。
扱うデータ量が膨大だからこそ遭遇する課題がある
――パッチを当てた後のことを教えてください。
この事例においてはパッチを当てればそれで終わりというわけではなく、さらに2つの課題を解決する必要がありました。前述の不具合を解消したことで本当にデータコラプションが起きなくなったかどうかを監視すること、そして別の種類の不具合が原因でデータコラプションが発生するのを防止することです。
1つ目の「データコラプションが起きなくなったかどうかを監視する」という課題は、Erasure Codingされたファイルのチェックサム値を、Sparkを使って日次でHiveテーブルに保存し、その値を用いて整合性を確認する方針にしました。ところが、実装はすぐに終わったものの、実際にジョブを走らせてみると予期せぬ不具合が2つ起きました。
Erasure Codingされたファイルのチェックサムを取得する際にデータノード上でファイルディスクリプタのリークが起きるという不具合と、誤ったチェックサムの値が返されるという不具合です。いずれも原因を特定したうえでData Platform室のエンジニアがパッチを書き、現在はHDFS本体に取り込まれています。こちらも詳細を知りたい方はセッションの動画をご覧ください。
――パッチを作成するにあたり、設計や実装で工夫したことはありますか？
正直なところ、パッチ自体はそれほど大きな修正ではありませんでした。例外発生時の処理を変更するくらいのシンプルな対応です。むしろ、この事例も先ほど述べたバッファープール汚染の事例と同じように、コード修正よりも調査や原因の特定に時間がかかりました。
もし運用しているHDFSの規模が小さい組織であれば、ファイルディスクリプタのリークが起きていたことに気づけなかった可能性が高いと思います。データ量が少ない場合はリークの増加量も緩やかであるため、なんらかの問題が表出するよりも前に、ローリングリスタートなどによってリークした情報が初期化されてしまうからです。
Data Platform室のように大規模なHDFSを運用している場合は、扱っているファイル数が尋常ではないため、1つのデータノードが落ちただけでも大量のリコンストラクション処理が走ります。そのため、ファイルディスクリプタのリーク量が急激に増加し、問題が表出してしまいます。つまりこのような事例は、大量のデータを扱うLINEで働くからこそ、積むことのできた貴重な経験だったと言えます。
また、「今後どのようにしてデータコラプションを防ぐのか」という2つ目の課題に関しては、リコンストラクションの正しさをチェックするためのバリデーションロジックを実装することで対応しました。このパッチもHDFS本体に取り込まれています。
難易度の高い問題に挑みたいエンジニアにとっては最高の環境
――記事の読者には「今回の事例のように、Hadoop本体へのコントリビューションをしてみたい」と考える人もいらっしゃると思います。Hadoopの理解を深めるには、どのような学習をすることをすすめますか？
エンジニアのスキルにもよるので一概には言えませんが、まだHadoopにそれほど慣れ親しんでいない方であれば、まずはHadoopの各種機能に触れてみてください。規模は小さくても構いませんからHadoopクラスターを自分で構築して、実際に各種のオペレーションをしてみましょう。挙動を把握したうえで、サービスのデーモンログを読んだり本体のソースコードを読んだりすると、内部的な処理の理解を深められるはずです。
少しずつ自信がついてきたら、GitHubのHadoopのリポジトリにはたくさんのOpen Issueがありますから、手をつけやすそうなものを探して対応してみてください。Hadoopのコミュニティでは活発に議論や活動が行われていますから、Pull Requestを出せば必ず誰かが丁寧にレビューをしてくれるので、コードへの理解や品質を高める助力となります。
――最後にData Platform室で働く醍醐味について教えてください。
先ほどの話と重複しますが、やはりData Platform室では扱うデータの種類が多種多様であり、かつデータの規模も非常に大きいことが一番の魅力だと考えています。
そういった環境で働いていると、世界的に見ても珍しい問題に遭遇します。深く調べなければ原因が究明できないような難易度の高い問題ばかりですが、その困難さを乗り越えることは非常にやりがいが大きく、エンジニア冥利につきます。今回の記事を読んで私たちの業務に興味を持ってくださった方は、ぜひ一緒に働いていただけると嬉しいです。
採用情報
LINE株式会社では一緒に働くエンジニアを募集しています！
今回のインタビューと関連する募集ポジションはこちらです。