KubernetesのSchedulerを評価するためのシミュレーター「k8s-cluster-simulator」公開

Daisuke Taniwaki

2019-04-11 08:00:27

概要

2018年夏のインターンおよびPEとして勤務した薮内さんとそのメンターである谷脇大村で開発したKubernetesクラスターのシミュレーターであるk8s-cluster-simulatorのアルファ版をオープンソースとして公開しました。このシミュレーターはKubernetesクラスタに投入されるPodのワークロードを時間とともにシミュレートできるため、Kubernetesのスケジューラーを本番環境に投入する前に評価することができます。

開発の動機

PFNでは巨大なオンプレのGPUクラスタを持っており、その上でKubernetesを使って様々な実行時間の機械学習ジョブを研究者が実行しています。我々クラスターサービスチームのミッションの一つとして、GPUの利用率を向上させ費用対効果をあげることが挙げられます。一方で、研究者間で使えるリソースの平等さも考慮しなければなりません。これを実現させるために、我々はKubernetesのスケジューラーを独自で開発したり、Extender (例 kube-throttler)を拡張したりしています。しかし、新しく開発したロジックを本番環境で走っている機械学習ジョブに影響させずに評価するのは難しく、また頻繁に試行錯誤を本番環境上で行うのは好ましくありません。バグのあるスケジューラーをデプロイしてしまった場合には研究者の仕事を止めてしまうことになるので、絶対に避けなければなりません。またスケジューラーのアルゴリズムを試すためだけに、大規模なクラスタを用意し、多くのワークロードを実際に可動させることも現実的ではありません。これらの理由からKubernetesのスケジューラーを評価するためのクラスタのシミュレーターの開発を開始しました。

デザイン

シミュレーターを開発するにあたって以下のことを考慮しました。

  • シミュレーター用のスケジューラーの実装を最小限の変更で本番環境で動かせるようにする。
  • 時間をシミュレートすることで評価を高速化するとともに、通信や内部処理のレイテンシーがスケジューリングのロジックの評価に影響しないようにする。
  • シミュレートするワークロードを自由に設計できる。
  • 後段の分析のために様々なメトリックスを出力できる。

 

アーキテクチャ

以下は簡単なフロー図になります。

 

アイデアはすごく簡単です。シミュレーターはループのステップ毎にクロックを1つ進めます。各ステップでサブミッターにそのクロックで投入するPodがあるかどうかを聞いて、サブミッターは投入または削除するPodがあればPodのリストを返します。シミュレーターはPodのリストをスケジューラーに渡し、スケジューラーはBindするものと削除するPodを選んでイベントとして返し、シミュレーターがリソース管理を行います。そして、この時に処理されたPodのメトリックスをMetrics Loggerに出力する流れになります。

 

以下はハイレベルなクラス図になります。

 

本シミュレーターでは拡張できる点は以下の2つになります。

 

Submitters

シミュレーターの定義するインターフェースに沿っていれば任意の数、組み合わせのサブミッターを使用することができます。複数のサブミッターをシミュレーターにプラグインできるので、例えばAさんは朝たくさんのPodをサブミットする傾向があるが、Bさんは夕方たくさんのPodをサブミットする傾向があるといったシミュレーションをする場合、それぞれのユーザの振る舞いモデルを独立に開発してシミュレーターにプラグインできます。

また、サブミッターはクロック毎のメトリックスを受け取ることができるため、クラスターの利用状況に応じて挙動を変えることも可能です。

Scheduler

スケジューラーの拡張方法は2種類あります。
Kubernetesのスケジューラー(kube-scheduler)をそのままもしくは拡張したアルゴリズムを利用したい場合、kube-schedulerが用意しているのと同様, Prioritizer, Extender, Predicateをセットできるミミックスケジューラーが用意されています。kube-schedulerはキューベースのスケジューラーですが、複数のPodを条件に応じてまとめてスケジュールするような、例えばより複雑なスケジューラーをシミュレーションしたい場合には、シミュレーターが定義するインターフェースを実装するように少しラッパーメソッドを書くと、それも評価できるようになっています。

