共用方式為

DevOpsインタビュー: 第 4 回 よるガタ渡辺さん 10 deploys per day on Azure with OSS!

  • 發行項

今日の DevOps インタビューは、よるガタの渡辺さんにお伺いしました。よるガタ様はスマートフォンを用いたサービス開発を得意とする会社様です。

渡辺さんは Microsoft Azure 上でオープンソースを使って、10 deploys per day の環境を実現されています。さらに、渡辺さんは、継続的インテグレーション (といいつつ、CD や IaC までカバーしている) この書籍『CakePHPで学ぶ継続的インテグレーション』の著者の 1 人でもあります。これは楽しいノウハウが聞けそうですね。ではインタビューを楽しんでください!

LIVER NOTES

インタビュー

(以下敬称略)

牛尾: はじめまして渡辺さん。DevOps に関してインタビューさせてください。
渡辺: よろしくお願いします。
牛尾: 私は増渕という別のエバから渡辺さんのことを聞いて、いてもたってもいられず、インタビューをお願いさせいただきました! なんか、こう、ガチのにおいがしたんですよね!
渡辺: (笑)
牛尾: 渡辺さんは、確か継続的インテグレーションに関する本を書かれておられましたよね?
渡辺: はい。『CakePHPで学ぶ継続的インテグレーション』を共著で書きました。
牛尾: 継続的インテグレーションに取り組まれたのはどういう切っ掛けだったのですか?
渡辺: はい。切っ掛けは 2012 年に福岡で行われたPHP MATSURI 2012 で、先ほどの本の共著者でもある吉羽さんのプレゼンテーションを聞いて継続的インテグレーションや継続的デリバリに興味を持ち始めたのがきっかけです。昔はテストは書いていましたが、書きっぱなしでした。吉羽さんが、講演で CI/CD の話をして、デプロイしたらツイッターでつぶやくみたいなことをしていてかっこいいなと刺激を受けました。ちょうどその時に始まった案件で、CI の予算をとってもらうことができて、実践し始めました。
牛尾: ちなみにこの本タイトルは、継続インテグレーションですけど、それ以上の内容ですね。Infrastructure as Code とか、継続的デリバリも入っていて相当濃厚な内容ですね。
渡辺: 私も初めて取り組んだ時に、Jenkins で環境を作るのが大変でした。だから、そこに必要な標準的な道を示すような書籍がほしいなと思ったので、そういう本を執筆してみました。
牛尾: 本当に実践的な本で素晴らしいですね!
渡辺: 継続的インテグレーションは本当にメリットが多かったので、その後もアジャイルの道を突き進みました。
牛尾: ところで、この LIVER NOTESS は Azure をご使用いただいておりますが、どういう切っ掛けだったのですか?
渡辺: Azure も使いたいなと思っていた時に、タイミングよく Azure のクーポンを買わないかと言われたのでそれで (笑)
牛尾: 実際に使ってみて Azure はどうでした?
渡辺: 言葉や概念が独特なので、なじむのが大変でした。例えば V1 とか、V2 とか、可用性セットとか負荷分散セットとか。自動でストレージ アカウントが作られるところもなれなかったですね。
牛尾: では、よかったところはどういうところですか?
渡辺: 国内の IaaS を使っていましたが、ちょっと設計思想が違う様な印象を受けました。一台一台のインスタンスの可用性と性能を追求する感じ。これに対して、Azure は用途にあわせてユーザが複数台で構成する。可用性は決して低くはないんですけど基本的に落ちるものとして考えないといけない。
牛尾: ほー
渡辺: あと、WebApp は超いいですね! GitHub にプッシュしたらデプロイされるのが便利ですね。
牛尾: PHP デプロイしているんですか?
渡辺: 静的なページに使っています。
牛尾: IaaS は他社のと同じ感じじゃないですか?
渡辺: はい。Ubuntu を使っています。もともと Debian 派でだっので。
牛尾: なぜ Ubuntu が好きなのですか? 私も Ubuntu 好きですし、吉田パクえが昨日ハッカソンで UbuntuT シャツきてたので。
渡辺: LTS で安定してつかえて、新しいのも取り込むのが比較的早いのもいいですね!
牛尾: では、今回のアプリケーションについて教えてください。
渡辺: LIVER NOTES はライブのレビューを共有するアプリで、iPhone でリリースしています。年末には正式リリースする予定です。同じライブハウスに来た人が、ライブハウスにチェックインしたら知らせてくれたりする機能を追加する予定です。
牛尾: かっこいいですね!
渡辺: 今後は Azure の Machine Learning 使えたらいいなーって思ってるんです。でも機械学習難しいですよね。
牛尾: Azure の Machine Learning はかなり行けてますよ。ちなみに、同僚のエバの大田が作った最強チュートリアルありますよ 注: 推薦システムを構築する手順書 with Azure Machine Learning>
渡辺: おー、是非教えてください!
牛尾: ほかにも、Machine Learning自体がもし難しかったとしても、Machine Learningでつくられた Project Oxford とかもおもしろいですよ。やっぱり、 Azure は PaaS とか SaaS が面白いですよね。Machine Learning の他には Media Service とか、IoT Hub とかも面白いですね。 注: Microsoft Project Oxford
渡辺: そこらへんはとても興味があります! よさそうですよね。使いたいです! 私はインフラ屋ではないので、やっぱりできれば PaaS が使いたいですね。
牛尾: ところで、開発チームについて教えてください。どういう組織ですか?
渡辺: プロダクト マネージャーが 1 人います。ライブ好きで、マーケや広報も兼ねています。私は、Dev の iOS 部分および、Ops 部分を担当しています。スタッフがもう 1 名いまして、バックエンドの CakePHP を担当しています。Version 3.x になってかなり楽になりました。
牛尾: PHP は楽しいですか?
渡辺: CakePHP が 3 になってだいぶ楽しくなりました。今年の年末に PHP の 7 のリリースが予定されていて、内部構造か高速化される予定です。
牛尾: いつも聞いている質問なのですが、実際にやるかどうかは別として、本番の環境に 1 日 10 回デプロイできる能力はありますか?
渡辺: 全然できますね。実際に新しいアプリの申請前や新しいバージョンをリリースする前新しいバージョンをには 1 日に何回もデプロイします。
牛尾: おー、ガチですね!! 趣味 DevOps の私としてはむっちゃ興奮ですわ!
牛尾: では、今回のプロジェクトのデプロイのプロセスを教えてください。あなたがコードをチェックインして、本番環境にデプロイするまでのプロセスはどのような感じですか?
渡辺: 最初に Pull Request を送付します。それをトリガに Jenkins が自動ビルド・テストを実施します。並行で人間がレビューを行います。両方がオッケーであれば、マージして、ステージングにデプロイします。本番も同じイメージです。
牛尾: それぞれの部分で人手が介する部分以外はワンボタンで自動化されている感じですか?
渡辺: はい。他のプロジェクトだと、例えばステージング環境へのデプロイが自動化されたりします。開発用ブランチのストーリーテストが成功すると自動でステージング環境にデプロイされます。ただ、今回のアプリは iOS のアプリとバックエンドサーバーという構成なので、こういったアプリの場合バックエンドの更新をアプリ側のアップデートとタイミングを合わせる必要があるケースが多いです。
牛尾: ここに、Hubot かいてありますが、ChatOps 的なことをされておられますか?
渡辺: はい。Slack を使っていて、情報をメンバーと共有しています。デプロイしたとか、そういう事がスラックにながれるので、それでリモート メンバとコミュニケートをとっています。

