大切なことはだいたいHerokuで学んだ

@shokai
右のメニューの Start presentation
でスライドになります
まとめ

使ってると
エラーコードで学ばせてくる
悪い設計をさせてくれない
運用しやすい設計になる
学生はHerokuでアプリ動かして勉強してたら、働く時も楽そう
自分は実際そうでした

本当にありがとうHeroku
本編
Scrapbox
WiKiみたいなノートアプリです
関連ページ推薦、同時編集
規模
ユーザー数
◯万人ぐらい
ページ数
約110万(wikipediaと同じぐらい)
インフラ構成
Standard1X Dyno 18台
Heroku scheduler 3つ
上の環境のコピー(テスト用環境)
Dyno数とmlabのプランだけ小さいが、同じ設定のコピーがある
セミオンプレ版
Heroku上の別App
pipelineで同じコードが同時デプロイされる
オンプレ版
Dockerイメージを提供
CircleCIでビルドしてdockerhubにpushしてる
感想

同じ環境のコピーを作ったり、同時デプロイするのが楽ですね
特にセミオンプレ版の運用が楽で最高
開発メンバー
フルタイム


夏インターン→アルバイト



の主な役割
twitter検索してユーザーサポート
コンセプト構築・実装・運用
運用専門メンバーがいない
運用が自動化する機能をアプリケーション本体に実装する
githubでプルリクして、CI通ればslackコマンドでherokuにデプロイされる
おかげで、インターン2日目にはdeployまでいける
失敗してもすぐ戻せる
$ heroku rollback
とても気楽
それまで大学でUIの研究してた
運用とか設計等の実務経験無し
職を得てからScrapboxの開発・運用を開始
問題なくやれている
なぜなのか?
この2つが大きい
1. 設計で地雷を踏んでない
2. 危機が迫る前にalert等で察知できた
(元々、個人で多少Heroku使ってたというのもあります)
Herokuに正しい設計を強制される
appサーバー内にstateを持たせてくれない
app dynoを増やすだけでスケールする設計になってしまう
無料枠でできる事がproductionとそんなに変わらない(気がする)
何でだよ!と思った所に
ちゃんと理由が書かれてる
もしくは、テクニカルタームが書かれていてググるとわかる
エラーを減らしていく活動
できたてのアプリ
heorku dashboardがエラーだらけでカラフル
socket.ioのcommet pollingが原因だった
学ぶ
エラー個別に社内Scrapboxにページを作る
どういう条件で発生するかまとめていく
だんだん平和になってくる
ここまでのまとめ
Herokuは
何が起きて、どう悪いのか説明されてる
どう設計すべきかも説明されてる
多少リンクたどる必要はあるが
読むとわかってくる
この辺は時間余ったら話す
不思議
herokuでやってると、強制的に
スケーラブルで運用しやすいアプリにされてしまうが
なぜかHerokuへのロックインも無くなっていく
ロックインがなくなっていくのに、Herokuに乗っておく方が良いなと思えてしまうのがすごい
現状で運用が楽というのもあるが
根底に技術的正しさ、公正さを感じるので、信頼できる
プログラミング初心者にオススメしたい
初心者が初期に間違える可能性をアーキテクチャレベルで潰している
同時にドキュメントで理由が説明されている
レンタルサーバー借りてLinuxに慣れましょう、とかは、コンテナの時代なのだからローカルでやればいい
Herokuにデプロイして正しい型を身に着けろ
余談
似た考えをScrapboxにも応用している
Wikiがスケールしなくなる機能を実装しない
例
階層分類できない
ページ毎の細かいuser権限が無い
行のメタデータとして編集者名を出さない
後々禍根を残す事ができないようにしている
Herokuへの要望
deploy中はレスポンスをrouterが握ったまま返さないのではなく、サッと500系エラーを返してほしい
ServiceWorkerで適当にハンドルしてリトライするので
すごく古いログが後でほしくなる事がある
4ヶ月前ログの問い合わせが来たが、もうない
serverの変更がなく、clientだけ更新の場合だけONにするとかやりたい
と思ったけど、ややこしいから不要な気もしてきた
