Hadoop Conference Japan 2014 参加メモ(個別セッション①) #hcj2014
Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014 の続きです。
続いて、個別セッションの前半。先は長い。。。
個別セッション
BigQuery and the world after MapReduce
Speaker: 佐藤一憲 (Google)
Google I/O で、GoogleはMapReduceを使っていないという話があった
We use Dremel ≒ Google BigQuery(MPP)
- 68B records in ~20 secs
- 120億行フルスキャンで10秒ぐらい
- コスト
- Storage 0.026/GB per manth
- Query: $5/TB
- Column Oriented Storage
HDFSの元となったGoogle File Systemも現在は使っていない
- Colossus
The next generation Google File System
- Tail Latency が低い -> レスポンスが遅いノードに引きずられない
- Colossus
The next generation Google File System
Google BigQuery
Scanning 1 TB in 1 sec takes 5000 disks
処理
- Mixer -> Shards -> Mixer
JOINの方式
- Small JOIN: Broadcast JOIN
- Big JOIN: JOIN EACH, GROUP EACH -> Shuffle
- 608M x 38M records -> 90s
BigQuery streaming
- 1M rows/s を格納可能
- Fluentd Plugin bigquery がこれに対応していて、データを流し込める
Google I/Oで発表された今後実装予定の機能
QA
Fluentdで今後チャンクにIDをつけるようにする。インターネット経由だと重複は結構ある。Googleへのデータ送信時に、そういう重複排除の仕組みは提供されるか。
- 現状はない。インポートしてもらって、Group BYで重複を排除してもらう等が必要。
- Exactly Onceに関しては、Google I/Oでも質問があって、Dataflowの中ではできている。
BIツールから直でつないで使うのか、スプレッドシートに書きだすのか、どちらの使い方を想定しているか
- 両方ともユースケースがある
大きなデータでクエリが走らないのは?
- おそらくソフト的なクォータ設定で止まっている。
- サポートを購入してもらうと制限を外せる
- Reserved Capacityというメニューがある
クエリの結果の整合性は?
- トランザクションはサポートしていないし、スナップショットとしての整合性も保証していない
Hivemall: Apache Hiveを用いたスケーラブルな機械学習基盤
- Speaker: 油井 誠(産業技術総合研究所)
Hivemallは、Hive上で動くOSSの機械学習ライブラリ
- HiveのUDF、UDTFで実装されており、Hiveに慣れていれば、追加の学習コストが少ない
- 学術研究の結果をいち早く取り込んでいる
既存ツールはプログラムが必要
- すべてのステップがHiveQLで実行可能
- add jar
- source のみで実行可能
- すべてのステップがHiveQLで実行可能
特徴数の削減をサポートしている
- 学習時やテスト時に予測モデルをメモリに収める必要がない。
EMRに自動構築するBootstrapを提供している
最新のオンライン学習アルゴリズムをサポート
- CW、SCW、AROWをサポート
- 学習の収束が高速
- 10イテレーション→2, 3イテレーション
オンライン学習で精度がよい
- confidence weighted
- 重みと確信度を更新する
- 確信度が十分な重みについては、小さな更新。学習初期は大きな更新。
- confidence weighted
UDAF(集約関数)での機会学習
-
- Sparkは担当領域を各ノードでキャッシュするので今後のバージョンで高速化する可能性がある
- SparkのMLlib はサンプリングを利用したMini-batch勾配降下法
Hivemall
- amplify UDTFでデータを増幅してShuffle
- rand_amplify UDTFでデータを増幅してMap Only Shuffle
Apache incubator化の打診がある。Hortonworksから打診を受けている。
QA
Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014
久々にブログを更新しようと思ったら、この数カ月で記事らしい記事は「一人遊園地」しか書いていないことに軽い絶望を覚えたせちろーです。
今日は、Hadoop Conference Japan 2014に参加してきたので、その時に取ったメモを整理してアップ。長くなるので、まずはキーノートから。間違いがあってもご容赦ください。
当日の資料は、以下のページにアップされると思うので、詳しい情報は以下を見てください。
http://www.eventbrite.com/e/hadoop-conference-japan-2014-tickets-12016613013
それぞれ別の立場から話しているのに、Hadoopの用途が大量データの保存と単純な集計から、汎用的な分散処理基盤かつMPPまで包含するような方向で進化しているという観点が共通しているところが面白いですね。
キーノート
開会挨拶
- 参加登録者
- 1296名 -> 最終的には1299名
- 約65%が初めて参加する人
データ
Hadoopのこれまで
だんだんYARNが中心に座ってきている
- MRの経験をもとに複数の分散処理エンジンを使い分ける時代に
『The Future of Data』
未来は予測できないが、いくつかの事実が真実を予測
『The Future of Spark』
- Speaker: Patrick Wendell (Apache Spark主要開発者, Databricks)
今日のスライドは、自分で日本語に翻訳した
Spark開発者の一週間
- 500 Patch
- 200 update issue
- 140 Mail thread
- ...
Spark開発目標
- Data scientist, engineerの能力拡張
- CleanなAPI
- 多様な環境に適用
- 強力な標準ライブラリ
API互換性を維持
Spark Stack
- Spark SQL
- MLlib
- Graph X
- Spark Streaming
Sparkの未来は「ライブラリ」
- パッケージ化してどこでも使えるように
Spark SQL
DatabricksではクラウドでSparkを提供している
『Hadoopエコシステムの変遷と、見えてきた使いどころ』
- Speaker: 太田 一樹 (Treasure Data CTO)
- Hadoopの本質的な価値とは
- Collect any types of Data
- Store any types of Data Economically
- Faster use of Data
- Better use of Data
ここまで使うことでHadoopの価値が出る
Collect any types of Data
- Fluentd
- Apache Flume
- Kafka
- Sqoop
Store any types of Data Economically
- どんなタイプのデータも格納可能
- ファイルフォーマットに注目が集まっている
- どんなタイプのデータも格納可能
Faster use of Data
Better use of Data
- Impala, Presto, Drill
- Mahout, Hivemall
データベースの進化
スキーマ管理がもたらす問題
- 一部のレポートしか作れない
- データの整合性はとれるが、出てくるころには使えない
現在のトレンド
今後、Hadoopは構造化データとの境界線に突入
- HadoopだけでMPPができるように
- トレンドを読みながら技術を利用すべき
キーノートのメモはここまで。
溜まってきた大量の名刺やシャッツキステのポイントカードをしまうのにちょうどいい道具を調べた
最近、名刺やらシャッツキステのポイントカードが貯まってきて、カード状のものを保存するのに使えそうな道具を調べたので、その時の内容の備忘録を書いてみました。*1
自分で探せていない範囲がまだありそうなので、この用途でもっといいものがあれば、教えていただけるとありがたいです。
調べるにあたっての前提
以前は、名刺はきちんと名刺ファイルにファイリングしていました。しかし最近は、ものぐさでファイリングしなくなってしまっていて、その管理方法も限界に…。また、電子化しておいて、実物は廃棄してしまうという方法もあると思うのですが、収集癖があるから現物を捨てるのは忍びないので、それも今回は除外。
上記の前提なので、今回は入れるのに手間がかからない箱状のものをターゲットとしました。
どうやって見つけるか
箱状のものを使うと決めたものの、最初にカード状のものをしまう箱をどういう単語で検索すべきかという問題に引っかかりました。いろいろ試行錯誤して検索してみた結果は以下の通り。
- カードホルダー → ハズレ
- 主に社員証をぶら下げるものや財布上のカード入れが引っかかる。
- カードケース → ハズレ
- 主に財布上のカード入れが引っかかる
- カードボックス → 当たり!
- 主に名刺を1000枚単位で収納できる箱やカードゲーム用カードを入れる箱が引っかかる
- 「ネームカードボックス」とすると、名刺をしまう箱に絞り込める。
- 名刺箱、名刺ケース → 当たり!
- 名刺を買った時に入っているような箱が引っかかる。
- ネームカードケース → 微妙
- 主に社員証をぶら下げるものが引っかかる。ただし、あとで取り上げる今回買った製品がたまたま「ネームカードケース」という製品名だったため、それだけ例外的に引っかかった。
「名刺箱」というのは、見つけてしまえば当たり前の検索ワードなのですが、当初は「カードケース」で検索していたので、なかなか見つけられずに苦労しました。。。
500枚以上のカードを入れるのに使えるもの
今回探したものの中で、500枚以上のカードがある場合に使えると思ったのは「カードボックス」系のものです。このジャンルのものは、今回初めて知りました。探してみるとあるもんなんですねー
自分で買ったのは以下の「ネームカードケース」。選んだ決め手は、下の箱の高さが名刺の縦幅よりも低く、名刺が取り出しやすい点。この製品はフタがパカっと完全に外れるタイプなので、フタに蝶番がついている方がお好みであれば、そちらもよいかも。
また、今回はファイルはなしということで除外しましたが、カードボックスの類似製品として、このジャンルだと下の商品のような円形に名刺をパタパタ入れていくものも見つけました。
「ローロデックス」という製品なんですね。どこかで見た気がしますが、名前を知るのは初めて。名前を知らないと全然見つけられない。。。
数百枚程度のカードを入れるのに使えるもの
数百枚程度のカードを入れる場合は、今見つけられているものの中では「名刺箱」が良さそうという結論です。名刺を買った時の箱が残っていれば、それを使うのが一番リーズナブルですが、単体で買うこともできました。
ただ、安い名刺箱はネットでは5個単位、10個単位ものが多くて、1個だけ買う方法がなさそうなのがネック。余った分は、小物の整理にも使えるので、まとめて買っても使うところはあるように思いますが。
透明なものがいいか、中は見えない方がいいかは好みの問題ですが、以下のようなものがありました。*2
3240円以上で送料無料!(沖縄県をのぞく)幅57x奥行93x高20mm名刺が100枚入るサイズです【HEIKO/... |
高級感が欲しい場合
今回自分では買っていませんが、「名刺箱」で調べてみると、凝ったものも見つかりました。千代紙のものは、値段も手頃なので個人名刺入れとかによいかも。ほかにも、漆器で1万円超えみたいなものも見つかりましたが、さすがに使う機会なさそう…。
【ホームステイのお土産】【海外出張の手土産】【和柄】【外国人に喜ばれる】【日本のおみやげ... |
木製漆塗りの縁起物の名刺箱(名刺ケース) ラッキーアイテム ビジネスギフト、父の日ギフト、就... |
以上、どこにニーズがあるかわかりませんが、調査メモでした。
今日はこの辺で。
一人遊園地に行ってみた
今日は、花やしきに行ってきました。行った理由は、花やしきのローラーコースターに乗ってみたかったから。
全然下調べせずにいったので、花やしきのローラーコースターがまだやっているか不安でしたが、行ってみたところ、まだまだ現役で稼働していました!
なんと去年還暦! そして、還暦の人は無料で乗り放題!!
楽しい!!! ✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌.
ただ、周りはカップルか子供連ればっかりで、一人で行くとその人の心が試されます。人の迷惑にならない限り、どんなところでも行きたかったら行くべきだとは思いますが、周りがキャッキャウフフしている中に一人でいると精神が徐々に蝕まれていくので、基本的には一人で遊園地に行くのはおすすめできませんね。
ちなみに、一時期Twitterで回っていたぼっち検定では、一人遊園地は上から2つ目のレベルになっています。ただ、神レベルのラブホテルは、旅行で使えば割と簡単に達成できるし、千葉のネズミの国はパスポート持ってソロで行ってる人が結構いるので、上位の方が割と簡単に達成できるような気もします。
【ぼっち検定】 初級 一人で牛丼 5級 一人でラーメン 3級 一人でファミレス 1級 一人で居酒屋 初段 一人で温泉 ニ段 一人で回転寿司 三段 一人で海水浴 五段 一人で焼肉 名人 一人で公園の手漕ぎボート 独聖 一人で遊園地 神 一人でラブホテル
今日はこんなところで。
#qpstudy を開催して、第2セッション「アーキテクチャ設計の勘所」で発表してきた
先週の土曜日、4月19日に qpstudy 2014.04 〜俺の屍を超えて行け、でも踏まないで〜 を開催して、第2セッション「アーキテクチャ設計の勘所」で発表は、自分から発表させてもらいました。
今回は、ドワンゴさんの会議室を借りて、ドワンゴのエンジニアの方にニコ生の配信までやっていただきましたドワンゴさんマジドワンゴ。
自分の発表資料はこちら。
今回の勉強会のテーマ
今回の勉強会のタイトルは「〜俺の屍を超えて行け、でも踏まないで〜」ということで、新人インフラエンジニアに伝えておきたい基本的な内容をテーマに、ベテランにも何らかの気付きがある中身とすることが、今回の勉強会の目標でした。
結果、初参加の人の割合も多く初参加と2回目以降の参加の人がおよそ半々。会場参加者が、スタッフ抜きでほぼ100人。ニコ生は、当日が300人強で、タイムシフトも含めた視聴数は826人。ニコ生の視聴者がここまで増えたのは、ドワンゴ研究開発チャンネルの力が大きかったと思いますが、内容も好評で、大成功だったと思っています。ありがとうございました!
また、オープンソースチャンネルとアメーバのガールフレンド(仮)のプロデューサーさんに協力いただき、会場に来た人限定で、公式公認でクロエ・ルメール(CV: 丹下桜)さんに、勉強会の開会挨拶をしていただきました。
いきなりの大人の力の無駄遣いぶりに参加者がポカーンとしていた気もしますが、スタッフのテンションは上がりました。この場を借りて関係各位にお礼申し上げますm(__)m
自分の発表
発表にあたっての自分の課題は、自分がインフラ全体設計を行う際のプロセスを整理して言語化することでした。
自分がやってきたことを振り返ると、インフラ全体設計は、過去の経験や類似システム事例から決めてしまうことが多かったように思います。しかし、それでは新人にも、チームメンバーにも自分がやっていることをうまく伝えることができません。そこで、今回の勉強会を機に、まとめたのが上に載せた資料です。
話のポイントを簡単にまとめると以下のような感じです。
- インフラ全体設計のインプットは、「機能要件」→「アプリ機能」と「非機能要件」の2つに整理可能
- Web三層モデル」を理解し、利用することが設計の基本
- どんな設計に場合も、どうしてそのアーキテクチャを選んだのか説明できることが重要
余談ですが、途中、どうやっても変更できない「非機能要件」として、総務省の事故報告制度みたいなものがあることも紹介しました。
今回のスライドの「途中にCMを挟む」スタイルは、スライドの途中に休憩用のスライドを入れておくというテクニックを応用したものです。このような本論と関係ないスライドを入れておくことで、以下のようなことを狙っていました。
- トピックの切替の時に、それまでの話と関係ないスライドを挟むことで、聞いている人を集中を一旦解いて、頭を切り替えてもらう
- 自分も、そのスライドのタイミングで一息ついて、聞いている人全体を確認する
- 休憩スライドが出た時の時間を確認することで時間配分を確認する
長時間のプレゼンで集中しっぱなしだと、聞き手も話し手も疲れてきますし、こういうスライドを入れていた方が自分としても気持ちが楽でした。
個人的には、参加者の世代を考えていなかったために、最近のポエムブログの流行とオープニングをクロエ・ルメールをかけたオープニングポエムと『男坂』のネタが通用しなかったのが最大の誤算です。さすがにときメモのラジオを聞いてる世代はいなかったか…
合わせて読みたい
第5セッションの@nekoruriさんが、僕の発表内容を引き継いで、ミドルウェア設計の勘所を話してくれたので、そちらも続けてみてもらえると、より内容がわかりやすいと思います。
順番が前後しますが、そのほかのセッション資料もアップされているので、こちらも是非。
第1セッション 構築作業の全体フェーズ
第3セッション『ハードウェア設計の勘所』
第4セッション『ネットワーク/OS設計の勘所』
第6セッション 今後のインフラエンジニアとは
- こちらは、資料非公開です。
また、前回の qpstudy 2013.07はDBに特化した内容でしたが、こちらもおすすめです。
最初のqp劇団による寸劇は置いておくとして、@nippondanji さん、@choplinさんのお話は、ほかではなかなか聞けないいい内容なので、さらにDB部分を掘り下げたい方は、合わせて読むと理解がさらに深まると思います。おすすめです。
漢(オトコ)のコンピュータ道: qpstudyで発表したスライドをアップロードしました。 (Ust: http://www.ustream.tv/recorded/36485447)
qpstudy 2013.07 NoSQL (Ust: http://www.ustream.tv/recorded/36487771)
勉強会の企画について
勉強会自体の報告は、ここまでですが、スタッフらしく企画のことを少し。
今回の勉強会の企画を決めるに当たっては、スタッフで飲み会ミーティングをして、ネタ出しをして、あとはSkypeチャットで、随時詰めていきました。4月に入っても全然具体化していなかったので、だいぶハラハラしましたが、、、
ネタ候補は以下のような感じ。
- 引継はどうあるべきか、どうするべきか 年度を越えて引継ぎをしてちゃんとできた人できなかった人がいらっしゃると思います。割とある出来事なのに今まで語られることがなかったこの分野にメスを入れますとかなんとか
- コマンドのアウトプットを理解する
- 「インフラデザインパターン」はなぜパターンなのか
- 「今すぐ使える基礎」
- 「年寄りから知っておいて欲しい情報基盤のいくつか」
- 「これを知らないと恥ずかしい」を新人向けに NICのボンディングとか
- 『ソフトウェアの教科書』 qp版
- 春ということで、新人向けに「プログラムはなぜ動くのか 2014年版」
- cgi getとpost
このエッセンスを煮詰めていって、今回の内容にしましたが、ネタとして上がっても、途中で落としたものもあるので、次回以降に取り上げられればと思っています。
関連エントリ
最後に、今のところ見つけている参加者ブログを。qpでは、「ブログを書くまでが勉強会」というのをキャッチフレーズの一つにしています。
ブログを書くと、自分が理解できたことも整理できますし、勉強会スタッフのモチベーションも上がるので、できるだけブログを書いてくれたら、嬉しいなと。とはいえ、自分でも書けないことが多いのですが^^;
参加者
- 【勉強会】qpstudy 2014.04 - Qiita
- qpstudyに行ってきた - としたにあんの左脳
- 4/19 「qpstudy 2014.04 俺の屍を超えて行け、でも踏まないで」勉強会参加:情熱の行方:So-netブログ
- qpstudy201404に行ってきた! - ITとか野鳥とかその他諸々のメモ
- qpstudy 2014.04 へ行ってきました #qpstudy | こえむの編集後記
- qpstudy 2014.04 〜俺の屍を超えて行け、でも踏まないで〜 #qpstudy - Togetterまとめ
スタッフ
今日は、こんなところで。
第6回 Zabbix-JP勉強会は、2年の空白を埋める非常に濃い勉強会だった #zabbix_jp
今日は、第6回Zabbix-JP勉強会に参加してきました。
今回の勉強会は、約2年ぶりの開催! @ike_dai さんが『Zabbix統合監視徹底活用 ~複雑化・大規模化するインフラの一元管理』を今年の2月に出したことが開催のきっかけになっています。この本は、Zabbixを大規模環境に適用するに当たっての実践的な知識が詰め込まれた労作です。まだ買っていない人はすぐ買いましょう。
本編の内容
そして、今回の勉強会は、この本の濃さに勝るとも劣らない非常に濃い内容でした。本編を以下にまとめてみましたが、タイトルだけでも内容が多岐に笑っています。(資料は、現時点で僕が把握できた範囲の公開資料です。【追記】4/14に@zembutsuさんの資料を追加、4/17に[@BSmile]さん、@qryuuさんの資料を追加)
本編
発表者(敬称略) | タイトル | 資料 |
---|---|---|
Zabbix Japan 寺島 広大 (@kodai74) | Zabbix最新情報について | |
TIS株式会社 池田 大輔 (@ike_dai) | Zabbix本に書いたこと書けなかったこと | http://www.slideshare.net/ikedai/6zabbix-jp |
株式会社サマリー @kenjiskywalker | Zabbixの運用において、自分で自分の労働力と時間を節約する為の工夫事例紹介 | http://blog.kenjiskywalker.org/blog/2014/04/12/zabbix_jp_6/ |
クリエーションライン株式会社 @zembutsu (a.k.a 前佛 雅人) | ZabbixのAPIを使って、運用を楽しくする話(仮) | http://www.slideshare.net/zembutsu/serf-orchestration-with-zabbix-operation |
LT
発表者(敬称略) | タイトル | 資料 |
---|---|---|
@2box2bo | ZabbixProxy on RaspberryPi(仮) | http://www.slideshare.net/yoshitakatsubouchi/raspberry-p-ionzabbixproxy |
鈴木 崇文 (@BlueSkyDetector) | mruby で zabbix agent の loadable module を作ってみた | http://www.slideshare.net/BlueSkyDetector/mruby-zabbix-loadablemodule2nd |
@BSmile | ZABBIXに手の届かない所はない(仮) | http://www.slideshare.net/hayatowatanabe121/zabbix-expect?ref=http%3A%2F%2Fwww.slideshare.net%2Fhayatowatanabe121 |
@qryuu | Zabbixの分散構築~ConoHa VPSでのZabbix Server構築~*自宅ラックポータルの裏側* | http://www.slideshare.net/qryuu/zabbixcono-ha-vpszabbix-server-share |
山根 健志 (@fripper1214) | LLD(ローレベルディスカバリ)を弄り倒せ、zabbix_senderを併用してらくらく可視化 | http://www.slideshare.net/takeshiyamane9/lld-zabbix |
@goto_ipv6さんのまとめ
第6回 ZABBIX-JP勉強会(tsudaり分)(2014年4月12日) #zabbix_jp - Yukarin'Note
Togetter
第6回ZABBIX-JP勉強会(2014/04/12 15:00~)まとめ - Togetterまとめ
感想
詳しい内容は、各資料を見てもらうとして、僕からは、断片的ですが感想を。
- Zabbix全体の話では、ユーザからの要望に基いてZabbixにかゆいところに手が届くような機能が次々に追加され、さらに完成度が上がっている印象
- VMware監視もデフォルト機能になり、苦手だったWindows監視も2.2では大幅に改善され、Windows環境の監視にも必要十分な機能を備えるようになって、いよいよ統合監視のデファクトスタンダードに。
- mrubyのローダブルモジュールで、ユーザによるAgentの機能拡張の枠組みができた。これから面白い機能が出てきそう。
- @fripper1214さんのzabbix_senderを使ってLLDを独自に拡張するというのは、まさに「その発想はなかった!」という盲点を突いたユーザによるZabbix機能の拡張。この発表に刺激を受けた人が多かったように思う。
全体としては、この2年間のZabbixの成長と運用での実績の積み重ねを一度に知ることができる、非常に濃い勉強会だったと思います。発表者のみなさん、スタッフのみなさんありがとうございました! 今回は自分は何もしていないので、次回はお手伝いや発表ができるようにしたいと思います。
余談
あとは、余談になりますが、懇親会で話したことを少し。
インフラエンジニアを意外と支えている「ざびたん」
懇親会に参加して、運用現場でざびたんを使ってくれている人が結構いるという話を聞きました。
もう、始めてのざびたんの発表から3年も経ったんですねー なかなかアップデートができていませんが、現場で使ってくれているというのが嬉しかったです。
聞いた話では、ブラウザを開かなくても見られるデスクトップ通知で手軽にできるもののニーズは結構あるとのこと。
可愛いキャラだと、現場で微妙な扱いを受けるので、UIをもっとパトランプみたいな無機質なものも欲しいとの話があったので、それはどうにかできないか考えてみたいと思います。
一方で、運用エンジニアが以下に頑張っているかを評価する好感度を実装して欲しいという話もあって、それをどうするのかが悩ましいところです(笑)*1
テンプレートやスクリプトの共有の仕組みがあったらよいな
そのほか懇親会では、Zabbixの外部チェックスクリプトやテンプレートなどの作り込み部分を共有する仕組みがあったら、素敵だなという話をしました。
スクリプトの作りや配置方法、APIを使ったテンプレートのインポート方法の標準化ができれば、簡単に各人が作り込んだものを共有できるようになると思うので、これもどういう方式ができるか考えてみたいと思っています。
サインもらいました!
勉強会に参加した人の特権として、本に@ike_daiさんのサインを貰ってきました。僕で通算5人目とのことなので、かなりのレアサインです。ありがとうございます!!
ということで、本編、懇親会ともに非常に刺激を受ける良い勉強会でした。運用や勉強は基本的に孤独であることが多いので、やはり勉強会でのモチベーションアップは重要ですね。
みなさん、またよろしくお願いします。
今日はこの辺で。
*1:実際、運用によってどれだけの価値が出たのかを経営層に可視化するというのは、重要かつ難しい課題なので、そういう指標も考えないと行けないとは思います。
Python版 AWS CLIでCloudwatchの情報を取得する
AWSを使っていると、Cloudwatchの情報を外部に取り出したくなるのが人情だと思います。
しかし、Cloudwatchの情報取得に関しては、Javaで書かれた「Amazon CloudWatch Command Line Tool」の情報やAPIを叩くツールを自作するような情報が多く、比較的新しいPython版 AWS CLIでの取得方法の情報はあまり見かけません。
AWS CLIは、旧来のツールで必要なJavaのインストールの必要がなく、また、1つのツールを導入するだけで、Cloudwatchを含む、すべてのAWSのサービスが操作可能というメリットがあり、比較的手軽に使うことができます。そのため、できればこちらで済ませたいところ。
ただ、AWS CLIでのCloudwatchは、いくつか癖があり、実際に使えるようになるまでハマったので、使い方をまとめておきたいと思います。
AWS CLIの導入と初期設定
今回の例を実行するために必要な初期設定方法は、以下の通りです。こちらは、ネット上に多くの情報が多くあるので、説明はざっくりで。
- Python pipの導入
- $ sudo pip install awscli
- $ complete -C aws_completer aws
- 必須ではないですが、これをやっておくとawsコマンド利用時にサブコマンドをタブ補完できるようになるので便利。
- 詳細はAWS CLIのgithubリポジトリ参照。
- $ aws configure
- jqコマンドの導入
- Billing情報監視の有効化
- Billing情報をCloudwatchから取得する場合は、その機能の有効化の設定を行う。設定方法は以下参照。
Billing情報の取得例
説明するよりは、例があった方がわかりやすいと思うので、例を2つ。(Gistへのリンクなので表示されていない場合は再読み込みをお願いします)スクリプトは、Mac OS 10.8 とCentOS 6にて動作確認しています。*1
[
{
"Unit": "Percent",
"Average": 0.33399999999999996,
"Timestamp": "2014-01-23T14:51:00Z"
},
(中略)
{
"Unit": "Percent",
"Average": 0.32799999999999996,
"Timestamp": "2014-01-23T14:56:00Z"
},
{
"Unit": "Percent",
"Average": 0.33399999999999996,
"Timestamp": "2014-01-23T15:01:00Z"
}
]
オプションの中身
スクリプトで指定しているコマンドとオプションの意味は以下の通りです。
- aws cloudwatch get-metric-statistics
- --region
- 取得対象リージョンの指定。Billing情報を取得する際には、必ず「us-east-1」を指定する必要がある。そのほかの場合は、自分が使っているリージョンを指定。"configure"時にデフォルト指定していれば、省略可能。
- --namespace
- --metric-name
- 取得するメトリックを指定。Billingのメトリックは「EstimatedCharges」のみ。EC2は、「CPUUtilization」や「DiskReadOps」など複数のメトリックがある。
- 各サービスで取得可能なメトリックは以下から確認できる。
- --start-time, --end-time
- メトリックの取得範囲をISO Dateの形式で指定する。日付だけ、日付+時間の両方の指定が可能。ただし、指定された期間÷データ間隔で決まるデータ件数(Datapoint数)が1440以下である必要あり。
- --period
- メトリックのデータ間隔を秒間隔で指定する。指定する値は、60の倍数である必要がある。Cloudwatchでは、デフォルトでは5分間間隔でデータが取得されているため、ここでは、300を指定。
- --statistics
- 平均値や最大値など、メトリックをどの断面で取り出すかの指定。
- 指定可能な値は、「"SampleCount"|"Average"|"Sum"|"Minimum"|"Maximum" 」
- --dimensions
- メトリックにサブカテゴリがある場合、指定するパラメータ。Billingでは上記の指定が必須。
- 各サービスで取得可能なDimensionはメトリックと合わせて確認できる。
- jq '.Datapoints | sort_by(.Timestamp)'
これらのオプションの組み合わせだけで、おおよそのAWSの利用状況は取得できると思います。
AWS CLIの公式のコマンドリファレンス*3には、ほかのサービスのメトリック取得方法やCloudwatch以外のサブコマンドの使い方も載っています。ここで例示したもの以外の使い方を知りたい方は、そちらを見てみてください。
夜も更けてきたので、今日はここまでで。