プログラマブルインフラストラクチャをテストすることは可能か？Matt Long氏はQCon Londonで答えが"イエス"であると裏付けた

QCon Londonにて、OpenCredoのQAコンサルタントであるMatt Long氏は"Testing Programmable Infrastructure with Ruby"のプレゼンテーションを行った。重要なポイントには次の内容が含まれていた。プログラマブルインフラストラクチャを単体、結合、受け入れのレベルでテストすることは可能である、ということ。インフラストラクチャの単体テストは典型的に投資対効果が低いこと。Ruby（ServerSpecと併用して）は結合、受け入れテストのためのプログラミング言語として十分な能力があり、それはテスターとシステム管理者の両者から理解されていることが多いこと。クラウドベースのインフラストラクチャをテストの一部としてプロビジョニングすることは時間と金銭的なコストを要することがあるということだ。

Long氏は、プログラマブルインフラストラクチャを"ソフトウェア開発からITインフラのマネジメントへ方法論やツールを応用すること"として定義することによってトークを始め、このトピックが一般的に、クラウドや他の'仮想'インフラストラクチャの自動化されたプロビジョニングおよび設定と、'infrastructure as code'と'configuration as code'に、いかに密接に関連しているかについて議論した。ツールはここ5年強の間に現れ、Puppet、Chef、Ansible、SaltStack、AWS CloudFormation、そしてHashiCorp Terraformといったものがある。

彼のコンサルティング経験に基づくと、Long氏はプログラマブルインフラストラクチャは多くの利益をもたらすと述べた。それは設定の成文化（そしてバージョン管理）ができること、繰り返し安定して環境を作成できることが含まれる。プログラマブルインフラストラクチャを定義することは複雑になることがあり、そして（あらゆるソフトウェア開発活動と同様に）テストは複雑性とリスクを減らすことに長けている。しかし、Long氏の経験上、プログラマブルインフラストラクチャがテストされることはまれだ。

Long氏は、彼が前年に従事した'クラウドブローカー'プロジェクトを紹介した。そこではwebベースのユーザーインターフェイスをもつ利用者が、理想的なクラウドベースの計算リソースとストレージを、必要とするクラウドプラットフォーム（AWS、GCP、Azureなど）と同時に指定し、経営陣の承認を要求することができた。承認が通ると、クラウドブローカーアプリケーションは自動的にクラウドリソースと提供されたユーザーをSSHとVPN接続によってプロビジョニングする。このシステムでユーザーが直接触るコンポーネントは容易にテスト可能だった（Selenium、Cucumber、Java、JUnitを用いて）が、プログラマブルインフラストラクチャのコンポーネントは検証が比較的困難だった。

インフラストラクチャに関して"何をテストする必要があるのか？"との質問に対し、Long氏は、その答えはテストのピラミッドの概念をよく理解することに関連付けられると述べた。例えば、単体テストはデプロイのスクリプトが期待どおりに動作しているかを表明でき、結合テストはオペレーティングシステムサービスが適切に実行されているかを検証でき、機能的な受け入れテストはシステムユーザーがSSHでインスタンスをプロビジョニングし、任意の操作を行えているかを表明できる。

単体テストはBashスクリプト、Ansibleの設定、Terraformのコードによって管理できるが、ツールが足りずに難しくなることも多く、典型的に投資対効果が低くなるとLong氏は述べた。コードが宣言型であれば、テストは単純にその宣言を返す。ソリューションの多くはTerraform validateのようにlinting機能をもち、複雑であったり高価値であったりするbashスクリプトには、Batsのようなbashの単体テスト用ツールがある。

結合テストは、Ruby/RSpecベースのインフラストラクチャテスティングフレームワークであるServerSpecで管理できる。これはSSHでインスタンスに接続し、OSのパッケージがインストールされていること、サービスが実行中であること、ポートがリスニングであることを表明することができる。Long氏は、ServerSpecのコードはシステム管理者とテスターいずれにとっても非常に読みやすいことが多く、フレームワークに関わるコミュニティが大きく役立つと述べた。Go言語ベースのインフラストラクチャテスティングフレームワークのGoss も結合テストのためのものと考えられていたが、テストするインフラストラクチャのためにバイナリのインストールが必要であり、MSのWIndowsベースの計算がサポートされていないこともあって、実行可能な選択ではなかった。

機能的な受け入れテストはCucumberによって定義とオーケストレーションができ、インストールされたアプリケーションやサービスに関してより高レベルな表明が可能だ。Long氏は、彼がRuby、ServerSpec、'Win RM'ジェム（MSのWindowsベースの計算のテスト用）を使用してCucumber Step Definitionsを実装したことについて議論した。プログラミング言語としてRubyが選択されたのは、チームのシステム管理者がすでにこの言語に精通しており、Rubyがアプリケーションインフラストラクチャーを定義するロジックで使用されていたためだった（それにより技術スタックが最小化された）。

彼のトークは、'the good, the bad and the ugly'（続・夕陽のガンマン）の形式で、一連の教訓をもって締めくくられた。良いものは以下で形成される。すなわち、テストのピラミッドの各層に特化されたテスト（関心事の分離と単体テストの迅速な実行が可能となる）。素早く表現豊かなServerSpecのテスト。ユーザーテストのために完全なプログラミング言語の能力を発揮させるRubyの使用。そして、このタイプのインフラストラクチャのテストが、このスケールのプロジェクトにとって確実に可能であるという事実だ。

Long氏は、彼が学んだことの悪い部分を述べた。受け入れテストへの過剰な信頼（これは'ice cream cone' のテストアンチパターンに変容しうる）。2つの、一方はUI、他方はインフラストラクチャへのテストの間に必要なコンテキストスイッチ。エンジニアはたいていユーザーインターフェイスのテストにフォーカスしがちであるという事実。Long氏は初め彼がコンフォートゾーンの外で仕事しているのだと感じた。学びの'ugly'な部分には次が含まれる。テストのためのインフラストラクチャが非常に遅いこと（結果的に開発者へのフィードバックが遅くなる）。プロビジョニングされるクラウドインフラストラクチャのために支払う費用がかさんでしまうことがあるということ（インフラストラクチャが数分しかプロビジョニングされないのに、時間単位で課金されてしまうことが多い）。

プログラマブルインフラストラクチャのプロビジョニングをテストすることは難しかったか？そのとおり。

それはやる価値があったか？間違いない！バグを埋め込むことなく新しい機能を追加したりリファクタリングできる能力は素晴らしい。

このトークで核となる結論は、インフラストラクチャのテストに対するあらゆる課題にかかわらず、それは間違いなく実施する価値があるということだった。機能とインフラストラクチャのプロパティが自動的に信頼性をもって表明できるという能力は、そのチームが継続して新しい機能を追加し、既存コードをリファクタリングし、クラウドインフラストラクチャの新しいバージョンを低減されたリスクで利用できる、ということを意味する。Long氏は、テストが重要であるにもかかわらず無視されることが多いため、テスターとシステム管理者/運用担当者はより親密に仕事をするべきであると述べた。インフラストラクチャのツールは存在しているが、状況に合わせて変更、統合できるようになっている。

Long氏のトークの以前のバージョンのスライド"Testing Programmable Infrastructure"はSlideShareで閲覧可能だ。