スタートアップこそ巨人の肩に乗りまくれ！ 〜craful開発とmackerel〜
TRANSCRIPT
スタートアップこそ 巨人の肩に乗りまくれ！ ～Craful開発とMackerel～ギルドワークス株式会社 前川 博志 a.k.a @Posaune
自己紹介
• 前川博志 a.k.a @Posaune
• もともと老舗メーカでWindowプログラマ⇒ ギルドワークス株式会社所属ALMエンジニア
• Microsoft MVP for Visual Studio ALM Visual Studio and Development Technology
ALM #とは
• Application Lifecycle Management
• アプリケーションの一生を面倒見るお仕事
• どういう課題から、どういう要求が生まれて、それをどう実現し、どう確認し、どう運用し、どう役目を終わらせるか。
• （個人的解釈です）
アプリーケーションの輪廻転生※イメージです
ALMエンジニアとしての最近
• ギルドワークスの現場コーチ
• 飛び込みCIエンジニアとして主にiOS周りのビルド環境を整備
• CI Serviceにゾッコン中
http://www.slideshare.net/Posaune/jenkinsci-50411288
開発者としての最近
• 現在、新規サービス立ちあげ案件3件に開発者（兼 マネジメント or Scrum Master）として参画中
• JavaとSwift楽しいです。コンパイルできるって素晴らしい。型って素晴らしい。
• どんなプロジェクトでも、ユーザに一歩踏み込んでディスカッションしています
開発・現場での困り事はなんでもギルドワークスへ！
さて、本題。
スタートアップこそ 巨人の肩に乗りまくれ！
～Craful開発とMackerel～
ギルドワークスとスタートアップ
• これまで、ギルドワークスでは2つのスタートアップ開発を支援してきました
• まごチャンネル (https://www.mago-ch.com/)
• Craful (http://www.craful.jp/)
• その中でも、本当に「スタートアップ」らしい開発を行ったCrafulの舞台裏についてお話します
スタートアップの悩み
スタートアップのジレンマ
• スタートアップは、 余計なことをしている時間はない！！
• スタートアップは、 できる失敗は限られている！！
余計なことをしている時間はない！
• スタートアップは、成功するまでに許された期間は少ない
• 次の投資を得るために、目に見える成果を、できるだけ早く得ることが重要
• 「製品をつくる」以外の事は、できるだけやりたくない
「余計なこと」の例
• ビルド・デプロイ・テスト
• メトリクス収集
• サーバ運用・監視
できる失敗は限られている！
• スタートアップが切り開く領域は、これまでだれも挑戦したことのない分野が多い
• 今作っているものが本当に市場の評価に耐えうるかを、全力で判断し、素早く方向転換
• 「市場の評価」は年々厳しくなる一方。使えない製品をリリースしている余裕はない。
しないといけない「余計なこと」
• ビルド・デプロイ・テスト⇒ 頻繁なフィードバックを得るのに必須
• メトリクス収集⇒ 事実に基づくフィードバックが必要
• サーバ運用・監視⇒ エラーをいち早く検知し、ユーザの離脱を防止
スタートアップのジレンマ
• 余裕が無い = 「製品をつくる」以外に中々気が回らない
• 失敗できない=失敗をすばやく計測しリカバリする仕組みが必須
• ただでさえ時間がないのに、環境を入念に仕込んでおかないと、致命的な失敗をしてしまう
ジレンマを解消するには？
• 「余計なこと」をある程度肩代わりしてくれるようなサービス・ソフトを活用する
• 設定はできれば自動化、最低でもデフォルト設定でそこそこ使えるような状態に
• 動き出せば、最小限のメンテンスで動いて欲しい⇒ Everything as a Service
Everything as a Service
• 何もかも、サービスに寄せよう
• 自分たちの技術力を過信しない⇒ 評判の良い環境・巨人の肩に乗る
• （ホントのスタートアップの規模だと、 サービスのほうが圧倒的にコスト安い）
ジレンマの解消のためにスタートアップでやったこと～Craful 開発を例に～
Crafulについて
Crafulについて
• ハンドメイドのアイデアを集めて見つける プラットフォーム（まずはiOSから）
• サービスの企画から、開発、リリースまでをギルドワークと共同で実施
• 今年起業の、バリバリスタートアップ
ビルド・デプロイの「余計」
• ビルドならJenkins！…ですら面倒
• サーバのデプロイも、手動とか無理！
• iOSアプリも、常に最新を！！確認したい！！
ビルド・デプロイを助けるサービス• ビルド：CircleCI
⇒ iOSビルド可能, 無料枠有り
• デプロイ：Heroku
⇒ 環境構築不要、つくるときにはこれで充分、無料枠有り
• iOSデプロイ：DeployGate
⇒ CLIから完全に自動で配信可能、無料枠有り
開発・確認のワークフロー
• サーバ側： - master push時にHerokuでテスト・デプロイ- ほとんど設定なし
• クライアント側： - master pushでDeployGateの配信バージョン更新- 常に最新のiOSビルドをクライアントと確認
メトリクス収集の「余計」
• 各画面における離脱率を見たい！けれど、、
• 開発中はページはコロコロ変わるし、細かいメトリクス収集を入れるのは非常に面倒
メトリクス収集を助けるサービス
• グロースのための画面録画サービス、Repro
https://repro.io/
• ユーザー端末上での画面の動きを録画し、動画でシミュレート表示
• ユーザの離脱原因やクラッシュ要因を、実際に目で見て確認できる
• ぶっちゃけ、スタートアップ早期だとわりと全部目を通せる量のアクセスしかこない
運用・監視の「余計」
• 当たり前だが、本番用サーバは必要。だが、設定諸々は面倒だし、ミスを起こしやすい
• サーバの監視はしておかないと、夜寝れないよね？
運用・監視を助けるサービス
• プログラム寄り（アプリケーションプロファイル）
⇒ New Relic ！
• サーバ寄り（マシンプロファイル）
⇒ Mackerel！
New Relic
• アプリケーションの各種メトリックスを（ほぼほぼ）自動取得してくれるサービス
• 特に何も考えずに入れておくだけで、パフォーマンスなどのメトリックスを出してくれる
Mackerel
• はてな製のサーバ外形監視ツール。
• とにかく、導入障壁が低いのが嬉しい所
• パフォーマンス測定時に、謎のエラーが 発生し、New Relicではさっぱり分からず、慌てて外形監視ツールを探していた
• 特に嬉しかったところは・・・
嬉しいポイント①設定の簡便さ
Mackerelは設定簡単
• 設定が超簡便。他のフレームワークだと…
Mackerelは設定簡単
• Mackerelだと・・・ ① rpmでインストールして、 ② 起動して、 ② 設定ファイルのコメントアウト外して、③ おしまい！
• Postgres用の設定なり、Linux用の設定なりも一瞬でできる。
• 深夜一時から、原因不明のエラー救命に大急ぎで入れる、なんて無茶な要請にも見事に答えてくれました！
地味に嬉しい設定ファイル
嬉しいポイント②画面のユーザーフレンドリーさ
Nagios
Zabbix
Mackerel
画面はバカにできない
• ぱっと見て使いたくなるか、使い続けようと思うかはかなり大きい
• 画面操作を覚えている時間すらも「余計」
• マニュアル片手にしか使えないツールは、 根本的にスピード感合わない
その他嬉しいポイント
• アラート設定も楽ちん （危ない時にメール送る、など）
• Agentと追加プラグインだけで、本当に 事が足りてしまう
• 開発者との距離が近い （僕が京都にいるから、という意味ではなくて・・・）
まとめ
巨人の肩に乗ろう！
• スタートアップでは、コアの価値を作ることに注力したい
• とはいえ、コア以外の価値なしでは、サービスとして成り立たない
• Everything as a Serviceの精神で、サービスを上手く使おう
• 本来「アウトソース」とはこういう事なんじゃないの？
Enjoy, Software Development !!