分散処理モデルの課題解決を歴史から探る
続いて登壇したのは、データ＆サイエンスソリューション統括本部 データインフラ本部のKVSチームに所属し、主にCassandra関連の開発と運用を担当している今野氏。セッションタイトルは「分散システム処理モデルの課題と展望」。
クラウドアプリケーションの構築方法は「協調サービス」「リソース管理サービス」「アプリケーションフレームワーク」という大きく3種類の分散処理モデル上に構築されているという。
分散処理モデルの課題の一つは「モデルが乱立していることだ」と今野氏は指摘する。乱立して困るのは、どれを選べばよいのか判断に迷うこと。そのほかにも、クラスタの構築や利用効率、ソフトウェア試算の継承、知識、経験の陳腐化などの課題があると言う。クラスタの利用効率についてはリソース管理などによる効率化が使えるのではと、今野氏は提案する。
例えばリソース管理の効率化はスーパーコンピュータの世界ではジョブ管理と呼ばれ、解決策は昔からある。クラウド環境と要件は違うとはいえ、「昔の技術を活用してシステムを作れないかといろいろ考えている」と今野氏は説明する。
例えば1980年代に登場したMicrokernel。これはモノリシックなカーネルの大規模化、柔軟性、信頼性、安全性などの問題を背景に発展した技術だ。特徴はカーネルを小さく分割して構成し、最小限のモジュールのみをカーネルモードで実行する。「カーネルとプロセスが分離しているので、高信頼性が保てること。単位責務、疎結合性により、理解度やデバッグ効率が高いことなどのメリットがある」と今野氏は説明する。
現在、マイクロサービスが流行しているが、これはモノリシックなサービスを、複数の小さな集合体として構成する手法で「Microkernelに似ていると思う」と今野氏は言う。
次に1960年代から登場したDataflow。これは電子回路の記述言語として運用された技術で、そのメリットは並行性が可能になることと抽象度が高いことである。そのため「ノードの処理はどんな言語でも実装でき、位置透過性もある」と今野氏は説明する。
続いてDataflowの実装モデルについても紹介。代表的なのはUNIXパイプで、大きな処理を実現する手法であり、これも実装するプログラミング言語は問われない。
モノリシックからマイクロに、静的から動的な仕組みを構築し、課題を解決
分散アプリケーションの課題の第一はモノリシックな構築であること。現在、分散アプリケーションはモノリシックな構築となっている。モノリシックな課題は、既存資産が移行できず陳腐化する場合もあるということ。しかも流用が難しく、単一のプログラミング言語に限定されるなど拡張性に乏しい。また動的な機能追加や変更の度に再起動が必要になったり、プログラムの構造の理解が難しく、ブラックボックス的な運用になってしまったりするという。
そこで今野氏は「モノリシックからマイクロに、静的から動的に」分散フレームワークの改善を提案。つまり分散アプリケーションをモジュール単位で構築し、既存資産を移行できる形にし、再利用性を高める。また、いろいろな言語で実装できるようにするほか、動的な機能追加や変更を可能にして、再起動の必要性をなくし、ホワイトボックス的な運用にするという提案である。
これを実現する基本コンセプトとして採用したのが、MicrokernelとDataflowに着想を得た「マイクロ協調サービス」だ。各クラスタは複数の基本処理エンジンから成るノードから構成。ノード自身は限定された機能しか持っておらず、その他の機能はユーザーが動的プログラミング言語でメソッドを作成して追加していくのである。動的なノードにすることで、多くのプログラミング言語に対応。自律的なノードで外部イベントだけではなく、内部イベントの定義も可能にする。
実装についてはオープンスタンダードな技術のみで実装。「JSON-RPC over HTTPを拡張した」と今野氏は語る。またコアエンジンはC言語で実装。バインディング言語は最終的にはPythonやLuaあたりが本命になりそうだという。
Yahoo! Cloud Serving Benchmark（YSCB）によって実際に評価したものが下図のグラフだ。「動的スクリプト言語による性能劣化は想定範囲内だった」と語る。今野氏は最後に「最終的にエンジン実装はC++もしくはGo言語＋C言語で、Cコア部の比率を調整するのが良いと思う」とまとめ、セッションを締めた。
お問い合わせ
ヤフー株式会社
