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

HashiCode#2 HashiCorp道場番外編 〜HashiConf 2015報告会〜

  • HashiConf 2015

Otto

  • Vagrant, Packer, Terraformを抽象化
  • GitとGithubの関係をOttoとAtlasに対応させたい様子

Sessions

  • Electric Cloud
    • 課題:Wikiを使わなくなってしまった
      • '10: 一人で何でも
      • '11: メンバが増えてくる
        • 10程度のWiki
        • 古い、不完全、見つからない、誰が管理するのか?
    • Vagrantを使い始めた
    • 新た問題: 複数アプリを複数サーバで動かしたい、Vagrantは環境切り替えが大変
      • Terraform導入
    • いろんな開発環境が出てくる
      • テスト環境まではTerraform、本番環境はDockerという棲み分け
    • 新しいツールを導入するとき、どうするか
      • 仮説を論理建てて、そしてツールやソリューションを見る
      • ✕:「このツールすげえ」「誰もこんなのしないよ」
        • とはいえ、外からは技術を追ってるように見えるかも
  • Groupon
    • Databases as Pets
      • ペットのように手厚くかわいがる
      • 家畜のように病気になったものはとっかえひっかえ
    • State Engine
      • Consul, Consul Templateを組み合わせてステート管理をするサーバがいる
    • Efficacy vs Efficiency
      • どこまで効率化するか、という問題
      • ヒトの三倍くらいがグルーポンの目処
        • 3回やったら自動化、という感じ
  • Capital One
  • Pinterest

    • Layer 0, 1, 2
      • AWS: 0
      • ベース環境: 1
      • 本番環境: 2
    • Jenkins
      • 開発環境のイメージを回して、本番にイメージでもう一周
  • 詳しくは: http://hashiconf.com/schedule.html

KeyNote day1, day2

  • Mitchell Hashimoto氏
  • Vault 0.3公開
    • 使い捨て認証のサポート
  • HashiCorp DevOps
    • Slackの画面にAtlas - Packer BuildsAtlas - Terraform Builds
    • EAST-AWS Services(35) Nodes(61)
  • Nomad

    • 多分ノーマッド
    • 何をするか
      • 分散スケジューラ
        • k8sより多様な環境に
      • デプロイを簡単に
      • ジョブの詳細設計
    • 対応環境
      • コンテナ対応
      • HCLによるジョブ定義
      • リソースを最大限に集約
    • 使用例の一部
    • アーキテクチャはConsulのそれに近い
      • 内部では実際にSerfやConsulが動いてるっぽい
    • nomad agent -devチュートリアル
    • 設定ファイルはApache Auroraで見たような...
  • Otto

    • おっとサーバ店ではありません
    • Vagrant後継ソフト
      • 開発者はデプロイしたい
      • マイクロサービスは未来
    • otto dev, otto build -> Vagrant
    • otto infra -> Terraform
    • otto build -> Packer
    • otto deploy -> Nomad
    • Appfileがあってもなくても動きます
      • Vagrantfile, Terraform Templatesなど既存のリソースも読んでくれる
      • Appfileは開発中だけど、最終的にコレ1ファイルのバージョン管理で完結したい
        • otto compileでAppfileから各フォーマットに変換、中間ファイル生成みたいな
      • 必ず裏にConsulが居て、スケール管理がしやすい
    • windows版はバギーなのでまだおすすめしません
    • otto status
    • デプロイ先は今はAWSのみ、拡大予定
    • Vault, Atlasと連携予定
    • 既存の構成管理ツールとのすみ分けは?
      • 現状Appfileは既存構成管理ツールとの互換性がない、殺しに来てるのではないか
    • 開発ツールでもあり、デプロイツールでもある
    • Docker対応
  • おまけ

    • HashiCorpのポートランドは西海岸の山の中でした、浮浪者も少なくて安全でした
    • 各サービスのステッカーをIDに貼って、
    • HashiCorpの箸が配られていた
      • ロゴの彫刻入り、ちゃんとしてる
    • アメリカ入国は指紋をとった人は2回目以降アメリカ人の列の端末でも入国ができます、日本語メニューもあります
  • Q&A

    • バージョンアップ頻度は?
      • 可能なかぎり速く
      • Issueは上がっていて、進行状況は見える
      • 3ヶ月〜半年ごとに0.1は上がってるという感覚
    • Serf自体はConsulに吸収される?
      • 多分どちらも残り続ける
      • Serfはオーケストレーションツール単体としては優秀、しかしConsul内部にもいる
      • Consulに実装する、とはいっているが未実装
      • ホントはSerfとConsulで別の仕事をするはずが、Consulで全部できちゃってる、というような状況
  • http://hashidocs.jp

LT

吉田さん

  • @yoshidashingo
  • mizzyさんもHashiConfに
    • otto testがない
    • もしかしてあんまりMitchelテストが好きじゃない?
  • VagrantだけRubyプロダクトが残ってる
    • Vagrantがgoに書き直されることって有るんだろうか?
    • (前佛さん)ないみたい、もしくはottoが取り込むかも
      • Vagrant->ottoは数年かけて徐々に完全移行に向かう、ということらしいです
  • 20のセッションの半分以上はだいぶショボかったです
    • 「使ってみた」レベルのセッションもある
    • CFPの期間があったので、日本のユーザー事例で半分もワンチャンある
    • 雰囲気はアットホームでした

@deeet

  • 「ottoを読む」
    • 第一印象:すごくPaaSに似てる
      • herokuのheroku pushのごときotto deploy、抽象化のレベルが近い
    • スケールを簡単にするのはまだできない

    • モニタリングはまだあまり考えてなさそう

    • コードを見てるとめっちゃテスト書いてるんで、嫌いではないと思う
      • あんなにテストとドキュメント書く人はめったにいない気がする
  • Nomad

    • スケジューラ、有名なのはYARN
      • リソースをスロットごとに分けて、Map/Reduceを割り振る
      • スロットが大雑把でリソースが結構あまりがち
    • Mesosはリソースマネージメント面に注力
      • 「こんだけのリソースが欲しい」に対して合うホストを返す
      • Information Hiding、そのホストで動いてる他のジョブを考慮しない
    • Nomadの凄いのは2-Level Model
      • Google Omegaを参考にしているので、ホスト内の他のジョブの状況(帯域つかうジョブとか)を気にしてくれる
    • OttoはGlobal State Model
  • Q&A

    • IoTへの細かいCSV数百種類のデリバリを自動化する術はあるか
      • Serf agent経由でイベントを握らせて、サーバに問い合わせるとか
      • HashiCorp以外であればBourbon IoT(?)
    • クリエーションラインのサポートはどういう?
      • 「ご相談下さい」
      • 今メニュー化してる最中です
    • モニタリングツールの成熟が遅れている?多様な環境の監視はどうする?こまめに見るしか無いのか?
      • 確かにこれからどうしようという感覚
      • とりあえずは環境に合うように作っていくしか無い、銀の弾丸は今のところない
      • 個々の画面から取れる情報(Zabbix/CloudWatch)を個別に見るしか無いのだろうか
        • 時間とお金があればゼロから考えなおしましょう、となるでしょうが...

SORACOM Developers Conference #0

SORACOM 新機能発表

  • '16 1/27 SORACOM summitやります
  • このイベントが終わるまで、AmazonでBuy 1, Get 1
    • レビューを書いてくれたら1枚進呈
  • RasPiにドングルを挿す
    • 8880円を本日5000円/本、先着10本

新機能を発表します

カスタムDNS

  • 独自のDNSサーバを指定可能
  • 端末に設定するDNSアドレスが追加されました
  • Groupごとに異なるDNSサーバを設定可
$ adb shell
adb$ getprop net.dns1
adb$ getprop net.dns2
  • DNSのQuery Log
    • デバイスの正常化道の確認
    • 不正利用の検出
  • プライベートDNSの利用
  • Dynamic DNS
  • DNSフィルタリング
    • アクセス先限定
    • 悪質サーバ回避
  • DNS応答を変えて接続先を切り替え
  • 未認証ユーザの認証用ポータルへの誘導

  • 利用時の注意点

    • 反映されるのはセッション確立時
    • 反映させるには一旦切断、APIコールでDeactivate->Activate
  • SIMカードあたり+1日3円
    • 10月中は無料でご利用いただけます

SORACOM Beam AWS IoT連携

  • re:Inventで登場、AWS IoT
    • 奥さん「あなた、大丈夫なの?」
    • 大丈夫、かぶってません
  • SORACOM AirAWS IoTに直結のモバイル通信
    • SORACOM BeamによるSSLオフロード
  • AWS IoTのThingsの認証の仕組みはすべてのデバイスに証明書を突っ込むモデル

    • クライアント証明書をBeamで管理
  • '15 12/11 SORACOM User Group Tokyo開催します


LT大会 怒涛の18連チャン

  • 本日の景品: フルスケールエンジニアT
    • #タマン賞: もっともウケたヒト
    • #ケンタ賞: もっともギークなヒト
    • #ヤマン賞: もっともスベったヒト

SORACOM イベントハンドラ

  • SORACOM ヤマンさん
  • JavaFXとDynamoDBでMVNE機構を実装しています
    • SIMを焼いたり解約したり

AWS IoT

  • AWS 榎並さん
  • AWS IoTでようやくMQTTも
  • Tokyoリージョンも利用可能です
  • メッセージブローカー
    • MQTT, HTTP1.1
    • 要望を下さい
  • 認証とアクセス許可
    • TLS1.2, IAM
  • SQLライクなメッセージJSONパース
    • Kinesis, Firehose, DynamoDB, SNS, S3, Lambda
    • 他のメッセージへのリパブリッシュ
  • シャドー
    • デバイスがオフラインでもメッセージ受信できる
    • 非同期通信
  • レジストリ
    • デバイス1つ1つの管理、Key-Valueによるメタ管理

