<commit_before>+++
date = "2015-09-01T18:47:11+09:00"
draft = true
title = "Google Omegaとは何か? Kubernetesとの関連は? 論文著者とのQA（翻訳）"
+++

エンタープライズ向けのKubernetesサポートを行っている[kismatic Inc.]([https://kismatic.com/)による["Omega, and what it means for Kubernetes: a Q&A about cluster scheduling"](https://blog.kismatic.com/qa-with-malte-schwarzkopf-on-distributed-systems-orchestration-in-the-modern-data-center/)が非常に良いインタビュー記事だった．Google Omegaとは何か? 今までのスケジューリングと何が違うのか? 何を解決しようとしているのか? 今後クラスタのスケジューリングにはどうなっていくのか? をとてもクリアに理解することができた．

自分にとってスケジューリングは今後大事になる分野であるし，勉強していきたい分野であるのでKismaticの[@asynchio](https://twitter.com/asynchio)氏と論文の共著者である[<NAME>](http://www.cl.cam.ac.uk/~ms705/)氏に許可をもらい翻訳させてもらった．

## TL;DR

2013年に発表された[Omega論文](http://www.cl.cam.ac.uk/research/srg/netos/papers/2013-omega.pdf)の共著者である[<NAME>](http://www.cl.cam.ac.uk/~ms705/)がGoogle OmegaのShared-stateモデルの主な目的がScalabilityよりもむしろソフトウェア開発における柔軟性であったことを説明する．Shared-stateモデルによるスケジューリングは優先度をもったプリエンプションや競合を意識したスケジューリングを可能にする．

今までのTwo-levelモデルのスケジューラー（例えば[YARN](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html)や[Mesos](http://mesos.apache.org/)）も同様の柔軟さを提供するが，Omega論文が発表された当時は，すべての状態がクラスタから観測できない問題（information hiding）や[Gang Scheduling](https://en.wikipedia.org/wiki/Gang_scheduling)におけるhoardingの問題に苦しんでいた．またなぜGoogleがShare-stateモデルを選択したのか，なぜGoogleは（Mesosのような）厳格な公平性をもったリソース配分を行わないのかについてもコメントする．

最後にMesosや[kubernetes](http://kubernetes.io/)のようにスケジューラーのモジュール化をサポートすることでいかにOSSのクラスター管理にOmegaの利点を持ち込むことができるのかを議論する．そしてより賢いスケジューリングを実現することでユーザはGoogleのインフラと同様の効率性を獲得できること提案する．

**2013年の論文の発表時と比べて何が変わったか? 何が変わらないか?**

クラスタのオーケストレーションは動きの早い分野である．しかしOmegaの中心となる原則はむしろよりタイムリーでとても重要であると思う．

2013年以来の大きな変化として，とりわけKubernetesやMesosのおかげで，Omegaのようなクラスタでインフラを運用するのが一般的になってきたことが挙げられる．2011年や2012年に立ち返ってみるとOmegaのShared-stateモデルによるスケジューリングの基礎となる仮説をGoogle以外の環境で実証するのはなかなかトリッキーなことだとみなされていた．しかし今日では，既存のモジュラーなスケジューラーをハックして新しい手法を試したり，[Google cluster trace](https://github.com/google/cluster-data)の公開されたTrace結果を使うことでより簡単にそれができる．<commit_msg>Change date<commit_after>+++
date = "2015-09-17T18:47:11+09:00"
title = "Google Omegaとは何か? Kubernetesとの関連は? 論文著者とのQA（翻訳）"
+++

エンタープライズ向けのKubernetesサポートを行っている[kismatic Inc.]([https://kismatic.com/)による["Omega, and what it means for Kubernetes: a Q&A about cluster scheduling"](https://blog.kismatic.com/qa-with-malte-schwarzkopf-on-distributed-systems-orchestration-in-the-modern-data-center/)が非常に良いインタビュー記事だった．Google Omegaとは何か? 今までのスケジューリングと何が違うのか? 何を解決しようとしているのか? 今後クラスタのスケジューリングにはどうなっていくのか? をとてもクリアに理解することができた．

自分にとってスケジューリングは今後大事になる分野であるし，勉強していきたい分野であるのでKismaticの[@asynchio](https://twitter.com/asynchio)氏と論文の共著者である[<NAME>](http://www.cl.cam.ac.uk/~ms705/)氏に許可をもらい翻訳させてもらった．

## TL;DR

2013年に発表された[Omega論文](http://www.cl.cam.ac.uk/research/srg/netos/papers/2013-omega.pdf)の共著者である[<NAME>](http://www.cl.cam.ac.uk/~ms705/)がGoogle OmegaのShared-stateモデルの主な目的がScalabilityよりもむしろソフトウェア開発における柔軟性であったことを説明する．Shared-stateモデルによるスケジューリングは優先度をもったプリエンプションや競合を意識したスケジューリングを可能にする．

今までのTwo-levelモデルのスケジューラー（例えば[YARN](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html)や[Mesos](http://mesos.apache.org/)）も同様の柔軟さを提供するが，Omega論文が発表された当時は，すべての状態がクラスタから観測できない問題（information hiding）や[Gang Scheduling](https://en.wikipedia.org/wiki/Gang_scheduling)におけるhoardingの問題に苦しんでいた．またなぜGoogleがShare-stateモデルを選択したのか，なぜGoogleは（Mesosのような）厳格な公平性をもったリソース配分を行わないのかについてもコメントする．

最後にMesosや[kubernetes](http://kubernetes.io/)のようにスケジューラーのモジュール化をサポートすることでいかにOSSのクラスター管理にOmegaの利点を持ち込むことができるのかを議論する．そしてより賢いスケジューリングを実現することでユーザはGoogleのインフラと同様の効率性を獲得できること提案する．

**2013年の論文の発表時と比べて何が変わったか? 何が変わらないか?**

クラスタのオーケストレーションは動きの早い分野である．しかしOmegaの中心となる原則はむしろよりタイムリーでとても重要であると思う．

2013年以来の大きな変化として，とりわけKubernetesやMesosのおかげで，Omegaのようなクラスタでインフラを運用するのが一般的になってきたことが挙げられる．2011年や2012年に立ち返ってみるとOmegaのShared-stateモデルによるスケジューリングの基礎となる仮説をGoogle以外の環境で実証するのはなかなかトリッキーなことだとみなされていた．しかし今日では，既存のモジュラーなスケジューラーをハックして新しい手法を試したり，[Google cluster trace](https://github.com/google/cluster-data)の公開されたTrace結果を使うことでより簡単にそれができる．
{'fraction_non_alphanumeric': 0.11599696739954511, 'fraction_numerical': 0.024260803639120546, 'mean_word_length': 12.062706270627062, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 10, 'lorem ipsum': 0, 'www.': 6, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3366714', 'n_tokens_mistral': 2762, 'n_tokens_neox': 2553, 'n_words': 82}