yumulog

北海道の大学教員/情報科学研究者の日記

CEDEC2016ペラコン177位でした #peracon

f:id:yumu19:20160827010538p:plain

今年もCEDECでペラコン(A4 1枚のゲーム企画書コンテスト)に参加しました。

結果は195作品中177位でした。初参加の一昨年は38位、昨年は26位とそこそこの順位をとってきたのですが、今回は最下位付近の大事故です。

できるまで

応募したのは、エントリのトップに貼った「Rokuring」という拡張現実ゲームです。今回のテーマは「リング」ということで、一人ブレストをしていろいろネタ出しをし、クラウドファンディングで一時期話題になったあの Ring が思い浮かびました。Ringのように指輪型ウェアラブルバイスで指先の動きをセンシングして操作を行うのをゲームに取り入れたらおもしろいんじゃないかと思い、ちょうど大流行中のポケモンGOやその元になったIngressのような街中でプレイする拡張現実ゲームのネタを詰めていきました。IngressやポケモンGOで散々言われていた「ヘッドマウントディスプレイ(HMD)でプレイればと絶対面白い」というのも取り入れてみました。技術的にも、現状のRingやHoloLensの技術を考えれば、それほど非現実的ではなく、数年後に実現してもおかしくないくらいです。

仕掛け

内容の他にペラ自体にも何か仕掛け(ペラコン自体もハック)をしたいなと思い、ゲームで現実をしたようにペラもWebへ拡張すべく、広告でよくある「続きはWebで」を取り入れてみることにしました。ポスターに検索ワードを書いて検索に誘導しつつ、実際にランディングページを作成し、検索すると本当にページを閲覧できるようにしました。

ページの作成には、 WebのGUIからランディングページ向けの1枚サイトを作成できる「ペライチ」という奇しくもペラコンっぽい名前のサービスを利用しました。

Google Analyticsも仕込んだのでアクセス数もわかるのですが、たったの8アクセス!その内、審査期間と思われるCEDEC開催中のアクセスは1アクセスで、まったく審査員に見てもらうことができませんでした。

ランディングページがあるからといって提案のネタが面白くなるわけではなく、面白い仕掛けとおもって票を入れてくれる審査員が数名いたらいいなあくらいの気持ちでしたが、そもそも検索してもらえないと仕掛けにも気づいてもらえないですね。200弱の大量のペラを審査している間にわざわざ検索して調べてもらうのは難しいということに気付かされました。

規約には違反していないはずなので失格にはならないだろうと思いつつ、失格になったらどうしようと少しドキドキしてました。*1

なぜ事故ったか

実際のところは審査員コメントを読むまでわからないのですが、自分で思いつくところの反省点を上げると

  • ゲームルールがIngressの劣化版パクリで新規性も面白味もない
  • 指輪ネタが多すぎたので、指輪という時点で興味を惹けなかった
  • 世界観(なぜ戦うのか)の記載が一切ない

あたりが思い浮かびます。ただ、この順位だと票を入れた審査員がおそらく0人か1人ということで、ほぼすべての審査員に響かなかったわけで、根本的に何かが違うんですかねー。

自分の中で「続きはWebで」の仕掛けにちょっと傾倒しすぎてたというのはありますが、「続きはWebで」が無くてもおそらくこのネタで勝負しただろうという程度には自信があったネタなので、ネタ作りに手を抜いたということでもないです。ペラの作成時間も、昨年までは2〜3時間でパワポで作っていたのが、今年はだいぶ気合入れて5時間以上かけてイラレでつくってたり。

まあでもやっぱり本当のところは審査員のコメントを見てみないとわからないので、講評出るのがとても楽しみです(開き直りではなく本当に)。50位くらいだとすごく凹んだ気がするのですが、ここまで低いと悔しさよりもなんで低かったんだろうという好奇心の方が勝るんですね。この順位だと酷評コメントばかりでしょうが、大人になると酷評される機会も少ないですし。

