はじめまして。データマネジメントグループ DMPチームの瀧澤と申します。趣味は映画鑑賞と自宅のスマートホーム化です。 ぐるなびではデータ基盤の構築・運用を担当しています。
今回は私が運用しているデータ基盤環境の概要や導入経緯、運用のTipsをご紹介させていただこうと思います。
ぐるなびでの導入経緯
我々のチームのミッションは、社内ビッグデータの一元管理と流動性の向上、データを背景とした新たな価値創造の促進をすることです。
ビッグデータから得られる知見を元に、 食品関連企業様のコンサルティングや新商品の開発などのコラボレーションも展開しています。
ビッグデータ解析のためのプラットフォームとして、数年前に Apache Hadoop（以下Hadoop） を導入しました。
Hadoopでは、各種ぐるなびサービスのデータベースやアクセスログを収集し、各サービス間で垣根なくデータ連携を行える基盤を提供をしています。また、リクエストに応じデータ集計を行い、企画担当者や該当サービスのエンジニアが利用しやすいデータ作成を随時行っています。
過去環境からの変遷
初期の環境は、Hadoop 1系を用いてデータの蓄積およびデータウェアハウスHiveでの分析処理を行っていました。
当時はHA構成ではなかったので、トラブル発生時の運用やバグ対応のコストが高く、本番運用に耐えうる状態ではありませんでした。そのため商用版Hadoopへ移行し、現在 Hadoop 2系 の商用版 Hadoop を オンプレミス で運用しています。
現データ基盤環境の概要
データ基盤環境は、本番、テスト、検証環境の3つを設け、それぞれ以下の用途で利用しています。
- 本番環境 ：本番サービス向け処理を行う
- テスト環境：開発・テストを行う
- 検証環境 ：最新技術の導入・検証を行う
Hadoopのエコシステムを利用
いずれの環境も以下のようなエコシステムを併用して活用しています。
Apache Hive
データウェアハウス構築環境システム。
Hadoop上のデータをRDBのようにSQLライクな言語を用いて処理できます。Apache Spark
Hadoopと同じ分散処理フレームワーク。
インメモリ処理によって巨大なデータの処理速度を高速化します。Apache Tez
Hadoopと同じ分散処理フレームワークであり、 HiveやPigの処理をMapReduceからインメモリ処理に置き換えます。Hue
Hadoopやエコシステムを利用するためのWebUIです。Apache Impala
MapReduceとは異なる、独自の分散処理エンジン。
SQLを用いてHiveの数倍の速度で処理できます。リアルタイム処理はImpalaを、バッチ処理などにはHiveを用いています。
他システムとの連携
ぐるなびの様々なコンテンツに利用されているコンテンツデータのほか、天気データやオープンデータ等の外部データのバッチによる連携を行っています。
また、データの抽出・変換加工・加工済みデータのロードといったETL処理は、既存のETLツールではなく、Hadoopを用いています。
気軽に分析・集計ができる検証環境
検証環境では最新技術を使って手軽に社内データを分析・集計できます。業務でビッグデータをあまり扱うことがないサービス開発者の方々にHadoopを実際に触ってもらい、Hadoopの有用性や新しい技術の利用方法を知り、新規サービスに繋げることを目的としています。
構築作業説明
ここからは、社内データ構築のために行っている作業を説明していきます。
エコシステムバージョンアップ
Hadoop周りのエコシステムのバージョンアップに追従するための作業です。
直近でバージョンアップを行ったエコシステムは Hive, Hue, Sparkです。 これらのアップデートでは一時的にサービスを止める必要があるため、 メンテナンス日時の調整を行っています。 アップデート自体はそれぞれのエコシステム毎にパッケージファイルをインストールし、 最新バージョン用に変更を行った設定を適用していきます。
注意した点〜入念にテストを実施
HiveはVer 1.2 から Ver 2.1 へのメジャーアップデートであったため特別なテスト環境を構築し、Hive用マスターDBのスキーマ更新、 新しいプロパティの設定追加、テストを入念に行いました。 ここについては後ほど「構築作業でハマった箇所」でも触れたいと思います。
マスターノード移行
サーバ性能がボトルネックにならないように、旧マスターノードから、スペックの向上した新ノードに機能を移すのが「マスターノード移行」です。
弊社では複数台のサーバを用いてマスター機能のHA構成にしています。
マスターノード移行作業は、まず初めに移行先となるサーバを一度スタンバイ系のサーバとして設定します。これにより、通常時の倍のHA構成となります。
いったん台数を増やした理由は、平常時より冗長性の高い状態を担保したかったからです。 旧マスターとなるサーバのスタンバイ系プロセスを順次停止しても、 移行作業前以上のサーバ台数構成にしています。最後に残るアクティブサーバのプロセスを停止した時点で移行先のスタンバイサーバにフェイルオーバーが行われ、機能を停止せずにマスターノードを切り替えられます。
また、移行元サーバはスレーブノードとして再利用しています。
- 移行先サーバをスタンバイ系サーバとして追加
- 移行元スタンバイ系プロセスを停止
- 移行元アクティブ系サーバを停止し移行先スタンバイ系サーバへフェイルオーバーさせる
注意した点
サービスを停止させることなく実施する必要があったため、 Hadoop上で動いているバッチの実行時間を確認したところ、 サービスに影響しない時間帯がわずか1日2時間程度しかないことが発覚しました。 このため作業手順の構成に特に注意を払いつつ、作業工程を数日間に分割し取り組みました。
構築作業でハマった箇所
構築作業でハマったポイントを紹介します。
Hiveのバージョンアップに伴うバッチ動作確認
Hiveバージョンアップ前の環境では、100を超えるバッチがあり、 次期バージョンでのバッチ動作確認を行える環境構築が必要となりました。
環境の要件は以下の通りで、イレギュラーな構成となります。
- Hive 1.2 と 2.1 が同一Hadoopクラスタ内で動作すること
- Hive 1.2 と 2.1 で同一データが利用できること
このため、Hive 1.2がインストールされているテスト環境のクラスタで、 既にHive 1.2 が導入されているノードと別のノードに Hive 1.2のマスターDBを元とした Hive 2.1 を導入し、バッチサーバから接続先を変更するだけでHive 1.2 と 2.1 の動作確認を行える環境を構築しました。
またHive 1.2とHive 2.1のパーティション情報等のメタデータを同期させるため、 以下のmsckコマンドを定期的に実行させ環境に差異が出ないよう注意しました。
msck repair table <tablename>
Hiveの認証方式廃止問題
Hive 利用当初からLegacy Mode(hive 1系のデフォルト認証方式)を利用しており、Hive 2.1でも同様の認証方式を引き継いで利用していました。しかし本認証方法がHive 2系では廃止されてしまったため、コミュニティーの最新機能を利用するには認証方式の変更が必要となりました。
現在Hive 2系では以下3種類の認証方式が利用できます。
Storage Based Authorization
Linuxのディレクトリパーミッションに準拠した認証方式SQL Standard Based Hive Authorization
SQLの認証方式に準拠した認証方式Authorization using Apache Ranger & Sentry
Apache Ranger & Sentry等のセキュリティフレームワークを利用した認証方式
弊社環境ではSQL Standard Based Hive Authorizationに変更したのですが、Legacy ModeとSQL Standard Based Hive Authorizationでは設計が大きく異なります。
設計の違いに対応するため、以下の設定を実施しました。
権限付与
認証切り替え以前はユーザ単位で権限管理を行っていましたが、ロール単位での権限管理に変更し、利用者にテーブル作成時にロールへ権限を付与する運用を策定しました。
なりすまし機能
実データのディレクトリ権限がHiveServer2プロセス実行ユーザとなるため、過去作られたデータのオーナーをプロセス実行ユーザに変更し、対応が難しいものについてはセキュリティに影響のない範囲でパーミッションを変更しました。
コマンド
CREATE FUNCTIONは、処理に必要なFUNCTIONをADMINユーザにて事前にデータベースへ登録し、CREATEせずにFUNCTION実行できる設定に変更。
ADDについてはHiveServer2にADD対象ファイルのパスを設定し、CREATE FUNCTIONと同様にコマンドを実行する必要がない状態に変更しました。これにより既存ジョブに対する改修コストを抑えられました。
ただ、対象ファイルを追加する際に上記設定を行う必要があるため運用コストは増加しました。ですが、ファイル追加作業は多くないため全体では作業効率が上がっています。
日々の運用
クラスタの運用について
日々のクラスタ監視ではGrafanaのグラフによるリソース推移の監視、 HadoopとHiveのポート監視、dstatコマンドによるリアルタイムなリソース監視を行っています。
Hadoopの処理リソースについては基本的に制限は行わずに運用していますが、 最低限のリソース確保が必要なもののみフェアスケジューラーを用いて、 特定のキューを指定する方法でリソースの担保をとっています。
自作のコンフィグ自動更新ツールによってファイル展開を容易にする
複数のサーバへコンフィグファイルを展開するにはPuppetやChef等の設定管理ツールを利用することが多いと思いますが、内製のコンフィグ自動更新ツールを利用しています。
この自動更新ツールは、Gitで管理しているHadoop用コンフィグファイルをマスターノードからクラスタの各ノードに展開し、 ノードごとに必要なエコシステムのコンフィグファイルを差分に応じて適用します。 このツールによって当初手動で時間をかけて行っていた作業が、ものの数分で終了するようになりました。 こういった便利ツールを作成し日々の運用に役立てています。
今後の展開
今後の環境
格納データ量及び利用者増加に伴うマルチテナント化対応
マルチテナント化対応することで複数のグループが分析基盤としてHadoopを利用することができるHadoop及びエコシステムのバージョンアップ
バージョンアップすることで分析者に安定した環境を用いて最新の処理を行うことができる
私の抱負
より良いデータ基盤環境運用のために、以下にも取り組んでいきたいです。
- ユーザ及び権限管理の効率化
- エコシステムの環境最適化
- データを横断的に利用するためのエコシステムユースケース作成
お知らせ
ぐるなびでは一緒に働く仲間を募集しています。
