スタートアップがデプロイ12倍速を実現した継続的デリバリーの仕組みとは？｜株式会社ハウテレビジョン　ヒカ☆ラボレポート

スタートアップの時期は「後回しできることは後回しにしてしまおう」

テキストスタートアップの時においては、まずは「ユーザーを集める」「ビジネスを立ち上げる」「事業を立ち上げる」といったことに注力することが大事です。
だから後回しにできることは全部後回しにしてしまいましょう。

サイトが開発され、ユーザーが増えるにつれ、新たな課題は次々に出てきます。
例えば「会員登録できる機能を追加したい」「会員登録できる機能は追加したが、それでは会員登録したら次に何をできるようにするのか」
そして「ユーザーの期待度をあげるためにはどうすればいいか」など。

しかし、新しい課題を解決するために開発スピードを上げたくて人数を増やしたのに、増えたメンバー間の調整業務が増加することで結果的に開発スピードが上がらない。

機能開発が優先で、開発基盤的な部分に時間が取れないことが多いかもしれません。
ですが、スピード感をもって開発を続けていく中で、様々な技術的負債が溜まり、それが足かせとなることがあるのです。

「技術的な負債を解消するには、タイミングがある」

技術的な負債に必ず対処しなくてはならない時期がきます。
ではいつ技術的な負債を解消するのか、ということですが、

「サービスから収益が出て一息つけた」
「開発者が4人を超えた」
「バグが頻発してきた」

この3つのうち1つでもひっかかった時が技術的な負債を解消するタイミングです。

技術的負債は大きく2つに分けることができて、
1つはコードの中に含まれるもの、具体的には理解不能な変数やメソッドなどですね。
もう1つが開発・運用プロセスに関わるものです。開発・運用プロセスの改善はコードの改善に比べて効果が大きく、また導入するタイミングが早ければ早いほどさらに大きくなります。

ではどのように開発運用プロセスの改善を進めるのか。

私達は2つのことに取り組み「CD（継続的デリバリー）」を実現しました。
1つはアプリケーションのデプロイを自動化すること、もう1つはサーバー構築/運用を自動化すること。

結果、当社比でデプロイが12倍高速になり、サーバー構築も8倍高速になりました。

アプリケーションのデプロイを自動化すると作業効率が12倍あがる！？

まず最初にデプロイの自動化を目標にすべきだと私は考えています。
なぜかというと、導入までの道筋が比較的はっきりしていて容易であり、効果が大きいからです。

これまでの私達のデプロイの手順の中には、かなり手間がかかる工程がありました。

しかし自動化を図った結果、以前は1時間くらいかかっていたデプロイの作業が、コマンドを1つ叩くだけで5分で完了するようになったのです。
コマンドを1つ叩くのなんて5秒もあれば出来るのですが、実行には処理に少し時間がかかるので、所要時間は5分というところになります。
つまりアプリケーションのデプロイを自動化することによって時間にして、12倍も高速化されたことになります。

私達は、Capistoranoというツールを使って自動化しました。
このツールはデプロイのためのタスクがデフォルトで用意されていて、このデフォルトタスクを採用することで最小のコストでデプロイの自動化が実現できるようになります。

「よし、自動化により全てがうまくいった！もう悩みなんてない！」

と思いたいのですが、そうもいきません。
新たなツール/手法の採用にはやはり、導入コストについても検討しておかなければなりません。

コストに影響を与える要素としては、アプリの規模、アプリの複雑さ、開発者の知識量などが挙げられます。
また、そのアプリ自体をよく知っているという点もコストを考える際に、非常に重要なポイントですね。

自動化ができるといっても、それで全てのデプロイを自動化できたわけではありません。
現在でも、リバースプロキシの切り替えなど自動化できていない部分があります。

けれども、それでも「デプロイの自動化が進んだことで開発効率は上がった」と言えます。

サーバー構築/運用の自動化をしたことで作業効率が8倍あがる！？

次に、サーバー構築の自動化にとりかかるのがよいと考えます。
理由としては、本番環境 → ステージング環境 → 開発環境と導入効果が拡散していくことが期待できるからです。

サーバーって、皆さんの開発環境の中でも、最も闇が深く、最も入り込みづらい場所と感じているのではないでしょうか。
なぜなら「サーバーで何が起こっているのか分からない」「（サーバーについて）誰も知らない」なんてことも往々にして起こりえます。

そうなると、バージョンアップや新しいパッケージにうまく対応できず、新しいツールも採用できなくなるという問題が生じるおそれがあります。

私達はこの問題を対処するために自動化を行うことにしました。
自動化を行うと、今まで1日かかっていたサーバーの立ち上げが、1時間でできるようになりました。1日の労働時間を8時間とすると、その差8倍です。
サーバーを構築する際、何かミドルウェアを入れようとしたら「Perlが必要だ！」とか「Rubyが必要だ！」みたいな事態が起こり、なかなか作業が終わらない、なんてこともあったりしますよね。しかし、自動化すれば、コマンド１つで1時間でできるようになります。
そしてこの「サーバー構築の自動化」を実現したのがChefです。
Rubyをベースにしたシステム開発ツールで、同じ設定ファイルを使うことにより、似たようなサーバーをどんどん作り出すことが可能になりました。

アプリケーションデプロイの自動化の時とほぼ同じメリットです。

けれども、自動化できなかった部分もあります。
Chefは所詮、OSが入ってから行うものなんで、OSのインストールをしない限り自動化できません。

本当は、KickstartとかPreseedを使ってサーバーを自動作成できるようにしたり、OSイメージファイルを使ってサーバーの生成を行う、みたいなことをやるべきなんですが、今はそこまで至っていません。

なおかつ、今我々が抱えているサーバーって全部が全部、自動管理の対象になっているわけではありません。

とはいえ、新しいサーバーを作ること自体については「かなりコストを下げられた」と言えます。

まとめると…

デプロイの自動化により、アプリケーションのデプロイの速度が12倍高速になりました。
サーバー構築の自動化により、構築が8倍高速になりました。

この2つの自動化を達成したことにより、継続的デリバリーとかBlue-Green DeploymentとかImmutabie Infrastructureとか、諸々のモダンな開発運用環境への足がかりを得ることができました。

皆さんは、是非この辺りの自動化から進めてみてください。
そして環境改善を行い、そして実績負債を解消して欲しいと思います。