「失うものしかない」との呼び声が高いペラコンですが、(逃げを打つわけではないですが)自分はゲーム業界の人間ではなく失うものが特にないので、順位が低くてもペラコンを楽しませて頂きました。また来年新しい気持ちで出直して、来年こそはきちんと結果を出したいと思います。

*1:まあこの順位だと失格のほうがマシと思えるくらいなんですが

研究テーマの探し方(大学3〜4年生・M1向け)

f:id:yumu19:20160624191126j:plain

書きかけを下書きに保存したまま忘れて放置してました。。。 研究室に配属されたばかりの大学3〜4年生・M1くらい向けに、研究テーマの探し方について書いてみます。

ざっくり次の4ステップ。うまく見つかるまで繰り返し。

  1. 授業等で得た知識の中から興味あるキーワードを10個挙げる
  2. そのキーワードをもとに、どういう研究ができそうか、研究テーマ候補を5個挙げる(この段階で新規性のあるものを思いつくのは無理なので、すでにありそうなものでOKなので、とにかく5個絞りだす)。
  3. それぞれの研究テーマについて、Google Scholarを使って、最も近い論文を探す(似たような研究テーマが必ずあるはずなので。見つからなければ検索ワードを少し変えて検索し直す。)
  4. その論文を読んでみて、自分のアイディアとの差分(自分のアイディアの方が優れていること)か、こうすればもっと上手くいきそうというアイディアを考える。

研究ネタを思いついた場合、同じような先行研究が必ずあるので、自分が考えたネタと一番近いことをやっている先行研究の論文を探しましょう。(思いついたネタがありきたりだからというわけではなくて、世の中のどんな研究ネタにも必ず先行研究があるし、人間が思いつくことは大抵過去の誰かがやってます)

1ネタについてGoogle Scholarを使って論文探し2時間・論文読み2時間として半日くらいあればできるはずで、丸1週間くらいかければ先行研究調査を大体終えられるはず。

その先行研究を踏まえたうえで、既存研究に対して差分が出せそうなネタを選ぶといいんじゃないかな。または、どうやればいいかは未確定だけどこれをやりたい!という情熱を持ってできそうなネタが見つかればそれでもよいし。

1ネタに絞ったら、国内研究会→国際会議→査読付き論文投稿という研究のステップ(分野によって異なります)を一通り体験できるといいですね。国内研究会だけで終わっちゃうと英語の論文が残らないので、世界的には何もやってないことと変わらないので、どんなネタでも国際会議まではやらないともったいない(ブーメラン)。

社会人博士に進学しようとしている人へ

f:id:yumu19:20160804081257j:plain

自分の周りで社会人博士に進学した人・しようとしている人が増えてきたのでちょっと書いてみます。本当はこういうのは自分が修了したあとに書いたほうが説得力があると思うのですが、それ*1を待ってるといつまで経っても書けないので。

ちょうど最近出てた

というエントリもすばらしいので、こちらとそのリンク先のエントリも合わせて読むといいと思います。

本当に社会人博士がベストな選択か?

いきなりですが、社会人博士として会社に勤めながら学位を取る以外にも、休職や退職をして学位取得に専念するという道もあります。同然メリットとデメリットがあり、どちらがベストな選択なのかは状況によって異なりますが、そういう選択肢もあるということを頭において一度きちんと考えてみてはどうでしょうか。これについては以前にまとめました。

本当に本当に本当に時間がない

フルタイムでも上手くいけば3年かけて修了(上手くいかないともっとかかる)というものを、仕事以外の時間(夜と土日)しか使えないという縛りプレイをやっているので、当たり前ですが本当に時間がないです。仕事以外の多くの時間を研究に割り当てる必要があります。研究のためにすべて我慢するというのはストレスが溜まって良くないとおもいますが、ある程度の取捨選択は必要です。直近数ヶ月くらいの自分の行動を振り返ってみて「何に時間を使っているのか」「どのくらいの時間を研究活動に割けそうか」「絶対に妥協できないものは何か」を見積もってみると良いとおもいます。ちなみに僕は、「社会人博士入学後は飲みに行く頻度を減らして研究に励もう!」と考えてましたが、もともとそんなに頻繁に飲みに行くような人ではないので、この決意は意味ありませんでした。自分の行動を把握するところからはじめましょう。

