【読書】The DevOpsハンドブック
もっといい開発方法はないだろうか？そんなことをよく考えます。
一方で昨今のシステム開発はリリースしても、運用しながら開発を続けることが多くなっています。
特にSaaSの自社製品はサブスクリプションの採用で、継続的な機能追加・機能改善による顧客の維持が重要になっています。
売り切りよりもお金を払ってもらい続ける方がキャッシュが安定しますから。
またスマホゲームもそういうものが増えていますね。継続的に機能が増えたり、RPGだったら最初からストーリーが全てあるのではなく、徐々に追加されていったりします。
その間はガチャや追加コンテンツなどで課金してもらって稼ぐというわけですね。
私が所属する会社は企業向けのシステムに関わっているのですが、やはりリリース後も運用しながら開発を続けています。
そこでDevOpsの本を読んでみました。
リードタイムを短縮しデプロイ頻度を上げる
ITバリューストリーム
本書にはITバリューストリームという概念が出てきます。
ITバリューストリームとはユーザーが要望を出してから、要望が本番環境に反映されるまでの工程全体のことです。
元々はリーン生産方式で使われているものです。製品を生産・テストして出荷し、顧客に届けるまでを指します。
システム開発においても、顧客の要望に合わせて要件定義・設計を行い、製作・テストを行って、出荷に当たるデプロイを行います。この流れはハードウェアでもソフトウェアでも変わらないわけです。
そしてこのバリューストリームを短縮することが、顧客にとってのリードタイムを短縮することになります。
バッチサイズを小さくすることでリードタイムを短縮できる
本書ではバッチサイズを小さくすることで、顧客が要望を出してから本番環境にデプロイするまでのリードタイムを短縮できると解説されています。
バッチサイズとは1回に生産する量のことを指します。ソフトウェアでバッチというと、一括処理のことを指します。
そもそも生産管理で一度にまとめて処理する作業をバッチと呼び、一度に処理する量をバッチサイズと呼びます。
バッチサイズを小さくするには、ハードウェアだったら生産する数を減らす、つまりロットサイズを小さくするという方法があります。
ソフトウェアでバッチサイズを小さくするには、1回のデプロイで本番機に載せる機能数を減らすということになります。
注意点として、沢山作ったうちの一部をデプロイするという意味ではなく、1回の開発サイクルで作る機能を少なくするということです。
デプロイ対象の機能が少なければ少ないほど、開発にかかる期間も短くなります。するとユーザーにとってのリードタイムが短くなります。
デプロイ頻度を上げるメリット
デプロイ頻度を上げるメリットの1つとして、デプロイを安全にできることが本書では挙げられています。
例えば開発費が1億円以上になるような大きなシステムをウォーターフォールかつビッグバンで開発することを考えてみてください。
単純計算で1人月100万円として、1億円なら100人月です。10人程度のチームで1年かかります。これをビッグバンですので1回の本番リリースで全機能をリリースします。
ITエンジニアなら想像がつくと思いますが、本番リリースの準備はとても大変なものとなるでしょう。何度もリハーサルを行った上で、本番リリース当日も緊張感の中で長時間の作業を行います。
こう考えるとアジャイルのように2週間とか1ヶ月でできるボリュームで頻繁に本番リリースを行った方が安全でしょう。
ウォーターフォールかつビッグバンほどの入念な準備は必要ないでしょう。もちろんしっかり準備する必要はありますが。
つまりバッチサイズを小さくしてデプロイ頻度を上げることで、本番リリースの危険度を下げることができるのです。
検証環境へのデプロイで練習試合を行う
これに加えて本番環境と同等の検証環境を用意しておくことも本書では挙げられています。
小さなシステムだと検証環境を用意するだけの予算を割いてもらえないかもしれませんが、大抵のシステムは本番環境とは別に検証環境があると思います。
バッチサイズを小さくしてデプロイ頻度を上げ、検証環境へのデプロイを繰り返すことで、実は練習試合を沢山やるような効果が得られるのです。
検証環境へのデプロイを繰り返すことで、本番環境へのデプロイに必要な作業手順を繰り返し練習できます。
また本番環境へのデプロイで起こりうるトラブルを、検証環境で事前に体験することも可能です。
チーム構成
組織構造はシステム構造に影響する
Conwayの法則というものが本書では紹介されています。組織構造はシステム構造に影響するという法則です。
大きな会社がシステムを作れば大きなものができます。システムの構造も開発チームの構造に合ったものが出来上がります。
例えばAチームとBチームに分けて作れば、A機能とB機能に分割されたシステムができるわけです。
また縦割りサイロ化が進んだ組織がシステム開発を行うと、プロジェクトメンバーは縦割りで役割分担され、他人の作業は知らないということが起こります。
役割分担が細かいと、担当者の作業待ちが沢山発生し、リードタイムが長くなります。その人しかできない仕事が増えるので、その人の手が空くまで待たなければいけないことが増えるのです。
小さなチームを活用する
本書では小さなチームを活用するという話が出てきます。代表的なものがtwo-pizza teamです。
少人数かつ自律的に動ける小さなチームはスピーディーな開発を行えるということです。
人月の神話でも書かれていますが、チームが大きいほどコミュニケーションコストが上がります。だから小さなチームの方がスピーディーなのです。
また本書ではジェネラリストを育成することも同時に書かれています。スペシャリストはボトルネックを作るとも書かれています。
一般的にはジェネラリストは中途半端で使えないのでスペシャリストが好まれます。ましてや日本はこの道何十年の職人が高く評価される社会です。
欧米だってジョブディスクリプションがしっかりしているので、スペシャリストの方が仕事を探しやすいでしょう。
しかし小さなチームでは、一人で何役もこなせるジェネラリストでなければ仕事が回りません。
社員の学習を促し、ジェネラリストを育て、一人で何役もこなせるようになってもらうのです。そうして小さなチームを効率的に回せれば、開発効率はとても上がるというわけですね。
ちなみに私は少数精鋭型の働き方が好きです。私自身マネジメントでずっと生きてきましたが、チームの人数はずっと1桁です。そしてIT業界にありがちな工程による担当者の変更もしません。
1人が設計・実装・テストをこなした方がコミュニケーションコストが下がって速くなるからです。
これは人数が10人以下の少数精鋭チームならではです。大規模プロジェクトでは役割分担にメリットがあるかもしれませんので。もちろん大規模プロジェクトでもチームの構成次第でやり方は変わります。
自動化を進める
理想はボタン1つでデプロイできること
本書には開発者がボタン1つでデプロイできるのが理想と書かれています。
本当は自動化を進めることで、デプロイボタンを押すだけでデプロイ作業が完結するのがいいでしょう。こうすることでデプロイ時のオペミスを防ぐことができます。
これをやるにはCI/CD環境を整えないといけませんね。そこまで環境構築で来ている会社やプロジェクトばかりではないでしょう。
計測によってコンディションを把握する
ログやサーバーのコンディションのモニタリングを活用すれば、本番環境での問題に早く気付けることが解説されています。
理想を言うならばユーザーが気付く前に問題を感知して、すぐに修正してしまうのがいいですね。
それをやるのは計測を作り込むことが必要です。
ユーザーにとっての問題が少ないシステム運用をするためには、テストをしっかりやって品質の高いシステムを作るだけではなく、予防や修復の仕組みも大事ということを覚えておきたいものです。
テクニカル面での実践例
本書は中盤くらいまでは生産管理や組織論をシステム開発に適用する話です。そして後半になるとテクニカル面での実践例が登場します。
私が気になったものをいくつか挙げてみます。
ブルーグリーンデプロイ
2つの本番環境を作り、緑は検証環境、青は本番環境とします。
通常はユーザーからは本番環境である青につながっています。緑は検証環境なので、テストを行うユーザーしか接続できません。
緑と青の環境は入り口のルーターで分けています。本番環境へのアクセスなら青へ、検証環境へのアクセスなら緑へつながるように、ネットワークを設定します。
この状態で緑の環境に新機能をデプロイしてテストします。テストが完了したら、ルーターの設定を切り替えます。そして本番環境へのアクセスは緑に、検証環境へのアクセスは青につながるように変えます。
このブルーグリーンデプロイのメリットは、もし新機能に大きな不具合などの問題があったら、ネットワーク設定だけで切り戻しができることです。
デプロイ作業自体をやり直して前のバージョンに戻すことは面倒です。ネットワークの設定変更だけで切り戻しができるのなら楽なものです。
コンテナでサーバーをインスタント製品のように使う
今まではサーバーの調子が悪くなったら修理して使っていたという話が本書に出てきます。その通りでサーバーの設定変更や再起動を行うことで、サーバーが堅調に動くように設定していました。
しかし最近はコンテナが増えてきたので、サーバーのインスタント化が進んでいると本書では書かれています。
つまりインスタント品すなわち使い捨ての製品にサーバーがなってきているのです。
コンテナであれば設定ファイルに沿っていくつもサーバーとして立ちあげられます。
調子が悪くなったら修理するのではなく、シャットダウンしてしまいます。そして設定ファイルに沿って新しいコンテナを作って立ち上げればいいのです。
つまりコンテナによってサーバーが使い捨て化し、調子が悪くなる度に新品のサーバーに入れ替わるのです。
これはサーバーが仮想化したからできることでもありますね。物理的なサーバーを使い捨てにするのはコスト面でもそうですが、それ以上に資源の面で問題がありすぎますから。
本番機にエラーを注入して訓練
NetflixではChaos Monkeyと言う方法を使っているそうです。これは本番機にわざとエラーを注入するという方法です。もちろん数あるほんの一部の本番機にです。ユーザーに影響が出てはまずいですから。
本番機にわざとエラーを注入するメリットは、万が一本番機でトラブルが起きたときに、どういう問題で困って、どう対処するかが解るということです。
当然ながら本番機でトラブルが起きるとものすごい緊張感が走ります。そして急いで問題の原因を特定し、対策を打たなければいけません。ユーザーに迷惑をかけてしまいますし、ビジネス面での損失も出てしまいますから。
そこで日頃から避難訓練のようなことをしておくのがChaos Monkeyという方法です。
この方法はいわば震度6とか7を実験できる建物で避難訓練をするようなものです。そんな避難訓練をしておけば、本番機で起こりうるトラブルへの事前対策や、起きたときの素早い対応ができるようになるということです。
これでTVで見た避難訓練の話をふと思い出しました。
今年の能登半島地震の被災地のとある町では東日本大震災以来、毎年避難訓練を行っていたそうです。その町は能登半島地震で町民全員が無事に避難できたそうです。
何もしないといざというときに何もできません。でも少しでも訓練を行っておけば、何をすればいいかは知っています。上手くできるかというと微妙ですが。
NetflixのChaos Monkeyは実施する頻度が高いのでしょうから、日頃から震災レベルの地震を体感できる建物で避難訓練を行っているようなものです。もしそうだとしたら消防士みたいですね。
実験を行う
本書には頻繁に実験するという話もありました。自動計測と短時間でのデプロイを実現すれば、A/Bテストのような実験もしやすくなります。
またカナリアリリースという方法も存在します。これは一部のユーザーだけに新機能をリリースし、問題がなければユーザー数を増やして行くと言う方法です。
例えば社内だけにリリースして、次に社外の一部のユーザーにリリースします。それでも問題なければ全ユーザーに展開します。
終わりに
本書は実に色々な知識や考え方、実践テクニックが解説されています。
しかしやりたいことは安全に短期間で顧客の要望を実現することなのかなと思います。
それがリードタイムを短縮することとデプロイ頻度を上げることです。
本書はとても分厚いので、一言では語れません。DevOpsや効率的なシステムの開発兼運用を求めている方は是非読んでみてください。
この記事が気に入ったらサポートをしてみませんか？