すずけんメモ

技術メモです

re:InventでのParseのDevOps話がとても良かったのでまとめておく

aws chef

今、AWS re:Inventにきていて、今日parse.comのセッションを聴く時間があったので簡単にまとめておく。とてもざっくり書くと、要点は

  • parseは1-3段階のDevOpsの進化を経てきた
  • 最初はRoRでデプロイするにも全てのサーバでcapistorano走らせなければ行けなかった。結果として90分から150分くらいデプロイに時間が掛かる。
  • 現在はAutoScalingGroupとChefがシームレスに連携していて、5-10分でシステムをフルビルドできるようになった。

ということ。

セッションの概要は以下のとおり。

MBL307 - How Parse Built a Mobile Backend as a Service on AWS

Parse is a BaaS for mobile developers that is built entirely on AWS. With over 150,000 mobile apps hosted on Parse, the stability of the platform is our primary concern, but it coexists with rapid growth and a demanding release schedule. This session is a technical discussion of the current architecture and the design decisions that went in to scaling the platform rapidly and robustly over the past year and a half. We talk about some of the lessons learned managing and scaling MongoDB, Cassandra, Redis, and MySQL in the cloud. We also discuss how Parse went from launching individual instances using chef to managing clusters of hosts with Auto Scaling groups, with instance discovery and registry handled by ZooKeeper, thus enabling us to manage vastly larger sets of services with fewer human resources. This session is useful to anyone who is trying to scale up from startup to established platform without sacrificing agility.

Charity Majors - Production Engineering Manager, Parse

以下僕のとったメモ。

1.5年前

ops philosophy

  • 我々はplatformだから
    • 全てを自動化すべき
    • 全員がfull stack engineerであり、ジェネラリストの小さいチーム
    • DevOpsチームのゴール
      • 80%の時間はやりたいことをやる
      • 20%の時間はしなければいけないことをやる
      • つまり、無駄を省いて、自動化していって、改善に時間を費やせるようにするということ

past and present

2013年にgoalを達成

takeaways

  • ASGs are your best friend
  • automation should be reusable
  • choose your source of truth carefully
    • puppet chef ansible
    • chef

parse stack

  • 基本的にデータはmongo
  • cassandraもある
  • elbのしたにnginxとhaproxy

infrastructure design

  • chef
  • route 53
  • use real hostnames
  • distribute evenly across 3 AZs
  • 自動フェールオーバー
  • single source of truth

EC2 design choises

  • m1.large, m1.xlarge, m2.4xlarge
    • multicoreであることが大事
    • 小さいインスタンスもstatelessなサービスには使ってる
  • security groups
    • one group per role
    • gitとnagiosを使ってセットが動くかどうかを確かめる

以下、markdownでメモるのがめんどくさかったのでツイートした内容。

所感

発表されていたCharityさんがとても楽しそうにDevOpsについて話されていた。なかでもMongoDBのchefによるprovisioningの話や、autoscaling groupをchefのroleとマッチさせて管理しているという話は実践的で面白かった。それと、amiをbuildするのはやはり時間がかるので、極力同じamiを使うようにしたいと言っていた。これはAWSを使うデプロイではとても頭を悩ませる所だと僕らも感じているところ。ただ、immutableなinfrastructureを構成する上ではこのあたりはさけて通れないところだし、parseがGoを利用すること（そして将来的にはGoに完全移行するかもしれないような雰囲気だったこと）はそういう点で理にかなっていると思った。MongoDBについても柔軟性の面からparseにはフィットしたんだと思う。DynamoDBではやはりMBaaSとしてあらゆるクライアントのスキーマに対応するのは厳しい。パフォーマンスもどこかで犠牲になるか、データのスキーマをいい感じに制限するかどちらかになると思うので、その辺のトレードオフを勘案してMongoDBを採用したというような話だった。また、MongoDBについてもProvisioningレイヤーがしっかりと整備されているのは好感が持てた。shardingも利用していて、特定のcollectionだけが肥大化する傾向にあるらしく、そのあたりをうまくわけるような形で管理するようにしているらしい。

ともあれ、1時間のセッションなのに随分と内容が濃かった。良いセッションだった。