HashiCode#2 HashiCorp道場番外編 〜HashiConf 2015報告会〜
- HashiConf 2015
- NomadとOttoの紹介
Otto
Sessions
- Electric Cloud
- Groupon
- Databases as Pets
- ペットのように手厚くかわいがる
- 家畜のように病気になったものはとっかえひっかえ
- State Engine
- Consul, Consul Templateを組み合わせてステート管理をするサーバがいる
- Efficacy vs Efficiency
- どこまで効率化するか、という問題
- ヒトの三倍くらいがグルーポンの目処
- 3回やったら自動化、という感じ
- Databases as Pets
- Capital One
Pinterest
- Layer 0, 1, 2
- AWS: 0
- ベース環境: 1
- 本番環境: 2
- Jenkins
- 開発環境のイメージを回して、本番にイメージでもう一周
- Layer 0, 1, 2
KeyNote day1, day2
- Mitchell Hashimoto氏
- Vault 0.3公開
- 使い捨て認証のサポート
- HashiCorp DevOps
- Slackの画面に
Atlas - Packer Builds、Atlas - Terraform Builds - EAST-AWS Services(35) Nodes(61)
- Slackの画面に
Otto
- おっとサーバ店ではありません
- Vagrant後継ソフト
- 開発者はデプロイしたい
- マイクロサービスは未来
otto dev, otto build-> Vagrantotto infra-> Terraformotto build-> Packerotto deploy-> Nomad- Appfileがあってもなくても動きます
- Vagrantfile, Terraform Templatesなど既存のリソースも読んでくれる
- Appfileは開発中だけど、最終的にコレ１ファイルのバージョン管理で完結したい
otto compileでAppfileから各フォーマットに変換、中間ファイル生成みたいな
- 必ず裏にConsulが居て、スケール管理がしやすい
- windows版はバギーなのでまだおすすめしません
otto status- デプロイ先は今はAWSのみ、拡大予定
- Vault, Atlasと連携予定
- 既存の構成管理ツールとのすみ分けは？
- 現状Appfileは既存構成管理ツールとの互換性がない、殺しに来てるのではないか
- 開発ツールでもあり、デプロイツールでもある
- Docker対応
おまけ
- HashiCorpのポートランドは西海岸の山の中でした、浮浪者も少なくて安全でした
- 各サービスのステッカーをIDに貼って、
- HashiCorpの箸が配られていた
- ロゴの彫刻入り、ちゃんとしてる
- アメリカ入国は指紋をとった人は２回目以降アメリカ人の列の端末でも入国ができます、日本語メニューもあります
Q&A
- バージョンアップ頻度は？
- 可能なかぎり速く
- Issueは上がっていて、進行状況は見える
- 3ヶ月〜半年ごとに0.1は上がってるという感覚
- Serf自体はConsulに吸収される？
- 多分どちらも残り続ける
- Serfはオーケストレーションツール単体としては優秀、しかしConsul内部にもいる
- Consulに実装する、とはいっているが未実装
- ホントはSerfとConsulで別の仕事をするはずが、Consulで全部できちゃってる、というような状況
- バージョンアップ頻度は？
LT
吉田さん
- @yoshidashingo
- mizzyさんもHashiConfに
otto testがない- もしかしてあんまりMitchelテストが好きじゃない？
- VagrantだけRubyプロダクトが残ってる
- 20のセッションの半分以上はだいぶショボかったです
- 「使ってみた」レベルのセッションもある
- CFPの期間があったので、日本のユーザー事例で半分もワンチャンある
- 雰囲気はアットホームでした
@deeet
- 「ottoを読む」
- 第一印象：すごくPaaSに似てる
- herokuの
heroku pushのごときotto deploy、抽象化のレベルが近い
- herokuの
スケールを簡単にするのはまだできない
モニタリングはまだあまり考えてなさそう
- コードを見てるとめっちゃテスト書いてるんで、嫌いではないと思う
- あんなにテストとドキュメント書く人はめったにいない気がする
- 第一印象：すごくPaaSに似てる
Q&A
- IoTへの細かいCSV数百種類のデリバリを自動化する術はあるか
- Serf agent経由でイベントを握らせて、サーバに問い合わせるとか
- HashiCorp以外であればBourbon IoT(?)
- クリエーションラインのサポートはどういう？
- 「ご相談下さい」
- 今メニュー化してる最中です
- モニタリングツールの成熟が遅れている？多様な環境の監視はどうする？こまめに見るしか無いのか？
- 確かにこれからどうしようという感覚
- とりあえずは環境に合うように作っていくしか無い、銀の弾丸は今のところない
- 個々の画面から取れる情報(Zabbix/CloudWatch)を個別に見るしか無いのだろうか
- 時間とお金があればゼロから考えなおしましょう、となるでしょうが...
- IoTへの細かいCSV数百種類のデリバリを自動化する術はあるか
SORACOM Developers Conference #0
SORACOM 新機能発表
- '16 1/27 SORACOM summitやります
- このイベントが終わるまで、AmazonでBuy 1, Get 1
- レビューを書いてくれたら１枚進呈
- RasPiにドングルを挿す
- 8880円を本日5000円/本、先着１０本
新機能を発表します
カスタムDNS
$ adb shell adb$ getprop net.dns1 adb$ getprop net.dns2
- DNSのQuery Log
- デバイスの正常化道の確認
- 不正利用の検出
- プライベートDNSの利用
- Dynamic DNS
- DNSフィルタリング
- アクセス先限定
- 悪質サーバ回避
- DNS応答を変えて接続先を切り替え
未認証ユーザの認証用ポータルへの誘導
利用時の注意点
- 反映されるのはセッション確立時
- 反映させるには一旦切断、APIコールでDeactivate->Activate
- １SIMカードあたり+１日３円
- 10月中は無料でご利用いただけます
SORACOM Beam AWS IoT連携
- re:Inventで登場、AWS IoT
- 奥さん「あなた、大丈夫なの？」
- 大丈夫、かぶってません
- SORACOM AirはAWS 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パース
- シャドー
- デバイスがオフラインでもメッセージ受信できる
- 非同期通信
- レジストリ
- デバイス1つ1つの管理、Key-Valueによるメタ管理
SORACOM * AWS IoT(仮
SORACOM Airとその先に IoTのThingの今とこれから
- アットマークテクノ 竹之下さん
- @koyo_take
- ハードの話だけします
- IoTの事例
- デバイスとどう繋ぐ
- これからは無線
- Sub-Gたい、Mesh構成
- Wi-SUN、Zwave
- 機器管理プロトコル
- どれを選ぶかはお金の話が絡むのでケースバイケースです
SIMの開封からSMS受信までを5分でやり切る
- ぷらっとホーム 松下さん
- OpenBlocks IoT BX1
- ネタがない、メソられている！
- 肉体芸
- SIM開封からSMS受信まで
SORACOM AirでIoTするなら3G Rayで簡単に
- SKYDISC 橋本さん
- 福岡から来ました
- デバイスに強い県です
- SORACOM、何が凄いのか
- 導入の簡素化
- 低価格
- セキュリティ
- 通信の拡張
- まずは動かす
- 3GRay
RasPi + ダイヤルスイッチで
- アドベン 吉田さん
- 好きなAPI: /subscribers/{imsi}/deactivate
- SORACOMといえばコンソール
- プラン変更、一人MVNO気分
- ロータリースイッチでプラン変更できるようにしました
- node.jsラッパーを使って
どこでも光るよ回転灯
- アレグロスマート おさださん
- 振動センサー→RasPi→回転灯＆Slack
- リアルタイム性を強化してます、が、Sparkが遅いので別のアーキテクチャを模索中です
IoTによるがんばらない介護
- Z-Works 小川さん
- 健康寿命と実寿命の差、約１０年
- この間、介護が必要な時間
- ここでヒトの代わりにIoTを
- 介護
- 重篤化予防
- 徘徊防止
- ライフログ
- 死活監視
- やりたいことはご遺体を速く発見する、ということ
- 24h以内に見つけたい
- Z-Works 主要IoTデバイスで展開
- ヒトの行動を表すAPI
- ホームセキュリティ
- 重篤化予防
- 非接触で3m以内の心拍
- 開かないスマートロック
- 夜に監禁するロック
- 健康寿命をのばす
- 心拍をモニタして健康寿命の観測
- スマートターミナル
- がんばらない介護を実現した上に、手を繋いで別れを言えるように
育児にも活用できる家庭用IoTのススメ
- @mana_cat
- 4歳と7ヶ月の男児二人と保活をしてます
- TechGIRL、TechLION
- 先月から電子工作を始めました
- 赤ちゃんには温度管理が重要です
AndroidでもSORACOM Airを使いたい！
- @mhidaka
- 組込からモバイルまで
- techbooster.org
- DroidKaigi
- 通信料を節約するアプリを作りました
- IoT Gateway
- AndroidのVPN機能を転用、ローカルVPNサーバに渡す
- アプリごとの制御はVPN信頼性確保の仕組みを転用
- 工夫(地獄)が楽しい
- 最後はパケットキャプチャとかまで
- 今後
SORACOMとAzureでIoT
- @kekekekenta
- JAZUG
- ケンタテクブロの記事の補足的な内容です
- AzureのCortana Analitics Suite
- 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で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検証環境に求めるもの
- 共有したい
beam.soracom.io A 169.254.254.169- リンクローカルアドレスなので注意
- ルータ側でスタティックルーティングができないとコケる
C#からSORACOMを叩けるようにした話
Interconnect Casual
Interconnect variations
- 田籠さん
- トレジャーデータ
- インターコネクト ... 分散システム同士の内部の通信
- HPC
- 分散DB
- Hadoop
- ソフトウェアで完結するもの、HWを使うもの
- なぜそんなことを？
- 目的を満たすほどに速い
- スループットとレイテンシ両面において十分に速い、ということ
- Hadoop
- ブレードサーバ
- 処理の粒度によってインターコネクトの要求、要件は変わりますね
- shared everything/memory/disk/nothing の区別、とか
- 共有するメディアに負けないくらいの速度がインターコネクトに要求される
- shared everything/memory/disk/nothing の区別、とか
InfiniBand利用状況 さくらのクラウドの場合
- 鷲北さん
- さくらインターネット
- 会社が４人の頃からエンジニアをやっています
- 研究所所長→現場に戻されてクラウドのリーダー
- 最近のさくらはDC事業は3割くらい、ホスティングが6割になりました
- このオフィスも都市型DCです、コロケーションで表に出せるお客様があんまりいない
- さくらとInfiniBbandの関係
- 2010年頃の評価
- さくらのクラウド
- １ヶ月目でストレージに大トラブルが
- IBに対応してるストレージがコレだけだった
- opensm(subnet manager)が詰め切れてなかった
- 完全安定まで２ヶ月、それ以降は不具合無し
- ノード数500くらい
- eastもwestも帯域は十分に余っていて、10GbEくらいでぜんぜん大丈夫だった、というのが実情
- HCA: 発熱に注意
- loadにより加熱しがち
- CPU負荷は増えない
- ケーブルが太くて堅い
- HPCではIBケーブルは一旦挿したっきり抜かないというのが常識らしいが、さくらでそれをやると怒られる
- 設置の見極めが難しい
- 2~3習慣
- 年間10枚くらい故障してる
- Etherに比べて多め、エラーレートがじわじわ上がってきて壊れる、というパターンが多い
- ドライバ
- IBは素晴らしい技術だが
- IB以外に試したものは実は無い
- Converged Ethernet(ストレージとの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%の確率で壊れずに終了
- 高信頼: チップあたり10FIT(1億時間平均で1回故障)
- LINPACK
- 理論性能: 11.28PFlops
- 積和(=乗算+加算)計算回路4 * 8コア @ 2GHz、が88,128チップ、キャッシュほぼ100%で当てつつこれをNWで同期を取りながら93.2%の稼働率を維持し続ける
- わかり易い例
- 要件は複雑
- 通信パターンは様々
- 頻度
- 組み合わせ
- 隣接間のみ
- 様々な状況で低遅延、広帯域、高信頼
- 本来トレードオフであるべきものが全て求められる
- 通信パターンは様々
通信のコストは並列度の関数でもっと大変、サチりやすい
Tofu Interconnect
- その実装、ICC
- Core 2 Duoくらいの規模のものを0から設計・実装した
- メッシュかトーラス、６次元
- 「ここはどんなに説明してもわからない」
- ３次元が２つある
- 折りたたまれた3次元(Tofu Unit)の頂点それぞれが独立した３次元トーラス、各ホップが短い(1μs/hop)
- RDMA
- チップが自立してDRAMノード間メモリコピー
- キャッシュインジェクションは検討して捨てた
- バグが出やすい、デコヒーレンスを詰めきるスケジュールがなかった
- 宇宙線対策
- 畳み込まれた次元でトランキング
- 最初の１hopだけ決定論的に決まるものをあえて使わずに、隣接するものを巻き込んで送る
- トランキングに加えて耐故障性
- 隣接する3つのコントローラを巻き込んで対向に送ることで5GB/s * 4 = 18(実効)/20(理論)GB/s
- 最初の１hopだけ決定論的に決まるものをあえて使わずに、隣接するものを巻き込んで送る
- その実装、ICC
HPC汎用 = 万能が求められる
- 高機能
- 自立通信・演算
- 仮想記憶
- 高性能
- 低遅延
- 広帯域
- 信頼性
- 10 FIT
- 故障検出
- 柔軟性
- 任意サイズの仮想1/2/3次元トーラス
- 故障迂回
- 高機能
- 当時アメリカのBluewaterは動かしきれずにポシャった
- 「bluewaterが上積みしても出し抜けるようにTofuは理論的にはもうちょっと伸ばせるように設計しておいた」
- アクセラレータは計算する分野を絞る、Tofu・京はベンチマークマシンで終わらせてはならないという至上命題があった、それで高くなったという側面がある
- 汎用とはいえセキュア演算回路を普通じゃありえないくらい載せてます
- 中心メンバー10人、外注含めたら50人、プラス検証で10人
- 全部が出来ないと動かないので、仕様自体は数人
たまにはTeradataのこと、思い出してあげてください
- tweetはしないでいただきたい...
- 青木峰郎
- Rubyの標準ライブラリ作者、著者
- テラデータ→クックパッド
- 好きなバス: HyperTransportとBYNET
- 最強の並列RDBMSであるTeradataのインターコネクト
30年前から並列
- Teradata RDBMS(1983~)
- 全部専用HW
- v2は486を1000台くらい繋げる構想だったらしい
- Shared Nothing Parallel
- AMP(プロセッサ)が自分専用のdiskを持って、ノード間をまたぐことはない
- 最大2000ノード、リニアにスケール
- ex.)Oracleに代表されるのがShared Everything(diskが1つ)
- Redshiftの構成
- Teradataのマルチマスター
- すべてのノードがマスターになれる
- PE(パースソフトウェア)とAMPを繋ぐのがBYNET、専用ハードウェア
- 業界最強WLM、割愛します
- Shared Nothingはインターコネクトが急所
- BYNETのすごいスイッチ
- Teradata on AWS
- BYNETはない
- さらばBYNET
- たまにはTeradataのことも思い出してあげて下さい
YAPC::Asia 2015 2日目
データ分析基盤を支える技術
@repeatedly
入門寄り、実装まで踏み込むことはしません
#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
- そう甘くは行かない、１台で行ければみんなハッピーだった
- 更新に対して強いが、時系列に従ってデータ量が増えるクエリには強くない
もっと早い(並列分散)RDBMS
- 実際そうしてきました
- PRDBMS
- Netezza, Teradata, Vertica...
- Web系はあまり馴染みないが、大きい会社だと使ってたりする
- OLAP
- ある１行のカラムの更新に強い
- shared-nothingで分散しているノードごとに計算が閉じるように実行できる構造
- PRDBMSはほぼほぼこのモデルを踏襲
- １個使ったことがあるとわりとつぶしが効く
列指向ストレージ
- int型の列をint型だけでまとめて保存
- codeカラムを集計、みたいなケースに行指向よりI/Oが少ない
- 圧縮効率も非常に良い
解析に特化したデータフォーマット、現行の解析DBのほとんどが採用
「１行更新したい」みたいなケースには、すべて更新書けないといけないので遅い
- INSERTをサポートしてなかったり、非推奨だったり
解析基盤そのものはフツーに回せるようになりました
2000年代後半まではこんなかんじでした
「どうデータを配置するか」というユーザのノウハウがないとうまく回らなかった
分散キーを指定できる
- どの値をどのノードに分散させていくか
- 下手な分散方式だと裏でNWがゴリゴリ動いてパフォーマンスが出ない
銀の弾丸ではない
- 再配置中はライトができない
- メタデータのロックで１秒くらい待たされたりする
ずっと同じスキーマを使いますか？
データの保存だけ何も考えずにガーッとやって、使うとき・解析するときに定義すれば良いのでは
- RDBMS: Schema-on-Write
- データソース・データウェアハウスの分離の発想
- ライトはちょっと重いけど、リードが軽くなる
- Hadoopでは読むときに型を作り出す
- Schema-on-Read
Data Lake
- ベンダー臭がして使っていいのか微妙なんですが
- Hadoop、あるいはより広大なもの
- 型を変換せずに、生のまま保存して、Data Lakeがその差異を吸収する
- 実はいろんな人が提唱して人によって中身がバラバラ
- 共通項は「デカいストレージ」
Data Lake Patterns
Apache Hadoop
- いろんなものが乗っかりすぎて、どこからどこまでを指すのかわからなくなりつつある
- 一昔前はMapReduceでしたが、今では膨大な選択肢の一つ
- 間にHadoopみたいな何でも置けるものを置いておくと楽ちん
- ETLではなく、EL/Tのアプローチ
- 今でも現役
余談
Ingestion Tools
ログの保存手法
- バルクロード
- ストリーミング保存
- fluentd
- Flume
- いろんなベンダのディストリビューションに入ってる
- Logstash, Heka, Splunk...
- 同上
1TBのデータを変換するのにまた1TBのストレージが必要だったりする、インポートはなかなか大変
- ためたデータに直接クエリを投げたい！
MPP query Engine
- さっきのPRDBMSからストレージを引いたみたいな
- データはなんでもOK
- Schema-on-Read
- データはなんでもOK
- RDBMSならRDBMSのスキーマ、HadoopならHadoopのスキーマを読んで結果を返せる
- 界隈では「SQL on Hadoop」
- presto, Impara, Drill
presto
- FaceBook社
プラガブルなバックエンド
つらいケース
「もっと速報値がほしい！」
Apache Storm
- 世の中の解析基盤はほとんどApacheに支配されています
- 出てきたレコードをダイレクトに解析にかける
- １レコード単位に解析
- マイクロバッチ
- Twitterが利用したことで有名、がTwitterはもう使ってない
Norikra
- @tagomoris開発、日本製
- StormはGradleでクエリを書く必要があった
- SQLで書ける！
- しかし分散しない！
- モリスさんの努力が足りない
- MerkariやFreakoutでは使っている
Apache Kafka
- Apache Que
- pullがあるまでpushされてきたデータを貯めこむ
- データ分岐の粒度が違ったり、間隔が違うときに挟ませる
- push側(fluentd, Flumeなど)は受け側のリソースを考慮せずに送りつけ続けてしまうので、そこを吸収するのが主なMotivation
- ない会社もあるので、なくても動くことはあります
- Push型とPull型が入り乱れ出したら、挟むとよさげ
めっちゃたくさんある、つらい
- みなさんは解析がしたいのであって、運用はしたくないハズ
- Amazon RedShiftやBigQueryみたいな便利なのがあります
Amazon RedShift
Google BigQuery
- 数秒〜数十秒で返ってきて欲しい
- 構造はほとんど同じなんだけど、最下層のColossusがスゴいらしい
- しかし論文未発表で謎技術です
Treasure Data
Resource Model Trade-off
- フルギャランティード
- 急激なスケールには自力でスケールアウトする必要がある
- フルマネージド
- BigQueryとか
- たまにレスポンスが遅くなったり、アンコントローラブルな要因が挟まる
- TDはその中間くらいです
- MS Azureもこういうことが出来ます、スライドに盛り込みたかったけど時間がありませんでした
「解析したい！」
- やりましょう！！！
- しかし運用コストが超高い
- クラウドベンダがそうさせないように努力しているので、その波に乗っかるべき
- エッジな機能を使いたい場合に限り、一緒に運用をしていきましょう
まとめ
Q&A
- PrestoのコーディネーターのHA構成ってやりようがありますか？
- 人間が分析するときの可視化、ダッシュボードを作るときのトレンドってありますか？
- セキュリティ的に全く外にデータを出せない時のパッケージってある？
- 実はあんまりないけど、MSのAzure Service FabricやOpenStackくらいなのでは
- バックエンドのスケーラビリティを担保できないと、実用的な基盤が作れない
- S3相当のオブジェクトストレージを自前で持つ、みたいな努力が要ります
- 実はあんまりないけど、MSのAzure Service FabricやOpenStackくらいなのでは
YAPCあるある
歴代実行委員長的な人たち
- miyagawa
- takesako
- 941
- lestrrat
- yusukebee
牧さん、941さん、miyagawaさんいらっしゃってますが、呼び込みをしたいので一旦出てもらってます
- 拍手のコツ
- 細かく早く
- 大きく
- 声も
- 拍手のコツ
基本情報から振り返るYAPC::Asia Tokyo
いつ・どこで
入場者数の推移
- '09にドロップがあったのは秘密にしたかった
- 推移についてはクロージングで話します
スポンサー数の推移
- 6社→47社
- メディア協賛とか含めると60越え
出来事から振り返る
'06
- '05に台北であった、そこで話した時に「来年東京でやってくれ」と言われたので
- 次の日のトークで「来年やります」と書いて
- 竹迫さんやnaoyaさんとキックオフをした
- ミーティングはそれっきりだったような
- 当日朝に集まって「あとよろしく」
- (牧)僕の受けた引き継ぎは↑でした
- ミーティングはそれっきりだったような
- 無線も家庭用無線LAN並べただけで、ほとんどつながらなかった
- 当時WiMAXも試験してたくらいの時期
- 「ワイエーピーシーアジア」かなと思ってたらmiyagawaさん「ヤプシーエイジア」
- 売上を来年に持ち越したくなかったので、20万くらい黒字になったけどperl Foundationに15万くらい寄付した
'07
- 津田ホール
- '07の懇親会でDanKogaiさんと邂逅
'08
- 東工大
- ３棟で移動が大変でした
- 大ホールの階段がコケやすい
- 以降'11まで
- ActivePerlのカナダactive state社からスポンサー協賛
- 芝生で餃子
- Y!がカップラーメンを配ってお湯で行列が出来る
- 食べると眠くなる
- 最後余って学生に押し付けてた
- miyagawaさんの紫色のやつ(Yahoo!知恵袋あごまくら)
'09
- 運営がJPAに
- '08のスタッフ打ち上げまで何もなかったが、各々ちょっと思っていたようで
- ちょっとやってもいいかなー、と思っていたら決定事項になっていた
- 階段でコケた事案をうけて保険を契約する際に、法人じゃないとダメでした
- 牧さんは当日38度の熱を出しました
- カメラマンの八木さん
- ACTがフランス
'10
- 941さんコミット
- JFXに初ドタキャン食らった気がする
- (牧)「引き継ぎ資料なんてものはない」
- (宮川)「'08までのMLはbasecampに全部残してある」
- (941/牧)「それ引き継ぎの時に聞きたかった」
'11
- ランチタイムrejectしたら大不評
- 「おなかすいた」言いながらみんなみっちりトーク聞いてた
- 941「トーク見るのは素人ですよ」
- 前夜祭で廊下で談笑してたら「静かにして下さい！」って言われた
- みねまつさんのマイクが壊れて大声でしゃべってもらった
'12
- 東大、一つの建物
- LTソンがすごかった年
- 人数が増えだして
- ぼっちランチ解消対策
- くじ引きして、お金あげてみんなでランチに行ってもらう制度
- RubyKaigiからパクった
- 個人スポンサーも
'13
- 慶応
- 941さんが会期中ずっとマークされてた
- CONBU
- 個人スポンサーの単価増
- おまもりを作った
- バグ封じのお守り
- 中には"Shut the fuck up and write some code"
- おまもりを作った
'14
- ゆーすけべーさん
- HUB貸切
- 宮川「今年はないのでちょっと不満ですね」
'15
- 会場がビッグサイト
- 5トラック、2000人超え
- 懇親会はキャパ700に600人
- 慶応では満員電車でご飯を食べるみたいな教訓があったので
Q&A
- お世話になった人リスト
- 勉強になったこと
- YAPCの人の集まる求心力の秘訣
- (941)負けを知りたい
- 嘘です
- 新しい人をどんどんいれること
- (牧)法人化して、投資できるようにしたこと
- 写真をとってもらうように
- ビジュアルで残して、想像できるようにできたのは大きい
- (941)負けを知りたい
YAPCに捧げたもの、得られたもの
- yusukebee
- 「LTは笑いを取るものなんだよ！」と言われたり
- あったかいなあと
- 一旦の区切り、ということで
- 941
- クロージング30分、長いなと思った
- 果たして最後なのかどうか
- 小さな飲み会みたいなのからイベントのノウハウを蓄積して、YAPCみたいな大きいイベントができるようになった
- みなさんも勉強会の主催・幹事を率先してやってみて頂ければ
- クロージング30分、長いなと思った
- 牧
- クロージングあるのでパスで！
- 竹迫
- 宮川
- yusukebee
HTTP/2時代のWeb
@Jxck
- Goでhttp2サーバ、クライアントを書いている
- mosaicfm
- http2study
- 今は正式名称がHTTP/2、HTTP/2.0と書いている記事があれば「古いんだな」と思ってくれれば
#http2study
日本人にすごいひとがたくさんいる
- nghttp2
- 「事実上のリファレンス実装」と言わしめた
- h2o
- kazuhoさんの発表とダダかぶりなんじゃないかと思って昨日の発表は全く見てません
- nghttp2
RFC 7540
- RFCになってしまいました
- みなさん既にお読みかと思いますが
策定のフェーズは終わった、使うフェーズに入った
今回は「理解した、導入する」を目指すつもりはありません
- 「気がついたらHTTP/2使ってたは」という世界も無くはない、実はそれはそんなに否定しなくてもいいのかもしれない
現状把握
- １ページ中のリクエスト数とコンテンツサイズは増える一方
- サイズも１こにつき2MB近くまできている
帯域 vs レイテンシ
- 帯域が増えたからWebが早くなる、というわけではないらしい
- やりとり自体のレイテンシが占める割合、それを削減する努力の方がクリティカルだということがわかってきた
速くするために
- RTT(ラウンドトリップタイム)を減らす
- 物理的に近くする
- レスポンスを早くする
- 光は案外遅い
- 光が早くなればいいが、どうやらそういう兆しはない
- RT(ラウンドトリップ)回数を減らす
- アクセス回数を減らす
- RTT(ラウンドトリップタイム)を減らす
HTTP/1.1
- テキストベース
- Header
- Body
- なんでもOK、バイナリでも圧縮でも可能
- TCPを毎回確立している
- 毎回3-Way-Handshake
- 毎回initial cwnd(輻輳制御)
- Head of line Blocking
- レスポンスが返るまで次のを返さない
- ひとつ詰まると後続が全部止まってしまう
- コレを受けて、ブラウザはこっそり6本張っている
- 2本推奨だったので6本張るようになりました
シンプルな一方高速化に限界が
- わりといろんな回避策を編み出してきました
- TCP
- TCP Fast Open
- 3-W-Hを
- InitCWND 10
- 昔ほど問題にならないので上げる
- TLS Session Ticket
- TLS False Start
↑Kernel level
それを待てない会社が独自プロトコルを作ってしまう
- これを標準化してみたのがHTTP/2です
HTTP/2
- バイナリフレーム
- パースしやすい
- サイズ効率が良い
- データ分割しやすい
語彙はそのまま(セマンティクス維持)
- GETはGETのまま
- 互換性をもたせる
ヘッダ何度も送る問題へのアプローチ
- HPACK
- ハフマン圧縮
- 頻出ヘッダ(200とか)を最初からIDにして共有
- 送信済みデータを再利用
- 圧縮の仕様だけ決めて、アルゴリズムは実装次第です
- http2studyでやってみて、高いものは8割方圧縮できたりしてます
- HPACK
1コネクションにストリームを多重化
- 全部同時に送る
- 全部一緒に送って全部遅くなるのは困るので、リソースに優先度をつける
- 画像より3倍cssにリソースを割り振る(ソケットに書き込む)
- コネクションを使い切る
- これまで6本がバラバラに走り出して、コネクションの割に帯域を使い切れてない
- １本にすればハンドシェイクも１回、帯域の限界までデータを送れる
- ベンチマーク
- https://jxck.io/labs/hol/
- 数字でも速く、それ以上に画像がの出る順番から体感で速く感じる
Server Push
- 1リクエスト1RTだった壁を超える
- Cache-Controlでブラウザキャッシュさせてると思いますが
- 熾烈なキャッシュの奪い合い
- 75%の人は48時間で領域を使い切っている
- 2日経てばクライアントキャッシュが無条件に空になっているかも
- Pushで積極的なCache管理していく案
- Service Worker
- フェッチとプッシュを全部jsで操作できる可能性がある
- アプリとしての側面が強くなる
Pushが入ることの意味
- FetchとPushの両方をカバー
- コンテンツ配信だけじゃもったいないですねコレ
- WebSocket over http2
- gRPC
- アプリケーション、ミドルウェアレベルで積極的に使える可能性が
では、採用しますか？
Response Timeの後の世界
- フロントエンドの画像１枚、がバックエンドのニューニングを台無しにする可能性は往々にしてある
- Res.Timeは世界の半分しか測れてない
- Speed Index
- Real User Monitoring
- 数値化しにくいものも多く、過渡期ではあるがレスポンスタイムだけで速度を測れる時代はもう終わった
最適化
- ものすごく素直に作っても遅くならないかもしれない世界が近づいている
実装
- まだ追いついてません
インフラ
- ロードバランスどうするの？
- HTTPS終端は？
- need more 知見
- まだ弱いです、議論が欲しい
HTTPS
- Pervasive Surveillance
HTTPS前提？
HTTP/2は巨人のものか？
- 戦ってるレベルが違う
- 毎日がDOSみたいな世界
- 我々のアプリが複雑でない、というわけでもない
- HTTP/2は使っても使わなくてもいい、というのがいいところ
- クライアントは標準化のおかげでいつのまにか導入されています
- リバプロ挟むだけで高速化した事例もある
- 今足りないのはノウハウ、ただそれだけ
これからどうなるのか
- priority 最適化
- HTTP/3の話ももう出てきています
- TCPの限界
「理解した、導入しない」
- 戦略としてはあり、ただしとどまり続けるリスクに注意
- まずは触ってみれば良いと思います、どうせまだ実装は足りていない
「能く知らないけど導入する」
- エコシステムの成熟次第ではあり得る
まとめ
- RFCが出てしまった
- HTTP1.1はなくなることはないので安心してください
HTTPS化はした方がいい、まともな新しい機能もだんだん試せなくなっていく
nginxが2015年末に実装を宣言
- ここが一つのチェックポイントになるのではないか
次のIETFが横浜に11月で
- Twitterに愚痴っても世界は良くならないので、ココに投げ込むことを検討して下さい
- 日本のガチ勢も集まります
Q&A
- ブラウザキャッシュの中身を知る方法は？
- 実は無いんです
- h2oが出しているのはサーバがキャッシュしているかどうかのシグナルを持っておこう、という提案
- 二重にpushを送っても問題はないので、あまり深刻な問題ではないかも
- 普及にどれくらい時間がかると考えていますか？
- 思いつくのはメジャーなサーバが正しく実装している状態、それなら来年か再来年くらい
- では、みんながそれを使うかどうかはわからない、来ないかもしれない
- したいひとはする、という程度のものだと思う
- 来るとしても近い未来ではなさそう
- エコシステムが揃うのは？
- Webはエコシステムで作るものだと思っている
- エコシステムが、使う側から見て成熟すると感じられるのはサーバ側のミドルウェアが暗黙的にサポート・支援をしてくれる状態
- そして、みんなが勉強会やブログで知見を共有できる状態
- 知見は少しずつ出てきつつあるが、サーバ実装は全然なので2,3年かかるだろう
- プライオリティの指定は明示できる？
- 今はブラウザの実装に依存しているが、
Resource HintsというのでProbabilityを指定することはできる - まだ実装の議論の段階
- 今はブラウザの実装に依存しているが、
- 昔から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になる技術
モダンなクライアントサイド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::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移行後の悩み
Consul
- 本番運用しているのは会場で3%くらい
- Agent
- Server
- クラスタ内の特定の奇数台で動いている
- うち１台がLeader
- 一人だとLeadarになれない、過半数(→最低でも2/3台)の賛成で選出される
- Raft
- クラスタ内の特定の奇数台で動いている
Service / Node Discovery
- サービス内のnode
- Service Definition of App
- :8500にRESTポート
- 最近外部DNS連携が出来るようになりました
Health Checking by script
- ユーザ定義のヘルスチェックコマンドを実行
- KVS
- memcachedのフラグにあたるユーザ定義を付けれる
- パフォーマンスはリーダーノードに向かって40000qps
- 他のノードはリーダーに問い合わせるので下がる
- かなり早い、遠慮なくGETできます
- PUTは427qps、そんなに頻繁に置かないはずなので深刻ではないハズ
- stale modeにするとリーダ以外でも応答できる
内部DNSとしてConsulを使う
- :8600に向けないといけない
- /etc/resolv.confではポート指定は無理
- 無理やり:53に向けるにはroot特権が必要で怖い
- :53は再帰問い合わせしないといけない、Consulはcache機能がないので難しい
- dnsmasq, bindなどからConsulをフォワードする
- resulv.conで
(node+service).consulを検索ドメインに指定- node/service名だけで検索できる
- BINDは夏休み取りたいので使いません
Deployment Table
- Server node: 本番では最低３台、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が引けなくなる
運用中のUpgrade
- クラスタは一回立てると落とせない
- ローリングアップデート方式
- 0.2時代からproductionに入れて1年運用してますが、agentが落ちたりクラスタが崩壊したりした記憶はないです
- Quorumが満たせないレベルまで減るとクラスタが崩壊します、データが飛んでしまう
- KVSは定期的にバックアップ、ユーザデータは絶対に入れないように
- Quorumが満たせないレベルまで減るとクラスタが崩壊します、データが飛んでしまう
オートスケール環境で使う
- Lobiの動画変換機能(ElasticTranscoder)
- S3に上げてキックしたら変換してくれる
- ちょっとお高い
- 1投稿2分で25円、1万人分で25万円
- S3に上げてキックしたら変換してくれる
- モンストにSDK導入しました
- 家が立つレベルでお金が飛んでしまう!!!
- →SPOTで変換する
- cc.88xlarge(32core) = 0.45USD/h
- 1/10〜1/100にまで削減
- ピーク時で45台くらいまでスケール、最低2台
スケールアウトはJobの量で
- リアルタイム性は低いので遅れてもOK
自動でuniqueなホスト名を付ける、join、Chef,デプロイ...
- user-dataでユニークホストを名付ける
- ChefのノードをConsulのKVに入れる
- Stretcherでdeploy
- Zabbixに登録
- OS起動時に登録するとアラートが飛んでしまう
Stretcherを利用したデプロイ
- 自作しました
- ConsulとSerfで動くデプロイツール
- これまでは中央サーバからのデプロイ
- このpush型はオートスケールに対応できない
- pull型で中途半端なときに持っていかれると困る
- gruntやGoの生成物を格納したくない
- デプロイのたびにAMI再生成はやりたくない、10デプロイ/日もできない
Stretcher
sorah/mamiyaとAWS CodeDeployとほぼほぼ同じですビルドしたものをtarにしてS3へ
YAMLの定義ファイルmanifestもS3へ
- 各ホストのConsulがtarとYAMLを読んでデプロイしてくる
Consul Event
- ビルドプロセスは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
Blocking query
- 次のリクエストが来るまでリクエストを待たせる機構
オートスケールでのデプロイのtips
- 最新のmanifestをConsulのKVに格納
- AMIに残ってる古いアプリが起動すると事故る
- 最新のデプロイID出ない場合は起動しない
- 初回起動時のみ、daemontoolを起こす前にKVとローカルの値を比較する
- 最新のデプロイID出ない場合は起動しない
bash-completionでsshのホスト名補完
- known_hostsを参照するときのfunctionを.bash_profileで上書きしてKVを参照するようにするとすっきりする
まとめ
- Consulは機能豊富、だが使いたい機能だけ使えば良い
- KV, Event, Health Check...
- consul-templateで動的LB設定
Q&A
- rsyncが滑った時(消せないファイルがある)はStretcher全体がabortするように設計
- ためにし１台、のときはeventを1台に送る
- consul-lockを使えばn=5にすると5台ずつ完了を待って実行していく
- あとはグループを分けるとかしてBlue-Greenっぽい挙動を作る感じ
- 同じアプリをポート番号だけ変えて複数持つ、みたいなケースにも使える？
- SRVレコードを引くとポート番号を含めたディスカバリができる
- サービス名、サービスIDは一意に
- StretcherとかDashboardはどれくらいで実装？
うっかりをなくす技術
- @karupanerura
人間は失敗する生き物である
- ヒューマンエラー
- 安全工学とかですごい研究されてる
この観点から見たアプリケーション開発
Agenda
- ヒューマンエラー
- どのようにして気づくのか
- どのようにエンジニアリングでなくしていくか
Huan Error
- We neet safe code.
- アプリをクラッシュさせたくない
- うっかり間違えるし、すごい工数が発生するときもある
- ヒューマンエラー≒うっかりミス
- ファクター
- 人的要因
- うっかり
- そもそもの間違い
- 安全工学的には意識レベルを意図的に高める
- 指差し確認、体と声を動かしながら意識を高める
- NKY
- マネジメント要因
- ワークフロー改善、ドキュメンテーション、自動化で対策
- 環境要因
- 理解しづらいもの{コード、仕様、手順}
- フェイルセーフにする、ミスに気付けるようにする
- 人的要因
near-miss
- ヒヤリハット
- 実際に顕在化してないミス
- ハインリッヒの法則
- １つの重大なインシデントの裏には30個の小さなインシデントがあり、そこにはさらに300のニアミスがある
- それらはほぼ同じ要因で起きている
- ニアミスの要因をなくしていけば、大きなミスも無くせる
- 実際に損害を出さないので、非常に気づきにくい
- どうやって集める？
- github issues
- 一覧できることが重要
- コードレビュー
- 他の開発者の視点を取り込める
- 認識が違っていたらマズい合図
エンジニアリングによるアプローチ
環境要因はエンジニアリングのアプローチが非常に有効
break
- 五反田のおにやんまのうどんをバックに
easy to understand
- 読みやすいコード
- 説明的な命名
- 副作用を減らす
"Art of Readable Code"
- 読んで下さい！それでこの話は終わりです！
ドキュメント・コメント
- そのコードの読み手は、コードに書かれていないことはわからない
- なぜこのアプローチ・ワークアラウンドが必要なのか
- これらを書いておけば、正しい取捨選択に役立つ
副作用をなくす
Simple ways
間違いに気づきやすくする技術
型制約
strict.pm- Perl5標準
- 未定義変数の参照をコンパイルエラーしてくれる
- soft referenceなどの危険な機能を制限してくれる
warnings.pm- perlは非常にコンテクストに敏感
'3:' + 2; # => 5 (!?)+の手前をatoiしてしまう- こんなケースの時に警告を出してくれる
コードの静的解析
perlcliticperllint実行せずに間違いに気づく
swiftにおける
int?guard.pm- GoとSwiftの
deferに相当
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
cpmcpanm --dev App::cpm
Norikraで作るPHP検知システム
- Masanori Nagano
- PHPの例外を検知し通知するシステム
RSSをざっくりクロールしてゆるふわにパース
- 角田さん
- @ace_project
- Feedwind
- 事例(クロール)
- 配信元に連絡して解除してもらう
- 連絡がつかない場合はプロキシを使って乗り越えている
- 事例(パース)
Mojo::DOM- パースできないやつにぶつかりサービスがダウン
<br<<- (!?)- 壊れてるDOMをパースできなかった
- 今後のことも考えてゆるふわにパースするようにしました
- できるだけ集めてできるだけパースしてあげよう、という姿勢が大事なんでないかと思います
Slack+Hubotでお前の一番好きな二次元嫁キャラと一緒に仕事をする
- @sairoutine
- さい
- 趣味プログラミングしてますか？
- 結構やってますね、ほいほいほいほい
- だいたい一人でやるので寂しいですよね？
- 事例: @marisa
- 自分と@marisaでチームを作りました
- Botとふたりきりのチームってとこ、ミソですよ
- 他の人としゃべることがないようにしておく
- cronモジュールは全部やるのは面倒なので、jsonにまとめて食べさせます
tw ......で投稿だけdeploy、issue list、trello add- 一人なんで自分でやったほうが早い気がするけど、botが自分のために動いてくれる、嫁っぽい！
YAPC?雨事情
- @likk
- Mobile Factory
- 会社を出たら雨
- エレベーターを降りてから気づく、傘はオフィス
- 戻るの面倒臭い！
- 定時に五反田で雨が降ってたら通知したい
- tenki.jp
- newして東京の場所を指定すると画像が出てくる
- 拡大して五反田の位置をマッピング
GD::Imageで画像差分検知、差分がアレば雨とみなす
- エレベーターを降りてから気づく、傘はオフィス
- すごい過去にも遡れる！
- 歴代YAPCの雨事情を起こしてみました、懇親会だけ雨みたいな日も
- 雨通知アプリametto/熱中症検知アプリachitto
PUGS ON STACK
- HIRATARA
- Freakout
- PUGS
- 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にのってる
- register_globalsの影響を受ける変数を逐次定義
- 使ってはいけない、間違っています
- php.netにない隠された仕様
$_FILES- 個別にマッピングされる
- 「その結果に驚くことでしょう。」
- ちゃんと書け
$_SESSIONSも対象です- リファレンス渡しで来てる!!!
同人活動の報告と今後の展望
第27回 PaaS勉強会
- OpenShift v3 リリース記念
- PaaSを勉強する会です
- herku, MS Azure, GCP...
- PaaSと組み合わせるHashicorp product, CoreOS, Mesos...
- あるべきPaaSの姿を求めてみんなで調べてみんなでつくってみんなで学ぼう、が主旨です
OpenShiftとScheduler
なぜ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 nodeoc create -f hello-pod.jsonoc get pod --watch- Pending状態で１時間待ってしまうことがあります
- 待ってはいけない
oc get event | lessError scheduling: failed to pod- 名前は一緒だけど、ポートが被ってる
- Pending状態で１時間待ってしまうことがあります
oc delete pod hello-openshift- バッティングしてるポートの１つ目を消すと後のがREADYになる
Scheduling Steps
- ノードのフィルタ
- predicates
- ≒フィルタ
- Portが競合するNodeをふるい落とす、要求したリソースの上限を超えるNodeをふるい落とす
- ふるい落とされなかったノードにPriorityをつける
- 0~10までのスコアを計算、各Priorityの計算で重み付けして、スコアと掛け算させることも可能
- 最もフィットしたノードの選択
- 同じスコアはランダムに選択
意外と単純な振る舞いに鳴ってますが、Priorityの計算だけ少し複雑
Predicates
- PodFitsPorts
- 既存のPodとportが競合しないノードに絞る
- NoDiskConflick
- GCEとEBSを使っている場合に、Diskがconflictしないのーどに絞る
- OSv3は↑２つではまだ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のみ
- トラフィックやストレージは考慮されていない
- ↑２つをWeightに加味するのはなかなか大変なので、先送りしてます
- upstreamで動きはあるので、入ってくるんじゃないかな、というのが個人の見解です
- OSv3(k8s)で管理しているリソースのみを計算
- Mesosは他のホストプロセスも考慮するけど、OpenShiftが動いているホストで直接バッチなんかを回すとpodが影響を受けることがある
- とはいえ、OpenShiftを動かすホストで直接なんかやるのはなにか設計が間違ってるのでは、と思っています
割と新し目のOpenShift Originで作る自宅PaaS作成記
- 原嘉彦
- @GORO_Neko
- 某ITベンダに勤めています
- 日本OSS推進フォーラム(JOPF)
- OpenShiftの中の人でも、プロでもありません
- 一回も組んだことのない人が構築してみる、動かしてみる、というレイヤーです
OpenShift Originの構造
- Docker + k8s + 何か、でできているPaaSです
- 4台構成の場合
- マシン１に
OpetShift-master- ログインなど
- マシン２に
OpenShift-node- インフラ的な役割
- docker-registryなど
- マシン３、４にユーザーの使う
- マシン１に
構築してみる
- 構築方法
今回の環境
ソースコードの準備
openshift/origin- リリース版のバイナリも
opetshift/origin/releasesに、現在は1.0.3
- 起動・ログイン
- Private Docker Registryのログイン
oadm registroyはsu権限で
気になったこと
- jsonの書き方がよくわからない
- 何はともあれ公式ドキュメントかー
- (中の人)ちゃんと使うと実はあんまり書かなくてよいです
- 古いドキュメントを引きずって書かないといけない雰囲気になってますが、シェルとかでも書けます
- VagrantでSELinux, firewalldが止まってる
- 開発が進むほどコマンドが変わる
- もう少しソフトランディングしてもらえないものだろうか
- (中の人)他のコマンドとかぶっていた事実がありました、1.0.0以降で変わってたら殴って下さい
OpenShift v3のCIとCD
去年の7月Flynnをベースに開発開始、おそらくDockerベースPaaSでは最速でエンタープライズベースに持っていった
- 皆さん上から「Docker使え」ってなんか降りてくるようで、今エンタープライズで日本語サポートが有るのはOSだけ、ということらしい
Takayoshi Kimura
- @nekop
OPENSHIFTの特徴
- k8sがスケーリングや障害復旧、B-G Deploymentなど基本的な機能をカバー
- ドキュメントが古いのを引きずっていて難しく見える
- OSのデプロイは慣れれば簡単
- Dockerを知らなくても動かせる
- プラットフォーム非依存
ococ loginoc new-projectoc 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におけるブランチのようなもので管理
- IMAGESTREAM
Docker PaaSとしての OpenShift. DEIS, Flynn比較
Kazuto Kusama
- @jacopen
Open PaaS
- 今回話すのはDEISとFlynn
- OpenShift勉強会でOpenShift以外の話をします
OpenShiftのいいところ
- OpenShiftのここがちょっとなー
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 creategit 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がビルドできないらしく、必ず死ぬので...
デモではダッシュボードをもう１個デプロイします
tsuru app-create dashbord2 pythongit push dashbord2 master
アプリはplatformと呼ばれるランタイムで動く
- 実態は
docker build - baseimageを作って、そこにアプリをデプロイしている
- 実行時のアプリは
circus
- 実態は
運用管理も考えている
- 物理ホスト管理
- dockerプール管理
- platform管理
service
- api連携が基本
- 概念としてはCloudFoundry Marketplace
- https://tsuru-crane.readthedocs.org
- contributeするなら今のうち
- 1.0.0が25%くらいです
どれもVagrantで試せます
- どっかのPaaSと違って2GBもあれば動きます
次回
- PaaS x IoT Node-RED勉強会
- 8/26
- 110/50人でめっちゃ好評なので、今後頻繁に開催します
- 第２９回は多分9月上旬〜中旬、多分品川あたり
July Tech Festa 2015
要約
- Docker監視はDatadog、New Relicの２強、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->...にどんどんドリルダウンさせていく
- Collectiong the right data
"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
- 「AWSは、勝手に値下げしてくれる」 vs 国内XXスタック
- 「SaaSは、勝手に昨日を追加してくれる」 vs 事業俊敏性優先、化石化しないように必死に運用して追加が追いつかない
- あなたの時間を使うときに、どっちが大事？
- おそらく運用しているシステムを理解する方が大事で、監視ツール
- Docker用のモニタリングシステムをDIYで作らなければならない時になったら
- 自分たちのビジネスにおける、差別化要因・キーポイントになるのかどうか、それより優先事項が無いか、というのを確認してほしい
- Docker含め、モニタリングシステムを自作する時代は終わった
Monitoring Options
- アメリカのDockerパートナーが挙げる監視SaaS
- sygnal fx
- sematext
- signify
- sysdig
- ETP PROGRAM Monitoring
- Dockerを動かすと、1コンテナに10のアプリ、10分に１回変更があると１台に60のムービングパーツが出てくる
- 600人の子供を1人の保護者が把握し続けられるだろうか
- Dockerをやる＝監視ははじめから非常に高いレベルで開始しなければ、
- naoya_ito「chef-solo使っていいのは中学生まで」
- 時間をかけて積んでいいのは中学生まで
- Why Docker Users Monitor
- 逆にこれらを満たせるのであれば、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数で２強 - Dockerだけのメトリクス
- cgroups
- docker api
- やるべきでない２つ
- in-container agent direct monitoring
- kernel hacking
- SaaSを見ていても、ドキュメンテーションが充実していないのがほとんど
- Docker imageの更新履歴を見ると、どこが頑張っているかは明らかです
- 答えは↑とほとんど変わらないです
- データの粒度をちゃんと考慮していないのがほとんど
- pricingがいい加減っぽい
- 使われてるところが一番安い
各SaaSの現状
- New Relicの例
- 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
-
- Datadogでのメトリクスは1年間ロールアップされません
- それ以上は有償オプション
- 「ここから来たら反応せざるを得ない」という状況を無理やり作る
"How to Monitor NGINX with Datadog"シリーズも始まりました
- 何を取るべきか
- nginx社の方に査読してもらっています
Q&A
- Ddはk8s連携は多分まだ、etcdは持ってたような
- 桶ソリューションとのインテグレーションはまだどこも実装できてないと思う
失敗例を成功に変える、AWSアンチパターンの数々(Webアプリ編)
- 荒木靖宏(@ar1)
- ADSJ
アンチパターンの前に、典型的なCDP
- Web Storageパターン
- 動画や過去画像はS3へ
- アクセス過多でつながりにくくなると
- Direct Hostingパターン
- 配信のメインサイトをS3へ(Route53)
- MTのスタティックパブリッシング→S3
- Cache Distributionパターン
- サブディレクトリ単位で別ドメインをオリジンにできる
- Web Storageパターン
-
- リファクタリングするための方法、が存在するパターン
EC2にまつわる7つのアンチパターン
- EC2一神教アンチパターン
- ノースナップショットアンチパターン
- 楽なバックアップです
- EBSのスナップショット機能を知らない
- 静止点を決めればずっと保持されます
- 2回目以降は差分バックアップ分のみ課金です
- スナップショット取得中はストップないしデタッチが必要です
- EBSはAZをまたげない
- 定期的に不必要なスナップショットを消すこと
- 差分課金なので莫大な請求はないけど、整理ができなくなってくる
- 「消す」という作業で目的を思い出せます
- AMI無しアンチパターン
- 手順書通りに作業したい人は不思議なくらいたくさんいる
- AMI作成は難しくありません
- AMI至上主義アンチパターン
- AMI作成をバックアップだと思っている
- 再起動なしAMIはリスクを伴います
- メモリ内データのフラッシュをユーザーが行う必要が出てくる
- バックアップはEBSで十分
- インスタンス振動アンチパターン
- オートスケーリングの設定が敏感すぎる
- CloudWatchの条件ソースが不適切
- 起動条件の4倍程度に緩和させておく
- 80%スケールアウト→20%スケールイン
- 1時間切り上げ課金なので、55分で自殺する方法も
- 単機能AZアンチパターン
- サブネットごとに「DB用」「アプリ用」などとわけてしまい、それぞれを複数設置し忘れる
- 単一AZしかない機能が落ちて、結局システム全断
- とりあえずELBアンチパターン
キャパシティにまつわる2つのアンチパターン
- CloudFront使わないアンチパターン
- 配信先を日本だけにもできます
- S3はレスポンスは200~500ms
- オリジンのキャッシュ制御を適切に設定する
- ベンチマークアンチパターン
- システム実態と違うベンチマークソフトによる測定値を使ったサイジング
- 本番と測定時の規模の差
こころがけるべき汎用的な３つのアンチパターン
- ノールック明細アンチパターン
- 明細は適宜確認しましょう
- 毎日、毎時アップデートする機能があります
- 最近95%の信頼区間で月末利用料を予測する機能もつきました
- インフラ塩漬けアンチパターン
- AWSも成長します
- ３ヶ月に一度、もしくは１年に一度見直しましょう
- サービスは四半期に一度は見直す
- 机上の空論アンチパターン
- JUST DO IT
- 事前のキャパプラに時間をかけすぎる
- とにかく小さく試してみること
ウェブアプリ向けアンチパターンまとめ
- 知る
- 議論する
- やってみる
アンチパターンは有益
- 恨み節をブログに書く
- 面白おかしく同僚と話す
- 打開策を発表
皆さん、モダンブラウザですよ！
- 勉強をお忘れなく
若手インフラエンジニアが語る技術トレンドと数年後の未来
- @hfm
- GMOペパボ '13 4~
- 新卒エンジニア研修担当
- @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
- @hfm: Puppet, Itamae, (Ansible)
- 「Chefの学習コストが高いのでAnsibleに移行します」事例
- 複雑な環境を触ることが多いので、学習コストより柔軟性を取る人もいる(@deeeet)
- Itamae -> Chef、といった段階的な移行が個人的には良い(@rrreeeyyy)
- 2台なのにChef、は逆にナンセンス、スケールさせたい需要の強さで
- 本質的にはどれも複雑なことをやっているものだと思う(@y_uuk1)
- ChefはRubyで書ける、というのはそれなりにアドバンテージがある
- 今から選ぶならItamaeやAnsibleもアリだとは思う
- Puppet, Chef, Ansibleの３つはあんまり学習コストは変わらない気がする(@hfm)
- 設計のほうがヘビーで、それはツールのせいではないような気がする
- サーバ構成に起因する部分が少なからずあるので、話すときは分けておきたい
- プロビジョニングツール何使ってる？
- Chefのクックブックを管理している人が１人の時はとても綺麗なんだけど...
- @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コンテナが投入されている
- @y_uuk1: Dockerを使うメリットを意識せずに使うと大変になりそう、今は各種環境のパッケージ化にメリットを感じて始めている
- たまに
docker buildがコケたり、Jenkinsジョブ途中で切るとシグナル周辺でゴミが残留したりする- 都度ワークアラウンドをはさみながら運用している状態
- 本番ではDockerで展開せずにイメージだけ持ってきて
chrootで動かしたほうが素直なのでは、という気がする
- たまに
- @catatsuy: 今のところ大きな問題は起こってないのであまり進展は無いけど、次もDockerを使うかは再考の余地あり
- @deeet: imageを作るまでは良くて、CloudFoundryもDockerは使わずDocker imageだけ使えるようにする流れがある
- ランタイムの流れが整理されるともっと使いやすくなるのでは、という印象がある
技術習得について
- どうやってキャッチアップしている？
最新技術追い過ぎ問題についてどう思う？割愛
今後のキャリアについて
- 今後どのような仕事をしてみたい？
- @y_uuk1
- @catatsuy
- 多分ずっとインフラエンジニアではないと思う
- 最初は開発で入った
- インフラの知識を活かしてアプリ開発したい、これができている人材は結構少ないと思う
- パフォーマンスチューニングなんかもアプリだけの人は難しいとおもう
- 教育系の本出したけど、当面はアプリエンジニアの職を奪っていきたい
- @rrreeeyyy
- 新卒2年目だけど、入社5年目
- MSPだけど、「運用を消したい」が野望
- 今や運用が一番手がかかっている、まだまだ省力化出来るハズ
- 自動化プロダクトへのコントリビュートや、設計を考えていきたい
- @deeet
- 運用のしんどさをどれだけ軽減していくか、というのをよく考えていた
- 実際の運用をどうよくしていくか
- Hashicorp脳なんで、運用をよくしていくプロダクトがどんどん出てくるだろうと思う
@hfm
Q&A
- 近い年の同僚と、どうやって高めあいたいか、みたいなものはありますか
- 壇上のデキる若者たちと、そうではない人との関係性
- @hfm:
- ペパボはサービスごとにチームが分かれているが、インフラは横串を通している
- ぽよん会(情報共有会)をやっている
- 自分の学んだことをアウトプットしたり、SlackやSNSに垂れ流せる環境
- 基本的には自分からつかみに取って行っていく環境でないと厳しい、という前提がある
- @y_uuk1:
Googleが描くMapReduceを超えたビッグデータの世界
MapReduceを取り巻く世界
- GFS('02、'04論文公開)
- MapReduce('04)
- Dremel('08)
- またの名をBigQuery
- Flume('10)
- MilWheel('11)
- この３つの技術
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)
Fast Aggregation by Tree Structure
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をJavaやPythonのコレクションに落とし込める
- PCollections
- 無限のデータを扱える、シャーディングやストアはすべてDataflow側で判別
- ParDo
- Count
- Top
- PCollections
フルマネージド、アプリケーションロジックに集中できます
- http://cloud.google.com/dataflow
今明かされる！シンラ・テクノロジーのインフラへの挑戦と舞台裏
岩崎哲史
- Shinra Technologies, inc. Senior vice president
- '94 Square Enix入社
- 一度転職してCrysis
- '09より再びSquare Enix
クラウドゲーミング
- コントローラ入力を受けて、サーバからストリーミングビデオで返す
ゲーム市場の移り変わり
- '75 ゲーセン
- '80~ コンソールゲーム
- '00~ オンラインゲーム
- ユーザがハードウェアに対する投資が少なくなればなるほど、市場は拡大する、というコンセプト
- ポータビリティとジェネラリティが鍵
- ゲーセン: 1台1ゲーム、ポータビリティなし
- スマホ: いろんなゲーム、ポータビリティ＋センサ、カメラ、音楽プレイヤー、電話
クラウドゲームシステムが次のメジャーゲームプラットフォーム
- ビデオ出力さえあればどこでもできる、究極のポータビリティとジェネラリティ
- クラウドゲームは市場を拡大していく
- HW投資がより縮小されるので
経営のビジョンなので、開発チームでは真理として扱われます
経営「クラウドゲームに取り組みなさい」
- 上になればなるほど、オーダーは悲しいくらいシンプルになる
- 研究部長時代のオーダーは「開発を効率化して下さい」だった
- 指示をブレイクダウンするのも重要な訓練、そうしておけばこういうことがあっても困らずにすみます
- 上になればなるほど、オーダーは悲しいくらいシンプルになる
何をするか
- 徹底的に調べる
- 既存サービスの事例
- 要素技術
- どうやって
- ともかく、RPGのごとくブレイクダウンに必要な知識を集める
- しかし社内に蓄積されている知識を活用できるかどうかは最も重要
- スクウェア・エニックスは大きな会社、足取りは遅い
- 事前準備なしでやるとベンチャーの速度に追い抜かれる
- スクウェア・エニックスは大きな会社、足取りは遅い
- 徹底的に調べる
既存クラウドゲームのインフラストラクチャ
- 典型的には1VM=1ゲーム
プラットフォームならではのゲーム
↑２つを一旦経営にフィードバック
コスト課題をどう解決するか
リモートレンダリングアーキテクチャ
- イーサネットを汎用インターフェースに
- ゲームコンテンツの計算とレンダリングを別サーバで実行
- レンダリングプロセスをシリアライズしてまとめて実行
- キャッシュ効率向上、リソースのシェア
- レンダリングAPIはデファクトのDirectX
- DiretXのAPIをリモートで叩けるように改修、過去のゲームも流用できるように
- 従来のNWゲームはインターネットを通じてメモリを同期
- クラウドゲーム内では1プロセス内で同期
- 1:Nアーキテクチャ
- 4入力→1プロセス→1レンダプロセス→4出力
ここまで経営に報告→'12 モントリオールでR&D開始
インターコネクション: 必要なレンダリングコマンドのサイズは3Gbps/s
- プロセスが死ぬと全員道連れ、接続ユーザ倍の信頼度が必要
- リサーチ項目
- 改善の推移
- ブレイクダウン
- 必要な知識
- たまたま全部触ってました
技術者としてのスーパージェネラリスト
- 田坂広志氏の定義は縦、自分のものは横
- できれば１つの専門分野
- 周辺分野の基本をマスターする
- 残りはコミュニティやカンファレンスから積極的に参加することが大事
- JTF2015に参加している皆様は素晴らしい
