現在位置: ホーム / ゲストブログ / [第3回]Linux/OSS エヴァンジェリスト古賀政純の ”旬”のオープンソースソフトウェア~Apache Mesos(前編)~

[第3回]Linux/OSS エヴァンジェリスト古賀政純の ”旬”のオープンソースソフトウェア~Apache Mesos(前編)~

今回のゲストブログは、日本ヒューレット・パッカードが公式に認定するオープンソース・Linuxテクノロジーエバンジェリストの古賀政純さんです。 前回、大好評だったSparkに引き続き、今回から2回にわたって、『次世代の計算資源管理ソフトウェアApache Mesosに迫る』と題して、資源割り当ての自動化ソフトウェアであるApache Mesosについて取り上げます。様々な商用の資源管理ソフトウェアが存在する中、オープンソースソフトウェアのApache Mesosに注目が集まっています。 この最近の話題のSparkやDockerとの連携を意識したApache Mesosとは、一体何者なのでしょうか?そして、Mesosを導入することによって、どのようなIT基盤になるのでしょうか?前編となる今回は、過去から存在する資源管理ソフトウェアも紹介しながら、Apache Mesosを紹介します。後編では、Apache Mesosのインストール手順、基本的な使用法を簡単に紹介します。(2015年10月14日)


次世代の計算資源管理ソフトウェアApache Mesosに迫る(前編)

■計算資源を有効利用するハイパフォーマンスコンピューティング

皆さんは、ハイパフォーマンスコンピューティング(High Performance Computing=HPC)という言葉を知っていますか?ハイパフォーマンス=高性能ですから、高性能な計算を行うシステムのことを指します。スーパーコンピューターや科学技術計算サーバーを駆使した超高速な計算処理などは、ハイパフォーマンスコンピューティングとよばれ、英語の頭文字をとって一般的に「HPC」と呼ばれます。

前々回の記事でご紹介したように、筆者は、学生時代に、人間の脳神経を模倣したコンピュータープログラムである「ニューラルネットワーク」を使ってシミュレーションの計算を行っていましたが、これらのコンピュータープログラムは、パソコンで稼働させていたわけではなく、エンジニアリング・ワークステーション(通称EWS)や、旧Digital Equipment Corporation(現Hewlett Packard Enterprise)の64bitのAlphaと呼ばれる高速演算用のCPUを搭載したHPC向けのマシンで稼働させていました。

1990年代、研究室では、これらのHPC向けのAlphaマシンや、一人1台以上のEWSを湯水のように使える恵まれた環境でしたので、いつでも自分の作ったソフトウェアをHPC向けのマシンで実行させることができました。しかし、筆者自身が、高速計算用のサーバーシステムをお客様に提供する立場になり、配属後まもなくお客様先に訪問した際、驚愕の事実を知ることになります。それは、

「1台から数台の高速計算用マシンを複数の研究者・開発者が奪い合うように相乗りして使っている」

という光景を目の当たりにしたのです。学生時代に湯水のように使っていたコンピューターシステムとは真逆で、複数の研究者や開発者が、限られた高速計算用のコンピューターシステムを最大限に有効利用するための仕組みが整備されていたのです。

例えば、ユーザー毎にコンピューターを利用する時間を決める仕組みや、業務の優先順位に応じて稼動させていたソフトウェアを一時的にサスペンドし、優先順位の高いソフトウェアの実行を割り込ませる、あるいは、ソフトウェアを実行させるコンピューターを明示的に選択するなど、コンピューターシステムの利用を「計算資源の有効利用」とみなしていたのです。 

占有 ・争奪型 vs. ジョブ管理による計算資源の有効利用
図1. 占有 ・争奪型 vs. ジョブ管理による計算資源の有効利用

このような計算資源の有効利用という発想がなぜ生まれたのでしょうか?

