1 サービスをつくりなおす決断をするとき Developers Summit 2015 KANSAI Masaki Yamamoto
2 自己紹介 ChatWork株式会社 専務取締役CTO 山本 正喜 2000年 兄とともに株式会社EC studioを学生起業 2011年 チャットワークを企画開発 2012年 ChatWork株式会社に社名変更 2015年 GMO ...
3 ChatWork社について
4 2013/5/15 発売
5 チャットワークとは in the cloud クラウド型ビジネスチャットツール チャットの効率性・シンプルさをビジネスへ + ビデオ通話 チャット タスク管理
6 導入企業数 7万7千社 突破！ 1,000台のAndroid端末とともに導入 with
7 チャットワークの規模感（2015年8月現在） メッセージ数 約7億9千万 チャットルーム数 約2千300万 タスク数 約3千900万 ファイル数 約3千100万 (約76TB)
8 チャットワークの開発体制 Web開発部：9人 （チャットツール画面） 基盤開発部：5人 （管理画面、プラン/決済、分析基盤） アプリケーション開発部：6人 （モバイル/デスクトップクライアント） CTO室：5人 (変人たちのあつまり) （ア...
テクノロジーマネジメント 技術支援プロジェクトマネジメント マンマネジメント 9 Web開発部：9人 （チャットツール画面） 基盤開発部：5人 （管理画面、プラン/決済、分析基盤） アプリケーション開発部：6人 （モバイル/デスクトップクライア...
本日お話すること 「サービスをつくりなおす決断をするとき」 10
11 2011年にリリースしてから3年・・・
12 ゼロベースでつくりなおすことを決断 before after
13 もちろん簡単なことではありません ๏ 総コード量30万行 Over ๏ 普通に考えて数年がかり？のプロジェクト ๏ DB含めインフラ環境も刷新したい ๏ 既存システムを止めずに移行する必要あり なぜすることになったのか？ どうやっ...
チャットワークのはじまり 14
15 開発をはじめる前の状況（2010年） ๏ ひとつ前につくっていたWebサービス が大失敗、、、 ๏ 会社としてWebサービス自体に挫折感 がただよう ๏ 会社としてはWebとリアルの融合とい う方向性に注力
16 チャットワークを思いつく ๏ 敗戦処理に追われる日々・・ ๏ 何かやりたいなぁとチャットワークの 企画を思いつく。 ๏ これはイケる！と大興奮して提案した ところ・・・
17 見事に企画を却下されました・・
18 却下された理由 ๏ ひとつ前につくったWebサービスで大ゴケし たばっかだよね・・・ ๏ Google Waveが出たばっかりで勢いがあった
19 まあ確かに・・・
20 でも諦めきれずに・・・ ๏ 絶対イケるから！と役員をひとりずつ呼 び出して説得 ๏ 社長からなんとか、「そこまで言うなら、 最悪社内ツールにすればいいか」という 言葉を引き出すことに成功！ 当時の役員陣
21 が！
22 社長からの一言 「やってもいいけど、好きなこと やるんやからひとりでやってや」
23 えっ
24 というわけで ๏ 一人プロジェクトとして開発スタート ๏ まずは社内ツールでの定着を目指すこ とに (期待されていない) ๏ 社内の他スタッフからは何してるんだ ろう状態・・・
25 幻のファーストバージョン
26 当時のアーキテクチャ ๏ 社内システムに相乗りする形でスタート ๏ PHP、内製の独自フルスタックFW ๏ 社内システム部分はレンタルサーバー、 チャットワークの部分はAWSで構築
ビジネスとしての転機 27
28 ๏ 社内ツールとしてそれなりに稼働し てきたころ・・・ ๏ 自社のUstreamチャンネルで社長が チラ見せしたところ大反響
29 社長からの一言 「これいけるで！商品化しよ！」
30 でしょ！
31 事態は急展開 ๏ 四人プロジェクトに昇格 ๏ 正式なプロダクトとしてローンチ
32 おかげ様でサービスは急成長 ๏ サービスリリース初月で1万ユーザー達成。 ๏ LINEリリースもあり、チャットブームの波に のって口コミで大きく広がっていく。 ๏ KDDI社と業務提携。エンタープライズのお客 様へも多数導入。 ๏ ...
33 しかし、、、
34 積み重なっていた技術的負債 ๏ 後ろを振り返らない開発の日々 ๏ とにかく忘れ去られる前に走らないと 死ぬ！(前失敗したトラウマ) ๏ 増え続ける人員、暗黙知 ๏ 社内システムベースのアーキテクチャ では扱い切れない負荷、データ量に
35 神クラスの誕生 ChatUtil.php 1クラス1万行 メソッド数200弱 ゴッド
36 神は降臨された ๏ リファクタを後回しにし続けた結果・・・
37 その他技術的負債 ๏ 低いテストカバレッジ ๏ 一貫しない命名規則 ๏ スケールを考慮されていないロジック ๏ オールドスタイルな開発フロー ๏ 本番環境と一致しない開発環境
技術的負債を貯め続けると
 最後はどうなるのか？ 38
