ほとラボ

It works!

オレオレ GitHub Issue テンプレートを晒す

Gaiax Advent Calendar 2016 2日目、ギフハブ GitHub のテンプレートについて。

GitHub のテンプレート機能

プロジェクトコードのホスティングサービスとして GitHub を利用している IT 企業は多いと思うし、Gaiax でも活用している。

そんな GitHub に今年の2月に派手ではないがとても便利な機能が追加された。 リポジトリのルートに .github というディレクトリを掘ってその中に ISSUE_TEMPLATE.mdPULL_REQUEST_TEMPLATE.md といったファイルを置いておくと、Issue や Pull request を作成する際にテンプレートを表示することができる。

github.com

この機能すごく便利で、今まで

◯◯が××になっていたので修正した

みたいな1行しか説明ない雑なプルリクエストが投げられると

  • それを直さないと誰がどう困るの
  • 原因はなんだったの
  • なぜその変更で修正されるの

などなど、いちいち聞き返さなければいけなくてレビューしづらいことこの上なかったのが、テンプレートを用意することによって予め書いてもらいやすくなる。

どういうテンプレートにするか

いざテンプレートを用意したとしても、知りたい内容をちゃんと織り込んでおかないと結局また質問する羽目になってしまう。

ちゃんとしたテンプレートを用意したいけど、こういうの毎回考えるの面倒じゃん? ベストプラクティスみたいなのが欲しいなー、と。

今は少ない頭を振り絞って考えたテンプレートで運用しているんだけども、どうもまだ「ベスト」という感じがしない。 もっと改善の余地がある気がする。

つまりこのエントリの趣旨としては、自分のチームのテンプレート晒すから「これだとここ不便じゃない?」「ウチはこうしている」みたいなレスポンス欲しいなーーー |д゚)チラッ という感じです。

各位よろしくお願いします。

Pull request テンプレート

まずはプルリクエストのテンプレートから。

<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい -->

# 概要
<!-- 変更の目的 もしくは 関連する Issue 番号 -->

# 変更内容
<!-- ビューの変更がある場合はスクショによる比較などがあるとわかりやすい -->

# 影響範囲
<!-- この関数を変更したのでこの機能にも影響がある、など -->

# 動作要件
<!-- 動作に必要な 環境変数 / 依存関係 / DBの更新 など -->

# 補足
<!-- レビューをする際に見てほしい点、ローカル環境で試す際の注意点、など -->

<!-- --> は内容を例示するコメントとして使えて良い。 消し忘れたとしても HTML に変換された際には見えなくなるので便利。

<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい --> はチーム内で合意が取れてればわざわざテンプレートに書かなくてもいいかなと思う。この一文があるせいで概要以外埋めてないプルリクエストもたまに上がってくるので微妙かもしれない。

Issue テンプレート

続いて Issue のテンプレート。

<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい -->

<!-- 要望のテンプレート -->
# 概要
# 目的
# 提案内容
# タスク
- [ ] 細かいタスクに分解できているなら書き出す

<!-- 不具合のテンプレート -->
# 概要
# 再現手順
# 修正しないとどう困るか
# 原因
# 修正案

Issue に登録するものってカテゴリに分けられるような気がして。

すごく大雑把に分けて「要望」「不具合」かな、と思った。

これをひとつのテンプレートにまとめてしまうと「知りたいこと」が書ききれずにまた質問しなきゃいけなくなりそうだし、 かといってこれ以上細かくするとテンプレートが巨大になってしまうので、これくらいがいい塩梅なんじゃないだろうか。

このテンプレートを使ってみた感想

  • すべての項目を埋めなくてよい を入れておくとたまに雑な Issue / PullReq が作られちゃう
    • でも Issue とかカジュアルに作って欲しいし、項目埋めるの必須にしたくない
  • Issue を「要望」「不具合」に分けたのいい感じ
    • 作るたびに片方削除するのちょっと手間だけど、そんなに気にならない

三行まとめ

  • GitHub のテンプレート機能便利
  • でもちゃんとしたテンプレート作らないと意味ない
  • 他社の事例とか知りたいなーーー |д゚)チラチラッ

CATV インターネット回線に切り替えてからわずか2日で解約するまで

今住んでるアパートには CATV (ケーブルテレビ) 回線が既に引かれていて、CATV のインターネット回線にすると安くなるっぽいので切り替えてみたものの、いろいろあって2日で戻した話。

前置き

