20170622 Heroku Meetup #17 スタートアップのインフラ選び高丸翔英 How to choose infrastracture in startup

Copyright ©crispy, Inc. All Rights Reserved.
スタートアップの
インフラ選び（仮）
株式会社crispy
高丸翔英

目次
• 自己紹介
• Herokuを選んだワケ
• インフラ選び
• まとめ
2

自己紹介

自己紹介
• 高丸翔英 (たかまるしょうえい、@takamario)
• (株) crispy 共同創業取締役 CTO
• 職歴
– 赤R (某ポータルサービスでEL、某国際EC立ち上げとTM) /
PHP Perl Node.js, Ruby
– 黃P (某note 立ち上げ) Ruby / Angular.js
– 青R (某キュレーション、某サロン予約サービス TL) Java / Go
– シンガポールで起業
– 事業都合で東京へ戻る ← イマココ
4

サービス紹介（1つ目）
• Botmart
• 簡単にFacebook Messenger上に
チャットボットECサイトを
作れるサービス
• Ruby on Rails
+ Heroku
5

サービス紹介（2つ目）
• 絶賛開発中！！
6

スタートアップの開発

スタートアップの開発は
• Done is better than Perfect
• 売上が立つまでは、インフラコストは抑えなければ
ならない
• エンジニアが少ない、1人のカバー範囲が大きい
• ある程度の自動化も必要だし、ある程度やらないこ
とも決めなければいけない
• ローカル環境でもりもり開発する
8

Herokuを選んだワケ

Herokuを選んだワケ
• Botmart開発時
• Ruby (Rails) との相性が良い、ハマるところが少ない
• Gitへのプッシュでデプロイ完了するので、コマンドを忘れていること
が少ない
• ダッシュボードのUIがシンプルでわかりやすい
• Hobbyならほぼタダのようなもの
（高すぎないサービスレベル、必要があればStdプランにしてスケール
できる）
• Heroku Postgres等のアドオンが大体イケている、違和感なく使える
10
→ どちらかというと、気分的なところが大きいかも

話は逸れますが

あなたがスタートアップ
（not 社内新サービス）なら
どの言語で開発しますか？

スタートアップの言語選び
• 頭のスイッチングコストはできるだけ少なく
• Ruby(Web) ⇔ Go(クローラー)でも結構きつかった
• ましてや、マイクロサービスアーキテクチャで
別々の言語なんて…
• DBの変更が容易なもの (例: winebarrel/ridgepole)
• ルール（DSL等）がしっかりしているもの
13
コードの品質を保ちやすいもの

私の言語選び
• Ruby or Go を基準に
• FWは、機能の大きさに応じて、Rails or Padrino/Sinatra
• どうしてもパフォーマンス優先しなければいけないときがある
• Python?
• 使えるけど、普段Webアプリを書いてないので、機械学習以外
なら使わない
• node?
• npmのモジュール群は便利だけど、nodeは言語仕様的に好きじ
ゃない
• もちろん、開発人数にもよる
14

私の言語選び
• 極力JSを使わないw
• もちろん、jQueryも使わない（Rails 5.1〜）
• ちょい使いなら、今はVue.js
• 使うんなら、がっちりJSに寄せる
• サーバー（API）⇔ クライアント（React or Vue など）
• モバイルアプリ開発にも対応しやすい
• noteがこのアーキテクチャ
15

ちなみに
• 某ベンチャー系フロントエンジニアの知人
• node（API）+ React + Redux
• 「サーバ側は面倒だったけど、JSに寄せて良かった」
• 現在はAndroidアプリも作成中
16
• 某大手Web系のエンジニア (リプレイスPRJ)
• 「Railsは意外とRenderが遅かった、Java はやっぱり速い」
• Google Next Tokyoで聞こえた話
• A「AppEngineとか使ってます？」
• B「使ってみようかなぐらい、だいたいはさくらのVPSで行ける
んだよねぇ」

Heroku対応言語
• Ruby / Java / PHP が選択肢として堅い
17
↑ちなみに、これって何順？？

さて、インフラ選び

インフラ選び (PaaS全盛期 2013年〜)
• コードだけ書いてPushすればOKなんて、サイコー
じゃん
• え？なんでSSHなんかしてるの？(^q^)
• 当時は、各PFで対応言語に差あり
19

インフラ選び (Infra as Code時代 2014年〜)
• やっぱ、Infra as Codeだな
• Ansible、CloudFormation、Terraform！
• PaaS、楽だけど自由度低いもん
• 常に同じ環境作れるし、壊しても問題ないし
• ただ、VM起動に時間が…
• 同時期にDockerも流行っていた（アプローチの違い
）
• 大規模な会社なら、現在も選択肢となりうる
20

インフラ選び (2015年〜)
• Dockerコンテナ化は必至 (デファクトスタンダード
)
• PFを選ばない（PFによってコマンド違えど、同じ
ようにデプロイできる、後の移行がしやすい）
• PaaSとIaCのいいとこ取り
• k8sを使うとなると、GCPが一番有利か
• かつ、GCPだと、その他サービスにつなげやすい
(AppEngine, CloudStorage, CloudFunctions,
PubSub)
21

Heroku Docker
• 2015/05〜 Dockerコンテナのデプロイが可能に！
• 2016/07〜 Dockerイメージの登録が可能に（β）！
• [deprecated] heroku-docker
• [deprecated] heroku-container-tools
• [now] heroku-container-registry
• コンテナの登録に異様に時間がかかるときがある。。？
• 独自のコンテナをデプロイできるが、1 Dynoにできあ
がるだけなので、Herokuである意味はあまりない
22

