Recommended
More Related Content
What's hot
What's hot (20)
Similar to サービスをつくりなおす決断をするとき
Similar to サービスをつくりなおす決断をするとき (20)
Recently uploaded
Recently uploaded (16)
サービスをつくりなおす決断をするとき
- 1. 1 サービスをつくりなおす決断をするとき Developers Summit 2015 KANSAI Masaki Yamamoto
- 2. 2 自己紹介 ChatWork株式会社 専務取締役CTO 山本 正喜 2000年 兄とともに株式会社EC studioを学生起業 2011年 チャットワークを企画開発 2012年 ChatWork株式会社に社名変更 2015年 GMO Venture Partners社より3億円調達 ↑大阪府吹田市が本社
- 7. 7 チャットワークの規模感（2015年8月現在） メッセージ数 約7億9千万 チャットルーム数 約2千300万 タスク数 約3千900万 ファイル数 約3千100万 (約76TB)
- 13. 13 もちろん簡単なことではありません ๏ 総コード量30万行 Over ๏ 普通に考えて数年がかり？のプロジェクト ๏ DB含めインフラ環境も刷新したい ๏ 既存システムを止めずに移行する必要あり なぜすることになったのか？ どうやってやるのか？
- 14. チャットワークのはじまり 14
- 15. 15 開発をはじめる前の状況（2010年） ๏ ひとつ前につくっていたWebサービス が大失敗、、、 ๏ 会社としてWebサービス自体に挫折感 がただよう ๏ 会社としてはWebとリアルの融合とい う方向性に注力
- 16. 16 チャットワークを思いつく ๏ 敗戦処理に追われる日々・・ ๏ 何かやりたいなぁとチャットワークの 企画を思いつく。 ๏ これはイケる！と大興奮して提案した ところ・・・
- 18. 18 却下された理由 ๏ ひとつ前につくったWebサービスで大ゴケし たばっかだよね・・・ ๏ Google Waveが出たばっかりで勢いがあった
- 19. 19 まあ確かに・・・
- 21. 21 が！
- 23. 23 えっ
- 24. 24 というわけで ๏ 一人プロジェクトとして開発スタート ๏ まずは社内ツールでの定着を目指すこ とに (期待されていない) ๏ 社内の他スタッフからは何してるんだ ろう状態・・・
- 25. 25 幻のファーストバージョン
- 26. 26 当時のアーキテクチャ ๏ 社内システムに相乗りする形でスタート ๏ PHP、内製の独自フルスタックFW ๏ 社内システム部分はレンタルサーバー、 チャットワークの部分はAWSで構築
- 27. ビジネスとしての転機 27
- 30. 30 でしょ！
- 32. 32 おかげ様でサービスは急成長 ๏ サービスリリース初月で1万ユーザー達成。 ๏ LINEリリースもあり、チャットブームの波に のって口コミで大きく広がっていく。 ๏ KDDI社と業務提携。エンタープライズのお客 様へも多数導入。 ๏ 社名をChatWork株式会社へ変更。社運を け る覚悟を決める。
- 33. 33 しかし、、、
- 34. 34 積み重なっていた技術的負債 ๏ 後ろを振り返らない開発の日々 ๏ とにかく忘れ去られる前に走らないと 死ぬ！(前失敗したトラウマ) ๏ 増え続ける人員、暗黙知 ๏ 社内システムベースのアーキテクチャ では扱い切れない負荷、データ量に
- 37. 37 その他技術的負債 ๏ 低いテストカバレッジ ๏ 一貫しない命名規則 ๏ スケールを考慮されていないロジック ๏ オールドスタイルな開発フロー ๏ 本番環境と一致しない開発環境
- 39. 39 1. 遅れる
- 40. 40 見積もりが大きくハズレるようになる ๏ 1ヶ月の予定が4ヶ月かかるとか・・ ๏ モジュールの密結合により影響範囲が 読めない ๏ 自動テストが網羅されてない為テスト 工数が膨大に ๏ 負荷的な問題でリリースできず何回も 手戻りに
- 41. 41 2. 落ちる
- 42. 42 加速度的に増える負荷問題 ๏ SPoF(単一障害点)が多く、ごく稀な条 件がそろうと一瞬で詰まって全体がサー ビスダウン ๏ 開発時は考慮されてない、1組織で X,000人の大規模利用。裏のバックグラ ウンド処理が進まない、、 ๏ ボトルネックが次々と顕在化
- 43. なんとかしなきゃ！ 43
- 44. 44 ビジネスインパクトが無視できないものに ๏ 新規開発を一旦止め、技術的負債の解決へ リソースを集中！ 行ったこと： ๏ CIの導入 (Jenkins、TravisCI、Coveralls) ๏ 開発環境の整備 (Vagrant、Ansible) ๏ PRベースの開発フロー (GitHub) ๏ 重い処理を疎結合にして非同期化 (SQS) ๏ スケールアウト可能なマネージドサービスを採用 (DynamoDB、CloudSearch、SendGrid) ๏ Scrumの導入 (JIRA、Confluence) ๏ サーバー監視ツールの導入 (NewRelic、Cedexis)
- 46. 46 Internet Auto Scaling EC2 (Web Server) ElastiCache (Session) DynamoDB (Flags) S3 (Logs) RDS(MySQL) S3 Direct Upload / Download ELB CloudSearch Index Tokyo GAE (Comet) BigQuery (API Logs) EC2 (Worker) Get SQS (Task Queue) Push Glacier 対策後
- 48. 48 しかし、根本的な解決はできていない ๏ 対症療法的にある程度の改善はできた ๏ しかし、内製フレームワークの仕様、 データ設計、API設計など根本の問題は 影響範囲が大きすぎてこれ以上の改善 が困難 ๏ 将来のグローバル展開を考えると、全 然耐え切れるイメージがない・・・
- 51. 51 案の定・・・ ๏ なんでそんなことするの？ ๏ 技術的負債って何？ ๏ 改善でなんとかならないの？ ๏ はじめからそうできなかったの？ まあ、そう思いますよね
- 54. 54 Martin Fowlerの犠牲的アーキテクチャ “For many people throwing away a code base is a sign of failure, perhaps understandable given the inherent exploratory nature of software development, but still failure. But often the best code you can write now is code you'll discard in a couple of years time.” “多くの人々にとって、コードベースの破棄とは失敗の象徴です。ソフトウェアが本 来持つ調査的性格を考慮したとしても。しかし、いま書けるベストなコードが数年後 に捨てられるということは珍しくないのです” http://martinfowler.com/bliki/SacrificialArchitecture.html 数年後に破棄することを前提にコードを書くという考え方。 長いスパンでのプロトタイピングとしてアーキテクチャを考える。 twitter：Rails→Scala PayPal：Perl→C++→Java dwango：PHP→Scala コードベースを刷新した例 開発に失敗したのではなく、 検証に成功したとみなす
- 55. 55 コードベースを破棄することで得られるメリット ๏ すでに確定した仕様でコードを再設計 できる ๏ 最新の技術を制約なく利用可能 ๏ 再実装時に仕様の再精査が可能 ๏ 新メンバーがレガシーな仕様をキャッ チアップしなくてよい
- 56. 技術の選定 56
- 57. 57
- 59. 59
- 60. 60
- 61. 61 選定合宿の結果・・・ ๏ Python / Flask ๏ Scala / Play Framework ๏ PHP / Laravel に決定！ ※Rails系はレールに乗りづ らいので選ばれにくかった
- 62. 62 Scalaを選んだ理由 ๏ 静的言語としての保守性とパフォーマンスの高さ ๏ 動的言語からスイッチして成功した実績があること ๏ AWSはJava SDKが最も充実している ๏ チャットのリアルタイム処理と相性がいい ๏ PHPエンジニアでも短時間(開発合宿中)でそれなりに書 けるようになった 大規模なシステムでは、静的言語の保守性が欲しくなる （他社の事例からも、第2言語には静的言語を選ぶ例が多い)
- 63. 63 設計手法としてDDD(ドメイン駆動設計)を採用 ๏ 大規模システムで評価が高く、Scalaとの相性も いいDDDを全面的に採用。 ๏ 非エンジニアもエンジニアもデザイナも、共通の 言葉「ユビキタス言語」を使って齟齬を防ぐ ๏ 仕様変更に強いアーキテクチャにできる ※大規模かつ長く開発を続けるシステムにDDDは向いている。 そうでないものにはオーバーヘッドが大きい。
- 64. 64 DDD勉強会を毎週開催 ๏ チャットワークのドメイ ンモデルをみんなで考え る会 ๏ ドメインモデルが実装で はクラス設計などに落ち てくる ๏ 軽食食べながら＆飲みな がらワイワイと 加藤潤一先生
- 65. 65 システム移行戦略 EC2 (Internal API) EC2 (Event Fetcher) Tokyo Tokyo Beanstalk DynamoDB 現行システム RDS(MySQL) 腐敗防止層 新システム call action fetch SQS (Event Queue) push call old api user new api user
- 66. 66 システム移行戦略のポイント ๏ 現行システムと新システムを並行して稼働させる ๏ 腐敗防止層を置いて、現行システムの設計に新シ ステムを依存させない ๏ 新システムのDBは当初キャッシュだが、将来的 にマスタDBとなる
- 68. 68 まとめ ๏ 社内システムから急成長したチャットワーク のシステムが限界に ๏ 根本の解決にはゼロからのつくりなおしが必 要と判断。経営陣の理解を得ることが重要。 ๏ Scala、DDDを採用しサービスを全面刷新中 ๏ 巨大システムなので、順次移行できるような 移行方法をとっています
- 69. 69 新バージョンにぜひご期待ください！ ありがとうございました Beyond chat. Beyond simple Scala + DDD + AWS で大規模開発してみたいエンジニア募集中です！ ※大阪オフィスあります