Microservices Meetup vol.2参加レポート

2016年8月9日、株式会社FiNCで開催されたMicroservices Meetup vol.2に参加してきた。
Microservicesってバズワードになっているわりに、これまで実践している人の話って聞いたことがなかったのだけれど、この勉強会では実践している人たちの話をたっぷり聴けて、本当に勉強になった。参加してよかった。
当日のメモを公開する。

「マイクロサービスとSREの役割」by 鈴木さん@kenjiszk (株式会社FiNC)

  • マネージャー。

What is Microservices?

What is SRE?

  • Googleを発端として、インフラの人が名乗りだした。
  • 新規にやること以外はこの部署がやりますよ、みたいなイメージ。
  • SREが独立しがち。

Microservices x SRE

  • サーバの種類が多い
  • Microserviceは増える
  • SREネックになるのでは？
  • Microserviceにすると、Railsとか一個一個対応しなくちゃいけなくて辛い。
  • 1マイクロサービスに1SRE張るのも現実的じゃないしなー。

対策案

  • 業務開発チームに任せてみる

SRE育ててみた

  • 注意すべきは、セキュリティなど、SREの本質的な部分はSREで守らないといけない。

「SRECon 2016 Wrap Up」by 坂本さん@takus (スマートニュース株式会社)

  • druid.io

SmartNews

  • モバイルに特化
  • スマニューには半年に１回海外の空気に触れさせる制度がある。

SRECon

  • Freedom & Responsibility
  • Netflixでは開発者に、サービスぶっ壊せるくらいの権限を与えている。
  • ぶっ壊されたらどうするの？=>開発者は変なツール使わない。 SREが作った、安全なツールがいけているから、何も言わなくてもそれ使う。

社内PaaS作った

  • 社内の課題を見つける
  • プロトタイプを作る
  • 最初の顧客を見つける

障害に現実感を持ってもらう

  • めったに起きないことに時間を割きにくい
  • 計画的にぶっ壊す。
  • Chaos Engineering
  • この辺り、うまくゲーミフィケーションの設定しようぜ。 -　障害発生時にbotにコメントしておくと、botがレポートにまとめてくれる。

SRE should be a Enabler, SRE should not be a Servant

「マイクロにしすぎた結果がこれだよ！」by 榎本さん@mosa_siru (株式会社Gunosy)

KDDIと連携して作ったニュースパスの話

  • コンポーネント分けて、権限ガチガチに分けた。

  • セキュリティグループ見れば

  • OpsWorksはラーメントッピング感覚でサーバ作れる

  • 全体構成が複雑

  • 開発が遅い
  • 障害時の調査範囲が広い ボトルネックの把握が難しい
  • オーバーヘッドが大きい 余ったリソースを融通しあえない
  • 共通部分がしんどい
  • 内部APIのIF変更が辛い モノリシックの辛さをレイヤーを変えて味わっているような感覚。。。
  • 統合管理画面がやばい

良かったこと

  • 影響範囲は局所化できた。
  • メンバー追加のハードルが低い。
  • 今のところデメリット多いけど、人が増えたら再評価されるかも。

「Microservicesの実際と対策」by 大谷さん@shot6 (株式会社 ファーストリテイリング)

  • AWSで働いてたら、作りたくなった。
  • ヘキサゴン
  • Queue, Database, Notification, File, REST, View
  • AWSの機能フル活用している
  • マルチクラウドは辛いので、どっちかに寄せたいという気持ちがある。
  • APIはSwagger。
  • elasticsearch。logstashをbeatsに置き換えたい。
  • MESOSPHERE。
  • KONG。
  • マイクロサービスは技術重要じゃない、組織、体制の話。
  • 並行開発しないなら効果出ない。
  • マイクロサービスは要件に十分な複雑さがない限りペイしない。
  • モノリシックの方が絶対的に安い。
  • CRUDのAPI全部作る、いやいややりすぎでしょ、はあるある。
  • ZIPKIN。Twitterが作っているツールがある。
  • Microservicesのテスト難しい。

ウェルネスタイム

  • HIIT（High- intensity interval training）
  • タバタトレーニング
  • 椅子にお尻をちょんとつけるスクワットを20秒やって、10秒休む。これを8セット。計4分。
  • これで１時間の有酸素運動と同じ効果。

「より良いAPIを作るために」by 相川さん@awakia (ウォンテッドリー株式会社)

  • 綺麗なAPI速習会
  • Wontedlyは生まれた時からHerokuだった。
  • WebはAngular, Reactでできるだけシングルページアプリにして、API通信する。
  • BFF(Backends for Frontends)
  • SEOの問題で、Nodeがいいと思っている。
  • FacebookはAPI力入れている。
  • eager loadみたいな形で作っている。
  • APIのバージョンはヘッダに入れる。
  • apig。みんながCRUDのAPI全部作るの！？と言っていたところ、DBのスキーマ情報から作るようにした。

まとめ

Infrastructure as CodeやImmutable Infrastructureは、基本実践したほうがメリットがあるので、頑張って実践しよう、という感じで盛り上がっていたと思う。
それに比べるとMicroservicesを実践する/しないをしっかり見極めないと、メリット出なそうと思った。
理解しきれていない部分も多かったが、Microservices実践している人の話を聞けて、Microservicesが単なるバズワードから現実感のあるものになった気がして、本当にモチベーション上がった。 togetherはここ。

CSVで吐かれるリソース情報をelasticsearch, kibanaでグラフ化する

CSVで吐かれるリソース情報を週次でグラフ化する必要があったんだけど、毎週Excel開いてグラフ作るのはだるいので、ログ可視化周りでデファクトスタンダードになっているっぽいelasticsearch, kibanaでグラフ化することにした。

手順は次の通り。

  1. elasticsearch, kibana環境を準備する
  2. リソース情報CSVをBulk API対応のJSONに変換する
  3. リソース情報JSONをelasticsearchにバルクインポートする
  4. kibanaでインポート結果を確認する
  5. 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ボタンです。
この機能を使って、画像の切替も実現可能です。
なお、説明と画像は一切関係がありません。

toggle_brother

toggle_brother

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見るために顔を落とすのは見栄えが良くないので。

発表内容

  • 資料を作る前は、内容簡単すぎて発表する意味ないかと思ったけど、資料を作っていたら、それなりに意味のある資料を作れている気がしてきた。

今作っているアプリをとりあえず作りきって、今年中にもう一回発表したいと思う。

発表動画


Ruby / Ruby on Rails ビギナーズ勉強会 第１１回 160227 #CoEdo.rb