下記スクリーンショットはよるガタ様で開発を担当した別アプリケーション「メガホン」の画面ですが、同様のシステムを使っているとのことです。

Jenkins のメッセージも Slack に書かれます

チケット管理の Pivotal Tracker も状態が変わったら Slack に連携している

Ansible 関連

DataDog のデータを張り付ける

デプロイを実施する。バックで Capstrano が動作している。
牛尾: おー、かっこいい
渡辺: 弊社メンバーはリモートで働くことがいいので、コミュニケーションをうまくとれるよう Pull request & Review の仕組みを作ったりしています。
牛尾: ちなみに Unit テスト以上のテストはしていますか?
渡辺: はい。一部 Functional テストも実施しています。
牛尾: DB どう実現していますか?
渡辺: Cake PHP に migration があります。
牛尾: では、Rails でいう Fixture に相当するものは?
渡辺: これも、Cake PHP にあります。もしくは Mock や Fabricate というデータ ジェネレータを使ってテストします。
牛尾: おー、PHP すごいですね。私は Ruby 派ですが、他の言語だと、Rails の環境のようにテストの環境やもろもろがそろってる方がレアだと思いますが、PHP はすごいそろっていますね。見直しました。楽そうですね?
渡辺: はい。ですので、最近では PHP を安易に Dis ると、刺されるよと言われているみたいｗ
牛尾: この構成だとがっつりテストはしていませんのでおそらく、ロールバックの機能が重要ですね。
渡辺: Capistrano でアプリ部分のロールバックができます。DB 部分はやろうと思ったらできるし、別のプロジェクトではやっている例もありますが、本アプリではあまり使っていませんね。不要です。ちなみに別のプロジェクトでは
牛尾: なぜですか?
渡辺: iOS のアプリなので、クライアントが古いバージョンでも新しいバージョンでも動く必要があります。そのためクライアントのバージョンに応じて API も微妙に挙動を変える必要があるケースが多いんです。例えば、データベースに変更があっても古いバージョンのアプリには今までと同じ形のレスポンスを返さないといけないので、新しい機能に何か問題があっても古いバージョンのアプリには影響がでない様に色々と工夫しています。
牛尾: なるほど! 今まで、シビアなトランザクションをさばく楽天さん、クックパットさんと、インタビューしましたが、それぞれに、アプローチが違っていて面白いですね!
牛尾: ところで、Infrastructure as Code について教えてください。
渡辺: Ansible + Vagrant + Virtual Box + Capstrano を使っています。
牛尾: なぜ Ansible にしたのですか?
渡辺: 昔は Chef を使っていたのですが、Ansible はシンプルでいいですね。Chef はサーバーが 10 台を超えるといいかもしれないけど、それまでは Ansible のほうが簡単ですね。あと、順番通りに動いてくれるw。
牛尾: Azure でのチャレンジはありましたか?
渡辺: IaaS だと他とそんなに変わらないですね。Azure の慣れですかね。IaaS の設定、特に本番の構成を考えるのに悩みました。吉田ゆうやさんのところに押しかけて強引に教えてもらいました。
牛尾: Infrastructure as Code を実施してよかったことを教えてください
渡辺: 何回やっても、10 数分で設定が終了しますね。
牛尾: 実際の効果としてはどんなのがありました?
渡辺: アプリの申請を控えた週末に本番環境の準備を始めて、試行錯誤しつつその週末だけで本番環境ができてましたね。で、週明け月曜日に関係者全員でテストして火曜日に申請しました。 それまでに、Vagrant を使った環境やステージング環境を構築をして何回もテストしたスクリプトがあるので楽勝でした。もし、クラウドの方で問題があれば、別のクラウドに移ればいいし。
牛尾: 今は、クラウドベンダに依存しないツールというのは重要だと思いますね。では、Docker とか興味ありますか?
渡辺: Docker が来たら、クラウドどこでもいーじゃんってなりそうですね。
牛尾: 本当にそう思います。
渡辺: Docker が PaaS になるイメージですね。
牛尾: もうイメージが DockerHub にのっているので、そんな感じですね。ちなみに、otto もそんな感じですね。 PaaSをプロビジョンするみたいな。
渡辺: そうなんですね。otto がリリースされた日はみんな朝から Otto, Otto って言いまくってましたねw。
牛尾: あれは熱いですよ、Vagrant の単純な後継じゃなくて、Ruby とかの PaaS をデプロイできたり、アプリデプロイできたり、マイクロ サービスの依存性を管理できたりとか。HashiCorp の製品ってほんまセンスがいいんですよね。
渡辺: そうなんですよねー。私も別プロジェクトで Consel を使っています。プロ野球を応援するアプリで、試合ごとのインスタンスが追加されたら、クラスタに追加するといった使い方です。

