チャットサービス運用の舞台裏

1,598 views

Published on

YAPC::Asia 2013 発表資料です

Published in: Technology

チャットサービス運用の舞台裏

  1. 1. チャットサービス 運用の舞台裏
  2. 2. 自己紹介 ○ 長田洸明 (ながた・ひろあき) ○ KAYAC Inc. ○ サーバーサイドエンジニア ○ https://twitter.com/handlename ○ https://facebook.com/handlename ○ https://github.com/handlename
  3. 3. INDEX ○ Lobiとは ○ 運用チーム ○ インフラ構成 ○ 開発フロー ○ デプロイ ○ IRC ○ リプレースの歴史
  4. 4. Lobiとは
  5. 5. Lobiとは
  6. 6. Lobiとは ○ スマートフォン向けチャットサービス ○ API/SDKが公開されている ○ アプリに組み込んで使うことができる ○ アプリ専用のアカウント(サブアカウント) ○ 運営からのお知らせに使ったり ○ アプリ内のコミュニティに使ったり ○ チームチャットとして使ったり ○ #lobi@freenode
  7. 7. 規模
  8. 8. 規模 ○ APIリクエスト ○ 平均 550 req/sec ○ ピーク 2,000 req/sec ○ クエリ ○ 平均 6,500 qps ○ ピーク 18,000 qps
  9. 9. 運用チーム
  10. 10. 運用チーム ○ 専属チームは約20名 ○ 大半がエンジニア ○ サーバーサイドエンジニアが一番多い ○ 専属以外 ○ インフラチーム ○ CSチーム
  11. 11. インフラ構成
  12. 12. インフラ構成 ○ 自社データセンターとAWSを併用 ○ サービス拡大に伴いAWSへの全面移行を計画中
  13. 13. インフラ構成 - サーバー
  14. 14. 開発フロー ○ カンバン方式 ○ コードレビュー ○ GitHub Flow ○ CI
  15. 15. 開発フロー - カンバン方式 ○ 進捗をホワイトボードで管理 ○ スケジュール ○ 開発項目 ○ 数値目標
  16. 16. 開発フロー - カンバン方式
  17. 17. 開発フロー - コードレビュー ○ GithubのPull Requestでレビュー ○ ひとり以上のレビューを経なければmasterにマージできない ○ 開発とレビューとバランス ○ レビューがボトルネックにならないようにする ○ 巨大プルリク怖い
  18. 18. 開発フロー - GitHub Flow ○ releaseブランチがないgitflow ○ developブランチは必要なときだけつくる ○ 完成していなくても(議論のために)PRをつくる ○ masterから作業ブランチを作成 ○ 短いスパン/細かい変更内容でリリース ○ 1日に数∼十数回デプロイ
  19. 19. 開発フロー - CI ○ おなじみのJenkins ○ EC2のスポットインスタンスを利用 ○ それなりにスペックがほしいけど安く抑えたい・・・ ○ テストの設定/結果はEBSに保存 ○ 再起動時にJenkinsのセットアップが完了する ○ Githubとの連携 ○ テスト実行中/成功/失敗をアイコン表示 ○ テストが通っていないPRはマージ時に警告が出る
  20. 20. 開発フロー - CI
  21. 21. 開発フロー - CI
  22. 22. 開発フロー - CI ○ 並列実行して高速化 ○ App::Prove::Plugin::MySQLPool https://metacpan.org/module/ App::Prove::Plugin::MySQLPool ○ c1.xlargeインスタンスで10並列で実行 ○ 3500項目 / 所要時間約7分
  23. 23. 開発フロー - CI
  24. 24. 開発フロー - CI ○ カバレッジ85% ○ APIを叩くテストがメイン ○ APIを公開しているので、レスポンスが正しいことは必須 ○ モデルのテストは必要最小限 ○ テストがリファクタリングの妨げにならないようにする
  25. 25. デプロイ
  26. 26. デプロイ - git pull ○ 各サーバー上でgit pull ○ 変更があるファイルに気づける(保険) ○ デプロイ前にチェック git status -s -uno
  27. 27. デプロイ - parallel ○ parallelコマンドでデプロイ用のコマンドを実行 ○ デプロイ処理に手を加えるのが簡単 ○ {対象ホスト} で {ある処理} を並列実行 ○ よく使う処理はショートカットを用意
  28. 28. IRCの活用 ○ botが簡単に作れる ○ 何度も発生する作業はbotにやらせる
  29. 29. IRCの活用 - ログ検索 ○ GitHubのhubotを利用 ○ IRCから話しかけるとログを検索しに行ってくれる
  30. 30. IRCの活用 - GitHubのissue展開 ○ プルリクエストを多用するのでissue番号でやりとりすることが多い ○ issue番号っぽいものをIRCに貼ると自動展開 ○ いちいちURLをコピーしなくていいので便利
  31. 31. IRCの活用 - cronの結果表示 ○ メールでも結果は届くけど… ○ IRCならみんな見ているしその場で議論できる ○ 標準出力をfluentdに投げるスクリプト + 特定のタグをNoPasteに投げるfluent plugin
  32. 32. リプレースの歴史 ○ 運用期間2年半 ○ 様々なリプレース
  33. 33. リプレースの歴史 - CVS ○ SVN -> Git ○ git-svnを使っていたので移行コストは低かった ○ 初期は自社サーバーにリモートリポジトリを設置 ○ 現在はGitHub
  34. 34. リプレースの歴史 - O/R Mapper ○ DBIC -> Teng ○ コードが追えるモジュールを使いたかった… ○ 一時期はDBICとTengが共存
  35. 35. リプレースの歴史 - O/R Mapper
  36. 36. リプレースの歴史 - WAF ○ Catalyst -> Ark + Amon2 ○ メインのアプリケーションはArk ○ 自社ソーシャルゲーム等で運用実績あり ○ 長らくGitHub止まりだったが・・・ ○ 運用用管理画面はAmon2 ○ 当初は小さなサービスだったので開発コストを掛けられなかった ○ シンプルなアプリケーションが書きやすい ○ モデル部分はメインアプリケーションと共有
  37. 37. リプレースの歴史 - WAF ○ Ark ○ 先々週ついにCPANに! https://metacpan.org/module/Ark
  38. 38. リプレースの歴史 - インフラ ○ AWS -> データセンター -> AWS ○ 現在はAWSへの移行期間 ○ スケールが簡単 ○ APIが充実しているので自動化もできる
  39. 39. リプレースの歴史 - サービス名 ○ Nakamap -> Lobi ○ デザインは現在のものが3つ目 ○ 仲間で使おう ○ 女子会で使おう ○ ゲームで使おう <- いまここ ○ ドメインも変わった ○ nakamap.com -> lobi.co ○ APIはどちらのドメインでも使える
  40. 40. おわり ○ 鋭意スケールアップ中! ○ 鋭意ドキュメント整備中! ○ カヤックでは… ○ スケールアップに興味のあるエンジニアを募集しています! ○ ドキュメントを書くのが好きなエンジニアを募集しています! ○ ログ・データの解析が好きなエンジニアを募集しています!
  41. 41. 参考 - GitHub Flow ○ Scott Chacon on the Interwebs http://scottchacon.com/2011/08/31/github- flow.html ○ 日本語訳 https://gist.github.com/Gab-km/3705015
  42. 42. 参考 - メイン&サブアカウント SDK導入アプリからサブアカウントを使うことができる。 Lobi本体アプリからはメインアカウントに関連付けているす べてのサブアカウントを使うことができる。 サブアカウントはメインアカウントに関連付けをしなくても SDK導入アプリから使うことができる。

×