初心者も分かるAWSとIaC

こんにちは~ スジェです。

今年もdevelopersIOが開催されました。
自分もYoutubeに「初心者も分かるAWSとIaC」というタイトルで動画をアップロードしました！
今回はその内容を整理してみます。

アジェンダ

• AWSとIaCについて
• IaCツールの特性
• ツール比較
• どんなツールを使うか？

AWSとIaC について

IaC

IaC (Infrastructure as Code) は、手動のプロセスではなく、コードを使用してインフラストラクチャの管理とプロビジョニングを行うことを言います。 - RedHat

整理すると手動で管理していたインフラのプロビジョニングや管理作業をコードで管理するということです。
AWSを例に挙げると、マネージメントコンソールでクリックして作成したリソースをあるツールのコードを利用して作成することができます。

もうちょっと詳しく見ると、複雑なクラウドインフラ管理にベストプラクティスを適用して迅速な構成や効率的な管理などができるようにすることです。¹
その目的を一言にすると自動化です。
こういった目的を持っているIaCでインフラを管理すると下記のようなメリットがあります。

• インフラ展開速度の向上
• 柔軟性の確保
• インフラの一貫性確保
• 管理の最適化
• エラー減少

一度コードを作成した後は、同じ内容のリソースを何度でも再作成することができ、必要に応じて簡単にバリューだけを修正するやり方でができます。
また、CD/CDツールと一緒に利用すれば持続的な管理も簡単になり、コードさえ理解すれば持続的なインフラ管理も可能です。
そしてリソース間依存性や設定問題も容易に把握できるため、不具合の減少という効果もあります。

つまりインフラ構築が早く、管理の効率が上がるということです。

AWSとの関係

AWSリソースを作成するためには、コンソール画面で直接作成することもできるし、AWS CLIのスクリプトを利用する方法もあります。
そして、コードでリソースを作成する方法もあります。

必要なリソースを手動にプロビジョニングや管理すると、そのリソースについてだけ知っていればいいので、ランニングカーブは低くなります。 しかし、プロビジョニングしたアプリケーションの修正、全体的なリソースの把握、セキュリティ的なチェックなどインフラ管理に対する長期的な観点では不便な点が多いです。

そのようなデメリットをコードで管理することで解決できます。
現在、使われているIaC製品はほとんどAWSに対してサポートしていますので、AWS環境でも問題なく適用できます。
でもリソース以外にも勉強が勉強する必要がありますので、全体的なラーニングカーブは増加します。

そのため、インフラをコードで管理し、IaCのメリットをそのまま活用することができます。

ツール比較

続いてIaCツールの特性について見てみましょう。
使用するツールを検討する際に、このような違いをよく把握しておいた方がいいです。

Language

ここでいうランゲージはファイルの作成言語ではなくインフラを定義する形式のことです。
IaCのツールごとに宣言型と手続き型でそのやり方が違います。
どちらも支援する場合もありますし、一つだけ支援する場合もあります。

これを簡単に説明すると 宣言型は作成するリソース、つまり最終目標だけを明示すればツールがその過程は勝手に処理する方法で
手続き型は作成するための手続きを全部明示するとツールがその通り動くことです。

宣言型はリソースだけ明示すればいいので作成や管理が簡単です。 手続き型は過程までわかる必要がありますがその分もっと確実にチェックすることができます。

Infrastructure

ツールでリソースを作成した後、コードが更新されたらそのリソースを変更できるツールと、できないのツールがあります。

変更できる場合（可変）は、プロビジョニングされたリソースに変更点があれば、改めてリソースをプロビジョニングせずに変更事項を適用できるので、迅速な対応が可能になります。
しかし、アップデートが続けると管理の難易度が上がります。

変更できない場合（不変）は、プロビジョニングされたリソースに変更点があれば、新しいリソースをプロビジョニングすることになります。
一貫性や安定性が確保されるので管理がしやすい方です。

Type

IaCツールを利用すると、インフラをプロビジョニングしたり、構成を管理したりすることができます。
各ツールは一つの機能だけ持っていることではなく、ツールによってその以上の機能を持っている場合もありますが、[どの機能に適しているのか]は確認する必要があります。

オーケストレーションもしくはプロビジョニングタイプはサーバやネットワーク、データベースなどのインフラリソースの作成に集中します。

構成管理タイプはコンピュータシステム や サーバ及びソフトウェアなどを正常に設定し管理することに集中します。

Architecture

一部のIaCツールは、命令を実行するためにインフラの状態を管理する一種のマスターサーバーを起動が必要な場合もあります。
マスターサーバーから他の管理対象のサーバーに作業を実行させたり、管理対象のサーバーがマスターサーバーから最新アップデートを取得したりします。

