• [アーティクル]

年 9 月 2015

ボリューム 30 番号 9

DevOps - マイクロソフト スタックでの DevOps の実現

Michael Learned | 年 9 月 2015

このところ、DevOps にまつわる話題が多くなっています。組織のカスタム ソフトウェアは、自社のビジネス ユーザーに充実したサービスと有益なデータを提供するうえで欠かせません。上質なソフトウェアを迅速に提供することはもはやオプションではなく、必須です。長期間の計画を経て繰り返し開発を行う時代はもはや過去のことです。Microsoft Azure などのクラウド プラットフォームの登場で、これまでのボトルネックが解消され、インフラストラクチャの共有が進んでいます。ソフトウェアは、あらゆるビジネスの成功の鍵を握る差別化要因であり、重要な要素になっています。組織も、開発者も、IT 担当者も、DevOps に向かう流れに逆らうことはできません。

DevOps の定義には、さまざまな見方があります。しかし、大半は、ソフトウェアをできる限り効率よく運用に移行できるように、開発チームと運用チームの間にある文化やテクノロジの壁を取り払うことを指します。ソフトウェアを運用に移行したら、多岐にわたる使用状況データを記録し、そのデータを開発チームと意思決定者にフィードバックできるようにする必要があります。

DevOps に役立つテクノロジやツールは数多く存在します。このようなツールやプロセスが、運用アプリケーションの迅速なリリース サイクルとデータ収集を支えます。マイクロソフト スタックには、迅速かつ予測可能なリリースを実現する Release Management や、アプリの多岐にわたる使用状況データを記録できる Application Insights などのツールがあります。今回は、DevOps のさまざまな側面 (図 1 参照) と、DevOps で使用する重要なツールやテクニックに注目し、解説します。

DevOps のさまざまな側面
図 1 DevOps のさまざまな側面

DevOps の役割

多くの組織は、次の分野で DevOps 体制による改善を見込んでいます。

  • 短いサイクルで信頼性のあるテストとリリースを実現する自動リリース パイプライン。
  • アプリケーション運用後の、要求の変化や不具合への迅速な対応力。
  • 運用中のアプリケーションの使用統計情報と使用状況データを記録と、"直感" 重視の意思決定からデータ重視にシフトするための記録データの活用。

このような DevOps の側面を妨げるサイロは組織内にあるでしょうか。このようなサイロは、ツール、スクリプト言語、ポリシー、部門の境界線など、さまざまな形で存在します。サイロには、各業務を分担して、セキュリティを管理し、運用中の安定性を確保するという目的があります。

このような目的があるとはいえ、組織が DevOps で実現を目指す多くの目標が、こうしたサイロによって妨げられることがあります。たとえば、運用上の問題への対応や、迅速かつ信頼性の高いリリースなどの実現の妨げになります。多くの場合、こうしたサイロ構造が驚くほど多くの無駄の原因になっています。開発者と運用担当者は、これまで異なる目標を掲げる別のチームで仕事をしてきました。開発チームと運用チームは、サイロの壁によって生じる問題の解決に時間をとられ、ビジネスの運営に力を注ぐ時間が少なくなっています。

企業の意思決定者は、新たな視点からさまざまな境界に目を向け、正確な ROI や、上記のサイロによって実現を目指した本当のメリットを評価する必要があります。サイロの壁を取り除くことができれば、正確な ROI や本当のメリットが明確になり、DevOps ソリューションを実装して無駄を省くことも容易になります。

アジリティに対するニーズとのバランスをとりながら、セキュリティ、統制、コンプライアンスなどを適切に確保することは簡単ではありません。企業のセキュリティ チームは、データの安全性と機密性が確保されていることを保証しなければなりません。セキュリティは、組織のどの業務にも劣らず重要であることは間違いありません。

しかし、セキュリティの境界が生み出されるたびに関連コストが発生します。セキュリティの境界が原因でチームに無駄や摩擦が生じるのであれば、この境界を新しい視点で見直す価値があります。その結果、チームによって ROI がもたらされるようになります。世界有数のセキュリティを確保している組織になれたとしても、ソフトウェアを予定通りにリリースできなければ競争に遅れを取ることになります。

