2016年振り返りと2017年

昨年をあらためて振り返ると、個人としては30代のワーストとなる年だった気がする
(あくまで個人としての話です)



ワーストの理由

  • インプット/アウトプットともにほぼ0に近かった(特に登壇は0)
  • 家庭についてもあまりお手伝いできず、家内に負担をかけてしまったかも

2015年のサービスローンチが終わって、2016年は少しは楽になるかな−と思いきや
より忙しくなってしまいいつの間にか今日に至る、という感じ。
忙しいのは自分のせいなので言い訳にせず、猛省します。


ロールの変化

そんなに大層な話でもないが、立場的にリーダーっぽいタスクが増えた。
昨年はいかにチームとしてうまく回せるか、というところを重点に置いて仕事を進めるように心がけていた。
独りよがりにならないようにチームメンバーと1on1を行ったり、全体の開発フローの提案では合意を取って進める(さらに改善できるところはする)、などを行っており、そこはうまく回っているように感じている。
ただ自分がクリティカルパスになりがちなことが多かったので
任せられるところは優秀な同僚に振りつつ、自分はもっと上のレイヤーにかかわらないとな〜と思っているところ。


2017年

特にこれといった目標があるわけではないけど、今年は40歳になる節目の年だし
忙しいを言い訳にせず何か一つでもやり遂げたい(やりたいことはたくさんある)。
仕事も家庭も充実した一年にしたい

Nginx実践入門

nginx実践入門 (WEB+DB PRESS plus)
久保 達彦 道井 俊介
技術評論社
売り上げランキング: 18,258


この度はご恵贈いただきましてありがとうございます。
途中からですが、自分もレビュアーの一人として参加いたしました。

本書についての雑感

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年

※仕事納めしながら書いてる


今年はまれに見る激動の年だった。
とくに後半は何してたかもあんまり覚えてない。

登壇

自分にしては例年よりか登壇して喋ったような気がする。
しかも嬉しいことにお声がけ頂くことも。。

ただ、話すのがそんなに得意ではないのもあり
毎回トーク後に反省してました…
もっとうまく喋れるように来年はがんばります。

仕事

前半に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はその手助けをしてくれるでしょう。

YAPCについて

自分はWeb業界に入って間もない頃、perlを使ってアクセスログ解析ツールなどを開発してました。
そんなころにYAPC(たしか2009)を知って初参加し、とても刺激を受けたのを覚えています。
今の自分にも多大な影響を受けたカンファレンスでした。
今回で終了とのことで残念ではありますが、フィナーレに相応しい素晴らしいイベントだったと思います。
関係者の方々、参加者の皆様、本当にお疲れ様でした!!!

#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

Redmineと連携している場合)

a. リポジトリへの権限付与
sudo gpasswd -a www-data gitlab-www
# redmineとgitlabの連携アクセス
sudo gpasswd -a redmine git
sudo chmod +rx /var/opt/gitlab/git-data

isucon4予選問題のLua(Lapis)バージョンを書いてみた

isuconアプリを書いてみましたシリーズ。
生でOpenresty+Luaで書いても良かったんですが
せっかくなのでLapisというWebフレームワークを使ってみました。
実は自分も初触り。

最初にLapisの概要など

http://leafo.net/lapis/


LuaのWebアプリケーションフレームワークです。*1
バックエンドはOpenresty(Nginx)を利用しています。既に速そうな感じがしますね…!
WebFrameworkBenchmarksでも割と上位にいます。

Lapis、実は生のLuaスクリプトではなく moonscript で書くのを推奨しているようです。
JavaScriptにおけるCoffeeScriptのようなものですね。
構文も似ているのでJS書いている人には取っ付き易いかもしれません。

コーディング/サーバ起動

moonスクリプトを書いたあとに

moonc *.moon

を実行するとコンパイルされます。
その後

lapis server <env>

を実行すると nginx.conf を nginx.conf.compiled にコンパイルし、
Webサーバを起動します。

もっと便利にコーディング
moonc -w *.moon

を実行しておくと、カレントディレクトリ以下をウォッチして
moonscript > luascript に自動コンパイルをしてくれます。
また、nginx.confに

lua_code_cache off;

を設定しておくと
サーバリロードしなくてもLuaスクリプトを反映してくれるので便利です。
開発中は offにしておくとよいでしょう。



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速いけどまだちょっと手を出しにくい…という人には
割とマッチするかもしれません。
ぼくはオススメはしませんが!!!

*1:ほぼデファクト