修了要件をきちんと把握する

ほとんどの博士課程で、査読付論文や国際会議の研究発表業績がいくつ以上あれば博士論文審査に進めるという修了要件が定められていると思います。例えば、JAIST情報科学研究科は査読付き論文誌論文1つ、査読付き国際会議1つ*2と言われています。ただ、こういう修了要件が明文化されてるのを他大も含めて見たことが無く*3、研究科や専攻や研究室の内規(暗黙の了解)となっているようなので、教員や大学院生に確認しましょう。

スタートダッシュはフライングで

入学時の面接にてどういう研究テーマについて研究するか話すと思います。この時点ではまだざっくりとした研究テーマで、詳細は入学後に指導教員と詰めるというケースが多いと思うのですが、上述のとおり時間がないので、入学前にできるだけ詳細に具体的に研究テーマについて詰めておいたほうが良いです。

現状どこまで研究されているか把握しないと研究テーマを立てようがないので、まずはとにかく論文を探して読むことから。最初は、興味があるキーワードでGoogle Scholarで検索するか、カンファレンスのプログラムから気になるタイトルをピックアップするのが良いとおもいます。気になった論文が古い場合には、Google Scholarの「引用元」を辿って行くと最新の研究がどのくらいのものなのか見えてきます。論文は基本的に有料で、大学で一括契約していて大学のネットワークからアクセスすると無料で読めるようになってますが、著者がPDFを公開しているケースも多いです。研究テーマの探し方について別エントリを書きました(大学3〜4年生・M1向けですが)。

ピンポイントな研究テーマまでは決められなくても、やりたい研究テーマに関するトップカンファレンスやメジャーなカンファレンスにどういうものがあるのかくらいまでは把握した状態で入学したいですね。例えば、情報系では AMiner の Conference Rank でトップカンファレンスを調べることができます。

トップカンファレンスが何かわかっていると、先行研究調査をするときに調査対象をまずトップカンファレンスに絞ることができるので調査しやすくなります。また、同じ分野の人が多く参加する国内学会は何なのか、入学後に一番最初に発表する研究会はどれに目標を定めるのかまで見えてくると、入学後の研究の流れとタイムスパンが想像しやすくなると思います。この辺は研究室の色というのもあると思いますが。

入学前にエンジンをどれだけ暖めておけるかが、研究をスムーズに進められるかどうかの鍵となります。あっという間に時間が過ぎてしまうので、最初から全力で(ただしバテないよう無理のないペース)で行きましょう。

博士号のとり方 学生と指導教官のための実践ハンドブック

博士号のとり方 学生と指導教官のための実践ハンドブック

なぜあなたの研究は進まないのか?

なぜあなたの研究は進まないのか?

  • 作者:佐藤 雅昭
  • 出版社/メーカー: メディカルレビュー社
  • 発売日: 2016/07/08
  • メディア: 単行本

*1:2017年12月に修了したいという思いを持っています。

*2:情報系では、国際会議が査読付き論文と同等かそれ以上に評価される

*3:公開されている事例があれば教えて下さい

July Tech Festa 2016 に参加した #JTF2016

f:id:yumu19:20160724120021j:plain

2016年7月24日(日)に産業技術大学院大学で開催された July Tech Festa 2016 に参加しました。 1000台以上の物理サーバがあるテストベッド で研究してるので最近はインフラ系をいじることが多く、そっち方面の最新技術についての情報収集ができればと思い参加しました。

ハンズオンも含めて最大8パラレルセッションなので、聞きたいセッションがかなりかぶりました。聞いたセッションについて、内容のログと感想を書きます。

