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にアウトプットする癖を付けないと。

2015年に購入してよかったもの

去年に引き続いて何点か。今年はそんなにもの買ってないかなーというところ。来年引越しする時に色々買い換えるので、その時にまた便利にしたいところです。

ドラム式乾燥機能付き洗濯機

Amazon.co.jp： Panasonic ドラム式洗濯乾燥機 9kg 左開き クリスタルホワイト NA-VX3500L-W: 大型家電

多分一番有効に時間を使えるようになった買い物。15万ぐらいしましたが、全然ペイしてます。何がいいかというと、天気に関係なく、洗濯が完了すること。ヒートポンプ式で、3時間ぐらいで乾燥まで完了。

今までは、干すために晴れた休日を使ってましたが、それがいつでもよくなったので、休日が有効に使えます。梅雨や雨続きでも関係ありません。大体平日昼ぐらいにタイマーかけて、帰ってきたらたたむという流れで、時間がだいぶ浮きました。

今は新しいモデルが出てるようで買ったやつは、もう生産終了の様子。

iPad mini 4

iPad mini 4 - Apple（日本）

iPad mini初代からの買い替え。2,3が初代より厚く重い点がネックで渋ってましたが、やっと軽く薄くなり、TouchIDも付いたので買いでした。 さすがに初代と比べると全然スピードが違うので、家でちょっと調べたりニュース見るのには最適です。

NEC モバイルルータ

Amazon.co.jp： NECプラットフォームズ SIMロックフリー LTE モバイルルーター Aterm MR04LN ( デュアルSIM 対応 / microSIM ) PA-MR04LN: パソコン・周辺機器

タイ行きでSIMフリー購入しましたが、iPhoneの方だけで済んだので、単なるバージョンアップ。 仕事柄常にMacでリモート作業が必要なのもあり使ってます。単にちょっと使いたいだけの人は、iPhoneでテザリングでいいと思います。（通信量制限は気をつけないといけません）

iPhoneは、OCNの最小プランで済ませているので、これは別のSIMを刺して使ってます。電池の持ちもあるので、私は分けたい派。まだデュアルSIMでは使ったことはないです。

買った後、amazonが値引きセールしていて、値段的にも2万前後ぐらいに下がってるようです。

ベッドマットレス

フランスベッドで高いのを買ってみて、寝心地がすごくいいです。人生1/3ぐらいは寝てるので、睡眠に投資するのはいいと思います。展示場で寝転がってみて、えいやで買いましたが、2,3日買う前に使えたらいいのになと思います。来年は掛け布団も少しいいやつにしてみようと思います。

取り寄せ海老 2kg

【楽天市場】ギフト【送料無料】どっデカ！生赤えび2kg〈天然有頭〉焼きでも刺身でも/新鮮船上凍結(約45尾〜55尾)2キロ/海老/えび/エビ/あかえび/赤えび/赤エビ/刺身/唐揚げ/bbq 海鮮/バーベキュー セット/200904/rdc/がってん：カニとマグロの『がってん寿司』

贈り物でもらって、自分でもリピートしてる海老。大体50匹ぐらい入っていて、サイズ的にも冷凍庫に入りやすいです。流水で解凍すれば生で食べられて、焼いても茹でても甘くて美味しい。取り寄せはカニが目立ちますが、この海老はコスパ良くておすすめです。

釣り道具各種

趣味的な物欲は全て釣り道具だった2015年。竿とリールが5セットぐらいとバスルアー、ソルトルアー、船タイラバと結構買いました。一応バスもサバもタイも釣って（釣れないのも含めて）楽しめたので満足してます。

技術本

暗号化入門など、色々買いました。やろうと思ったことが書籍化されて、それを参考にできるという流れに乗っているので助かります。最近は本当に数が多く触りだけのも増えましたが、ややニッチな感じの詳しい書籍も多く出ているので、気になったら買って会社に置いてます。

来年

引っ越すので、冷蔵庫を買い替えたり、ルンバを導入したりしようと画策中。食洗機は付けられるかどうかがまだ不明。どんどん機械や外部サービスに任せてやりたいことをやれるようにしていきたいところ。

データに対する時間がたくさんある

ちょっとハマったので、整理というか殴り書き。

一つのデータにも様々な時間が関わります。

スマートフォンアプリから、WebAPIを経由して、DBおよび検索エンジンに至るまでのデータに対する時間

- ユーザが作成した時間
- アップロードした時間
[↑スマートフォン端末側]
-------------------
[↓サーバ側]
- APIが受け付けた時間

- DBMasterに記録された時間
- DBMasterで参照可能になった時間

- DBSlaveに記録された時間
- DBSlaveで参照可能になった時間

- 検索エンジンに反映された時間
- 検索エンジンで検索可能になった時間

これらの時間を取り違えると、挙動がおかしくなります。

スマートフォンの時間、サーバの時間

大きな点として、スマートフォンと、サーバシステムでの時間の扱いがあります。

基本的にスマートフォン側の時間は、ずれることもあることや、基本的にサーバ側からは操作不可で、それを考慮する必要があります。また、スマートフォンはオフライン時に操作してそれを後から送信するといったユースケースがあるため、一概にサーバ到達時刻に置き換えることができません。

もちろん端末の時間がずれていたら別なので、その対処も必要です。日記などの時刻の場合は、ユーザが意図的に変更していても問題ないですが、特定のイベントに関することや、厳密にその時間に行ったことを証拠とするケースでは端末とサーバシステム側の時刻の整合性が必要です。

サーバ側では、基本的に複数台で同一の時間になるようにNTPで調節します。そして、システム的に記録した時間が重要になってきます。例えば、APIで受け付けた時間を、ユーザが作成した時間と取り違えると、実際にユーザが作成したは時間はいつなのか、消えて無くなります。

DB上に記録された時間も同様です。DBに記録された時間はユーザが作成した時間とは異なりますし、APIが受け付けた時間とも異なります(少なくとも数ミリ秒は)

また、DB上に記録された時間で厄介なのがトランザクションです。MySQLの場合、NOW()で、その時間はMySQL側の現在時刻に合わせることはできますが、トランザクションが完了するまで、別の接続からはそれを見ることはできません。つまりデータは存在する（予定）ですが、その時点では見えない状態です。 つまり、他の接続からは、この時間からこの時間の間に作られたデータを参照しても、ある時点では存在しないことになっていたが、後から存在していたことになった。という状況が生まれます。

単純に、1分前から今までに作成されたデータを参照していたら、参照インターバルをまたぐデータ作成・更新があると抜けるケースが出てきます。

さらに検索エンジンへの反映も、時間差は生まれるので、同様にDB上での時間と検索エンジンで検索できるようになった時間がずれるので、同様の問題が発生します。

秒以下も重要

また、これらの時間を秒単位で記録している場合、ミリ秒での前後関係の問題が出てきます。

12:00:00に作成されたデータが、12:00:00に参照しても取得できなかった場合に、それが遅延によるものなのか、そもそも順番が違うのかが判断できません。

• 参照が12:00:00.001に来て、作成が12:00:00.999に行われていたのか（作成前の参照なので正常）
• 作成が12:00:00.001に来て、参照が12:00:00.999に行われていたのか（何かしら遅延があったのか）

APサーバの場合、1台の中であれば、ログファイルの順序で判断できるケースもありますが、基本的に複数台で構成されるため、それらをマージすると秒以下の順序は無くなります。

他にも

タイムゾーン、サマータイムなどが時間では大きな落とし穴になります。 あまりまとまってないのと、それでどうするのかというところは書けてないですが、とりあえず殴り書き。