SORACOM * AWS IoT(仮

  • ジャストインケース 松井さん
    • @j3tm0t0
    • 好きなSIM: DN(DNP製)
  • RasPi -> Beam -> AWS IoT

SORACOM Airとその先に IoTのThingの今とこれから

  • アットマークテクノ 竹之下さん
    • @koyo_take
  • ハードの話だけします
  • IoTの事例
    • ビアバーの世界のIoT
      • 注ぎすぎの無駄を11%削減
      • Veverage Analytics(WeissBerrger、イスラエル)
    • Amazon dash button
      • ハードはタダ、日用品メーカーの宣伝広告費から出ている
    • 3Dのプリンタの予防保守
  • デバイスとどう繋ぐ
    • これからは無線
    • Sub-Gたい、Mesh構成
    • Wi-SUN、Zwave
    • 機器管理プロトコル
      • どれを選ぶかはお金の話が絡むのでケースバイケースです

SIMの開封からSMS受信までを5分でやり切る

  • ぷらっとホーム 松下さん
    • OpenBlocks IoT BX1
  • ネタがない、メソられている!
  • 肉体芸
    • SIM開封からSMS受信まで

SORACOM AirでIoTするなら3G Rayで簡単に

  • SKYDISC 橋本さん
    • 福岡から来ました
    • デバイスに強い県です
  • SORACOM、何が凄いのか
    • 導入の簡素化
    • 低価格
    • セキュリティ
    • 通信の拡張
  • まずは動かす
  • 3GRay
    • 汎用ピン採用、3G/GPSへのアクセスをAPI経由で

RasPi + ダイヤルスイッチで

  • アドベン 吉田さん
    • 好きなAPI: /subscribers/{imsi}/deactivate
  • SORACOMといえばコンソール
    • プラン変更、一人MVNO気分
  • ロータリースイッチでプラン変更できるようにしました
    • node.jsラッパーを使って

どこでも光るよ回転灯

  • アレグロスマート おさださん
  • 振動センサー→RasPi→回転灯&Slack
  • リアルタイム性を強化してます、が、Sparkが遅いので別のアーキテクチャを模索中です

IoTによるがんばらない介護

  • Z-Works 小川さん
  • 健康寿命と実寿命の差、約10年
    • この間、介護が必要な時間
    • ここでヒトの代わりにIoTを
    • 死活監視
      • やりたいことはご遺体を速く発見する、ということ
      • 24h以内に見つけたい
  • Z-Works 主要IoTデバイスで展開
    • ヒトの行動を表すAPI
    • ホームセキュリティ
  • 重篤化予防
    • 非接触で3m以内の心拍
  • 開かないスマートロック
    • 夜に監禁するロック
  • 健康寿命をのばす
  • スマートターミナル
    • がんばらない介護を実現した上に、手を繋いで別れを言えるように

育児にも活用できる家庭用IoTのススメ

  • @mana_cat
    • 4歳と7ヶ月の男児二人と保活をしてます
    • TechGIRL、TechLION
    • 先月から電子工作を始めました
  • 赤ちゃんには温度管理が重要です
    • ピジョンのデジタル温湿度計、をIoTで作ってみましょう
    • IoTスーパーこまち
      • RasPi + USBモデムで10000円
      • OS: pidra(Fedora20ベース)
      • python + s3cmd > csv
      • 311円/月で始められます

AndroidでもSORACOM Airを使いたい!

  • @mhidaka
    • 組込からモバイルまで
    • techbooster.org
    • DroidKaigi
  • 通信料を節約するアプリを作りました
  • AndroidVPN機能を転用、ローカルVPNサーバに渡す
    • アプリごとの制御はVPN信頼性確保の仕組みを転用
    • 工夫(地獄)が楽しい
      • 最後はパケットキャプチャとかまで
  • 今後
    • 用途に応じて速度変更
    • IPフィルタリング
    • パケットキャプチャ
    • Java SDK SORACOM4j SDK

SORACOMとAzureでIoT

  • @kekekekenta
    • JAZUG
    • ケンタテクブロの記事の補足的な内容です
  • AzureのCortana Analitics Suite
    • Azure EventHub(Kinesis)
      • AMQP
    • Stream Analytics(Kinesis Analytics)
    • Machine Learning
    • Power BI
    • Azure IoT Hub
      • MQTTは変換が必要
  • SORACOMさん、AMQPとSAS TOKENを下さい!

SORACOM BeamとBluemixで簡単IoT

  • 日本情報通信 常田さん
    • SoftLayerユーザー会
    • Node-RED Users Group
  • Bluemix
    • CloudFoundryベースのPaaS
  • IoT Foundation
    • IBMはMQTTの開発者
    • 無料の認証なしMQTTブローカーも
  • Cloudant NoSQL DB
    • Global Data Delivery Network(DDN)
    • MapReduce
  • Node-RED
    • JSベース、nodejs開発GUI

センサネットとモバイルネットワークをくっつけるソラコムさんに作ってほしいサービス

  • AWS 荒木さん
  • デバイス→AWSは100%解決しそうですね
  • 親「インターネットができないんだけど、どうしたらいいの?」
    • IT息子と親を繋ぐIoTプラットフォーム
  • タッチLCD
  • Beamの逆方向トンネルサービス希望
  • イベント駆動アーキテクチャ
    • 昔は研究者でした
      • モバイル網とセンサネットワークをくっつける
      • 従来のセンサネットワークは垂直統合モデル
    • マッシュアップするヒトがアドホックな構築をSORACOM上でできない
    • センシングデータの共有をしない
    • アドホックなアプリケーションを構築ができない
      • これをやるか、声を上げたSIerVPCピアリングするなりをしていただきたい

SORACOMでVoIPやってみた

  • エイビット・テクノロジーズ 椚座(くぬぎざ)さん
    • 会社に伝搬室があったりする
    • OSIでいうとL3~L1
      • 上位レイヤと下位レイヤの溝
    • IoTをやろうとすると、アプリも作って、物理もちゃんと作る必要が
      • SORACOMさんが鎹になってくれるのでは
  • 音声は64kbps
    • s1.small(128kbps)で問題なく繋がる
    • s1.tiny(32kbps)だとヘッダーがでかくなってダメでした
  • かなり繋がる、トンネルの中で1秒だけ切れた
  • 条件:高トラフィックエリア 渋谷
    • 奥さんに電話できました
  • かなり安定して使える!
    • RTT遅延30ms
  • 3分2円

RasPi + SORACOMでGPS Logger

  • はてな 田中さん
    • @stanaka
    • CTO
  • SORACOM Air いいですね
  • GPS loggerを作ってみる
    • 車載したい
    • AnyCaに出すときに仕込んだり
    • node.jsのbancroft
  • 車速・燃費情報とかと連携したい

silk

  • マイニングブラウニー 得上さん
  • Airの帯域はパケット交換機までの速度
  • Silk ... Browser Split Architecture
    • ぽいやつ
  • SORACOM BEAMに正規表現をください!

ぼくのかんがえたさいきょうのSORACOM Beam検証環境

  • クラスメソッド 大瀧さん
    • @takipone
    • ブログの会社です
  • Beam検証環境に求めるもの
    • OS Xのルーティングテーブルいじるのがめんどい
    • DNSが169.254.0.53なので結構ハマる
  • 共有したい
    • 社内LANからアクセスできる環境を
    • 無線LAN -> DWR-PG -> SORACOM Air -> SORACOM Beam -> インターネット
  • beam.soracom.io A 169.254.254.169
    • リンクローカルアドレスなので注意
    • ルータ側でスタティックルーティングができないとコケる

C#からSORACOMを叩けるようにした話

  • @muo_jp
  • 自分がSORACOMでやりたいこと
    • はやぶさにあこがれて
    • アンテナのトラブルで超低速通信しかできなくなった→リモートでソフト書き換えて改善、といういい話がある
    • リモートから低電力でFW書き換えとかやりたい
  • Ruby SDKしかなくね?
    • 10/15気づいてしまった→10/16朝にできました
    • SoraCommonNet
  • APIのsandboxがない!
  • Beamの署名検証方法ががない
  • APIのsandboxがない!

Interconnect Casual

Interconnect variations

  • 田籠さん
    • トレジャーデータ
  • インターコネクト ... 分散システム同士の内部の通信
  • ソフトウェアで完結するもの、HWを使うもの
  • なぜそんなことを?
    • 目的を満たすほどに速い
    • スループットとレイテンシ両面において十分に速い、ということ
  • Hadoop
    • Interconnect的に見ると特殊
    • 分散計算するときの単位がデカい
      • データソースが128MB~256MB
      • 並列DBやHPCに比べると遥かに荒い
      • ノードの計算独立性が高い
      • →インターコネクトに対する要求が少ない
    • 分散FS, HDFS
      • 処理エンジンとかなり密接につながっている
      • 各ノード・プロセスに計算を割り当てるときに、localhost内で計算が閉じるかの判断がある
        • TDでは使ってないので今名前をど忘れしてます
      • HWは普通のイーサネット
    • イーサネット
      • ラック内のTOR(トップおブラック)スイッチ、そこから中央スイッチに繋がるという構成
      • rack-awarenessトポロジを設定できる、1台で閉じない処理でもスイッチ内で完結するようにできる
  • ブレードサーバ
    • SIer時代の話なので、うのみにするとヤバイかも
    • 物理層でかなりいろいろやっている
      • ラックを超えるときはスイッチを担当するブレードを経由してからつなぐ、など
    • NWは普通のI/Aサーバと変わらない
    • eg) Egenera BladeFrame
      • ラック1本まるまる専用機、ブレードに仮想化を提供するもの
      • 専用物理レイヤー(Spine)があり、スイッチ担当ブレードはL1スイッチング相当をやっていてNW的にはダイレクト通信になる
      • Oracleラックをこのブレード上で走らせると早かった
  • 処理の粒度によってインターコネクトの要求、要件は変わりますね
    • shared everything/memory/disk/nothing の区別、とか
      • 共有するメディアに負けないくらいの速度がインターコネクトに要求される

InfiniBand利用状況 さくらのクラウドの場合

  • 鷲北さん
    • さくらインターネット
    • 会社が4人の頃からエンジニアをやっています
    • 研究所所長→現場に戻されてクラウドのリーダー
    • 最近のさくらはDC事業は3割くらい、ホスティングが6割になりました
      • このオフィスも都市型DCです、コロケーションで表に出せるお客様があんまりいない
  • さくらとInfiniBbandの関係
    • そもそもなぜさくらとクラウドとの関係が?
    • さくらインターネット研究所
      • 実は今研究をしているのは松本さん一人、幽霊研究員が3人
      • インターネット関連なら何でもOK
      • 10GbE+技術
        • この過程でIBに注目
      • IoT関連の論文を書いたり
      • IBの研究テーマ
        • HCA, SWの評価
        • Linuxサーバで使えるのか、のドライバ検証
        • 10GbEとの比較
  • 2010年頃の評価
    • pros: 10GbEよりもポート単価が安い、レイテンシが低い、広帯域
      • DDR(20Gb)主流の中に40GのQDRが出てきた頃、IB 32Gが実測27Gbpsくらいだった
    • cons: 社内運用実績が少ない、ドライバ安定性が未知数、インターネットにどう繋ぐか?
      • ブリッジが必要になる
    • さくらのくらうどの第1世代で稼働して、4年目くらい
  • さくらのクラウド
    • 1ヶ月目でストレージに大トラブルが
    • IBに対応してるストレージがコレだけだった
      • opensm(subnet manager)が詰め切れてなかった
      • 完全安定まで2ヶ月、それ以降は不具合無し
    • ノード数500くらい
      • eastもwestも帯域は十分に余っていて、10GbEくらいでぜんぜん大丈夫だった、というのが実情
  • HCA: 発熱に注意
    • loadにより加熱しがち
    • CPU負荷は増えない
    • ケーブルが太くて堅い
      • HPCではIBケーブルは一旦挿したっきり抜かないというのが常識らしいが、さくらでそれをやると怒られる
      • 設置の見極めが難しい
      • 2~3習慣
    • 年間10枚くらい故障してる
      • Etherに比べて多め、エラーレートがじわじわ上がってきて壊れる、というパターンが多い
  • ドライバ
    • Mellanoxのドライバが最も安定している、他に2つあるがSWも作っているのでMellanoxは3rt partyというよりはベンダっぽい
    • Xsigoのドライバが鬼門
      • Oracleに買収されちゃった
      • Xsigo時代は1日以内でパッチが返ってきていたが、Oracleになってから社長はBrocadeへ
      • ドライバのアップデートが止まってしまった
    • さくらではXsigoじゃない製品を探しに行く、しかし代わりが見つからない
  • IBは素晴らしい技術だが
    • IBで閉じてれば最強
    • Ethernetとのブリッジが課題、ここにマトモなソリューションがないと厳しい
    • 第2第3は10GbEです
      • 10GbEがすごい安くなった、'12にはほぼ同じくらいの値段に(まだIBの方がぎりぎり安い、くらい)
      • サーバ・スイッチ間は10GbEで足りる、という知見が得られた
    • DC運用・サービスを作る上ではこういう結論になりました
  • IB以外に試したものは実は無い
  • Converged Ethernet(ストレージとのTCP接続)
    • コンバージドだちょっと高い、ストレージはFCじゃなくてiSCSIなのでTCPで十分
    • サーバメーカからも潤沢なオプションがないと手を出しにくい
    • 現状では切り替えてもあんまり性能・運用コストに差が出ない
      • ポート単位の監視ができない、スイッチでは何も出来ないのでサーバ側で監視を頑張っている
    • システムのアップデートがドライバでブロッキングされるのは非常に恐ろしい
      • セキュリティイシューをそれで足止めされるとデッドロックになっちゃう
      • こうなるとカーネルパッチを自分たちで書く、ということをしている
  • トラフィックの種類は?
    • だいたいeast/northwestで同じくらいで、我々も内訳がいまいちわかっていない
  • IBで良かったのはDRBDの同期がスペシャルに早かった

