読者です 読者をやめる 読者になる 読者になる

July Tech Festa 2015

要約

  • Docker監視はDatadog、New Relicの2強、DIYでやるのは分が悪すぎる
  • モダンブラウザでELB要らずになる???
  • はてなやpixivの若手は素でDocker運用はじめてるけど、次も使うかは微妙らしい
    • サービス事業者は開発用途に絞ったほうが幸せそう
  • Google Dataflowなるフルマネージド(MapReduce,Spark)++が出る
    • バッチとストリームの分界も含めてフルマネージド

真剣にDocker運用を考える人に、各種監視ツールとサービスを比較

  • naotaka jay hotta
    • Datadog
    • Dockerのモニタリングについて、真剣に考え始めているハズ
    • 5 year Datadog day event
      • 今日で5年目、NYでパーティーが始まっている
    • 「なぜその技術を使わないといけないのか?」
      • ビジネス視点で考え続けることが、エンジニアとして重要になってきていると思う

Monitoring 101

  • 先に結果を言うと
    • (AWS+Docker) -> New Relic + Datadog + Pagerduty + Slack
  • Datadogブログで

    • Collectiong the right data
      • 集めるべきデータ
      • WORK METRICS
      • RESOURCE METRICS
        • 使用量、サチュレーション、エラー、availability
      • EVENTS
        • コードの変更
        • アラート
        • スケーリングイベント
        • デプロイのフック
        • など
    • Alerting on what matters
      • 仕込むべきアラート
      • SYMPTOMS
        • 症状に対してアラートをかける
          • 対応を起こせる症状にアラートを仕込む
      • DIAGNOSTICS
    • Investigating performance ...
      • 対応手法
      • Work -> Resources -> Events
        • ResourcesからさらにWork->...にどんどんドリルダウンさせていく
  • "Datadog Monitoring 101 Collecting the right data"

Sass or DIY

  • どちらに未来があるのか
  • New Relic, Mackerel vs Zabbix
  • Docker界では
    • signal fx, Datadog, New Relic, Scout, Sysdig, AppDynamics
    • Mackerelが選ばれなかったのがとても残念
  • <-> Zabbix, sensu, InfluxDB, Hashicorp Products
    • DIYは紳士服に置き換えると英國屋さんになるのではないか
    • 自作・特注する人と、UNIQLOや青山(SaaS)を使う人の2極化していく
  • AWSは、勝手に値下げしてくれる」 vs 国内XXスタック
  • SaaSは、勝手に昨日を追加してくれる」 vs 事業俊敏性優先、化石化しないように必死に運用して追加が追いつかない
  • あなたの時間を使うときに、どっちが大事?
    • おそらく運用しているシステムを理解する方が大事で、監視ツール
  • Docker用のモニタリングシステムをDIYで作らなければならない時になったら
    • 自分たちのビジネスにおける、差別化要因・キーポイントになるのかどうか、それより優先事項が無いか、というのを確認してほしい
  • Docker含め、モニタリングシステムを自作する時代は終わった
    • 特注できる特殊な事業者は、はてなのように自作するのがよいでしょう

