IaCをやって感じた心理的作用が開発チームにあたえる影響

by asano

Infrastructure as code（IaC）で、Immutable Infrastructureな構成にした際に、色々と恩恵を受けてよかったことがあったので、「責任」と「心理的負担」という視点で感じたことと、使ったツール群や仕組みを紹介したいと思います。

責任の所在

プロジェクトチームの役割や責務とはなんでしょうか。

私たち開発者はプロダクトの出荷時に品質に対して責任を持つ必要があると考えています。 これは自社サービスでも他社へ納品するものでも同じですね。

製品に責任を持っている人（ここではプロダクトオーナーと呼びます）は開発チームを信頼してプロダクト設計から出荷まで任せています。

品質を保証する中の必要な要素として、今回はテストという観点で責任について触れてみたいと思います。

テストでは設計や手順どおりに実現されているか、デグレーションが発生していないかを確認します。プロダクトは1度きりの納品や検証で終わることはありません。プロダクトは継続的に開発され、回帰テストが必要になります。この回帰テストを1回実施することにどれくらいコストがかかるか、どのような範囲をカバーできるかが、プロダクト開発を駆動していくうえで重要なキーとなります。

この、プロダクトを出荷するルーチンワークの中で、プロダクトオーナーに機能や変更点のレビュー説明以外の「言われなくてもやっている」という前提事項が信頼関係の目では見えづらい責任分岐点のひとつではないかと考えています。

信頼関係が良好という状況がベースにあると、やる気も自然にでてきます。

開発チームの気持ち

開発チームのメンバーは何度も同じことをやる場合には、スクリプト化や手順化をします。 そして、ミスを見過ごさない為にペアワークや実施後のチェックも行います。

ただ、いくら手順化やスクリプト化してあっても人間はミスするものです。 この「ミスをしてはいけない」という心理的負担はかなりのもので、時間がない時には通常時とは比べられないくらいに心理的な負荷やストレスがかかります。

こういう背景もあって、何度やっても同じ結果になる自動テストやImmutable Infrastructureは心配事から解放できる一因になることから、生産性をあげるという以外の理由として実現を望まれます。

同じノウハウを使い回したい

技術は日進月歩で新しくなり、導入をしていきたいのですが、同じ仕組みで横展開して複数プロジェクトで使えれば、初動からのリズムを掴みやすかったり、ワークフローを確立しやすくコストにも影響してきます。

また、SIをやっているとお客様によって背景や事情もあり、導入する環境やソリューションが異なることがあります。現在は、クラウド環境を採用するメリットが高くAWSを前提に考えることが多いのですが、時にはAPIを持っているプライベートクラウドや別クラウドベンダーの環境を提案したり、利用することもあります。

その場合には、特定ベンダーに特化しているライブラリより汎用的に使える方が、柔軟性という意味ではうれしいです。 そこで、私が使った、Immutable Infrastructureを実現する為のツールとやりかたを紹介します。

構成イメージ

オーケストレーションツール

Code実行により環境毎の構成を起動・設定します。

DryRunやPlugabbleな仕組みを持っており、現時点でマルチクラウドに対応しているTerraformがお勧めです。

Immutable Infrastructureのように環境を複製して構築するようなケースでは、採用すると時間的にも心理的にも負担が減ります。

また、環境を削除する時にも、構築し際動的に割り当てられたリソース情報をTerraform実行後に生成されるTFファイルで保持しているので、一括削除が可能です。 ロードバランサなど特定のリソースだけ削除し忘れるようなケースも防げるので、説明責任として、事後報告するケース時の後ろめたい気持ちや、お金を無駄にしてしまったことによる「これ防げたらチームにお菓子を配れたのに」というような気持ちを抱かなくてもよくなりますね。

プロビジョニングツール

Chef、Puppet、Itamaeなどがあります。

私はAnsbileというAgentレスのプロビジョニングツールを利用しています。

Code実行により環境に対してアプリケーションやOSの設定などが行えます。

手順書の実行手順ミスや、オペレーション実施者による手順に記載していない事の「暗黙の実行内容」の齟齬が発生することを防げます。

近年のクラウド時代に考慮しないといけない「気にしておいた方がいいこと」があります。Code実行前には動的に変わるリソースIDを明示的に指定できないという点を、プロビジョニングツール実行時にはカバーしておく必要があります。

AnsibleではDynamic Inventoryという機能でスクリプト実行した結果を利用し、動的生成されたリソースをプロビジョングの対象にでき、この機能を利用しました。

この機能を使えば、AWSやプライベートクラウドなどAPIが用意されている環境であれば、ほぼ汎用的に対応が可能です。

自動テストツール

次に「責任の所在」にあった回帰テストについてです。 オーケストレーションツールやプロビジョニングツールを実行した結果を保証しなければなりません。

都度、結果を目視で確認していくのはつらいものがあり、回帰テストも自動テストでカバーしたくなります。

そこでつかえるのが、Serverspecです。

ここで気をつけたいのが、参照する設定が冗長的にならないように管理することについてです。私の使い方ではAnsibleはTerraformで動的生成されたリソースに対して動的に指定しているので、同じく自動テストツールのServerspecでもAnsibleの設定ファイルの値を利用したくなります。

そういう時に利用できるのが、ServerspecをAnsibleにIntegrateしたAnsibleSpecです。 Ansibleで利用したDynamic Inventoryの仕組みをServerspecでもそのまま利用できます。動的に対象指定するスクリプトも共通化できますので、試験でも更新漏れが発生しにくく、ここでも安心を手に入れることができました。

Immutable Infrastructureを手に入れることの意義

もう一度、責任の所在に関して話を戻すと「自分たちが安心する」というのは、すなわち「納品への自信」へと繋がるわけです。

そうすればもっと他の事に気を使えるので、良いプロダクトを作れる気運が高まったと感じました。

最初に構築からデプロイまでのパイプラインを作るのは面倒ですが、一度やってしまえばたくさんの恩恵をうけれるので、まだ試したことない方はぜひ導入を検討してみてはいかがでしょうか。