Interconnect casual: 『京』

  • 現職: Google Chrome
  • 前職: 富士通 次世代TC開発本部
    • 京のインターコネクトのチップを作っていました
  • HPCの話をします
    • あくまでも既知の情報をまとめています、ということで
  • High Performance Computing、あるいはTechnical Computing
  • 極端な例: スパコン世界ランキング
    • LINPACK
      • n*n線型方程式系 Ax = b を解く
      • 巨大な行列計算
      • サイズはメモリには載り切らないくらい
    • 実効/理論性能: 10.51/11.28[PFlops] = 93.2%
      • 残りの6.8%で通信を行う
    • 実行時間: 約30時間
      • 高信頼: チップあたり10FIT(1億時間平均で1回故障)
        • クルマに載せるミッションクリティカルでも二桁いくかくらい、かなりエクストリーム
      • ボードあたり40FIT → 90%の確率で壊れずに終了
  • 理論性能: 11.28PFlops
    • 積和(=乗算+加算)計算回路4 * 8コア @ 2GHz、が88,128チップ、キャッシュほぼ100%で当てつつこれをNWで同期を取りながら93.2%の稼働率を維持し続ける
  • わかり易い例
    • 宇宙関連
    • 医療関連
      • 生体分子
      • 巨大分子の第一...(創薬)
      • 脳神経シミュレーション
    • こういうケースだとワークロードは10%を切るくらい
  • 要件は複雑
    • 通信パターンは様々
      • 頻度
      • 組み合わせ
        • 隣接間のみ
    • 様々な状況で低遅延、広帯域、高信頼
  • 通信のコストは並列度の関数でもっと大変、サチりやすい

  • Tofu Interconnect

    • その実装、ICC
      • Core 2 Duoくらいの規模のものを0から設計・実装した
    • メッシュかトーラス、6次元
      • 「ここはどんなに説明してもわからない」
      • 3次元が2つある
        • 折りたたまれた3次元(Tofu Unit)の頂点それぞれが独立した3次元トーラス、各ホップが短い(1μs/hop)
    • RDMA
      • チップが自立してDRAMノード間メモリコピー
    • キャッシュインジェクションは検討して捨てた
      • バグが出やすい、デコヒーレンスを詰めきるスケジュールがなかった
    • 宇宙線対策
    • 畳み込まれた次元でトランキング
      • 最初の1hopだけ決定論的に決まるものをあえて使わずに、隣接するものを巻き込んで送る
        • トランキングに加えて耐故障性
      • 隣接する3つのコントローラを巻き込んで対向に送ることで5GB/s * 4 = 18(実効)/20(理論)GB/s
  • HPC汎用 = 万能が求められる

    • 高機能
      • 自立通信・演算
      • 仮想記憶
    • 高性能
      • 低遅延
      • 広帯域
    • 信頼性
      • 10 FIT
      • 故障検出
    • 柔軟性
      • 任意サイズの仮想1/2/3次元トーラス
      • 故障迂回
  • 当時アメリカのBluewaterは動かしきれずにポシャった
    • 「bluewaterが上積みしても出し抜けるようにTofuは理論的にはもうちょっと伸ばせるように設計しておいた」
  • アクセラレータは計算する分野を絞る、Tofu・京はベンチマークマシンで終わらせてはならないという至上命題があった、それで高くなったという側面がある
  • 汎用とはいえセキュア演算回路を普通じゃありえないくらい載せてます
  • 中心メンバー10人、外注含めたら50人、プラス検証で10人
    • 全部が出来ないと動かないので、仕様自体は数人

たまにはTeradataのこと、思い出してあげてください

  • tweetはしないでいただきたい...
  • 青木峰郎
  • 最強の並列RDBMSであるTeradataのインターコネクト
  • ジョブズWWDCで喋ってる時のラックが何故かTeradataのラック

  • 30年前から並列

    • Teradata RDBMS(1983~)
    • 全部専用HW
    • v2は486を1000台くらい繋げる構想だったらしい
  • Shared Nothing Parallel
    • AMP(プロセッサ)が自分専用のdiskを持って、ノード間をまたぐことはない
    • 最大2000ノード、リニアにスケール
    • ex.)Oracleに代表されるのがShared Everything(diskが1つ)
  • Redshiftの構成
    • Leader Node *1
      • SQLを受け付ける
    • Compute Nodes *n
    • Hadoopにもある、名前はいろいろあるけど大差はない
  • Teradataのマルチマスター
    • すべてのノードがマスターになれる
    • PE(パースソフトウェア)とAMPを繋ぐのがBYNET、専用ハードウェア
  • 業界最強WLM、割愛します
  • Shared Nothingはインターコネクトが急所
    • ノードローカル処理最高
    • 突然の再分散
      • インターコネクトに一気にデータが集中して死ぬ
    • 他ノードのデータとJOIN/GROUP BYしたいとき
    • 並列DBのインターコネクト
      • Hadoopだと10GbEが一般的
      • TeradataはBYNET v5、10Gbps * n
        • カタログに* nって書いてある
        • 「ノード数に比例して帯域が増えます」
  • BYNETのすごいスイッチ
    • 全体全
    • 一時期AT&Tが使っていたようで、その時ベル研究所に作ってもらったらしいです
    • 数十台につきスイッチを増やさないといけない、らしい
    • InfiniBandに取って代わられ、最上位機種100台以上のときだけ登場する
  • Teradata on AWS
    • BYNETはない
  • さらばBYNET
    • たまにはTeradataのことも思い出してあげて下さい

YAPC::Asia 2015 2日目

データ分析基盤を支える技術

  • @repeatedly

    • Masahiro Nakagawa
    • Perlの話は全く出てきません
    • TreasureDataでソースコード読んだり、tdメンテしたり
    • 小規模なイベントをぽつぽつやってる
      • 「ソース読むぞ」ってイベント作ってほんとに読むイベントやると人が集まらないのでオススメです
  • http://www.slideshare.net/repeatedly/technologies-for-data-analytics-platform Technologies for Data Analytics Platform

  • 入門寄り、実装まで踏み込むことはしません

  • #yapcasiaD繋がりで、D言語コミッタもやってますので興味あれば

  • 必要なコンポーネント、それをどう組み合わせるかという話

  • データ解析基盤に必要なもの

    • Reporting
    • Monitoring
    • Exploratory data analysis
      • 探索的な解析
        • どういうものが効果的かわからない時に、いろんな断面から可視化する
        • 相関を見つけ出す
    • Confirmatory data analysis
      • 仮説ありきの解析
    • Need data, data, data!
  • 勘でやってハズしてるのはままある

Data Analytics Flow

  • 一般的なデータ解析の流れ
    • アプリからアクセスログ・アプリログをどっかに保存(象さん)→処理して解析
    • テーブル一気に出しても人間解析できないので、整理しなければ
      • 整理した上でビジュアライズする

Let's Launch Platform!

RDBMS

  • とりあえずデータベースに放り込めばOK、スタートアップでもコレのままのところは多い
  • 枯れててナレッジがたまってる
  • シングルサーバなので分散ほにゃららを考えなくて良い
  • RDBMSスキーマに合うようにログのをETLしてクエリに変換、INSERT
  • そう甘くは行かない、1台で行ければみんなハッピーだった
    • 更新に対して強いが、時系列に従ってデータ量が増えるクエリには強くない

もっと早い(並列分散)RDBMS

  • 実際そうしてきました
  • PRDBMS
    • Netezza, Teradata, Vertica...
    • Web系はあまり馴染みないが、大きい会社だと使ってたりする
  • OLAP
    • ある1行のカラムの更新に強い
    • shared-nothingで分散しているノードごとに計算が閉じるように実行できる構造
    • PRDBMSはほぼほぼこのモデルを踏襲
      • 1個使ったことがあるとわりとつぶしが効く

列指向ストレージ

  • int型の列をint型だけでまとめて保存
  • codeカラムを集計、みたいなケースに行指向よりI/Oが少ない
  • 圧縮効率も非常に良い
  • 解析に特化したデータフォーマット、現行の解析DBのほとんどが採用

  • 「1行更新したい」みたいなケースには、すべて更新書けないといけないので遅い

    • INSERTをサポートしてなかったり、非推奨だったり

解析基盤そのものはフツーに回せるようになりました

  • 2000年代後半まではこんなかんじでした

  • 「どうデータを配置するか」というユーザのノウハウがないとうまく回らなかった

  • 分散キーを指定できる

    • どの値をどのノードに分散させていくか
    • 下手な分散方式だと裏でNWがゴリゴリ動いてパフォーマンスが出ない
  • 銀の弾丸ではない

    • 再配置中はライトができない
    • メタデータのロックで1秒くらい待たされたりする
  • ずっと同じスキーマを使いますか?

    • 今までのRDBMSスキーマを変えなければならない時、すべてのデータの再構築・再圧縮が走ってしまう
    • それが何度も起きると、人は疲弊してしまう
    • 「じゃあスキーマ変えるんで、1日待って下さい」
    • 個々に対する異論がふつふつと出てきた
    • ↑がHadoopが流行る一因に
  • データの保存だけ何も考えずにガーッとやって、使うとき・解析するときに定義すれば良いのでは

    • RDBMS: Schema-on-Write
    • データソース・データウェアハウスの分離の発想
    • ライトはちょっと重いけど、リードが軽くなる
  • Hadoopでは読むときに型を作り出す
    • Schema-on-Read

Data Lake

  • ベンダー臭がして使っていいのか微妙なんですが
  • Hadoop、あるいはより広大なもの
  • 型を変換せずに、生のまま保存して、Data Lakeがその差異を吸収する
    • 実はいろんな人が提唱して人によって中身がバラバラ
  • 共通項は「デカいストレージ」

Data Lake Patterns

  • Web業界ではHDFSをデータレイクの代わりに使う
  • HDFSのデータをHadoopで処理する、というアプローチ
  • 生のjsoncsvなら、Hadoopが適当にやってくれる

Apache Hadoop

  • いろんなものが乗っかりすぎて、どこからどこまでを指すのかわからなくなりつつある
  • 一昔前はMapReduceでしたが、今では膨大な選択肢の一つ
  • 間にHadoopみたいな何でも置けるものを置いておくと楽ちん
    • ETLではなく、EL/Tのアプローチ
    • 今でも現役

余談

  • MapReduceというのがありましたが
  • Apache Tez
    • MapとReduceのタイムベースからDAGベースのより最適化された分界に
    • M/Rの段数が減る
    • MapReduceの記事を探すときはTez以降か以前か、で大きく変わります
    • Sparkがよく比較してるけど、旧MapReduceと比較してたりするので要チェック
  • いくつか迷信がある
    • HDFSとYARNはSPOF持ち」
      • Resource Managerが落ちると困る問題はもう治りましたよ
      • まだ言ってたら「ポジショントークだな」と思って下さい
    • Hadoopってソースからビルドできないからクソだ」
      • TDではCircleCIから毎回ビルドしてるんで、何を言ってるんだという感じ
      • HortonworksやCrouderaもしかり
  • Hadoopを自社で持ちたい!」
    • 「やめろ!」と言いたいですが...
    • 使うならパッケージをおすすめします
      • Hortonworks HDP, CDH, MapRとか
    • 最新を追うならJIRAとかでバグトラッキングをちゃんと追ってあげて
    • TDはHadoopにパッチを送っている会社で、パッチが当たったものを使いたい
      • それには数ヶ月ラグがあるので、コミュニティ版にモンキーパッチしたりするような時があります

Ingestion Tools

  • ログの保存手法

    • バルクロード
      • RDBMS->Hadoop、みたいなケース
      • Embulk
        • ちょっと宣伝込み
        • TDのOSS
      • Sqoop
        • Hadoop界隈ではよく使われている
      • 用途によってリサーチして下さい
    • ストリーミング保存
  • 1TBのデータを変換するのにまた1TBのストレージが必要だったりする、インポートはなかなか大変

    • ためたデータに直接クエリを投げたい!

MPP query Engine

presto

  • FaceBook
  • プラガブルなバックエンド

    • Hadoop上でなくてもできる
    • prestoそのものがMySQLを読んだりできる
      • FB社はめちゃくちゃDBの種類を持ってるので、いちいち置いていられない
  • つらいケース

    • 「速報値がほしい」
    • HDFSからデイリーや1時間おきにRDBMSへ持って行って、インタラクティブクエリを受けられるようにしてダッシュボードへ
      • データがでかくてクエリが帰ってこない、サマらないとダメ
      • サマってなおデカイともっとつらい
    • HDFSからpresto
  • 「もっと速報値がほしい!」

