セルフサービスツーリングの思想から生まれたNetflixのフルサイクル開発者

Netflix Technology Blogの記事に、同社のEdge Engineeringチームが実施したサービス開発と運用に関するアプローチの実験と、その結果“フルサイクル開発者(Full Cycle Developers)”が誕生するに至った経緯が公開されている。このアプローチは、開発者がサービス提供の特定の運用面を担当すべく、トレーニングや一連のセルフサービスツールによってサポートするという、Netflixの姿勢を示すものだ。プラットフォームやツーリングの開発やメンテナンスは専任のチームが担当するが、社内の各チームにはその“決められた道”を逸脱する自由が認められている。

記事の筆者であるPhilip Fisher-Ogden、Greg Burrell、Dianne Marshの３氏は、このソフトウェア提供サイクルの目的について、アイデアを実際のユーザ向け製品やサービスに効率的に変換する“Time to Value”の最適化にある、と述べている。考え方としてはDanNorth氏やJessica Kerr氏の、現代のソフトウェア開発は“ビジネスインパクトへのリードタイムを持続的に最小化する活動”を重視すべきだ、という提案に通じるものがある。ソフトウェアサービスの開発と運用には、設計、開発、テスト、デプロイ、運用、サポートという、すべての責任が関与する。従来、これらの責任は、企業内のサイロとして分割され、担当されていた。古典的なDevOpsの書籍である“The Phoenix Project”はその典型だ。

これらの専門化された役割は各セグメントを効率化する反面、ライフサイクル全体としては潜在的な非効率性を生むことになる。Netflixでビデオストリーミングに必要なAWSサービス第1層を担当するEdge Engineeringチームは、DevOpsムーブメントの原則からインスピレーションを導き出して、従来のアプローチを再検討することにした。特にGene Kim氏が広めた“DevOpsの3つの方法(Three Ways of DevOps)”には、システム思考の重要性、フィードバックループの強化、継続的な実験と学習の文化の育成について説明されている。

Edge Engineeringチームの新たなアプローチでは、“開発したものが運用する(AmazonのCTOであるWerner Vogel氏によって有名になった、“開発したものが運用する”という考え方に近い)”という点に重点を置いて、システムを開発したチームが稼働環境での運用やサポートにも責任を持つことにより、DevOps原則の実践を図っている。

この責任を外部に渡すのではなく、それぞれの開発チームが負うことによって、インセンティブを伴った直接的なフィードバックループが作り出されます。運用の苦労を体験したチームは、システム設計やコードを変更する苦労を厭わなくなります - つまり両方の役割を理解し、その責任を負うようになるのです。

このアプローチで問題となるのは、開発ライフサイクルすべてのオーナシップが開発者にとってさらに負荷となったり、新たなスキルを学ばなくてはならなくなることだ。責任が個人やチームに課されることにより、バーンアウトを発生させる可能性もある。これらの問題を軽減する方法は、関係する開発要件や運用要件を簡略化し、自動化するためのツールを活用することだ。Netflixでは、“クラウドプラットフォーム”、“パフォーマンスおよび信頼性エンジニアリング”、“エンジニアリングツール”というような専門のサポートチームが用意されて、共通(“Paved Road / 決められた道”)プラットフォームや、すべての開発チームが抱える問題を解決するツールの開発を担当している。これらツールの多くは、継続的デリバリシステムのSpinnakerのように、Netflix OSS運動の一部としてオープンソース公開されている。

考え方の転換、共通インフラストラクチャの構築、そしてツーリングを組み合わせることで、“フルサイクル開発者”が生み出された。フルサイクル開発者には、ソフトウェアライフサイクルすべての分野に熟知し、その能力を持つことが期待される。フルサイクル開発者モデルに移行するには、考え方の転換が必要だ - フルサイクル開発者はソフトウェア開発者(SWE)、テストにおけるソフトウェア開発エンジニア(SDET)、サイト信頼性エンジニア(SRE)として思考し、行動する。Netflixの採用するすべての開発者がこのようなスキルセットを持っている訳ではないので、広範なトレーニングが提供されることになる。さらにブログ記事では、すべての技術者がこのような業務を望むのではなく、Netflixでもより専門的な役割を選択する機会がある、と述べている。

このモデルを採用するNetflix以外の企業には、適応性が必要になる可能性が極めて高い、とブログ記事では警告している。それはこのモデルが、Gareth Rushgrove氏のような業界の思想リーダや、氏が2016年に行ったプレゼンテーションの“Two Sides of Google Infrastructure for Everyone Else”で紹介されているような、評価の高い“ソフトウェアユニコーン”企業のプラクティスからのカーゴカルト(cargo-culting)や盲目的コピーの排除を迫るからだ。Matthew Skelton氏と(InfoQエディタである)Manuel Paisが“DevOps Team Topologies” Webサイトで銀論したように、開発要件や運用要件を解決するために構築されたアプローチや組織構造は、極めて広範にわたっている。

フルサイクルアプローチの採用を検討する企業に対して、Netflixブログの筆者たちは、まず潜在的な価値と関連するコストを分析した上で、考え方の転換を図ることを提案している。NetflixのブログやWeb一般には関連情報が数多くある。その他にも、プラットフォームやツールのオープンソースおよびSaaSソリューションもあり、多くの企業のニーズを満たしている。講演を締め括る言葉として重要なのは、シンプルさを重視するということだ。“何が必要かを吟味して、複雑性の導入を必要最小限にすることを心掛けてください。”