ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

2018年6月振り返り

6月も終わった。

blog.chaspy.me

技術

  • (できてない)railsで簡単なサービスを実際に作る
  • OSレイヤーの学習
    • (半分読んだ)[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識
    • (読んでない)Goならわかるシステムプログラミング
    • (読んだ)なるほどUnixプロセス ― Rubyで学ぶUnixの基礎

blog.chaspy.me

  • 新しい会社に向けたキャッチアップ
    • 残りとしてあげた部分は結局できてないが、やりながら覚えていく感じになってる

登壇

目標通り、できた。

blog.chaspy.me

音楽

2nd albumリリースがもろもろの都合でできてない。2nd liveノーミスはできなかったなー。

英語

  • (できた)Seeking SREから2つ

blog.chaspy.me

blog.chaspy.me

  • (できた)英語Writing月4本

medium.com

medium.com

medium.com

dev.to

夏休みの宿題さながら月末にバタバタ追い込んだし、最後についてはdev.toに初投稿、qiitaに書いたメモを移植した感じで済ませたのは反省。

健康

一番ダメ。海外旅行で普通にリバウンドしてるわ。あと結局運動してない。

f:id:take_she12:20180703022320p:plain

f:id:take_she12:20180703021640p:plain

お金

使途不明金なし、マネーフォワードでしっかり管理できてます。可視化はできたので次はどの分野をどれぐらい減らすか、を目標に設定していこう。

振り返り的な

6月は半ば10日は海外旅行に、そして21日からは新会社入社ということであまり時間が取れなかったのもあり、予想通りあまりできませんでした。とりあえずカイゼン・ジャーニー・ライトニングトークスでLT登壇できたのはよかった。これまでいろいろ改善とか組織とかチームとかやってきたことをシメておきたかったので。

英語については今まで1mmもしなかったのがようやく何かしらするようになったのでやっぱり必要性にかられるって大事だなーと思いました。やるぞー。

健康がやばい。これからもやばそう。いくらでも言い訳できるし。可視化しても結果出さなきゃダメなわけで。どうやって毎日運動するように自分を落とし込めるかが課題。

お金に関しても可視化まではうまくいっているので、分析して改善をして効果を見ていきたいと思う。

ついでに2Qも終わったので2Q目標も見ておく。

blog.chaspy.me

うーん、技術的なところは半分ぐらいはやったかなーでもあとは実践で入って必要なものを埋めていくって感じ。

健康に関しては全然未達成って感じです。四半期ごとの目標あんまり意味ない気がしてきた。

次のエントリで7月の目標立てます。

おまけ

書いた記事

blog.chaspy.me

ブログは18件。うち8件が海外ひとり旅日記。あとは勉強会したとか、退職エントリとか、入社して感じたこととか。シュっと書いてるのがいくつかって感じ。

あとはqiitaに3本。これも本当にメモな感じでシュっと書いただけ。qiitaには仕事でぶつかったちょっとしたTipsを書いていこうと思っている。

qiita.com

qiita.com

qiita.com

読んだ本

いい加減読書メーターのしょぼいまとめやめたい。別のサービス使おうかなあ。

美意識の本と外国語学習の科学の本はよかった。

6月の読書メーター
読んだ本の数:11
読んだページ数:2633
ナイス数:37

人生の勝算 (NewsPicks Book)人生の勝算 (NewsPicks Book)感想
あんまり面白くなかった。「仕事の基本は思いやり」は同意。
読了日:06月30日 著者:前田 裕二
世界のエリートはなぜ「美意識」を鍛えるのか? 経営における「アート」と「サイエンス」 (光文社新書)世界のエリートはなぜ「美意識」を鍛えるのか? 経営における「アート」と「サイエンス」 (光文社新書)感想
非常に説得力のある本だった。個人的に、言葉、言語化は大切だと思うし、好きだけど、それの限界を感じることも多く、一方で感覚的なものに対する信頼も年々増している。ビジネスという現場においても、大企業では上層部の意思決定のために多くの情報を提供しなければならず、現場が疲弊しているうちに市場が変わるという現場を見てきた。ビジネスの現場でも、あるいは一個人が生きる上でも、論理"だけでなく"美的感覚あるいはビジョンが必要だというのは重要なメッセージだと思う。
読了日:06月30日 著者:山口 周
外国語学習の科学―第二言語習得論とは何か (岩波新書)外国語学習の科学―第二言語習得論とは何か (岩波新書)感想
この本で書かれている分析はまだわかっていないことも多いが、感覚的に一致することも多いので自分自身の学習に反映させたい。文法/言語が完璧じゃないことを踏まえつつ、まず生の英語に大量に触れて感覚をアップデートし、その上でアウトプットをちゃんとしていく。補助的に(?)発音/単語のトレーニングは学習としてやる、というスタイルでやっていこうと思う。
読了日:06月30日 著者:白井 恭弘
インターネット的 (PHP文庫)インターネット的 (PHP文庫)感想
まさにこの本でかかれている内容こそが「インターネット的」であり、メタな本になっていて非常に面白いです。インターネットによって多種多様な表現が、ビジネスが可能になるが、エッジの人間も、市場となる人間もたいして変わらない。その中でどう生きるのか?論理/言語で表現できるところじゃなくて、感情、魂といったところがより重要になるし、かっちりしなくてもいい、不完全でもいい、より自由に生きれるけど、発信が必要で、それをしないと自由を得づらくなっていくかもしれない。それがインターネット的に発信されている本。面白かった。
読了日:06月30日 著者:糸井 重里
松浦弥太郎の仕事術 (朝日文庫)松浦弥太郎の仕事術 (朝日文庫)感想
「おとなのきほん」をベースに、仕事に対する考え方もいいですね。停滞しないよう、努力・勉強を続け、"ちゃんと"成果を出す。約束を守る。  時間を守る。  相手を喜ばせる。
読了日:06月30日 著者:松浦弥太郎
おとなのきほん 自分の殻を破る方法おとなのきほん 自分の殻を破る方法感想
自分と近い考えも多く、追いかけたい、目指したい50代の、「おとな」だなぁと思った。20代は形だけのおとなで、30を目前に、何か違うな、30以降の「おとな」ってなんだろう?ってことを漠然と考え始めたときのこの本と出会い、なるほど参考になる点がたくさんあった。美学、哲学は各個人違うにせよ、それを持ち、安定と変化を、確実に行う、そんなおとなになりたいと思った。
読了日:06月20日 著者:松浦 弥太郎
DTMerのためのド派手なバンドアレンジがガンガン身に付く本DTMerのためのド派手なバンドアレンジがガンガン身に付く本感想
ポップスのアレンジとして、参考になる。歌えるフレーズを散りばめることと、それに関して、シナジーとプライオリティを考えることは大切だと思う。
読了日:06月07日 著者:熊川 ヒロタカ,石田 ごうき
世界でいちばん旅が好きな会社がつくった ひとり旅完全ガイド世界でいちばん旅が好きな会社がつくった ひとり旅完全ガイド感想
はじめてひとりで海外旅行をするときに一通り読んでおくと、才芸元の心構えと準備ができると思う。
読了日:06月06日 著者:TABIPPO
情報を活かす力 (PHPビジネス新書)情報を活かす力 (PHPビジネス新書)感想
直近に読んだ佐藤優との僕らが毎日やっている最強の読み方―新聞・雑誌・ネット・書籍から「知識と教養」を身につける70の極意と重複が多かった * 銀の弾丸はない。インプットし、思考し、アウトプットして、ブラッシュアップしていって自分の身にする。そして問題意識を持てばまたそれに関連するインプットをする。それを繰り返すしかない。
読了日:06月05日 著者:池上 彰
会話もメールも 英語は3語で伝わります会話もメールも 英語は3語で伝わります感想
3語にするというよりは、明快なコミュニケーションをとるための取捨選択を促してくれる、良い本だと思った * 実際英会話するときは、相手が自分の言葉を待ってくれてる。具体的で、明快な言葉を、結論から先に出す、という意識だけでも違ってくると思う
読了日:06月05日 著者:中山 裕木子
ファーストラヴファーストラヴ感想
環菜が受けたことは救えないし、やったことも救えない。もう戻れないところからはじまる物語は、少しは環菜を救ったのだろうか。自分と向き合っていいことに気づけたことですら、救いかもしれない。償ったあとの8年後に彼女が自分の気持ちとともに生きられることを願う。 由紀と迦葉の関係性、それがファーストラヴだったんだと思う。謝れない。何もなかったことにしたい。なんで男と女になってしまったんだとすら思う2人は、男と女であり、信頼があり、信用があり、絆があった。死ぬまで言えない真実を抱え込んだ関係、尊いと思う。
読了日:06月04日 著者:島本 理生

読書メーター

「Seeking SRE Chapter 11. Immutable Infrastructure and SRE」メモ

はじめに

Seeking SREで気になる章を読んでいます。

Sre in Practice

Sre in Practice

前回はサービスをメッシュしていました。

blog.chaspy.me

今回はImmutable Infrastructureがテーマ。

結論、あんまり真新しいことは言っておらず、「Immutable Infrastructure最高!!!いろんな面で!!!」って感じで、まぁ内容も確かになって感じでした。

個人的にはConfiguration Managent Tool(like Chef, Puppet)との比較がされていて、そちらと対するようなことを言っていて、別に対立するものではなく両立するものでは?と思いました。あくまでアプリケーションの話だろうけど。周辺のインフラの設定に対してはどういう考えなんだろう。そこはConfiguration Managent Toolを使うべきだと思うけどなぁ。

あとは利点ばかりではなく(たった2つだけど)不利な点も述べられていてよかった。まぁそりゃそうだって感じだけど。ここでデータベースが出てくるってことはやっぱりELBみたいなものの設定変更もイメージに固めてしまえって感じなのかなぁ。ELB自体もイメージから再作成する感じで。まぁ悪くはないけど、設定変更して再起動するだけ、であれば別にConfiguration Managent Toolで十分感はある。

では以下簡単なメモ。

Chapter 11. Immutable Infrastructure and SRE

  • Immutable Inftastractureは大規模なサーバを管理するコストを減らしたよ
  • システム内の変数を減らして、同一のサーバを作り出すことで変更可能性を高めたよ

Scalability, Reliability, and Performance

  • SREは大変だけど、Immutable Infrastractureの効果は絶大だよ
  • 小さなイメージに必要なソフトウェアをインストールしたものをリリースし、その後Puppet, Chef, SSHなどあらゆる方法でも一切変更がされない方法をImmutable Infrastractureというよ。
  • Immutable Infrastructureはスケーラビリティとパフォーマンスを提供するよ。手動で数十台なら変更できたとしても、100台、1000台は骨が折れるし、エラーを起こしがちだけど、Immutable Infrastactureであればそれを回避できるよ。
  • ChefやPuppetのような構成管理ツールは最初はうまくいくけど、規模が大きくなると、特に動的に拡張するときにうまくいかなくなるよ。

Failure Recovery

  • Immutable infrastructureは障害からすぐに復旧するのにも役立つよ。ハードウェア障害が起きてもイメージからすぐに再作成すればいいからね。加えてNetflixのChaos Monkeyテストのように耐障害性を高める取り組みもできるよ。

Simpler Operations

  • Immutable infrastructureであれば変更操作もシンプルになるよ。だって新しいものに置き換えるだけだから、状態変化に気を使う必要がなくなるよね。

Faster Startup Times

  • Immutable infrastructureであれば、ビルドには時間がかかるけど、起動時間ははるかに短縮できるよ。このおかげで、短い起動時間の範囲のみ予想すればよく、スケールアウト/ダウンが容易かつ効果的になるよ。

Known State

  • SREやセキュリティーチームにとってもImmutableでないサーバの管理は懸念がたくさんだよ。

Continuous Integration/Continuous Deployment with Confidence

  • Immutable infrastructureでない場合、微妙な変更差分がデプロイの失敗を招き、「テスト環境ではうまくいったんだ!」ということを起こしかねないよ。Immutable infrastructureであれば、Blue/Green Deploymentによってロールアウトとロールバックがスムーズにできるからいいよ。

Security

  • セキュリティの観点でもImmutable infrastructureは大切だよ。
    • 一時的にインストールしたライブラリがあったりして脆弱性を放置してしまうことを防ぐ
    • セキュリティパッチの適用も通常のデプロイと同じフローで行えるから安全
    • 何よりKernelのアップデートのような再起動を伴うパッチ適用も、事前にインストールした状態で配れるから安全だし速いよ

Multiregion Operations

  • 複数リージョンでもImmutable infrastructureであれば複製が容易だよ。構成管理だと難しいよ。

Release Engineering

  • 開発者にとってインフラの設定変更はおそろしいものであり、運用者のレビューなしでは適用できず、設定管理ツールが持つ言語を習得する必要があるよ。Immutable infrastructureであればこういった懸念事項はなくなるよ。

Building the Base Image

  • immutable infrastructureを行う最初の一歩は良いイメージを作ることだよ。
  • 小規模なサービス(shop)であればLinux Dist.のイメージを使うといいよ。
  • それなりに規模のあるサービスであれば、
    • 不要なパッケージを取り除き、
    • セキュリティアップデートがされ、
    • 共通ライブラリや内部で使うパッケージをインストールされたイメージを作るといいよ。
  • 新しいイメージを展開するときは、優先度の低いサービスに対して、カナリアでリリースするといいよ。

Deploying Applications

  • 必要なパッケージはベースイメージにインストールされ、展開するコードも何らかのパッケージングシステムにより更新されるよ。

Disadvantages

  • 永続的なデータレイヤーにはImmutable Infrastructureの適用は難しいよ。1台ずつ変更すべきで、構成管理の方法が向いてるよ。
  • イメージの更新に時間がかかるのも問題だよ。開発者がちょっとした変更を行うのにビルドを待つのはやりたくないよね。一時的に開発環境へのコードの変更を容易にすることでバランスをとりたいよね。

Conclusion

  • 導入できたら開発者はよりプロダクト開発に集中でき、アプリケーションの展開時間を短縮でき、信頼性のあるインフラを実現できるね! :+1

「なるほどUNIXプロセス」を読んだ

はじめに

読んだ。

tatsu-zine.com

ずいぶん前に買っていて、途中までやって放置していた。3時間ほどで読み通せた。 モチベーションとしては、「プロセス」って正直よくわかってないな、と思ったから。そのあたりをちゃんと学ぼうと思った。 コンテナを使うことが当たり前になった今、コンテナはプロセスだーって言っても、そもそもプロセスって何なのか。こういうOSレイヤーの知識は長く活きるので、学習効果が高いと思い、最近はこのあたりを学んでいきたいと思っている。

感想

プロセスとはUNIX上の全てのプログラムの実行単位としての抽象概念であることがわかった。

この本はUNIXプロセスの様々な挙動をRubyプログラムから試す本である。さくさく進めて気持ちいいし、著者のユーモアの効いた表現が読んでいて楽しい。ただその特性からRubyプログラムを深く理解するものでも、UNIXプロセスの詳細を理解できるものでもなく、あくまでRubyプログラマUNIXプロセスの仕組みを理解するための最初の一歩を手助けしてくれる本である。必要に応じて別のサイトを参考にしながら進めたほうがいい。

副読書としてはLinuxのしくみのプロセスの部分に先に目を通しておくと良さそうだ。

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

この本には付録がついている。おそらく実際のアプリケーションを通じた応用的な内容だと思う。現職でもWebサーバや非同期ジョブシステムは使っているので、また別の機会に学ぶ。

  • 付録
    • Resque
    • Unicorn
    • preforkサーバ
    • Spygrass(学習用アプリ)

以降は動かしながらのメモ。

3章 すべてのプロセスにはIDがある

rubyプロセスのid

irb(main):001:0> puts Process.pid
12512
=> nil

psで確認

$ ps -p 12512
  PID TTY           TIME CMD
12512 ttys001    0:00.17 irb

4章 プロセスには親がいる

irb(main):002:0> puts Process.ppid
9825
=> nil

irbプロセスの親プロセスはbash

$ ps -p 9825
  PID TTY           TIME CMD
 9825 ttys001    0:00.15 -bash

5章 プロセスにはファイルディスクリプタが ある

Unix の世界では「すべてがファイルである」。これは Unix の哲学の一つだ。

ファイルディスクリ プタはプロセスとともに生き、プロセスとともに死ぬ運命にある。

/etc/passwdを開いたときのファイルディスクリプタ番号を取得する。

irb(main):003:0> passwd = File.open('/etc/passwd')
=> #<File:/etc/passwd>
irb(main):004:0> puts passwd.fileno
9
=> nil

このファイルを閉じないまま、/etc/hostsを開く

irb(main):005:0> hosts = File.open('/etc/hosts')
=> #<File:/etc/hosts>
irb(main):006:0> puts hosts.fileno
10
=> nil

1つ増える。

クローズするとファイルディスクリプタ番号は再利用される。

irb(main):005:0> hosts.close
=> nil
irb(main):006:0> profile = File.open('/etc/profile')
=> #<File:/etc/profile>
irb(main):007:0> puts profile.fileno
10
=> nil

通常、ファイルディスクリプタ番号の最小は3であり、0, 1, 2は標準入力、標準出力、標準エラー出力に割り当てられている。

irb(main):008:0> puts STDIN.fileno
0
=> nil
irb(main):009:0> puts STDOUT.fileno
1
=> nil
irb(main):010:0> puts STDERR.fileno
2
=> nil

第6章 プロセスにはリソースの制限がある

1プロセスあたりのファイルディスクリプタ上限を調べる。

irb(main):011:0> p Process.getrlimit(:NOFILE)
[4864, 9223372036854775807]
=> [4864, 9223372036854775807]

ソフトリミットとハードリミットが得られる。

ちなみにOSのファイルディスクリプタ上限は以下の通り、256。こっちのほうが少ない。

$ sudo launchctl limit
Password:
    cpu         unlimited      unlimited
    filesize    unlimited      unlimited
    data        unlimited      unlimited
    stack       8388608        67104768
    core        0              unlimited
    rss         unlimited      unlimited
    memlock     unlimited      unlimited
    maxproc     709            1064
    maxfiles    256            unlimited

第7章 プロセスには環境がある

ここでいう「環境」とはいわゆる「環境変数」のことだ。環境変数はキーとバリューが 対になっており、プロセスで使えるデータを保持している。

$ MESSAGE='wing it' ruby -e "puts ENV['MESSAGE']"
wing it

ENV には Hash のようにアクセスできる API が用意されているが、実際には Hash オ ブジェクトではない。

第8章 プロセスには引数がある

$ cat /tmp/argv.rb
p ARGV
$ ruby /tmp/argv.rb foo bar -va
["foo", "bar", "-va"]

前章で紹介した ENV は Hash オブジェクトではなかったが、ARGV は普通の Array だ。

所感:引数はプログラムのものと思っていたが、プロセスの概念だったのははじめて知った

第9章 プロセスには名前がある

プロセスのレベルで情報を伝えるための仕組みは二つある。一つはプロセス名。もう一 つは終了コードだ。

RubyではPROGRAM_NAMEというグローバル変数に格納されている。

irb(main):001:0> puts $PROGRAM_NAME
irb
=> nil
irb(main):002:0> puts Process.pid
13146
=> nil
irb(main):003:0> $PROGRAM_NAME = "irbirb"
=> "irbirb"

この変数を変更すれば、psコマンドでも変更が確認できる。

$ ps -p 13146
  PID TTY           TIME CMD
13146 ttys001    0:00.17 irbirb

第10章 プロセスには終了コードがある

プロセスが終了時にこの世に残す最後のしるし、それが終了コードだ。あらゆるプロセ スは、正常終了か異常終了かを示す終了コード値(0-255)と共に終了する。

  • Kernel#exit: デフォルトでは終了コード0を返す。任意の終了コードを返すこともできる。
  • Kernel#exit! デフォルトでは終了コード1を返す。任意の終了コードを返すこともできる。Kernel#at_exit で定義されたブロック は実行されない。
  • Kernel#abort デフォルトでは終了コード1を返す。メッセージを渡すことができ、STDERRに出力される。
  • Kernel#raise デフォルトでは終了コード1を返す。呼び出し元に送出される。メッセージを渡すことができ、STDERRに出力される。
irb(main):004:0> exit
$ echo $?
0
$ irb
irb(main):001:0> exit!
$ echo $?
1

第11章 プロセスは子プロセスを作れる

子プロセスは親プロセスで使われているすべてのメモリのコピーを引き継ぐ。親プロ セスが開いているファイルディスクリプタも同様に引き継ぐ。

irb(main):001:0> puts "parents process pid is #{Process.pid}"
parents process pid is 13273
=> nil
irb(main):002:0> if fork
irb(main):003:1> puts "entered the if block from #{Process.pid}"
irb(main):004:1> else
irb(main):005:1> puts "entered the else block from #{Process.pid}"
irb(main):006:1> end
entered the if block from 13273
=> nil
entered the else block from 13286
irb(main):007:0> => nil

何が起きたのか?

  • forkは子プロセスを生成し、1つは呼び出し元に、1つは子プロセスに返る
    • 親プロセスに対しては、生成した子プロセスのpidが返す
    • 子プロセスではforkはnilを返す
irb(main):001:0> puts fork
13383
=> nil
irb(main):002:0>
=> nil

第12章 孤児プロセス

親プロセスが死んだら、子プロセスには一体何が起きるのだろうか? 端的に言えば「何も起きない」。どういうことかというと、オペレーティングシステム は子プロセスを特別扱いしない。だから親プロセスが死んでも子プロセスは生き続ける。 親プロセスは死ぬ時に子プロセスを道連れにしない。

第13章 プロセスは優しい

CoW は fork(2) で子プロセスを生成するときにリソースを節約できるのがとても便利 だ。親プロセスの物理メモリを一切コピーしなくて構わないので、fork(2) は速い。子プ ロセス側で必要になるデータだけコピーすればよく、残りは共有すればいいのだ。

第14章 プロセスは待てる

Process.wait は何をしたのだろうか? Process.wait は、子プロセスのどれ か 1 つが終了するまでの間、親プロセスをブロックして待つ。

Process.wait には Process.wait2 という親戚がいるん だ! どうしてこんな紛らわしい名前なのだろうか? だが、戻り値(pid)を 1 つ返すの が Process.wait で、2 つ(pid と終了ステータス)を返すのが Process.wait2 だと説 明すれば納得してもらえると思う。

動かしてみる。

$ cat /tmp/orphan.rb
# 子プロセスを 5 つ生成する
5.times do
  fork do
# 子プロセスごとにランダムな値を生成する。
# もし偶数なら 111 を、奇数なら 112 を終了コードとして返す。
    if rand(5).even?
      exit 111
    else
      exit 112
    end
  end
end

5.times do
# 生成した子プロセスが終了するのを待つ。
  pid, status = Process.wait2
# もし終了コードが 111 なら、
# 子プロセス側で生成された値が偶数だとわかる。
  if status.exitstatus == 111
    puts "#{pid} encoutered an even number!"
  else
      puts "#{pid} encoutered an odd number!"
  end
end
$ ruby /tmp/orphan.rb
13530 encoutered an odd number!
13529 encoutered an odd number!
13528 encoutered an odd number!
13527 encoutered an even number!
13531 encoutered an odd number!

Process.wait2はいずれかの子プロセスが終了するまで待つ、というのがポイントだ。

ま だ 話 は 終 わ ら な い 。実 は Process.wait に は さ ら に 2 人 の 親 戚 が い る 。 Process.waitpid と Process.waitpid2 だ。

!?

違いは、任意の子プロセスの終了 を待つのではなく、指定した子プロセスの終了を待つという点になる。このとき、終了を 待つ子プロセスは pid で指定する。

2 つのメソッドの実体は同じかもしれないが、任意 の子プロセスを待つ場合には Process.wait を、特定のプロセスを待つ場合には Process.waitpid を使おう。

親プロセスがProcess.waitにたどり着く前に子プロセスが終了したとしたら?これは問題ない。

カーネルは終了したプロセス の情報をキューに入れておくため、親プロセスは子プロセスの終了時点の情報を必ず受け 取ることができる。

逆に、子プロセスがない状態でProcess.waitを行うと例外となる。

終了を待つ子プロセスが 1 つも無い状態で Process.wait の一族のどれかを呼び出 すと Errno::ECHILD 例外が送出されることに気をつけておこう。生成した子プロ セス数を控えておいて、この例外が送出されないようにしておこう。

第15章 ゾンビプロセス

カーネルは、親プロセスが Process.wait を使ってその情報を要求するまで、終了し た子プロセスの情報をずっと持ち続ける。すなわち、親プロセスが子プロセスの終了ス テータスをいつまでも要求しなければ、その情報はカーネルから決して取り除かれない。 となると、子プロセスを「撃ちっ放し」方式で生成して、子プロセスの終了ステータスを 放置しているのは、カーネルのリソースの無駄使いになるというわけだ。

Process.detach は何をしているのだろうか? Process.detach は新しいスレッドを 生成している。生成されたスレッドに与えられた唯一の仕事は、 pid で指示された子プ ロセスの終了を待ち受けることだ。こうすることで、カーネルは誰からも必要とされない 終了ステータスを持ち続けなくてよくなる。

整理。ゾンビプロセスとは、

  • 親プロセスからforkされた子プロセスであり
  • 終了した子プロセスであり
  • 親プロセスが子プロセスの終了を要求していない状態である

本当?

プロセス - Wikipedia

UNIXオペレーティングシステムにおいて、ゾンビプロセスZombie Process)は、処理を完了したがプロセステーブル(プロセス制御ブロック相当)が残っていて、終了ステータスを読まれるのを待っているプロセスである[1][5]。この用語のメタファーに従えば、ゾンビプロセスは「死んでいる」が、まだ「死神」が到着していないということになる。