1990年代のコンピューターは、今に比べてCPU性能も低く、少ないメモリ容量でしたので、非力なCPUや少ないメモリをいかに大人数で有効利用できるかが勝負でした。HPCの分野におけるコンピューター資源の有効利用という観点では、コンピューターシステムのアーキテクチャが深く関係しています。HPCの分野では、どれだけ高速な計算ができ、かつ、大容量のメモリにどれだけデータを効率よく載せて処理できるかがキーとなります。

コンピューターは、大きく分けて、2種類に大別できます。共有メモリ型と分散メモリ型です。共有メモリ型は、複数のCPUコアが単一のメモリ領域を共有することからそのような呼び方が一般的にされています。HPCの世界では、非常に高速なマルチコアが搭載されたシステム1台(一般的には、SMPマシンと呼ばれます)を意味します。

それに対し、分散メモリ型は、計算処理を行うx86サーバー(HPCの世界では、一般的に計算ノードと言います)を何十台、何百台もならべ、一つのクラスターとして稼働させます。メモリ領域が計算ノードごとに分かれるため、分散メモリ型と呼ばれるのです。分散メモリ型は、クラスター構成をとりますので、一般的にHPCクラスターと呼ばれます。これらの共有メモリ型マシンや分散メモリ型のHPCクラスターを使うことで、大規模なシミュレーションや、ニューラルネットワークによる学習、自動車の衝突解析など、人間の手計算ではとても行うことができない膨大な計算を高速に行うことができます。

しかし、共有メモリ型と分散メモリ型では、プログラミングに大きな違いがあります。共有メモリ型マシンでは、1台のコンピューターで動くプログラミングをすればよいのですが、分散メモリ型のシステムでは、複数の計算ノードが協調して稼働するようにプログラミングしなければならず、共有メモリ型に比べて非常に複雑なのです。

そのため、利用者としては、共有メモリ型でプログラミングしたほうが楽であるため、分散メモリ型のプログラミングを習得する余裕のない開発者や研究者が共有メモリ型マシンに殺到するという事態が起きます。一方、分散メモリ型のシステムにおいては、計算ノードを追加すればするほど、性能が向上するという特性があるため、自分が使うソフトウェアをできるだけ多くの計算ノードで実行させようとするため、計算ノードの取り合いになるのです。

このため、多くの企業や研究機関では、共有メモリ型のシステムや分散メモリ型のシステムにおいてユーザーのアプリケーションに対するジョブ管理システムが導入されており、共有メモリ型であれば、時間貸しでの利用、分散メモリ型であれば、全体のうちの一部のノードをユーザーに自動的に割り当てるなどの運用が行われています。

クラスターのクラスター、グリッドコンピューティングへ
図2.クラスターのクラスター、グリッドコンピューティングへ

Apache Mesos登場以前の資源管理ソフトウェアを知る

共有メモリ型のSMPマシンや分散メモリ型のクラスターにおける「計算資源を有効活用」の仕組みは、どのように実現されているのでしょうか?

ビッグデータの世界の方なら、HadoopのYARN、Dockerユーザーの方なら、Apache Mesosと言われるかもしれませんが、実は、YARNやMesosが登場する遥か以前から利用されているソフトウェアがあります。代表的なものとして、Altair社のPBSPro(ピービーエス・プロ)、IBM社のLSF(エル・エス・エフ)、Univa社のUniva Grid Engine(ユニバ・グリッド・エンジン)、そして、オープンソースソフトウェアのTORQUE(トルク)とMaui Cluster Scheduler(マウイ・クラスター・スケジューラー)などが存在します。

これらは、ワークロードのスケジューリング、ジョブの実行、サスペンドなどを実現する計算資源の管理ソフトウェアです。ユーザーは、使用したいCPUコア数やメモリ容量などを指定し、自分が実行したいアプリケーションをジョブとして資源管理ソフトウェアに登録します。資源管理ソフトウェアは、空いている分散メモリ型マシンや計算ノードを選択し、適切に計算資源を割り当てます。このような仕組みのおかげで、限られた計算資源を複数のユーザーで効率的に利用することができます。

