第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自体のステータス監視

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

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

asciinema / asciicast2gifでターミナルのアニメーションGIFをつくる

ターミナルでのコマンド実行のアニメーションGIFを作るとき、自分はasciinemaとasciicast2gifを使っています。

github.com

github.com

ターミナルのアニメーションGIFを作るツールはいろいろありますし自分でも試したのですが、今のところ使い勝手が良いのと出力されるGIFが良い感じなのでこれらに落ち着いています。

使い方

asciinemaをインストール

MacであればHomebrewでインストール可能です

$ brew install asciinema

それ以外だと pip でインストールすることになります

$ sudo pip3 install asciinema

asciinemaはDockerも用意されていてそちらも利用可能なのですが、自分は手元のコマンド環境を録画することが多いのと、自分でカスタマイズしたターミナルのままで録画したいので直接インストールしてしまいます。

asciinemaで録画

asciinema は https://asciinema.org にアップロードされる想定で作られていますが、今回は使いません。asciicastというファイルフォーマットで出力する形で録画をします。

以下のコマンドで録画が開始されます。

$ asciinema rec mycli.cast

Ctrl-D か exit で録画が終了します。mycli.cast というファイルが出力されているかと思います。

asciicast2gifでGIFに変換する

asciicast2gifもDockerが用意されているので、こちらはDockerで実行します。

$ docker run --rm -v $PWD:/data asciinema/asciicast2gif mycli.cast output.gif

オプションも充実しているので、速度やサイズなどを調整します。

これで終わりです。

では実際の流れを見てみましょう

インストールからアニメーションGIF作成まではこんな感じです。

f:id:k1LoW:20180501001604g:plain

実際にできたアニメーションGIFはこんな感じです。

f:id:k1LoW:20180501001547g:plain

という感じに asciinemaの録画をasciinemaで録画できるくらい優秀なので 是非使ってみてください。

cgroupの状況を確認するコマンドcgrpsを作った

cgroup
  • cgrps v0.5.0 から cgrps ps コマンドは削除しました
  • cgroup / cgroups 問題について下記に追記しました。それに伴いタイトルと文章も修正しました。

以前のエントリで書いたようにcgroupの状況を確認するコマンドはあります。

k1low.hatenablog.com

ごく普通のcgroupsの使い方であれば上記エントリにある systemd-cgtop systemd-cgls や lscgroup などで十分です。

しかし、 たまたまなのですが 私が関わっているプロダクト ではコンテナをフル活用しているためcgroupが大量に作成されることがあり、systemd-cgtop などではなかなか厳しいことになってきていました。

また、同じcgroup階層のサブシステムの状況は「同じグループとして」確認したいという気持ちもありました。

cgrps

というわけで、cgroupとGoの勉強がてらに cgrps というコマンドを作ってみました。

github.com

img

cgrps は以下のような特徴があります

  • cgroupの各サブシステム内の同じ階層(例えば /sys/fs/cgroup/cpu/my-cgroup-name と /sys/fs/cgroup/memory/my-cgroup-name )を同じグループとしてまとめる
  • 状況を確認できることに特化して、cgroupの操作系はない

使い方

基本的に peco などのフィルタリングコマンドとの併用を想定しています。

例えばあるcgroupで動いているプロセスを確認したいときは

$ cgrps ps $(cgrps ls | peco)

とすると peco でcgroupを絞り込んで確認ができます。

当然、cgroupの階層がわかっていれば

$ cgrps ps /my-cgroup-name

としても確認可能です。

現在は cgrps ls cgrps ps cgrps stat がありますが、今後はそれぞれの機能拡張( cgrps stat も対応サブシステムが少ない )に加えて、 cgrps top が欲しいです。あとJSON出力ですね。

勉強にちょうどいい。

余談

cgroupはファイルシステム

開発当初は https://github.com/containerd/cgroups を使っていたのですが、表示したいものを作っていくうえで痒いところに手が届かない感じだったので（そもそも使い方が違う）、結局最後は /sys/fs/cgroup 内のファイルを直接見にいく形に変更しました。

CLK_TCK

udzuraさんの便利エントリにもあるように cpuacct.stat の値を秒単位で表示するためには クロック/秒 を知る必要があります。これをcgoを使わずにどうやって取得しようかなと考えたのですが、getconf というコマンドがだいたいのディストリビューションにあることを知って、採用させていただきました。

github.com/shirou/gopsutil ++

RedHatの資料がかなり充実している

ギョーム中にpyamaさんに教えてもらいました。

リソース管理ガイド - Red Hat Customer Portal

ギョーム中もcgrpsを作っている間もずっとにらめっこしてました。

というわけで

なかなか使う機会はないかもしれませんが、cgroupsの勉強などに是非。

ところでcgroupsなのかcgroupなのか。。。 解決しました！

cgroupの状況を確認するコマンドcgrpsを作った - Copy/Cut/Paste/Hatena

便利感ある / cgroup(s?) の問題は <a href="http://tenforward.hatenablog.com/entry/20160425/1461583475" target="_blank" rel="noopener nofollow">http://tenforward.hatenablog.com/entry/20160425/1461583475</a> などご参照のこと

2018/04/26 13:02
b.hatena.ne.jp

JAWS-UG福岡#6 でロリポップ!マネージドクラウドについて発表した #mclolipop

JAWS-UG福岡：6度目もちょっと濃い目にAWSの話をしてみよう というAWSなイベントでマネージドクラウドの発表をさせてもらいました。

もともと自分はAWSをよく使っていて、いろいろなツールを作っていたこともあって、JAWS-UG福岡の中の人たちにはお世話になっていましたが、今回も「面白ければ良い」ということで発表の機会をもらえました。ありがとうございます！

さらにロリポップ!マネージドクラウド正式版リリース最速での発表を「一番最後にJOINした」自分が話すという、完全に「いいところをかすめとった」感じになっていて、ちょっと申し訳ない気持ちも。

せっかくの新参なので、外から見ていたマネージドクラウド（の理解とその誤解）と、実際のマネージドクラウドとのすり合わせができて価値が理解できるような資料を作るよう心がけてみました。

結果、様々な疑問・質問やフィードバックをもらうというありがたい状況になり、発表して良かったなと思いました。JAWS-UG懐デカい。

（このあと懇親会ではさくらインターネットの方とも濃い話ができて嬉しいことに）

より、もっとわかりやすくしていくのは今後の課題です！

ありがとうございました！