「The DevOps ハンドブック」を読んだ
「The DevOps ハンドブック」を読んだので感想を書きます。
https://www.nikkeibp.co.jp/atclpubmkt/book/17/P85480/
The DevOps ハンドブック 理論・原則・実践のすべて
仕事でMLOpsに取り組んでおり、名前の通りMLOpsはDevOpsに影響された概念だと思うので、まずDevOpsを知るために読むことにしました。
どんな本？
DevOps導入の取り組みを成功させ、目指した目標を達成するために必要な理論、原則、実践を読者に伝える（序章 0.3節）
ための本で、
ITバリューストリームの仕事をおこなっているか影響を与えているすべての人々のための本であり、ほとんどのITプロジェクトを生み出すもととなっている経営者、販売推進リーダーのための本（序章 0.3節）
です。
DevOpsとは、リーン生産方式の原則をITバリューストリームに適用し、バリューストリームの一部であるデプロイのリードタイムを削減するための取り組みを指します。
DevOpsを実践すると、
デベロッパーの小規模なチームが、ほかのチームに依存せずに独力で機能を実装し、本番に近い環境でその正しさをチェックし、すばやく安全、セキュアに本番環境にコードをデプロイできるように（序章 0.2.1節）
なります。
DevOpsにはそれを支える3つの原則があります（本書では「3つの道」と呼んでいる）。
- 開発->運用->顧客の左から右の高速なワークフローの実現
- 右から左へのフィードバックフローの実現
- 成功と失敗の両方から組織として学習する文化の実現
この3つの原則に基づいた様々なプラクティスが紹介されています。 また、DevOpsを適用し変革を果たした企業の事例も多数収録されています。
気になった点
DevOpsではリーンの原則を適用する
本書ではDevOpsとはリーンの原則に基づいてデプロイのリードタイムを削減する取り組みだと書かれており、これまでもDevOpsはアジャイルと似ている点があるなと感じていたのでなるほどと思いました。
リーンにはリードタイムの削減とバッチサイズの縮小という二大基本原則があるため（序章 0.1.2節）、開発・デプロイをより頻繁におこない（バッチサイズの縮小）、デプロイリードタイムを削減することで、ITバリューストリーム全体のリードタイムを削減します。
デプロイのリードタイムを伸ばす原因は運用だけではない
本書ではデプロイのリードタイムを伸ばす原因として運用だけでなくQAやセキュリティについても触れられています。
確かに開発が完了してからQA・セキュリティチェック・運用を別チームに依頼すると各チームのキューの中で待たされることになり、デプロイのリードタイムを長くすることにつながるので、QAやセキュリティについてもDevOpsの枠組みで考えるのは自然なのかと感じました。
市場指向チームの実現
7.3節には
DevOpsの成果を得たいと思うなら、職能指向（「コストのために最適化」）の影響を抑え、市場指向（「スピードのために最適化」）を実現して、独力で安全に仕事を進められる小さなチームを編成して、顧客に価値を早く届けられるようにする必要がある。
とあり、これを実現するために
サービスチームに各種のスキルを持ったエンジニア（たとえば、運用、QA、情報セキュリティ）を配置したり、自動化されたセルフサービスプラットフォームを通じてチームに運用、QA等の職能を提供したりする
と書かれています。
かといって運用部門が全く必要ではないかというとそんなことはなく、サービスチームが独力でサービスを提供できるようにするための実践方法は第8章に記載されています。
CI+
10章の脚注で、
開発においての継続的インテグレーションとは、複数のコードブランチを継続的にトランクにインテグレートして、ユニットテストを合格させることだと考えられていることが多い。しかし、継続的デリバリーとDevOpsの文脈からは、継続的インテグレーションとは、本番に近い環境での実行と受け入れ、インテグレーションテストでの合格を義務付けることでもある。Jez HumbleとDavid Farleyは、後者をCI+と呼ぶことによって両者の区別をはっきりとさせている。本書で継続的インテグレーションという用語を使うときには、かならずCI+の実践という意味になる。
とあり、CIに対する自分の理解も前者だったのでこの脚注を意識しておかないと11章の内容に違和感を感じることになる。というかなりました。
トランクベースの開発
11.2章で
トランクベースの開発では、すべてのデベロッパーが1日に少なくとも1回はトランクにコードをチェックインする
と紹介されています。
GitHubのpull requestベースの開発に慣れてしまって、数日程度自分のブランチで作業してからトランクにマージするのが普通の感覚になっていたので、1日に少なくとも1回マージするというのは非常に斬新に感じました。
MLOpsにも応用できそうな点
さて、自分の本来の目的はMLOpsについて理解を深めることでした。この本の内容をMLOpsに適用してみるとどうなるか？
まず、ITバリューストリームと同様に「MLバリューストリーム」を定義してみたい。ITバリューストリームは
ビジネス上の仮説を立案してから、顧客に価値を送り届ける技術サービスを生み出すまでの間に必要なプロセス（1.2節）
なので、MLバリューストリームは「ビジネス上の仮説を立案してから、顧客に価値を送り届ける機械学習を用いたサービスを生み出すまでの間に必要なプロセス」とでもなるでしょうか。
MLを利用したサービス開発には、通常のサービス開発にはない難しさがいくつかあります。
まず機械学習にはデータが必要なので、データを機械学習に利用しやすくするためデータ基盤の構築が必要です。 また、精度の向上のため頻繁に実験をおこなうため、実験に必要なマシンリソースの確保や実験の結果を管理しやすくするツールなども必要です。 さらに、本番環境に機械学習モデルをデプロイした後に本番環境で観測できるデータの分布が変化すると精度が劣化してしまうため、モニタリングが必須です。 なので、MLOpsの場合は単にデプロイのリードタイム削減にとどまらず、MLバリューストリームの様々なプロセスに対して働きかける必要があるでしょう。
チーム構成については、機械学習エンジニアやデータサイエンティストだけからなるチームではなくソフトウェアエンジニアも含めた職能横断的なチームを作り、それとは別の機械学習プラットフォームを作るチームがプラットフォームを提供して機械学習チームの生産性を上げる、という形になるのではと思いました。
「DevOpsから考えるMLOps」というテーマで記事が一つ書けそう。
まとめ
自分の場合はMLOpsをちゃんと理解するためにまずDevOpsを知ろうと思いこの本を読むことにしましたが、単にDevOpsのみを知りたい人にももちろんおすすめです。非常によくまとまっており、これからDevOpsを実践しようとしている組織のリーダーや、DevOpsに興味のある現場のエンジニアはとりあえず読んでみて損はないと思いました。