すちゃらかSREが語る、日本一簡単なIaC入門 #AWS

はじめに

都内の某企業に勤めて早３ヶ月。一応肩書きはSREということもあり、この機会にIaCについてまとめてみようと思いました。（名乗るのが恥ずかしいレベルです。。。）
インフラのコード化に興味はあるけどよく分からない、フロントエンドorバックエンドの経験しかないけどインフラ方面にも興味が出てきた。そういった方々の参考になれると幸いです。

そもそもIaCとは

CloudFormationやTerraform、Ansibleに代表されるIaC (Infrastructure as Code)とは、手動のプロセスではなく、コードを使用してインフラストラクチャの管理とプロビジョニングを行うことを言います。（RedHat社より引用）
...要するに、今までドキュメント・手動で管理されていたwebインフラについて、コードで管理することによって誰でも読めば分かるようにしましょうよ、という考え方です。
2022年のGitHub使用言語の伸び率では、HCL（要するにTerraformのこと。）が第一位となり、世界的にも浸透してきていることが伺えます。
インフラを手動で管理することには以下のようなデメリットがあります。

インフラは構築されているが、手順書が更新されていないため、実態との乖離が生じてしまう。
それまでの財産で入ったソフトウェア・設定によって奇跡的にサーバーが稼働している状態であり、いつ壊れてもおかしくない。
手順書が複雑になりすぎて、ヒューマンエラーを誘発してしまう。
（人によっては）そもそも手順書通りに再現、構築ができない。手順書の更新ができない。

これらを解決するのがIaCです。IaC導入によって以下のようなメリット・デメリットがあります。

メリット

人件費を削減できる。
人為的なミスを未然に防げる。それによって品質が向上する。
モジュールを利用することによって、サービスの提供が柔軟になる。

順に説明しますと、これまで手動で管理していたインフラをコード化できれば、それに伴うソフトウェアのインストール、設定の変更を自動化することができ、工数を削減できます。
誰がやっても同じ結果になるため、私のように経験が浅い人がサーバーの設定をいじってもミス無く変更ができます。（これが本当にありがたいんだ！）
また、サービスによって異なる設定も柔軟に管理できるため、このサービスではDBも構築する。このサービスでは別の構成を採用する、といったことも容易に行うことができ、検証環境の構築が容易になる等サービスの柔軟性が向上します。

デメリット

システム構築のためにIaCのスキルが別に必要で、最初の構築には時間がかかってしまう。（私はまだ暗中模索）
IaCツールのVerによって記述が大きく変化するため、キャッチアップが大変である。
簡単な設定変更でも時間がかかる場合がある。（例えばCLIからECSコンテナに接続できるようにするだけでも、公式ドキュメントを調べて、実装方法を探して検証する必要があります。AWSのマネジメントコンソールを使えば一発。）

IaCのスキルが、インフラの知識とは別で必要になります。またTerraformはVerによって書き方が大きく異なるため、それらの変化に対応するのも一苦労です。既存システムのTerraformのVer.UPを図る作業は、すごい工数と難易度を伴うと、噂レベルで耳にしたことがあります。
またAWSのマネジメントコンソールを使用すれば、一発で解決するような設定変更にも、時間を要する場合があります。

Ansibleの特徴と歴史

Ansibleとはオープンソースで開発されている構成管理ツール（サーバーの状態、構成を管理するための補助をするツール）です(Python製)。もともとAnsible社が開発していたのを、RedHat社が買収し、その経緯もあって注目されるようになりました。
Ansibleの特徴として、Playbookというyaml形式で記載されたコードに従って、Inventoryという実行対象に対してサーバーやネットワークの設定を自動で行います。サーバーやネットワークがどのように設定（構成）されているべきかをあらかじめ定義しておき、その上で実態とその定義内容に差異がある場合、Ansibleが自動で定義した設定（構成）にしてくれるわけです。PlaybookとInventryが揃ってさえいれば動作する点も特徴の一つです。
人の代わりにAnsibleがSSH接続をしてくれる性質上、初めて接続するサーバーにはfingerprintの登録が必要になると、先輩エンジニアに口酸っぱく教えて頂きました。

Terraformの特徴と歴史

TerraformはHashiCorp社が開発している構成管理ツールです（Go言語製）。HCLという独自言語を用いて記述をします。
下記のように、コードでインフラリソースを管理することができます。

vpc.tf

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = "true"

  tags = {
    Name = "aws-terraform-vpc"
  }
}

resource "aws_subnet" "public-a" {
  vpc_id                  = aws_vpc.main.id
  availability_zone       = "ap-northeast-1a"
  cidr_block              = "10.0.0.0/24"
  map_public_ip_on_launch = true #サブネットで起動したインスタンスにパブリックIPを許可する

  tags = {
    Name = "public-a"
  }
}

公式ドキュメントを見ても、CloudFormationと比較して多くのクラウドリソースを管理できることが利点の一つです。

AnsibleとTerraformの違い

同じ構成管理ツールと呼ばれている性質上、AnsibleとTerraformは似たような用途で用いられると考えている方も多いようですが、この二つは役割が異なります。（バックエンドエンジニアの友人と話していても、質問もらうことが多いです。）
Terraformは主にクラウドリソースの管理を行い、Ansibleは作成されたサーバーのソフト面を管理します。サーバーを構築するのがTerraformで、実際に構築されたサーバーをどのような状態にするのか、Ansibleを用いて管理するというイメージです。

AnsibleとChef,Puppetの比較

同じ構成管理ツールとして、Ruby製のChef,Puppetも引き合いに出されることがあります。
以下比較表です。

よく言われているAnsibleのメリットとしては、エージェントレスで使用できること。また書式もyaml形式で、インフラエンジニアにとって他所でも使用する形式であるため、汎用性が高いと言える点も魅力です。yamlさえ覚えてしまえばプログラミング知識を必要としないのも、選ばれる要因になっているようです。反対にGUIは実装されていないのと、複雑な処理には向いていません。

TerraformとCloudFormationの比較

TerraformはAWS,Azure,GoogleCloudPlatform,どのクラウドリソースも管理できるのに対して、CloudFormationは主にAWSリソースの管理に利用されます。Terraformの登場以前よりCloudFormationが利用されていましたが、その弱みを補完するように台頭しました。（terraform plan というコマンドがあり、今書かれているコードではこういったリソースが構築されます。というのを事前に教えてくれます。）
CloudFormationはyaml形式で記述を行うのに対して、TerraformはHCLという独自言語を用いて記述を行います。（HCLの学習が必要な分、学習コストは少し高めかも？）

Terraformは簡単なチュートリアルを用意していますので、よければそちらもご参照ください。

終わりに

いかがだったでしょうか？少しでも参考になれたら幸いです。
私自身まだまだ事業貢献度が低く、勉強させてもらうばかりの毎日です。
作業理解とともにドメイン知識も深めて、すちゃらかSRE改めドヤ顔SREとして活躍していきたいですね。
ここまで読んで下さりありがとうございました。