Apache Storm

  • 世の中の解析基盤はほとんどApacheに支配されています
  • 出てきたレコードをダイレクトに解析にかける
  • 1レコード単位に解析
    • マイクロバッチ
  • Twitterが利用したことで有名、がTwitterはもう使ってない
    • 代替ツールOSSでないので、みなさんはStormを使いましょう

Norikra

  • @tagomoris開発、日本製
  • StormはGradleでクエリを書く必要があった
  • SQLで書ける!
  • しかし分散しない!
    • モリスさんの努力が足りない
    • MerkariやFreakoutでは使っている

Apache Kafka

  • Apache Que
  • pullがあるまでpushされてきたデータを貯めこむ
  • データ分岐の粒度が違ったり、間隔が違うときに挟ませる
    • push側(fluentd, Flumeなど)は受け側のリソースを考慮せずに送りつけ続けてしまうので、そこを吸収するのが主なMotivation
  • ない会社もあるので、なくても動くことはあります
  • Push型とPull型が入り乱れ出したら、挟むとよさげ

めっちゃたくさんある、つらい

  • みなさんは解析がしたいのであって、運用はしたくないハズ
    • Amazon RedShiftやBigQueryみたいな便利なのがあります

Amazon RedShift

  • EMRは構築までで、Hadoop自体の面倒は見ないですが
  • Kafkaの代わりにKinesis、などでAWSソリューションだけで分散機構が

Google BigQuery

  • 数秒〜数十秒で返ってきて欲しい
  • 構造はほとんど同じなんだけど、最下層のColossusがスゴいらしい
    • しかし論文未発表で謎技術です

Treasure Data

  • 僕らもやってます
  • クラウドベンダではないので、OSSを組み合わせてデータレイクソリューションをクラウドの上に構築している
  • ストリーミングは未実装なので、機械学習みたいなのに

Resource Model Trade-off

  • フルギャランティード
    • 急激なスケールには自力でスケールアウトする必要がある
  • フルマネージド
    • BigQueryとか
    • たまにレスポンスが遅くなったり、アンコントローラブルな要因が挟まる
  • TDはその中間くらいです
  • MS Azureもこういうことが出来ます、スライドに盛り込みたかったけど時間がありませんでした

「解析したい!」

  • やりましょう!!!
  • しかし運用コストが超高い
    • クラウドベンダがそうさせないように努力しているので、その波に乗っかるべき
  • エッジな機能を使いたい場合に限り、一緒に運用をしていきましょう

まとめ

  • SQLちゃんと使って下さい
    • RDBMS以外でさえも、SQLで記述するような世界になってきている
    • あと10年は、SQLだけは覚えとかないとダメだと思います

Q&A

  • PrestoのコーディネーターのHA構成ってやりようがありますか?
    • TDではPrestoのHA構成はよっぽどデカいクエリがない限りやっていない
    • コーディネーターはステートレスなので、複数のPrestoをラウンドロビンして落ちたら別のに投げる、という感じです
  • 人間が分析するときの可視化、ダッシュボードを作るときのトレンドってありますか?
    • 作らないほうがいいと思ってます
    • Tableau、MetricWizard?など、探せばいっぱいあります
      • 要望に合わない時に作らないといけないけど、js/cssバリバリの世界
      • OSSではあんまり良いのがない、みんなよさ気なのは有償になっちゃっている
      • キャッシュしないと毎回投げちゃって課金がかさむことがあり、Tableauは内部にキャッシュDBを持ってたりする
      • このへんまで考慮して作らないと難しいのでは
  • セキュリティ的に全く外にデータを出せない時のパッケージってある?
    • 実はあんまりないけど、MSのAzure Service FabricやOpenStackくらいなのでは
      • バックエンドのスケーラビリティを担保できないと、実用的な基盤が作れない
      • S3相当のオブジェクトストレージを自前で持つ、みたいな努力が要ります

YAPCあるある

  • 歴代実行委員長的な人たち

    • miyagawa
    • takesako
    • 941
    • lestrrat
    • yusukebee
  • 牧さん、941さん、miyagawaさんいらっしゃってますが、呼び込みをしたいので一旦出てもらってます

    • 拍手のコツ
      • 細かく早く
      • 大きく
      • 声も

基本情報から振り返るYAPC::Asia Tokyo

  • '06~'08は有志、'09〜JPA

  • 歴代ロゴと運営

  • '06のラクダはオライリーから許可をもらいました

    • perl関連でラクダを使うときはオライリーが権利を持っている
    • Tシャツでの使用のみ、なので来年以降のロゴは変えるようにしてました
  • '06来た人は10人いないくらい

いつ・どこで

  • '06は大田区民プラザ
  • '09に東工大が秋にしか開かなかったので10月に、それ以降は詰められずずっと秋
  • 民間施設は津田ホールとビッグサイトのみ

入場者数の推移

  • '09にドロップがあったのは秘密にしたかった
  • 推移についてはクロージングで話します

スポンサー数の推移

  • 6社→47社
    • メディア協賛とか含めると60越え

出来事から振り返る

'06

  • '05に台北であった、そこで話した時に「来年東京でやってくれ」と言われたので
    • 次の日のトークで「来年やります」と書いて
    • 竹迫さんやnaoyaさんとキックオフをした
      • ミーティングはそれっきりだったような
        • 当日朝に集まって「あとよろしく」
      • (牧)僕の受けた引き継ぎは↑でした
  • 無線も家庭用無線LAN並べただけで、ほとんどつながらなかった
    • 当時WiMAXも試験してたくらいの時期
  • 「ワイエーピーシーアジア」かなと思ってたらmiyagawaさん「ヤプシーエイジア」
    • 当時はCPANもクパンと呼ばれてたりした
    • YAPCをやっぷくと呼んでる人も
  • 売上を来年に持ち越したくなかったので、20万くらい黒字になったけどperl Foundationに15万くらい寄付した

'07

  • 津田ホール
  • '07の懇親会でDanKogaiさんと邂逅

'08

  • 東工大
    • 3棟で移動が大変でした
    • 大ホールの階段がコケやすい
    • 以降'11まで
  • ActivePerlのカナダactive state社からスポンサー協賛
  • 芝生で餃子
  • Y!がカップラーメンを配ってお湯で行列が出来る
    • 食べると眠くなる
    • 最後余って学生に押し付けてた
  • miyagawaさんの紫色のやつ(Yahoo!知恵袋あごまくら)

'09

  • 運営がJPA
  • '08のスタッフ打ち上げまで何もなかったが、各々ちょっと思っていたようで
    • ちょっとやってもいいかなー、と思っていたら決定事項になっていた
    • 階段でコケた事案をうけて保険を契約する際に、法人じゃないとダメでした
  • 牧さんは当日38度の熱を出しました
  • カメラマンの八木さん
  • ACTがフランス
    • ACT...YAPCの管理CMS
    • 日本から使うためのPayPalゲートウェイシステムにバグがあり(ドットの位置がズレてるみたいな)、直さないといけなかった
      • 販売開始してから動かなくなった
      • miyagawaさんがお金もらってフランスの作者の家に泊まりこんで直した

'10

  • 941さんコミット
  • JFXに初ドタキャン食らった気がする
  • (牧)「引き継ぎ資料なんてものはない」
  • (宮川)「'08までのMLはbasecampに全部残してある」
    • (941/牧)「それ引き継ぎの時に聞きたかった」

'11

  • ランチタイムrejectしたら大不評
    • 「おなかすいた」言いながらみんなみっちりトーク聞いてた
    • 941「トーク見るのは素人ですよ」
      • 前夜祭で廊下で談笑してたら「静かにして下さい!」って言われた
  • みねまつさんのマイクが壊れて大声でしゃべってもらった

'12

  • 東大、一つの建物
  • LTソンがすごかった年
    • udzulla劇場
    • LTは(アメリカの)YAPC発祥です
  • 人数が増えだして
  • ぼっちランチ解消対策
    • くじ引きして、お金あげてみんなでランチに行ってもらう制度
    • RubyKaigiからパクった
      • 個人スポンサーも

'13

  • 慶応
    • 941さんが会期中ずっとマークされてた
  • CONBU
  • 個人スポンサーの単価増
    • おまもりを作った
      • バグ封じのお守り
      • 中には"Shut the fuck up and write some code"

'14

  • ゆーすけべーさん
    • '13に牧さん941さん引退宣言
    • つらかったので今年はまた牧さんに...
    • 「慶応とめっちゃモメるから」と言われ続けて教授からあたってちゃんとしたら何も怒られなくなった
      • 慶応では加藤教授、東工大は奥村教授
      • 大学を使いたければ教授から攻めましょう
  • HUB貸切
    • 宮川「今年はないのでちょっと不満ですね」

'15

  • 会場がビッグサイト
  • 5トラック、2000人超え
  • 懇親会はキャパ700に600人
    • 慶応では満員電車でご飯を食べるみたいな教訓があったので

Q&A

  • お世話になった人リスト
    • (941)永山さん
      • 懇親会を毎度セッティングしてくれる幹事マン
    • (宮川)竹迫さん
      • '07,08はほとんど日本に居なくて、すごいいろいろやってもらった
    • (竹迫)DanKogaiさん
      • 外国人スピーカー、ハッカソン
      • 日本でハッカソンをやったのは多分YAPC::Asiaから
    • (牧)並木さん
      • 多分自分の次に長くYAPCにいた人
      • 有名でないけど、こういう人に支えられて
  • 勉強になったこと
    • (竹迫)スライドの翻訳
      • ものすごく教養がないと翻訳できなかった
    • (宮川)最初に講演をお願いしたまつもとさんとラリー・ウォール
    • (牧)スタッフやってるとLTしか見れなかった
    • (941)同じくLTでdameningenさんのWerl
  • YAPCの人の集まる求心力の秘訣
    • (941)負けを知りたい
      • 嘘です
      • 新しい人をどんどんいれること
    • (牧)法人化して、投資できるようにしたこと
      • 写真をとってもらうように
      • ビジュアルで残して、想像できるようにできたのは大きい
  • YAPCが今、Perl以外の言語を許容している理由

    • (竹迫)'06にまつもとさん、高橋さんを招聘している
    • '08からの前夜祭のRejectConfが盛り上がった
      • Perl人口自体は減少の傾向があるので、他の言語を取り込んでも、という認識
      • RejectConfの方がお酒片手に読めて面白そうなのもあった
    • (牧)言語を1つに絞ると、あまり業務に即してなくて面白いのがなさげな感じがする
    • (宮川)他のYAPCではこの傾向はなくて、Perl自体の話が多い
      • 言語のレベルではない、上のレイヤーの話が増えてきたのはそういう流れなのかなと思う
  • YAPCに捧げたもの、得られたもの

    • yusukebee
      • 「LTは笑いを取るものなんだよ!」と言われたり
      • あったかいなあと
      • 一旦の区切り、ということで
    • 941
      • クロージング30分、長いなと思った
        • 果たして最後なのかどうか
      • 小さな飲み会みたいなのからイベントのノウハウを蓄積して、YAPCみたいな大きいイベントができるようになった
        • みなさんも勉強会の主催・幹事を率先してやってみて頂ければ
      • クロージングあるのでパスで!
    • 竹迫
      • YAPC::Asiaで初めてのイベント運営、国際カンファレンス運営
        • YAPCに育てられました
      • 東京以外でもやってもいいんでないか、その時にはやってもいいんじゃないかなと
      • (牧)YAPC自体は商標ないので、やりたい人いたらやっていいんですよ
    • 宮川
      • 自分のルーツはPerlコミュニティ、年3,4回の帰国のうち1回はかならずYAPC::Asia
      • 同窓会みたいな感じ、YAPC以外にもこういう帰ってこれる場所が残っていって欲しい
      • いろんな人に支えて頂いて感謝