Heroku Docker
• 参考資料
• Local Development with Docker Compose
• Container Registry and Runtime
• Heroku Dockerの使いどころ (Heroku Meetup
#15)
23
• For local development: use official Docker images, such as Postgres and Redis.
• For staging and production: use Heroku add-ons, such as Heroku Postgres and
Heroku Redis.

dockerを使うと

構成が管理しやすい、テストしやすい
25
version: "2"
services:
web:
command: bundle exec rails s -p 3000 -b '0.0.0.0'
links:
- db
- mail
- redis
...
db:
image: mysql:5.7
...
mail:
image: schickling/mailcatcher
...
redis:
image: redis:3.0.7
...
docker-compose.yml

26
FROM ruby:2.3.4
RUN apt-get update -qq
&& apt-get install -y
build-essential
libpq-dev
vim
mysql-client
postgresql-client
apt-transport-https
FROM ruby:2.4.1
RUN apt-get update -qq
&& apt-get install -y
build-essential
libpq-dev
vim
mysql-client
postgresql-client
apt-transport-https
Ruby 2.3.4 Ruby 2.4.1
Dockerfile

27
version: "2"
services:
db:
image: mysql:5.7
ports:
- "3306:3306"
web:
build: .
command: ...(snip)...
version: "2"
services:
db:
image: postgres:9.6
ports:
- "5432:5432"
web:
build: .
command: ...(snip)...
MySQL PostgreSQL
docker-compose.yml

mailcatcherでのメール確認時も
• https://hub.docker.com/r/schickling/mailcatcher/
28
mail:
image: schickling/mailcatcher
ports:
- "1080:1080"
- "1025:1025"
docker-compose.yml

できれば、無料でいたい

一時期
• [qiita] Herokuでbotを運用する時代は終わった。こ
れからはIBM Bluemixを使って無料で運用する
• 2016/06〜 Freeは 1000 dyno hoursまで
30

Heroku以外のPaaS選択肢
• IBM Bluemix (Cloud Foundry)
• Microsoft Azure (Web Apps)
• Google Cloud Platform (App Engine Flex
Environment)
• など
31

料金面（無料枠）
• IBM Bluemix
• 512MBのインスタンスなら無料、1ヶ月目は無料
• Microsoft Azure Web Apps
• CPU60分/日、ストレージ1GBまでは無料
• Google App Engine
• 28インスタンス時間 / 日
=> 868 インスタンス時間 / 月
• Heroku
• 32 dyno 時間 / 日
=> 1,000 dyno 時間 / 月
32
1インスタンス/日が目安

料金面（有料枠 - 基本プラン）
33
IBM
Bluemix
Microsoft
Azure
Web Apps
Google
App
Engine
Heroku
プラン名 (Ruby) B1 Flex B1 Standard
CPU 1 1 1 1
メモリ(GB) 1 1.75 1 0.5
ストレージ 20GB 10GB 10GB 300MB?
料金/日 ¥89.36 ¥183.60 ¥160.95 ¥92.5
1ヶ月でも数千円程度の差

Herokuのアドオン
• Heroku Postgres (DB) ← これだけたまに厄介かも
• Heroku Redis (セッション・キャッシュ・キュー用)
• SendGrid (メール)
• New Relic (パフォーマンス監視)
• Papertrail (ログ監視)
• Librato (メトリクス監視)
• Fastly (CDN)
34
非同期処理を楽に導入できるかも重要

地味にうれしいことも

地味にありがたい
• [2016/09〜] Heroku SSL、有料dynoなら無料！
• [2017/05〜] さらに自動更新までしてくれる！
(Let’s encrypt)
– https://blog.heroku.com/ssl-is-now-included-on-
all-paid-dynos
– https://blog.heroku.com/announcing-automated-
certificate-management
36

じゃ、いつ大規模開発となる？

大規模とは？
• データが肥大化
• デフォルトのRDBMSでは捌ききれなくなってき
た場合
• Amazon RDS / Google Cloud Spanner など
• データ解析にパワーが必要
• BigQuery / RedShift
• 機械学習 (GPU)
38

大規模とは？２
• 分業できる (チーム)
• マイクロサービス化
• k8s
• Rancher
• コンテナ化しておいた方が楽
39

つらいときが来る
40
https://martinfowler.com/bliki/MicroservicePremium.html
生
産
性
複雑度

まとめ

まとめ
• スタートアップの開発は早さ一番、料金はそんなに
変わらないので気分が乗るような開発にするべき
• 「RubyならHeroku」はやっぱり変わらず
• いろいろPFの状況は変化するので、常にちぇきする
こと、でも細かく差を気にしすぎないこと
• Herokuの料金体制は今後も変わる可能性大だけど、
最近でもどんどん機能追加があるからうれしい
（Enterpriseに力入れるんですかね？w）
42

失敗を恐れずに
楽しく開発しましょう！

Thanks!

20170622 Heroku Meetup #17 スタートアップのインフラ選び高丸翔英 How to choose infrastracture in startup

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 20170622 Heroku Meetup #17 スタートアップのインフラ選び高丸翔英 How to choose infrastracture in startup

Semelhante a 20170622 Heroku Meetup #17 スタートアップのインフラ選び高丸翔英 How to choose infrastracture in startup (20)