2016年お金の使い道ランキング
2015年は、買って良かったもの書きましたが、2016年は、自分の時間を取り戻そうに感化され、価値のある出費TOP3に変えてみました。
2016年は子供が生まれたこともあり、そっち関係の出費の価値が高かったです。1位に関しては本当ケチらなくてよかったと心底思いました。
価値ある出費TOP3
1位 飛行機ビジネスクラス (13万)
子供の出産立会いで、嫁の実家に向かうために、初めて飛行機のビジネスクラスを使いました。破水していたので、時間が読めないこともあり、なるべく早い便を探してビジネスしかなかったので使うことに。エコノミーだと5万ぐらいだったので、+8万でした。しかし、結果出産に間に合い（エコノミーの便だと間に合わなかった！）、初めての子供の出産に立ち会えました。個人的にかなり価値にある出費でした。
2位 ベビーカー(7万)、抱っこ紐(2万)
子供が生まれて、ベビー用品のありがたみがよくわかりました。細かいものもそうですが、ベビーカーと抱っこ紐が当たり前ですが重宝しています。これがないと外に出られない。自由がなくなる。
3位 歯医者（保険効いてる分だと計1万ぐらい）
嫁が近所にいい歯医者を見つけてくれて、そこに通い始めました。もう少しで虫歯がやや深刻になるところだったのと、全体的にクリーニングして思った以上に綺麗になったので、良かったです。長期的な歯や健康面を考えてもいいことでした。
番外
iPhone7
iPhone5sから変更で、SIMフリー継続。12月後半なのでギリギリですが、ApplePayでsuicaが使えることでガラケーのモバイルスイカを終わらせられることもあり、順当ながら。あとは年始ですが、ApplePayに登録したクレジットカードでQuicPayが使えるようになって、ポストペイ型のチャージレスが思いの外便利なことに気づきました。買い物で日常的suica使ってたので、月に3,4回ぐらいチャージしてたんですが、地味に手間だったんだなーと。iPhoneSEと最後まで迷ってましたが、7にして正解でした。
今回初めて128GBにして、子供の写真とビデオ撮り放題。前まで16GBで十分だったんですが、動画撮りだすと足りない足りない。
自分の時間を取り戻そう
生産性に関して、平易に書かれています。忙しいし楽しくないし実入りも少ないと感じている人にはオススメ。自分の中で感覚でしかなかったものがちゃんと説明されていて、他の人に伝えたい時にこの本を渡せば済むのはありがたいです。読んですぐに実家の家族用に追加注文しました。このエントリ自体もそうですが、価値のあることにお金を使ったか？という投げかけはすごくいいと思いました。
デフォルト値の怖さ
何も設定せずに動かせることは便利ではある
様々なサーバアプリケーションや、ミドルウェアを使う場合に、設定がない場合のデフォルト値が用意されていることがあります。
広く配布して使われるアプリケーションは、様々な人達が使うこともあり、なるべく何もいじらずにとりあえず使い始める（試す）ことができるようにされていることが多いです。特にローカル環境やサーバ1台でとりあえず動くようになっている場合があり、これは開発者が自分のマシンで試すことを前提にしている場合があります。
これと似た様に、開発者がローカルや開発環境で動かしやすいように、設定がなければローカルや開発環境のデフォルト値を使うように実装してしまうことがあります。サンプルの設定ファイルではなく、設定がない場合に勝手に使う値として。これは開発者にとって便利な反面、事故を誘発する場合があるので、気をつける必要があります。
開発より大事な本番リリース
このデフォルト値で事故が起こるケースがあります。それは本番環境にリリースする時です。本来は本番環境向けの設定で、他のサーバに接続すべきところを、デフォルト動作があることによって、気づかずにローカルや開発環境の設定で動作してしまうケースです。
基本的に開発と本番ネットワークは分離されているべきなので、DBなどは問題ないかもしれませんが、特定の状態をローカルに持ってしまうといった動作が考えられ、冗長、分散構成を取っていると問題になる可能性があります。
例えば、以下のような、複数台で共有しなければならないものです。
もちろん、設定の確認や動作の確認は行うべきですが、一見すると動作しているように見える場合もあるため、事故を誘発する危険性があることを理解しておく必要があります。設定ファイルを置いたつもりで、Pathや設定変数名が違い、デフォルト値で動作していたということも考えられます。きちんとチェックすべきだ！という話ではありますが、現実全てを行えない状況もままあります。
設定自体を間違えている場合はどうしようも無いですが、運用では様々な人が関わり、開発者自身が忘れてしまうことも当たり前です。そういった時に、少しでも事故の可能性を減らすようにしておくことは重要です。
動き続けることが重要か、きちんと動作することが重要か
個人的には、暗黙的なデフォルト値で動くよりは、無ければ落ちて動作させない。という方針をとっています。確実に気づくためです。また、アプリケーションのデプロイと設定の配置を別々に行うようにしています。アプリケーションと一緒にデフォルトの設定ファイルを置いて、後から本番設定に上書きするといった手順でも同じように事故を誘発します。
ちなみに、設定内容次第では、動き続けることが大事な場合もあるため、もしこういうことが起きたらどうあるべきかを考える必要があります。
2015年技術でやってきたこと
毎月やらないとと言っていた振り返りが結局また年をまたぐという状態です。前半何やってたか記憶がないぐらい衰えを感じるので、2016年は四半期ぐらいにはまとめようと思います。。。
キーワードだけあげるとこんな感じ
- さらにgolang
- プライベート開発
- Aurora移行
golang本格化、WebAPI作成
2014年から、golangでWebAPIを作りだして、そこからサービス全体の各機能を順に実装していきました。また、他の人にもgolangを広めることも行っていきました。Webフロント側はPHPで作られているため、バッチやツール等でもPHPを使いがちだったところを、なるべくgolangに置き換えるように促しました。その甲斐あって、今では5人ぐらいgolang書けるようになっていて、今後もフロント以外はgolangでやっていきたいです。
省力化、ラッパーコマンド
ansibleを使ってデプロイの省力化を行っていますが、ansible-playbookコマンドが全部打つと長いこともあり、特定の環境によく使うものを短いコマンドとオプションで実行できるようにラッパーコマンドを作りました。 また、必ずplaybookを作ってそれを使って開発環境で開発を行うように促し、golang同様に使える人を増やしていきました。最初は少しハードルがありますが、開発中は何度もデプロイするのでplaybookに慣れると、自分でメリットを実感しやすく、覚えてもらえました。
AWSの設定周りは、roadworker, miam, piculetを使いコード化して、変更を記録できるようにしました。
冗長化、マイクロサービス化
2014年は冗長化周りを行っていましたが、2015年はマイクロサービス化も進め始めました。マイクロサービスに何を求めるかというと、部分的な置き換えです。一番最初は新卒と外注で作られたため、いろんなところに問題点が潜んでいます。それを一気に刷新するほど、お金も人も余裕がないため、一部分をマイクロサービス化して置き換えていくことで、全体を刷新しようとしています。データ構造も修正していくため、2016年以降もかかりそうです。
監視周りnagios(Icinga)
10月に、監視周りの構築（と検索エンジン全般）を任せていたエンジニアが辞めたので、そこから少し監視周りを見ることになりました。 監視の設定更新などは、ansible+ラッパーコマンドが用意されていたので非常にスムーズでした。Icingaはnagiosベースなので、チェックはコマンドの戻り値で判断されます。やってみると簡単に実装できるため、サーバ側の開発者には自分で作らせるようにしました。逆にIcingaの設定ファイル構成などはものすごくわかりづらいのでその点はどうにかしたいところです。
Amazon Aurora移行
RDS(MySQL)のDB容量不足の懸念が急に来ました。急激ではないですが、ありがたいことに利用者増によって、ほっとくと2016年1月にサービスが死ぬ可能性が出るぐらいに。当初、容量を増やしたRDS MySQLに移行するつもりでしたが、利用者数によっては1年ほどでまた同じ問題にぶつかる可能性がありました。さらに、PIOPSをつけると、使っていない容量の分まで利用料金が発生して、あまりよい出費ではありませんでした。
そんな検討の最中、注目していたAuroraが10月にTokyoリージョンに来ました。Auroraは容量をあらかじめ決める必要がなく、自動で拡張されます。さらに、PIOPSは不要かつ、Slaveがホットスタンバイになるので、MultiAZ待機側の料金も減らせます。加えて、接続数が増える、データが増えた場合のパフォーマンス低下も抑えられているということで、今後のスケールにも対処可能。まさに夢のような解決策が降ってきました。
そこから、移行に関してはどうしてもサービス停止が必要になるため、年末に計画停止（※）を挟むことにして、移行手順の確立や動作検証を進めていきました。無事年末に移行を終えて（今の所）問題なく稼働しています。 ※ビジネス系のサービスなので、年末はトラフィックが下がる
プライベート開発（rnssh, rnzoo, cstoreなど）
プライベートでも、自分のツール開発を再開し、rnsshとrnzooに機能追加や改善を行いました。11月に活発に開発を行いましたが、12月はAurora移行であまり手をつけられませんでした。2016年は、cstoreのようなよく使う部分をライブラリ化して、プライベートでも仕事でも使えるようにしていきたいと思っています。
2016年は
面白そうなことをやってくスタンスはあまり変わらないです。
マイクロサービス化を進めると同時に、プロダクション環境にDockerを投入していきたいと考えています。Docker自体は前からありますが、AWSでの環境が揃い始めたことや、ノウハウが十分に公開されてきているので、踏み切れるかなと思います。
ディープラーニング周りもやりたいんですが、正直よくわからないので、詳しい人と話せる機会を持っていきたい所です。画像認識周りはサービス内でやらざるを得ない状況になっているので、その辺りでやることにはなるかもしれません。
あとはブロックチェーン周りも応用がききそうなので、詳しく見ていこうと思ってます。
振り返りもそうですが、普段の調査検証もwebにアウトプットする癖を付けないと。