こうした優先順位のバランスを取るという課題は今に始まったことではありませんが、組織がこれまで生み出してきたさまざまなプロセスやサイロに対し、率直かつ新たな視線を向けるときがきています。チーム全員が、個々の目標ではなく、ビジネス価値に重点を置くべきです。

リリース パイプライン

リリース パイプラインでは、バージョン管理を行いながらコードが作成され、そのコードがさまざまな環境を経て、最終的に運用環境にリリースされます。その過程で、自動ビルドと自動テストが実行されます。リリース パイプラインには、変更から運用への移行に透明性があり、反復可能で、信頼性が高く、その上迅速であることが求められます。ここには自動化が必要になることは間違いありません。このリリース パイプラインには、アプリケーション ホスト環境のプロビジョニングが含まれることもあります。

次の要因が存在すると、リリース パイプラインが最適化されない可能性があります。

  • 使用しているツールとプロセスが環境ごとに異なり、ツールとプロセスの組み合わせが不適切な場合 (たとえば、開発チームと運用チームが別々のツールを使用している)。
  • 間違いが起こりやすい手作業の手順を避けている場合。
  • 新しい環境に配置するだけでも再構築が必要な場合。
  • トレーサビリティに欠け、リリース済みのバージョンの把握が難しい場合。
  • リリース サイクルが長く、修正プログラムのリリースにさえ時間を要する場合。

プロビジョニング

コンテナーのプロビジョニングは、リリース パイプラインではオプションと考えられることもあります。従来のオンプレミスのシナリオでは、多くの場合、Web アプリケーションをホストする環境は既に運用されています。IIS Web サーバーなどのホストや、SQL Server のようなバックエンドは、数え切れないほどのイテレーションを行って運用されています。このような環境に向けて迅速にリリースする場合は、アプリケーション コードと関連 SQL スキーマ、および更新レベルを適切に移行するのに必要なデータ変更を配置するだけです。こうしたケースでは、アプリケーションをホストするインフラストラクチャ (ISS と SQL の両方) を新しくプロビジョニングすることはありません。プロビジョニングを含まない、アプリケーション コード自体のみに傾注するリリース パイプラインを利用します。

各種コンテナーの構成設定の変更を必要とするシナリオもあります。たとえば、ISS のアプリケーション プール設定の一部の微調整が必要になることがあります。このような微調整は、リリース パイプラインの一部として実装することも、手動で処理することも可能です。コードとしてのインフラストラクチャ (IaC:Infrastructure-as-Code) 戦略では、何らかの種類のバージョン管理システムで構成設定の変更を追跡することもあります。

プロビジョニングを自動化リリース パイプラインの一部に含めるシナリオは、他にもいくつか考えられます。たとえば、開発サイクルの初期では、リリースのたびに SQL データベースを破棄してから新しく再構築し、環境に対して完全かつ自動的なテストを実行する場合です。

Azure などのクラウド コンピューティング プラットフォームでは、必要なものだけに代価を支払います。自動的にセットアップと破棄を行うことで、コスト効率が向上する可能性があります。プロビジョニングと環境の変更を自動化することで、エラーを避け、アプリケーション環境全体を管理できるようになります。このようなシナリオでは、全体的なリリース管理システムの一部にプロビジョニングを含めることが推奨されます。

リリース パイプラインの一部にプロビジョニングを含めるためのオプションやテクニックはたくさんあります。どれを利用するかは、ホストするアプリケーションの種類とホストする場所によって変わります。たとえば、従来の ASP.NET Web アプリケーションをホストする場合と、Azure Web アプリケーションや PaaS (サービスとしてのプラットフォーム) アプリケーション (Azure Cloud Services など) をホストする場合は異なります。これらのアプリケーションはコンテナーが異なり、プロビジョニング手順をサポートするのに必要なツールの使い方も違います。

IaC

よく使われるプロビジョニング テクニックの 1 つが、IaC (コードとしてのインフラストラクチャ) です。アプリケーションとは 1 つの実行可能ファイルですが、運用環境との組み合わせによっては、コンパイル済みコードにもスクリプトにもなり得ます。ここでは、IaC 環境が生み出す多くのメリットについて見ていきます。