HTTP/2時代のWeb

  • @Jxck

    • Goでhttp2サーバ、クライアントを書いている
    • mosaicfm
    • http2study
    • 今は正式名称がHTTP/2、HTTP/2.0と書いている記事があれば「古いんだな」と思ってくれれば
  • http://http2.info

  • #http2study

    • IETFに行ってきた人の報告を聞く会、とか
    • 実装についての議論
    • RFCが出る前からハッカソンやったりしてました
    • MLのissueにあわよくばコメントしてみよう、みたいなissueソン
  • 日本人にすごいひとがたくさんいる

    • nghttp2
      • 「事実上のリファレンス実装」と言わしめた
    • h2o
      • kazuhoさんの発表とダダかぶりなんじゃないかと思って昨日の発表は全く見てません

RFC 7540

  • RFCになってしまいました
    • みなさん既にお読みかと思いますが
  • 策定のフェーズは終わった、使うフェーズに入った

  • 今回は「理解した、導入する」を目指すつもりはありません

    • 「気がついたらHTTP/2使ってたは」という世界も無くはない、実はそれはそんなに否定しなくてもいいのかもしれない

現状把握

  • 1ページ中のリクエスト数とコンテンツサイズは増える一方
    • サイズも1こにつき2MB近くまできている
  • 帯域 vs レイテンシ

    • 帯域が増えたからWebが早くなる、というわけではないらしい
    • やりとり自体のレイテンシが占める割合、それを削減する努力の方がクリティカルだということがわかってきた
  • 速くするために

    • RTT(ラウンドトリップタイム)を減らす
      • 物理的に近くする
      • レスポンスを早くする
        • 光は案外遅い
        • 光が早くなればいいが、どうやらそういう兆しはない
    • RT(ラウンドトリップ)回数を減らす
      • アクセス回数を減らす

HTTP/1.1

  • テキストベース
  • Header
    • 圧縮負荷、変わらないものも毎回送る、重複が多い(UA)
    • UAは嘘をつかないといけないのでどんどん長くなっている
  • Body
    • なんでもOK、バイナリでも圧縮でも可能
  • TCPを毎回確立している
    • 毎回3-Way-Handshake
    • 毎回initial cwnd(輻輳制御)
    • Head of line Blocking
      • レスポンスが返るまで次のを返さない
      • ひとつ詰まると後続が全部止まってしまう
    • コレを受けて、ブラウザはこっそり6本張っている
      • 2本推奨だったので6本張るようになりました

シンプルな一方高速化に限界が

  • わりといろんな回避策を編み出してきました
    • HTTP
      • KeepAlive
      • CSS Sprite
      • File Concat
      • Domain Sharding
        • ドメイン変えればもう6本張れるじゃん」
      • Bad Hack
        • なんで画像一個にまとめる必要があるんだ
  • TCP
  • TCP Fast Open
    • 3-W-Hを
  • InitCWND 10
    • 昔ほど問題にならないので上げる
  • TLS Session Ticket
  • TLS False Start
  • Kernel level

    • おいそれと触れるレイヤーではない、Linux/iOS/Androidが対応してくれるのも待たなければならない
  • それを待てない会社が独自プロトコルを作ってしまう

    • これを標準化してみたのがHTTP/2です

HTTP/2

  • バイナリフレーム
    • パースしやすい
    • サイズ効率が良い
    • データ分割しやすい
  • 語彙はそのまま(セマンティクス維持)

    • GETはGETのまま
    • 互換性をもたせる
  • ヘッダ何度も送る問題へのアプローチ

    • HPACK
      • ハフマン圧縮
      • 頻出ヘッダ(200とか)を最初からIDにして共有
      • 送信済みデータを再利用
    • 圧縮の仕様だけ決めて、アルゴリズムは実装次第です
      • http2studyでやってみて、高いものは8割方圧縮できたりしてます
  • 1コネクションにストリームを多重化

    • 全部同時に送る
    • 全部一緒に送って全部遅くなるのは困るので、リソースに優先度をつける
    • 画像より3倍cssにリソースを割り振る(ソケットに書き込む)
  • コネクションを使い切る
    • これまで6本がバラバラに走り出して、コネクションの割に帯域を使い切れてない
    • 1本にすればハンドシェイクも1回、帯域の限界までデータを送れる
  • ベンチマーク

Server Push

  • 1リクエスト1RTだった壁を超える
  • Cache-Controlでブラウザキャッシュさせてると思いますが
    • 熾烈なキャッシュの奪い合い
    • 75%の人は48時間で領域を使い切っている
    • 2日経てばクライアントキャッシュが無条件に空になっているかも
    • Pushで積極的なCache管理していく案
  • Service Worker
    • フェッチとプッシュを全部jsで操作できる可能性がある
    • アプリとしての側面が強くなる

Pushが入ることの意味

  • FetchとPushの両方をカバー
  • コンテンツ配信だけじゃもったいないですねコレ
    • WebSocket over http2
    • gRPC
    • アプリケーション、ミドルウェアレベルで積極的に使える可能性が

では、採用しますか?

Response Timeの後の世界

  • フロントエンドの画像1枚、がバックエンドのニューニングを台無しにする可能性は往々にしてある
  • Res.Timeは世界の半分しか測れてない
    • Speed Index
    • Real User Monitoring
      • 数値化しにくいものも多く、過渡期ではあるがレスポンスタイムだけで速度を測れる時代はもう終わった

最適化

  • ものすごく素直に作っても遅くならないかもしれない世界が近づいている

実装

  • まだ追いついてません

インフラ

  • ロードバランスどうするの?
  • HTTPS終端は?
  • need more 知見
    • まだ弱いです、議論が欲しい

HTTPS

  • Pervasive Surveillance
    • NSAのPRISM(広域盗聴)
      • スノーデンが告発、この間のIETFSkypeで「スノーデンだけど質問ある?」みたいなことやってたみたいです
      • AT&Tがそれに協力していたとか
      • 牧歌的にできていた時代はもう終わったのではないか
    • 証明書高い問題、特に個人のレベルでは顕著

HTTPS前提?

  • HTTP/2はHTTPS上にしか実装、しない流れ
    • Oppotunistic Encryption
      • 日和見暗号
      • HTTPなのに暗号化
      • Fxで脆弱性が見つかりoffになっている

HTTP/2は巨人のものか?

  • 戦ってるレベルが違う
    • 毎日がDOSみたいな世界
  • 我々のアプリが複雑でない、というわけでもない
    • HTTP/2は使っても使わなくてもいい、というのがいいところ
    • クライアントは標準化のおかげでいつのまにか導入されています
    • リバプロ挟むだけで高速化した事例もある
    • 今足りないのはノウハウ、ただそれだけ

これからどうなるのか

  • priority 最適化
  • HTTP/3の話ももう出てきています
  • TCPの限界
    • UDP、それは最後の希望
    • →QUIC
      • = TLS1.3, HTTP/2, UDP
      • Google検索結果で既に使っているはずです

「理解した、導入しない」

  • 戦略としてはあり、ただしとどまり続けるリスクに注意
  • まずは触ってみれば良いと思います、どうせまだ実装は足りていない

「能く知らないけど導入する」

  • エコシステムの成熟次第ではあり得る

まとめ

  • RFCが出てしまった
  • HTTP1.1はなくなることはないので安心してください
  • HTTPS化はした方がいい、まともな新しい機能もだんだん試せなくなっていく

  • nginxが2015年末に実装を宣言

    • ここが一つのチェックポイントになるのではないか
  • 次のIETFが横浜に11月で

    • Twitterに愚痴っても世界は良くならないので、ココに投げ込むことを検討して下さい
    • 日本のガチ勢も集まります

Q&A

  • ブラウザキャッシュの中身を知る方法は?
    • 実は無いんです
    • h2oが出しているのはサーバがキャッシュしているかどうかのシグナルを持っておこう、という提案
    • 二重にpushを送っても問題はないので、あまり深刻な問題ではないかも
  • 普及にどれくらい時間がかると考えていますか?
    • 思いつくのはメジャーなサーバが正しく実装している状態、それなら来年か再来年くらい
    • では、みんながそれを使うかどうかはわからない、来ないかもしれない
      • したいひとはする、という程度のものだと思う
      • 来るとしても近い未来ではなさそう
    • エコシステムが揃うのは?
      • Webはエコシステムで作るものだと思っている
      • エコシステムが、使う側から見て成熟すると感じられるのはサーバ側のミドルウェアが暗黙的にサポート・支援をしてくれる状態
      • そして、みんなが勉強会やブログで知見を共有できる状態
      • 知見は少しずつ出てきつつあるが、サーバ実装は全然なので2,3年かかるだろう
  • プライオリティの指定は明示できる?
    • 今はブラウザの実装に依存しているが、Resource HintsというのでProbabilityを指定することはできる
    • まだ実装の議論の段階
  • 昔からIPv6という問題があるんだけど、どっちからやんなきゃいけないんですかね
    • IPv6も昔からあるけど、IPv6は一人が頑張ってなんとかなる問題ではないと思う
    • HTTP/2はある意味ではサーバとクライアント間で完結している
      • 対応のスピードは圧倒的にHTTP/2の方が早く、低コストなハズ
    • IPv6はやっていくべきだが、大変なんでないか

LT

MySQL 5.7の罠があなたを狙っている

  • @yoku0825
  • 5.7
    • 今年中にはGAが出るでしょう
  • 余計なお世話なパラメータが多い
    • パスワード変更から360日後にロックされる
    • UTCで出る、誰得
    • binlogへの書き込みはDiskFullでは開放してくれないのでスタックする
  • (めっちゃ多いのでスライド参照)

吉祥寺.pmというイベントを作った話

  • Magnolia
  • 悩み
    • 聞きたいテーマの勉強会が都合よく解決されない
    • →自分でイベント作ればいいのか!
      • 聞きたい人の話が聞ける
      • 自分の家の近くで開催できる
  • 自分が聞きたいトークがあれば自分で開催すれば良い!

a good naming makes a good design

  • Satoshi SUZUKI
  • ・「いい名前が決まると設計が決まって勝手に実装が出来上がる」
    • ちょっと意味がわからない
  • 名前以上の機能を持たせない
    • buildというメソッドでbuild以外にいろいろやっちゃうと
    • テストも書きにくい
    • 全部説明するのは最悪
    • 日本語で説明して、割れそうなのを分けるという順番がよさげ
    • 適切に役割を分割

botになる技術

  • botの人います?
  • 平田哲
  • bot、便利で多様化していきます
  • 社員で発言をEvernoteに保存していて、100個超え
    • bot化されてしまう
    • PHPで49行
    • 「便利!本人要らない!」
  • botになる技術
    • 生きろ

モダンなクライアントサイドJSに追い付くための小さな(しかし大変な)一歩

  • @zoncoen
  • モダンなクライアント
    • React, brownerify, BABEL, webpack, ngJS...
    • ウチではjQuery1系とCoffeでした
    • グローバル直叩き
  • DOMは変数じゃない
    • 「糞コードじゃないすか」「そう思うし、直して」
  • 直した
    • npm
    • ファイルに分けつつ、WebPackでまとめる
    • Marionette.js
  • 圧倒的につらい状況からは脱した

Evaluating your stylesheets

  • @t32k
  • Kaizen Platform

    • Naoyaさん、5社で技術顧問してて「技術顧問ビッチじゃないか!」と言ってしまったのが今週のハイライトです
  • CSSのヘルスチェックしていますか?

Perlの$encoding変数

  • @yappo
  • 5.22からdeprecatedです
  • いろんなバグ

THE REAL LOCK

  • 本当のロックの話をします
  • @moznion
  • 分散排他ロック
  • 何を使うのが正しいのか?
    • ...電話だ!
    • 電話を使うことで本当のロックに到達することができました
    • 1876年からの伝統
  • 「相手と通話できる」「相手と通話できぬ」
  • Twilioでこれが実現できます
    • 無料アカウントでデバッグしまくってたらexpireされてしまってDemoはできません

