IaaS構築自動化の目標
本稿では、IaaS構築自動化を実現する方法について紹介する（ここではクラウド上でインフラを構築する場合を、「IaaS構築」と呼んでいる）。
インフラ構築では、Infrastructure as Code（IaC）を実現する構成管理ツールやテストツールの利用が浸透してきた。しかし実際には、OSやミドルウェアの構築は自動化したものの、ビジネス上の理由からIaaSレベルは手動のままであったり、IaaSレベルでは自動化していても組織間の責任分界の点から、OSやミドルウェアの自動化と連携できていないケースが見受けられる。
実例として挙げるなら、Squidサーバーを追加する場合に、OSやミドルウェア設定のためのPlaybookはすぐ書けても、VMを追加する作業で特定の担当者に負荷が集中したり、時間を要することがあった。
IT業界の動向としても、大手企業ではアドホック的な自動化から各社独自の自動化戦略へ投資が進むとの調査結果がある。こうした状況をもとに、筆者はIaaS構築の自動化では、以下を目標にすべきだと考える。
・IaCをさらに進めて、構築作業のスピードアップと省力化を推進すべき
・IaaSレベルからOS／ミドルウェアまでを一貫して自動化すべき
・アプリケーションのデプロイも自動化して、CI／CDを実現すべき
そこで自動化技術とその連携方法について解説し、連携を実現した参考事例を紹介する。
IaaS構築時の自動化ツール
IaaS構築時の自動化ツールは、大きく4つに分類できる。アプリケーションのライフサイクルに当てはめると、主に「Test」～「Operate」のフェーズで使用される（図表1）。
① プロビジョニング・ツール
IaaSレベル／PaaSレベルのインフラを準備する。扱えるインフラの種類は、サーバー（VM）やストレージ、ロードバランサなどから、RDBサービスやクラウドプロバイダーのユーザー、Kubernetesのdeployment等、多岐にわたる。
OSSとしてHashicorp社のTerraform、クラウドプロバイダーのサービスとしてAWS CloudFormation、Azure Resource Managerが挙げられる。
いずれのツール／サービスでも、インフラをYAMLやJSON形式のテンプレートで定義し、それを適応する形でインフラを作成する。構築対象のインフラが大量にある場合、手作業と比較してスピードアップ・省力化が図れるうえ、コードの形でインフラを管理しているため再利用や横展開が容易になる。
なお、TerraformはAWSやAzureなどのマルチクラウド対応であり、各クラウドプロバイダーのほとんどのリソース種別に対応しているため、最近注目されている。
② 構成管理ツール
プロビジョニングされたインフラと、その上で稼働するアプリケーションを設定・管理する。
OSSとしてRed Hat社のAnsible、Chef社のChefが挙げられる。最近では、Agent不要で管理対象への影響が少ないという点からAnsible採用例が多い。Ansibleには、GUIベースで管理機能を提供するAnsible Towerもある。
サーバーOS上でパッケージ導入やハードニングなどの初期設定を行ったり、ミドルウェアを導入・設定する使い方が一般的である。
それ以外に、たとえばAnsibleのec2_volモジュールを使うと、EC2インスタンスにEBSボリュームを追加・アタッチするなどの使い方も可能であり、OS以外にもクラウドサービスやコンテナ環境、ネットワーク機器などさまざまな種類のインフラに対する設定を行える。
③ サーバー・テストツール
インフラの設定および状態を確認する。一般的には、構成管理ツールで設定した内容が正しく反映されているかを確認する。たとえばパッケージが導入されているか、サービスが自動起動設定になっているか、設定ファイルの中身が正しいか、といった内容をテストする。
それ以外にOperateフェーズで稼働状況確認に使うケースもある。たとえば、定期的にテストを実行し、所定のポートがListenされているか、監視用スクリプトを起動してミドルウェアのログ内にエラーがないかを確認し、問題があればアラートをあげる例がある。
OSSとしてServerspecが有名であるが、Chef社からServerspecを拡張したツールとしてInSpecが提供されており、Serverspecに対してセキュリティ関連のテスト機能が追加されている。
InSpecでは、AWS・Azure・GCP用のテスト機能（リソース）も用意されており、たとえばaws_iam_root_userリソースを使って、IAM rootユーザーのMFA（多段階認証）がEnableになっているか、アクセスキーが発行されていないかなどを確認できる。
④ VMイメージ作成ツール
サーバー・イメージを作成する。構築済みのVMイメージ（ゴールデンイメージ／ゴールデンマスター）からサーバーを起動して利用する。
VMイメージ取得用の臨時のサーバーを起動し、同サーバー内で構成管理ツールやテストツールを利用して所定の設定・テストを行ったうえで、VMイメージを取得する。OSSとして、Hashicorp社のPackerが挙げられる。
さらに自動化を支援するためのツールとして、以下の2つが挙げられる。
❶ 運用管理サービス
各クラウドプロバイダーから、自社クラウドのさまざまな運用タスクを自動化するサービスが提供されている。自社のさまざまなサービス、AnsibleやInSpecなどのツールと組み合わせが容易で、運用タスクごとの自動化処理を記述したテンプレートも用意されている。
たとえばAWS Systems Manager、Azure Operational Insightsが挙げられる。AWS Systems Manager-Automationでは、VMイメージ作成用のテンプレートが利用できるので、AWSではVMイメージ作成ツールとしてPackerではなく、こちらを選択するケースもある。
❷ コマンドライン・ツール
各クラウドプロバイダーから、自社クラウドのさまざまなリソースを操作するためのコマンドライン・ツールが提供されている。コマンドラインとスクリプト言語を組み合わせることで、自動化が促進される。
また強力なフィルタリング機能を備え、リソース特定の処理を簡潔に記述できる。たとえばAWS CLI、Azure CLI、IBM Cloud CLIが挙げられる。
これまで紹介してきたツール／サービスを図表2に整理する。
ツールの組み合わせで自動化を前進させる
次に、これらのツールを組み合わせた例を2つ紹介する。
組み合わせ例 （1）
プロビジョニング、構成管理、サーバー・テストの各ツール
1つ目の例では、プロビジョニング・ツールと構成管理ツール、サーバー・テストツールを組み合わせる。
Terraformでクラウド上にLinuxインスタンスを作成し、Ansibleで同インスタンスに対しhostname設定などのOS設定を行ったうえで、InSpecでインタンスの設定（インスタンスタイプやセグメント等）とOS設定が正しいかを確認している。
ポイントは設定内容と処理の流れを一元管理するために、全体管理するAnsible Playbookと各ツールで利用する共通の変数ファイルを用意している点である。
これにより、変数ファイルに構築したいサーバー分の設定値を登録してPlaybookを流すだけで、さまざまな種類のサーバーが構築可能となる（図表3）。
組み合わせ例（2）
プロビジョニングと構成管理の各ツール、運用管理サービス
2つ目の例では、プロビジョニング・ツールと構成管理ツール、運用管理サービスを組み合わせる。
AWSのAutoScaling構成のインスタンスでは、起動中のインスタンスの設定を直接変更するのではなく、スケールアウト時のベースとなるAMI（Amazon Machine Image）に設定変更を加える。
さらに、同AMIを指定する新たな起動設定（LC: Launch Configuration）を作成したうえで、これをAutoScalingGroupの起動設定として再登録することで、スケールアウト時に設定変更が反映されたインスタンスが起動される仕組みとなっている。
AWS Systems Manager（SSM）でテンポラリー・インスタンスを起動し、同インスタンスに対しAnsibleでOS設定を行う。
この際、Ansibleはローカル実行となり、PlaybookはS3上に保管したものをダウンロードして利用する。OS設定が終わると、インスタンスのAMIを取得する。
次にTerraformで新しいAMIを指定する起動設定（LC）を新規作成し、AutoScalingGroupの起動設定として登録する。
全体管理は、上位のPlaybookで実施する。ポイントは、AWS Systems ManagerをVMイメージ（AMI）作成ツールとして利用している点である。
一連の処理により、煩雑で間違えやすいAMI更新作業を自動化することが可能となる（図表4）。
このように自動化ツールを適材適所に組み合わせることで、IaaSレベルからOS／ミドルウェアまでの一貫した自動化が可能になる。
ただ実際には、個々のツール／サービスは、多様な機能を備えることが多い。たとえば、AnsibleはAWS用のモジュールを利用すれば、AWSに対するプロビジョニング・ツールとして利用できる。
しかしTerraformと比較した場合、Ansibleでは作成可能なリソースの種類や設定個所が少ない点、複数リソースの依存関係を含めた管理が行えない点などを考えると、プロビジョニング・ツールとしてはTerraformのほうが優れていると言える。
このように、それぞれのエリアを専門とするツールのほうが、機能面や拡張性で優れているので、学習コストという課題はあるものの、専門のツールを採用することが推奨される。
IaaS構築自動化の参考事例
最後に、IaaS構築自動化を実現した事例を紹介する。
AWSリソース提供サービス
この事例はアプリ開発者からメールとExcelで依頼を受けて、手作業によるAWSリソース作成業務を自動化し、提供サービスの効率化を実現した例である。
具体的には、以下のように対応した。
・Terraformを使って、各種AWSリソースを作成する。
・AnsibleとInSpecを使って、標準的なOS設定を実施する。
・複数の運用メンバーで開発／保守していくため、自動化ツールの設定ファイルはGilLabに保管する。
本事例でのTipsとしては以下がある。
・Terraformは複数のAWSリソース間の依存関係をツール側で解決できるので、本事例のように、アプリ開発者からの依頼で複数のEC2やELB、RDSをセットで提供する作業に向いている。
・自動化サーバー（Ansible／InSpecサーバー）から直接SSH／WinRM（Windows リモート管理）ができないSubnetに対しては、AWS Systems Manager経由のAnsibleローカル実行で対応する。
AWSリソースを作成する作業自体は自動化したが、メールとExcelで依頼を受け、それをツールが利用する変数ファイルに登録する部分は手作業として残っている。
今後は、この部分を既存の申請システムで自動化することを検討している（図表5）。
CI／CDパイプライン
この事例はシステムのリニューアルに伴ってCI／CDパイプラインを構築し、アプリ変更はもとより、OS／ミドルウェアのパッチ適用時等の構成変更作業を自動化することで、スピードアップと運用工数の削減を実現した例である。具体的には、以下のように対応した。
・AWSのCodeシリーズを利用して、CI／CDパイプラインとBlue／Greenデプロイメントのフレームワークを構築する。
・アプリケーション変更時に、AWS Systems Manager（SSM）、AnsibleとInSpecを使って、最新のアプリケーションを含むGolden AMIを自動生成する。
本事例でのTipsとしては以下がある。
・当初、Golden AMI（VMイメージ）作成ツールとしてPackerを検討したが、AWS CodeBuildから起動する場合、AMI取得用のテンポラリー・インスタンスとの通信がパブリック経由となり、セキュリティ面に課題のあることがわかった。またAWSの操作に慣れており、新たなツールを導入して必要スキルを増やしたくないという顧客の要望もあり、最終的にAWS Systems Managerとなった。
・Golden AMI方式の場合、これをベースとした実稼働インスタンスで個別要件の設定内容が発生する（例：ステージング環境と本番環境で設定するプロキシーサーバーが異なる）。そこで本事例では、EC2のユーザーデータで実稼働インスタンス起動時に処理を実行することで対応した。個別要件の確認と実装方法の検討が必要となる。
なおCI／CDパイプラインは、アプリ開発者の要望に合わせた継続的な改善が必要となる（図表6）。
以上ここまで、自動化技術とその連携方法、IaaS構築自動化を実現した参考事例について紹介してきた。
自動化の連携は、現時点では主流となる考え方や方法が確立されているわけではない。しかし今後は企業全体のIT自動化が期待されるので、我々はこの領域でさまざまな試行と工夫を重ねていく必要があると考える。
著者
伴 俊秀
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・イノベーション
シニアITスペシャリスト
1991年、日本IBMに入社。監視やジョブ管理を中心に、システム管理分野での技術支援やプロジェクトでの設計・構築を実施。近年はインフラ運用設計や運用プロセス改善に携わり、ITサービス管理の価値をユーザーに提供するための取り組みを行っている。