マイクロソフトは最近 Forrester Research Inc に委託して、IaC の影響に関する調査を実施しました (bit.ly/1IiGRk1、英語)。この調査では、IaC が DevOps の重要なコンポーネントであることが示されました。さらに、ソフトウェアを提供するチームにとっては、プロビジョニングと構成は摩擦を引き起こす重要なポイントであることも示されました。DevOps の目標を完全に実現するつもりならば、自動化と IaC の手法を活用する必要があります。

以前からある運用の課題の 1 つは、アプリケーションやサービスを実行する適切な環境を自動的に提供し、このような環境を既知の良好な状態に保つことでした。仮想化などの自動化手法が有効ですが、ノード間の同期を保ち、構成の違いを管理することは依然として課題があります。運用チームと開発チームは、これからも、さまざまなツールセットや専門技術、プロセスを駆使して奮闘することになります。

IaC は、自動リリース パイプラインを通じて、インフラストラクチャ コードの作成、バージョン管理、実行、およびテストが可能になるという前提に基づきます。たとえば、IIS で構成された Windows 仮想マシン (VM) は、Windows PowerShell の簡単なスクリプトを使用して作成できます。運用では、同じ ALM ツールを使用して、インフラストラクチャのスクリプト化、バージョン管理、およびテストが可能です。

他にも、既知のバージョンの環境を起動したり破棄したりできるというメリットもあります。つまり、開発環境と運用環境の違いから生まれる厄介な問題を避けることができます。アプリケーション環境固有の依存関係をコードで表し、バージョン管理でその依存関係を切り替えることができます。端的に言えば、手作業のプロセスを取り除き、アプリケーションにとって信頼性が高い自動環境コンテナーをテストできるようになります。開発と運用に共通のスクリプト言語とツールを使用できることで、このような効率化が実現されます。

アプリケーションの種類と意図するホストの場所に応じて、インフラストラクチャ コードを実行するために必要なツールが決まります。こうした手法をサポートするツールで、よく使われているものには、Desired State Configuration (DSC)、Puppet、Chef などがあります。いずれも、今回のシナリオに基づく同様の目標実現に有効です。

IaC のコードにはさまざまなものがあります。たとえば、リソースをプロビジョニングする簡単な Windows PowerShell スクリプトになるかもしれません。いずれにせよ、アプリケーションの種類とホストする環境によって、選択するコードが決まります。

Azure の場合、Azure リソース管理 API を用いているクラウド デプロイ プロジェクトを使用して、Azure リソース グループを作成および管理できます。この場合は JSON を使用して環境を記述できるようになります。Azure リソース グループでは、Web サイトや SQL データベースなど、グループに関連するリソースを一緒に管理することもできます。クラウド デプロイ プロジェクトにより、プロビジョニングの要件をバージョン管理に保存でき、自動リリース パイプラインの一環として Azure プロビジョニングを実行できます。以下は、プロビジョニング テンプレートの基本構造を構成するセクションです。

{
  "$schema": "http://schema.management.azure.com/schemas2015-01-01/
    deploymentTemplate.json#",
  "contentVersion": "",
  "parameters" { },
  "variables": { },
  "resources": [ ],
  "outputs": { }
}

テンプレートの詳細については、https://azure.microsoft.com/ja-jp/documentation/articles/resource-group-authoring-templates/ を参照してください。クラウド デプロイ プロジェクトの詳細については、https://msdn.microsoft.com/ja-jp/library/azure/dn872471.aspx を参照してください。

IaC 戦略を正しく採用するために変更が必要なのはスクリプト言語とツールだけです。開発チームと運用チームが連携し、共通に設定した目標に向けて業務を統合する必要があります。これは簡単なことではありません。これまで運用チームは環境の安定性を確保することに重点を置き、開発チームは新しい機能を環境に導入することを重視してきたためです。高度なテクノロジが登場していますが、IaC の実装を成功に導くための土台として、運用チームと開発チームが効率的に連携できることが不可欠です。

リリース オーケストレーション

Release Management は、Visual Studio ALM スタックのテクノロジです。実際には、ソフトウェアのリリースにかかわるさまざまなオブジェクトやタスクを編成できる場所という概念の方が大きいかもしれません。Release Management の成果物には、ビルド システムによって作成されたペイロードやパッケージ、リリース パイプラインの一環として行われる自動テスト、承認ワークフロー、通知、運用直前の環境を管理するセキュリティ統制などがあります。

