以下の記事が話題になっていたので、さっそく買って読んだ。
Wantedlyを支える技術をギュッと１冊の本にして技術書典に出展しました
で、ちょうど最近自分で、マイクロサービスの開発フローを整えたところなので、反省した点を書いていく。
PUSHからDEPLOYまでのフローについて
wantedlyのフロー
自分が構成した現在のフロー
反省した点
dockerの導入について
Wantedlyのように、dockerを使ってテストや本番にリリースしたいとは当初思っていたが、以下の理由で諦めた。
- AmazonLinux用のAnsibleから環境構築していた
- CircleCIを会社で利用していた
- CircleCIでAWSネットワークが利用できない
- AmazonLinuxのDockerimageを導入してもyum installができない
- Ansibleを書きなおすか、Dockerを諦めるか → Dockerを諦めるを選択
本書を読んで、やはりDockerを導入するメリットは大きいと判断したので、あらためてDockerを利用するフローに変更してみたいと思った。
利用するサービスすべてがCoreOSというようになるのも魅力的。
ただ全てのパッケージをdockerfileから構成しようとすると大変そうなので、既存のAnsibleファイルも活用できるところは活用していきたい。
deployのフローについて
古い感覚なのかもしれないが、いくらテストを突破しても、マージが完了したら自動で本番にリリースするのは怖い。
ステージ環境までは自動でリリースして、ステージ環境で軽く触ってみて問題ないかを確認する手順は続けていくだろう。
本番環境へは手動リリースというフローにすると思う。手動といっても、別にコマンドではなくchat opsでも何でもいい。
※ @awakiaさん(wantedlyの中の人)からコメントいただきました。本番環境への自動デプロイは勘違いみたいです。コメント参照。
その他
deploy後にエラーが起こった時にGithub issueに登録するというのもやりたい。
現状のシステムではエラーの通知だけしかできていないが、たしかにストックされるべき情報なので、Github issueなり、backlogの課題なりに自動的に登録されていいと感じた。
検索について
学んだ点
まだ今回開発したものに対して、検索機能の必要性はないが、利用するのであれば、Apache Solrなどを利用しようと考えていた。
ただ今回、Elasticsearchを利用すると、ある程度重み付けをした検索結果を得られ、導入時の敷居も低いことがわかったので、そちらを利用するのもありだと思った。
データ解析とか
現状、うまくデータ解析までできていない。
ログは残すようにしているが、それを元にして何を集計するか、というのを決める人がいない状況。
GoogleAnalyticsと、GoogleBigQueryを使っており、
データが増えてきたらTreasureDataを使いたいという依頼は数ヶ月前から行っているので、参考になりそうなことが多かった。
まとめ
123ページと技術書にしてはかなり薄い。
たぶん電子書籍で読むよりも、紙媒体で同人誌的に読んだほうが楽しめたろうな、と感じた。
他社で実際に運用されているインフラまわりの情報が、ここまで分かることはあまりないので、とても参考になった。
あと、すくなくともインフラチームが持っている理念はすごく共感できる。普通にwantedlyで働くの楽しそうだと思った。