現実が正解だ! やってみんとわからんことだらけ。 さくらのIoT企画・開発365日の軌跡。そして、次の365日へ。

さくらインターネット株式会社 小笠原 治(@)さんの基調講演。記事になってました。

  • チームビルディングの話をします
  • 自己紹介
    • ABBALabという投資ファンドをやってます
    • DMM.makeというモノづくりスペースも運営してます
      • Orphe,Exiii,Vincle,SYMAC,Sensprout,犬パシー
  • 14年経ってさくらに出戻り
  • IoTとは
    • 狭義のIoT: いわゆるインダストリー4.0
    • 広義のIoT: 生活に密接したIoT ← さくらのIoTはここがターゲット
    • IoTってバズワード
    • 「モノのインターネット」という呼び方が好きじゃない。「モノゴト」のインターネット
    • IoTを継続するには商売をしないといけない
    • さくらはインフラ屋なので、インターネットと繋ぐところを提供
    • ビジネスの話がIoTをうさんくさく感じさせるが、お金の話がないと何も進まない。
      • 1回1円払うとしたら6兆円の産業が生まれる
  • さくらのIoTプラットフォームの話
    • さくらのプラットフォームでは閉域網でインターネットに出る手前に処理できる
    • 研究が必要なので、研究所で研究を行う
    • 会社に説明するために予算取りをする人に入ってもらう
    • プラットフォーム構築のためにエンジニアが入る。新卒2年目の江草さんが執行役員に。
    • ここまでを3ヶ月くらいで実施
    • 他の会社とのアライアンス
    • さくらのIoT Platform α リリース
    • UI/UXのデザイナー
    • 組み込みエンジニア、社会人だとなかなか出会えない。学生で修士1年でリモートで仕事。
  • プロトコルを簡単に
  • Mesos / MARATHON / Dockerで構築
  • 会社という組織の中でやるとチームをつくったり離れたりしやすいのがいい
  • 天草でパラグライダーの追跡実験を行った
    • 3G/LTEを使用すると電波法にひっかかるのでLoRaを用いた
    • 実質10日で開発を実施した。クラウドが整っているとこのくらいの期間で開発できる。
    • 目的と締切があって短期的に一気にやることはサービスの立ち上げ時には必要。ただしこれが繰り返されると人が去っていくのでいけない。
  • 7月からはリーダーを山口さんにバトンタッチした。僕(小笠原さん)はまた別のことをやれる。この柔軟さも会社の良さ。

  • よくある誤解

    • MVNOではない
    • インターネットなクラウドサービスでもない → 閉域網とつながる
    • バイスメーカーになるわけでもない → サービスを使うハードルを下げるためにデバイスを安く提供
  • エンジニアの愚痴を聞くことが増えた

  • 流動性が増えるのはよいこと」

Q&A

  • Q. 他のクラウドとの差別化は?
    • ハードウェア屋さんにとってさくらのほうが使いやすい

感想

さくらのIoTプラットフォームは、サービス面はもちろん、ネットワーク技術が絡んだ話なので開発にもすごく注目してます。チームビルディングをメイントピックとし、チームメンバーを1人あたりにスライド1枚つかって紹介していたのも印象的でした。絶賛開発中なのでリリースに向けて頑張ってください。

さくらのDockerコンテナホスティング-Arukasの解説とインフラを支える技術

さくらインターネット株式会社 山田修司(@)さんの発表。

Arukasの紹介

  • dockerイメージをデプロイできる環境
  • 現在オープンベータ
  • 1850ユーザ
  • 4000種類のイメージ、6000個のコンテナが動いた
  • API対応、CLI対応、非公式でTerraform対応

