CSVで吐かれるリソース情報をelasticsearch, kibanaでグラフ化する
CSVで吐かれるリソース情報を週次でグラフ化する必要があったんだけど、毎週Excel開いてグラフ作るのはだるいので、ログ可視化周りでデファクトスタンダードになっているっぽいelasticsearch, kibanaでグラフ化することにした。
手順は次の通り。
- elasticsearch, kibana環境を準備する
- リソース情報CSVをBulk API対応のJSONに変換する
- リソース情報JSONをelasticsearchにバルクインポートする
- kibanaでインポート結果を確認する
- kibanaでグラフを作成する
1. elasticsearch, kibana環境を準備する
環境構築は切り出してこっちに書いた。
2. リソース情報CSVをBulk API対応のJSONに変換する
今回、リソース情報CSVとして適当に作成したダミーファイルは以下の通り 日付はelasticsearchのDate型にあわせないといけない。 最初作ったダミーファイルの日付は「DD-MM-YYYY」の形式だったんだけど、これだとelasticsearchが日付と認識してくれなかった。
# memory.csv
Date,memory
2015-01-01,10
2015-01-02,11
2015-01-03,12
2015-01-04,13
2015-01-05,14
2015-01-06,15
2015-01-07,16
2015-01-08,17
2015-01-09,18
2015-01-10,19
2015-01-11,20
2015-01-12,21
2015-01-13,22
2015-01-14,23
2015-01-15,24
2015-01-16,25
2015-01-17,26
2015-01-18,27
2015-01-19,28
2015-01-20,29
2015-01-21,30
2015-01-22,31
2015-01-23,32
2015-01-24,33
2015-01-25,34
2015-01-26,35
2015-01-27,36
2015-01-28,37
2015-01-29,38
2015-01-30,39
2015-01-31,40
2015-02-01,41
2015-02-02,42
2015-02-03,43
2015-02-04,44
2015-02-05,45
2015-02-06,46
2015-02-07,46
2015-02-08,46
2015-02-09,46
2015-02-10,46
2015-02-11,46
2015-02-12,46
2015-02-13,46
2015-02-14,46
2015-02-15,46
2015-02-16,46
2015-02-17,46
2015-02-18,46
2015-02-19,46
2015-02-20,46
2015-02-21,46
2015-02-22,46
2015-02-23,46
2015-02-24,46
2015-02-25,46
2015-02-26,46
2015-02-27,46
2015-02-28,46
2015-03-01,46
2015-03-02,46
2015-03-03,46
2015-03-04,46
2015-03-05,46
2015-03-06,46
2015-03-07,46
2015-03-08,46
2015-03-09,46
2015-03-10,46
2015-03-11,46
2015-03-12,46
2015-03-13,46
2015-03-14,46
2015-03-15,46
2015-03-16,46
2015-03-17,46
2015-03-18,46
2015-03-19,46
2015-03-20,46
2015-03-21,46
2015-03-22,46
2015-03-23,46
2015-03-24,46
2015-03-25,46
2015-03-26,46
2015-03-27,46
2015-03-28,46
2015-03-29,46
2015-03-30,46
2015-03-31,46
2015-04-01,46
これをBulk API対応のJSONに変換する。 ポイントは、普通に変換するだけだと数値が文字列に変換されてしまう(""がついちゃう)ので、数値だったら数値として変換する必要があるということ。 Qiitaに掲載のスクリプトを参考に、以下の通りスクリプトを作成した。
参考
以下のコマンドを実行してmemory.csvをmemory.jsonに変換する。
cat memory.csv | ./csv2esjson.rb > memory.json
こんな感じになるはず。memoryの値に""がないので、数値として変換されているのがわかる。
"index":{"_index":"test","_type":"type1","_id":"bc171ba7-cffa-4b47-a763-1071c758e59b"}}
{"Date":"2015-01-01","memory":10}
{"index":{"_index":"test","_type":"type1","_id":"ddb85e8e-4933-4579-8aff-05073e14f201"}}
{"Date":"2015-01-02","memory":11}
{"index":{"_index":"test","_type":"type1","_id":"c9053988-cffe-47af-9bd0-82ee664dd047"}}
{"Date":"2015-01-03","memory":12}
3. リソース情報JSONをelasticsearchにバルクインポートする
curl -s -XPOST localhost:9200/_bulk --data-binary @memory.json
4. kibanaでインポート結果を確認する
http://localhost:5601にアクセスすると「Configure an index pattern」という画面になる。
「Index contains time-based events」にチェックした上で、「Index name or pattern」に「test」と入力する。
testはjsonの_indexで指定した値。うまくいっていれば、ちょっと待つと「Create」というボタンが表示される。
「Time-field name」には「Date」と表示されているはず。
ここに何も表示されていなかったら、それは日付型の指定がうまくいっていないということだと思う。
「Create」を押す。Fieldsで、「Date」のtypeが「date」, 「memory」のtypeが「number」になっていることを確認する。
5. kibanaでグラフを作成する
「Discover」タブを押す。「No results found」と表示されるが、それは表示範囲が直近15分だから。
右上の「Last 15 minutes」を変更するとグラフが表示されるはず。
その後は「Visualize」タブを押して、任意のグラフを作成する。
スケールの変更もGUIで簡単にできるし、ここは問題ないと思う。
elasticsearch, kibana環境をDockerでさくっと準備する
環境情報
- Docker for Mac Version1.12.0-beta21
Docker Image取得
公式のイメージが提供されているので、それを使う。
docker pull elasticsearch
docker pull kibana
コンテナ起動
いくつかブログ見た感じ、これでいいらしい。
docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 elasticsearch
docker run -d --name kibana --link elasticsearch:es -e ELASTICSEARCH_URL=http://es:9200 -p 5601:5601 kibana
確認
下記ページにアクセスして、「Status: Green」になっていればよい。
http://localhost:5601/status
プロジェクトが縦割りか見分ける方法
自分なりに納得感のある「プロジェクトが縦割りか見分ける方法」を思いついたので、日記に残しておきます。
まず本文を読むにあたっての前提を記載します。
- 本文章では「縦割りなプロジェクト」の対義語を「一体感のあるプロジェクト」としています。
- 本文章ではある１つのシステムやサービスを開発する集団のことを「プロジェクト」、プロジェクト内で役割によって分かれた集団のことを「チーム」と記載します。
イメージとしては、プロジェクトは○○更改プロジェクト、チームはＡ業務チーム、B業務チーム、基盤チームといった感じです。
この前提で「プロジェクトが縦割りか見分ける方法」を述べると、「プロジェクトが縦割りか見分ける方法」それは「チームをまたがる技術的な課題の解決策をわくわく感を持って議論できるかどうか」です。
一体感のあるプロジェクトは、チームをまたがる技術的な課題の解決策をわくわく感を持って議論できますが、
縦割りなプロジェクトは、チームをまたがる技術的な課題の解決策をわくわく感を持って議論することはできないと考えます。
何故こう考えたかということ、チームをまたがる技術的な課題の解決策を議論するというのは、本来的にはエンジニアにとってわくわくする楽しいことだと思うからです。
エンジニアの方であれば、ある技術的な課題を「こういう技術があれば課題は解決するのに」「その技術ってこうやったら実装できるんじゃない？」「あ、それならできそう、チャチャッとやってみるか」といった感じで、楽しく議論したことがあると思います。
一体感のあるプロジェクトであれば、議論した内容がプロジェクトに本当に必要ということになれば、チーム間で作業の優先度勘案した上で、プロジェクトとして課題を解決するためのアクションを取れると思うんですよ。
縦割りなプロジェクトというのは、このチーム間の調整ができないのだと思います。
だから、本来的には楽しい技術的な課題のディスカッションの場が、作業の押し付け合いのような様相を呈してしまうのだと思います。
明らかにまとまってないんですが、今思っていることの骨子は書けたので、とりあえず文章を公開しようと思います。
また何か考えたら書きます。
このページはtoggleボタンのサンプルページです
要素の表示・非表示を切り換える、それがtoggleボタンです。
この機能を使って、画像の切替も実現可能です。
なお、説明と画像は一切関係がありません。
この機能を使って、画像の切替も実現可能です。
なお、説明と画像は一切関係がありません。
yaml.erbをyamlに変換するスクリプト
yaml内で変数を使いたかったので、erbと組み合わせて実現した。
個人的な備忘録として書き残しておく。
早速だがyaml.erbをyamlに変換するスクリプトは以下の通り。ファイル名はymlerb2yml.rbとする。
require 'erb' require 'yaml' # VARIABLE DEFINITION var1 = 'bbb' var2 = 'ddd' # FORMAT TRANSLATION yml_erb = ARGF.read() ruby_data_type = ERB.new(yml_erb).result(binding) yml = YAML.load(ruby_data_type) puts yml.to_yaml()
動作確認には以下のyaml.erbを用いる。ファイル名はtest.yml.erbとする。
- aaa - <%= var1 %> - ccc_<%= var2 %>: eee
実行結果は以下の通り。
# ruby ymlerb2yml.rb test.yml.erb --- - aaa - bbb - ccc_ddd: eee
ワンライナーでやると以下の通り。
# ruby -r erb -r yaml -e "var1 = 'bbb'; var2 = 'ddd'; puts YAML.load(ERB.new(File.open('test.yml.erb').read).result(binding)).to_yaml()"
---
- aaa
- bbb
- ccc_ddd: eee
こんな感じでやりたかったことやれたっぽい。
Ruby / Rails ビギナーズ勉強会（第11回）登壇レポート
- [3/16追記] 発表動画をYouTubeに挙げていただいたので、リンクを貼りました。
2月27日(土)にRuby / Rails ビギナーズ勉強会で発表してきた。
タイトルは「Railsチュートリアル完走後の次の一歩」。
発表資料はこちら。
準備や発表を通じて感じたことを簡単にまとめる。
スライド作成
- スライドのデザインを考えるときはまずノンデザイナーズ・デザインブックを参照した。特に配色の考え方が参考になった。
- 文字色のベースを黒じゃなくて灰色すると綺麗というツイートを見て、そのようにした。
- フォントは「Noto Sans」が綺麗と聞いて試してみたが、「Meiryo UI」のほうが好きだったので、そちらを使った。
- 今回の発表資料はそれなりに時間をかけてこだわれたので、今後また発表資料作るときはこれを参考にしようと思う。
- クリップアートや画像を探すのにやたら時間がかかってしまった。会社だと会社でクリップアートを用意してくれていて、それを使えばいいのだけど。
発表
- 練習のとき12分くらいかかっていたので、ちょっと急ぎ目でやったら8分かからず終わってしまった。かなり早口になってしまっていたと思う。反省。
- 発表練習しまくって、できれば資料の内容は暗記しておきたいと思った。スクリーン見るために後ろ向いたり、手元のノートPC見るために顔を落とすのは見栄えが良くないので。
発表内容
- 資料を作る前は、内容簡単すぎて発表する意味ないかと思ったけど、資料を作っていたら、それなりに意味のある資料を作れている気がしてきた。
今作っているアプリをとりあえず作りきって、今年中にもう一回発表したいと思う。
発表動画
Amazon Aurora東京ローンチ記念セミナー参加レポート
11/10(火)、目黒で開催されたAmazon Aurora東京ローンチ記念セミナーに参加してきたので、レポートをまとめておく。なお、数値などは聞き間違いがあるかもしれないので、詳しくは発表者の資料や公式のドキュメントを参照してほしい。
セミナーの感想
セミナーを通してAmazon Auroraはエンタープライズレベルの要件に耐えうるスケーラブルなRDBMSであると、自分なりに咀嚼して理解できたのがよかった。
Auroraの特徴のうち、特に衝撃だったのは次の3点だった。
- MySQLの5倍の性能
- 秒オーダでのフェイルオーバ
- Auroraはマスタは1つなので、マスタ障害時にはフェイルオーバが発生する。リードレプリカがある場合、フェイルオーバ時間は30秒ほど。MariaDB Connectorと組み合わせたら1～2秒になったという事例がある。
- お手軽マイグレーション
セミナー後調べたこととか考えたこと
- Auroraの資料見たところ、なんとAuroraはPostgreSQLと同じ追記型らしい。
これによりバックアップなどの運用性向上、書込性能の向上が実現されているとのこと。 - Auroraは可用性99.99％で設計されていて、SLAは99.95％とのこと。この数字が今後向上したら世の中のシステムはどうなるんだろう。
- NoSQLが出てきたとき、「NoSQLがRDBMSに取って代わることはなくて、適材適所で使われるようになる」という話があったと思う。
これに対してAuroraは、「Oracle, SQL Server並みの性能を、MySQL, PostgreSQL並みのコスト、運用性で」というセミナーでの発言が示すとおり、これから全てのRDBMSの領域を置き換えていく可能性のあるサービスだと思った。 - これからもたくさん事例が出てくると思うので、そのあたりウォッチしていこうと思う。
以降はセミナー中に取った聴講メモなど。
はじめのあいさつ
最初はAWSJ安田さんの挨拶。
Talend、DataSpiderといったデータ連携のツールが既にAuroraに対応。
ウイングアーク1st株式会社は自社製品の中でAuroraを使っているとのこと。
Using Amazon Aurora for Enterprise Workloads
AuroraのGMのDebanjan Sahaさんのお話。
聴講メモ
- Auroraはエンタープライズ利用を想定して設計してある。
- MySQLに完全互換。MySQL向けアプリはそのままAuroraで使える。
- 性能はOracle, SQL Server並、運用のしやすさ、コスト効果はMySQL, PostgreSQLというところを狙っている。
- Master障害時のフェイルオーバ時間は30秒以内。
- MySQLでは数分かかるようなクラッシュリカバリがほぼ即時に実行される。
- 最大50万回/秒の読込、10万回/秒の書込性能。これはMySQLの5倍。
- ストレージ自体がDB用に設計されている。
- これらがフルマネージドサービスになっている。すぐ使えるし、パッチも自動で当たる。
- AWS史上最速で成長しているサービス。
- 国連でも使っている。公開事例になっていなくても、多くの会社がAuroraを使っている。
- 事例1: Expedia
- リアルタイムでのBIと分析が要件。現行はSQL Serverベースのアーキテクチャだったが、高価だった。またスケールしなかった。 そこでCassandraとSolrを組み合わせてインデックスを作成したが、これは大きなメモリー空間が必要で、結局コストが高くなってしまった。
- 事例2: Pacific Gas and Electric Company
- この顧客特有の事情として、停電時にバーストトラフィックが来るので、これを捌かなければならないという事情があった。
- 事例3: ISCS
- 現行ではOracleとSQL Serverを通常業務とDWH用途で使用。これらのコストがIT費用の中で最も大きな支出になっていた。
- Auroraの利用により、70％安価なシステムを実現。
- 事例4: Alfresco
- 事例5: Earth Networks
- 25TB/日で増えるデータの処理をする必要があった。(IoT関連の事業をやっている会社なのかな？)
- 事例6: threat stack
- これもCassandraからの移行事例。
- 高可用性を支える技術
- 3つのAZにまたがり6つの複製を保持。
- Peer-to-pper gossipレプリケーション
- 6つのうち2つを失っても性能は落ちない。6つのうち3つを失っても読み込みは可能。
- 高速なクラッシュリカバリ
- 普通はチェックポイントが5分間隔とかで、ログをシーケンシャルに適用する。時間がかかる。
- Auroraは、Disk readの一環として、オンデマンドでredo logの適用を行う。そのため、リカバリ時にredo logを当てる必要がなく、1秒以内でのリカバリが実現できる。
- AuroraとMariaDB Connectorにより、さらに短時間でのフェイルオーバが可能。
- バックアップについて
- 各DBのスナップショットを定期的かつ並列で取得し、REDOログをAmazon $3へ転送する。
- 適用型スレッドプール
- この辺りはMySQLの実装とかなり違う。(詳細聞き逃した。)
- 非同期グループコミット
- 6つのうち4つのDBでコミットがされた時点で、データの書込みが成功する。
- Advanced monitoring(開発中)
- 顧客からの要望のあった、OS関連メトリクスを取得できるようになる。
- Cloud watchは1分間隔だが、Advanced monitoringは1秒間隔でメトリクスの取得ができる。
- AuroraはMySQLと比べてもコスト効果があることがある。
Q&A
- Q MySQLの場合、データサイズが大きくなるとDDL変更が時間がかかるが、Auroraはそのあたり改善しているのか？
- A いくつかは改善しているが、全てではない。オンラインでのDDL変更については、現在開発中。
- Q モバイルSDKから直接使えるか？
- A 使える。
- Q インスタンスタイプR3しかないが、今後の展開は？
- A 現時点では、T2タイプを今後サポートしたいと考えている。M, CあたりはAuroraのアーキテクチャを活かせないので、考えていない。
- Q メモリに載らない大きなテーブルのalter tableしないほうがいいという話があるが、現在は？
- A おおよそ修正済み。ただ超巨大なテーブルをalter tableするのであれば、大きなインスタンスタイプを利用することをオススメする。
- Q MySQLのMHA(数秒でのインスタンスタイプ変更)のような機能は提供されているか？
- A MHAはサポートしていない。そのような場合の対応方法としては、大きなインスタンスにリードレプリカを作っておいて、そこにフェイルオーバするのを推奨している。
Nice to meet you, Aurora! ～RDS for MySQLからAuroraへの移行～
株式会社Grani @guitarrapc_techさんの発表。発表前に資料公開されていて、ありがたかった。
資料
聴講メモ
- 性能改善について
- NewRelicでざっくり見る。個々のクエリはBigQueryで見る。
- 参照は変わらなかった。
- 更新が5倍速くなった。5倍というアナウンスどおりの結果が出た。
- インサートも速くなった。
- 削除は若干遅くなった。
- 移行について
- MySQLだと高負荷時にダウンしてしまうことがあった。Auroraはスローダウンすることはあっても、動き続ける。
- 年間2200万円のコスト削減効果。
ドワンゴがAurora使ってみた(仮)
株式会社ドワンゴ 細川さんの発表。
聴講メモ
- これまでのはなし
- Aurora適用プロジェクト
- 検証結果・パフォーマンスなど
Amazon Aurora 評価・検証結果発表
アイレット株式会社 cloudpack 新谷さんの発表。
実データを用いたAurora検証結果の報告。
Amazon Auroraはこう使おう！
～基幹業務をフルクラウド化するポイント～
ウルシステムズ株式会社 漆原さんのお話。
聴講メモ
- これまでRDBMSとNoSQLという極端な2択しかなかった。基幹業務系やっていて、ずっとクラウド型のRDBMSが欲しいと思っていた。
- オンプレをそのままクラウドに持っていくと、インフラコストの削減にはなるけど、それしかない。その先へ。
- モノリシックな業務APが、今、すべてを邪魔している。このままAuroraにいっても、それからどうしようもなくなる。
モノリシックなものをマイクロサービスへ。APIで綺麗に切りなおして、そこからしかアクセスさせないようにする。
オーバヘッドはあるが、その代わりスケーラビリティが得られる。こうすることで、Auroraの特性をフル活用できる。
New Cloud Design Pattern using Amazon Aurora
クラスメソッド株式会社 大栗さんのお話。
聴講メモ
- Develpers.IO移行事例
- Developers.IOをAuroraに移行した。性能向上した。
- もともとdb.m3.mediumだったので、db.r3.largeになって、コストは1.5倍になった。
- 某SNS移行事例
- これ以上DBのスレーブ増やせない状態。移行検討中。
- 高速なフェイルオーバ
- OSS DBと比較して低価格の場合もある。インスタンス台数が削減できる場合があるので。
Amazon Aurora＋ScaleArcによる Amazon Aurora のデータベース分散処理技術の最大活用
株式会社システムサポート 山口さんのお話。タイトル違うかも。
ScaleArcという製品の紹介。
エンタープライズシステムにおける Amazon RDS for Aurora 活用ノウハウ
株式会社野村総合研究所 西岡さんのお話。
聴講メモ
- Auroraは可用性99.99％で設計されていて、SLAは99.95％。
- Auroraは現状参照しかスケールしない。
その他
- Amazon Aurora TシャツとAurora利用クーポンの抽選があったけど、外れた。Tシャツ欲しかったな。残念。
- アマゾンのセミナールーム、発表者の立つところに神棚があって、意外と日本ぽいんだなーと思った。
けどよく見たらドアだった。しかもセミナールーム中にいっぱいあった。どういうことなの。