ケーブルテレビ品川 さんおよび イッツコム さんをディスるような意図はない。

解約したのはちょっと今の自分に合わなかっただけで、人によっては良いサービスだと思う。

契約してから解約するまでの流れ

  1. ケーブルテレビ品川が数年に一回点検に来る
    • 点検のついでに営業を受ける
    • メリデメともにわかりやすく説明してくれる良い営業だった
    • ネット代が結構安くなることがわかったのでその場で即決して契約
  2. 工事の人が来て開通
    • 工事を見てたワイ「えっ、CATV インターネットって同軸ケーブルで通信するの・・・」
    • ケーブルテレビインターネットの罠があることを知る (後述)
  3. 自分でルータを設定する
    • モデム + ルータ + アクセスポイント が一体になっているタイプ
    • わけわからないルータ使わないといけないのつらい気がしてきた
  4. 解約

CATV インターネットの注意点

CATV ネット回線を使ってみて気づいた罠っぽいことのまとめ。

同軸ケーブルはカジュアルに抜いてはいけない

CATV のインターネットは同軸ケーブル (テレビに繋ぐアレ) をモデムに接続して通信を行う。

電話回線を利用したインターネットであれば、電話線をポンポン抜いて部屋の模様替えをしたりするが、同軸ケーブルの場合はモデムからケーブルを抜くと何かの信号レベルが変わってインターネットに接続できなくなってしまうらしく、「同軸ケーブルを抜くなどの操作をしたい場合は連絡して欲しい」と言われた。

模様替えを頻繁にしなければ特に問題にはならないんだけど、カジュアルにケーブルを抜き差しして配線を試行錯誤するのが好きな身としてはこの縛りは結構つらい。

速度が理論値よりだいぶ遅い(かもしれない)

回線が変わるとどれだけ速度がかわるのか気になっていたので、計測した。

Internet Speed Test - HTML5 Speed Test

フレッツ光ネクスト マンションタイプ (下り最大100Mbps)

f:id:hoto17296:20161113152933p:plain

最大 100 Mbps のところ実測で 75 Mbps というのは、けっこう良い方なんじゃないかと思う。

イッツコム かっとびメガ160 (下り最大160Mbps)

f:id:hoto17296:20161113154208p:plain