Monitoring Options

  • アメリカのDockerパートナーが挙げる監視SaaS
    • sygnal fx
    • sematext
    • signify
    • sysdig
  • ETP PROGRAM Monitoring
    • 6社がDockerから公認される
    • 理由
      • 明確にDockerのモニタリングはこれらにシフトしていく
        • iterate faster
        • no longer statically allocated
        • track ephemeral and rapidly scaling sets
      • 今まで以上に加速し、今まで以上に不安定になる
      • このスピード感に追随できると思われる事業者を選びました
      • これらの事業者はDockerイメージを持ち、docker runで監視を始められる環境を提供している
  • Dockerを動かすと、1コンテナに10のアプリ、10分に1回変更があると1台に60のムービングパーツが出てくる
    • 600人の子供を1人の保護者が把握し続けられるだろうか
  • Dockerをやる=監視ははじめから非常に高いレベルで開始しなければ、
  • naoya_ito「chef-solo使っていいのは中学生まで」
    • 時間をかけて積んでいいのは中学生まで
  • Why Docker Users Monitor
    • ddユーザーにDockerのモニタリングのキモを聞いてみた
    • コンテナのステータスは知りたい
    • コンテナエンジン、中身がどう変わってるか
    • 問題が起きた時に、コンテナが悪いのか、エンジンが悪いのか、それ以外か、が切り分けられていて欲しい
    • Dockerとの関連性が見えないと、モニタリングする価値が感じられないということの様子

      満たすべきポイント

  • 逆にこれらを満たせるのであれば、DIYでも大いに結構
  • Stable data endpoint
  • Container agent images
  • High monitoring granularity (1s)
    • モニタリング粒度は1秒単位で
    • そうでなければ、ぐるぐる変わるコンテナを追うのは難しい
  • Multi layer capability
    • apps
    • container
    • docker host
    • other parts
    • これらのすべてが関連付けられていないと、悪夢を見ているような状態になる
  • Easy submissionn of custom metrics
    • 自分がほしいと思うメトリクスを、簡単につけて簡単に集められないと厳しい
  • Strong metrics & event correlation
    • イベントとメトリクスを関連できる
    • Mackerelの積み上げグラフ、のような表示を正規表現やタグ一つでできる、くらいの手軽さが必要
  • Flexible Alert setting
    • アラートが簡単に設定できて、コンテナにまたがった(グルーピングみたいな)閾値を付けられる
    • コンテナのグルーピングを監視システム側で備わってないと、どんどんおかしくなっていくハズ
  • Communication hub

For a SAGE

  • 賢者曰く
  • Datadog(2255189)とNew Relic(19xxxxx)がdocker pull数で2強
  • Dockerだけのメトリクス
    • cgroups
    • docker api
    • やるべきでない2つ
      • in-container agent direct monitoring
      • kernel hacking
  • SaaSを見ていても、ドキュメンテーションが充実していないのがほとんど
    • Docker imageの更新履歴を見ると、どこが頑張っているかは明らかです
    • 答えは↑とほとんど変わらないです
    • データの粒度をちゃんと考慮していないのがほとんど
    • pricingがいい加減っぽい
      • 使われてるところが一番安い

SaaSの現状

  • New Relicの例
    • IPOしてる
    • 有名なのはNew Relic APM
    • DockerはNewRelic SERVERS
      • sysmondのフォーク、あんまり筋が良くない
    • Collation(メトリクスとアラートの連携)が弱いので要注意
  • AppDynamicsの例
    • 丸紅が日本代理店
  • Mackerelの例
    • 個人的にはすごく推しています、試してみる価値がある
    • コンテナは田中さんが一人で作ってるかな、という感じ
    • 価格体系がかなり関西ノリで、不透明なものが多め
  • sysdig cloudの例
  • Scout appの例
    • cgroups
    • イベントとのインテグレーションが弱め
    • 昔からあって、へんな資本が混ざってないので頑張ればワンちゃんあるかも
  • signal fxの例
    • 有望株、参加者のメンツが凄い、LinkedInで探してみてください
    • メトリクスの関連性についてめちゃくちゃ勉強してる
    • メトリクス連携がこのあいだステルスから抜けたばかりで、全開放したらインフラはゴリゴリ変わると思う
    • メトリクスの測り方が毛色が違いすぎる、料金体系が相対的に高い
  • Libratoの例
    • Fluentd agent(cgroup)を提供している
    • tdの扱いに長けている、td好きの方は考えてみては
    • 取得間隔が5秒、ちょっとDockerには不向きかなと
  • Datadogの例
    • 今挙げてきた問題はすべて解決しているつもりです

DIYでは

  • 新国立競技場みたいなことになるのでは
  • 最後に誰も責任がとれなくなる
  • ほんとにやるなら前佛さんあたりが...
    • LLD(Low Level Discovery)を誰が書くか
  • Prometheus
    • Rancherのブログで紹介されている
    • が、ブログ本文で「買ったほうがいいけどね」と言われている