計算資源の管理ソフトウェアの機能は非常に豊富ですので、簡単に比較表にまとめることが難しいのですが、知っておくべき最低限の情報をざっくりと比較表としてまとめておきましたので、参考にしてみてください。

資源管理ソフトウェアをざっくり比較してみる
図3. 資源管理ソフトウェアをざっくり比較してみる

また、表にあげた各管理ソフトウェアの動作環境に関する情報源のリンクも示しておきます。

PBSPro:
http://www.pbsworks.com/Product.aspx?id=18

LSF:
http://www-03.ibm.com/systems/platformcomputing/products/lsf/#show-hide

Univa Grid Engine:
http://www.univa.com/resources/files/Release_Notes_Univa_Grid_Engine_8.3.0.pdf

TORQUE:
http://docs.adaptivecomputing.com/torque/5-1-0/help.htm#topics/hpcSuiteInstall/manual/1-installing/installingTorque.htm#req

歴史のあるオープンソースの資源管理ソフトウェア「TORQUE」を少しだけ紹介

オープンソースのTORQUEの例をあげてみます。とある共有メモリ型のコンピューターシステムが存在し、64コアのCPUと128ギガバイトのメモリを搭載しているとします。そのコンピューターシステムにおいて、ユーザーが実行したいHPCアプリケーション(myprog)があったとします。もし、TORQUEが存在しない環境の場合、ユーザーは、以下のようにコマンドプロンプトからHPCアプリケーションmyprogを直接実行するはずです。

$ ./myprog

もし、myprogが64コアのCPUと128ギガバイトのメモリを全て使い切るソフトウェアだとすると、myprogが稼働し続ける間、空いているCPUコアもメモリもほとんど無くなるため、他のユーザーは、このコンピューターシステムで殆ど自分のアプリケーションを動かすことができなくなってしまいます。

一方、TORQUEがある環境では、以下のようなスクリプトmyprog.shを用意し、そのスクリプトをTORQUEが提供するコマンド(qsubコマンド)で実行すると、TORQUEのキューに登録され、適切な計算資源の割り当てをスケジューリングしてくれます。

$ vi myprog.sh
#!/bin/sh
#PBS -l nodes=1:ppn=8
#PBS -l pmem=2gb
#PBS -l walltime=00:45:00
cd $PBS_O_WORKDIR
$PBS_O_WORKDIR/myprog
$ qsub ./myprog.sh

上記の場合、1ノード、8コアのCPUと2ギガバイトのメモリ容量として、TORQUEに実行をリクエストしており、もしその資源が利用可能であれば、myprogが実行されるという仕組みになっています。またジョブの有効期限もリクエストされており、限られた時間内で、アプリケーションの実行が許可される仕組みを提供し、一人のユーザーが無限に使い続けることを防ぐこともできます。

このように、計算資源を有効利用するには、直接プログラムを実行するのではなく、ジョブの管理ソフトウェアを経由して実行させることがわかります。分散メモリ型、共有メモリ型のコンピューターシステムが混在していても、このような資源管理ソフトウェアが介在することで、限られた性能のコンピューターを有効利用することができるわけです。

このような仕組みは、本連載の本題であるApache Mesosでも同様のものが取り入れられており、HPC系のアプリケーションに限らず、WebアプリケーションやDockerコンテナーの実行に適用することができるようになっています。

ちなみに、筆者がTORQUEとMaui Cluster Schedulerに初めて触れたのが、2002年でした。筆者が担当していたHPCユーザーの方は、計算資源の有効利用を必要としていましたので、当然、資源管理ソフトウェアが導入されていました。実は、2015年現在、13年経過した今でも、計算資源に対する考え方、設計方法、TORQUEの構築手順は、ほとんど変わっていません。

TORQUEは、HPCの世界で非常に有名なオープンソースソフトウェアですが、Apache Mesosに負けずとも劣らないジョブ管理の機能を備えています。HPCアプリケーション以外でもTORQUEは適用可能ですので、みなさんも是非一度は触ってみて、計算資源の管理を味わってみてください。