メガフォン プロ野球の応援アプリ (注：筆者は阪神ファン)
牛尾: かっけー! まさかそれは、Azure?
渡辺: 残念ながらｗ しかし、CI サーバは Azure ですよ。ちなみに Michel Hashimto 北海道の PHP 祭りに呼びました
牛尾: え、マジっすか?
渡辺: 2 年前ですね。Vagrant が広まっていたので、ダメ元で他のスタッフがトライしたら OK してくれました。日本語わからないけど、いいとかいわれて
牛尾: すげー!
渡辺: とても、気さくな人で、Vagrant 作った理由とか話してくれました。
牛尾: ほんま HashiCorp はセンスがいいので大好きですね! ちなみに、Serverspec とか使われていますか?
渡辺: まだですね。
牛尾: あれは、簡単なのでいいですよ!
渡辺: なんか難しそうで
牛尾: 最初は、ポートが開いているかの確認とか、アプリが入っているかのテストだけでも書くといいのではないでしょうか?私が昔お手伝いしていたアジャイル + DevOps プロジェクトで、Chef 等のIaCツールを導入しようとしたけど、インフラベンダの抵抗にあって、その時はあきらめたけど、その代わりインフラベンダーの受け入れに Serverspec をパラメータシートをもとにかいて、テストして 6 分で 50 台のサーバー検査して、沢山エラー見つけたとかありましたよ。
渡辺: おー、それは便利そうですね。トライしてみます!
牛尾: 他に、DevOp s的な観点でメリットはありましたか?
渡辺: Face 2 face ではないので、普通にやると回らない。今は勝手にスラックに流れてきます。
牛尾: Pull request やレビューや Hubot もうまく使われていると思います。
渡辺: 今は Pivotal Tracker を使ってIssue的な管理をしています。全ての情報は Slack にながれれるので、「俺、今から外出だから、デプロイしといて」というのも可能です。権限をみんなが持っているので。今はとにかくかなりの情報が Slack にポストされますね。
牛尾: ありがとうございました! たぶん渡辺さんの事例は多くの Azure x OSS 実践者にとって背中を押してくれるものになるとおもいます。ほんまガチですね!
渡辺: ありがとうございます。牛尾さんはどんなことをしているのですか?
牛尾: 月 1 回のペースで DevOps ハッカソンやってますね。面白いですよ!
渡辺: 面白そう、是非次回以降の開催を教えてください!
牛尾: あとで案内送りますね!

あとがき

私もあまりに面白いお話で、ほぼ趣味のような会話になってしまい申し訳ありませんが、オープンソースの世界だけで行われていると思われていた 10 deploys per day も Azure x OSS の上でなんの問題もなく動いていて、しかも、その仕組みやプロセスが本当によくできていてお話をお聞きしているだけで大変興奮しました!
渡辺さんありがとうございました!