Arukasのインフラを支える技術

  • 今後のインフラ環境予測
    • 2010年まではベアメタル
    • 2020年まではIaaSだろう
    • 2025年までは lightweight PaaS (Container as a Service)
    • その後に PaaS
  • CaaSの流れ: Build -> Ship -> Run
  • 構成
  • エンドポイント 'hoge.arukascloud.io' のアクセスを許可(HTTPのみ)
    • HAProxyによるリバースプロキシ (malathon-lb)
    • Marathonと連携してコンテナの動的なポート変動にも追従する
  • malathon-lb以外の候補
    • haproxy-consul
    • hipache
    • etc.
    • malathonとの相性でmalathon-lbに
    • 最近注目されている traefik がstable releaseされてなかった
  • 「ゾーン」という単位で資源管理している

運用にともなう痛み

  • 様々なトラブル
    • 100コンテナ以上のビットコインマイナーが起動
    • Zookeeperがフラップ
      • 再起動を繰り返すコンテナがZookeeperログを逼迫
    • Zookeeperクラスタの同期が中途半端に
    • Docker Image で Disk Full
    • アップデート後に動かない
  • 対処
    • キレイに落とす(Reboot)
  • 幅広い設計が必要
  • 1ノード数万コンテナは幻想。実際は100〜200コンテナ
  • Dockerは枯れていない技術なので追いつく努力が必要

Q&A

  • Q. Docker Hub経由ではなくDocker imageの直接アップロード対応は?
    • いまのところ非対応サポートしきれない。
  • Q. Dockerイメージのキャッシュは?
    • してる。しててもディスクがあふれる
  • Q. マルチテナント対応の工夫は?
    • 特別な対応はしていない
  • Q. Docker標準のリソース配分機能が弱いけど、大丈夫?
    • 厳しい。設定が対応されればいいなと思ってる。

感想

実際に環境構築につかったソフトウェア(Mesos / MARATHON / Zookeeper)を知れてとてもよかった。Arukas 使ったことなかったので、話聞きながらコンテナひとつ立ち上げてみたらすぐにできた。アカウントはGitHubアカウントが使えて、コンテナ立ち上げはwebをポチポチ叩くだけ。簡単!

ベータリリース期間で無料で使用できます。しょうもないコンテナでリソースつかってすみません・・・。あとで落とします。

Mackerelの技術の全て。これまでの道のりと更なる発展に向けて

株式会社はてな @ さんの発表。

Mackerel概要

  • サーバ監視・管理のツールが当時は良い物がなかったので自社でつくった
  • 100週連続リリースを達成
    • 毎週火・木を定期リリース
  • オンプレからクラウドに移行してビジネスの本質に集中する流れ
  • モニタリングが大事になってきた
    • 『マイクロサービスアーキテクチャ
    • 「やっていくしかない」みたいなことが書いてある

Mackerelの開発

  • Mackerel開発運用体制
    • プロダクトマネージャ / エンジニア / デザイナー / インフラ / セールス
  • スクラムのような体制
  • オンプレミス環境
  • Scalaで開発
    • 大きくてかっちりしたものを作るのに向いている

Mackerel関連ソフトウェア

  • mackerel-agent
    • OSS
    • Goで書かれている
      • バイナリ1個で動く
      • クロスビルドできる
  • mkr
    • Mackerel 操作のためのCLIツール
  • Goの使い所
  • Perlでコードの中にテストコードを書ける(proveでテスト実行)のがよい
  • fluentdとの連携を勧めていて、プラグインも提供している
  • Capistranoをつかってる
    • ちょっとつらい
  • Graphiteをつかってる
    • 時系列データベース
    • 最近は結構コントリビュートしている

エンジニア向けSaaSを開発するということ

  • ドッグフーティングするのが当たり前なので楽しい
  • エンジニアコミュニティからものすごい感謝される
  • サポートのために新しい技術を広く学ぶ必要がある

Mackerelのこれから

  • 1000台のサーバを監視するシステムがなかったので作った
  • インフラ全体を管理する仕組みが必要となってくる
  • アルゴリズムによる支援をやっていきたい
  • 次世代の時系列データベースに刷新したい

感想

Mackerel、想像してたよりもかなり少ない人数で開発・運用していて驚いた。mackerel-agentはOSSになってるので活用してプルリクしていきたい。