このようなマスターサーバーのあるツールを利用すると、中央集中式にインフラの管理ができるし、そのおかげで全体的な進行状況も一目で把握できるメリットがあります。
しかし、設定を配布のためのサーバーが必要であることやマスターサーバーのためのロギング、モニタリング、セキュリティなどを考慮しなければならないデメリットもあります。

Agent-Agentless

一部のツールは管理対象のサーバーにエージェントをインストールする必要があります。
このようなツールはマスタサーバーの場合と同じく、ロギング、モニタリング、セキュリティーなどを考慮する必要があります。

ツール比較

IaCツールが持つ特徴についてみてみましたので、AWSに関してよく使われるいくつかのツールを比較しながら、その特徴についてみてみます。
比較するツールは

• Terraform
• CloudFormation
• Ansible
• Chef
• Puppet

参考までに、該当ツールの1年間の関心度はイメージの通りです。

Terraform

公式ページ

テラフォームはインフラのプロビジョニングとオーケストレーションをするツールです。
2022年6月基準でバージョン４まで公開されています。ユーザーはHCLという言語でインフラを定義することができます。

宣言型のツールなのでインフラの最終結果化だけ定義すれば作成は自動に進められます。
コードの更新があったら新しいリソースをプロビジョニングする不変のツールです。
テラフォームはAWS, Azure, GCP, Kubernates など 1700個以上の様々なサービス²をサポートしています。
そのサービスのAPIを抽象化したプロバイダーを定義してインフラを構成することができます。

出所：terraform公式ページ

インフラの作成はコード作成・プラン・アプライの流れで進みます。
作成したコードをplanして予想結果を確認した後、問題なければapplyして実際にインフラを作成します。
作成したリソースはステータスファイル（state file）上に管理し、実際のリソースを追跡できるように構成されています。

実行するためにマスタサーバーや管理対象へのエージェント導入は不要です。
操作するローカルサーバーにクライアントだけをインストールすれば利用できます。

整理するとHCLという言語でインフラを定義し、様々なサービスに対応可能なプロビジョニングツールです。
AWSインフラをプロビジョニングするツールとしてCloudFormationやTerraformを利用する場合が多いです。

CloudFormation

公式ページ

AWSから提供しているサービスでありプロビジョニングツールです。yamlやjson形式でリソースを定義した後、AWSコンソールやCLIを利用して作成したコードをベースにリソースが作成できます。
宣言型のツールなのでインフラの最終結果だけ定義すれば作成は自動に進められます。
コードを修正するとリソースによって再作成されたりアップデートされたりします。

作成したインフラはcloudformationサービスにstackという単位で管理されます。
もしかしてAWSがあるサービスを変更してもcloudformationで作成したリソースはいつでも互換できるように高いレベルの保証を提供します。
そしてAWSのサービスに対して一番早く対応するサービスです。
ですが、AWS以外のサービスには対応していません。それで他サービスと連携が必要なら選択しにくいツールです。

整理するとYAMLやJSONでコードを作成し、AWSに限って高いレベルの保証を提供するAWSだけのプロビジョニングツールです。

Ansible

公式ページ

現在はRedhatが買収したオープンソースプロジェクトで提供されているツールであり、2022年6月基準でバージョン5まで公開されています。
構成管理を重点としており、プレイブック(playbook)というyaml形式のファイルにタスクを指定することでインフラを管理します。
手順型の特性を持つツール³なので、必要なタスクだけではなく手続きも定義する必要があります。
可変の特徴を持っており、アップデートが発生してもインフラの再プロビジョニングは行われません。

アンシブルがインストールされたコントロールノードから管理対象のノードにSSHでアクセス⁴してコントロールします。
この過程のためにエージェントは不要です。管理するノードのリストはinventoryで管理します。
実行する命令単位はmoduleと呼ばれますし、このmoduleはtaskに定義されます。
また、このタスクはplackbookに定義されます。
結果的にこのplaybookを参考してnodeを管理することになります。
AWSではAnsibleを使用するためにEC2のControlNodeからSSHでアクセスして管理したり、AWS SystemManagerを利用してプレイブックを実行することもできます。⁵

整理するとプレイブックにYAML形式でコードを作成し、中央でリソースを管理する構成管理ツールです。

Chef(progress chef)

公式ページ インフラを管理するために必要な内容をcookbookとい要素にRubyDSL(Domain-Specific Language)という言語で定義する構成管理ツールです。
構成内容をChef-serverというmaster serverを経由して、管理対象のサーバーを管理します。
この過程のために管理対象サーバーにエージェントのインストールが必要です。
手続き型ツール⁶なので、インフラと手続きの定義も必要です。
可変の特性があるのでアップデートが発生してもインフラの再プロビジョニングは行われません。

