インフラ構築・運用自動化が
求められる背景と課題
クラウドが普及した今日、規模の大きなシステムであっても短期間の構築・リリースが強く求められている。実際、クラウドを活用する企業のなかには、1日に数百〜数千回もアプリケーションを変更しデプロイするケースもある。
インフラについても同様で、短期間の構築が要請されている。そして今、それを可能にするアプローチとして、「Infrast ructure as Code」によるインフラ構築・運用の自動化が重要になりつつある。
本稿では、Infrastructure as Codeによるインフラ構築の自動化を実案件で経験した筆者が、そのときの知見をもとに、Infrastructure as Codeの課題と対処法について解説してみたい。
読者のなかには、インフラの構築・運用に関わるすべての作業をコード化するアプローチは、効率が悪く、手間がかかるだけと思う人もいるかもしれない。しかし、次のような課題を抱えている企業は少なくないだろう。
・ プロジェクトの規模が大きくなるほど、構築・運用にかかる工数（＝コスト）が増える。
・ 一度確立した運用手段を改善しようと思っても、テストなどに時間・工数を割けない。
・ 構築や運用の手順が煩雑なので、人為的ミスによる重大な障害を招く恐れがある。
これらの解決には、ヒューマン・エラーを排除する根本的な対策が必要である。たとえば、人的操作を極力排除して運用のためのコマンド操作を自動化すれば、それだけでタイプミスのような誤りを排除できる。Infrastructure as Codeはこうした対策にも有効である。
では、Infrastructure as Codeによるインフラの構築・運用では、どのような課題があるだろうか。
現実的には技術的な課題もさることながら、スキルの問題や組織の壁、Infrast ructure as Codeの実装を阻むさまざまなハードルが待ち構えている（図表1）。とくにサーバー更改のような現行システムを踏襲するプロジェクトでは、設計・構築だけでなく運用プロセスの大幅な変更も伴うので、一般にハードルは高くなる。
ただし、そうしたケースであっても課題を1つ１つ丁寧にクリアしていくことで、Infrastructure as Codeによるインフラ構築・運用の自動化を実現できる。
Infrastructure as Codeの
目的とメリット
インフラ構成自動化ツールと言うと、ChefやAnsibleを思い浮かべる人も多いだろう。あるいは、PuppetやSalt、Vagrantなどを挙げる読者もいるかもしれない（図表2）。
インフラ構成自動化ツールは、スクリプトによって構成の自動化を定義するものである。しかし、それが単なる「スクリプト」と異なるのは、インフラ構築作業のすべてをコードで記述できることに加えて、その記述が処理単位で抽象化された表現になる、という点である。たとえば、「インストール・モジュールの追加」には、「どの」モジュールを「どこに」インストールするか、というリソースの定義が含まれる。インストールのためのコマンドの記述ではない点が、根本的な違いである。
近年では構成自動化ツールを取り巻くエコシステムが整備され、ベンダー・ソリューションも充実しているので、さまざまなITインフラに対してリソースを定義するだけで、システム構成の自動化が行えるようになっている。
Infrastructure as Codeを用いる目的は、手作業が介在しない非対話処理としての自動化にとどまらず、複数のITインフラをまたぐ一連のシステムの自動連携（オーケストレーション）と、さらにその先にAIとの連携を見据えたシステム全体の自動構築がある。
Infrastructure as Codeのメリットとしては、次の4点を指摘できる（図表3）。
・ 専用のUI（とくにGUI）を通さずにインフラの変更を自動化できる
・ 一度記述したコードは共有・再利用が可能である
・ ソフトウェア開発と同じ手法でバージョン管理を行える
・ コード化された手順を第三者が検証できる
このうち、ソフトウェア開発と同じ手法を適用できる点は、小さな変更を頻繁にリリースするアジャイルな開発において、とくに大きなメリットになる。DevOpsの考え方に基づくビルド → テスト → デプロイの継続的デリバリーを、ITインフラの局面でも実現できるからである。
常に同じ結果となる「冪等性」と
「クラウド上での実装」という基本
インフラの構築・運用をコードにより管理するときの基本的な考え方は、「冪（べき）等性」を備えていることである。冪等性とは、ITインフラがどのような状態であっても、インフラ構築・運用のコードを実行したときは、常に同じシステム構成や運用になることを指す。
たとえば、新しいバージョンのOSがリリースされたとしても、以前に開発したコードを利用できるのが冪等性である。逆に言えば、どのような環境に対しても、常に自動でインフラを構築・運用できる冪等性を満たすことがInfrastructure as Codeに求められる。
もう1つの基本的な考え方は、Infrast ructure as Codeはクラウド上で実装されることである。つまり、永続的に存在し続ける実行環境ではなく、いずれ消滅するインスタンス上で実装されるということだ。それゆえに、従来とは異なる「あるべき姿」を追求する構築・運用が必要となる。
たとえばバックアップ／リストアでは、永続的ではない環境において、求めるレベルのRPO（目標復旧時点）やRTO（目標復旧時間）を常に満たす仕組みをどう作るか、という観点でインフラ構築を考えるべきである。
そのためには、構築したら変更を加えないインフラ基盤（Immutable Infrast ructure）や、組み立て容易なIT基盤（Composable Infrastructure）の考え方も非常に重要なので、これらについても十分な理解が必要である。
中途半端な自動化と
手動操作の混在が引き起こす問題
Infrastructure as Codeでインフラ構築・運用を行う際の注意点は、どこまで自動化を行うか、という見極めである。自動化による構築・運用と手動による作業が明確に切り分けられずに混在すると、さまざまな問題を引き起こす。Kief Morris氏の『Infrastructure as Code：クラウドにおけるサーバー管理の原則とプラクティス』（*1）によれば、自動化と手動が中途半端に混在する環境では、以下のような問題が起きかねないという。
・ サーバーが爆発的に増加すると、メンテナンスしきれなくなる（サーバー・スプロール）
・ サーバーの構成・設定が時間とともにバラバラになる（構成ドリフト）
・ ほかのサーバーと設定・構成が異なる（スノーフレークサーバー）
・ 簡単に壊れ、簡単に修復できない（脆いインフラストラクチャ）
・ 構成自動化ツールを使っているのに無人化できない（オートメーション恐怖症）
・ 時間の経過とともにインフラが壊れていく（システム疲労）
上記のような問題を回避してInfrast ructure as Codeを推進するには、As-is、To-beを明確にしたうえで、自動化実現のスコープをきちんと定義する必要がある。
プロジェクトで留意したこと
明らかになったこと
Infrastructure as Codeを用いたプロジェクトで、筆者がとくに留意したのは次のような点である。
●技術面
・ 新しい技術の採用によるスキル習得が必須である
・ クラウドをはじめとする自動化実装の新しい概念や考え方を理解する必要がある
・ すべてのインフラ基盤（サーバー、ストレージ、ネットワークなど）が「インターフェース」の側面をもつ
その結果、現行システムを踏襲する場合とは異なる設計・検討が必要になった。
●プロジェクト体制
・ 設計フェーズから基盤担当チームとの密な連携が必要である
・ 自動化の検討は、組織を横断した全社的な取り組みが必要である
・ プロジェクトの1チームとしてではなく、プロジェクトや全社に対して提言を行い、実行力を伴う必要がある
その結果、自動化推進ミッションを担っていることを強く意識することになった。
このプロジェクトはサーバーの更改だったので、新しいスキルの習得といった技術面の課題も大きかったが、それに加えて、サーバーの構築・運用を自動化することについての意識改革も非常に重要であった。
またユーザーに対しても、システム構築・運用の自動化の適用によってプロジェクトの進め方が大きく変わるので、それをきめ細かく説明し、了解を得ることに注意を払った（図表4）。
プロジェクトの実装は、ChefのCookbook／Recipeを用いて進めた。さらにコードの品質を担保するために、Chef Development Kitの同梱ツールであるCookstyleとFoodcriticを使って静的コード解析や構文チェックを行うと同時に、レビュアーが開発コードをレビューしたうえで開発リポジトリにコードを登録するプロセスも組み入れた（図表5）。
インフラ構築・運用の自動化で最も重要なのは、構築・運用の操作が完全な形でコード化されているという保証である。そのためにも、正常系・異常系のいずれに対しても期待どおりの動作となるようコードの品質を高めていくプロセスが不可欠となる。
そのほか、インフラ構築・運用の自動化を進めるうえで検討したのは、以下の点である。
・ 業務システムおよび論理サーバーの単位で構築対象をパターン化し、開発する自動化対象の組み合わせを策定
・ 自動化を行うCookbook、Recipeの開発項目を、設定書（パラメータ・シート）の章立ての粒度に分割（1つの小項目は1つのRecipeとテストコードに）
・ テストコードでは設計書とテスト実行ログを比較し、パラメータ・ファイルの設定項目と設定値が正しいことを確認
従来からのシステムを踏襲するプロジェクトでInfrastructure as Codeを推進するには、クリアすべき課題が数多くある。とは言え、従来の仕組みが不要であることを意味するわけではない。むしろ、現行の設計や運用を意識したうえで、Infrastructure as Codeによるインフラ構築・運用自動化のあるべき姿を作り上げていく必要がある。
たとえば、従来どおりの設計書・設定書（パラメータ・シート）の管理が求められるケースでは、自動化の仕組みと合わせて、一元管理と連携の仕組みも考えねばならない。今回のプロジェクトでは、設定書（パラメータ・シート）とChefのパラメータ・ファイルを可読化し、比較および設定を反映する仕組みも検討する必要があった。
Infrastructure as Codeは、非常に効果的である。それを実現するには、従来の構築・運用がどのように変わるかを説明し、推進のための仕組みやプロセスをすべて具現化することが大切である。
◎著者インタビュー（2021年2月）
必然的な選択肢へと成長した Infrastructure as Code｜人気記事の著者に聞く①
････････
著者｜小栗 直樹 氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・プラットフォーム
シニアITスペシャリスト
OpenStackをはじめ、IBMのクラウド基盤ソリューションの製品技術支援ならびに案件でのシステム自動化連携部分の開発・実装に従事。パブリック・クラウド基盤ではIBM Cloud、プライベート・クラウド基盤ではPureApplication System、IBM Cloud Orchestrator、近年ではIBM Cloud Private、Cloud Automation Managerなどの技術支援、デリバリーを担当。
［IS magazine No.20（2018年7月）掲載］
