カンリーでのTerraform（IaC）活用事例紹介

※このストーリーは、noteで発信した記事を転載しています。

株式会社カンリー、エンジニア部の井上です。
前回はセキュリティに関するWebアプリケーション診断の内容を記事にしました。

今回はカンリーでのTerraform活用事例を紹介したいと思います！

さてみなさん、Infrastructure as Code（以下、IaC）してますか？
インフラをコードで管理しましょう！と言われ始めて久しいですが、カンリーでもTerraform（と一部Ansible）を利用してIaCを実践しています。
クラウドはAWS、モニタリングはDatadogを利用しておりこれらが管理対象になっています。

目次

1. IaCのメリット
2. カンリーにおけるIaC活用事例
3. 各プロダクト個別設定のリポジトリ
4. AWSモジュールのリポジトリ
5. Datadogモジュールのリポジトリ
6. 全体の構成
7. 今後の取り組み
8. applyの自動化
9. バージョンアップの自動化
10. モジュールの拡充

IaCのメリット

インフラをコードで管理するメリットは主に以下です。

• 何か問題が発生した場合でも、スピーディーに回復できる
• 既にあるインフラと同様な環境をすぐデプロイできる
• 環境が作りやすくなり、メンテナンスなどの考慮・工数が削減できる

まだまだメリットはあると思いますが、これまで手動で行っていたインフラ作業をコード化することで人為的ミスを無くしたり回復性を向上できたりと恩恵はたくさんあります。

王道ですが、IaCに関する書籍ではオライリー社の「Infrastructure as Code」が非常に参考になります。
興味ある方は、ぜひ一度手にとってみてください！
（表紙の動物が興味深いです…！）

カンリーにおけるIaC活用事例

カンリーでもTerraformでIaCを実践してますが、GitHubで3つのリポジトリを作成して運用しています。

• 各プロダクト個別設定のリポジトリ
• AWSモジュールのリポジトリ
• Datadogモジュールのリポジトリ

1つずつ説明していきます。

各プロダクト個別設定のリポジトリ

1つのリポジトリ内にモノレポとしてプロダクト毎にコードを管理しています。
以下のとおりプロダクトのディレクトリがあり、その配下は機能や環境、顧客の単位で細分化しています。（一部抜粋）

├── canly
│   └── env
│       ├── demo
│       ├── dev
│       ├── prod
│       └── stg
├── canlyhp
│   ├── common
│   │   └── env
│   │       ├── prod
│   │       └── stg
│   ├── customer01
│   │   └── env
│   │       ├── prod
│   │       └── stg
│   ├── customer02
│   │   └── env
│   │       ├── prod
│   │       └── stg
│   └── customer03
│       └── env
│           ├── prod
│           └── stg
├── canlyhp-cms
│   ├── api
│   │   └── env
│   │       ├── demo
│   │       ├── dev
│   │       ├── prod
│   │       └── stg
│   └── front
│       └── env
│           ├── demo
│           ├── dev
│           ├── prod
│           │   ├── common
│           │   ├── customer01
│           │   ├── customer02
│           │   └── customer03
│           └── stg├── canly
│   └── env
│       ├── demo
│       ├── dev
│       ├── prod
│       └── stg
├── canlyhp
│   ├── common
│   │   └── env
│   │       ├── prod
│   │       └── stg
│   ├── customer01
│   │   └── env
│   │       ├── prod
│   │       └── stg
│   ├── customer02
│   │   └── env
│   │       ├── prod
│   │       └── stg
│   └── customer03
│       └── env
│           ├── prod
│           └── stg
├── canlyhp-cms
│   ├── api
│   │   └── env
│   │       ├── demo
│   │       ├── dev
│   │       ├── prod
│   │       └── stg
│   └── front
│       └── env
│           ├── demo
│           ├── dev
│           ├── prod
│           │   ├── common
│           │   ├── customer01
│           │   ├── customer02
│           │   └── customer03
│           └── stg

AWSモジュールのリポジトリ

各プロダクトで共通して利用できるものはモジュール化して管理しています。
例えばtfstateのbackendをS3に配置する場合、S3バケットを作る必要があります。
その際、バケットだけでなく暗号化の設定やバケットポリシーなどもまとめて作成できるようにしてモジュール化しています。
この1つのモジュールを利用するだけで、手軽にtfstate用のバケットが作成できます。
他にもGitHub Actionsワークフローで利用するOIDCのIAM Roleなどがモジュール化されています。
また、作ったモジュールはGitHubのリリース機能を使って、バージョン管理してます。

リリースしたモジュール例

Datadogモジュールのリポジトリ

Datadogのモジュールも考え方は同じです。モニタリング1つ1つをモジュール化しています。例えばCPU使用率の監視やMemory使用率の監視、ヘルスチェックなどです。
これらも各プロダクトで必要に応じて利用します。

全体の構成

全体の構成イメージは下図です。
よく使う機能はモジュール化して、必要に応じて各プロダクトで利用します。
applyは各プロダクト単位で実行します。

全体の構成イメージ図

今後の取り組み

ここまでの取り組みでも十分に運用できますし、ナレッジも蓄積できました。
ただここで満足するのではなく、もう一歩踏み込んで今後は以下のような取り組みを行いたいと考えています。

applyの自動化

Canlyホームページというプロダクトでは、新しく導入が決定したお客さまに専用の環境を構築する必要があります。
基本的にはこれまで導入いただいた他のお客さまとインフラの構成は同じなので、繰り返し同じ作業が発生します。
同じ作業なので、自動化しインフラ担当者だけでなく誰でも簡単に展開できると大幅に生産性Upが期待できます。

バージョンアップの自動化

構成管理する上で必ずついて回るのが、バージョンアップ（EOL対応など）。
Terraformしかり各種Providerをバージョンアップした際には、影響のある部分を手動で修正していく必要がありこれも工数が掛かります。
Renovateを活用できれば、バージョンアップの自動化も実現できそうなのでこれも今後の取り組みの一つです。

モジュールの拡充

まだまだモジュール化できる部分が多くあり、リファクタリングできる部分が多数あります。
これは引き続き根気強くやっていくしかないですね...！

細かい点を言うとまだまだ沢山ありますが、強固なインフラ基盤を作るためにも一つずつやっていく必要がありますね！

さいごに

今回はカンリーでのTerraform活用事例を紹介しました。本記事は概要なのでより細かい方法についても追々記事にしていこうと思います。
まだまだよく出来る部分は沢山あるので、一緒にプロダクトを作っていける仲間を募集しています！
カンリーのバリューに共感できる方、ちょっと話を聞いてみたいという方、ぜひご応募ください！