エンジニア１名によるサービス開発と運用

2014-2-19 egmc@Speee

14年2月21日金曜日

自己紹介

14年2月21日金曜日

who?• @EGMC• http://egmc.me/• しごと

• こじんももクロAndroidアプリhttp://momochro.me/

14年2月21日金曜日

ももクローム！

14年2月21日金曜日

ももチェック！

14年2月21日金曜日

•ということで

14年2月21日金曜日

今日話すこと

•少人数でのサービス運用についての話•サービス開発時の課題と対応•ステージごとの開発のバランスの取り方について

14年2月21日金曜日

今日話さないこと

•最新技術的なこと•技術的な詳細（コードなし）•大規模チーム開発っぽいこと

14年2月21日金曜日

アジェンダ

14年2月21日金曜日

アジェンダ

•はじまり　ローンチ前、背景•つくる期　サービスローンチ～１年•安定させる期　2年目～•発展させる期　現在～future

14年2月21日金曜日

はじまり～ローンチ前、背景

14年2月21日金曜日

運営サービス

• クラウドファンディングプラットフォームCAMPFIRE

• 総支援額約2億6000万

• 総プロジェクト数約680件

2014年2月時点

14年2月21日金曜日

チーム（開始時）

•デザイン•キュレーター• tech（ひとり）

14年2月21日金曜日

チーム（現在）

•デザイン•広報•Growth•キュレーター（4名）• tech（ひとり）

14年2月21日金曜日

環境•Amazon Linux• PHP5.4• CakePHP1.3• apache2.2•MySQL5.5(RDS)• redis(セッションストレージ)

14年2月21日金曜日

背景(1)

• CAMPFIREローンチ• 2011-06-02•株式会社ハイパーインターネッツ入社• 2011-06-01

14年2月21日金曜日

背景(2)•元々作ってた人から引き継ぎ•仕様書なし•「アプリは出来てるから」って言われてた

•リリース直前にバグ対応•突貫でインフラ構築してリリース

14年2月21日金曜日

背景(3)

•入社時のスキルセット•前職はガラケーのポイントサイト•オレオレPHPフレームワーク•メジャーなPHPフレームワークは初•ソシャゲの開発でAWS経験はアリ

14年2月21日金曜日

•何かあればタイム

14年2月21日金曜日

つくる期サービスローンチ～１年

14年2月21日金曜日

•まずは何から？

•サービスを作る体制を作る

•運用を作る

14年2月21日金曜日

•サービスを作る体制を作る

14年2月21日金曜日

•タスク管理＆バージョン管理＆デプロイ•情報共有•ルールづくり

開発体制？

14年2月21日金曜日

•サービスを作るためのツール•何を使うか？•自前、オープンソース、外部サービス

開発ツール

14年2月21日金曜日

デプロイ

•自作のrsyncラッパー• https://github.com/egmc/dssync

14年2月21日金曜日

一応•こんな感じで差分が見れたりもします

14年2月21日金曜日

何故自作？

•とにかく早く構築する必要があった•既存ツールは学習コストがかかる•機能的に要件を満たしている•Webインターフェースが必要•要件に合わなくても手を入れやすい

14年2月21日金曜日

要件を満たす

•社長がデザインもやるので勝手にデプロイ出来る仕組みが必要

•リリースするものを選べる仕組み•Webインターフェース

14年2月21日金曜日

情報共有

14年2月21日金曜日