MOM (Message Oriented Middleware) に求めるモノ

株式会社DMM.comラボ 大山裕泰 さんの発表。

MQ技術と各種実装(MOM)

  • Queuing
    • Brokerを介して通信。プロセス同士が直接通信しない
  • Pub/Subモデル
  • もしMQがなかったら
    • サーバが増えた場合などにアプリケーションでケアする必要がある
  • Broker-MQ
  • Broker-less MQ
    • クライアントにBrokerをもつ
  • 実装例
    • AMQP(RabbitMQ)
    • MQTT
    • Kafka
    • その他たくさんある
  • 完璧なMOMはない
    • アプリケーションの要件に応じて選ぶ

AMQP (RabbitMQ)

  • 柔軟なメッセージルーティング
  • Advanced Messaging Queuing Protocol

MQTT

  • 軽量なメッセージプロトコル
    • ヘッダが3Bytes
  • 高品質なメッセージの到達保証
  • At-most-once
    • 送りっぱなし
  • At-least-once
    • ack返す
  • Exactly-once
    • 確実に1度送る
    • メッセージを送った後に開封メッセージを送る

Kafka

  • スケーラブル
    • 順序保証

MOMを使う目的

  • 非同期通信
  • システムの孤立化
  • 負荷平準
  • スケーラビリティ
  • データストア

MOMの使用事例

  • SENSU
  • OpenStack
  • IBM
    • さくらもだいたい一緒らしい

結論

  • 完璧なMOMはない
  • アプリケーションの要件に応じて選ぶ

感想

MQ話題になってて、あまり良く知らなかったのだけど、いろいろあることがわかった。きちんと知るにはたぶん触ったほうが早いので、とりあえずRabbitMQとMQTTあたりから触ってみよう。

ベアメタルクラウドの運用をJupyter NotebookとAnsibleで機械化してみた

株式会社ボイスリサーチ 谷沢智史(@)さんと株式会社N.ジェン 丸岡隆さんの発表。NII(国立情報学研究所)にて構築したプライベートクラウドの話。

Jupyter Notebook を用いた運用

  • NIIでは研究で使うので要求が多様
    • 判断は人にさせる
    • 手順は機械的に再実行できるようにしたい
  • Jupyter Notebookにすべて書く
    • インストール手順
    • 動作確認
    • ディスク壊れた時用 Notebook
  • コードの実行はAnsible経由
  • 文芸的機械化
    • 機械的に再現できる
    • 人が読み解ける手順
  • オートメーションは大事だが、コミュニケーションが大事
  • テンプレートをGitHubにて公開

Jupyter Notebook の改善

  • 株式会社 N.ジェン
  • もともと運用のために作られたものではない
  • JavaScript拡張
  • Server Extension
  • nb extensionを2つつくった
    • 出力をタブで表示
  • JavaScriptのprototypeを拡張しているので衝突する可能性がある
  • server extensionはまだ使ったことがない
  • PullRequestもお待ちしています

Q&A

  • Q. 最初は試行錯誤があるのはわかるが、何周かして落ち着いたらAnsibleやJenkinsに移行するとよいのでは?
    • 固められればいいがバージョンが変わると手順も変わったりしてしまう

感想

研究所でのプライベートクラウド構築という、同じような境遇での話。すべてJupyter Notebookに書いておくというやり方は、情報とスクリプトを蓄積できて導入の敷居も低くてすごくよさそう。

仮想ネットワークアプライアンスで実現するネットワークエンジニアのためのDevOps

