GameWith Developer Blog

GameWith のエンジニア、デザイナーが技術について日々発信していきます。

インフラ苦手エンジニアが Terraform にチャレンジしました #GameWith #TechWith

ご挨拶

はじめまして。 GameWith のエンジニアの esuEichi です。 ツール開発チームというチームで普段は開発やディレクションをしたりしています。

2021年3月に入社しました。入社時にやりたい仕事やキャリア観を聞かれた際、 「何でもやりますがインフラだけは本当に勘弁してください」といって入社した経緯があります。

そんな自分が Terraform にチャレンジした話を書いていこうと思います。

経緯

PMとして参加したとあるプロジェクトでそこそこ大きなインフラを構築する必要がありました。 しかしインフラ構築に明るいメンバがおらず、苦手とはいえ前職でインフラ周りを手習い程度ではありますがかじっていたため 自分が担当することを決意しました。

その際以下理由から Terraform を導入しようと考えました

  • 開発環境や本番環境など複数環境構築することが確定していたので環境構築の手間を減らしたい
  • Terraform によって自分の知識の曖昧な部分などがいい感じにフォローアップされるのではという期待
  • インフラ構築が苦手なので少しでもコードで管理できるようにしたい
  • どうせ苦手なことやるなら新しいことにチャレンジ

Terraform とは?

Infrastracture as a code (IaaC) を実現するプロダクトで、hashicorp によって提供されています。 今回はAWSに環境構築するために使いましたが、Azure などにも対応しており マルチクラウドでの環境構築をソースコードとして管理できるメリットがあります。

例えばDBの設定をしているコードはこちらです(一部データはマスクしています)

Terraform のコード一部(一部データはマスクしています)

Terraform を導入してよかったこと

作業状況の視認性が高い

上記の画像を見てもらうとわかるのですが、DBの構築で使った設定もVSCodeなどで画面分割すれば必要な情報が網羅的に視認できます。 なんのインスタンスを作っているのか、各インスタンスに対してなんのパラメータが設定されているのかの視認性がとても高いなという印象です。 そのため、例えばレビューしてもらう際も何ができてて何が漏れているのかが見やすく、相談しやすいなと思いました。 これが IaaC 製品を使っていない場合、AWS画面から各インスタンスの画面をいちいち遷移しながら確認して、 忘れないようにメモしたり行ったり来たりしないといけないのでかなりストレスだったと思います。

差分の把握のしやすさ

そもそも IaaC 製品が解決する第一義の課題なので当然といえば当然ですが、 GitHubにて管理できるので変更差分や変更履歴が追いやすいです。 何を変更したのかどうして変更したのかいつ変更したのかがわかるのでかなり安全性が高まる気がします。

環境複製の容易さ

当初見込んでいたように、1環境作った後複数環境を作るのは環境ごとのパラメータファイルを書き換えるだけで済みました。 ただ、例えば環境ごとに構成を変えたいとなると少しそこは面倒かもとも思いました。

Terraform を導入して解決しなかったこと

Terraform は素晴らしいと思いましたが、一方でうまくいかなかった点もあります

Terraform はAWSやインフラの知識不足を補わない

Terraform はもうちょっとエラーなどで作業の抜け漏れを指摘してくれると思っていたのですがそういう事はありませんでした。 正直AWSについてはちょっとかじった程度で大きなインフラ構築をしたことはなかったので、知識不足から動かないインスタンスを作っていることが多かったです。 今回やってて一番心理的にきつかったのは ECS を構築しても ECS タスクがないと動かないということを全く知らず、 そこにたどり着けないということでした。 一番印象的だったのはそれですが、こういったミスは恥ずかしながら正直たくさんありました。 プロジェクト外のインフラに明るいメンバにかなり相談しながらなんとかやりきったというのが正直なところです。

導入してどうだったか

今回 Terraform を導入するにあたって目的としていた各項目についてどうだったかを記述します

  • 開発環境や本番環境など複数環境構築することが確定していたので環境構築の手間を減らしたい

これについては達成できたかと思います。開発環境構築したあとは .env 相当のファイル (Terraform の場合 .tfvars など) を作れば ほぼほぼ問題なかったかと思います

  • Terraform によって自分の知識の曖昧な部分などがいい感じにフォローアップされるのではという期待

これについてははっきりと全くなかったです。 (もしかしたらVSCodeにいい感じの extention 入れたらうまくいったかもしれません) 上述の通り、AWSの知識が曖昧なまま Terraform にチャレンジすると AWS の学習と Terraform の学習とでかなりの工数がかかると思っておいたほうがいいです。 これから組織として Terraform を導入しようとする場合、 自分のようなインフラ苦手な人がいきなり Terraform にチャレンジするのではなく インフラに強いエンジニアが Terraform にチャレンジするのが無難かなと思いました。 ただ、Terraform 自体は書き味が意外とよく、 AWSでどのような構成にするか、各インスタンスでどのような設定が必要かさえわかっていれば Terraform 自体の習得はそこまで難しくないかもとは思いました。

  • インフラ構築が苦手なので少しでもコードで管理できるようにしたい

これは体験としては良かったです。 例えば過去 AWS コンソール上で構築した際は何を作ったかをコンソールでインフラエンジニアと一緒に確認したり どう設定したかなどログが残っていないが故に AWS 上でも確認する画面がたくさんあった気がします。 今回ソースコードで定義されているため、ファイル分割を適切に行うことで なんのインスタンスがどういう設定で作られているのかの視認性が高かったです。

実際の Terraform の構成(一部)。インスタンスや環境ごとにファイルを分割している

加えて、GitHub 上でレビューもできるため、一緒に画面見ておく必要もなく、 レビュアーの空いている時間でコードを見ることもできると思います。 結果としてレビュアーの時間も拘束しないで済みそうに感じました。

  • どうせ苦手なことやるなら新しいことにチャレンジ

これは達成できました。学習に時間がかかってしまいプロジェクトとして想定していた期間を超えてかなりの時間やってたと思います。 加えて一点良かったなと思うのが、Terraform を採用することでインフラ構築の再利用性が高まるなと感じました。 個人的なインフラ構築の苦手なところに AWS のコンソール上で毎回同じ作業を間違えないようにやるというのが大変苦痛なのですが、 Terraform が導入されていれば次回同じようなインスタンスや構成を作るときに過去の Terraform からコピペで作れるなと思いました。 これは個人的にはかなり楽になるので、小さい構成の Terraform をいくつか用意しておけば最終的には組み合わせて作っていける気がします。

今後の期待

書いたコードから構成図が吐き出せたらいいのにとは思いました。 そういった機能や OSS など探しても見つからなかったのですが、もしすでにある場合はこっそり教えて下さい。 前職では AWS Cloud Formation (CFn) を少し触っていたのですが、CFnにはデザイナーという機能があり、 構成図からインフラを作ってくれる機能がありました。 そういった機能もあればより便利になるなとは思いました。

終わりに

正直 Terraform を導入したことで構築までの学習コストはかなり大きかったと思いますが、 GameWith では技術へのチャレンジは積極的に行っており、自分もいい経験をさせてもらったなという感じです。 また、今回 Terraform の学習だけでなく AWS についても部のメンバにかなりフォローしてもらって勉強になりました。