TORQUEによるジョブの投入
図4. TORQUEによるジョブの投入

Apche Mesosがもたらす世界

Mesosは、複数のサーバーからなるヘテロな分散システムを、あたかも一つのコンピューターシステムとして取り扱うことができます。Mesosは複数のホストからなる分散環境を1つのリソースプールとして取り扱うことができ、各管理対象マシンの利用可能な計算資源の情報から、適切なジョブ投入先のマシンを選定し、ジョブを実行します。

この仕組みにより、計算性能の異なる管理対象サーバーが複数混在するヘテロな分散環境の計算資源を有効利用することができます。Mesos は、Apacheコミュニティが手掛けるオープンソースのプロジェクトで、クラスター管理システムのソフトウェアとして位置づけられています。日本では、「クラスター」というと、データベースなどが共有ストレージと共に稼働する高可用性クラスター(HAクラスター)を思い浮かべる方もいるかもしれませんが、Mesosにおけるクラスターとは、高可用性クラスターのことを意味するのではなく、分散ヘテロ環境の計算資源をひとまとめにしたものを意味します。

したがって、Mesosの管理対象は、共有メモリ型システム、Hadoopクラスター、前回ご紹介したSparkクラスター、そして、HPCアプリケーションが稼働する分散メモリ型のHPCクラスターなどが混在する環境です。先述のTORQUEは、主にHPCの世界で利用されている歴史あるソフトウェアですが、Mesosは、HPCだけでなくHadoopやSpark、ビジネスアプリケーションも見据えた計算資源の管理ソフトウェアを目指しています。

Mesosは、オープンソースで提供されており、Apache Mesosのコミュニティによってメンテナンスが続けられていますが、Twitter社などの大規模な導入事例や、Apple社におけるSiriのバックエンド基盤での導入事例があるものの、エンタープライズレベルに必要とされる具体的な技術情報も商用製品に比べるとまだ乏しい状況であり、先進的なサービスプロバイダー企業において、ユーザーの責任で導入されているというのが現実です。

しかし、巷では、Dockerなどのコンテナー技術やHadoopにおける資源管理の仕組みであるYARNなどが登場し、再びコンピューターの計算資源の有効利用に注目が集まっています。多くの計算資源の管理ソフトウェアが乱立する中、特にMesosが注目され始めた理由には、話題のインメモリ処理基盤ソフトウェアのApache Sparkやコンテナー管理ソフトウェアのDockerへの対応があげられます。

前回ご紹介したインメモリの分析基盤ソフトウェアであるApache Sparkのリソース管理のソフトウェアとして、Mesosを選択することができますし、資源管理ソフトウェアを使って、管理対象の物理サーバー上で稼働するDockerコンテナーでアプリケーションを実行することができます。このように、Mesosは、ヘテロな分散環境における資源管理ソフトウェアとして、ビッグデータ、コンテナー技術、HPCなどの異業種を巻き込んでいます。

Apache MesosがもたらすIT基盤の将来像 ~Hadoop、Spark、HPCクラスターが混在するヘテロ環境の資源管理~
図5. Apache MesosがもたらすIT基盤の将来像 ~Hadoop、Spark、HPCクラスターが混在するヘテロ環境の資源管理~

MesosのアーキテクチャとヘテロなIT基盤

Mesosの主な特徴としては、Zookeeperを使ったフォルトトレラント型のシステム、そして、Dockerコンテナーのサポート、CPU、メモリ、ディスク、ポートなどの計算資源のスケジューリングなどです。また、サーバー1万台を超えるレベルまでスケールが可能であると言われています。

それでは、Mesosによる資源管理のシステムは、具体的に、どのような構成になるのでしょうか。Mesosでは、通常、マスターノード(Mesosマスター)とスレーブノード(Mesosスレーブ)に分かれます。マスターノードは、Mesosで形成されるクラスター全体の計算資源の状況を管理しています。スレーブノードで稼働しているデーモンなどもマスターノードが管理しています。