DSC、Windows PowerShell スクリプト、Azure リソース マネージャー、Chef などのテクノロジを使用して、環境の状態を管理し、ソフトウェアと依存関係を運用環境にインストールすることができます。Visual Studio ALM で提供されるツールの中での Release Management の立場は、配置の実行に必要なテクノロジやツールをすべて盛り込んだサービスと考えることができます。Release Management では、単純なコマンドライン スクリプトや Windows PowerShell スクリプトを利用することも、DSC を使用することも、さらには独自のカスタム ツールを実行することも可能です。リリースの実行には、できる限りシンプルなソリューションを使用することを目指します。

Windows PowerShell が至るところで使われているため、これを利用するのも得策です。たとえば、リリース パイプラインの一環として Windows PowerShell スクリプトを使用して、Azure クラウド サービスをデプロイすることができます。Release Management にはそのまま使用できるツールが多数存在しますが (図 2 参照)、ツールを自作する柔軟性もあります。

Release Management で利用可能なツールとオプション
図 2 Release Management で利用可能なツールとオプション

Release Management では、自動リリース パイプラインを簡潔に作成し、信頼性の高い自動アプリケーション リリースを生み出すことができます。また、プロビジョニングを組み込むこともできます。Visual Studio および Team Foundation Server と共に Release Management ツールを使用すると、上記の成果物を全体的なリリース トランザクションに編成することができます。また、現在と過去の状態がリッチなダッシュボードスタイルで表示されます。さらに、Release Management を Team Foundation Server および Visual Studio Online に統合することもできます。

DSC を使える場面

最近、DSC (Desired State Configuration) についての記事を見かけることが多くなりました。しかし、DSC はあらゆるものを処理できる包括的ツールではありません。DSC は、DevOps 体制で使用できるツールの 1 つではありますが、唯一のツールというわけではありません。

DSC はプル モードまたはプッシュ モードで使用できます。さらに、サーバーの状態を管理するために、「目的の状態にする (make it so)」フェーズを使用できます。状態の管理には、必ずファイルやディレクトリが存在するようにするといった単純なものもあれば、レジストリの変更、サービスの停止と開始、アプリケーションを配置するスクリプトの実行などを行う複雑なものもあります。DSC では、これをエラーを発生させずに繰り返し実行できます。独自の DSC リソースの定義や、多数の組み込みリソースの利用も可能です。

ローカル構成マネージャー (LCM) として実装される DSC は、管理オブジェクト フォーマット (MOF) 構成ファイルを受け取り、ターゲット ノード上で実行されます。そして、この MOF ファイルを使用して構成をターゲット ノードに適用します。そのため、かなり密結合のツールです。MOF の作成に、Windows PowerShell を使用する必要さえありません。

DSC の使用を開始するには、単純に MOF ファイルを作成します。ただし、最終的には実行するさまざまなリソースを記述することになり、結局はほとんど Windows PowerShell で記述することになります。Windows Server ベース システムでの DSC の大きなメリットの 1 つは、LCM が Windows Server に対してネイティブであることです。つまり、組み込みエージェントのように考えることができます。DSC には Linux で利用するシナリオもあります。DSC スクリプトの構成データを分離する例については、図 3 を参照してください。

図 3 DSC スクリプト内での構成データの分離

Configuration InstallWebSite
{
  Node $AllNodes.NodeName
  {
    WindowsFeature InstallIIS
    {
      Ensure = "Present"
      Name = "Web-Server"
    }
  }
}
InstallWebSite –ConfigurationData .\config.ps1
Where config.ps1 contains
$ConfigData = @{
  AllNodes = @(
  @{
    NodeName = “localhost”
  })
}

DSC に配置のサポートに利用できるリソースがある場合、DSC はリリース パイプラインの重要な要素になる可能性があります。オンプレミス アプリケーションや IaaS アプリケーションの場合は、環境構成の管理と、配置シナリオのサポートを支援する目的で DSC を選択するのが非常に適切です。

ただし、DSC はあらゆるシナリオで使用されることを意図していません。たとえば、Azure PaaS リソースをデプロイする場合は、Azure Resource Manager を使用して VM を起動し、ネットワークを構成する方が適しています。DSC はこのような状況に対応するようには設計されていません。VM が実行されたら、DSC を使用して目的とするローカル構成を受け取り、管理すべき構成要素が変わらないようにすることができます。

