大切なことはだいたいHerokuで学んだ
shokai.icon @shokai
右のメニューのStart presentationでスライドになります
まとめ
Heroku.icon使ってると
エラーコードで学ばせてくる
https://gyazo.com/81f27f51c12fab10d496f825cff77e24
悪い設計をさせてくれない
運用しやすい設計になる
学生はHerokuでアプリ動かして勉強してたら、働く時も楽そう
自分は実際そうでしたshokai.icon
本当にありがとうHeroku
本編
Scrapbox
WiKiみたいなノートアプリです
https://gyazo.com/86faa398b233f86be3ad4a15cd2e777e
関連ページ推薦、同時編集
https://gyazo.com/343caf0f14cc565ce656a43e9a02aad2https://gyazo.com/471d8cab15bf364febe29e6f2cafb5ad
規模
ユーザー数
◯万人ぐらい
ページ数
約110万（wikipediaと同じぐらい）
インフラ構成
Standard1X Dyno 18台
Heroku scheduler 3つ
上の環境のコピー（テスト用環境）
Dyno数とmlabのプランだけ小さいが、同じ設定のコピーがある
セミオンプレ版
Heroku上の別App
pipelineで同じコードが同時デプロイされる
オンプレ版
Dockerイメージを提供
CircleCIでビルドしてdockerhubにpushしてる
感想shokai.icon
同じ環境のコピーを作ったり、同時デプロイするのが楽ですね
特にセミオンプレ版の運用が楽で最高
開発メンバー
フルタイムshokai.icondaiiz.icon
社内の他プロダクトも兼務rakusai.icontakeru.iconTiro.iconhiroshi.icon
夏インターン→アルバイトprogfay.iconyutaro.icon
shokai.iconの主な役割
twitter検索してユーザーサポート
コンセプト構築・実装・運用
運用専門メンバーがいない
運用が自動化する機能をアプリケーション本体に実装する
githubでプルリクして、CI通ればslackコマンドでherokuにデプロイされる
https://gyazo.com/39edc9ec7e78b14864c70f5411f15863
おかげで、インターン2日目にはdeployまでいける
失敗してもすぐ戻せる
$ heroku rollback
とても気楽
shokai.icon
それまで大学でUIの研究してた
運用とか設計等の実務経験無し
職を得てからScrapboxの開発・運用を開始
問題なくやれている
なぜなのか？
この2つが大きい
1. 設計で地雷を踏んでない
2. 危機が迫る前にalert等で察知できた
（元々、個人で多少Heroku使ってたというのもあります）
Herokuに正しい設計を強制される
appサーバー内にstateを持たせてくれない
app dynoを増やすだけでスケールする設計になってしまう
無料枠でできる事がproductionとそんなに変わらない（気がする）
何でだよ！と思った所に
ちゃんと理由が書かれてる
もしくは、テクニカルタームが書かれていてググるとわかる
エラーを減らしていく活動
できたてのアプリ
heorku dashboardがエラーだらけでカラフル
https://gyazo.com/81f27f51c12fab10d496f825cff77e24
socket.ioのcommet pollingが原因だった
学ぶ
エラー個別に社内Scrapboxにページを作る
どういう条件で発生するかまとめていく
https://gyazo.com/27817371e0cb862f0af64fb41e504c2c
だんだん平和になってくる
https://gyazo.com/f05409abc28ce75383b8a44f98744e9f
ここまでのまとめ
Herokuは
何が起きて、どう悪いのか説明されてる
どう設計すべきかも説明されてる
多少リンクたどる必要はあるが
読むとわかってくる
この辺は時間余ったら話す
不思議
herokuでやってると、強制的に
スケーラブルで運用しやすいアプリにされてしまうが
なぜかHerokuへのロックインも無くなっていく
ロックインがなくなっていくのに、Herokuに乗っておく方が良いなと思えてしまうのがすごい
現状で運用が楽というのもあるが
根底に技術的正しさ、公正さを感じるので、信頼できる
プログラミング初心者にオススメしたい
初心者が初期に間違える可能性をアーキテクチャレベルで潰している
同時にドキュメントで理由が説明されている
レンタルサーバー借りてLinuxに慣れましょう、とかは、コンテナの時代なのだからローカルでやればいい
Herokuにデプロイして正しい型を身に着けろ
余談
似た考えをScrapboxにも応用している
Wikiがスケールしなくなる機能を実装しない
例
階層分類できない
ページ毎の細かいuser権限が無い
行のメタデータとして編集者名を出さない
後々禍根を残す事ができないようにしている
Herokuへの要望
deploy中はレスポンスをrouterが握ったまま返さないのではなく、サッと500系エラーを返してほしい
ServiceWorkerで適当にハンドルしてリトライするので
すごく古いログが後でほしくなる事がある
4ヶ月前ログの問い合わせが来たが、もうない
serverの変更がなく、clientだけ更新の場合だけONにするとかやりたい
と思ったけど、ややこしいから不要な気もしてきたshokai.icon