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