コミュ力あげてこ

  • WebAudioを応用してコミュ力を鍛えるツールを作りました
  • 世界的 <- コミュ力高い
  • 伝統的 <- コミュ力高い
  • 通信手段 <- コミュ力高い
    • モールスは黒電話以上の伝統
  • モールスでのコミュニケーション
    • 情報量がめっちゃ少ない
    • 「伝わってめっちゃ嬉しい」というプリミティブな感情が得られます
    • 村上春樹「理解とは誤解の総体である」
      • =わかった感
  • 積極的に劣った手段でコミュニケーションをしていきましょう

COMBU

  • 総延長1.6km、AP/SW90個、1時間でやりました
  • ホントにやったのか?ということで、今から設営します
    • 1分で設営、撤収できました

Vim script静的解析の光と闇

  • Kuniwak
  • 嘘、光はない
  • 変数が闇
    • リリースしてissueが速攻で5個立つ
    • 謎構文
    • Vim「甘えるな」
  • 宣言と参照を追跡する
  • Lv.1 redir
  • Lv.2 スコープ
  • Lv.3 map
    • 文字列で渡されてしまう
      • 無視するように甘えたら誤検知の嵐
    • 再帰展開する
  • 解析しやすいコードを書いて欲しいです
  • そんなこんなでできたのがvim-vint
  • pip install vim-vint

クロージング

  • 軽くYAPCの振り返り

  • 60スポンサー、90スタッフ、90のトーク

  • 平均100Mbps
  • 来場者数2130人

  • 3位 Kazuho Oku

  • 2位 Jxck
  • 1位 hitode909

  • "YAPC::Asia" is free

  • Please BLOG ABOUT YAPC!!!

  • One more thing

    • builderscon.io
      • (仮)
      • 2016年は絶対に何もやりません

YAPC::Asia 2015 1日目

Consulと自作OSSを活用した100台規模のWebサービス運用

  • @fujiwara
  • Agenda
  • 最近のロンチサービスは使い方はいろいろだけど全てにConsulが入っている

Lobi

  • Playdog、ゲームのストリーミング配信SDKの開発など
  • '10〜、ap-northeast-1登場以前のAWSで始まった
    • App2, DB2の4台とか
  • '13.11 ~ AWS東京リージョン Maxで100台くらい
  • AppのASG、SDKのASG、画像変換のASG、ストリーミング、バッチサーバ、ログ集約/解析(Norikra)、動画変換ASG
  • モダンになるまえからやってるのでマネージドサービスより役割の違うEC2が多い
    • ホストの種類が多い
  • Perl(アプリ), Node.js(ストリーミング), Go(ストリーミング)
  • ミドルウェアいろいろ

  • AWS移行後の悩み

    • 当時内部DNSがなかった
      • hostsをchefで書いていた
      • 名前が引けないとChefが滑ることがあったので、Chef実行そのものがわかれていた
      • DNSサーバ自前構築は面倒
      • Internal DNSはなかった

Consul

  • 本番運用しているのは会場で3%くらい
  • Agent
    • DNSとHTTPのインターフェースがある
    • consul1バイナリに引数でデーモンになったりCLIになったり
  • Server
    • クラスタ内の特定の奇数台で動いている
      • うち1台がLeader
      • 一人だとLeadarになれない、過半数(→最低でも2/3台)の賛成で選出される
    • Raft

Service / Node Discovery

  • サービス内のnode
    • consul members
      • 順番はランダム
      • Failed(監視失敗), Left(クラスタから除去)
    • @127.0.0.1 -p 8600にDNSポート
      • Leftしたノードは返らない
  • Service Definition of App
    • jsonでサービスを定義、dig app.service.consul @127.0.0.1 -p 8600で引く
      • DNS-RRでコロコロ変わる
      • 10ノードでもうちランダムで3アドレスのみ返る
      • TTLは0
    • TCPで引けば全て返ってくる
  • :8500にRESTポート
  • 最近外部DNS連携が出来るようになりました

Health Checking by script

  • ユーザ定義のヘルスチェックコマンドを実行
    • 終了コードで判別、Nagios互換
    • consul agentがHTTPチェック
    • TTLで数分間隔以内でpushしにこれるかのTTLチェックもある
  • KVS
    • memcachedのフラグにあたるユーザ定義を付けれる
    • パフォーマンスはリーダーノードに向かって40000qps
      • 他のノードはリーダーに問い合わせるので下がる
      • かなり早い、遠慮なくGETできます
    • PUTは427qps、そんなに頻繁に置かないはずなので深刻ではないハズ
    • stale modeにするとリーダ以外でも応答できる

内部DNSとしてConsulを使う

  • :8600に向けないといけない
  • /etc/resolv.confではポート指定は無理
  • 無理やり:53に向けるにはroot特権が必要で怖い
    • :53は再帰問い合わせしないといけない、Consulはcache機能がないので難しい
  • dnsmasq, bindなどからConsulをフォワードする
    • .consulならlocalhost 8600にフォワード、それ以外はunboundへ
      • たまにVPC標準DNSが返さない時があるので、自前のunboundを置いています
  • resulv.conで(node+service).consulを検索ドメインに指定
    • node/service名だけで検索できる
  • BINDは夏休み取りたいので使いません

Deployment Table

  • Server node: 本番では最低3台、5台が推奨
    • 3と4では耐障害性は変わらない
    • 2CPU、RAM20MB、2MBストレージ、くらいの消費
      • RAMとストレージはKVS次第
    • Serverには専用ホストが必要か
      • たぶん不要
      • ディスクIOが激しいとRaftでリーダーが入れ替わりがちなのでIOの穏やかな所が良い
      • デーモナイズ機構がないのでdaemontoolなんかでお願いします
  • start_join
    • consul serverには固定サーバ
  • Atlas連携
    • 大統一理論
    • Atlasのトークンで全部引っ張れる
    • 10ノードまで無料、それ以降は40USD/m、join自動化のためだけには高い
  • Server nodeのフェイルオーバーは自動、リーダーが落ちたら再選出が終わるまでDNSが引けなくなる

    • だいたい2,3秒で終わるが、stale modeを使えばそれも潰せる
    • DNSキャッシュがあればTTLを明示しておける、ただしその分反映は遅れる
  • 運用中のUpgrade

    • クラスタは一回立てると落とせない
    • ローリングアップデート方式
  • 0.2時代からproductionに入れて1年運用してますが、agentが落ちたりクラスタが崩壊したりした記憶はないです
    • Quorumが満たせないレベルまで減るとクラスタが崩壊します、データが飛んでしまう
      • KVSは定期的にバックアップ、ユーザデータは絶対に入れないように

オートスケール環境で使う

  • Lobiの動画変換機能(ElasticTranscoder)
    • S3に上げてキックしたら変換してくれる
      • ちょっとお高い
      • 1投稿2分で25円、1万人分で25万円
  • モンストにSDK導入しました
    • 家が立つレベルでお金が飛んでしまう!!!
    • →SPOTで変換する
      • cc.88xlarge(32core) = 0.45USD/h
      • 1/10〜1/100にまで削減
    • ピーク時で45台くらいまでスケール、最低2台
  • スケールアウトはJobの量で

    • リアルタイム性は低いので遅れてもOK
  • 自動でuniqueなホスト名を付ける、join、Chef,デプロイ...

    1. user-dataでユニークホストを名付ける
    2. ChefのノードをConsulのKVに入れる
    3. Stretcherでdeploy
    4. Zabbixに登録
    5. OS起動時に登録するとアラートが飛んでしまう

Stretcherを利用したデプロイ

  • 自作しました
  • ConsulとSerfで動くデプロイツール
  • これまでは中央サーバからのデプロイ
    • このpush型はオートスケールに対応できない
    • pull型で中途半端なときに持っていかれると困る
  • gruntやGoの生成物を格納したくない
  • デプロイのたびにAMI再生成はやりたくない、10デプロイ/日もできない

Stretcher

  • sorah/mamiyaAWS CodeDeployとほぼほぼ同じです

    • AWS以外でもつぶしが利く
    • rsync&コマンド、というフローを踏襲
    • sshではなくConsulのイベントで通知
    • golang
  • ビルドしたものをtarにしてS3へ

  • YAMLの定義ファイルmanifestもS3へ

    • 各ホストのConsulがtarとYAMLを読んでデプロイしてくる
  • Consul Event

    • ゴシッププロトコル
    • consul event .....で発火
    • consul watchでイベントの伝搬を監視
  • ビルドプロセスはStretcherには関与しない
  • 各クライアントでtar.gzを一旦TMPDIRに展開して、ローカルrsync

  • Lobiでのデプロイ例

  • tgz 200MB
    • CPAN 110MB
    • nade_modules 10MBx5
    • Go app binaries 8MBx5
    • static files(S3に逃したい)
  • ビルドで1分
  • パックとアップロードで1分
  • イベント通知から10~30秒
    • S3は200MBを100並列で取得してもびくともしない、おそろしく頑健
  • ロールバックで威力を発揮
    • 元のmanifestだけ送ればOK

Chef/Serverspecの通知を一覧したい

  • 100台で失敗すると100行エラーが出て阿鼻叫喚
  • Consul KV Dashboard

    • 作りました
    • golang
    • ConsulのHTTP APIで送る
  • Blocking query

    • 次のリクエストが来るまでリクエストを待たせる機構

オートスケールでのデプロイのtips

  • 最新のmanifestをConsulのKVに格納
  • AMIに残ってる古いアプリが起動すると事故る
    • 最新のデプロイID出ない場合は起動しない
      • 初回起動時のみ、daemontoolを起こす前にKVとローカルの値を比較する

bash-completionでsshのホスト名補完

  • known_hostsを参照するときのfunctionを.bash_profileで上書きしてKVを参照するようにするとすっきりする

まとめ

  • Consulは機能豊富、だが使いたい機能だけ使えば良い
  • KV, Event, Health Check...
  • consul-templateで動的LB設定

Q&A

  • rsyncが滑った時(消せないファイルがある)はStretcher全体がabortするように設計
  • ためにし1台、のときはeventを1台に送る
    • consul-lockを使えばn=5にすると5台ずつ完了を待って実行していく
    • あとはグループを分けるとかしてBlue-Greenっぽい挙動を作る感じ
  • 同じアプリをポート番号だけ変えて複数持つ、みたいなケースにも使える?
    • SRVレコードを引くとポート番号を含めたディスカバリができる
    • サービス名、サービスIDは一意に
  • StretcherとかDashboardはどれくらいで実装?

うっかりをなくす技術

  • @karupanerura
    • うっかりACアダプタを忘れてしまった
      • 貸して頂けました
    • Kenta SATO
    • Perl/XS/Swift/Kotlin/Java/Crystal/C99
    • Gotanda.pm
    • Senior Engineer at Mobile Factory, Inc.
    • CPAN
      • Time::Strptime
      • Geo::Hex:V3::X5
      • etc
    • YAPCで毎年少しずつ大きなところで話させてもらい、主催側に
      • YAPCありがとう

人間は失敗する生き物である

  • ヒューマンエラー
  • 安全工学とかですごい研究されてる
  • この観点から見たアプリケーション開発

  • Agenda

    • ヒューマンエラー
    • どのようにして気づくのか
    • どのようにエンジニアリングでなくしていくか

Huan Error

  • We neet safe code.
    • アプリをクラッシュさせたくない
    • うっかり間違えるし、すごい工数が発生するときもある
  • ヒューマンエラー≒うっかりミス
    • ちゃんとした定義をいろんな人が定義してる
    • David Meister
      • システムから要求された行為からの逸脱
      • エンジニア的には↑のオペレータ視点は"他の開発者"
    • 他の開発者の視点でコードやシステムを見つめる
    • 「システム」は人によってはインフラ、アプリ、ソースコード...
  • ファクター
    • 人的要因
      • うっかり
      • そもそもの間違い
      • 安全工学的には意識レベルを意図的に高める
        • 指差し確認、体と声を動かしながら意識を高める
      • NKY
    • マネジメント要因
    • 環境要因
      • 理解しづらいもの{コード、仕様、手順}
      • フェイルセーフにする、ミスに気付けるようにする

