Fukuoka.go#11 に参加してspf13/cobraの紹介をした #fukuokago

先週、Fukuoka.go#11 に参加しました。

fukuokago.connpass.com

どの発表も興味深く聞くことができました。主催の皆さん。発表者の皆さんありがとうございました!!

感想を1つだけあげるとしたら

どの発表も本当に面白かったのですが、個人的には @deeeet さんのAPI Gatewayの開発の話が面白かったです。

チーム内外の社のメンバーが機能開発ができるための技術選択としてのGo、そしてGopherが入りやすいように考えられた設計やコーティング

Middlewareのレイヤーを作ることでシンプルでわかりやすいアーキテクチャを維持

パフォーマンスや統一的に活用できる機能をCore packageとしてSREチームが責任をもって開発していく。それを読み込むことでその恩恵を得つつドメインに沿った機能追加ができるようにするという。プラグイン的な責務分担

Goの話というよりも、開発すたやアーキテクチャの話が実践的でほんとうに唸ってしまいました。同じものを作りたいわけではないのに、参考にできそうなことばかりでした。

LT: spf13/cobraの紹介

あと、Gopher君のぬいぐるみが欲しくて、LTを発表してきました。

作者がいらしているのは当然知っていました*1(笑

spf13/cobraフルスタック過ぎる感じで便利だし、ちょうど @deeeet さんと話すきっかけにもなるしいいかも。と。

もっとGo力をつけていこうと思いました。

*1:自分が初めて作ったGo製CLIツールはtcnksm/gcliを使って進めました

データベースドキュメント生成コマンド tbls 更新情報 ( MySQLに対応/ER図自動生成/リレーション・コメント追加機能 etc)

tbls更新情報です。

やっと、もともと実装したいと思っていた機能をすべて実装できましたので紹介します。

なお、tblsコマンドについては以下のエントリに書いています。

k1low.hatenablog.com

追加機能 ( ~ v0.8.2 )

MySQL対応

まずはPostgreSQLを対応しましたが、MySQLの要望もあったので対応しました(もともと対応予定でしたが要望をいただいたので急ぎました)。

tbls doc mysql://user:pass@hostname:3306/dbname ./dbdoc

というような形でPostgreSQLと同じようにデータベースドキュメントを生成できるようになっています。

ER図作成機能

tbls コマンドを実行する環境で、Graphvizdot コマンドが実行できる場合は、 自動で dot コマンドを利用して以下のようなER図を生成してドキュメントに配置するようにしました。

f:id:k1LoW:20180610230630p:plain

ER図があったほうが視覚的にわかりやすいので、以外に便利です。

リレーション・コメント追加機能

tblsは外部キー制約を見てテーブル間のリレーションを判断します。

しかし、スキーマによっては、ORMにリレーション設定を任せていたりその他様々な理由で外部キーを張ることができないことがあると思います。

そのようなスキーマでも、テーブル間のリレーションをER図やドキュメントのテーブル情報に付与したい場合のために、追加でリレーションをtblsコマンドに渡すことができるようにしました。

具体的には --add オプションにYAMLファイルのパスを渡します。

$ tbls diff mysql://user:pass@hostname:3306/dbname --add path/to/additional_data.yml

追加するYAMLファイルは以下のように指定します。

---
relations:
  - # logsテーブルにおける FOREIGN KEY(user_id) REFERENCES users(id) と同様
    table: logs
    columns:
      - user_id
    parentTable: users
    parentColumns:
      - id
    def: logs->users
  - # logsテーブルにおける FOREIGN KEY(post_id) REFERENCES posts(id) と同様
    table: logs
    columns:
      - post_id
    parentTable: posts
    parentColumns:
      - id

また、--add オプションで渡すYAMLファイルで、テーブルコメントやカラムコメントも上書き追加可能です。

コメント修正のためにSQLを流す必要がなくなりますし、通常のテーブルだけでなくVIEWテーブルのカラムにもコメントが付与できるので便利です。

comments:
  -
    table: post_comments
    tableComment: 各投稿についたコメントの詳細確認用VIEWテーブル
    columnComments:
      post_user: 投稿したユーザ名
      comment_user: コメントしたユーザ名

テーブル定義(DDL)をドキュメントで確認できるように

PostgreSQLはVIEWテーブル、MySQLはテーブルとVIEWテーブルのテーブル定義をドキュメントから確認できるようにしました。

例えばVIEWテーブルTable Definition というリンクがあった場合、クリックするとテーブル定義を確認できるようになっています。

f:id:k1LoW:20180610233020p:plain

というわけで

更新が激しいサービスのデータベースやドキュメントのなかったデータベースにたった1コマンドでデータベースのドキュメントを生成できるtbls、是非使ってみてください!

CIフレンドリなデータベースドキュメント生成コマンド tbls を作った

進捗報告です。

ドキュメントの更新が追いつかない問題を解決したい

活発なプロジェクトでは、システムのソースコードだけにとどまらず、データベース設計やアーキテクチャもどんどん変化していきます。

そういった時、一度作ったドキュメントを追従させていくのは至難の技です。主に優先順位とかモチベーションとかの理由で。

そういった課題を解決すべく、今回はデータベーススキーマのドキュメントを生成するツール tbls を作ってみました。

github.com

これは何?

tbls は対象のデータベースに接続してGitHub FriendlyなMarkdownスキーマのドキュメントを生成するツールです。

主にGitHubにドキュメントごとコミットされることを想定しており、GFMフォーマットなだけでなく、エントリページが README.md であることも特徴です。

使い方

ドキュメントの生成

tbls doc で対象ディレクトリに一気にMarkdownフォーマットでデータベースのドキュメントを生成します。

$ tbls doc postgres://user:pass@hostname:5432/dbname ./dbdoc

既に存在する場合は --force オプションを利用して上書き可能です。

たったこれだけでこのようなドキュメントが生成されます。

これだけで随分ドキュメント運用が楽になります。

CIとの連携

個人的にはコレがこのツールの特徴だと思っている(そしてもっと改善していきたいところ)のですが、tbls にはCIと連携することを想定したコマンドがあります。

先ほども書いたように、活発なプロジェクトに対してのドキュメントの追従は課題です。

ドキュメントを生成するコマンドを作っても、そのコマンドを打たなかったら結局は実際のデータベースと離れていきます。

それを解決するためにCIに組み込むコマンドとして tbls diff を用意しました。

これは対象データベースと既に作られたドキュメントのdiffを出力します。

$ tbls diff postgres://user:pass@hostname:5432/dbname ./dbdoc

たったコレだけをするコマンドですが、(Go製であるがゆえの)シングルバイナリであることからCIとの連携が非常にしやすくなっています。

例えば .travis.yml に組み込むとしたらこんな感じでしょう。

script:
  - DIFF=`tbls diff postgres://user:pass@localhost:5432/testdb?sslmode=disable ./dbdoc` && if [ ! -z "$DIFF" ]; then echo "document does not match database." >&2 ; tbls diff postgres://user:pass@localhost:5432/testdb?sslmode=disable ./dbdoc; exit 1; fi

Makefileにコマンドとして組み込むとしたらこんな感じでしょうか。

doc: ## Document database schema
    tbls doc postgres://user:pass@localhost:5432/testdb?sslmode=disable ./dbdoc

testdoc: ## Test database schema document
    $(eval DIFF := $(shell tbls diff postgres://user:pass@localhost:5432/testdb?sslmode=disable ./dbdoc))
    @test -z "$(DIFF)" || (echo "document does not match database." && tbls diff postgres://user:pass@localhost:5432/testdb?sslmode=disable ./dbdoc && exit 1)

テストでは大抵データベースのマイグレーションも走っていると思います。そのテスト環境とうまく連携すればドキュメントが更新されているかどうかもテストすることができます。

サポートデータベース

現時点では残念ながらPostgreSQLのみですが、MySQLも近いうちにサポート予定です。

これでデータベースのドキュメントが本番と違うということはなくなるはず。

ドキュメントの更新をCIでチェックさせるというアイデア

これは余談なのですが、「ドキュメントの更新をCIでチェックさせる」というのはawspecのメンテナンスを続けるうえで得たアイデアです。

awspecのテスト対象はあのAWSです。物凄い勢いで機能が追加されています。そういった意味でawspecはメタ的な作り方をしており、実は、AWSによる新パラメータの追加・削除と共にawspecは勝手に対応していきます。

ただ、その機能ドキュメントを追従させるのが難しかったのでそのためのドキュメント生成をコマンド化し、そしてCIで回しています。

github.com

現在ではTravis CIのCRON機能を使っていて、定期的に "Broken" とメールが飛んできます。

f:id:k1LoW:20180521225503p:plain

というわけで

MySQLもさっさと対応して、「データベースのドキュメントがないプロジェクト」「データベースのドキュメントが古いプロジェクト」を撲滅していこうと思います!

第2回Web System Architecture研究会@福岡 に参加した #wsa研

まさに「Webシステムのアーキテクチャ」で悩んでいることがあって、どうしても「これだ!」という情報を探すことができなかったところ、Web System Architecture研究会が福岡で開催されるということで渡りに船とばかりに参加してきました。

発表内容

予稿

github.com

発表資料

発表した内容を端的に説明すると「Webシステム前提において、トラブルシュートのために生ログにアクセスするためのログ保存の方法として、パス構造にリクエスト-レスポンスの伝搬情報を埋め込んだらどうだろう?」という提案でした。

参加して発表してみて

感想は、以下のツイートに集約されています。

実はhayabusa、第1回WSA研でも発表されていた内容だったらしく、完全に自分の予習不足でした。。。。

ただ、正直、予習不足で良かったです。そうでないと発表はしなかったかもしれないし、自分のアイデアに対して様々な深い意見をもらうこともなかったので。

hayabusaとhayabusaのアイデア(もしくはその一部)は、自分が解決したいことに使えないかずっと考えています。まずは触ってみよう。

発表についても、リクエスト-レスポンスの伝搬情報の置き換えについて、自分の発表では「有向グラフ」とまででしたが、「DAG(有向非巡回グラフ)に落とし込むことで、例えば検索面で先行研究や実装でできることの世界が広がるのでは」というアドバイスもいただきました。そうなのか、DAG。

本当に予想以上の成果で、強い気持ちで参加表明して良かったです。

ちゃんとやるぞ!!

cgrpsの実践を考える

(主に自分に)来たる大量コンテナ時代に向けて作ったcgrpsですが、試験運用をしていて気づきがありました。

github.com

今回は新たに作成したサブコマンド cgrps pids について紹介します。

cgrps pids を使って他のコマンドと連携する

実際に使ってみて気づいたことに

自分で作ったcgrps psコマンドよりpsコマンドのほうが強力

という当たり前といえば当たり前の事実が判明しました。

で、よく考えたらpsコマンドはPIDを引数に渡せるので、cgroup単位のPIDのリストを出力するコマンドを作成して他のコマンドとパイプで連携するようにしました。

ということで cgrps ps を削除。新たに cgrps pids を作成しました。

ps との連携

psコマンドは --pid (-p) オプションにPIDを複数渡すことができます。

cgrps pids は複数のcgroupを引数に渡せるので、cgrps ls -> [peco] -> cgrps pids の結果をpsコマンドに渡すことで絞り込んだ結果を得ることができます。

$ ps u --pid $(cgrps ls | peco | cgrps pids | xargs)

pidstat との連携

pidstatコマンドも-p オプションにカンマ区切りでPIDを複数渡すことができます。

任意のcgroupのstatを5秒間隔で取得するとしたら以下のようなコマンドで確認可能です。

$ pidstat -dru -h -p $(cgrps ls | peco | cgrps pids | xargs | tr ' ' ',') 5

lsof との連携

lsofコマンドも-p オプションにカンマ区切りでPIDを複数渡すことができます。

$ lsof -Pn -i -a -p $(cgrps ls | peco | cgrps pids | xargs | tr ' ' ',')

というわけで

cgrpsの実践を試した結果、 cgrps pids を作成することになりました。

少しは「1つのことをうまくやる」「協調して動く」UNIX哲学なコマンドに近づけたかと思います。

MISSION WORKSHOP The Rhakeを使い始めている

2ヶ月ほどになりますがバックパックをMISSION WORKSHOPのThe Rhakeに変えて使い始めています。

f:id:k1LoW:20180506190535j:plain
左がThe Rambler、右がThe Rhake

Tha Rambler

もともとは同じMISSION WORKSHOPのThe Ramblerを愛用していました。つまり前もMISSION WORKSHOPです。

missionworkshop.com

これは自分が「モノを丁寧に扱えない人」という自覚があって、シンプルで使いやすく「かつ丈夫な」バックパックを探していて知りました(ちなみにこのTogetterがキッカケだった気がします)。

見た目のカッコよさも耐久性もバッチリです。

メインのラインナップは多少大きいですが、大きいくらいが好きなのでむしろ好印象なブランドです。


Rambler Roll Top Backpack // Pikey Science

vimeo.com

The Ramblerの魅力はなんといっても容量を拡張できることで、普段は22Lなバックパックとして使いつつ、帰り道にビールを大量(24缶くらい)に買い込んで、容量をその場で拡張して雑に詰め込むということも余裕で対応できました。

拡張状態も耐久性に不安はなく、さらに防水なので「何も考えず」使えます。

あと出張時も自分のスタイルだと2泊3日くらいは余裕で、ホテルに中身を出してしまえば普通のバックパックとして持ち運べます。

The Rhake

で、最近はThe Rhakeをメインに使っています。


The Rhake

vimeo.com

なぜ変えようかと思ったかというと、殆どはノリですが、自分のバックパックの使い方を改めて考えたからです。

自分のバックパックの用途としては会社への通勤がメインなのですが、そこに必ずノートPCの持ち運びがあります。

人によってはPCは持ち運ばないという人もいますが、自分は「ノートPCが手元にないと不安な人」なので、プライベートでもプライベートのノートPCを持ち運びます。それがたとえ15inch Macbook Proでも、です。

The Ramblerも背面に位置するポケットにノートPCを入れていたのですが、その場所がその用途ではなかったのと、充電器やケーブルといったガジェットも1つの場所に雑にいれている状態でした。

そして、実はそれ以外を入れることがあまりない(書類とか上着をときどき突っ込むくらい)

そうなってくると「ノートPCを入れることを想定している」「ガジェットを入れることを想定している」「丈夫な」バックパックのほうが通常状態では良さそうということになってきます。

そして、たまたまMISSION WORKSHOPのサイトをみたら当時The Rhakeがプレオーダーをしていたので、そのまま購入ボタンを押してしまったという感じです。

使い勝手とか

使い勝手はとても良いです。

The Ramblerから容量拡張機能をなくなった感じですが、それ以外の良さは何も失われていないです。

ポケットが増えたので自然とガジェットを整理できます。ただ、簡単な取り出しは想定していないので、そういうことをしたい人には向いていないかもしれません。

背面ポケットもノートPCを想定しているのでクッションもついていて安心です。バックパックを背からおろして手で持つときのハンドルが丁寧に作られていて、バスやエレベーターで手持ちのときも持ちやすいのも地味に良いです。

というわけで

非常に満足していて、バックパックに関しては完全に物欲がなくなっています。壊れない限りずっと使いそうです。

今は小さい小回りが効くボディバッグが欲しいです。

faultlineのGitHub連携機能をGH:Eに対応した / faultline-go をリリースした

faultline更新情報です。

faultlineのGitHub連携機能をGH:Eに対応しました

faultlineのGitHub連携機能をGitHub Enterpriseに対応させました。faultline v1.2.0 から利用可能です(ただ、バージョンアップされる方は最新にすることをおすすめします)

具体的には以下のURLに説明がありますが、GitHub連携の設定項目に新たに endpoint が増えました。

faultline/notifications.md at master · faultline/faultline · GitHub

GH:Eのホスト名が https://ghe.example.com だった場合は、指定するendpointは https://ghe.example.com/api/v3 になります。

faultline-go をリリースしました

周りでGoのエラートラッキングのニーズが高まっていたのと、少しづつGoがわかるようになってきたので、faultline-goをgobrakeからフォークして作成しました。

github.com

注意点として、 faultline-go の利用のためには faultline本体を v1.3.0 以上にする必要があります 。(原因はスキーマ設定のミスです🙇)

今後faultlineでやりたいこと

faultlineは一度デプロイするとずっと稼働できてしまうので、更新をサボりがちになりますね。。。

現時点でやっていきたいなと思うのは

  • faultlineのNodeバージョンのアップデート
  • 各言語用のライブラリのアップデート
  • バックエンドで活用しているDynamoDB AutoScalingのサポート
  • faultline自体のステータス監視

などです。ここらへんを今まで同様に「運用レス」ファーストでやっていきたいと思っています。

どうぞよろしくお願いします。