Application Insights による監視

アプリケーションと環境の運用を開始したら、データを収集して運用の正常性を監視することが重要です。また、使用状況パターンについても把握しておく必要があります。サービスの正常性を管理するにはこうしたデータが不可欠です。DevOps では、このようなデータを収集し、監視することが重要な要素になります。たとえば、マイクロソフトは運用データを利用して Visual Studio Online チームを改善しています。豊富なデータを利用して、Visual Studio Online チームはサービスの可用性を確保し、開発者のサービスの利用方法を実証し、機能の優先順位の決定を情報に基づいて下すことができます。マイクロソフトが提案する DevOps 導入の詳細については、https://www.microsoft.com/ja-jp/server-cloud/solutions/development-operations.aspx を参照してください。

Visual Studio Application Insights により、SDK が自身のアプリケーションに追加され、利用統計情報が Azure ポータルに送信されます。Application Insights は iOS、Android、ASP.NET、Java など、多種多様なプラットフォームと言語をサポートします。パフォーマンス データ、アプリケーション稼働時間など、使用状況のさまざまな分析結果を記録することができます。この豊富なデータを意思決定者や関係者に提供することで、より適切な決断、問題の発見、およびアプリケーションの継続的な改善を支援できます。Application Insights の詳細については、https://azure.microsoft.com/ja-jp/documentation/articles/app-insights-get-started/ を参照してください。

図 4 と 図 5 には Application Insights で収集されるデータの種類の一例を示しています。

ユーザーおよびページ ビューに関するデータを提供する Application Insights
図 4 ユーザーおよびページ ビューに関するデータを提供する Application Insights

Web テストも監視する Application Insights
図 5 Web テストも監視する Application Insights

まとめ

DevOps によって、チームは継続的な配信の実現に向けて進むことができ、運用中のアプリケーションのデータを活用してより適切な情報に基づいた決断が下せるようになります。今回は、下記の DevOps の目標を達成するために使用できるマイクロソフトの優れた各種テクノロジを解説しました。

  • Release Management により、任意のテクノロジを使用して、配置を主導できるようになります。このようなテクノロジには、単純な Windows PowerShell スクリプトや DSC 構成、さらには Puppet のようなサードパーティのツールも含まれます。
  • IaC 戦略は、開発チームと運用チームの効率的な連携に役立ちます。
  • Visual Studio Application Insights は、運用中のアプリケーションについて豊富なデータを記録するメカニズムを提供します。また、関係者がアプリケーションの正常性を把握できるようにし、使用状況パターンの調査を通じて情報に基づく意思決定を推進します。

このようなテクノロジにより、DevOps の成熟度は大きく向上します。チームどうしの文化の壁を乗り越えようと働きかけているときは、テクノロジを適切な組み合わせて利用する必要があります。

関連情報

  • IaC の詳細については、bit.ly/1IiNqmr (英語) で Channel 9 の Brian Keller のディスカッションを視聴してください。
  • Azure リソース グループ デプロイ プロジェクトの詳細については、https://msdn.microsoft.com/ja-jp/library/azure/dn872471.aspx を参照してください。
  • TFS の計画、障害回避と復旧、および Azure IaaS での TFS の詳細については、vsarplanningguide.codeplex.com (英語) のガイドを参照してください。
  • DevOps や ALM の実践者に向けたコードとしての構成の詳細については、vsardevops.codeplex.com (英語) を参照してください。

Micheal Learnedは Visual Studio ALM レンジャーで、現在は DevOps と Microsoft Azure に注力しています。マイクロソフト内外で多数のソフトウェア プロジェクトに 15 年以上携わってきました。現在、イリノイ州の中心部に在住し、自由な時間を使ってコミュニティをサポートしたり、娘、2 人の息子、妻と一緒にのんびり過ごしたりしています。連絡先は、Twitter (twitter.com/mlhoop、英語のみ) です。

この記事のレビューに協力してくれた技術スタッフの Donovan Brown (マイクロソフト)、Wouter de Kort (個人開発者)、Marcus Fernandez (マイクロソフト)、Richard Hundhausen (Accentient)、Willy-Peter Schaub (マイクロソフト) および Giulio Vian (個人開発者) に心より感謝いたします。