redmineのwiki•細かく仕様は書かない•見るべき箇所、気をつける点のみ•着手したところから書いていく•非エンジニアも使用•最初に教育(使い方と概念）•ストック情報、ルールを一箇所に

14年2月21日金曜日

ルール作り•コーディング規約• PSRをベースに若干おおらかに•デプロイに関するルール•文言修正レベルは通したい•ロジックが絡むかどうかが基準•ルールはwikiへ、定期的に更新

14年2月21日金曜日

•運用をつくる

14年2月21日金曜日

•サービスのサイクルに合わせた運用ルール、体制、管理ツール作り

•エンジニアだから～というフェーズではないので積極的に関わっていく

•チェックリスト作りなど

運用を作る？

14年2月21日金曜日

サービスのサイクル

•案件投稿•→審査•→素材の受け取り、フィードバック•→掲載作業

14年2月21日金曜日

運用を作っていく

•「まずこうあるべき」というフローを作る

•手持ちのツールで一本のフローを作る•徐々に「機能」で置き換えていくことで手離れ

14年2月21日金曜日

案件管理ツール•巨大なエクセルシート→redmine

14年2月21日金曜日

何故redmine？•基本ツールはなんでも良い•海外のisssue管理系ツールとかね•ただしAPIが利用出来ること•「最小限のルール」からスタート•なんでもかんでもやろうとすると破綻•「時間管理」とか使ってない

14年2月21日金曜日

Excelはダメなの？

•スプレッドシート結構使ってます•現在の状態は管理出来るが歴史は管理しづらい（そういうツールじゃない）

•同時更新とかそういうの•使いどころの問題ですね

14年2月21日金曜日

API大事! ! ! ! ! ! // -------redmineへ登録連携! ! ! ! ! ! // タイトル! ! ! ! ! ! $redmine_title = "{$propdata['Proposal']['id']};{$propdata['Proposal']['title']}";! ! ! ! ! ! // 登録! ! ! ! ! ! $response = $redmine->postIssue(! ! ! ! ! ! ! array(! ! ! ! ! ! ! ! CfRedmine::PARAM_PROJECT_ID => _CF_REDMINE_PROJECT_ID,! ! ! ! ! ! ! ! CfRedmine::PARAM_TRACKER_ID => _CF_REDMINE_TRACKER_ID,! ! ! ! ! ! ! ! CfRedmine::PARAM_SUBJECT => $redmine_title,! ! ! ! ! ! ! ! CfRedmine::PARAM_DESCRIPTION => $bodytext,! ! ! ! ! ! ! )! ! ! ! ! ! );

14年2月21日金曜日

管理ツール

•よく使うものから作る•この場合「案件管理」•なにはともあれ動くことが大事•運用に合わせて変更を加えていく•足りない部分は文言で補足

14年2月21日金曜日

ユーザーサポート

•すべてを作ろうとすると際限ない•お金に関わる部分から作る•対応する機能を作るか、そもそも問い合わせが来ないようにするか判断

•機能をどこまで作りこむかはトレードオフ

14年2月21日金曜日

つくる期まとめ

•サービスのフロー（つまり業務フロー）を一緒に作る

•将来的にシステムに置き換える想定はしておくが最初は手動

•サービスがまわることが大事

14年2月21日金曜日

•何かあればタイム

14年2月21日金曜日

安定させる期2年目～

14年2月21日金曜日

•安定させる？

•運用に必要な機能の作り込み

•スケール可能な安定したインフラ

•設計上の問題点の対応

•セキュリティの強化

14年2月21日金曜日

•運用に必要な機能の作り込み

14年2月21日金曜日

管理ツール

14年2月21日金曜日

管理ツール

•機能追加ですぐ作れるように定型化•よく使う機能は作りこむ•事故らないように作りこんでいく•入力項目の制限•ステータスに応じて操作を制限

14年2月21日金曜日

•スケール可能な安定したインフラ

14年2月21日金曜日

リリース時サーバー

14年2月21日金曜日

現在のサーバー構成

14年2月21日金曜日

インフラ

•限られたリソースとのトレードオフ•予算、時間（人）•「絶対に落とすべきではない」かどうか

14年2月21日金曜日

•設計上の問題点の対応

14年2月21日金曜日

•リリース時に想定してなかったこと•設計上の問題は負債として積み上がっていく

•時間が経つほど手を入れづらい•コア機能こそ手を入れていく

設計上の問題点

14年2月21日金曜日

設計上の問題(1)

•ユーザーが登録時のログイン方法しか使えない

•複数アカウントの紐付け•後でやると結構大変•追加テーブルを作ってデータ移行

14年2月21日金曜日

設計上の問題(2)

•支援データと決済データの密結合•決済に失敗した場合などに困る•決済システムの変更を行った際にまとめてテーブル構成を変更

14年2月21日金曜日

とはいえ

•基本的にはシンプルに設計しておいた方が良い

•２つ以上の概念や詳細が一つのテーブルに同居してると危険

•この場合「決済」と「購入情報」、「ユーザー」と「ログイン方法」

14年2月21日金曜日

•セキュリティの強化

14年2月21日金曜日

•基本的にこのあたり• XSS•セッション固定化、ハイジャック• SQLインジェクション• XSRF

セキュリティ

14年2月21日金曜日

どこまでやるか？

•基本的には粛々とやれば良い•どの程度の悪いことが出来るのか？を想定

•個人情報、お金への影響•ただのイタズラ

14年2月21日金曜日

CAMPFIREの場合

•初期は発送先等の保存機能なし•あんまり悪さ出来ない•支援を勝手にやるとかそのレベル•機能が増えるとできることも増える•守るべきものが増えていく

14年2月21日金曜日

XSS対策

•とにかく起こりやすい•ユーザーの機能が増えるほどできることが増える→リスクが増す

•基本は自動エスケープ• JSへの値に受け渡しは特に気をつける

14年2月21日金曜日

安定させる期まとめ

•手動→自動•動いているから大丈夫、ではない•既に動いている部分にも手を入れる

14年2月21日金曜日

•何かあればタイム

14年2月21日金曜日

発展させる期現在～future

14年2月21日金曜日

•数字を伸ばす

•効果測定

•サービスとしての付加価値

14年2月21日金曜日

•効果測定

14年2月21日金曜日

コンバージョンとか

14年2月21日金曜日

アプリ固有の情報

14年2月21日金曜日

ツール•普通にGoogle Analytics•カスタム変数で属性追加•週次でレポート送信→軌道修正•アプリ固有の情報はDBで•案件情報はredmineAPI経由で取得して集計

14年2月21日金曜日

•サービスとしての付加価値

14年2月21日金曜日

• 2013-8 ユーザー向けインサイト機能こういうのとか

14年2月21日金曜日

インサイト機能

•よくあるユーザー向けの簡単なAnalytics的なもの

•プロモーション支援• fluentd+Amazon EMRで実装•難しいことはそんなにしてません

14年2月21日金曜日

付加価値

•なくてもなんとかなる機能•なるべく勝手にまわるような仕組みを作る

•効果測定を忘れずに

14年2月21日金曜日

future•ログ分析をもっといい感じに•アプリケーションログを使おう•早いサイクルで軌道修正•アプリケーションレベルでの自動化•アプリレベルで運用をまわす•人間がやるべきことをやろう

14年2月21日金曜日

まとめっぽいこと

14年2月21日金曜日

ひたすら自動化

•手動は基本的にミスる可能性がある•自動化もエラーはありうるがそれは単に不具合

•それぞれやるべきことに集中する•開発、分析、営業

14年2月21日金曜日

•ステージごとにトレードオフを考える•サービスの段階で優先度は変わる•リソースは常に有限（マシンリソース、人、お金）

•「十分なレベル」も変化する

トレードオフ

14年2月21日金曜日

•ご静聴ありがとうございました

14年2月21日金曜日