near-miss

  • ヒヤリハット
  • 実際に顕在化してないミス
  • ハインリッヒの法則
    • 1つの重大なインシデントの裏には30個の小さなインシデントがあり、そこにはさらに300のニアミスがある
    • それらはほぼ同じ要因で起きている
  • ニアミスの要因をなくしていけば、大きなミスも無くせる
  • 実際に損害を出さないので、非常に気づきにくい
    • どうやって集める?
    • github issues
      • 一覧できることが重要
    • コードレビュー
      • 他の開発者の視点を取り込める
      • 認識が違っていたらマズい合図

エンジニアリングによるアプローチ

  • 環境要因はエンジニアリングのアプローチが非常に有効

  • break

    • 五反田のおにやんまのうどんをバックに

easy to understand

  • 読みやすいコード
  • 説明的な命名
  • 副作用を減らす
  • "Art of Readable Code"

    • 読んで下さい!それでこの話は終わりです!
  • ドキュメント・コメント

    • そのコードの読み手は、コードに書かれていないことはわからない
    • なぜこのアプローチ・ワークアラウンドが必要なのか
    • これらを書いておけば、正しい取捨選択に役立つ
  • 副作用をなくす

    • 当然ながらグローバル変数を使わない
    • オブジェクトのライフサイクルを短くする
    • Immutableなオブジェクト・値を使う
    • 関数型的なアプローチ
    • オブジェクトはほとんどの場合状態を持つ
      • これを減らすためにはオブジェクトそのもののライフサイクルを小さくすること
    • Switch Frameworkをご存知のかた?
      • (Perlのカンファレンスなのに少ない!)
      • eg.)Sledge::Plugin::Stash

Simple ways

間違いに気づきやすくする技術

型制約

  • strict.pm
    • Perl5標準
    • 未定義変数の参照をコンパイルエラーしてくれる
    • soft referenceなどの危険な機能を制限してくれる
  • warnings.pm
    • perlは非常にコンテクストに敏感
    • '3:' + 2; # => 5 (!?)
      • +の手前をatoiしてしまう
      • こんなケースの時に警告を出してくれる

        コードの静的解析

  • perlclitic
  • perllint
  • 実行せずに間違いに気づく

  • swiftにおけるint?

    • Optional<int>シンタックスシュガー
    • Optional型がnullでないことを確認しないとコンパイルエラーを出す、nullが代入されえるかを明示する
  • guard.pm

  • GoとSwiftdeferに相当

Poka-yoke

まとめ

  • ニアミスをなくしてインシデントをなくす
  • 簡単に使えること、間違いに気づきやすいこと

Q&A

  • 一番うっかりが減ったアプローチは
    • 静的型付け言語を触ると補完の強みも相まって想定外の挙動はかなり減った気がする
  • コメントがコードを反映してない現象への対策
    • コードをみんなでレビューして、その場でコメントをコードと同等にレビュー対象にしてもらう
    • コードとコメントの整合性を機械的にチェックできる機構ができれば良い未来がありそう
  • うっかりが出そうな、ニオうコードの傾向は
    • 他の人の書いたAPIをどのように自分が叩くだろうか、といった考え方で触れてみる
    • コードから連想する使い方をそのままぶつけてみる
  • 静的解析ツールの、理不尽な指摘への対処
    • perlcliticなんかは重箱の隅をつつく感じの理不尽な指摘がある
    • それをほったらかしても問題が出ない、と経験的に確信が持てるものなら無視しても良いと思う
      • たとえばundefを返すコードが怒られる
        • カラコンテキストだとundef、リストコンテキストだと[undef]が返って罠っぽい
    • 自分は破るときは意図して破るようにしています

LT

良いオフィスランキング

  • 941
  • くしい
  • '10~13 YAPC::Asia主催
  • いろんな会社に訪問して紹介してます
  • 941::BLOGのすごいところ
    • 業界の知名度が抜群
  • もっと選択肢は有るよ!と昔の自分に言い聞かせたかった

  • 良いオフィスランキング

  • NHN Japan
  • Gree
  • Cookpad
  • 現Wantedly
  • 旧Freakout
  • ネクストイノベーション
  • リッチマン・プアウーマンのモデル
  • 超リッチ: Microsoft
  • 頭おかしい: バーグハンバーグバーグ

Gitのつくりかた

  • DQNEO
  • どきゅねお
    • 今月メルカリに就職しました
  • "gitを理解する最良の方法、それはgitを自ら作ることです" --DQNEO
  • gitはVCS、というよりコンテンツ管理システム
    • キーバリューストア
      • キーはSHA1ハッシュ
      • バリューはzlib圧縮するされた何か
  • "hello world\n"
  • blob 12\0hello world\n
    • 圧縮して保存: git add
    • 解凍して取得: git cat-file -p
  • git checkoutは

SaaSで作る僕らの障害対応術

  • @papix
    • GAIAX
  • みなさんびっくりどっきりメカで対応体制を作ってると思います
  • 障害は、ただ治ればOKではありません
    • 何故起きたのか、どう解決したのか、どう再発防止するのか
  • 今回はSaaSを組み合わせた障害対応の仕組みを作ってみました
  • Mackerel::Webhok::Manager
  • Meckerelを軸とした障害対応の仕組み
    • Webhookを投げて再現
    • 「今ホントにアラート飛んできた」
    • Qiita:TeamとTwilioに通知
    • Reactioを使って対応
  • 障害はなくなりません
    • (さらに障害アラート)
    • 備えあれば憂いなし

cpm

  • Shoichi Kaji
  • cpm
    • CPAN client
    • cpan.pm、cpanplus、cpanmがある中で何故?
      • 皆さんちゃんとperlでものを作るときにはたくさんのCPAN依存を持つことになる
      • 既存のツールは直列で膨大な時間がかかる
    • 実際のところ新しいことはなくて、
    • menlo(cpanm 2.0)を並列で叩いてインストールします
    • Plack 50s -> 18s
  • cpanm --dev App::cpm

Norikraで作るPHP検知システム

  • Masanori Nagano
  • PHPの例外を検知し通知するシステム
    • error_log()で返す
    • set_exception_handler
      • try~catchの外の例外を受け取る
    • set_error_handler
      • エラーと例外は別物、例外をエラーに変換する
    • error_reporting & error_log
      • 設定してないとApacheエラーログに出て行く
      • プロセスごと落ちるとさらに別の場所にエラー
    • PHP(mod_php)は4箇所に吐かれる
    • Norikraを使ってます
      • td: in_tail x 4
    • 調べたらudzullaさんが全部書いてました
      • udzullaさんすごい

RSSをざっくりクロールしてゆるふわにパース

  • 角田さん
  • @ace_project
  • Feedwind
  • 事例(クロール)
    • 配信元に連絡して解除してもらう
    • 連絡がつかない場合はプロキシを使って乗り越えている
  • 事例(パース)
    • Mojo::DOM
    • パースできないやつにぶつかりサービスがダウン
    • <br< <- (!?)
    • 壊れてるDOMをパースできなかった
      • 今後のことも考えてゆるふわにパースするようにしました
  • できるだけ集めてできるだけパースしてあげよう、という姿勢が大事なんでないかと思います

Slack+Hubotでお前の一番好きな二次元嫁キャラと一緒に仕事をする

  • @sairoutine
  • さい
  • 趣味プログラミングしてますか?
    • 結構やってますね、ほいほいほいほい
    • だいたい一人でやるので寂しいですよね?
  • 事例: @marisa
    • 自分と@marisaでチームを作りました
    • Botとふたりきりのチームってとこ、ミソですよ
    • 他の人としゃべることがないようにしておく
  • cronモジュールは全部やるのは面倒なので、jsonにまとめて食べさせます
  • tw ......で投稿だけ
  • deployissue listtrello add
    • 一人なんで自分でやったほうが早い気がするけど、botが自分のために動いてくれる、嫁っぽい!

YAPC?雨事情

  • @likk
    • Mobile Factory
  • 会社を出たら雨
    • エレベーターを降りてから気づく、傘はオフィス
      • 戻るの面倒臭い!
    • 定時に五反田で雨が降ってたら通知したい
    • tenki.jp
      • newして東京の場所を指定すると画像が出てくる
      • 拡大して五反田の位置をマッピング
        • GD::Imageで画像差分検知、差分がアレば雨とみなす
  • すごい過去にも遡れる!
    • 歴代YAPCの雨事情を起こしてみました、懇親会だけ雨みたいな日も
  • 雨通知アプリametto/熱中症検知アプリachitto

PUGS ON STACK

  • HIRATARA
    • Freakout
  • PUGS
    • Perl6のHaskell実装
    • 2007に開発停止、ほとんどの機能が壊れている
    • githubに6.2系のメンテナンス(開発最新は6.28)
  • ghc 7.8でビルド
    • ghcはバリバリ非互換変更があり、最新ではビルドできない
  • 7.10とstackでビルドできるようにしてPR送ったら速攻でリリースしてもらえました
  • ベンチしてみたらめっちゃ遅い!
    • 50ms or dieってことで最適化してみました
    • モナド変換を潰したら早くなるので潰してみる
      • Rakudo実装より早い!?
      • 10000万回にすると逆転

PHPの話をします

  • gongoZ

  • 肉体言語を作ったりEmacs内部で一句を見つけるelispを書いたりしてます
  • PHP5.4のセキュリティサポートは'15 9/14までです
  • 5.3の壁
    • うち最大のものがregister globals
    • 「安全でないコードを書くことが極めて容易になることを意味します。」
    • 未だonのアプリの特徴
    • includeしてきた変数と見分けがつかない
  • php.netにのってる
  • 使ってはいけない、間違っています
  • php.netにない隠された仕様
    • $_FILES
      • 個別にマッピングされる
      • 「その結果に驚くことでしょう。」
        • ちゃんと書け
  • $_SESSIONSも対象です
    • リファレンス渡しで来てる!!!

同人活動の報告と今後の展望

  • 本日はコミケ、じゃない、YAPC
  • Kokusaitenjijomae.pm
  • 先週の金曜から日曜まで夏コミでした
  • 例の紐じゃなくて例のモヒにしたい

  • 同人サークル どんぞこ楽屋

  • Acme大全2015頒布中です
  • Acme大全の裏の裏
    • 表ですね
    • 何で書いてる?
      • Word
    • フォントは何ですか?
      • IPAexフォントです
    • なぜつくるのですか?
      • CPANにあるからです
      • 割と苦役に近くなっている
    • なぜ7/7に?
      • ドキュメントに残さないと忘れます、忘れました
    • Acme::Cake
    • 書いてて行き詰まった時
      • むしろ進みが良いと焦ります
    • 電書版は
      • Perl6と同時リリース予定です!
    • いつまでやるの?
      • Perl6リリースまで...

第27回 PaaS勉強会

  • OpenShift v3 リリース記念
  • PaaSを勉強する会です
    • herku, MS Azure, GCP...
    • PaaSと組み合わせるHashicorp product, CoreOS, Mesos...
  • あるべきPaaSの姿を求めてみんなで調べてみんなでつくってみんなで学ぼう、が主旨です

OpenShiftとScheduler

  • Kenjiro Nakayama
    • RedHat OpenShiftサポートエンジニア
    • Fedor Project パッケージメンテナ
    • Emacsコミッタ

なぜScheduler

  • OpenShiftV3のスケジューラ←k8sのスケジューラと全く同じものが使われています
  • 勉強すると役に立ちます
    • k8sの構造が難しくなっている、結構勉強になります
    • プラガブル
    • 入り口としては良い
  • 個人的にはHOTです
    • Mesosフレームワークとしてk8s on Mesosができるようになります
    • スケジューリング周りが最強になる風潮
    • k8sだけのスケジューラがどんなもんか、まず把握しておくのが重要