*kube-schedulerの挙動については大村によるQiita投稿をご覧ください。

ロードマップ

現在、シミュレーターの使いやすさを向上させ、またより現実的な環境をシミュレーションできるように、ベータバージョンに向けて以下の機能を開発しています。

  • より疎結合なコンポーネント(例:スケジューラーとサブミッターにRPCインターフェースをサポート)
  • よく使われるサブミッターの提供(例: 典型的な確率分布に従うサブミッター(一様分布、二項分布、ポアソン分布等)
  • より多くのクラスターイベントへの対応(ノード故障、突発的なPod故障、ノード追加、削除)
  • デファクトなプロッターツール(matplotlib, gnuplot等)で直接読み込める出力フォーマットのサポート

興味のある方は是非試していただいて、フィードバックをいただけると幸いです。

 

Rust向け字句解析器生成器「rflex」を公開しました

kashihara
エンジニア

2019-04-09 08:00:14

Rust向け字句解析器生成器である「rflex」をOSSで公開しました。ここでは簡単に、「rflex」や開発に至った経緯について紹介します。

PFNエンジニアの柏原です。あまりリサーチブログには出てきませんが、前回は「[BoF] How to choose programming language for product/in-house software development」というブログを書きました。

「rflex」はプログラミング言語処理系のフロントエンドにおける文字列解析を行うコンポーネントである字句解析器(Lexical analyzer)と構文解析器のうち、前者の字句解析器のコードを生成するツールです。字句解析器生成器の「flex」とよく似たツールとなっています。構文解析器の生成では 「GNU Bison」が有名です。

開発のモチベーション

個人的には「rflex」開発においては社内外での言語処理系開発の盛り上がりについて期待を込めて作っている部分もあります。実務に役立つのはもちろんありがたいことですが、コンパイラ・言語処理系の開発といったプログラミングを楽しむことにも役立ててもらえると開発者として嬉しいと思っています。

PFNでは、業務中の活動として20%に相当する時間を個人の研究テーマや、新規アイディアのプロトタイプ実装などに当てることが認められています(20%ルール)。

今回、私は字句解析器生成器がRust に存在しないことを確認した、2018年7月頃から「rflex」の開発を開始しました。正確には、2018年1月頃から個人的に字句解析器生成器の開発のための学習をしていましたが、せっかくなので制度を活用することにしました。
「rflex」の開発においては既存ライブラリの再実装・移植、つまり車輪の再発明という側面が強いですが、以下の点でメリットがあると考え実装に至りました。

  • Rust向けのツールとして、字句解析器生成器を提供することができる
    • プログラミング言語処理系のフロントエンド開発(Rust)において、字句解析器の作成が楽になる
    • GitHubに公開することでユーザを増やし、バグレポート等の対応により品質の向上が期待できる
    • ブログ執筆時点で社内ユーザは確認できていないが、将来的に社内で必要なテキスト処理・言語処理系フロントエンド開発を手伝える可能性がある
  • Rustを業務時間内に学習できる
  • 字句解析器生成器の仕組みを再実装を通して学習できる
    • 正規表現パーサの実装
    • 非決定性オートマトン(NFA)及び決定性オートマトン(DFA)を構築するコードの実装
    • 決定性オートマトンの最小化アルゴリズムの実装

終わりに

PFNではこのような個人の活動を支援する制度(20%ルール)があり、何かに挑戦したい人にとって嬉しい仕組みだと思います。私自身も「rflex」のユーザとして応用的(言語処理系フロントエンド開発といった)な活動を新たに挑戦していく予定です。これからも「rflex」は継続的に開発を続けていく予定ですので、GitHubでのPull Request/Issueを通してフィードバックをお待ちしています。

最後に宣伝となりますが、今年もPFNはインターンを募集しています。