本当だった。

所感:今まで子プロセスの終了を始末するという場面に出会ったことがなかった。子プロセスを生成するシステムではうまくゾンビとならないようになっているのだろう。

第16章 プロセスはシグナルを受信できる

Process.wait はブロッキング呼び出し だ。つまり、子プロセスが終了するまで親プロセスは処理を続行できない。 親は親で忙しい場合はどうすればいいだろうか? すべての親が日がな一日、ぶらぶら している子供たちを待てるわけもない。そんな忙しい親のための解決策を紹介しよう! Unix シグナルの出番だ。

子プロセスが終了した時に、カーネルから送られるSIGCHLDを親プロセスで補足すれば良い。

Unix シグナルの世界への第一歩を踏み入れることができた。シグナルは非同期通信だ。 プロセスはカーネルからシグナルを受けたとき、以下のいずれかの処理を行なう。

  1. シグナルを無視する
  2. 特定の処理を行なう
  3. デフォルトの処理を行なう

シグナルはある特定のプロセスから別のプロセスへと送られるものであり、 カーネルはその仲介役となっている。

2つのrubyプログラムで、片方のプログラムから片方のプログラムにkillシグナルを送ってみる。

$ cat /tmp/sleep.rb
puts Process.pid
sleep
$ ruby /tmp/sleep.rb
13797
$ cat /tmp/kill.rb
Process.kill(:INT,13797)
$ ruby /tmp/kill.rb