39 1. 遅れる
40 見積もりが大きくハズレるようになる ๏ 1ヶ月の予定が4ヶ月かかるとか・・ ๏ モジュールの密結合により影響範囲が 読めない ๏ 自動テストが網羅されてない為テスト 工数が膨大に ๏ 負荷的な問題でリリースできず何回も 手戻りに
41 2. 落ちる
42 加速度的に増える負荷問題 ๏ SPoF(単一障害点)が多く、ごく稀な条 件がそろうと一瞬で詰まって全体がサー ビスダウン ๏ 開発時は考慮されてない、1組織で X,000人の大規模利用。裏のバックグラ ウンド処理が進まない、、 ๏ ボ...
なんとかしなきゃ！ 43
44 ビジネスインパクトが無視できないものに ๏ 新規開発を一旦止め、技術的負債の解決へ リソースを集中！ 行ったこと： ๏ CIの導入 (Jenkins、TravisCI、Coveralls) ๏ 開発環境の整備 (Vagrant、Ansi...
45 対策前のサーバアーキテクチャ Tokyo Internet ELB EC2 GAE (Comet) S3 RDS(MySQL) upload EC2 (groonga) index
46 Internet Auto Scaling EC2 (Web Server) ElastiCache (Session) DynamoDB (Flags) S3 (Logs) RDS(MySQL) S3 Direct Upload ...
47 サービスの大幅安定化に成功 ๏ AutoScalingの導入によりダウンタイム が大幅に短縮化 ๏ 負荷特性に応じてスケールアウト型の マネージドサービスをフル活用。パ フォーマンスが大きく上がった。
48 しかし、根本的な解決はできていない ๏ 対症療法的にある程度の改善はできた ๏ しかし、内製フレームワークの仕様、 データ設計、API設計など根本の問題は 影響範囲が大きすぎてこれ以上の改善 が困難 ๏ 将来のグローバル展開を考えると...
これ以上の拡張はもう限界。。。 再実装しよう！ 49
50 一番のハードルは、社内の理解 ๏ 非エンジニアな役員陣にどう納得 してもらうか？ ๏ 技術的負債を理解してもらうのは 大変難しい。。。
51 案の定・・・ ๏ なんでそんなことするの？ ๏ 技術的負債って何？ ๏ 改善でなんとかならないの？ ๏ はじめからそうできなかったの？ まあ、そう思いますよね
52 建物の例をつかって説明しました いまのシステムはコレです↓ 初期バージョン 追加された機能 これ以上機能追加できませんよね・・？ (c)REUTERS/China Daily FW=工法 言語=建材
53 これから必要なもの 高層ビル 上にどんどん建て増していける 建てる前に基礎工事が必要
54 Martin Fowlerの犠牲的アーキテクチャ “For many people throwing away a code base is a sign of failure, perhaps understandable given ...
55 コードベースを破棄することで得られるメリット ๏ すでに確定した仕様でコードを再設計 できる ๏ 最新の技術を制約なく利用可能 ๏ 再実装時に仕様の再精査が可能 ๏ 新メンバーがレガシーな仕様をキャッ チアップしなくてよい
技術の選定 56
57
58 アーキテクチャ選定合宿を開催 ๏ 各エンジニアが、いまのチャット ワークを再実装するならどの技術 を選ぶかを選択 ๏ 言語、フレームワーク、一切自由 ๏ 合宿で仮実装して、選定する
59
60
61 選定合宿の結果・・・ ๏ Python / Flask ๏ Scala / Play Framework ๏ PHP / Laravel に決定！ ※Rails系はレールに乗りづ らいので選ばれにくかった
62 Scalaを選んだ理由 ๏ 静的言語としての保守性とパフォーマンスの高さ ๏ 動的言語からスイッチして成功した実績があること ๏ AWSはJava SDKが最も充実している ๏ チャットのリアルタイム処理と相性がいい ๏ PHP...
63 設計手法としてDDD(ドメイン駆動設計)を採用 ๏ 大規模システムで評価が高く、Scalaとの相性も いいDDDを全面的に採用。 ๏ 非エンジニアもエンジニアもデザイナも、共通の 言葉「ユビキタス言語」を使って齟齬を防ぐ ๏ 仕様変更...
64 DDD勉強会を毎週開催 ๏ チャットワークのドメイ ンモデルをみんなで考え る会 ๏ ドメインモデルが実装で はクラス設計などに落ち てくる ๏ 軽食食べながら＆飲みな がらワイワイと 加藤潤一先生
65 システム移行戦略 EC2 (Internal API) EC2 (Event Fetcher) Tokyo Tokyo Beanstalk DynamoDB 現行システム RDS(MySQL) 腐敗防止層 新システム call act...
66 システム移行戦略のポイント ๏ 現行システムと新システムを並行して稼働させる ๏ 腐敗防止層を置いて、現行システムの設計に新シ ステムを依存させない ๏ 新システムのDBは当初キャッシュだが、将来的 にマスタDBとなる
67 新システム移行戦略のねらい ๏ ビッグバンリリースを避ける。デバイスごと、 エンドポイントごとに少しずつ新システムへ 移行可能（最初はiOSの予定） ๏ 新システム側に不具合があっても、マスタ DBは現行システムが持つため安全
68 まとめ ๏ 社内システムから急成長したチャットワーク のシステムが限界に ๏ 根本の解決にはゼロからのつくりなおしが必 要と判断。経営陣の理解を得ることが重要。 ๏ Scala、DDDを採用しサービスを全面刷新中 ๏ 巨大システムな...
69 新バージョンにぜひご期待ください！ ありがとうございました Beyond chat. Beyond simple Scala + DDD + AWS で大規模開発してみたいエンジニア募集中です！ ※大阪オフィスあります
Upcoming SlideShare
Loading in...5
×

サービスをつくりなおす決断をするとき

565

Published on

Developers Summit 2015 KANSAI 登壇資料

Published in: Technology
0 Comments
15 Likes
Statistics
Notes
no profile picture user

  • Be the first to comment

Show More
No Downloads
Views
Total Views
565
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
15
Embeds 0
No embeds

No notes for slide

サービスをつくりなおす決断をするとき

  1. 1. 1 サービスをつくりなおす決断をするとき Developers Summit 2015 KANSAI Masaki Yamamoto
  2. 2. 2 自己紹介 ChatWork株式会社 専務取締役CTO 山本 正喜 2000年 兄とともに株式会社EC studioを学生起業 2011年 チャットワークを企画開発 2012年 ChatWork株式会社に社名変更 2015年 GMO Venture Partners社より3億円調達 ↑大阪府吹田市が本社
  3. 3. 3 ChatWork社について
  4. 4. 4 2013/5/15 発売
  5. 5. 5 チャットワークとは in the cloud クラウド型ビジネスチャットツール チャットの効率性・シンプルさをビジネスへ + ビデオ通話 チャット タスク管理
  6. 6. 6 導入企業数 7万7千社 突破！ 1,000台のAndroid端末とともに導入 with
  7. 7. 7 チャットワークの規模感（2015年8月現在） メッセージ数 約7億9千万 チャットルーム数 約2千300万 タスク数 約3千900万 ファイル数 約3千100万 (約76TB)
  8. 8. 8 チャットワークの開発体制 Web開発部：9人 （チャットツール画面） 基盤開発部：5人 （管理画面、プラン/決済、分析基盤） アプリケーション開発部：6人 （モバイル/デスクトップクライアント） CTO室：5人 (変人たちのあつまり) （アーキテクチャ、R&D） MGR MGR MGR CTO
  9. 9. テクノロジーマネジメント 技術支援プロジェクトマネジメント マンマネジメント 9 Web開発部：9人 （チャットツール画面） 基盤開発部：5人 （管理画面、プラン/決済、分析基盤） アプリケーション開発部：6人 （モバイル/デスクトップクライアント） CTO室：5人 (変人たちのあつまり) （アーキテクチャ、R&D） MGR MGR MGR CTO
  10. 10. 本日お話すること 「サービスをつくりなおす決断をするとき」 10
  11. 11. 11 2011年にリリースしてから3年・・・
  12. 12. 12 ゼロベースでつくりなおすことを決断 before after
  13. 13. 13 もちろん簡単なことではありません ๏ 総コード量30万行 Over ๏ 普通に考えて数年がかり？のプロジェクト ๏ DB含めインフラ環境も刷新したい ๏ 既存システムを止めずに移行する必要あり なぜすることになったのか？ どうやってやるのか？
  14. 14. チャットワークのはじまり 14
  15. 15. 15 開発をはじめる前の状況（2010年） ๏ ひとつ前につくっていたWebサービス が大失敗、、、 ๏ 会社としてWebサービス自体に挫折感 がただよう ๏ 会社としてはWebとリアルの融合とい う方向性に注力
  16. 16. 16 チャットワークを思いつく ๏ 敗戦処理に追われる日々・・ ๏ 何かやりたいなぁとチャットワークの 企画を思いつく。 ๏ これはイケる！と大興奮して提案した ところ・・・
  17. 17. 17 見事に企画を却下されました・・
  18. 18. 18 却下された理由 ๏ ひとつ前につくったWebサービスで大ゴケし たばっかだよね・・・ ๏ Google Waveが出たばっかりで勢いがあった
  19. 19. 19 まあ確かに・・・
  20. 20. 20 でも諦めきれずに・・・ ๏ 絶対イケるから！と役員をひとりずつ呼 び出して説得 ๏ 社長からなんとか、「そこまで言うなら、 最悪社内ツールにすればいいか」という 言葉を引き出すことに成功！ 当時の役員陣
  21. 21. 21 が！
  22. 22. 22 社長からの一言 「やってもいいけど、好きなこと やるんやからひとりでやってや」
  23. 23. 23 えっ
  24. 24. 24 というわけで ๏ 一人プロジェクトとして開発スタート ๏ まずは社内ツールでの定着を目指すこ とに (期待されていない) ๏ 社内の他スタッフからは何してるんだ ろう状態・・・
  25. 25. 25 幻のファーストバージョン
  26. 26. 26 当時のアーキテクチャ ๏ 社内システムに相乗りする形でスタート ๏ PHP、内製の独自フルスタックFW ๏ 社内システム部分はレンタルサーバー、 チャットワークの部分はAWSで構築
  27. 27. ビジネスとしての転機 27
  28. 28. 28 ๏ 社内ツールとしてそれなりに稼働し てきたころ・・・ ๏ 自社のUstreamチャンネルで社長が チラ見せしたところ大反響
  29. 29. 29 社長からの一言 「これいけるで！商品化しよ！」
  30. 30. 30 でしょ！
  31. 31. 31 事態は急展開 ๏ 四人プロジェクトに昇格 ๏ 正式なプロダクトとしてローンチ
  32. 32. 32 おかげ様でサービスは急成長 ๏ サービスリリース初月で1万ユーザー達成。 ๏ LINEリリースもあり、チャットブームの波に のって口コミで大きく広がっていく。 ๏ KDDI社と業務提携。エンタープライズのお客 様へも多数導入。 ๏ 社名をChatWork株式会社へ変更。社運を け る覚悟を決める。
  33. 33. 33 しかし、、、
  34. 34. 34 積み重なっていた技術的負債 ๏ 後ろを振り返らない開発の日々 ๏ とにかく忘れ去られる前に走らないと 死ぬ！(前失敗したトラウマ) ๏ 増え続ける人員、暗黙知 ๏ 社内システムベースのアーキテクチャ では扱い切れない負荷、データ量に
  35. 35. 35 神クラスの誕生 ChatUtil.php 1クラス1万行 メソッド数200弱 ゴッド
  36. 36. 36 神は降臨された ๏ リファクタを後回しにし続けた結果・・・
  37. 37. 37 その他技術的負債 ๏ 低いテストカバレッジ ๏ 一貫しない命名規則 ๏ スケールを考慮されていないロジック ๏ オールドスタイルな開発フロー ๏ 本番環境と一致しない開発環境
  38. 38. 技術的負債を貯め続けると
 最後はどうなるのか？ 38
  39. 39. 39 1. 遅れる
  40. 40. 40 見積もりが大きくハズレるようになる ๏ 1ヶ月の予定が4ヶ月かかるとか・・ ๏ モジュールの密結合により影響範囲が 読めない ๏ 自動テストが網羅されてない為テスト 工数が膨大に ๏ 負荷的な問題でリリースできず何回も 手戻りに
  41. 41. 41 2. 落ちる
  42. 42. 42 加速度的に増える負荷問題 ๏ SPoF(単一障害点)が多く、ごく稀な条 件がそろうと一瞬で詰まって全体がサー ビスダウン ๏ 開発時は考慮されてない、1組織で X,000人の大規模利用。裏のバックグラ ウンド処理が進まない、、 ๏ ボトルネックが次々と顕在化
  43. 43. なんとかしなきゃ！ 43
  44. 44. 44 ビジネスインパクトが無視できないものに ๏ 新規開発を一旦止め、技術的負債の解決へ リソースを集中！ 行ったこと： ๏ CIの導入 (Jenkins、TravisCI、Coveralls) ๏ 開発環境の整備 (Vagrant、Ansible) ๏ PRベースの開発フロー (GitHub) ๏ 重い処理を疎結合にして非同期化 (SQS) ๏ スケールアウト可能なマネージドサービスを採用 (DynamoDB、CloudSearch、SendGrid) ๏ Scrumの導入 (JIRA、Confluence) ๏ サーバー監視ツールの導入 (NewRelic、Cedexis)
  45. 45. 45 対策前のサーバアーキテクチャ Tokyo Internet ELB EC2 GAE (Comet) S3 RDS(MySQL) upload EC2 (groonga) index
  46. 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 対策後
  47. 47. 47 サービスの大幅安定化に成功 ๏ AutoScalingの導入によりダウンタイム が大幅に短縮化 ๏ 負荷特性に応じてスケールアウト型の マネージドサービスをフル活用。パ フォーマンスが大きく上がった。
  48. 48. 48 しかし、根本的な解決はできていない ๏ 対症療法的にある程度の改善はできた ๏ しかし、内製フレームワークの仕様、 データ設計、API設計など根本の問題は 影響範囲が大きすぎてこれ以上の改善 が困難 ๏ 将来のグローバル展開を考えると、全 然耐え切れるイメージがない・・・
  49. 49. これ以上の拡張はもう限界。。。 再実装しよう！ 49
  50. 50. 50 一番のハードルは、社内の理解 ๏ 非エンジニアな役員陣にどう納得 してもらうか？ ๏ 技術的負債を理解してもらうのは 大変難しい。。。
  51. 51. 51 案の定・・・ ๏ なんでそんなことするの？ ๏ 技術的負債って何？ ๏ 改善でなんとかならないの？ ๏ はじめからそうできなかったの？ まあ、そう思いますよね
  52. 52. 52 建物の例をつかって説明しました いまのシステムはコレです↓ 初期バージョン 追加された機能 これ以上機能追加できませんよね・・？ (c)REUTERS/China Daily FW=工法 言語=建材
  53. 53. 53 これから必要なもの 高層ビル 上にどんどん建て増していける 建てる前に基礎工事が必要
  54. 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. 55 コードベースを破棄することで得られるメリット ๏ すでに確定した仕様でコードを再設計 できる ๏ 最新の技術を制約なく利用可能 ๏ 再実装時に仕様の再精査が可能 ๏ 新メンバーがレガシーな仕様をキャッ チアップしなくてよい
  56. 56. 技術の選定 56
  57. 57. 57
  58. 58. 58 アーキテクチャ選定合宿を開催 ๏ 各エンジニアが、いまのチャット ワークを再実装するならどの技術 を選ぶかを選択 ๏ 言語、フレームワーク、一切自由 ๏ 合宿で仮実装して、選定する
  59. 59. 59
  60. 60. 60
  61. 61. 61 選定合宿の結果・・・ ๏ Python / Flask ๏ Scala / Play Framework ๏ PHP / Laravel に決定！ ※Rails系はレールに乗りづ らいので選ばれにくかった
  62. 62. 62 Scalaを選んだ理由 ๏ 静的言語としての保守性とパフォーマンスの高さ ๏ 動的言語からスイッチして成功した実績があること ๏ AWSはJava SDKが最も充実している ๏ チャットのリアルタイム処理と相性がいい ๏ PHPエンジニアでも短時間(開発合宿中)でそれなりに書 けるようになった 大規模なシステムでは、静的言語の保守性が欲しくなる （他社の事例からも、第2言語には静的言語を選ぶ例が多い)
  63. 63. 63 設計手法としてDDD(ドメイン駆動設計)を採用 ๏ 大規模システムで評価が高く、Scalaとの相性も いいDDDを全面的に採用。 ๏ 非エンジニアもエンジニアもデザイナも、共通の 言葉「ユビキタス言語」を使って齟齬を防ぐ ๏ 仕様変更に強いアーキテクチャにできる ※大規模かつ長く開発を続けるシステムにDDDは向いている。 そうでないものにはオーバーヘッドが大きい。
  64. 64. 64 DDD勉強会を毎週開催 ๏ チャットワークのドメイ ンモデルをみんなで考え る会 ๏ ドメインモデルが実装で はクラス設計などに落ち てくる ๏ 軽食食べながら＆飲みな がらワイワイと 加藤潤一先生
  65. 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. 66 システム移行戦略のポイント ๏ 現行システムと新システムを並行して稼働させる ๏ 腐敗防止層を置いて、現行システムの設計に新シ ステムを依存させない ๏ 新システムのDBは当初キャッシュだが、将来的 にマスタDBとなる
  67. 67. 67 新システム移行戦略のねらい ๏ ビッグバンリリースを避ける。デバイスごと、 エンドポイントごとに少しずつ新システムへ 移行可能（最初はiOSの予定） ๏ 新システム側に不具合があっても、マスタ DBは現行システムが持つため安全
  68. 68. 68 まとめ ๏ 社内システムから急成長したチャットワーク のシステムが限界に ๏ 根本の解決にはゼロからのつくりなおしが必 要と判断。経営陣の理解を得ることが重要。 ๏ Scala、DDDを採用しサービスを全面刷新中 ๏ 巨大システムなので、順次移行できるような 移行方法をとっています
  69. 69. 69 新バージョンにぜひご期待ください！ ありがとうございました Beyond chat. Beyond simple Scala + DDD + AWS で大規模開発してみたいエンジニア募集中です！ ※大阪オフィスあります

  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×