インフラ管理よりも価値を生み出すことに時間を
まず大前提として、ユーザーはバックエンドのインフラがEC2で手動でデプロイされていようと、Lambdaで実行されていようと「どうでもいい」ということ。インフラの技術自慢はユーザー視点・ビジネス視点からは乖離している。
未経験駆け出しエンジニア転職界隈では「Herokuにデプロイしているポートフォリオ」を揶揄されているらしいが、その面接官全員に説教したい。「ラクできることって素晴らしいじゃん！」と思っている。エンジニアは手抜きできる人の方が優秀なのだ。
その上で理解してほしい価値観として、
インフラ管理は要求を満たした上で最小限にし、アプリケーション(ユーザーが体験できる価値)を充実させることに時間を集中しよう
というのがサービス開発者の価値観であるべき。と思っています。
PaaSもKubernetesもCI/CDもトータルでプロダクト開発を"ラクするため"のツールなんだよ。みんなインフラ管理でラクしてもっと価値あるコードいっぱい書こうぜ！
自己紹介とアプリ紹介
職歴
- コナミでゲーム(C/C++)作ってた。
- ヤフーで数千台規模のIaaSサービスの運用＆それをKubernetesに移管するプロジェクトやってた
- スタートアップでリードエンジニアしてた
- 副業で作ってたアプリで稼げるようになって独立 - 株式会社GENIT
ピアノあそび
子供向けの音楽アプリ(子供向けの超簡単な音ゲーのイメージ)
↓くらい遊んでもらえています。
| パラメータ | 概数 |
|---|---|
| 累計DL数 | 50万DL |
| DAU | 1万人 |
| 月間遊ばれる回数 | 100万プレー |
インフラ構成の考え方
まず、そもそも考えることは、そのサービスにサーバーいるの？というところから。
その判断基準は単純で
UGCがあるか？
これ。要はユーザーが何かを入力して保存して、それを"他の誰か"が見る必要があるのか？
"他の誰か"が見る必要がないなら、ローカルストレージで事足りる(体重管理アプリとか)
ピアノあそびに関しては、ユーザーが入力したデータを他の人が見ることはない。(ランキング機能とか)
が、以下の2点でクラウド化する必要がある
- JASRACの契約上ストリーミング方式(都度楽曲データをクラウドから取得)する形にしたい。音楽データをローカルに保存すると「複製権」というのがかかるらしく、支払額がバク上がりする。
- 季節の曲の追加など(クリスマス曲等)をアプリのアプデなしでやりたい。
ということ。
なので「ピアノあそび」の要件は
UGCはない。でもデータはクラウドから取得したい。
ピアノあそびのインフラ構成
オチはとてもシンプルで、クラウドからクライアントへのデータが一方通行なんだから、サーバーなんて用意しなくて、s3に置いて配信するだけでいいじゃん。ということ。
- 開発PCでRails+sqliteのアプリを起動してデータの管理はそこでやっている(.sqliteはGitの管理対象にしている)
- ボタンをポチって押すと、DBからjsonを生成して、s3に保存
- クライアントからはCloudFront経由でGETリクエストで取得。GETリクエストでJSONが返るので、それはもうWebAPI
s3 + CloudFrontなので、普通にサーバーで運用しているより可用性が圧倒的に高い＆サーバー障害が…とか気にしなくていい(s3が落ちたらそれはもうしょうがない)
管理ツール
ローカルで超シンプルなRailsアプリ+sqlite
- ローカルで実行するからログイン機能必要ない
- sqliteのファイルを.gitignoreから外してGitで管理してしちゃう
- もちろんサーバー代かからない
viewのh1、scaffoldした時に作られたやつのままだな…
最後に
もう一度言うけど、やっぱりエンジニアは要件の範囲で手抜きできる人が優秀だと思う。
プログラマになること#9 三大美徳
会社もお客さんも、結局のところユーザーに喜んでもらって"なんぼ"なので、よりユーザーに喜んでもらえる価値を提供できるエンジニアに僕はなりたいです。
Twitterよかったらフォローしてください@ryohorie3
(フォローしてくれたら自動でフォロバするボットが走ってます)