デブサミ2014に参加した！(1日目)
ということで、引き続き1日目のレポートです。
サーバプロビジョニングのこれまでとこれから
資料: https://speakerdeck.com/mizzy/future-of-server-provisioning-at-developers-summit-2014
2013年に非常に流行し、発展した技術は、VagrantやPacker、Chef、Docker、serverspec等、数ステップで予め設定したサーバーを立ち上げ、検証できるツールです。このセッションはserverspecを開発しているpaperboy&co.宮下さんのお話でした。
それぞれどんなツールか簡単に紹介すると、
Vagrant
仮想マシンを簡単に作成、管理するツール。各OSをインストールしたイメージを作成しておき、再利用できるツール。プラグイン機構を持ち、VirtualBoxだけでなく、VMWareやEC2、さくらクラウドや後述するDockerに仮想マシンを作成できる。
Packer
仮想マシンのひな形を作成するツール。各OSのインストール、セットアップを自動化するツール。JSONで設定値を書いて実行。VirtualBoxを使って試したところ、キーボード入力なども自動で行ってくれました。過去veeweeというツールもありましたが、Packerの作者はVagrantの作者と同じ方なので、こちらがメインになりつつある。
Docker
Linux上に別のLinuxの仮想マシンを立ち上げるLXCという技術をベースに、より利用しやすくしたツール。
Chef
ミドルウェアのセットアップをcookbookという形式でセットアップできるツール。cookbookはRubyスクリプトで書く。
serverspec
仮想マシンのテストをできるツール。設定が壊れていないか、テストで繰り返し検証できることや、同一の設定のサーバーを一度に展開した時に、自動的に確認できる。
こんな感じのツールが雨後の竹の子のように生まれ、流行したのが、2013年でした。(間違ってたらコメントを頂けるとうれしいです。)
実際は2013年よりも前からこういったツールがあり、AWSの流行と共により使われるようになり、流行し始めたようです。この流行の流れで、Infrastructure as Codeとか、Immutable Infrastructure とか、 Disposable Component といった言葉が生まれました。インフラを作るのもコードで済むようになり、既存のサーバーの設定をいじくるのではなく、コードを変更して、新たにサーバーを作成し、ロードバランサーの設定を変更することで接続先を変更する、と言った辺りを表現したのがこれらの言葉です。
インフラ周りのセットアップがコードに寄せられると、バージョン管理とかもしやすくなるので、便利ですよね！
テスト自動化を見直そう！自動化への投資が開発チームをクリエイティブにする
資料: 非公開 (代わりにtogetter http://togetter.com/li/628619 )
このセッションはランチセッションでした。いつの間にか、デブサミでも昼ごはんが提供されるようになってました。このセッションは、静的解析ツールベンダーのコベリティさんの中で行われているテスト自動化の取り組みの発表でした。
コベリティさんは、6ヶ月ごとのリリースサイクル、3ヶ月毎に次期リリース計画を練り直し、リリース直前のテストに6週間。スクラムで回しています。サポートするプラットフォームは非常に多く、215の仮想マシンインスタンス上でテストをしています。これだけのサポートプラットフォームを人力でテストすることの方が非効率なため、数年前からテスト自動化に投資し、現在はSelenium(ブラウザテスト自動化ツール)で3000以上のテストケースを自動実行しています。
とはいえ、テスト自動化を行うにもスキルが必要です。一年目は外注した事で失敗したので、現在は社内に専門のチームを設けているそうです。
別のセッションでDeNAのテストチームの話( http://www.slideshare.net/masaki/test-engineering-on-mobage )を聞いたのですが、DeNAも専門のチームがあり、MSやGoogleもそういった部署があります。また、楽天にいる友人は、社内にTDD(ユニットテスト)の文化を根付かせる部隊で仕事をしているそうです。テストの自動化には相応のコストがかかるのですが、大きな会社では自動化に投資を始めています。
スマホアプリのテストも、Seleniumと同一のAPIで実行ができるAppiumというライブラリが出てきています。(Seleniumの開発者がスマホ向けに開発を始めたのがAppiumです。)Seleniumのユーザーグループもできたそうです。
こういった流れを見てみると、2014年は、テストケース自体の管理を、インフラ同様、よりコードの方に寄せていきそうな印象を受けました。
何故クックパッドのサービス開発は日々進化しているのか
資料: https://speakerdeck.com/yoshiori/how-we-cook-cookpad-dot-com
2年ほど前にドワンゴからクックパッドに転職した庄司嘉織(通称@yoshiori)さんの講演です。一言で言うと、クックパッドの文化の話でした。
クックパッドでは、ユーザーに向いた仕事をする事を全社員に課せられており、クックパッドのエンジニアは、社外で講演したり、成果を公開することが義務付けられています。それが人事評価の指標にもなっており、今まで講演してきた資料は、会社サイトにまとめられ、公開されてます。 (これを作成するスクリプトもGitHubで公開されています。 https://github.com/cookpad/presentations )
クックパッドでは、ユーザーサポートの管理もGitHubのIssueで行っています。これによりエンジニアとしては、どういう内容が今サポートに来ているのか把握でき、サポートとしては、ユーザーサポートで必要になったコードの変更などの進捗も、コメントで見えるようになったそうです。
そういった取り組みを始めたのがヨシオリさんで、30分程度サポートの人に、GitHubの使い方やMarkdownの書き方(GitHubのWiki記法)を伝えたらサポートの人もGitHubを使えるようになったそうです。それができたのも、サポートの人もユーザーに向いた仕事をすることが求められているため、GitHubを使うことでよりエンジニアと密にコミュニケーションが取れ、よりよい仕事ができるのなら新しいツールを覚えることに抵抗がないという、「文化」があればこそできたことだろう、と言う話でした。
その他にも、クックパッドのシステムは1000以上のモデル（テーブル）を持つシステムですが、2ヶ月で50以上新たにモデルが追加されるなど、活発に開発が行われています。基本的にmasterの内容をGitHubにpushするとそのままシステムにデプロイされるため、 日に多い時は10回システムの更新が行われます。システムの更新時には当然CIが走り、壊れていない事を検証します。今、クックパッドのシステムには16000件以上のテストケースがあるので、毎回16000件のテストが実行されます。この16000件を超えるテストケースの実行を10分以内に終えるために専門のチームがあるそうです。デプロイの早さがシステムの更新回数に影響するため、10分以内に終える事を目指しているのだと思います。
1日目の終わりにはアンオフィシャルパーティーがありました。会場の隣はアマゾンジャパンの本社があり、そこの2階で開催されました。アマゾンジャパンの玉川さんにお話を伺う機会がありました。
アマゾンの文化は、Work Hard, Have Fun, Make History というスローガンに現されるとおり、まず「一生懸命働く事」が第一だ、と笑っていらっしゃいましたが、僕は、ユーザーにとって何が一番いいか、ということに向けて一生懸命に働く文化がある、という風に感じました。そのため、特にAWSを利用しているユーザーと共に必要な機能を考え、優先度付けをする会議を設けたりしているそうです。 これから作るツールはどうあるべきか、二日目に考えた事があるので、二日目のレポートにまとめます。