株式会社インターネットイニシアティブ 川又幸恵(@)さんの発表。

  • 運用自働化
  • ネットワークエンジニアの対象
    • ネットワーク構成
      • showコマンドなど
    • config設定
    • 障害対応
  • コマンドがベンダ毎にバラバラ
  • それでも自動化したい場合はオーケストレータの導入
  • expect とかになりがち
  • ベイビーステップ
    • できそうなところからはじめる
  • 仮想ネットワークアプライアンス
    • ネットワークOSのVM
    • 操作感は実機と変わらない
    • 挙動は実機と異なる
  • Devにおける活用方法
  • 本番環境と同じに
  • 仮想アプライアンス
    • VyOS
    • vMX,vSRX(Juniper)
    • vEOS(Arista)
    • SEIL/x86
  • VMとは言え毎回立てるのは大変なのでVagrantやpackerなどを活用
  • ベンダからディスクイメージを取得してVMを作成
  • 仮想アプライアンスのメリット
    • 安い
    • 何をしてもいい
  • 願望

Q&A (答え書き漏らしてます、すいません)

  • Q. スイッチのポート数は設定で変えられる?
    • VMNIC数が認識されるのでVMの設定で変える
  • Q. Aristaがすごく開発しやすそうだが、他のベンダは?
    • これから充実してくるのではないか
  • Q. 仮想アプライアンスのバージョン指定はできない?
  • Q. Aristaの実機持ってなくて仮想NW落とせるか?
    • 担当者に要相談
  • Q. 仮想環境のバグの切り分け / 不具合での苦労

感想

「本番環境にあるスイッチは開発に使えないし、実機は高いから余分に買えないので、仮想アプライアンスをつかいましょう」という、激しく同意する話。ただ、今回紹介してたAristaとJuniper以外に仮想アプライアンスがあまり無い模様(あるのかな、あとでちゃんと調べよう)。Arista の仮想マシンと開発環境がとてもよさ気なので、Arista 最強という結論。

Mesosphere DC/OS-データセンターOSの世界

クリエーションライン株式会社 木内満歳さんの発表。

  • 自己紹介
  • クリエーションライン
    • もともとCloudstackではじまった会社

DC/OS

  • データセンターの構築もウォーターフォールでは間に合わない
  • 要求される構成が頻繁に変わる
  • 今の開発はほとんど(8〜9割くらい?)オープンソースベースなので基盤管理もオープンソース
  • 現在のデータセンターの問題はPUE(電源効率)ではない
    • 先進的なPUEは1.1〜1.05程度で十分に省電力
    • PUE = (サーバの消費電力+空調の消費電力)/サーバの消費電力
  • DCの稼働率はめちゃくちゃ低い → リソーススケジューラの必要性
  • 第一世代: VMware DRSなど
  • 第二世代: コンテナ仮想化
    • Hyperviser型VMとはちょっと異なる
  • 第三世代: マイクロサービス
    • サービスを細切れにして必要な部分を改修できる
    • AWS Lambda もマイクロサービスと言ってもよいかも
  • (Mesosphereが言う)未来のコンピューティングとは
    • ハードウェアの効率的な利用
    • イムリーなリリース
  • DC/OS
  • 5月にオープンソース
  • アプリケーションリポジトリを持っている
    • 様々なアプリが1コマンドで導入できる
    • dcos package install spark
  • Dockerが稼働する
  • DC/OS とは Apache MESOS + パッケージマネージャ
  • Microsoft, Cisco, Apple etc. で使われている
  • Apple
    • Siriのバックエンド
  • Microsoft
    • Azure Container Service を DC/OS で
  • Autodesk
  • 理研 遺伝子データベース FANTOM5-CAGE

感想

DC/OSとても気になる。触ってみよう。会場の設備不具合でデモが見られなかったのが残念。 あと、関係ないけど会社紹介でちらっと出てた Neo4j も気になる。

全体の感想

  • インフラ系のイベントに参加することがあまりないので、知り合いもあんまりいなくて新鮮な感じだった。
  • 知らないツールたくさん知れてよかった。何から手を付けるのがいいのかもわからない状態だったのが、優先順位が掴めてきたので、重要そうなものから触ってみよう。
  • JTFでスポンサーしている会社が人材募集に力入れてるのだけど、ビジネスも技術もしっかりした良い会社ばかりだと思うので、新卒の人とか転職したい人とかは候補に入れておくのをオススメします。