ひえええ〜〜〜(´・_・`) まさかフレッツ光の半分以下になるとは思わなかった・・・*1

まあこの速度でも YouTube 観れるし、特に困らないので致命傷ではなかった。

ネットワーク構成があまり自由にできない

普通のインターネット回線の場合だと別にプロバイダを契約するので、モデムに接続する PC なりルータなりでプロバイダのアカウント情報を使って PPPoE 接続する場合が多い。

CATV のインターネットの場合、そもそもプロバイダという概念がないので接続端末でプロバイダ情報を入力する必要がない。すると「はじめから回線契約者の情報はモデムに埋め込んである」→「もういっそモデム1台で全部やってくれたら無敵」という発想になる。その結果「モデム + ルータ + アクセスポイント」が一体となった謎端末を利用することになる。

「インターネットが使えれば良いんじゃ」という大多数の利用者からすればむしろ一体型端末の方が便利だが、EdgeRouter X とか買っちゃうような自宅ネットワークで遊びたい人間にとっては「なんだかよくわからないルータの利用を強制される」という縛りになってしまう。

blog.hotolab.net

ワケわからないなりにそのルータを使い倒していこうと思ったのもつかの間、ポートフォワードの設定がうまく機能せず、サポートに問い合わせても「その設定で動くはずですね・・・」との回答で何も解決せず、最終的に「ポートフォワードもマトモに出来ないルータなんて使ってられるかーーーい」ということで開通二日目にして解約するに至った。

ケーブルテレビ品川 / イッツコム の良かった点

なんかこのままだと悪口エントリになってしまうので良かった点も書いておく

営業の人すごい

点検ついでに営業トークしてきたお兄さんがすごかった。

ぶっちゃけこのプランは乗り換えるメリットそんなにないんだけど個人的にはすごく契約して欲しくてですね〜」とかナメたこと言ってきてめっちゃ面白かったし、あと「(インターネットへの)接続方法は PPPoE ですか?」って訊いたら「CATV 回線にはプロバイダというものが無いので〜(以下略)」と返ってきて、あーちゃんとわかってる人が営業やってるんだなスゲー、ってなった。

技術ちゃんとわかってて営業も上手い強い人が点検作業してるってすごくない?

安い

もともとこの安さに惹かれて回線を切り替えようと思った。

au 使ってる人限定の話だけど、ケーブルテレビ品川に限らず多くの CATV で ネット + 電話 を契約すると au スマートバリューが適用できるらしい。これは知らなかった。

au スマートバリュー、てっきり「au ひかり」じゃないと適用できないと思っていて、今の家は「au ひかり」提供エリア外だったので割高でもフレッツ光使うかー、となっていた。

ウチは夫婦で au スマホを使っているので、スマートバリューが適用できると月額料金がだいぶ安くなる計算だった。

まとめ

  • 自宅ネットワークをいじりまわしたい人 / 回線速度をとても気にする人 は高い金払ってでもフレッツ光にしたほうがいい
  • CATV が引かれている集合住宅に住んでいる場合は CATV のインターネットに切り替えるだけでだいぶ安くなるかもしれない

*1:あくまで「ウチで測ったらこうだった」というだけなので参考程度に

EdgeRouter X を共同購入した

先月 YAMAHA NVR510 が発売され自宅用に買おうか迷っていたタイミングで「EdgeRouter X がすごい」というエントリを読み、EdgeRouter に俄然興味が湧いてきてしまった。

EdgeRouter X とは何か、どうすごいのかという話はすべてこのエントリを読めばわかるので割愛するが、「めっちゃカスタマイズできるコスパ良すぎるルータ」という感じでだいたい合ってると思う。

yabe.jp

このエントリかなりバズったらしく、日本の EC サイトでは軒並み EdgeRouter X が品切れになってしまっていた。 次回入荷時期が未定な中この IYH 欲を抑え続けることが不可能だった。 海外から個人輸入するしかない。

某エンジニアコミュニティで共同購入を募ったところ予想以上に 8 人も集まり、数千円かかる送料が一人当たり数百円で済んだ。共同購入はいいぞ。

今回は日本に直送できる EuroDK というサイトから購入したが、注文で困ることもなかったし、特に問題もなく一週間くらいで届いた。

www.eurodk.com

海外からの輸入なので日本のコンセント(TypeA)用の AC アダプタは自分で用意しなければいけないかと覚悟していたが、届いたのを開けたらなんと変換器を付けてくれていた。送る国によって対応する変換器をサービスしてるということなんだろうか。なんにせよとてもありがたい。

まだ届いたばかりで何も触ってないので、ちゃんと色々いじったらもう一度エントリを書こうと思う。

LINE Pay カードを作らなくても LINE Pay アカウントは作れる

LINE Pay アカウントを作るには LINE Pay カードの申し込みが必須っぽい雰囲気あるけど、別に LINE Pay カードを作らなくても LINE Pay アカウントを作れたという話

個人間決済したい

飲み会の割り勘やイベントやるときの集金、海外のものを共同購入するときの集金など、個人間決済をしたいケースは多々ある。

現金手渡しは超面倒だし、銀行口座を晒して振り込んでもらうのも人によってはハードルが高い。 スマホでポチポチするだけで隣の人に送金できるようにしたい。

海外だと Facebook のメッセンジャー決済とかあるけどまだ日本対応してないし、Apple Pay もなんだかんだ個人間決済はできないっぽい(?)し、やはり決済が絡むプラットフォームは海外サービスが入ってくるのがだいぶ遅い印象がある。

となると個人間決済をするなら現状では LINE Pay を使うのがベターなんじゃないだろうか。

LINE Pay とは

LINE の電子マネーサービス。

口座振替やコンビニ支払いでチャージしたり、LINE ポイントから変換したりすることで残高が増える。

チャージした残高は LINE Pay 対応のお店で使えたり、銀行口座に振り込んだりできる。

そしてなにより、個人間決済(LINE Pay アカウント間での残高のやりとり)ができる。これが他の電子マネーと違うところ。

LINE Pay カード とは

クレジットカードと同じインタフェースで LINE Pay 決済ができるようになるカード。

LINE Pay 決済に対応しているお店はまだまだ少ないが、クレジットカード(正確には JCB カード)払いに対応してさえいれば LINE Pay 決済を使うことができるようになって便利。

クレジットカードではない(審査がない)ので高校生でも作れるし、残額以上に使うことはできないので使いすぎる心配もない。チャージして繰り返し使えるプリペイドカードのようなイメージだ。

カードを作らずにアカウントを開設する方法

この LINE Pay カードだが、まだ LINE Pay アカウントを持ってない人がアカウントを開設しようとすると「まずは LINE Pay カードを申込みましょう」みたいに表示され、あたかも「LINE Pay アカウントを作成するには LINE Pay カードの申込みが必須です」という雰囲気を醸し出してくる。

別にカードの申込みにお金がかかるわけじゃないし特にデメリットはない。 しかし個人的にはもうクレカを持っているし、LINE Pay カードを作っても全く使わないことが目に見えているので、使わないカードはできるだけ作りたくないという気持ちがある。

だから「作らなくても済むなら作りたくないなー」くらいの気持ちで Twitter につぶやいたら、LINE Pay 公式から返信が来た。

これがアクティブサポートってやつだ。すげえ。

一度カードを申し込んで直ぐに解約すればアカウントだけ作れる、ということらしいので一旦カードを申し込んでアカウントを作ってみると、カードの詳細画面の下の方に解約のリンクが確かにあった。

丁寧に教えていただいた LINE Pay サポートさんには申し訳ないけど、やはり使う気がしないので「カード解約」をした。

今のところカードは届いていないので、無事「LINE Pay カードを作らずに LINE Pay アカウントを作る」ことに成功した模様。

まとめ

  • 日本で個人間決済するなら今のところ LINE Pay が良さそう
  • LINE Pay アカウントを新規作成するためには LINE Pay カードへの申込みが必須
  • アカウントを作成してすぐにカードを解約すればカードは送られてこない

LINE Pay 使っていこうと思います ₍₍⁽⁽(ી( ・◡・ )ʃ)₎₎⁾⁾

ServerlessConf Tokyo に参加したけど残念だった

前々から楽しみにしていた ServerlessConf Tokyo に参加したけど、1時間も経たずに帰ってしまった。

tokyo.serverlessconf.io

ちなみに前日のワークショップはとても面白かった。

金曜日の疲労感でとても濃いワークショップを4時間やったらとても疲れてしまって、朝起きることが出来ずに昼から参加したのだけれど、行ってみたらイベント運営の不備みたいなものが目についてしまってどうしてもコンテンツに集中することができなかった。

受付がない

カンファレンスと言えば、会場に着いたら受付をしてスポンサーノベルティを貰って着席する、というイメージがあったのだけれど、ServerlessConf では「受付どこかな」と探しているうちに発表部屋に着いてしまった・・・。

遅れて参加したから受付なくなっちゃったのかな・・・。 「見逃した」ということはなさそう、「受付はない」という感じだった。

これ、仮にも 3000 円するイベントだよね? そんなにすんなり入れちゃって大丈夫なの???

「金払ってなくても入れる」って金払った人に失礼だと思うんだけども。

「Amazon Cognito 使ってどうのこうの」云う前にまずは会場の認証をどうにかしたほうがいいのではないか。

なぜこの会場にしたのか

会場が、技術系カンファレンスをやるには向いてないとしか言いようがない。

まず 電源 も Wi-Fi もない ということ。

エンジニア向けのイベントって参加者が PC 広げて Twitter で実況とかするのはよくあることだし、そういうところから「イベントが盛り上がってる感」が醸成されると思うんだけども、それが極めてやりづらい会場だった。

2時間程度のイベントなら バッテリー + テザリング 使えばいいという話だけど、丸一日あるカンファレンスだとそうもいかない。「Twitter 実況がしたければモバイルバッテリーをご持参ください」という世界観なのか。せっかく盛り上げるチャンスなのにそれはもったいなさすぎないか。

もうひとつは、会場の構造が微妙 ということ。

写真を見てもらえばわかるが会場が縦長で、後ろの方に座るとまあ見にくい。 特に両端の席に座ると上の構造物でスライドの一部が隠れてしまって見えない。

「電源 Wi-Fi がない」「会場の構造が微妙」のどちらも許容できなくはないし「会場の質」はイベントの本質じゃないとはいえ、技術系カンファレンスを開催するにはあまりに不適切じゃないだろうか。本来楽しめたはずのコンテンツが全く楽しめなくなるような会場がチョイスされてしまったのは非常に残念だった。

最後に

前日のワークショップは面白かったし、発表資料も読んでいてとてもタメになったし、コンテンツの質が高いだけに本当にもったいないイベントだった。

サーバレスな技術にはすごい興味があるのでまた同様のイベントがあったら参加すると思う。 次回はもっといいイベントになることに期待したい。

ISUCON 6 予選に出て 0 点だった

f:id:hoto17296:20160918092910j:plain

今年も ISUCON 予選に出場したけど、最終スコアは 0 点だった。

写真はあまりの不甲斐なさに食べた地獄谷麻婆豆腐

3回目の出場で、練習会も開催して、当日までの準備もバッチリ整えてやった結果が 0 点というのかなりヘコむ事態。

blog.hotolab.net

事前にやったこと

  • Slack にプライベートチャンネルを作る
  • Azure に慣れる
  • NewRelic と Mackerel のアカウントを作る
  • 事前に「Node でやろう」と決めておき、プロファイルの仕方などを調べておく
  • Azure でインスタンスのクローンするの大変そうだったので1インスタンス内で全員作業することにする
    • そのため、インスタンス外にリポジトリは作らなかった

午前中まではよかった

  • 開始30分前に全員集合
  • インスタンスを立てるのは難なくクリア
  • サービスふたつあるし、isupam とかいう謎サービスも動いてるし、お題「マイクロサービス」っぽい
  • Node 実装、どうせ Express だろうと高を括っていたらまさかの koa
    • Node の初期実装がバグっていたのもあって「ここで頑張るのはやめよう」と判断し、Ruby に切り替え
  • NewRelic と Rack::Profiler 入れてベンチマークを回してみる
    • まあどう見ても htmlify がボトルネック

実装力が低かった午後

  • 毎回 htmlify するのどう考えても無駄なのでどこかにキャッシュするしかない
    • htmlify 済みの文字列を MySQL にカラム増やして突っ込めば良さそう
    • エントリが増減する度にすべてのデータを更新する

ここまでは誰でも思いつくはず

DB 初期化

エントリが増減すると初期データのレコードが更新される → 初期化処理が「id:7101 以降のデータを削除する」だけではダメ

MySQL の初期データを作って /initialize 時に5秒以内にツッコめばいい、ということになる。

  • mysqldump : 軽く5秒以上かかるので無理
  • xtrabackup : MySQL 5.7 で動かずに困惑
    • 今思えば MySQL を 5.6 に下げればよかったでは

どっちもうまくいかなかったので「MySQL のデータファイルを直接置き換える」という力技で突破

Unicorn 再起動

  • MySQL を再起動すると Ruby からのコネクションが切れる
  • コネクションが切れたときの貼り直し方がわからない
  • /initialize 時に Unicorn を再起動しよう
  • Unicorn が自分自身を再起動させるとうまくいかない
  • 初期化用の別アプリケーションを実装して、/initialize のアクセスをそっちに流す
  • 初期化用アプリケーションが MySQL と Unicorn を再起動する

なんか・・・コレジャナイ感が漂ってきた・・・

MySQL が死ぬ

再起動はできたものの、initialize 後に MySQL が死ぬ現象に戸惑っていたところで時間切れ

反省

  • 初期化処理に時間かけすぎた
    • 初期かそんなちゃんとやらなくてもベンチマーク通った気がする
  • 1インスタンス内で全員が作業するの良くない
    • 検証したくなる度に「いまブランチ切り替えていい?」って気にしなきゃいけないの無駄
    • 多少時間使ってでもインスタンスは複数立ち上げるべきだった

他にも色々と試みてたけどそのへんは他のメンバーが書いてくれるはず

まとめ

  • ISUCON 4 は何もわからないまま終わった
  • ISUCON 5 は頑張ってチューニングした箇所が大してボトルネックじゃなくてスコアが上がらなかった
  • ISUCON 6 はボトルネックの見極めまではできたが、実装力の低さと時間配分ミスから爆死 ← NEW!

少しずつ成長してはいるけど、まだ決勝行ける実力ではない・・・

はーーー 悔しさ〜〜

謝辞

今年もとてもおもしろい問題でした、運営の皆様ありがとうございました!

ISUCON 練習会をするために InfluxDB + Grafana でポータルサイトを作った

9/17,18日に迫る ISUCON 6 予選に向けて、某若手エンジニアコミュニティで参加者を募って ISUCON 練習会を開催した。

お題は今年の出題者である pixiv さんが社内 ISUCON を開催したときの AMI を活用させていただいた。

inside.pixiv.net

やってみた結果については同じチームだった sota1235 さんがまとめてくれているのでここには書かないが、まあここままだと決勝進出はまず無理だしもっと予習を頑張らないといけない。

ポータルサイト使えない問題

本番の ISUCON ではポータルサイトが用意されていて、ベンチマーカーを実行すると自分のチームのスコアがページに反映され、また他チームのスコアもリアルタイムで確認することが出来る。

しかし ISUCON 終了後に練習用 AMI が公開される際にはポータルサイトの AMI は公開されない。一人で予習復習する分にはポータルサイトは必要ないのだし、そりゃそうだ。

しかし今回の練習会のように複数チームでわいわいやるのであれば、本番さながらに他チームのスコアがリアルタイムで見れたほうが間違いなく楽しい。こうなったら自分で作るしかないので、試行錯誤を重ねてそれっぽいものを作った。

1行もコード書きたくない

まず思いつくのは、愚直に「スコアを MySQL か何かに保存して Google Charts のようなグラフ描画ツールで表示する Web アプリケーションを開発する」こと。 ただこれは極力やりたくない。 超汎用的な手段で無理矢理解決しにいっている感じがあって、面白くもなんともない。

21世紀という便利な時代なんだから、きっと他にもっとこのニーズに最適化された解決策があるはずだ、と思う。 エンジニアだからこそ、安直にプログラミングで解決しにいってはいけない。 「送られてきたデータをグラフで表示する」くらいのシンプルなニーズであれば、1行もコードを書かずに解決したい。

あと思いつくのは Mackerel にスコア飛ばすくらいだけど、無料プランだとホスト5台までだから5チームまでしかできないのかー、でも有料プランを使うと1ホスト(チーム)あたり1800円かかってしまって現実的ではない、という感じでコスト的に除外。

そんなことをあれこれ考えてるうちに、時系列 DB を使ってみようと思い立った。

時系列 DB の機運

時系列 DB はその名の通り時系列に沿ったデータを取り扱うのに特化した DB。 用途が限定的だ思うかもしれないが決してそんなことはない。 よくよく考えると多くのデータにはタイムスタンプがついていて、それを可視化しようとなったら時系列に沿ったグラフを表示することが多いので、時系列 DB が活用できる場面は思っていた以上に多い。

時系列 DB にもいくつも種類があるが、今回は

  • 簡単に扱えそうだから
  • 比較的新しいっぽいから
  • オシャレっぽいから

という雑な理由で InfluxDB を使ってみることにした。

趣味プロダクトだし、ダメだったらそのときに次の手段を考えればいいんや。

他の時系列 DB についてはこんな感じ。

  • Elasticsearch
    • fluentd → Elasticsearch → Kibana でログ可視化、という話はよく聞く
    • 単純なデータのグラフを表示する程度のニーズで使うには複雑すぎる
    • そもそも時系列 DB じゃないし
  • RRDtool
    • 枯れてる(らしい)
  • Graphite

詳しくは: 時系列DB・可視化のいまむかし - Qiita

今回は用途が小規模かつ1日だけだったので、可用性だの何だのということは一切考えていない。 長期的にメトリクス監視をしたいなどの場合はもっといろいろと検討した方がいいと思う。

ポータルサイトでスコアを集計する仕組み

  • 競技の参加チームにはベンチマークサーバにスクリプトをひとつ入れてもらう
    • ベンチマークを実行する際にはそのスクリプトを実行する
    • スクリプトを実行すると、ベンチマークが実行されると同時に InfluxDB のサーバへデータが送信される
    • そのスクリプト: ISUCON/bench.sh at master · ngineerxiv/ISUCON · GitHub
  • InfluxDB のデータは Grafana でリアルタイムに可視化される

f:id:hoto17296:20160904205703p:plain

実際の様子

触ってみた感想

InfluxDB は導入・設定も簡単だったし、スキーマレスだし、データ構造がシンプルだし、とっつきやすいことこの上なかった。

Grafana は InfluxDB のみならずいくつもの時系列に対応していて便利。 InfluxDB がシンプルな分を Grafana のリッチさがカバーしていて、良い組み合わせ。

InfluxDB / Grafana ともに公式ドキュメントがちゃんと書かれていて、導入方法とか書こうと思ったけど特に書く必要もないかなと思った。

まとめ

  • InfluxDB + Grafana で ISUCON 練習会のポータルサイトを作った
    • シェルスクリプトちょっと書いたけどほぼ「コード書かずに」作れた
  • InfluxDB も Grafana もとっつきやすくて便利