実行すると、1つめのプログラムは終了する。

Traceback (most recent call last):
    1: from /tmp/sleep.rb:2:in `<main>'
/tmp/sleep.rb:2:in `sleep': Interrupt

INTシグナルが送られたことがわかる。

Signalにはたくさん種類があるが、killとstopとuser1/2ぐらいしか使ったことがない。

Man page of SIGNAL

第17章 プロセスは通信できる

プロセス間通信(IPC、Inter Process Communication)と呼ばれる分野の話 になる。IPC はさまざまな方法で実現できる。この章ではよく使われる 2 つの方法を紹 介しよう。パイプとソケットだ。

パイプを使ってwriterからreaderへ文字列を送る。

irb(main):001:0> reader, writer = IO.pipe
=> [#<IO:fd 9>, #<IO:fd 10>]
irb(main):002:0> writer.write("Into the pipe I go...")
=> 21
irb(main):003:0> writer.close
=> nil
irb(main):004:0> puts reader.read
Into the pipe I go...
=> nil

readerからwriterへ送ることはできない。そもそも、IO.pipeの返却値はreader, writerの順に返るようだ。

docs.ruby-lang.org

戻り値の配列は最初の要素が読み込み側で、次の要素が書き込み側です。

また、親プロセスはforkした子プロセスとメモリを共有するため、パイプでメッセージをやり取りすることが可能だ。

パイプは一方向だが、ソケットは両方向で読み書きができる。

第18章 デーモンプロセス

デーモンプロセスは、ユーザーに端末から制御されるのではなく、バックグラウンドで 動作するプロセスだ。デーモンプロセスのよくある例には、Web サーバやデータベース サーバのように、リクエストを捌くためにバックグラウンドで常に動作するプロセスが挙 げられる。

オペレーティングシステムにとって特別重要なデーモンプロセスが一つある。前の章 で、すべてのプロセスは親プロセスがあることを説明した。これはあらゆるプロセスに あてはまる真実だろうか? システム上のまさに一番最初のプロセスについてはどうだろ うか。

initプロセスである。pidは1だ。

$ ps -p 1
  PID TTY           TIME CMD
    1 ??         2:52.00 /sbin/launchd

Macだとlaunchdというものだった。

launchd - Wikipedia

launchdデーモン)、アプリケーションプロセススクリプトの起動・停止・管理を行う、オープンソースのサービス管理フレームワークである。アップル)のDave Zarzyckiによって作られ、Mac OS X Tiger (Mac OS X v10.4) で導入された。Apache Licenseのもとで公開されている。

