ミクシィには、探究心溢れるエンジニアがたくさん在籍しています。

その探究心は業務で扱う技術にとどまらず、趣味で書いているプログラムだったり、個人的に研究している言語だったりと、自身の気になった技術への追求も留まることを知りません。

そこで、社内のエンジニアに“好きな技術”について、思う存分に語ってもらうシリーズを始めました。

ルールはこの通り。

• 業務で使っている技術でも、使われていない技術でもOK
• あくまでも個人的な見解で
• その技術のどこが面白いのか
• 愛を込めて語り尽くしてもらう

第2回目は、みてね事業部 開発グループ SREチームの清水に「Terraform」について語ってもらいました。

注目のIaCツール「Terraform」

── 今日語っていただくのはどんな技術ですか？

例えばAWSのようなクラウドサービスの構成を、ソースコードによって管理できるオープンソースのIaCツールのひとつ「Terraform」についてお話させていただきます。

── IaCツールとは何でしょうか？

IaCとは「Infrastructure as Code」の略称で、インフラの構成をコード化し、自動化するアプローチのことを指します。諸説ありますが2009年頃から世の中に出てきた言葉・概念とされているようです。

なぜIaCが世の中に登場してきたのかというと、インフラ環境を手作業で構築していると色々とミスが発生する要因になりますし、また作業の記録や同じ作業を繰り返すためには、都度手順書を作り、手順書のメンテナンスを続けなくてはならず、非常に作業負担が大きいので、そうした課題を解消するためのツールとして誕生したわけです。

── IaCツールには「Terraform」以外にも種類があるのですか？

代表的なものには「Puppet」「Chef」「Ansible」といったツールがあります。これらはどちらかというとサーバー内のソフトウェアの設定をコードで管理できるツールなのに対し「Terraform」はAWS（Amazon Web Services）に代表されるパブリッククラウドなどのインフラの構成をコードで管理できるツールです。また「Terraform」ではインフラ構成を宣言的に定義できるようになっている「宣言モデル」を採用しています。インフラがあるべき状態をコードとして書いて「適用」するだけでそのコードの内容そのままをインフラに反映できます。

── つまり、大量のクラウドサーバーの構成が迅速にできるということですね？

そうです。すべての構成がコードで管理されるので、仮にコードで管理されている対象を手作業で変更してしまっても、コードを再度適用することで状態を簡単に戻すこともできます。また適用作業を自動化することで、さらに手間を減らすことができます。

── それは安心感がありますね！

またTerraformには「プロバイダ」という重要な概念があります。「プロバイダ」とは、AWSやGCP（Google Cloud Platform）等のクラウドサービスごとに用意されたプラグインのようなものです。AWSやGCP以外にも多くのTerraformプロバイダが開発され、自由に使うことができるんです。

── 特定のクラウドサービスだけではなく、APIが存在していて、それを外から操作できれば何でもTerraformで管理できる…ということですね？

そうですね。もしTerraformが対応していないサービスであっても、プロバイダを自分で作ることによってTerraformを使うことも可能になります。Terraform Plugin SDKというものが提供されているので、Go言語でSDKを使って開発することで世界初のプロバイダを作るなんてことも可能です。ざっと調べたところ現在1,600以上のプロバイダが開発されていました。

正確性と再現性が大きな魅力

── そもそも「Terraform」を使いはじめたきっかけは何だったんですか？

約6年前ですが新規のゲーム開発プロジェクトを担当していた時に、手作業によるインフラ構築では非効率だと感じたんです。

── それは具体的にどういうことですか？

新しいサービスを作る時って本番環境、開発環境、ステージング環境といった類似した設定の環境を複数台用意する必要があります。それを手作業で準備する際に、その作業が正しいかどうかを確認する場合には他の人に目視でレビューしてもらわないといけないんですね。そうした時に、設定をコードで管理し、なおかつそのコードをGitHub上で管理できれば、他の人からのコードレビューを簡単にできるようになるので、それを実現するために「Terraform」を使うことにしたんです。

── それはメリットが大きそうですね！

インフラの構成がソースコードとして書けて、ドキュメントを書く手間が省けるというのが、メリットとして非常に大きいですね。ドキュメントって一度書いても、AWS等のサービスは随時アップデートされて機能やUIがどんどん変わっていくので、以前書いたドキュメントを参照して同じ作業をしようとしても、ぜんぜん変わっていて手順通りにいかない！ってことがありがち。でもサービスが提供するAPIは基本的にほとんど変わらないので、一度コードとして記述しておけば変わらずに適用できるのが非常に大きなメリットです。現在のようにAWSやGCP等のクラウドプラットフォームを使うことが当たり前の時代になってくると「Chef」や「Ansible」のようにサーバーの内側を管理するだけでなく、外側も含めたインフラ全体を管理できる「Terraform」は非常に重要ですね。

── ドキュメント作成の時間が削減できるというのは、大きいですね。

時間の削減も大きいですし、同じ作業を正確に繰り返しできること。つまり再現性を担保できて、属人化からも脱却でき、作業の信頼性が上がったことが大きいですね。ただ、ドキュメントが常に悪というわけはなくドキュメントが役立つケースもあるので適材適所というところですね。

── 他にはどのようなメリットがあるのでしょうか？

いくつかありますが、1つ目には「Terraform」はGo言語で開発されたオープンソースのソフトウェアなので、WindowsでもMacでもLinuxでも実行できてインストールが楽なのが良いところですね。

2つ目には「Terraform」で管理されていない大量のクラウドのリソース、例えば既に稼働しているAmazon EC2のインスタンスが100台あったとして、それらを後から「Terraform」で管理したくなった場合に、既にある状態をインポートしてTerraformで管理できる機能がとても便利です。