マスターノードは、1台で構成することが可能ですが、通常は、Zookeeperによる複数台のアクティブ・スタンバイ型のクラスター構成をとります。Zookeeperは、クラスターにおけるジョブの実行などを調整します。Mesosは、複数のマスターノードのうち、どれをアクティブにしてクラスターに組み込むかなどにZookeeperを利用します。

一方、スレーブノードは、ユーザーのアプリケーションが稼働するノードです。スレーブノードでは、マスターノードによってユーザーのワークロード(タスク)が割り当てられ、実行されます。MesosマスターとMesosスレーブが主な構成ですが、これに加え、ジョブのスケジューラーとなるChronos(クロノス)、アプリケーションの起動、停止、削除などを行うMarathon(マラソン)が存在します。Chronos、MarathonともにWebブラウザー経由でのユーザーインタフェースを持っており、ユーザーは、ブラウザー経由でジョブを投入できます。

ただし、2015年9月時点では、Dockerコンテナーの起動に関するジョブ投入に限り、REST APIを使ってコマンドラインから行う必要があります。以下に、Mesosを使ったワークロードの投入・実行の大まかな流れを以下に示しておきます。

  1. ユーザーは、Mesosマスターへジョブの実行を依頼(MarathonやChronos経由でもよい)
  2. Mesosマスターが、ユーザーの実行依頼を受領すると、Mesosスレーブの計算資源の空き状況を判断し、ジョブが実行される。
  3. Mesosスレーブでのユーザーのジョブが終了すると、実行結果をMesosマスターに通知する。

Apache Mesosのアーキテクチャ
図6. Apache Mesosのアーキテクチャ

Mesos上でDockerコンテナーを稼働させる意味

Mesosは、Dockerとは完全に独立したソフトウェアであり、Dockerが無い環境でも、ユーザーのアプリケーションをジョブとして投入し、分散環境で実行させることができます。

しかし、投入先のホストには、実行すべきアプリケーションがあらかじめインストールされている必要があり、複数のアプリケーションを分散環境で実行させるには、各ホストに実行する全てのアプリケーションをあらかじめインストールし、Mesos経由でいつでも実行できる環境を準備しておかなければなりません。

例えば、稼動するアプリケーションがApache Webサーバー、Blogサイトを実現するWordPress、データベースのMariaDB、ビッグデータ処理基盤ソフトウェアのHadoopやSparkなど、利用するアプリケーションが複数ある場合は、稼動する可能性のあるスレーブノードに、全てのソフトウェアを事前にインストールしておかなければなりません。これは、非常に煩雑な作業になり、かつアプリケーションによっては、ソフトウェアのバージョンの制約等により共存ができない場合も考えられます。

また、複数のアプリケーションの共存ができない場合、例えば、物理サーバーにアプリケーションとして、NoSQLのみを構築し利用することになると、その物理サーバーは、NoSQL専用機になってしまいます。他のマシンで、計算資源にいくら空きがあったとしても、NoSQLがインストールされていないマシンでは、NoSQLを利用できません。

そこで、スレーブノードでは、物理サーバーにアプリケーションを直接稼働させず、OSとアプリケーションをDockerコンテナ上で稼働させます。MesosによるDockerコンテナーの稼働環境では、あらかじめ、稼動させる予定のアプリケーションを含んだDockerイメージを、Mesosスレーブノードに登録しておきます。Dockerイメージを使って、1台の物理サーバーのホストOS上で複数のDockerコンテナーを稼働させることができます。しかも、Docker環境ですので、ホストOS上でマルチOS環境を実現できます。DockerコンテナーをMesosで管理することにより、計算資源の空いたマシンで、Dockerコンテナーを起動させることができ、アプリケーションの計算資源の利用効率が高まります。

