Cookpad 5day service dev internship に参加した！
2017/09/11 から 5日間で開催されたcookpadのサービス開発インターンシップにエンジニア枠で参加してきた。
インターンシップ概要
cookpadのインターンシップは二種類あって、今回参加したのはサービス開発を実践的に行う方です。 こちらのインターンシップは就業フェーズは無くて、5日間かけてサービス開発のサイクルを回して１つのサービスを作ろう！という趣旨らしい。
サービス開発は “デザイナー” と “エンジニア” がペアになって、課題発見・価値仮説・ユーザーストーリー・実行・検証といった一連の流れをcookpad製のフレームワークに沿って行っていく。 もちろん価値が見いだせなければ価値仮説まで戻ってやり直すし、ユーザの導線や周知ストーリーも考えないといけない。
日程としては
- １日目：元々価値仮説の済んでいる状況から検証まで行いサービス開発に慣れる
- ４〜５日目：実際に価値仮説から開始して最終発表までサービス開発
で行われる。もちろん後半は実装時間も含まれているし、発表資料も用意する必要があるしで大変……。
インターン成果物
今回のインターンシップテーマは “一人暮らししている人の料理が楽しみになるサービス” を作れというもので、 自分たちのチームは課題発見から価値仮説までがすんなり進んだおかげか、検証もある程度行えて、最終発表までにカタチにすることができた。 作ったアプリは僕の実装が雑なので完成度が高いとは言えないけど、ペアの方が優秀だったのでデザインの適用がサクッと進んで本当に助かった。
ちなみに作ったのはkurashiruやクックパッド料理動画のようなサクサク見れる料理動画をスマホ１つで簡単に撮れるアプリ。 以下は最終発表資料で、少しだけ内容を簡素に手直ししている。
余談というか、成果物をApp storeに載せたいと考えていたんだけど、機種別の対応が必要なのと、先日iOS11にしたらまったく起動しなくなってしまったのでまだ先になりそう…。
以下、ポエムと感想。
提供することは難しい
インターンシップでもっとも大変だったことが「これ本当に価値あるの？」という問いに対して、 自分の感性だけでなく定性・定量的なデータを持って「あります。」と言い切るまでブラッシュアップすることだった。 このインターンシップではユーザインタビューという形で定性的なフィードバックをもらい、 価値仮説をし直したりしたので最終的には自信を持って取り組めたけど、最初はやっぱり手が進みそうにない感があった。
もちろん、ユーザーインタビューをするにはアプリとして動作の流れができていないといけないし、 多少自信が無くても価値を提供できることを想定して作らないといけない。 それでユーザーインタビューの結果ズタボロになると結構ずっしりくる。 講義段階で、社内デザイナーの方が “正解はない” という言葉を使っていた。でも “外れはある” と思う。 ただその外れを引いたときには絶対に間違った方向はわかるから、 正解を見つけるためでなく、失敗を理解するために何度も開発サイクルを回すのは本当に大切なんだと実感ができた。
サービスを実装すること
今回はiOS向けでアプリを作ったのだけど、macOS使ってるけどxcode開かないユーザーだったので結構実装は大変だった。 メンターの方がiOSエンジニアで本当に助かったし、頼りになる方だったのでtipsとか色々聞くこともできた。たぶん違う業種の方だったら終わらなかったかもしれない…。
大変だった。大変だったんだけど、実装はしないとそもそもアプリは完成しない。 頑張って、苦しんで、機能をすべて実装しても、それはアプリとして最初から想定していた最低限の機能だからあって当たり前だと思っている。 自分のマインドとして、全て実現できなかったらそれは設計段階で「無理」と言い切れなかったエンジニアの落ち度だし、もしくは実力不足だと考えてる。
正直、今回も全てを実装しきれたわけではなかったので悔しいと思っているし、見積もりも甘かったと思ってる。 これから先何を仕事にしていくかわからないけど、エンジニアとして知識や技量を積んで、実現能力を高めたいなと実感した。
さいごに
お昼は人事の方が美味しいごはん作ってくれたので体験が最高だった…本当に美味しかったです…ありがとうございました…。 普段は１日１食か２食しか食べないのだけど、インターンシップ期間中で３食摂る癖が付いて今も調子が良い。すごい。 講師・メンターの方々、人事の方々、他参加者の方々、５日間ありがとうございました。お疲れ様でした！
NGINX unit v0.1 と所感
せっかくなので動作までの作業ログと所感をまとめて書いておく。最新のインターフェースや環境構築については公式README.mdのほうが詳しいので参考程度に。記事内リンクについてはv0.1時点のものを引用しているためmasterとは差分があるので注意。
環境
Vagrantでubuntu-xenialを用意してgolangの受け答えができるところまで作った
$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
構築
unitの本体を入れる
configurationの受け答えしたり、（将来的に）アプリケーションのリロードや監視などのAPIが生えるであろうパッケージ。yum だと面倒な手順いらないらしいけどaptだとkeyの登録が必要だったりする。インストール手順はREADME.md#ubuntu-packagesを見てほしい。
goのプロジェクト作成
テスト環境なのでディレクトリはGOPATH以下に作ってしまう
$ mkdir -p $GOPATH/src/github.com/your-name/nginx-unit $ cd $GOPATH/src/github.com/your-name/nginx-unit $ touch nginx-unit.go
nginx-unit.go
このunitパッケージはgolangだけ必要らしい。PHP, pythonはピュアな応答をするモジュールを作成するだけで済むが、Golangはおそらくバイナリ上でポート設定等をgracefulにやりたかったのでパッケージを別にする必要があったのだと思ってる*1。それはそうと、unitって名前どうにかならないのかな。リネーム前のnginext よりはいいんだけど。
package main import ( "fmt" "net/http" "unit" ) func handler(w http.ResponseWriter, r *http.Request) { w.Header().Add("Content-Type", "text/plain") fmt.Fprintf(w, "Proto : %s\n", r.Proto) fmt.Fprintf(w, "Method : %s\n", r.Method) fmt.Fprintf(w, "URL : %s\n", r.URL.Path) fmt.Fprintf(w, "Host : %s\n", r.Host) } func main() { http.HandleFunc("/", handler) // port はダミーなので適当で良い unit.ListenAndServe("8080", nil) }
nginx/unitをコンパイル
各種言語用のパッケージをコードからビルドする必要があるのでcloneしてきて必要なものをビルドしていく。依存パッケージのインストールからパッケージのインストールまでをやると動く。特にv0.1に関しては入れるだけで済んだ。
起動
goのプロジェクトをビルドしてパスを控える
$ cd $GOPATH/src/github.com/your-name/nginx-unit $ go build
unit本体の起動
$ sudo service unitd start
一応socket探す（手元では /run/control.unit.sockにあった）
$ find / -name 'control.unit.sock'
config.json
configuration用のjson。executableへは先程のビルドしたバイナリファイルへのパスを書く。また、ポート・ワーカー数などは適当な数に設定する
{ "listeners": { "*:8040": { "application": "golang" } }, "applications": { "golang": { "type": "go", "workers": 1, "executable": "full/path/to/nginx-unit/binary/file", } } }
jsonの内容はAPI、もしくはserviceに生えてるインターフェースから適用する
$ sudo curl -X PUT -d @config.json --unix-socket /run/control.unit.sock http://127.0.0.1:8040/ # または $ sudo service unitd restoreconfig /full/path/to/json
ここまでするとconfigに書いた内容でgolangのプロセスが立ち上がっているのでcurlで確認
$ curl curl http://localhost:8080/foo/bar Proto : HTTP/1.1 Method : GET URL : /foo/bar Host : localhost:8040
さらにconfig.json書き換えることで複数のパスを指定し、複数のプロセスを管理することもできる。
おお、簡単に動くじゃんと思ったが、機能としては現状ここまでらしく、hot reload がされなかったり（インターフェースがまだない？）unitをrestartするとconfigurationは全てpurgeしたり*2するなど全く実用段階ではないことがわかった。
所感
そもそもNGINX unitで何が嬉しいのかっていうと、今のところ言語間のインターフェースを吸収することでUnicornとかuwsgiを必要とせず、さらにアプリケーション内にデプロイ用のコードを個別に実装する必要がなくなるっていうのが強みにかなと思う。あとはHTTPで橋渡しができるのでそれがとにかく楽であった。 公式のKey Featuresを見る限りは動的なプロセス管理の対応や、サービスメッシュになっていくぞという宣言があるのでそこにも期待していきたい。所詮NGINX Application Platformの一機能としてのNGINX unitだが、unitのKey Featuresだけでも高機能なので、完動すればだいぶ心地の良いものになるんじゃないかと思っている。
References will be Garbage
参照カウント方式のメモリ管理機構ではメモリ解放のプロセスを分散できるために、他のメモリ管理と比べて目に見える停止時間が少ない。 ただ、純粋な参照カウント方式では全てのオブジェクトの状態を管理することは難しくて、例えば循環参照などの問題が発生する。 歴史は色々あるのでそうした問題解決方法について少し調べたものをまとめてみた。 GCハンドブックなどを見れば一通り書いてあるので、気になったら書籍を参考にしてもらえればと思ったり。
循環参照の解決
参照を持っていればオブジェクトは破棄されない。そのため参照カウント方式のメモリ管理機構では参照の状態が循環状態になるとオブジェクトは一生解放されないという問題点がある。以下はReferenceクラスのインスタンス変数としてお互いを参照している例である。この状態ではa, bそれぞれ他のオブジェクトからの参照が残っているため、参照カウント方式のメモリ管理ではどちらも解放されない。（rubyっぽく書いているが一応疑似コード）
class Reference instance_var :ref end a = classA.new b = classB.new a.ref = b b.ref = a
弱参照と強参照
一つの手段として参照に強弱を持たせる。それぞれ強参照、弱参照と呼び、強参照は一般的な参照と似たようなもので。参照されている先のオブジェクトは参照が残っている限り破棄されない。 対して、弱参照は参照先から強参照が消えると破棄される。つまり破棄を防ぐ強制力を持たない。
対策としてしばしば参照カウント方式のメモリ管理機構には弱参照の概念が導入される。 例えば、イミュータブルな参照を弱参照で扱ったり、強弱両方の参照記法を用意し、プログラマに明示させるなどの方法がある。
もともと手動管理であったり、 静的にメモリを管理できる機構が備わっている場合は負担は少ないだろうけど、 記述のミスが原因でメモリリークを引き起こしたりする可能性があるため若干怖い節がある。
ちなみにC++11以降ではスマートポインタ、objective-cではARC（Auto reference count）、RustではArc・Rcが似たような機能を持っている。
ガベージコレクション（GC）の分散
また、別の対策としてあるのが、別のGCを導入することである。 例えば Mark and sweep を導入し、使用未使用の状態をフラグで管理することで循環参照状態のオブジェクトを発見、破棄できる。
逆に Mark and sweep のみの構成ではMarkフェーズ、sweepフェーズの負荷が大きく、プログラムに停止時間を与える可能性がある。 そのため、参照カウントを用いて適度にオブジェクトの破棄を進めつつ、参照カウントで破棄できないオブジェクトをまとめて破棄する。 互いの欠点を補いつつ複数のアルゴリズムでGCしていくのは一般的な手段であると言える。
例えば、Python2.2では参照カウント方式のGCと Mark and sweep を組み合わせてメモリ管理を動的に行っている。 最近あったその手の話では、instagramがWebサーバーへのリクエスト時にMark and sweepによるGCを停止させ、参照カウントのみでメモリ管理を一時的に行うことで性能を向上させるなどの工夫があった。*1
参照カウントのトレードオフ
闇雲に参照カウントを入れればフルGCの機会が減って性能が向上するわけでもない。 オブジェクトの参照をカウントするにはそれ専用の領域が必要になる。すなわち、オブジェクトが確保するヒープ領域には最大オブジェクト数分のカウントが可能な領域が余分に確保される。 余分に確保されるということはヒープ領域をフルに活用できるない。フルに活用できないのであればメジャーGCの頻度は向上するだろう。 結局、参照カウントによって分散できるはずが、総フルGC時間が長くなってしまい、逆に性能が悪化する恐れがある。
そこで例えば、参照カウント用のビット数を絞る方法なども考えられる。例えば、ビット数を1ビットとして参照カウントをし、2つ以上の参照があった場合には参照カウントによるGCを諦め、他のGCに処理を移譲する。 こういった方法は一般的なオブジェクトの生存期間や参照の数について統計やベンチマークを行い、言語やフレームワーク、設計の特性からビット数を工夫することで性能は向上する可能性がある。