3つ目には「Terraform」はHashiCorp社が開発したツールなんですけど、HCL (HashiCorp Configuration Language) という言語を用いて記述できるのもメリットです。HCL自体もどんどん進化を遂げていて、表現力が向上しているんです。例えば三項演算子やfor文のような構文も使えますし、再利用可能なモジュールを構成して使い回したりもできます。ただの設定ファイルじゃないというところが大きいですね。

難易度は高くないが、慣れは必要

── ちなみにHCLって「Terraform」独自の言語なんですよね？習得するのは難しいですか？

HCLが使われるIaCツールは「Terraform」だけだと思いますが、言語としての難易度という意味ではそれほど難しいわけではないと思います。型の種類や標準で用意されている関数の使い方で戸惑う時がありますが、公式ドキュメントを参考にしながら何度もコードを書いていけば自然に慣れていくと思います。

── なるほど。慣れの問題ですね。

あとファイル構成やディレクトリ構成で悩む人も多いですね。そのあたりのベストプラクティスを探すと色んな方法がでてくるので、どれが正解なのかは私も当初は正直わからなかったですし、実際に経験を重ねる中で改善していくしかない感じです。そういう点は難しさと言えるかもしれませんね。

── 「Terraform」の弱点やデメリットを挙げるとしたら、どうですか？

「Terraform」が全てのクラウドサービスに対応しているわけではなくて、我々のチームでも「Terraform」だけで全てを管理しているわけではありません。またクラウドサービスにおける新サービスにTerraformが対応するにもある程度時間がかかるという課題があります。例えば、つい先日開催された「AWS re:Invent 2021」で発表されたAWSの新サービスがTerraformで使えるようになるには、新しいAPIに対応したコードがプロバイダに追加されないといけないんです。ただ、AWS クラウドコントロール APIというものがそのあたりを今後解決してくれるかもしれません。またそもそもAPIが公開されていないサービスも「Terraform」では管理できないという課題もありますね。

── 「Terraform」が万能というわけではないのですね。ちなみに他のIaCツールも併用しているのですか？

いいえ。基本は「Terraform」のみですね。私が『みてね』チームにジョインする前から「Terraform」に使い慣れていたということもありますし、AWSが提供するIaCサービス「AWS CloudFormation」のコード形式であるJSONやYAMLでの記法があんまり馴染めなかった…ということもあります（笑）。

── 「Terraform」の機能の中で、特にお気に入りのものは何ですか？

Workspaceという複数環境を管理する機能ですね。インフラは基本的に開発環境、本番環境、ステージング環境の構成が同じでなくてはいけません。『みてね』ではAWSを使っているのですが、AWSのベストプラクティスに則ると、環境ごとにアカウントが独立している方が良いとされています。しかし当初の『みてね』では1つのアカウントで複数の環境がごちゃまぜになっていて、それを別々のアカウントに分ける必要があったんです。

── 別アカウントにしながら、同じ構成にする必要があったわけですね。

そうです。Workspace機能のおかげで、別アカウントへの移行がスムーズにできましたし、Workspaceを切り替えることで同じコードの適用先を簡単に変えられるのが非常に便利です。本番環境と開発環境は同じ構成である必要がありますが、アクセス数やトラフィック量には大きな違いがあるので、Workspaceを使って環境に応じてパラメータを変えてスペックのコントロールはしつつ、設定は同じにできるわけです。

── 「Terraform」を学ぶためにオススメの方法はありますか？

前提としてAWSを管理することが目的なのだとしたら、まずはAWS自体の理解を深めることが必要ですね。そしてTerraformの管理対象が何であれ、重要なのはTerraformの公式ドキュメントを読むことだと思います。公式ドキュメントには基本的に最新で正しい情報が載っています。ドキュメントは英語なので英語があまり得意ではない方には大変かもしれませんが、翻訳ツールを使ってでも読むべきですね。世の中にはブログやエンジニアコミュニティサービス等に様々な情報が紹介されていますが、時間の経過とともに情報が古くなってしまっていたり、試行錯誤中の情報が含まれていたりすることもあるので、一番のオススメはやはり公式ドキュメントですね。

── 「Terraform」のコミュニティもあるのでしょうか？

「Terraform」を作っているHashiCorp社の日本法人が最近できて、ユーザ会やMeetup、ウェビナー等を拡充してきているので、公式Twitter等から情報を仕入れるのが良いと思います。

── 清水さんの個人的にオススメな勉強法はありますか？

「Speaker Deck」というWeb上にスライドを共有できるサービスで「Terraform」に関するものを検索して、時系列で新しいものから読んでいく方法はけっこう好きですね。Terraformに限った話ではありませんが、勉強会向けのプレゼン資料はクオリティが高く、適度にまとまっているものが多いのでオススメです。あとは人が実際に書いたコードをたくさん読んで、手を動かしてみるのが実践的な学びになるので、TerraformのGitHubリポジトリのコードやプルリクエストを見て学ぶことも良いと思います。

── 最後に、今後挑戦してみたいことを教えてください。

「New Relic」や「GitHub」「Pivotal Tracker」等、まだ手作業で管理しているサービスがいくつかあるので、Terraformに対応させてコード化・自動化したいですね。そうすれば、例えば新しいメンバーが『みてね』にジョインした時の各種アカウント設定をコード管理できるようになります。本来はSSOを使えるのが一番ですが、すんなりSSOに対応できないケースもあるので。あとSREチームとしては、エンジニアがプロダクトや機能の開発、運用をする際にストレスをなるべく感じないように、プロダクトの成長を支えることにフォーカスできる環境をつくっていきたいですね。「Terraform」活用を含め、現場の作業効率を上げていけば必ず事業の成長につながりますし。エンジニアがジョインしたいと思える組織環境づくりに今後は注力していきたいと考えています。