2016年振り返りと2017年
昨年をあらためて振り返ると、個人としては30代のワーストとなる年だった気がする
(あくまで個人としての話です)
ワーストの理由
- インプット/アウトプットともにほぼ0に近かった(特に登壇は0)
- 家庭についてもあまりお手伝いできず、家内に負担をかけてしまったかも
2015年のサービスローンチが終わって、2016年は少しは楽になるかな−と思いきや
より忙しくなってしまいいつの間にか今日に至る、という感じ。
忙しいのは自分のせいなので言い訳にせず、猛省します。
ロールの変化
そんなに大層な話でもないが、立場的にリーダーっぽいタスクが増えた。
昨年はいかにチームとしてうまく回せるか、というところを重点に置いて仕事を進めるように心がけていた。
独りよがりにならないようにチームメンバーと1on1を行ったり、全体の開発フローの提案では合意を取って進める(さらに改善できるところはする)、などを行っており、そこはうまく回っているように感じている。
ただ自分がクリティカルパスになりがちなことが多かったので
任せられるところは優秀な同僚に振りつつ、自分はもっと上のレイヤーにかかわらないとな〜と思っているところ。
2017年
特にこれといった目標があるわけではないけど、今年は40歳になる節目の年だし
忙しいを言い訳にせず何か一つでもやり遂げたい(やりたいことはたくさんある)。
仕事も家庭も充実した一年にしたい
Nginx実践入門
この度はご恵贈いただきましてありがとうございます。
途中からですが、自分もレビュアーの一人として参加いたしました。
本書についての雑感
Nginx入門ではなく、Nginx実践入門というタイトルからも分かる通り
より実践向けの内容となっています。
ターゲット層としては
「一通りNginxを触ったことがあるが、さらにNginxを使いこなしたい人向け」
といったところでしょうか。
特に後半
第5章 安全かつ高速なHTTPSサーバの構築
第6章 Webアプリケーションサーバの構築
第7章 大規模コンテンツ配信サーバの構築
第8章 Webサーバの運用とメトリクスモニタリング
辺りの内容が素晴らしいです。
5章、HTTPS周りではセキュリティ/パフォーマンスについても考慮されており
Nginx+HTTPSで配信している環境では必読かと思います。
6章、Nginxでよく利用されるパターンと思われる、リバースプロキシ周りのお話です。
普段よく目にするプロキシ周りのディレクティブですが、
「この設定値はどのように決めたらよいか」という説明が丁寧に説明されていて
非常に勉強になりました。
7章、大規模コンテンツ配信、主にLBやキャッシュ周りのお話です。
キャッシュ戦略の話や配信クラスタの話など、とても興味深く読むことが出来ました。
8章、運用周りのお話です。モニタリングやアクセスログについて、
きちんと運用しようとすると意外と大変だったりします。
その辺りのリファレンスや実際の手法が書かれていて参考になりました。
また全体的に
単純なリファレンスとして書かれているのではなく
「なぜこういうことをするのか」
「そのためにはどういう設定をすればよいのか」
「この設定はどのような事を考慮して値を決めればよいのか」
が丁寧に書かれていて非常に読みやすかったです。
このように、実践の名にふさわしく
著者が今まで培ってきた運用ノウハウがギッシリ詰め込まれています。
「他社では実際にどのような設定をしているのか」
「どのような運用をしているか」
といったところはとても参考になりますし、普段から気になるところでもあります。
Nginxを使い倒している会社の知見を得られるというだけでも
本書を読む価値はあると思います。
レビューについて
自分は主に9章/10章のlua関連の箇所をレビューさせていただきました。
こういった書籍のレビューに参加するのは初めてでしたので
どの程度口を出して良いかの匙加減が難しかったのですが
いくつか反映していただきました。
貴重な体験ありがとうございました。
まとめ
Issue上のやり取りを遠くから眺めていたのですが
「出来るだけ新鮮な情報を載せたい」
「妥協せず良い情報を載せたい」
という意気込みを感じました。
そしてそれが反映されている書籍だと思います。
是非手にとって、実際にそれを感じていただきたいです。
また著者のお二方、関係者の方々、お疲れ様でした!
2015年振り返りと2016年
※仕事納めしながら書いてる
今年はまれに見る激動の年だった。
とくに後半は何してたかもあんまり覚えてない。
登壇
自分にしては例年よりか登壇して喋ったような気がする。
しかも嬉しいことにお声がけ頂くことも。。
- CROSS 2015: はやぶさ2開発者に聞く〜一度きりのテスト対策〜
- TV連動勉強会vol1: TV連動サービスのリアルタイム通知を支える技術
- Monitoring Casual Talks #7: shinken monitoringについて真剣に調べてみた結果
- YAPCAsia2016: Docker3兄弟
- Itamae Meetup#1: Chef SoloからItamaeに完全移行した話+
ただ、話すのがそんなに得意ではないのもあり
毎回トーク後に反省してました…
もっとうまく喋れるように来年はがんばります。
仕事
前半にHAROiDに転籍してから
無事リリースまで漕ぎ着けることが出来た。よかった。
今年はほぼこのリリースに注力した年だった。
完全に言い訳になるが、目の前の仕事が忙しすぎてほとんど技術系への投資が出来なかったのは反省。
本もほぼ読めてない…
2016年
おそらく会社としても自分としても転機になりそうな年。
モチベーションはかなり高いので攻めの姿勢でがんばります!
YAPC::Asia 2015で「Docker3兄弟」というお話をしました+QA補足 #yapcasia
※2015/08/29 追記
現在DockerToolboxでVirtualBoxもインストールすると最新の5.0.2がインストールされますが
このバージョンがDockerMachineと相性が悪く、VMが起動しないという罠があります。
https://github.com/docker/machine/issues/1716
VirtualBoxのバージョンを5.0.0に下げるか、
こちらから次期テストバージョンの5.0.3をインストールしましょう。
まずはじめに、足を運んでお聞きいただいた皆様ありがとうございました。
30分(トークは20分)にこれら3つのツールを紹介するにはボリュームが少し多すぎた感があり
きちんと伝えたいことが伝わったかどうか不安。。
また、QA時に英語で質問されテンパってしまってきちんと回答できず、質問していただいた方に大変申し訳なく思っております。。
QA時に回答できなかった分について補足します。
※kitematicについては英語でQAされたもので、きちんと理解出来ていない可能性があるので2通りの回答してみます
Q. kitematicでlinux上のリモートホストを管理できる?
A. 現在は出来ないようです。issueにはあがっているのでそのうち対応するかもしれません
Q. kitematicはlinux os上で動く?
A. 現在は出来ないようです。issueにはあがっているのでそのうち対応するかもしれません。
Q. docker-machineでREST APIはある?
A. 現在は出来ないようです。がロードマップ(c/sアーキテクチャ)には記載されているのでそのうち対応するでしょう。
あと一つ強調し忘れていたこととしては
「docker composeは冪等である」ということです。
どの環境でもdocker-compose up すれば動く!最高!!
開発環境やインフラでは冪等性が大事だと思っています。
docker-composeはその手助けをしてくれるでしょう。
#tvrendo テレビ連動サーバ勉強会 で発表しました
http://connpass.com/event/10424/
弊社にて、テレビ連動サービスに特化した勉強会を開催しました。
で、自分も発表してました。
スライドはこちら。
http://www.slideshare.net/tsuyoshitorii5/public-43549341
時間配分全然わかってなかったので、(特に後半)かけ足になってしまいました。
申し訳ございません。
デモの辺りの補足
背景
そもそもだいぶ前から
「こういう感じでsocket.ioコンテナ化して自由に上げ下げできると面白いな。
で、実際どうなのかな?実運用できそう?」
ということを考えていました。
そして今回いい機会なので急ぎでプロトタイプ書いてみたところ
なんとなく上手くいったのでデモとして公開してみました。
またこの構成だとLBが最初にサチるので、この構成単体だと限界があります。
あくまでサーバ1台辺りのリソースをうまく使いきりたいなーというところが目的です。
あと半分は遊びですねw
デモ動作説明
スライドにも書いてますが、以下のような仕組みで実現しています。
- LBは Openresty+Luaで実現。sticky idからsocket.ioサーバを決定
- socket.ioコンテナを増やすと以下のような処理が動く
- Registratorが増えたコンテナ情報をconsulに通知する
- consulと繋がっているconsul-templateに変更情報が通知される
- consul-templateがnginx.confのサーバリストを書き換え、自動で restart が行なわれる
- 複数コンテナはsocket.io-redis adapterで繋がっているのでブロードキャストも通知される
デモでやったこと
定期的にsocket.ioクライアントでコネクションし続け、
その状態でDockerコンテナ増やしたり減らしたりしても
問題なく接続/再接続できる様子を動画にしてみました。
反応ないのでわからないんですが、この手法どうだったんだろうかw
(動画アップロードしてもいいんですが、やりかたわからん…)
感想
クラスメソッドさんの大規模通知の話も共感しながら聞けましたし、
voluntasさんのMQTT話も本当にとてもわかりやすくて勉強になったし、
a2cさんのマル秘話も非公開にするのが惜しいほどすごいお話で刺激受けました。
正直言うと自分はめっちゃ面白かったので
第2回もあると良いですね!!!
omnibus-gitlabを利用したGitlabアップグレードの手順メモ
毎回ドキュメント見つつ実行するのがダルいのでメモしておく。
7.10.x 以降: 手順
これだけでOKになりました:)
# ubuntuバージョン sudo apt-get update sudo apt-get install gitlab-ce
7.9.x 以前のバージョンから上記手順に移行したい場合は
普通に最新版install手順から繰り返せばそのまま移行することができます。
https://about.gitlab.com/downloads/
※一応前バージョン移行手順も残しておきます
7.9.x 以前: 手順
1. 最新バージョンのGitlabダウンロード
こちらのページから最新バージョンを確認し、ダウンロードをしておきます。
https://about.gitlab.com/downloads/
ex) Gitlab-7.6.2の場合
wget https://downloads-packages.s3.amazonaws.com/ubuntu-14.04/gitlab_7.6.2-omnibus.5.3.0.ci-1_amd64.deb
2. デーモン停止
sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop sidekiq sudo gitlab-ctl stop nginx
3. バックアップ実行(※必須ではないが、念のため)
バックアップ先は /var/opt/gitlab/backups です。
sudo gitlab-rake gitlab:backup:create
4. 1. でダウンロードしたパッケージをインストール
# Ubuntu/Debian: sudo dpkg -i gitlab_x.x.x-omnibus.xxx.deb # CentOS: sudo rpm -Uvh gitlab-x.x.x_xxx.rpm
5. プロビジョニング実行
sudo gitlab-ctl reconfigure
6. デーモン再起動
sudo gitlab-ctl restart
isucon4予選問題のLua(Lapis)バージョンを書いてみた
isuconアプリを書いてみましたシリーズ。
生でOpenresty+Luaで書いても良かったんですが
せっかくなのでLapisというWebフレームワークを使ってみました。
実は自分も初触り。
最初にLapisの概要など
LuaのWebアプリケーションフレームワークです。*1
バックエンドはOpenresty(Nginx)を利用しています。既に速そうな感じがしますね…!
WebFrameworkBenchmarksでも割と上位にいます。
Lapis、実は生のLuaスクリプトではなく moonscript で書くのを推奨しているようです。
JavaScriptにおけるCoffeeScriptのようなものですね。
構文も似ているのでJS書いている人には取っ付き易いかもしれません。
isucon4 Lapis版ソースコード
こちら。
https://github.com/toritori0318/isucon4
また、Gistにitamaeレシピを置いておきました。
こちらを実行すると Openresty+Luarocks+Lapis がインストールされますので
試したい方はお使いください。
# itamaeインストール gem install itamae # レシピダウンロード wget https://gist.githubusercontent.com/toritori0318/2f2e080f906dbbbd0dea/raw/b0de3d7e8ece81fc81514b074e49549d0975da16/isucon4_lapis_recipe.rb # レシピ実行 itamae ssh isucon4_lapis_recipe.rb -h xxx.xxx.xxx.xxx -u ec2-user -i /path/to/aws.pem
isucon4 Lapisバージョンを動かすための手順
1. isucon4アプリを上記ソースコードに置き換えます
2. /etc/supervisord.confのminfdsを増やしておき、 service supervisord restart を実行します。
[supervisord] logfile=/tmp/supervisord.log loglevel=info pidfile=/var/run/supervisord.pid nodaemon=false minfds=100000 minprocs=200
3. /etc/supervisord.confに以下を追記し、supervisorctl reload を実行します。
[program:isucon_lua] directory=/home/isucon/webapp/lua command=/opt/openresty/nginx/sbin/nginx -p /home/isucon/webapp/lua -c "nginx.conf.compiled" #command=/home/isucon/env.sh /usr/bin/lapis server production user=isucon environment=LAPIS_OPENRESTY="/opt/openresty",PATH="/opt/openresty/nginx/sbin:$PATH" stdout_logfile=/tmp/isucon.lua.log stderr_logfile=/tmp/isucon.lua.log autostart=true
ベンチマーク
kazeburoさんの "ISUCON4 予選でアプリケーションを変更せずに予選通過ラインを突破するの術" を参考にし、
サーバに対してほぼ同じ修正をした後のベンチマークです。
perlアプリケーション(kazeburoさんversion)で実行
$ ./benchmarker bench --workload 8 18:17:59 type:info message:launch benchmarker 18:17:59 type:warning message:Result not sent to server because API key is not set 18:17:59 type:info message:init environment 18:18:07 type:info message:run benchmark workload: 8 18:19:07 type:info message:finish benchmark workload: 8 18:19:12 type:info message:check banned ips and locked users report 18:19:15 type:report count:banned ips value:593 18:19:15 type:report count:locked users value:4357 18:19:15 type:info message:Result not sent to server because API key is not set 18:19:15 type:score success:186360 fail:0 score:40258
Lapisアプリケーションで実行
$ ./benchmarker bench --workload 8 18:54:06 type:info message:launch benchmarker 18:54:06 type:warning message:Result not sent to server because API key is not set 18:54:06 type:info message:init environment 18:54:14 type:info message:run benchmark workload: 8 18:55:14 type:info message:finish benchmark workload: 8 18:55:19 type:info message:check banned ips and locked users report 18:55:22 type:report count:banned ips value:859 18:55:22 type:report count:locked users value:4747 18:55:22 type:info message:Result not sent to server because API key is not set 18:55:22 type:score success:221580 fail:0 score:47865
やはり速かった。
Lapis雑感
全体的につらい方が多い :(
つらい点
実例が少ない
Lapis(Lua)自体のユーザ数が少ないこともあり、ノウハウ的な情報はほぼ皆無です。
自力で頑張る必要があるでしょう。
Webに情報が少ない公式ドキュメント以外は情報少ないというかほぼ皆無です。
自力で頑張る必要があるでしょう。
エコシステムが弱い
そもそも便利ライブラリが少ない、またはメンテされていないのが多いので
普通のWebアプリケーションを作ろうとした時につらいです。
自力で頑張る必要があるでしょう。
MySQL非対応
PostgreSQLはバッチリ対応していますが、現時点で何故かMySQLは非対応です。
Pull Requestはされているようなのでその内当たるかも。
しかも現時点ではそのまま利用しようとすると動かないバグがあるので
1行パッチを当てる必要があります。(こちらのレシピでもパッチを実行しています)
良い点
Openrestyの遺産が使える
普通にngxの情報にアクセスできますし、Openrestyのライブラリも使えます。
これは結構な利点だと思います。
速い
パフォーマンスはだいぶ良いので
単純なアプリでパフォーマンスが必要であれば
選択肢として考えてもよいかもしれません。
まとめ
Lapisでisucon4予選問題アプリを書いてみました。
実際のWebアプリケーションを作るにはだいぶ茨の道だと思いますが
LLのように書ける割には速いですし
isuconのような一発アプリに使うのはアリかなと思いました。
またLua/MoonScript、実際書いてみるとわかるのですが
構文はJavaScript/CoffeeScriptに似ている部分があるので
実は(書くだけであれば)そんなに違和感なく書けたりします。
Go速いけどまだちょっと手を出しにくい…という人には
割とマッチするかもしれません。
ぼくはオススメはしませんが!!!