Process.setsid は次の 3 つの処理をおこなう。

  1. プロセスを新しいセッションのセッションリーダーにする
  2. プロセスを新しいプロセスグループのプロセスグループリーダーにする
  3. プロセスから制御端末を外す

???

  • プロセスグループ:プロセスのグループ。基本的に子プロセスは親プロセスと同じグループになる。プロセスはシグナルを受け取ると、グループ内のすべてのプロセスにシグナルを送る。
  • セッショングループ:プロセスグループよりさらに一段抽象化したグループ。親子関係はないが、パイプでつなげられた一連のコマンドが該当する。
    • セッションリーダーにシグナルが送られると、同じセッショングループのプロセスにもシグナルが送られる

はじめて知った。デーモンプロセスを作るには、新規セッション・グループのリーダーにし、端末の関連を外すことで独立させるということをしている。

第19章 端末プロセスを作る

Ruby プログラムでよくある他のプログラムとの連携方法に、端末から外部コマンドを 動かす「シェルに出る(シェル・アウトする)」というやり方がある。Ruby スクリプトで いくつかのコマンドを自分用に組み合わせて使う場合などに、こうした光景によく遭遇す る。Ruby から外部コマンドを実行するためにプロセスを生成する方法は複数提供されて いる。

この章でこれから説明していく手法はすべて、fork(2) + execve(2) の応用だ。