勿論、HPCなどで利用されていたような、従来型の物理サーバーにアプリケーションが紐づいた非Docker環境でもMesosを利用するメリットは大いにありますが、DockerをMesos環境で利用すれば、OSのインストールの手間、複数アプリケーションの共存問題、計算資源の有効利用を阻むアプリケーションの物理サーバーでの固定利用などを排除することができます。

Docker on Mesosの意味
図7. Docker on Mesosの意味 



回は、過去から存在する資源管理ソフトウェアも紹介しながら、Apache Mesosを紹介しました。第4回の後編では、Apache Mesosのインストール手順、基本的な使用法を紹介します。お楽しみに。

各種お問い合わせ

サイオスOSSよろず相談室(1)

問い合わせボタン

最新の情報
[第15回] Linux/OSS エバンジェリスト古賀政純の『オープンソース・Linux超入門』 Linuxサーバーのためのハードウェア設定 ~ Hyper-Threading ~ 2017年06月21日
わかっておきたいセキュリティ: 第5回 VirusTotal at Home/Work「Malice」 2017年05月10日
わかっておきたいセキュリティ: 第4回 IRMA (Incident Response Malware Analysis) 2017年03月29日
わかっておきたいセキュリティ: 第3回 マルウェア解析サンドボックス「Cuckoo」との連携 その2 2017年02月22日
[第14回] Linux/OSS エバンジェリスト古賀政純の 『オープンソース・Linux超入門』 システム要件において検討すべき点 その4 2017年02月08日
[第13回] Linux/OSS エバンジェリスト古賀政純の 『オープンソース・Linux超入門』 システム要件において検討すべき点 その3 2017年02月01日
[第12回] Linux/OSS エバンジェリスト古賀政純の 『オープンソース・Linux超入門』 システム要件において検討すべき点 その2 2017年01月25日
[第11回] Linux/OSS エバンジェリスト古賀政純の『オープンソース・Linux超入門』 システム要件において検討すべき点 その1 2017年01月18日
Python人材育成の支援を目的としたPythonエンジニア育成推進協会の活動とは? 2016年12月21日
わかっておきたいセキュリティ: 第2回 マルウェア解析サンドボックス「Cuckoo」との連携 2016年12月14日
可知豊の『 わかっておきたい、オープンソースライセンス』: 第3回 オープンソースライセンスの使い方をわかっておきたい 2016年12月08日
可知豊の『 わかっておきたい、オープンソースライセンス』: 第2回 色々なオープンソースライセンスをわかっておきたい 2016年11月30日
可知豊の『 わかっておきたい、オープンソースライセンス』: 第1回 著作権とライセンスをわかっておきたい 2016年11月17日
わかっておきたいセキュリティ: 第1回 マルウェア解析サンドボックス「Cuckoo」 2016年11月02日
[第10回] Linux/OSS エヴァンジェリスト古賀政純の 『オープンソース・Linux超入門』 Linuxサーバーシステム導入前の検討~ RHELを知る ~ 2016年10月26日
[第9回] Linux/OSS エヴァンジェリスト古賀政純の 『オープンソース・Linux超入門』 Linuxサーバーシステム導入前の検討~ Ubuntu Serverを知る ~ 2016年10月19日
[第8回] Linux/OSS エヴァンジェリスト古賀政純の 『オープンソース・Linux超入門』  Linuxサーバーシステム導入前の検討~ SUSEを知る ~ 2016年10月12日
[第7回] Linux/OSS エヴァンジェリスト古賀政純の 『オープンソース・Linux超入門』~「初心者でもわかる、Linuxサーバーシステム活用者が知っておくべきポイント」(後編) 2016年08月09日
[第6回] Linux/OSS エヴァンジェリスト古賀政純の 『オープンソース・Linux超入門』~「初心者でもわかる、Linuxサーバーシステム活用者が知っておくべきポイント」(前編) 2016年08月02日
[第5回] Linux/OSS エヴァンジェリスト古賀政純の 『オープンソース・Linux超入門』~「ミッションクリティカルシステムとオープンソース・Linux」(後編) 2016年06月22日
最新の情報 - もっと...