まとめ

  • Datadog
    • フロントエンドからNew Relic APM
    • Pager Duty
    • Slack
  • 監視SaaSはそれだけでIPOできるくらい未来があるツール

    • Datadogでのメトリクスは1年間ロールアップされません
    • それ以上は有償オプション
    • 「ここから来たら反応せざるを得ない」という状況を無理やり作る
  • "How to Monitor NGINX with Datadog"シリーズも始まりました

    • 何を取るべきか
    • nginx社の方に査読してもらっています

Q&A

  • Ddはk8s連携は多分まだ、etcdは持ってたような
    • 桶ソリューションとのインテグレーションはまだどこも実装できてないと思う

失敗例を成功に変える、AWSアンチパターンの数々(Webアプリ編)

EC2にまつわる7つのアンチパターン

  • EC2一神教アンチパターン
    • AWSを古くから知っている人ほどハマっている
      • アプリケーションに口出しできないインフラエンジニアもはまりがち
    • 目的ごとにEC2を用意してしまう
      • 目的ごとにEC2を用意するため、インスタンス数が増えすぎる
      • 可用性の担保にも手間がかかる
    • SQS, Route53, RDS, S3, ELBなどEC2以外のサービスを活用する
  • ノースナップショットアンチパターン
    • 楽なバックアップです
    • EBSのスナップショット機能を知らない
    • 静止点を決めればずっと保持されます
    • スナップショット取得中はストップないしデタッチが必要です
    • EBSはAZをまたげない
    • 定期的に不必要なスナップショットを消すこと
      • 差分課金なので莫大な請求はないけど、整理ができなくなってくる
      • 「消す」という作業で目的を思い出せます
  • AMI無しアンチパターン
    • 手順書通りに作業したい人は不思議なくらいたくさんいる
    • AMI作成は難しくありません
  • AMI至上主義アンチパターン
    • AMI作成をバックアップだと思っている
    • 再起動なしAMIはリスクを伴います
      • メモリ内データのフラッシュをユーザーが行う必要が出てくる
    • バックアップはEBSで十分
  • インスタンス振動アンチパターン
    • オートスケーリングの設定が敏感すぎる
    • CloudWatchの条件ソースが不適切
    • 起動条件の4倍程度に緩和させておく
      • 80%スケールアウト→20%スケールイン
    • 1時間切り上げ課金なので、55分で自殺する方法も
  • 単機能AZアンチパターン
    • サブネットごとに「DB用」「アプリ用」などとわけてしまい、それぞれを複数設置し忘れる
    • 単一AZしかない機能が落ちて、結局システム全断
  • とりあえずELBアンチパターン
    • モダンブラウザを知ろう
    • 冗長化のためにロードバランサを必ず置かないといけないと古い知識のまま勘違いしている
    • ロードバランサを置くとサーバからプッシュできなくて困る、ということがある
    • モダンブラウザ×DNSラウンドロビン
      • ロードバランサは適材適所に

キャパシティにまつわる2つのアンチパターン

こころがけるべき汎用的な3つのアンチパターン

  • ノールック明細アンチパターン
    • 明細は適宜確認しましょう
    • 毎日、毎時アップデートする機能があります
    • 最近95%の信頼区間で月末利用料を予測する機能もつきました
  • インフラ塩漬けアンチパターン
    • AWSも成長します
    • 3ヶ月に一度、もしくは1年に一度見直しましょう
    • サービスは四半期に一度は見直す
  • 机上の空論アンチパターン
    • JUST DO IT
    • 事前のキャパプラに時間をかけすぎる
    • とにかく小さく試してみること

ウェブアプリ向けアンチパターンまとめ

  • 知る
  • 議論する
  • やってみる
  • アンチパターンは有益

    1. 恨み節をブログに書く
    2. 面白おかしく同僚と話す
    3. 打開策を発表
  • 皆さん、モダンブラウザですよ!

    • 勉強をお忘れなく