OpenShiftとSchedulerの仕組み

  • 今回はJob Schedulerの話ではありません
    • バッチ処理のやつではない
    • 今RHからk8sへJobSchedulerのプロポーザルPRを投げている
  • どのNodeにPodを配置するか
    • CPU/Memoryリソースやポートなどで、ベストフィットするノードを選択
  • OSv3はk8sのSchedulerをそのまま使用

  • oc get node

  • oc create -f hello-pod.json
  • oc get pod --watch
    • Pending状態で1時間待ってしまうことがあります
      • 待ってはいけない
    • oc get event | less
      • Error scheduling: failed to pod
      • 名前は一緒だけど、ポートが被ってる
  • oc delete pod hello-openshift
    • バッティングしてるポートの1つ目を消すと後のがREADYになる

Scheduling Steps

  1. ノードのフィルタ
  2. predicates
    • ≒フィルタ
    • Portが競合するNodeをふるい落とす、要求したリソースの上限を超えるNodeをふるい落とす
  3. ふるい落とされなかったノードにPriorityをつける
  4. 0~10までのスコアを計算、各Priorityの計算で重み付けして、スコアと掛け算させることも可能
  5. 最もフィットしたノードの選択
  6. 同じスコアはランダムに選択

意外と単純な振る舞いに鳴ってますが、Priorityの計算だけ少し複雑

Predicates

  • PodFitsPorts
    • 既存のPodとportが競合しないノードに絞る
  • NoDiskConflick
    • GCEとEBSを使っている場合に、Diskがconflictしないのーどに絞る
    • OSv3は↑2つではまだTechPreview
  • PodFitsResources
    • リクエストしたPodのCPUとMemoryがノードのCapacityを超えていないノードに絞る
  • MatchNodeSelector
    • 指定したSelectorがマッチするノードに絞る
  • HostName
    • Host名の指定が既存のノードのホスト名にマッチしているものに絞る
  • LabelsPresence
    • k8sの機能、ノードのラベルで絞る
  • ServiceAffinity
    • Labelのvalueに関係なく、ラベルの付いているNodeにpodをデプロイ
    • チューニングの腕の見せどころでもある

Priority

  • LeastRequestedPriority
    • 要求されているリソースが最も少ないリソースのノードにデプロイ
  • BalancedResourceAllocation
    • CPUとメモリで偏りがないPodにデプロイ
    • ↑とセットで使うのが吉
  • ServiceSpreadingPriority
    • 同一ノード上に同じサービスが稼働しないように分散させる
  • EqualPriority
    • 基本使わない
    • 指定のないノードを1に
  • LabelPreference
    • ラベルのあるノードにweight分だけscoreを足す
  • ServiceAntiAffinity
    • ServiceAffinity同様、チューニングの腕の見せどころ

Affinty(Zone), Anti-Afinity(Region, Rack)

  • 同じゾーンにしたいけど、リージョンとラックは分けたい場合

Default Schedule Policy

  • ポート害競合しない、リソースがNode上限を超えない、など
  • Affinity周辺は自前でチューニングする必要がありますが、ほっといてもだいたい上手くいきます

Debug in Error

  • SchedulingエラーはPending状態になるので、eventを見て下さい

Resource

  • Nodeを走らせたタイミングでetcdにリソース情報が送られる
    • 完全同期ではない
  • k8sで管理していないリソースは見ていない

Schedulerの苦労

  • なぜ不完全か
  • 計算されるリソースはCPUとMemoryのみ
    • トラフィックやストレージは考慮されていない
    • ↑2つをWeightに加味するのはなかなか大変なので、先送りしてます
    • upstreamで動きはあるので、入ってくるんじゃないかな、というのが個人の見解です
  • OSv3(k8s)で管理しているリソースのみを計算
    • Mesosは他のホストプロセスも考慮するけど、OpenShiftが動いているホストで直接バッチなんかを回すとpodが影響を受けることがある
    • とはいえ、OpenShiftを動かすホストで直接なんかやるのはなにか設計が間違ってるのでは、と思っています

割と新し目のOpenShift Originで作る自宅PaaS作成記

  • 原嘉彦
    • @GORO_Neko
    • 某ITベンダに勤めています
    • 日本OSS推進フォーラム(JOPF)
    • OpenShiftの中の人でも、プロでもありません
  • 一回も組んだことのない人が構築してみる、動かしてみる、というレイヤーです

OpenShift Originの構造

  • Docker + k8s + 何か、でできているPaaSです
  • 4台構成の場合
    • マシン1にOpetShift-master
      • ログインなど
    • マシン2にOpenShift-node
      • インフラ的な役割
      • docker-registryなど
    • マシン3、4にユーザーの使う

構築してみる

  • 構築方法
    1. 1つのDockerコンテナにマスターもノードも構築する
    2. 1つのVM(Vagrant)にマスターもノードも構築する
    3. 別々のマシンにマスターとノードを構築する
  • 今回の環境

  • ソースコードの準備

    • openshift/origin
    • リリース版のバイナリもopetshift/origin/releasesに、現在は1.0.3
  • 起動・ログイン
    • 素のVagrantfileはmemory1024
    • RHのガイドラインは最低4GB、8GB以上推奨
    • 開発版は動きが定まってないみたいなので、リリース版が吉です
    • openshift startすると設定ファイル群はカレントディレクトリ以下にできてしまう
      • 環境変数周りはサービス起動のものに準拠、sudo systemctl start openshiftだとトップノード以下に配備される
  • Private Docker Registryのログイン
    • oadm registroysu権限で

気になったこと

  • jsonの書き方がよくわからない
    • 何はともあれ公式ドキュメントかー
    • (中の人)ちゃんと使うと実はあんまり書かなくてよいです
      • 古いドキュメントを引きずって書かないといけない雰囲気になってますが、シェルとかでも書けます
  • VagrantSELinux, firewalldが止まってる
    • 利用する形だった気がするが、まだ未実装の様子
    • (中の人)SELinuxVagrantのみです、実機はEnforcing、firewalldは未実装でiptablesゴリゴリです
  • 開発が進むほどコマンドが変わる
    • もう少しソフトランディングしてもらえないものだろうか
    • (中の人)他のコマンドとかぶっていた事実がありました、1.0.0以降で変わってたら殴って下さい

OpenShift v3のCIとCD

  • 去年の7月Flynnをベースに開発開始、おそらくDockerベースPaaSでは最速でエンタープライズベースに持っていった

    • 皆さん上から「Docker使え」ってなんか降りてくるようで、今エンタープライズで日本語サポートが有るのはOSだけ、ということらしい
  • Takayoshi Kimura

    • @nekop
  • OPENSHIFTの特徴

    • k8sがスケーリングや障害復旧、B-G Deploymentなど基本的な機能をカバー
    • ドキュメントが古いのを引きずっていて難しく見える
    • OSのデプロイは慣れれば簡単
      • Dockerを知らなくても動かせる
      • プラットフォーム非依存
  • oc

    • oc login
    • oc new-project
    • oc new-app <git clone url>
      • DBなどを使うアプリはテンプレート(長いjson)利用、実は無くてもnew-appを何度か叩けば無くても建てれます
    • oc expose service <service name>
    • http://..
  • 基本的な開発フロー

    • git pushやoc start-buildでビルド指示
    • OpenShiftソースからDocker imageをビルド
    • OpenShiftが自動でデプロイ
  • この流れでどうやってCIを?

    • Jenkinsを使う

      • Docker imageのテストにJenkinsは基本大変
      • Jenkins slaveを混ぜてDocker imageビルド
      • コンテナ内でsshdを建ててslaveをプロビジョニング
      • Jenkinsを使う場合Docker、コンテナの恩恵は受けられないけどOpenShift関係なく普通にOpenShiftの外でJenkinsを使うのが無難
        • CloudBees社が先月、今月にDocker対応/k8s対応を発表しました
    • STIビルドにテストを混ぜる

      • フックスクリプト自体を置き換える必要があります
        • 前処理/後処理フック追加をfeatureでissueがあります
    • fabric8
      • DevOps促進統合プラットフォーム
      • まだあんまり見慣れてないですが、見た目キレイなので統合できたらよさげ
  • OPENSHIFTでCD

    • IMAGESTREAM
      • OSの中で一番わかりづらい概念だと思う
      • Docker imageへの参照、を管理するオブジェクトです
      • IMAGESTREAMのタグ、実際はgitにおけるブランチのようなもので管理

Docker PaaSとしての OpenShift. DEIS, Flynn比較

  • Kazuto Kusama

    • @jacopen
  • Open PaaS

    • 今回話すのはDEISとFlynn
    • OpenShift勉強会でOpenShift以外の話をします
  • OpenShiftのいいところ

    • 進化著しい
      • そもそもk8sの進化が早い
    • github連携、webhookなど、便利な機能が最初から備わっている
      • きれいなGUIがあるのが良い
        • CloudFoundryはありません
    • RH, Google, ...のベンダや開発者が作っている安心感
  • OpenShiftのここがちょっとなー
    • 色濃くk8s、簡単に使えるPaaS、とはちょっと毛色が違いそう
      • デプロイのためにjsonを書かされる
        • 実はYAMLでもシェルでも書けますが
    • CloudFoundryほどエコシステムが広がっていない

DEIS

  • Docker, CoreOSベースのPaaS
  • '13~、OpDemand→EngineYard
  • PaaS、CLIはすごい地味
    • deis create
      • 作られました!超地味!
    • git remoteするとdeisリモートができている
    • git push deis masterでgit経由でデプロイ
      • buildpackでデプロイされています
    • deis openで表示
  • 簡単にアプリがデプロイできるよ
    • 要はherokuインスパイア
    • PaaSなのでスケールアウトも簡単
      • deis scale web=3
      • スケジューラのせいか、20秒くらいかかるけど簡単にインスタンスを増やせます
  • メリット
    • Herokuライクな使い勝手
    • Buildpack, Docker image, Dockerfileなど様々な仕組みが利用できる
  • デメリット
    • スケジューリングが遅い
    • Production投入にはもう少し
      • EYがDeis Proってのもあるようです

Flynn

  • '13 クラウドファンディングスタイルでスタート

    • 現在はPrime Directiveが主導
    • dokku開発者が在籍
  • flynn create

  • git remoteするとflynnリモートができている
    • デジャヴ
  • git push flynn master
    • FlynnもBuildpackを使っています
    • コッチのほうが早い
  • flynn routeでエントリポイントが表示
  • flynn scale web=3

    • すぐ終わる
  • シンプル、モジュラー、カスタマイズしやすいアーキテクチャ

  • PaaSに必要な要素がFlynn内で完結している
    • OpenShiftはk8s、DEISはCoreOSのFleetあたりをバリバリ使っているがFlynnはワンストップ
  • 開発の継続力に一抹の不安
    • 会社の規模が違いすぎる
  • Ubuntu前提

  • All-in-OneはどれもVagrantが提供されてます

  • 開発言語は全部goです

Open PaaS tsuru

  • たかはしなおと
    • @tnaoto
    • Cloud Foundry理事

tsuru

  • ブラジル開発、golang
    • '12 3.14~
    • どこかでコードがらっと変わっている可能性はある
  • インストール: all-in-one or Vagarnt

    • http_proxyがあるとどうやってもインストール出来ないので諦めましょう
  • Webインターフェースもtsuruアプリとして動いている

  • tsuru app-create hoge ruby
    • Rubyを別途ビルド、Buildpackを事前にビルドしてるような形
    • repositoryが吐かれる
      • git push hoge masterでデプロイ
      • nokogiriがビルドできないらしく、必ず死ぬので...
  • デモではダッシュボードをもう1個デプロイします

    • tsuru app-create dashbord2 python
    • git push dashbord2 master
  • アプリはplatformと呼ばれるランタイムで動く

    • 実態はdocker build
    • baseimageを作って、そこにアプリをデプロイしている
    • 実行時のアプリはcircus
  • 運用管理も考えている

    • 物理ホスト管理
    • dockerプール管理
    • platform管理
  • service

  • contributeするなら今のうち
    • 1.0.0が25%くらいです

  • どれもVagrantで試せます

    • どっかのPaaSと違って2GBもあれば動きます
  • 次回

    • PaaS x IoT Node-RED勉強会
    • 8/26
      • 110/50人でめっちゃ好評なので、今後頻繁に開催します
    • 第29回は多分9月上旬〜中旬、多分品川あたり

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に参加している皆様は素晴らしい