無料を好んで人件費がかかりすぎ!? 過剰なベンダーロックイン恐怖症から脱却を！
冒頭から「こんなタイトルで人が集まるとは（笑）」と、ハイテンションで登場した牛尾氏。そんな牛尾氏による本セッションのテーマは「Be Lazy（楽をして）でDevOpsの自動化の第一歩を踏み出そう！」だ。
セッションは牛尾氏が最近疑問に感じている話題からスタート。みんな「0円＝タダ」が大好き。お金をかけることは誰も好まない。牛尾氏自身も元々は商業ツールを好まず、できるだけオープンソースを活用することを考えてきた。しかし「最近、意識が変わってきた」という。
そもそも、なぜベンダーロックインが好ましくないのか。恐らく「高い汎用機やシステムを購入し、それを使い続けるしかなかった」思い出を持つ人が多いからだろう。つらい記憶があるからこそ、ベンダーロックインを避けてきたのではないだろうか。
「しかし、それが過度になり、逆に損しているのでは？」と、牛尾氏は問いかける。
近年、有料の製品といえばソフトウェアやサービスを指すことが多く、以前主流だった汎用機や大型システムと比べると安価なものが中心だ。解約や移行も簡単にできることが多い。それなのに、なぜ今も「ベンダーロックインを避けること」にこだわり続けるのか。
むしろ、今の時点で最も高価になっているのは人件費であり、無償の製品を使用するために人を雇うのであれば本末転倒だ。牛尾氏は「車輪の再発明よりも、（既に存在する良い製品に）お金を払おう」と語る。ベンダー提供のツールやソフトウェアを賢く使うことが、本セッションのテーマである「Be LazyでDevOpsの自動化の第一歩を踏み出そう！」につながっていくのだ。
DevOpsでは自動化の技術的な話がクローズアップされがちだが、それだけではなく、重要なポイントが3つ存在する。
まず、「人」の考え方やマインドセット、組織の在り方について考えること。次いで開発の手法や進め方といった「プロセス」の改善。その上で最適な技術や「プロダクト」の活用が求められる。「人」「プロセス」「プロダクト」を集合体として考え、エンドユーザーに対して継続的に最高の価値を提供することがDevOps本来の意味だ。DevOpsが実現すれば「1日に10回ものデプロイが可能となる」といわれているが、「現代の技術を活用すれば簡単にできることだ」と、牛尾氏。
DevOpsの目的は次の3つだ。まず1つ目は、アイディアを思いついてからデプロイするまでの時間の短縮、つまり「リードタイムの短縮」である。そして2つ目は「本番環境やユーザーから開発側へ、速やかなフィードバックを届ける」ことだ。以前は「本番環境に出す前に、できるだけ精度を上げるべき」という考え方が一般的だった。しかし現在では、「できるだけ早く本番環境に反映させ、フィードバックを得つつ改善していくことが望ましい」。なぜなら本番環境に置いて初めて判明する問題もあるからだ。こうしたデプロイとフィードバックを繰り返す「継続的な実験と学び」が3つ目に挙げられる。
実際、DevOpsを実現することで得られるメリットは非常に大きい。コードのデプロイ速度は30倍にもなり、リードタイムは1/2555に短縮され、障害復旧は24倍の速さで実現、変更の失敗率は1/3にまで削減可能、とされている。必然的に導入の有無で大きな差が生まれることになり、その影響は将来にわたって続く可能性が高い。
DevOpsな開発環境を実現するため、初心者にオススメの「バリューストリームマッピング」とは？
DevOpsで重要となる自動化の導入ステップについて、牛尾氏はまず「DevOpsプラクティスを理解する」こと、つまり考え方を理解することが重要だと語る。Infrastructure as Code（IaC）や継続的インテグレーション、自動テスト、継続的デプロイなど、主要なプラクティスを理解することで、適切なツールを選定することができる。ちなみに牛尾氏は、DevOpsのスタータキットを公開しており、DevOpsの概要やプラクティスの詳細をデモ付きで説明している。
DevOps最初のステップとして、牛尾氏は「バリューストリームマッピング」を勧める。アイディアを実装してデプロイするまでの過程を“見える化”して、リードタイムや実行時間を明確にする手法だ。
バリューストリームマッピングを実行する場合、開発者（Dev）や運用者（Ops）だけでなく、決定権を持つ上層部やビジネスサイドのメンバーなど、あらゆる人を巻き込むことが重要だ。「効率的な開発を妨害するプロセス」や「自動化のため有用な技術」についてディスカッションを行い、情報を共有する。そこから、自動化・効率化について「人・プロセス・ツール」の三位一体で考えていくきっかけが生まれる。
次のステップでは、CI/CD（継続的インテグレーションと継続的デリバリー）の基本チェックリストを用いる。リストの内容を確認し、アプリケーション開発の流れである“パイプライン”を実際に見ながらディスカッションする。ここでは牛尾氏の経験則から想定されるチェックリストが紹介された。内容は基本的なものであるが、これらを意識するだけでも大きな効果が得られるという。
最先端DevOps開発環境から学ぶ「基本動作」の大切さ
次に、牛尾氏が企画し2017年2月初旬に行われた「DevOps EBCツアー」の様子が紹介された。牛尾氏は日本の顧客を米マイクロソフト本社に招き、先進的にDevOpsに取り組むチームや、自動化テストに熱心に取り組むチームなど、DevOpsの最先端を行く開発現場を共に見学した。このツアーを企画した意図を、牛尾氏は次のように語る。
「初めて米国で仕事をしたとき、日本の開発チームと比べて集中力やパフォーマンスが全然違うことに衝撃を受けた。しかも、彼らは特に目新しいことをやっているわけではなかった」
このような体験から、日本の開発者にも米国の開発現場の空気を実際に感じてほしい、と考えたのだ。
牛尾氏はツアーを通じて「基本動作の大切さ」を痛感したという。「DevOpsなどできない」と主張する現場ほど、そもそもアジャイルに対して真摯に取り組んでいなかったり、単体テストを自動化していなかったり……基本ができていないことが多いのだ。
DevOpsは何度もテストを行うことになるので、「回帰テストの自動化」といった基本的な作業をきちんと行うことが重要だ。米マイクロソフトのBing開発チームでは、単体テストはもちろんのこと、その上位層のテストや環境別のテストに関しても自動化している。それだけでなく、長いテスト時間を短縮するため、キューに投げて負担を分散させる仕組みを自分たちで作成し、不要なテストケースを発見して停止させる仕組みを作ったという。効率化にこだわった、これらの工夫には驚かされるばかりだが、彼らとて最初からできていたわけではない。徐々に単体テストの割合を上げ、エンドツーエンド（E2E）テストを減らしてきた。時間と手間をかけて文化を変え、素晴らしいDevOps開発環境を少しずつ実現してきたのだ。
米マイクロソフトにおける、先進的な取り組みを目の当たりにした牛尾氏は「日本ではどうだろうか。難しさを口実に工夫しない。変化を嫌うあまり、進化もしない状況に陥っているのではないだろうか」と、苦言を呈する。テストコードも書かないようでは、アジャイルもDevOpsもマイクロサービスもあり得ない。だからこそ「まずはテストコードを書くこと」を勧めるという。そして「テスト駆動開発（TDD）についてしっかり勉強をするべきだ」と力説する。
- 牛尾氏が作成した動画「6 Minutes DevOps: テスト駆動開発」
牛尾氏はさらに、CI/CDの究極のコツについて言及。「PowerShell」を開発したジェフェリー・スノーバーが「Remove Windows＝マイクロソフトのサーバーからWindowsを取り除いた」ことを紹介した。ウィンドウ、つまりGUIでの操作を自動化するのは難しい。そこで彼は、PowerShellを作ってGUIを使わずにコマンドラインだけで操作ができるようにした。自動化のコツは非常にシンプルで「コマンドラインで動かすこと」なのだ。
DevOpsを快適に推進する「Visual Studio Team Services」
DevOpsを推進しつつ、「ベンダーロックインが嫌い」という牛尾氏は、気に入っているツールとして「Visual Studio Team Services」を紹介。開発者はサム・グッケンハイマー氏だ。彼はAgile Conference 2014のキーノートスピーカーとしても知られ、マイクロソフトのDevOpsをリードした人物ともいわれている。
Visual Studio Team Servicesは、SaaS版であれば3週間ごとにアップデートされ、衝撃的なスピードで使いやすさが増しているという。「なぜ、日本で使われていないのか分からない。過小評価されている」と、牛尾氏が憤るほどだ。標準機能だけでも、自動化ツールや情報共有ツールなど、DevOpsに必要な機能がほぼ網羅されている。
Visual Studio Team Servicesの特徴的な機能の1つとして、牛尾氏は「Hosted」を例に挙げた。自動化に必要なビルドマシンが用意できない状況でも、この機能を使えば自らサーバーを立てる必要がない。さらに、OSはWindowsとLinuxがいずれかを選択できる。Macを使用したい場合は、エージェントを入れることによって対応が可能だ。
そして、牛尾氏はDevOpsプラクティスの1つである「継続的インテグレーション」に触れた。アプリケーション開発中、「ブランチを切ってメインラインにマージする」過程の時間、つまり結合までの時間が長ければ長いほど、コンフリクト発生の可能性が高くなる。この問題を解決すべく、アジャイルマニフェスト起草者の1人であるケント・ベック氏は「常に結合し続ければ問題が減るのでは？」と考えた。コードに変更があればすぐにビルドして結合する。そこで問題が生じたとしても、すぐに解決し、再び結合することで問題の影響範囲を最小限にとどめることができる。このように変更と結合のサイクルを小さく回す仕組みにすれば、コードへの変更が多い環境でも大きな手戻りがない。加えて、自動テストを行えば安全に開発を進めることができる。これが「継続的インテグレーション」だ。逆に言うと、ブランチを切ってマージするまでの時間が長ければ、どんなに素晴らしいツールを導入しても“ひどい目”に遭う可能性は高い。つまり、考え方をチームでシェアしていかなければツールを活用することはできない。
さらに、プラクティスの1つである「リリースマネジメント」の中で、環境を作ったり、負荷テストを行ったりする際にも自動化は必要だ。パイプラインの基本的な作り方に、ビルドした成果物をそのままリリースに使用し、さまざまな環境にデプロイしていく手法がある。というのも、どんなに開発環境側でビルドやテストを行っても、リリース側でビルドやテストを行う際にパッケージが変わる可能性もあるため、同じものである保証はできないからだ。
ここで、Visual Studio Team Servicesがさまざまな環境にデプロイしていくデモを行おうとしたものの、ネットワーク不調のため接続できず、断念することに。そして、デモの中で披露されるはずだったDockerのオーケストレーションツール、Kubernetes（キューバネイティス）の機能に触れつつ、タスクを書いたのが牛尾氏自身であることが明かされた。タスクは隠蔽されて使用者からは触れないと思われがちだが、ソースは全て公開されている上に、自作することも可能だ。
デモ動画［1］
ネットワークの不調で当日実施できなかったデモを、牛尾氏は動画で公開している。
デプロイ時に活躍する「Vamp」とは
牛尾氏は次に、カナリ―テスティングにおける「Vamp」を使ったテクニックを紹介した。カナリーリリースは全てのサーバーに対してデプロイする前に、まずは限られたサーバーにリリースして、新しい機能が問題なく動いているか確認してからロールアウトする手法だ。これに対し、データセンターを1台のコンピューターのように抽象化して扱うためのツール「DC/OS」と「Azure Container Service」を用いて、さらにオープンソースのツールであるVampを使えば、“かなり面白いこと”が実現できるという。
例えば、マイクロサービスを作る際にはAPIゲートウェイが必要になるが、Vampを使ってデプロイするとAPIゲートウェイも同時に作成され、構成まで行われる。ブルーグリーンデプロイやカナリ―テスティングも簡単に行うことができる。さらに、サービスディスカバリやスケールアウト／イン、自動回復などの機能もカバーしている。DC/OSやKubernetesと併用すれば、かなり強力なツールとなるのだ。
ここでVampのデモを行おうとしたが、またもやネットワークの不調で断念することに。ちなみにその内容は、用意しておいたIPアドレスにアクセスすると2つの環境どちらかに振り分けられ、その振り分けの割合をVampのGUIのスライダーで容易に設定・変更することで、ロールバックやロールアウトが容易にできるというものだった。
デモ動画［2］
ネットワークの不調で当日実施できなかったデモを、牛尾氏は動画で公開している。
さいごに
最後に、牛尾氏は「やってみたらどうなるか、失敗したらどうなるかと、日本人が躊躇している間に、海外では試行錯誤しながらどんどん自動化を進めている。もちろんひどい目に遭うこともあるが、そこで得られるスキルも多い。不安に思う前にまずはやってみて、愚直にテストを実践することが大切なのではないか」と語り、「疑ったり必要以上に調査をしたりする前に、やってみよう。やるかどうかを悩むより、やってダメなら撤退する方針のほうが良い」と訴えた。
さらに「本番で学ぶ」ことの重要性を強調。自動化を試す場合でも、テスト環境ではなく、本番環境に投入することによって初めて見えてくる課題があるということだ。
牛尾氏は改めて当初のテーマに立ちかえり、かつてビル・ゲイツが不正コピー問題について激怒し、書いたといわれる手紙の中の一節「Most directly, the thing you do is theft（はっきり言って、君がやっていることは盗みだ）」を紹介。現在でもオープンソースのベンダーはマネタイズに苦労していることを指摘した。そして「無料に慣れ過ぎているのを改めよう。イケてるソフトウェア、良いツールにはお金を使おう。その結果、ソフトウェア産業が潤い全体が良くなっていく」と語り、「ぜひともVisual Studio Team Servicesを使ってみてほしい」と訴えてセッションを終えた。
デモ動画［3］
こちらも牛尾氏が公開しているデモの動画。VSTSを使用し、何もない状態から、リポジトリの作成、CI/CDパイプラインの作成、Infrastructure as Codeの作成と適用、リリースまでを30分程度で実施、解説している。
お問い合わせ
日本マイクロソフト株式会社
- TEL：03-4332-5300（大代表）
- コーポレートサイト
