TCP Proxyを書いてPostgreSQLの通信を覗いてみる

Go

覗いてみました。

ただ見るだけなら tcpdump などを活用すれば良さそうなのですが、せっかくならプロトコルを解析した結果を出力してみたかったので、取得結果をイジれるようにTCP Proxyを書くところからはじめてみました。

TCP Proxyってどうやって書けば？というのは基本的にインターネットの情報を参考にしました。特に以下のツールのコードを参考にしました。

github.com

で、書いたのが tcprxy です。

github.com

$ tcprxy -l localhost:12345 -r localhost:1234

という、よくありそうな感じでTCP Proxyなプロセスを起動するだけのツールです。

準備

まず、localhost:5432 でPostgreSQLを起動しておきます。 tcprxy をPostgreSQLをリモートアドレス -r に指定して起動します。

$ tcprxy -l localhost:55432 -r localhost:5432

tcprxy はデフォルトで双方向の通信を hex.Dump() を使って標準出力に出力します。

あとは psql コマンドなどを使って localhost:55432 に接続して通信結果を覗いてみます。

PostgreSQLの通信を覗いてみる

まずはPostgreSQLへの接続まで

$ psql -U postgres  -h localhost -p 55432 -d testdb
Password for user postgres:
psql (10.2, server 10.4 (Debian 10.4-1.pgdg90+1))
Type "help" for help.

testdb=#

ダンプ結果が以下

00000000  00 00 00 08 04 d2 16 2f                           |......./|
00000000  4e                                                |N|
00000000  00 00 00 52 00 03 00 00  75 73 65 72 00 70 6f 73  |...R....user.pos|
00000010  74 67 72 65 73 00 64 61  74 61 62 61 73 65 00 74  |tgres.database.t|
00000020  65 73 74 64 62 00 61 70  70 6c 69 63 61 74 69 6f  |estdb.applicatio|
00000030  6e 5f 6e 61 6d 65 00 70  73 71 6c 00 63 6c 69 65  |n_name.psql.clie|
00000040  6e 74 5f 65 6e 63 6f 64  69 6e 67 00 55 54 46 38  |nt_encoding.UTF8|
00000050  00 00                                             |..|
00000000  52 00 00 00 0c 00 00 00  05 75 d4 cb 36           |R........u..6|
00000000  00 00 00 08 04 d2 16 2f                           |......./|
00000000  4e                                                |N|
00000000  00 00 00 52 00 03 00 00  75 73 65 72 00 70 6f 73  |...R....user.pos|
00000010  74 67 72 65 73 00 64 61  74 61 62 61 73 65 00 74  |tgres.database.t|
00000020  65 73 74 64 62 00 61 70  70 6c 69 63 61 74 69 6f  |estdb.applicatio|
00000030  6e 5f 6e 61 6d 65 00 70  73 71 6c 00 63 6c 69 65  |n_name.psql.clie|
00000040  6e 74 5f 65 6e 63 6f 64  69 6e 67 00 55 54 46 38  |nt_encoding.UTF8|
00000050  00 00                                             |..|
00000000  52 00 00 00 0c 00 00 00  05 d2 92 d0 67           |R...........g|
00000000  70 00 00 00 28 6d 64 35  63 66 35 39 35 66 36 63  |p...(md5cf595f6c|
00000010  34 39 34 66 64 35 66 32  66 34 37 62 62 31 31 32  |494fd5f2f47bb112|
00000020  35 30 62 35 65 65 31 31  00                       |50b5ee11.|
00000000  52 00 00 00 08 00 00 00  00 53 00 00 00 1a 61 70  |R........S....ap|
00000010  70 6c 69 63 61 74 69 6f  6e 5f 6e 61 6d 65 00 70  |plication_name.p|
00000020  73 71 6c 00 53 00 00 00  19 63 6c 69 65 6e 74 5f  |sql.S....client_|
00000030  65 6e 63 6f 64 69 6e 67  00 55 54 46 38 00 53 00  |encoding.UTF8.S.|
00000040  00 00 17 44 61 74 65 53  74 79 6c 65 00 49 53 4f  |...DateStyle.ISO|
00000050  2c 20 4d 44 59 00 53 00  00 00 19 69 6e 74 65 67  |, MDY.S....integ|
00000060  65 72 5f 64 61 74 65 74  69 6d 65 73 00 6f 6e 00  |er_datetimes.on.|
00000070  53 00 00 00 1b 49 6e 74  65 72 76 61 6c 53 74 79  |S....IntervalSty|
00000080  6c 65 00 70 6f 73 74 67  72 65 73 00 53 00 00 00  |le.postgres.S...|
00000090  14 69 73 5f 73 75 70 65  72 75 73 65 72 00 6f 6e  |.is_superuser.on|
000000a0  00 53 00 00 00 19 73 65  72 76 65 72 5f 65 6e 63  |.S....server_enc|
000000b0  6f 64 69 6e 67 00 55 54  46 38 00 53 00 00 00 31  |oding.UTF8.S...1|
000000c0  73 65 72 76 65 72 5f 76  65 72 73 69 6f 6e 00 31  |server_version.1|
000000d0  30 2e 34 20 28 44 65 62  69 61 6e 20 31 30 2e 34  |0.4 (Debian 10.4|
000000e0  2d 31 2e 70 67 64 67 39  30 2b 31 29 00 53 00 00  |-1.pgdg90+1).S..|
000000f0  00 23 73 65 73 73 69 6f  6e 5f 61 75 74 68 6f 72  |.#session_author|
00000100  69 7a 61 74 69 6f 6e 00  70 6f 73 74 67 72 65 73  |ization.postgres|
00000110  00 53 00 00 00 23 73 74  61 6e 64 61 72 64 5f 63  |.S...#standard_c|
00000120  6f 6e 66 6f 72 6d 69 6e  67 5f 73 74 72 69 6e 67  |onforming_string|
00000130  73 00 6f 6e 00 53 00 00  00 11 54 69 6d 65 5a 6f  |s.on.S....TimeZo|
00000140  6e 65 00 55 54 43 00 4b  00 00 00 0c 00 00 0d a7  |ne.UTC.K........|
00000150  05 14 5d 33 5a 00 00 00  05 49                    |..]3Z....I|

