マルチテナント利用を実現する 大規模データ分析共通基盤の構築 井ノ口 裕也＊ 三屋 誓志郎＊ 福島 慎一＊ 渡邉 健太＊ 埋金 進一＊＊ Construction of Large-scale Data Analysis Base to Realize Multi-tenant Use 要 旨 近年，コンピュータシステムの扱うデータ量は増加の一 このような中，三菱電機インフォメーションシステムズ 途を辿っており，膨大なデータを活用し，新たな価値を生 (株)（MDIS）と（株）ノーチラス・テクノロジーズは，高 み出すことが脚光を浴びてきている。 速化や高信頼性に加えてマルチテナント運用向け機能を持 これらのデータを扱う手段の一つとして Google(注 1)社の つ Hadoop ディストリビューションである MapR(注 3) (1)を用 論文(2)をベースにオープンソフトウエア（Open Source いて複数用途を共存させるマルチテナント構成による運用 Software:OSS）として実装された Hadoop(注 2)がある。 方法の確立に取り組んだ。 Hadoop は複数マシンでの分散処理を実現でき，従来のデー 専用サーバを割り当てる構成か，あるいはマルチテナン タベース，データウェアハウスでは取り扱うことができな トで共有する構成かを選択可能とするなど，テナント要件 かったデータ量を扱うことができる。さらに分析の用途が に沿って柔軟な構成を実現している。また，ログ運用，ア 増加するにつれ，Hadoop クラスタを共用するニーズが発生 プリケーションの制限事項の設定，クラスタ拡張のための したが，既存の Hadoop ディストリビューション（Hadoop 本 情報収集などの運用方針を整理した。MDIS では，本実績を 体と利用に必要なアプリケーション等をまとめたもの）で 元に，2015 年 6 月より『MapR クラスタ構築サービス』の は用途毎のリソース管理にいくつかの課題があった。 提供を開始している。 マルチテナント対応大規模データ構築基盤 大規模データ構築基盤をマルチテナント対応として構築したシステム構成図である。テナント毎にクラスタの一部を占有またはマルチテナントによ るリソース共有といった，テナントの要件に沿った柔軟な構成を取ることが可能なシステムとなっている。 (注 1) Google は Google Inc.の登録商標である。 (注 2) Hadoop は Apache ソフトウェア財団の米国及びその他の国における登録商標である。 (注 3) MapR は MapR Technologies の米国およびその他の国における登録商標である。 *三菱電機インフォメーションシステムズ（株） **（株）ノーチラス・テクノロジーズ １． ま え が き (3) 耐障害性の不足 多くのテナントでの利用を展開するには，極力システム 近年，コンピュータシステムの扱うデータ量は増加の一 停止を伴わない運用が必要であり，耐障害性の向上は必須 途を辿っている。今までは処理しきれずに捨てていたデー である。既存の Hadoop ディストリビューションの標準構 タを活用し，新たな価値を生み出すことが，ビッグデータ 成では単一障害点が存在するため,Hadoop ディストリビュ の取り組みとして脚光を浴びてきている。その基盤として ーション以外のミドルウェアなどを利用して，独自に多重 複数マシンでの分散処理を実現する Hadoop の構築を行う 化構成を構築する必要があった。 企業が増加している。 サーバ数が数十台，データ量が数百ＴＢ(terabyte)の大 規模データ分析基盤構築に際して，企業内の複数の部門が (4) Hadoop 固有 API(Application Programming Interface)のみの提供 既存の Hadoop ディストリビューションでは大規模デー 共有して利用すること（マルチテナント運用）によるコス タを扱うインタフェースとして HDFS（Hadoop ト削減やリソースの有効活用が求められるが，既存の Distributed File System）（注 4）インタフェースしか提供 Hadoop ディストリビューションでは複数アプリケーション されず，データアクセスの処理を新たに作りこむ必要があ 間のリソースの競合を抑制する機能や，利用部門（テナン った。 ト)毎のディスク使用量を制限する機能が不足しておりマ ルチテナント運用を行うことが困難であった。 この問題を解決するため，MDIS では既存 Hadoop と完全 （ 注 4 ） Hadoop が 利 用 し て い る 分 散 フ ァ イ ル シ ス テ ム 。 OS （Operating System）のファイルシステムを代替するものではなく， 互換で，マルチテナント運用向け機能を持つ Hadoop ディ その上に独自のファイル管理システムを構築するもので，アプリケー ストリビューションである MapR(1)を用いてマルチテナント ションからローカルファイルと同様のインタフェースでアクセスする 設計及び運用設計を行った。 ことはできない。 本稿では，従来の Hadoop ディストリビューションでの ３． 目標とするマルチテナント要件 課題について述べ，その課題を解決するために実現すべき マルチテナント機能を定義した上で，その実現に向けたマ Hadoop の商用ディストリビューションである MapR は， ルチテナント設計のポイントを説明する。 高速化や高信頼性に加えてマルチテナント運用向け機能を さらに，運用上の留意事項についても述べる。 保有していることを特徴としている(1)。MapR を用いて， 以下(1)～(3)のマルチテナント要件を満たすことを目標と ２． 従来の大規模データ分析基盤の課題 既存の Hadoop ディストリビューションでは，以下(1)～ して，従来の課題を解決することに取り組んだ。 (1) マルチテナントに対して，テナント毎にデータ管 (4)に示す課題があり，複数部門で大規模分析基盤を共有 理機能を持たせて，かつ利用サーバを分離できる Hadoop 利用するマルチテナント運用を行うことが難しい状況にあ システムを提供する。 った。 (1) テナント毎のディスク使用量制限機能の欠如 テナント毎のディスク使用量を制限できず，特定テナン トによる大量データ利用が他テナントに影響を及ぼす可 能性がある。 (2) マルチテナント機能を，単一クラスタ上に構築する。 (3) データアクセスの分離とテナント間のリソースの利 用を MapR および Linux（注 5）の標準機能で構築する。 （注 5）Linux は米国及びその他の国における Linus Torvalds の登録商 標です。 (2) テナント間でのリソースの競合による処理の遅延 クラスタを構成する全てのサーバに分散してデータを蓄 ４． マルチテナント設計のポイント 積し，全てのサーバで処理を実行する構成のみの実装とな っている。この方式は全サーバのリソースを有効に活用で 4.1 前提条件の設定 きる点では有利であるが，複数処理の同時実行によりリソ まずはマルチテナントを利用する範囲や利用するユーザ ースの競合が発生する可能性があり処理時間の見積もりが を定義した。システム設計・運用設計において要件の発散 難しい。確実に規定時間内に処理を完了させるためにはリ を排除するために重要なプロセスであるため，設計の初期 ソースの競合が発生しないようにテナント間で利用サーバ 段階で検討を行った。 を分離する必要があるが，既存の Hadoop ディストリビュ ーションでは，利用サーバを分離するために複数の Hadoop クラスタを構築する必要があった。 (1) マルチテナントを利用する範囲の設定 今回構築したシステムは，企業内の社内利用であり，部 門やプロジェクト毎に 1 テナントずつを割り当てる想定で 設計した。社内ネットワークで接続され，ユーザは提示さ 安定した性能が求められる場合に選択する。 れたルールを守ることを前提としたため，ルール無視のユ （ⅱ）共有構成 ーザの誤使用を排除する対策等は実施していない。 マルチテナントでサーバを共有する構成である。リソース (2) マルチテナント運用に係る役割の明確化 次に，運用にかかわる登場人物の役割（ロール）とそれ ぞれが利用できる機能を定義した。 を効果的に活用できるが，競合により性能面の保証が出来 なくなる。応答性能の要件が高くない場合に選択する。 それぞれの構成における比較を表１に示す。 具体的には設定ファイルの変更やリソースの払い出しが 可能なインフラ担当者，クラスタの通常運用を行う MapR 運用者，テナント側の接続環境を構築するテナントインフ ラ担当者，ファイル I/O やアプリケーション実行が可能な テナント利用者である。 4.2 マルチテナント機能実現方式 ２章で述べた従来課題（1)～(4)を解決すべく採用した マルチテナント機能実現のための具体的な方式を以下に述 べる。 (1) テナント毎のデータアクセス制限の設定 テナント毎に利用可能ディレクトリを割り付け，アクセ ス権を適切に設定することによりテナント間のデータアク セスを分離した。従来の Hadoop 機能でもこのデータアク セスの分離までは実現可能であるが，クラスタ全体のスト レージを１つのファイルシステムとして扱っているため， テナント毎のデータ使用量を制限することはできなかった。 MapR では「ボリューム」という概念でファイルシステムを 分割管理しており，ボリューム毎にディスク使用量の上限 値を設定できる(1)。これにより，ボリュームをテナント毎 のディレクトリに割り付けることでテナント毎のデータ使 表 1．分離構成と共有構成の比較 項目 分離構成 共有構成 他テナントへの ほとんどない 性能，容量面で 影響 影響がある。 小規模なリソー 最低でも 3 台分 小規模なリソー スの割り当て のサーバリソー スを割り当て可 スを割り当てる 能 必要がある。小 規模なリソース 割り当ては不 可。 テナント追加 専用サーバを確 既存リソースに 保する必要があ 余裕があれば， り共有構成と比 分離構成と比べ べて，工数と時 て容易 間が大きくかか る。 クラスタ構成 １クラスタ（注 １クラスタ 6） (注 6）既存の Hadoop で分離構成相当の機能を実現するには，テナント 間のリソース競合を回避するためにテナント毎に別々のクラスタを構築す る必要があった。本設計では１クラスタ構成でテナント間のリソース競合 を回避できるため，既存の Hadoop に比べコスト削減となる。 また，分離構成と共有構成のイメージを図 1 に示す。 用量を制限することを可能とした。また，MapR では，ボリ ューム毎にスナップショットを生成する機能を有しており (1) ，ユーザがデータ処理で誤操作をした場合の復旧手段と してテナント毎にこの機能を提供することとした。 (2) テナント間の利用サーバの分離 従来の Hadoop では，各テナントの利用サーバを分離す るためには複数のクラスタに分割した構成にする必要があ った。以下に示すように，MapR の持つ機能を適切に組み合 図 1. 共有構成と分離構成 わせて活用することにより，単一のクラスタ構成でノード (b)分離構成の実現方式 間の分離を柔軟に行う事を可能とした。 分離構成を実現するには，テナント間で，データの分離 (a)分離構成と共有構成の定義 と処理の分離を実現する必要がある。構築したシステムで 今回構築したクラスタでは，リソースを割り当てる構成 は，MapR の「ボリュームトポロジー」機能(1)と「ラベル」 として次の（ⅰ）,（ⅱ）の 2 種類の構成を定義し，テナ 機能(1)を組み合わせることにより，分離構成を実現してい ント毎にこれらを選択できかつ共存できるよう設計した。 る。それぞれの説明を以下（ⅰ），（ⅱ）に示す。 利用するアプリケーションの要件に応じてどちらを選択す （ⅰ）ボリュームトポロジー るかを決定する。 「ボリュームトポロジー」機能を用いてデータの分離を （ⅰ）分離構成 行った。「ボリュームトポロジー」は，ボリュームのデー １つのテナントに対して専用サーバを割り当てる構成であ タをどのサーバに格納するかを設定する機能である。各テ る。他テナントとのリソース競合を回避出来る構成であり， ナントのデータの保存位置を分離したサーバ内に限定する ことでディスク I/O，ネットワーク I/O の競合による性能 劣化を防止する。 (4) API の拡張 本実現方式では，ファイルシステムに対し，従来の （ⅱ）ラベル Hadoop インタフェースに加えて NFS（Network File 「ラベル」機能を用いて処理の分離を行った。「ラベル」 System）（注 7）で接続する機能を提供している(1)。UNIX（注 8） は，アプリケーションを実行するサーバをグループ化する ファイルシステムと同様の操作でデータ入出力することが 機能である。テナント毎に，アプリケーションを実行する でき，多くの既存アプリケーションをそのまま利用するこ サーバを特定ラベルを付けたサーバに限定することで とが可能である。 CPU( Central Processing Unit),メモリの競合による性能 劣化を防止する。 ボリュームトポロジーとラベルのイメージを図 2 に示す。 NFS の構築においては，Hadoop インタフェースと同様に アクセス権を設定してテナント間のアクセス権の分離を実 現している。また，NFS ゲートウェイサービスを行うサー バをテナント毎に分散して割り付け，さらにそれぞれのマ ウントポイントに接続可能なクライアントマシンを制限す ることで負荷分散とセキュリティ向上を実現する設計とし た。 （注 7）主に UNIX 系 OS (Operating System)で利用される分散フ ァイルシステム。サーバのストレージをネットワーク経由でマウント することによりローカルファイルと同様にアクセスすることができる。 (注 8）UNIX は，The Open Group の米国ならびに他の国における登録商 標です。 図 2. ボリュームトポロジーとラベルによる分離 ５． マルチテナント運用上の注意点と対応策 上記に示すように，本設計での分離構成では，MapR の設 定を変えることによりクラスタ内の物理的なサーバ台数を 5.1 変化させずに，テナントが利用するサーバ台数を変化させ 各テナントのアプリケーション実行における障害発生時 ることができる。この妥当性を確認するために，分離構成 等での問題の解析・解決のためにテナントへログを提供す の設定により利用可能サーバの台数を変化させた場合と， る。ログ提供においてもテナント間のアクセス権の分離が 物理的にクラスタ内の接続サーバ台数を変化させた場合で 必要であるが，テナント間のアクセス権の分離ができない のベンチマークテストプログラムの応答性能の比較を行っ ログもあり，ログの種類により以下(1)，(2）の運用とし た。結果，両者でほぼ同等の結果を得ることができ，分離 た。 構成により有効にリソース分離ができていると考えられる。 (3) 耐障害性の向上 マルチテナントに対して安定した運用を提供するために， ３重化冗長構成として２重までの障害に耐えうる構成とし ログの運用 (1)OS のログ，MapR デーモンのログについては，テナン ト毎の分離が不可能なため，テナントにはそれらのログは 公開せず，テナントの要請によりシステム管理者側でログ 内容を確認する運用とした。 ている。２台以下のサーバ，２台以下のハードディスク， (2)アプリケーション実行時のログについては，他テナ ２つ以下の管理サービスの同時障害が発生してもシステム ントがログをアクセスできないようにアクセス権を設定し 停止が起こらないように設計した。これは，ファイルのレ た上で各テナントから参照可能とした。なお，ログはクラ プリカ数（多重度）を“３”にすること，各管理サービス スタ内で散在しており参照処理が煩雑であるため，MapR を３重化構成にすることにより実現している。前者は既存 の持つ集中ロギング機能(1)を活用して，テナントへの利便 の Hadoop から有する機能，後者は MapR が提供する機能で 性を図っている。 ある (1) 。また，管理サービスの配置設計においては，各管 理サービスを別ラックのサーバに分散させることにより１ 5.2 テナント運用形態の選択 新たにテナントを追加する際，テナント間のリソースの ラック全体障害発生時のシステム停止を回避するために， 分離を適切に実現するために，分離構成とするか，共有 分離構成を構築するサーバでは管理サービスを動作させな 構成するかを決める必要がある。 い構成として分離構成利用テナントとそれ以外のテナント 追加テナントに対して，リソース容量，利用する機能， 間で管理サービスに伴う影響を最低限にする等の構築上の アプリケーションの特殊要件等のヒアリング項目を明確に 工夫を行っている。 し，どちらの利用形態が適しているかを判別できるように した。基本的には他テナントへの，または他テナントから の影響度により判断する。 5.3 共用構成における運用方針 (1) クラスタのチューニング方針 基準を策定した。 主な監視対象は以下の 5 点であり，これらを定期的に監 視することとした。なお，これらが拡張基準となる閾値を 超えた際にはクラスタの拡張を検討することとしている。 共有構成ではどのようなアプリケーションが動作するか の予測が不可能であるため，パラメータは最も汎用性があ ・CPU 利用率（サーバ毎） るデフォルト値を採用した。なお，個別チューニングによ ・メモリ利用率（サーバ毎） る応答性能の向上が必要なテナントについては分離構成を ・ディスク I/O （Input/Output）（サーバ毎） 選択することでパラメータのチューニングを可能としてい ・ネットワーク I/O（サーバ毎） る。 ・ファイルシステム利用率（全体，サーバ，ボリューム毎） (2) アプリケーションの制限ルールの設定 ６． む す び 共有構成においては，サーバのリソースを有効に利用で きるメリットはあるが，サーバを共有するテナント間での 今回，MapR を利用して，データ用ディスク数百 TＢ規模 リソースの競合が発生する可能性が高くなる。通常は， のマルチテナント向け大規模データ分析基盤を設計・構築 Hadoop の機能で，リソース利用はテナント間で適切に制御 することができた。これまでは，この規模のシステムを単 されるが，アプリケーションの利用方法によっては， 一テナントでしか利用できなかったが，本マルチテナント Hadoop では制御しきれないケースがある。そのため，他テ 設計を用い，ログの分析システムと IoT（ Internet of ナントに影響を与えないようにするアプリケーションの制 Things）関連データ処理システムの２つの大容量データ処 限ルールを定めた。具体的には， Linux 上の別アプリケー 理テナントを同一プラットフォームで稼動させる運用を ションを起動する場合の使い方の制限や一時ファイル等の 2015 年 4 月より開始している。また，本ノウハウを活用 出力先としての Linux ローカルのファイルシステムの利用 して 2015 年 6 月より『MapR クラスタ構築サービス』を開 禁止等である。 始している。今後，今回開発した大規模データ分析基盤の 5.４ アラートの監視 MapR では問題を検知した際にアラートを発生させるが， 運用に際して，特定テナントにのみ影響があるかクラスタ 技術をベースとして様々な適用分野を探って行くと共に， データ分析のためのアプリケーションの拡充を図って行く 予定である。 全体に影響があるかを判別することが難しい。 発生する可能性のあるアラートをリスト化し，運用時に 影響範囲を判断できるようにガイドを作成した。 5.5 クラスタの拡張方針の策定 マルチテナント運用を継続するには，運用中のテナン トの処理量・データ量の増加や新規テナントの追加に備 えてクラスタの拡張を検討する必要がある。拡張検討の ために，日々の運用で，監視対象とするリソースと拡張 参 考 文 献 (1) MapR 公式ドキュメント http://doc.mapr.com/display/MapR3/Home (2) MapReduce: Simplified Data Processing on Large Clusters (Dean, J. and Ghemawat, S. 2004)
© Copyright 2024 ExpyDoc