若手インフラエンジニアが語る技術トレンドと数年後の未来

  • @hfm
  • @rrreeeyyy
    • Yoshikawa Ryota
    • ハートビーツ
  • @catatsuy
    • KANEKO Tatsuya
    • pixiv '13 10~
  • @y_uuk1
  • モデレータ: @deeeet
    • 楽天
      • アプリ→去年11月から社内PaaS開発運用
    • @tcnksm

#wakateinfra

  • 新卒入社3年以内
  • インフラにかかわる仕事をしている

技術トレンドについて

Infrastructuro as Code

  • JTFで長らく語られてきたテーマ
  • 息を吐くようにサーバ設定をコードで書いてきた世代
    • プロビジョニングツール何使ってる?
      • 少なくともChefかPuppet
      • みんなAnsibleは手を出している
      • Itamaeが使われ始めている
    • どんなところが良い?どんなところがイケてない?
      • @rrreeyyy: Chef, Ansible, Itamae
        • ハートビーツがMSPの会社、ユーザによってツールが違う
        • 全社的にはChef、監視設定を作るときに内部情報の参照で柔軟なものを使っている
        • ミドルウェアインストールはssh経由で済むAnsible, Itamaeにしている
      • @hfm: Puppet, Itamae, (Ansible)
        • ペパボは'07からPuppet資産がたまっている
        • Itamaeは今年の新卒研修から構成管理ツールとして使っている
          • PuppetやChefはツールそのものの学習コストによりがちだった
          • 宣言的な記述、コードの保存にフォーカスしたかったのでItamaeを選出
          • Serverspecも使っていたので
    • 「Chefの学習コストが高いのでAnsibleに移行します」事例
      • 複雑な環境を触ることが多いので、学習コストより柔軟性を取る人もいる(@deeeet)
      • Itamae -> Chef、といった段階的な移行が個人的には良い(@rrreeeyyy)
      • 2台なのにChef、は逆にナンセンス、スケールさせたい需要の強さで
    • 本質的にはどれも複雑なことをやっているものだと思う(@y_uuk1)
      • ChefはRubyで書ける、というのはそれなりにアドバンテージがある
      • 今から選ぶならItamaeやAnsibleもアリだとは思う
    • Puppet, Chef, Ansibleの3つはあんまり学習コストは変わらない気がする(@hfm)
      • 設計のほうがヘビーで、それはツールのせいではないような気がする
      • サーバ構成に起因する部分が少なからずあるので、話すときは分けておきたい
  • Chefのクックブックを管理している人が1人の時はとても綺麗なんだけど...
    • @deeeet のところでは人が増えて汚くなってきてる
    • 同時にChefをガンガン触ることはあんまりなくて、今のところあんまり考えていない(@y_uuk1)
      • 管理しようと思ったら、Linterとかで規定できるとよさげ
  • pixivではシェルスクリプト+Serverspec(@katatsuy)
    • nginx設定をまくためにAnsibleを使ってる、くらい
  • Serverspec

Container

  • runCとOpen Container Project
    • DockerとCoreOSが合流
  • kubernetes v1.0とCloud Native Computing Foundation
    • k8sはGoogleから離して開発するよ、という宣言
  • コンテナ使ってる?
  • 使ってみてどう?
  • IaaCは2年くらいかけて浸透したけど、コンテナは2年後どうなってると思う?
  • @y_uuk1: 本番ではなく、パッケージビルドやCI環境(Jenkins上)、STG環境にDockerを使っている
  • @catatsuy: 本番投入されていて、IDCFクラウド上のCoreOSインスタンスにpixivマンガのAPIコンテナが投入されている
    • 普通の運用の範囲では特に大事無く動いている
    • JVM周りをDockerfileに丸投げで来たのがメリット大
    • デプロイ周りのノウハウがたまりきってないので、pixiv本体みたいな大規模導入はまだ難しそう
      • 今のDockerだとiptablesでNW周辺やっていて、パケット変換のコストやデプロイが整備されれば
      • k8sなどの桶は使っていない
  • @y_uuk1: Dockerを使うメリットを意識せずに使うと大変になりそう、今は各種環境のパッケージ化にメリットを感じて始めている
    • たまにdocker buildがコケたり、Jenkinsジョブ途中で切るとシグナル周辺でゴミが残留したりする
    • 本番ではDockerで展開せずにイメージだけ持ってきてchrootで動かしたほうが素直なのでは、という気がする
  • @catatsuy: 今のところ大きな問題は起こってないのであまり進展は無いけど、次もDockerを使うかは再考の余地あり
  • @deeet: imageを作るまでは良くて、CloudFoundryもDockerは使わずDocker imageだけ使えるようにする流れがある
    • ランタイムの流れが整理されるともっと使いやすくなるのでは、という印象がある