一度 Ruby プロセ スを execve(2) で他のプロセスに置き換えたら、それはもう決して元には戻せないのだ

irbで実行するとirbプロセスは終了した。

$ irb
irb(main):001:0> exec 'pwd'
/Users/take
$

execve(2) は、現在のプロセスを別のものに置き換える、とても強力で効果的な方法だ。唯一の難点 は、現在のプロセスが終了してしまうことだ。そこで fork(2) が活躍する。

rubyプログラムからpythonプログラムを実行する例。

$ cat /tmp/exec.rb
hosts = File.open('/etc/hosts')
python_code = %Q[import os; print os.fdopen(#{hosts.fileno}).read()]
# 引数の最後のハッシュは exec を介して開きつづける
# ファイルディスクリプタを指定している
exec 'python', '-c', python_code, {hosts.fileno => hosts}

結果、ちゃんと動く。

$ ruby /tmp/exec.rb
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost

ポイント

  • Ruby での exec 呼び出しは、デフォルトで標準ストリームを除くすべての ファイルディスクリプタを閉じる。

    • execのオプションとしてファイルディスクリプタとIOオブジェクトのハッシュを渡すことで、execで呼び出したpythonプログラムからも対象ファイルをopenできる
  • fork(2) と違い、execve(2) は新しいプロセスとメモリを共有しない。

  • execに引数として配列を渡す。

    • 外部コマンドを文字列としてまとめて exec に渡した場合は、実際にシェルプロセスが 起動して、渡された文字列を解釈する。配列にして渡した場合には、シェルの起動は行わ れずに配列を直接 ARGV にして新しいプロセスに渡す。

そういえばcapistranoで実行コマンドを文字列にするか配列にするかで挙動に違いがあるって話があった気がする。

これらの手法には一つだけ難点があって、それは fork(2) に依存していることだ。

シェルアウトする場合、いかなる場合でもforkを使うので、メモリを全てコピーされる。それが単純なlsだったとしても。

fork(2) にはコストがかかり、パフォーマンスのボトルネックになる可能性がある、と いうことを頭の隅に入れておこう。

第20章 おわりに

Unix のプロセスについて「なるほど」と合点がいくというのは、次の 2 つを会得する ということだ。つまり、抽象化と情報伝達だ。

  • Kernelから見るとプログラムは全て同じに見せるのがプロセスという抽象化である
  • シグナルや名前、パイプやソケットを使ってプロセス同士は情報伝達ができる

入社して7日

blog.chaspy.me

今しか書けないこともあるだろうから、シュっと書く。しっかりは書かない。

7営業日が経った。業務はGitHubとSlackとGSuiteで完結しており、全ての仕事はGitHub issueで行う。で、細々とした依頼をissueでアサインされて、説明してもらい、やりながら学びながら、プルリクを出して終わる。そういう感じだ。

これが出来るのもInfrastructure/Configure as a codeがしっかりできているからだろう。まだまだスピードは遅いが、わからなければコードを読めばいいので、読んで読んで、わからないものは聞いて、プルリクでレビューもらって、バシーって感じ。

特に前回の記事と変わったことはない。少しずつ、少しずつ。社員同士の交流の機会も多いと思う。業務でなくてもイベントがあったり、急に呼ばれたり、もちろん全ては強制ではないが、僕はひとと話すのが好きだし、新人だから覚えてもらいたいし、覚えたいし、ということでなるべく顔を出すようにしている。

ちゃんと他人に、チームメンバーに関心を持っている感じがする。これはslackの絵文字のリアクションの効果も手伝っているのは見逃せないが、それでも、ちゃんと。自分のことだけ考えるとかじゃなくて、ちゃんと、まわりのひとを気にかけていることがわかる。ありがたい。

変わらない不安は、やっぱり自分ができること、自分ができるスピード、自分が知ってること、自分のことばかりだ。チームにはどうやって勝つねんみたいな強いひとばかりだが、焦らずやっていこうと言い聞かせる他ない。

いい感じだ。

「カイゼン・ジャーニー・ライトニングトークス」でLTしてきた

はじめに

参加してきました!

devlove.doorkeeper.jp

資料はこちら!

言いたかったこと

  • カイゼンに必要なのは「強さ」「外と中を比較する」「思いやり」「楽しさ」
  • まずは自分だけ楽しければいいじゃん、勇気とかいらない
  • 強くなって、カイゼンして、楽しい!サイクルをまわしていこー!
  • みんなで強くなろー!

発表の動機

月イチで社外の発表を、(まずはLTから)していこうということで、5月はどうしようかな〜と思ってたところで見かけたのでポチりました。カイゼン・ジャーニーは以前も何度かイベントに行っていたのと、前職では組織とかチームとかカイゼンとかに関心があった時期があったので、そのまとめとしてアウトプットをしておきたかったので、ちょうどよかったです。

発表内容

今回は全員LTするということで、熟練したカイゼンerたち(?)が集うでしょうと考えました。カイゼンのコツなんか話しても面白くないな〜と思い、とことん自分のことを話そうと思いました。なんで僕はカイゼンをしたかったのか?ということを問い直すことにしました。

その根源は新人時代につらかった経験から、同じようなひとを救いたいという思いでした。実際、自分がこの数年でやってきたことを振り返ると、「強くなる」「カイゼンする」「楽しい」というサイクルをうまく回せていたと思います。何より「強くならなければならない」ということに気付けて良かったと思います。

(強くなるっていうのは、、、まぁ喩えですが、、、雰囲気で感じ取って、、、技術的に成長するという意味で使ってます)

前の職場では一番強い、というところには到底遠いですが、仕事もそれなりにできて、ところにより強い(?)状態だったからカイゼンができたんだと思います。今の職場では一気に「ククク、、、だが奴はSREチームの中では最弱。。。」となっているので、面汚しにならないようまた強くなっていきたい所存です。(本当に今のSREチーム、BOSSを除いて4人だわ、四天王。。。)

おわりに

がっつり飲みながらLTっていうのは僕も好きで、よく前職の同期とやってました。今回2時間半全部LTで終わってしまったので、会話する時間もあればなおいいなーと思いました。Twitterでつながっていたひととの縁もできて、参加してよかったです。

これまでのあれこれ

blog.chaspy.me

blog.chaspy.me

blog.chaspy.me

blog.chaspy.me

blog.chaspy.me

blog.chaspy.me

blog.chaspy.me

blog.chaspy.me

「Seeking SRE Chapter 26. The Service Mesh: Wrangler of your Microservices?」メモ

はじめに

読んだ。

shop.oreilly.com

意識だけ大気圏超えて高めていくスタイルなので、イキってSafari契約しました。月39ドル分読むんだよな?読むんだよ!

まーまじめな話、一次情報をちゃんと英語から得ないといけないというのは感じているので少しずつやっていく足がかり。技術書はまぁまぁ読んできたほうだと思うけどなんやかんや翻訳まで2年とかかかること考えるとね。

まだ英語版もEarly Releaseでもあるので本文の引用は控えて、メインな部分や気になった部分だけをざっくりまとめるにとどめるので興味を持ったひとは原文へGoです。

メモ的な

  • マイクロサービス、バズってるよね
  • 信頼性エンジニア(SRE)はマイクロサービスに関する問題で大変だよね
    • networking
    • observability
  • 考えていくぞ

Ready to Get Rid of the Monolith?

  • マイクロサービスの話する前にモノリシックなアプリから考えていくよ、だいたいこんな感じのコンポーネントからなるよね
    • LoadBalancer(AWSのELBみたいな)
    • Application(ステートレス。phpとかnodeとか)
    • Database(MongoDBとかMySQLとか)
  • 相対的にシンプルと言われてるモノリスでもNetworkingとobservilityが大事やし、十分複雑なんよ

Current State of Microservice Networking

  • マイクロサービスの現状を見ていくよ
    • 言語とフレームワーク、だいたい複数の言語で書かれてる
    • プロトコル
      • RPC:REST, gRPC, HTTP/1.1, and HTTP/2
      • messsaging:Kafka and Kinesis
      • cache:Redis and memcached
      • Database:MySQL and MongoDB
    • インフラ:クラウドサービス(AWS、Azure、Google
    • LoadBalancer
    • Service Discovery:DNSからConsulのようなものまで
    • 認証認可
    • Networking libraries
    • Observability
  • Observabilityが一番大事やけんね

Service Mesh to the Rescue

  • 開発者の選択肢は2つ
    1. 使われる言語数を制限し、一貫した方法で、必要な機能を全て内包した複雑なライブラリを導入する
    2. sidecar proxyの導入

The Benefits of a Sidecar Proxy

  • sidecar proxyのメリットってあるの?
    • Out-of-process architecture、アプリから独立できる
    • High-performance code base、C++とか性能が高い言語でかく
    • Pluggability、プラガブルにすることでいろんなプロトコルともしもしできる
    • Advanced protocol support、HTTP / 2、QUIC、TLS 1.3
    • Service discovery and active/passive health checking
    • Advanced load balancing
      • retry
      • timeouts
      • circuit breaking
      • rate limiting
      • shadowing
      • outlier detection
    • Observability
      • 何度も言うけど一番重要やけんね
    • Additional use as an edge proxy
    • Ease of deployment and upgrade

Eventually Consistent Service Discovery

  • まぁいろいろあるよね、静的設定したIPアドレスからDNSからZookerperから
  • service discoveryのcheckは2段階でやって、どっちもfailだとrouteを閉ざすよ
    • 外部からの(例えば)/healthcheck endpointを叩く
    • 内部的に(例えば)503 responseを3回返してるとか
  • 前者がOKだと後者がNGでも通すし、どっちもダメならrouteから消す

Observability and Alarming

  • 本当に何度も言うけど一番大事よ
  • sidecar proxyが提供する機能は以下
    • Consistent statistics for every hop
    • A persistent request ID that can join logs and traces across the entire system
    • Consistent logging for every hop
    • Distributed tracing for the entire system
    • Consistent system-wide alarming

Sidecar Performance Implications

  • 性能大丈夫なん?
    • スループット、大企業だと重要、小さい企業だとインフラコストのほうが大きい
    • テール・レイテンシー、どんな会社でも重要、原因が難しく、エンジニアに負荷が大きい
  • sidecar proxyは諸刃の剣

Thin Libraries and Context Propagation

  • 結局アプリケーションレイヤーでContext Propagationは必要
    • いろいろライブラリはあるとはいえ、どう実装するかは悩みどころ

Configuration Management (Control Plane versus Data Plane)

  • これまでService meshの利点語ってきたけど、実際どうやって設定配るかの話してなかったね
    • Data Plane:実際のsidecar proxy。地下鉄でいえば電車。
    • Control Plane:ルートテーブルやトラフィックルールを持って、データに配る。地下鉄でいえば路線切り替え。
  • 実際にどう動くかというと
    1. データプレーンに変更が必要な、グローバルシステムの変更を探索
    2. システム内のすべてのプロキシへの新しい設定を生成
    3. すべてのプロキシに設定変更をデプロイ
    4. 各プロキシに設定をリロードさせる

The Service Mesh in Practice

  • proxyのソリューション:HAProxy、NGINX、Linkerd、Traefik、Envoy
  • 完全なソリューション:
    • SmartStack(HAProxy上に構築)
    • Istio(Envoy上に構築され、現在Linkerdもサポートしています)

The Origin and Development of Envoy at Lyft

  • LyftにはSREと呼ばれるポジションはない
  • envoy作ったらすっごい役に立った
  • アプリケーション構築にネットワーク意識することなくなった

Operating Envoy at Lyft

  • もう一度言うがLyftにはSREポジションはなく、すべての開発者がそれをかねる

OPERATIONAL LEARNINGS

  • デフォルトのダッシュボード、トレース、ログ、アラームの自動生成
  • ドキュメント
    • めっちゃ重要よ
    • みんなのスキルはそれぞれ。ネットワークにあまり詳しくないひとに役立つ
  • テンプレート化された設定生成
  • Hot restart for easy roll-forward and rollback:ローロバックやロールフォワードが行えるホットリスタート
  • Administration endpoint for on-node debugging:人間が読めるようなデバッグノード

DEVELOPMENT LEARNINGS

  • Decoupled sidecar deploy process
    • アプリケーションから独立してsidecar proxyをdeployできる

TECHNICAL LEARNINGS

The Future of the Service Mesh

  • Service Mesh開発はこれからしばらく多額の投資が必要だと思う
  • ただ、サービスメッシュがうまいこといってるアプリケーションに対して開発者はデプロイしたくなくなるだろう(なんで?ここの訳がわからず)

Recommended Reading

(読んでいません)

www.envoyproxy.io

blog.envoyproxy.io

Istio service mesh(どのページかわからず)

“Lyft’s Envoy dashboards”

blog.envoyproxy.io

blog.christianposta.com

blog.envoyproxy.io

blog.envoyproxy.io

おわりに

英語の技術書の読み方に関して。まずざざーっと英語読んで、わかんないところは翻訳ぶち込んで、また英語読んで、ってのを小分けに何度かやって、またまとめながら書いた感じ。日本語技術書の解釈と似たようなプロセスだけど、時間が3、4倍(もっとか?これ1章分だしなぁ)かかるのがつらい。慣れかな。とりあえず自分なりのいいやり方があると思うので続けたい。

サービスメッシュに関して。とにかくObservabilityが大事ということはとても伝わった。実際envoy/istioは今導入検討している会社が多いので今後触ってみたいのと、本当にその解決が必要なのか、課題は何なのかは十分に考えたい。

Observability、結局のところ、logging, alarting, tracingあたりだと思う、一番大事なのは分散トレーシングだよねーこれは欲しいよねーというのはわかるなぁ。ただ本章で触れられている通り、リトライなりロードバランシングなりはproxyに持たせることはできたとしても、一貫したトレースIDはアプリからつけてあげなきゃいけない気がするし、その実装がさっぱりなので知りたい。opentracingっていう仕様に従うのが良いのかな。よくわかってない。

ただでさえ複雑でつらいMicroservices、そもそもそれにする必要があるのか、さらにService meshを導入する必要があるのか、その損益分岐点はどこだ?みたいな話が聞きたいし、試してみたいところです。

入社して2日

シュっと書く。

わいわい!って感じがしてとても楽しい。

一方で、(想像はしてたにせよ)扱うシステム・インフラの(まだ知らないが故だが)膨大さに、理解のスピードが追いつくかは不安である。自分自身のコーディング/インフラスキルに対する不安もある。

とはいえ、そもそもソフトウェアエンジニアリングそのものが不安との戦いだとすら僕は思っているので、そういうものだと思ってやるしかないのはわかっている。

ひとがいい。

Web系というのはそういうものなのか、他社を知らないので何とも言えないが、わいわい!って感じで、みんなわいわい!って感じで、とても好きだ。(3行目以降何も言っていないが許してほしい)

どうやって自分のバリューを出すか、その前にちゃんと1人前に給料分の対価出すか、については頑張るぞいというしかないが、少なくともこの2日でアンマッチさは微塵も感じていない。これから出てくるかもしれないが、それは会社のブログで書くかもしれないし、書かないかもしれない。

いい感じだ。