全くわからない。

簡単なクエリを実行してみます。

testdb=# SELECT COUNT(*) FROM information_schema.tables;
 count
-------
   196
(1 row)
00000000  51 00 00 00 34 53 45 4c  45 43 54 20 43 4f 55 4e  |Q...4SELECT COUN|
00000010  54 28 2a 29 20 46 52 4f  4d 20 69 6e 66 6f 72 6d  |T(*) FROM inform|
00000020  61 74 69 6f 6e 5f 73 63  68 65 6d 61 2e 74 61 62  |ation_schema.tab|
00000030  6c 65 73 3b 00                                    |les;.|
00000000  54 00 00 00 1e 00 01 63  6f 75 6e 74 00 00 00 00  |T......count....|
00000010  00 00 00 00 00 00 14 00  08 ff ff ff ff 00 00 44  |...............D|
00000020  00 00 00 0d 00 01 00 00  00 03 31 39 36 43 00 00  |..........196C..|
00000030  00 0d 53 45 4c 45 43 54  20 31 00 5a 00 00 00 05  |..SELECT 1.Z....|
00000040  49                                                |I|

クエリが見えます。これなら解析結果を出力できそうです。

PostgreSQLのプロトコルを解析してみる

PostgreSQLは通信プロトコルも含め、しっかりとドキュメント化されています（日本語化も）。

第52章 フロントエンド/バックエンドプロトコル

とりあえず今回は、簡易クエリ ( 52.2.2. ) だけを解析して出力できるようにしてみました。

52.7. メッセージの書式

クエリは先頭バイトが 'Q' になるのでそのメッセージだけ取得して、クエリ文字列の部分だけ取得してみます。

実際の解析結果は tcprxy に -d pg オプションを渡して確認できます

$ tcprxy -l localhost:55432 -r localhost:5432 -d pg

先ほどと同じようにクエリを実行してみます。

testdb=# SELECT COUNT(*) FROM information_schema.tables;
 count
-------
   196
(1 row)

testdb=# SELECT COUNT(*) FROM information_schema.columns;
 count
-------
  1775
(1 row)
$ tcprxy -l localhost:55432 -r localhost:5432 -d pg
SELECT COUNT(*) FROM information_schema.tables;
SELECT COUNT(*) FROM information_schema.columns;

クエリを取得できました。

まとめ

簡単ですが普段使っているPostgreSQLの通信を覗くことができました。

せっかくTCP Proxyを書いたので他の通信も覗いてみようと思います。

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

Go

先週、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)

Go

tbls更新情報です。

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

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

k1low.hatenablog.com

追加機能 ( ~ v0.8.2 )

MySQL対応

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

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

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

ER図作成機能

tbls コマンドを実行する環境で、Graphvizの dot コマンドが実行できる場合は、 自動で 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 を作った

Go

進捗報告です。

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

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

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

そういった課題を解決すべく、今回はデータベーススキーマのドキュメントを生成するツール 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を想定しているのでクッションもついていて安心です。バックパックを背からおろして手で持つときのハンドルが丁寧に作られていて、バスやエレベーターで手持ちのときも持ちやすいのも地味に良いです。

というわけで

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

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