技術習得について

  • どうやってキャッチアップしている?
    • だいたいみんなはてブ
    • とりあえずでたら触る
    • ソースが公開されれば読む
    • おすすめ情報源
      • @y_uuk1:
        • kazuho's weblog
        • blog.nomadscafe.jp
          • kazeburoさん
        • こういう考え方・アイデアがある、というのを吸収するために
      • @hfm:
        • あんちぽさんの本棚
          • CTO、読んだ本が書評も付いて会社でただで読めるようになるので便利
        • 人間とウェブの未来
          • matsumotoryさん、ここにいる人はみんなファン
      • @catatsuy: ゆううきブログ
      • @rrreeeyyy: blog.kubernetes.io
      • @deeeet:
        • CoreOS blog
        • Influx blog
        • kelseyhightower
    • おすすめ本
      • @catatsuy: 『鈴木さんでもわかるネットの未来』
        • あたりまえだと思っていたことを改めて言語化してもらって、再発見がたくさん
        • 10年上の世代がさらに10年上の世代に若者の常識を説明している
        • 自著を書いてないのは若者らしいですね(@deeet)
      • @rrreeeyyy: 『分散システム―原理とパラダイム
        • 和著は高く、訳も怪しい、よめるひとはタネンバウム先生の原著がオススメ
        • ココ最近の分散システムの根幹を理解するために
          • Raftとか
  • 最新技術追い過ぎ問題についてどう思う? 割愛

今後のキャリアについて

  • 今後どのような仕事をしてみたい?
  • @y_uuk1
    • はてなで2年もたってない
    • 長期で運用するサービスが多く、はてダなんかは10年以上
    • サーバを増やせばとりあえずスケールする、のためにいろんなアイデアが詰まっている
    • 成長とともに詰まないために、アーキテクチャを新鮮に保ち続けるところにいたい
  • @catatsuy
    • 多分ずっとインフラエンジニアではないと思う
    • 最初は開発で入った
    • インフラの知識を活かしてアプリ開発したい、これができている人材は結構少ないと思う
    • パフォーマンスチューニングなんかもアプリだけの人は難しいとおもう
    • 教育系の本出したけど、当面はアプリエンジニアの職を奪っていきたい
  • @rrreeeyyy
    • 新卒2年目だけど、入社5年目
    • MSPだけど、「運用を消したい」が野望
    • 今や運用が一番手がかかっている、まだまだ省力化出来るハズ
    • 自動化プロダクトへのコントリビュートや、設計を考えていきたい
  • @deeet
    • 運用のしんどさをどれだけ軽減していくか、というのをよく考えていた
    • 実際の運用をどうよくしていくか
    • Hashicorp脳なんで、運用をよくしていくプロダクトがどんどん出てくるだろうと思う
  • @hfm

    • ロリポップみたいな、ホスティングサービスをやってた
      • カーネル周辺の知識を潜りたいと思っていた
    • 会社の中での学習環境を作る方向でもっとコミットしていきたくなった
    • 研修と教育は分けて考えている
      • 教育を会社でやると、会社で使っている業務知識を詰め込もうとしちゃいがち
      • 「何を教えたか」までで、受講者がどう変化したかまで踏み込んでいることはあまりない
      • 「教育」=詰め込みのイメージが強め
      • 自分たちがもっと進んで興味関心のあることに進んでもらえるようになってほしい
        • ブログに動機や詳細を書いています
      • そういう意味での「教育」はやらないと思っています
    • 今年いっぱいかけて研修、10月からOJTの予定
  • Q&A

  • 近い年の同僚と、どうやって高めあいたいか、みたいなものはありますか
    • 壇上のデキる若者たちと、そうではない人との関係性
  • @hfm:
    • ペパボはサービスごとにチームが分かれているが、インフラは横串を通している
    • ぽよん会(情報共有会)をやっている
    • 自分の学んだことをアウトプットしたり、SlackやSNSに垂れ流せる環境
      • 基本的には自分からつかみに取って行っていく環境でないと厳しい、という前提がある
  • @y_uuk1:
    • 高め合う、あんまり考えたことがない
    • 今、自分より年下のエンジニアはいない
    • はてなはみんなとても優秀で、追いつこうとしている間に自然と高まることが多い
      • 自分で高まる人ばかり集めている、ということなのかもしれない
    • ブログのはてブ数xxxで次の技術勉強会時に🍣...みたいな実績解除システムがある

