GiltのYoni Goldbergが、同社のアプリが、RailsベースからScalaに移行しスケールしてきた経緯を紹介しています。

Videoがでたら是非紹介したいと思っていたネタですが、1ヶ月待ってもアップされないので、ひとまずあきらめてスライドの紹介だけになります。もしビデオがアップされたら改めて更新します。

2007年の典型的なスタートアップ。サービスをとにかくなるはやでローンチするために、当時盛り上がってきていたRailsを採用。

2009年、フラッシュセール開催時のトラフィックが急増。

技術上の問題点:

• トラフィックが跳ねる瞬間には、数千のRubyプロセスを立ち上げる必要があった。
• PostgreSQLはオーバーロード。
• Rubyプロセス間のルーティングトラフィックはうまくいかなかった。

開発上の問題点:

• 1000 Models/Controllers、コード20万行、数百件のジョブ
• 開発に関わるエンジニアは増えても、オーナーシップが欠如。
• インテグレーションのサイクルが長く、デプロイメントが困難。
• 根本原因を調査するのが難しい。

JVMへの移行

• 採用実績豊富
• 安定
• 並列処理うまい
• MRIよりガベージコレクタがよかった

スケールの問題の90%は解決したが、開発上の問題は残った。

• 新しいサービスもそれぞれ単一の大きなアプリになった。
• 1000 Models/Controllers、コード20万行、数百件のジョブ
• 開発に関わるエンジニアは増えても、オーナーシップが欠如。
• インテグレーションのサイクルが長く、デプロイメントが困難。

なぜ、さらにアプリを細分化したのか？

• チームを活性化させてオーナーシップの意識を持たせるため。
• スコープを狭める
• デプロイメントとロールバックをシンプルで簡単にする。

Scalaに移行して、現在450のサービスで構成される。

新しい課題

• 開発/インテグレーション環境: 誰も20個のサービスのコンパイルはしたくない
• 各チームがステージング環境をもっているが、全サービスを最新の状態にしておくのは大変。
• サービスのオーナーは誰？
• 監視
• デプロイメントと機能/結合テスト

将来はDockerを利用して、このようなデプロイメント環境にしたい。

開発者個人ではなく、チームがコードのオーナーになる。コードレビューを繰返す。OpenGrok

マイクロDB化で、データのオーナーシップを各サービスに（現状1/3）。

MongoDB / PostgreSQL / Voldemort

Schema Evolution Managerで、マイクロDBスキームを管理。

監視: New Relic / Boundary / Graphite / openTSDB

テストとデプロイメント

• サービス間の機能テストを実行するのは難しい
• Capistranoでのデプロイは半分手動作業になる
• 他のチームのサービスをデプロイするのは怖い

Ion-Cannon + sbt

• 機能/Seleniumテストを専用環境で実行できる
• カナリア（一部のユーザ向け）リリースをサポートできる
• ロールバックが簡単
• インテグレーションのヘルスチェックができる

#gilt #開発スタイル #アーキテクチャ #rails #scala #モジュール化 #docker #自動化 #devops