以前下記で書かせていただいた

goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話

ですが、上から下まですべてを担当して個々の技術をすべてやった経験自体も勉強になったのですが、
どうして、そのような技術選択をしたか？という点が自分でも振り返ってみて学ぶ点がありました。
それぞれ良し悪しがあったので何かしらの参考になればと思い、それ以後の技術変遷や取捨選択を踏まえて、振り返ってみたいと思います。

なにかしらの参考になれば。

ちなみに未だに一人です。

今回の技術選択をした時の基準や自分なりの戦略

スピード重視。これは今回に限らず自分自身の戦略です。基本通常の人の３倍のスピードでやる気概でやってます。
ユーザーグロース重視。これはサービス立ち上げからやるので当然。
コスト重視。今回フリーになってコストまできちんと意識するようになったのでこちらも基準として重視。
全ての開発作業をやっているが、すべて自分の勉強になるようなことをちょこちょこ織り交ぜて、モチベーションも保つ。
最初からできればいいけど、ほぼむりなので、ひとまず自動化やスケール化を先にできるかできないか、やりやすいかなどを調べておく。そこまでやっていれば、あとから改善できるのでひとまず運用で乗り切れるならそちらを選択。なにぶん一人なので。。

この戦略は自分がずっと持ち続けてる基準と今回の制約条件のもとで決めた基準の２つに分かれます。

リリース当初の技術選択

設計上以下の基準を設けて、設計を考えました。

コストまで意識してやるため、パフォーマンスやコストメリットが出るほうの設計を選択する
音声サーバー、マイクラサーバーなどは、肝なのでスケールしやすい設計を最初から織り込む。
サーバーサイドやインフラ周りなどの作業もあり、また通常あまり作っていないアプリで、審査などで時間も食いたくないので、アプリは固めの設計で考えました。

クラウド

AWSで行く。まあ一人なので、他に選択肢はなかったのですが、コスト面の心配はあったので、あまりロックインせずに、設計した。

サーバーサイド

パフォーマンスやサーバーコストを下げたかったので、使ったことはなかったが、go言語選択。あとgoは使いたかったし実際楽しい。
フレームワークをシンプルなものを使う。一人なので、機能がないものは作ればいいし、変にフレームワークの学習を行ったり、地雷を踏むより見通しが良いほうがいいので選んだ。
音声サーバー、マイクラサーバーのスケール設計、後述のクラウド分離も視野に入れて最初から設計。ここは肝なので手を抜かず調べました。

コードまわり

サービスごとにgoのアプリケーションを分離。それぞれのサービスが別のものすぎるので当たり前ですが。
DB周りは見通しをよくしておく。ゴリゴリのORMはつかわない。これは今までそうしてきているので自分の中では当たり前。
コードレビューなし。なにぶん一人なので。。。
テストは書けたら書く。ここはちょっと後悔ポイント。もうすこし基準を設けるべきだった。

アプリ

Objective-Cを選択。今はましだが、Swiftのビルドの遅さなどを鑑みて。Swift自体のアップデートのつらみや、Swiftへの理解の時間を省けたので、この選択はひとまずよかった。

CI

Circle CI導入。ここは毎回導入してるので、問答無用に使用。

デプロイ、構成管理

構成管理、デプロイもAnsibleで。Ansible自体はとても使いやすく、とにかくこれだけメンテしてればいいので、ひとまずデプロイもansibleでやってます。

フロントエンド

フロントエンド周りはサーバーサイドから分離してあつかう。gulp,webpack,bowerは自分でやる場合の一通りのセット.
jsのフレームワークなどはなし。それほどweb側で大層なものは作っていないので。
JSはcoffee scriptで書いてたが、これは将来性をみると正直やめておけばよかったかなと思っている。

サーバー監視

zabbixを利用。細かい点をカスタマイズしたかったから使ったが、メンテナンス性と見た目の部分であまり気に入ってはいなかった。

数値解析

fluentd,monboDBにデータを突っ込んで確認。数値解析自体は最初から行ったが、この構成だと結局面倒で解析自体も自分でやってるので手が回らなくなった。

管理ツール

つくらない！というか間に合わなかった！

このような技術選択をそれぞれで選んでいきました。
全面的にスピードはかなりはやくでき、ひとまずよかったのか感じです。
ただサービスは出して終わりではありません。

サービスがを続けていく中で、さらに技術の取捨選択、当初の判断がよかったのかどうかも見えてきました。

リリース以後

言語選択

goは楽しいし、使ってて非常によい言語であることは実感できました。ただエンジニアを探すとなると、まあまあ苦労しているので、その点はマイナスかなとは思っています。ただやる気のある人が今後来てくれることは期待しています！

マルチクラウド化

DB直アクセス部分をAPI化し、サービスを分離。別クラウドを利用することで大幅にコストを削った。これは最初から設計していたことが功を奏しました。これは最初の設計が生きた点です。

まだAWSのみに頼って生きてるの？複数のクラウド利用で、大幅コストダウンした話

パフォーマンス改善

ユーザー数の増加に伴い、とにかくDB周りのパフォーマンス改善を先に。設計自体きちんとやっていてよかった。現状もユーザー数や機能が増えても、当初はサーバーのスケールアップで乗り切っていたのを、逆にスケールダウンして運用できています。
それでもpushからの一斉アクセスなどどうしようもなくなってきた時に,初めてキャッシュの導入。あんまりこれも後々見通しが悪くなるので、アプリ起動時やpushからのアクセス時にきつくなる部分からすこしすこしすすめて居ます。
データのクリーニングも空いた時間を見つけてやる。ついつい後回しにしがちなのですが、おろそかにしてパフォーマンスが遅くなっていくことを良しとしない。

自動化

クラウド移行したものの、AWSよりサーバー追加など面倒な部分があったが、cloudstack APIが使えるクラウドだったので、あとから自動化。クラウドの移行するにしても運用上インパクトがあるところがないかを調べておく。

サーバー監視

mackerelに移行。移行先のクラウド向けに特別枠があったので即座に移行！これは、もう戻れません。管理周りも日々重要な要素なので、よりよくできるのであれば、強気に変更していきます。

数値解析

elasticsearch + kibanaに変更。こちらも当初の構成だと全然数値が見れなかったので移行。サーバーコストが当初よりまあまあかかるのでこちらもコスト的に見合ってきたら移行予定だったので、タイミングを見計らい移行。

管理ツール

最初はなかった。遅れて作ったが正直もっと充実させたいが必要なものだけ。

コード周り

リリース時に比較的まずいバグを出しました。。ここはもっとテストを充実させるべきでした。。特に重要な部分はカバレッジを高めにするなどのルール付けをしておいてよかったと完全に判断をあやまったかなと思う点でした。。

以上、リリースしてからも戦略としてクラウド移行するなどドラスティックに変更するところは変更するなどやっていますが、それは当初からの基準をベースに都度判断しています。

一人なのでできることは限られますが、とにかくリターンが大きければ、色々と踏み込んでいます。

終わりに

開発における手法や設計方針、ノウハウなどは様々なものはありますが、それを取捨選択することが結構難しかったりします。使える人的リソースやお金的なものによって、それらを使うか使わないかの判断基準もその場その場で変わってくると思います。
ここで書いた判断基準がみなさんの場合でそのまま当てはまることもないと思いますので、自分なり、プロジェクトチームにおける基準や戦略がない場合は、一度考えてみるのもいいかと思います。

皆さんの戦略や基準などあれば是非聞かせてください！

そして、エンジニア引き続き募集中です！人が増えたらまた戦略も変わるでしょう。

エンジニア募集！