Googleが描くMapReduceを超えたビッグデータの世界

  • Your Data and the World Beyond MapReduce
  • Kazunori Sato

MapReduceを取り巻く世界

  • GFS('02、'04論文公開)
  • MapReduce('04)
    • 超巨大な検索インデックス(100PB)
    • 最初期ではOracleMySQLを試していたらしい
    • ラリーとセルゲイがHCPの学術の人たちを大量に雇ってスクラッチ開発
    • GoogleではMapReduceは使っていない
      • ウルムさんが'13に口を滑らす
      • 社内でMapReduceのツリーを削除するパッチが承認待ちになったりした
  • Dremel('08)
    • またの名をBigQuery
  • Flume('10)
  • MilWheel('11)
    • この3つの技術

Google BigQuery

  • 分析専用クエリサービス
  • BigTableでは検索に不向きなので、検索用DBとして開発
  • Google社内では「ビッグデータ」というワードはあまり出ていない
  • 佐藤さん、最初はGoogleアドアーズAPIのサポート
    • 日本最大の顧客のサポート、20TB/日
    • 「東京のモバイル向けに出稿してるこの広告全然出てこないんだけど」という電話がくる
    • そうでなくとも、ディレクターから「昨日出したこの機能動いてる?」というメッセージが来る
  • すぐにログを解析したい、さもなくば仕事が回らない
    • MapReduceでは追いつかない
    • Dremel
      • 入社して最も衝撃的なプロダクトでした
        • Dremelのペーパーは'10、当時はDrillやImpalaはなかった
  • Google社員の2/3はDremelに依存し、残りの複雑な1/3のクエリをMapReduceで書き起こすような状況だった
    • 営業やCSがDremelの糞SQLをコピペしてガンガン使っていた、それでも何の問題もなく返してくれる
  • フルマネージド、管理者不要、でもハイパフォーマンス

    • 1000億行のフルスキャンを20秒以内で
  • デモ

    • REGEXP_MATCH(title, r' Cloud ')
    • インデックスの通用しないクエリ
    • (7.1s elapsed, 3.54 TB processed)
    • さらにGROUP EACH BY(Hadoopでいうシャッフル)を掛けても30秒未満
  • 列指向ストレージ

    • titleだけのストレージ、dateだけのストレージ...とカラムごとにHWを分離
    • RedShiftでもおなじみ
  • MPP(Massively Parallel Processing)

    • いわゆるImpalaのMPPとは比較にならないMassiveっぷり
    • お試しクエリでも1500~2000台で働く
    • 5000~10000台のディスクをぐるぐる回す
    • GoogleはDCの構造が違う
      • 台湾やアメリカにあるが、特定サービスに結びついているものは全くない
      • すべて汎用サーバ
      • Borg
        • Google謹製コンテナ技術
        • GCP、検索、GmailAndroid....すべてのサービスがBorgでパッケージされ、任意のリソースで動く
        • GCPVMサービスはコンテナの上でVMが立ち、その上にDockerが動いたりする
  • Fast Aggregation by Tree Structure

    • ツリー構造でネットワーク上に展開、分散→収束
    • Google検索のアルゴリズムそのもの
    • LSIから独自設計、超広域NWを支える
      • GoogleのHQはチップの専門家を抱えている
  • BigQueryは1分以内に解析対象にできる

  • RasPi→td→BigQuery

    • 世界最大規模のIoT基盤がもうできちゃった
    • PubSubやMQTTを意識しなくても良い
  • 事例: セブン&アイ

    • GA、Oracleの購買履歴をBigQueryへ
    • ポチポチでDMPが完成
  • Google社内にとっては大きなデータ、小さなデータを区別する必要がなくなった

  • RedShift, Hadoop, BigQueryで比較してBigQueryが1/3くらい、という記事も
    • 日本最大のユーザはストリームをガンガンに使って数万〜数十万円
    • 何につけてもフルマネージド、クエリを気に掛けられる人である必要すらない

Cloud Dataflow

  • まだベータ、グルーヴノーツなどのアーリーアダプターが使い出している
  • Flume + MillWheel
  • ユースケース
    • バッチ、ストリーミング
    • SparkなどでやっているETL、フィルタ、前後の処理など
    • 自前で書いたML処理を投入
      • BigQueryだけでできるのは相関を出すくらい、それ以上はRと組み合わせる必要があった
  • Dataflow = BigQuery + BigTable + Google PubSub(AWSでいうKinesis)

Pipeline

  • MapReduceは普通多段になる
  • DataflowはそのDAGをJavaPythonのコレクションに落とし込める

    • PCollections
      • 無限のデータを扱える、シャーディングやストアはすべてDataflow側で判別
    • ParDo
    • Count
    • Top
  • フルマネージド、アプリケーションロジックに集中できます

  • http://cloud.google.com/dataflow

今明かされる!シンラ・テクノロジーのインフラへの挑戦と舞台裏

ゲーム市場の移り変わり

  • '75 ゲーセン
  • '80~ コンソールゲーム
  • '00~ オンラインゲーム
  • ユーザがハードウェアに対する投資が少なくなればなるほど、市場は拡大する、というコンセプト
  • ポータビリティとジェネラリティが鍵
    • ゲーセン: 1台1ゲーム、ポータビリティなし
    • スマホ: いろんなゲーム、ポータビリティ+センサ、カメラ、音楽プレイヤー、電話
  • クラウドゲームシステムが次のメジャーゲームプラットフォーム

    • ビデオ出力さえあればどこでもできる、究極のポータビリティとジェネラリティ
    • クラウドゲームは市場を拡大していく
      • HW投資がより縮小されるので
    1. 今のインターネットの状況では、クラウドゲームは難しいのでは?
    2. 投資のシフトが起こり、DCのスペック向上がクラウドゲームを可能にする
  • 経営のビジョンなので、開発チームでは真理として扱われます

  • 経営「クラウドゲームに取り組みなさい

    • 上になればなるほど、オーダーは悲しいくらいシンプルになる
      • 研究部長時代のオーダーは「開発を効率化して下さい」だった
    • 指示をブレイクダウンするのも重要な訓練、そうしておけばこういうことがあっても困らずにすみます
  • 何をするか

    • 徹底的に調べる
      • 既存サービスの事例
      • 要素技術
    • どうやって
      • 論文やインターネットの調査
      • メールを送って質問
        • 書いてある=送ってもOK
        • 意外と帰ってこなかったことはなく、良い時代になりました
      • 大学院に入ってみる
      • HWベンダへのヒアリング
      • 大学との共同研究
      • 毎日飲み会(自腹)
    • ともかく、RPGのごとくブレイクダウンに必要な知識を集める
    • しかし社内に蓄積されている知識を活用できるかどうかは最も重要

既存クラウドゲームのインフラストラクチャ

  • 典型的には1VM=1ゲーム
    • Intel Xeon E5-2670, NVIDIA GRID K520/K2
    • とても高い、これで4人しか繋げなかったり
      • いくらもらったらペイできる...?
    • すごいコスト課題
  • プラットフォームならではのゲーム

  • ↑2つを一旦経営にフィードバック

  • コスト課題をどう解決するか

    • ボードゲームや高度なAIはCPUの並列度をスケールアップ
    • グラフィックヘビーなゲームはGPUが巨大化
    • ここが固定的だとロスが出る、これを解決すればコスト効率が上がるのでは
    • ウルリッヒの製品アーキテクチャ('94)
      • インテグラ
        • =All-in-One
      • モジュラ
        • スロット
          • =それぞれ専用スロット
        • バス
          • =汎用端子で接続
          • '15現在でまだ達成されていない
        • セクショナル
          • =数珠つなぎ
    • アーキテクチャないし要素機能の変更
    • スマホ:入力装置と表示装置の統合
    • アーキテクチャ、要素機能、インターフェースの変更は革新的な商品開発に結びつく可能性がある

リモートレンダリングアーキテクチャ

  • イーサネットを汎用インターフェースに
  • ゲームコンテンツの計算とレンダリングを別サーバで実行
  • レンダリングプロセスをシリアライズしてまとめて実行
    • キャッシュ効率向上、リソースのシェア
  • レンダリングAPIデファクトDirectX
    • DiretXのAPIをリモートで叩けるように改修、過去のゲームも流用できるように
  • 従来のNWゲームはインターネットを通じてメモリを同期
  • クラウドゲーム内では1プロセス内で同期
  • 1:Nアーキテクチャ
    • 4入力→1プロセス→1レンダプロセス→4出力
  • ここまで経営に報告→'12 モントリオールでR&D開始

  • インターコネクション: 必要なレンダリングコマンドのサイズは3Gbps/s

  • プロセスが死ぬと全員道連れ、接続ユーザ倍の信頼度が必要
  • リサーチ項目
    • FPGAボード性能評価
    • イーサネットカード
    • TCP, UDP, RDMA
      • Remote Direct Memory Access
        • ヘッダがほぼ無いので帯域節約
        • 32kbで50マイクロ秒
    • 圧縮ソフトウェア
      • Snappy, LZO, LZ4
      • Intrincip(?)で極限まで最適化
        • CPUは命令の解釈は早いが、メモリからの読み出しが遅い
        • 4つ書いてCPUを暇にさせないように
        • 一般的なアプリの挙動は逸脱していく
          • ハイパースレッディングはOffった方が早くなる
      • アフィニティ
        • 各CPU間の接続
        • 対向のCPUのキャッシュに行こうとするとQPIを通る必要がある
  • 改善の推移
    • 4ヶ月くらい頭打ちしていたが、ベアメタルからVMに置き換えたら目標以上の値に
    • ビデオエンコーディングを統合しても目標値以上を保った
  • ブレイクダウン
  • 必要な知識
  • たまたま全部触ってました
    • 究極のYes man
      • 体が空いてる限り上司からのオーダーは未経験でも全受け
    • 先約優先
      • 断るのが面倒くさいので
    • 勉強する
      • 「岩崎さんは○○はわからない」と言われると勉強しちゃう
      • ひとしきり勉強したらあんまり話しかけられなくなりますが...
    • →たまたま全技術要素について事前知識があった
      • でももうちょっとうまくできたような気もします

技術者としてのスーパージェネラリスト

  • 田坂広志氏の定義は縦、自分のものは横
  • できれば1つの専門分野
    • 周辺分野の基本をマスターする
    • 残りはコミュニティやカンファレンスから積極的に参加することが大事
      • JTF2015に参加している皆様は素晴らしい