AWS オプスワークスを利用するとシェフサーバーの管理をAWSに任せることができます。

chef infra 要素間の関係(出所：公式ページ)

ChefではRecipeというものに構成要素を定義します。また、構成やポリシー展開などが定義されているいわゆる管理方法はクックブックに定義します。
このcookbookにRecipeやメタデータ、ファイルなどを定義してnodeを管理します。
こんなcookbookの作成はChef Workstationで行います。Workstationで検証が終わったらChef-serverを通じて、Cookbookを展開します。⁷
管理対処のnodeにはChef Clientというエージェントをインストールする必要があります。
インストールしたChef ClientはChef Serverからcookbookを持ってきて定義されている構成を実行します。
サーバーとエージェントはHTTPSプロトコルで通信します。

AWS Opsworksを利用するとChef Serverの管理をAWSに任せることができます。⁸

整理すると、RubyDSLで手続き型に構成を作成し、管理対象を分けて構成を管理するツールです。

Puppet

公式ページ PuppetはPuppetLanguageという言語で構成を定義する構成管理ツールです。
パペットサーバーというマスターサーバーで中央管理式に管理対象のサーバーを管理します。
情報収集や命令の実行などのためにエージェントのインストールが必要です。
宣言型のツールなので必要なインフラだけ定義すればいいです。
可変の特性があるので　アップデートが発生しても　インフラの再プロビジョニングは行われません。

Puppetのフロー（出所：公式ページ）

パペットではコードを保存、管理、実行する単にパペットプラットフォームというパッケージグループが使用されます。
このパッケージにはパペットサーバー、パペットDB、パペットエージェントなどが含まれてます。
パペットは管理対処のノードにエージェントをインストールして中央サーバーからそのノードを管理します。
それで希望する構成を定義したコードをパペットサーバーに保存するとパペットエージェントがコードを命令に変換し、作業を実行します。
パペットサーバーがエージェントのファクターでホスト名、IPアドレス、OSなどの管理するエージェントノードの情報を収集します。
収集が終わったら希望する構成を定義したカタログというゼーソンファイルを管理対象のノードが読んで構成を変更します。
その後、レポートをサーバーに送信します。

AWSOpsworkを利用すると、AWSインフラでPuppet Enterpriseを構成し、実行できます。⁹

整理するとPuppet Langageで宣言型にインフラを定義した、中央でインフラを管理する構成管理ツールです。

特徴整理

紹介しましたツールの特徴を整理すると下記の通りです。

どんなツールを使うか？

調べてみたら本日紹介されたツール以外にもたくさんのツールが公開されてます。
また、そのツールの詳細まで見るとどれもこれも似ったような機能を提供する場合が多いです。
ではこんなに多いツールの中で　何を使えばいいでしょうか。

個人的には下記の項目を考慮する必要があると思っています。
場合によって項目や優先順位は変わりますので参考としてご覧ください。

• 結果物(=目標)
• ツールの長所と短所の把握
• 要素の把握
• 費用

まず、結果物を確実にすることです。
プロビジョニングだけ必要なのか。それともアプリケーションの管理も必要なのか、セキュリティの強化も必要なのかなどを考慮してツールを選定しましょう。
すると一つのツールで十分なのか。それとも複数のツールが必要になるのかが判断できます。
また、作成しようとするリソースやインフラのサービスを　ツールが対応しているのかも確認する必要があります。

ある程度ツールの選定が終わったら、ツールの長所と短所を把握しましょう。
ほかにもセキュリティ、冗長性、ツールの支援範囲、コードの言語、コミュニティの大きさ、ラニングカーブなどなど状況にに合わせて判断が必要な要素を引き出して把握します。
エンタープライズサポートが必要な場合はその費用も考慮する必要があります。

最後の目標は自動化

最初にお話ししましたどおりIaCの最終的な目標は工程の自動化にあります。¹⁰

各作業のステージにはたくさんのツールが使われている

イメージのように各作業のステージにはたくさんのツールがあるし、これからも増えていきます。
この中で適切なツールを適用して、影響が大きい選択以外はコードの修正だけで対応できるように自動化を完成した方が効率的な場合が多いです。

そのためただインフラのプロビジョニング、構成管理だけではなくコードの作成からアプリケーションとサーバーのモニタリングまで必要な部分を徐々に自動化していくことをおすすめします。

最後に

初心者のためだと書きましたが、あちこちを少しずつ紹介してみると文が長くなりました…
本記事では「IaCはこんな感じだなぁ、ツールはこのように使われているなぁ」程度だけを紹介しました。
必要なツールがあれば詳細まで調べてみることをおすすめします。

お読みいただきありがとうございます。
誤字脱字、内容フィードバックはいつもありがとうございます。must01940 gmailでお願いします。