Slide 1
Slide 1 text
コード化できていなかったヤプリを
Terraform文化に変えていった話
株式会社ヤプリ 羽渕元紀
Slide 2
Slide 2 text
● 羽渕元紀 / @modokkin
● 株式会社ヤプリ
● 2018年 インフラエンジニア第一号として入社
● インフラ周りからYoutubeまで
● Terraform歴 4年ちょっと
自己紹介
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
● アプリ開発・運用・分析をノーコードで
提供するアプリプラットフォーム
● 年間200以上のアップデート
● 導入実績600社以上
● 累計アプリ数1億DL以上
● 2013年創業、2020年上場
Yappli について
Slide 5
Slide 5 text
Yappli のサービスイメージ
Slide 6
Slide 6 text
● かっこ悪いかもしれないけど我々の開発フローの改善、
Terraform活用の取り組みをお話します
● 同じ轍を踏まないためのヒントをおすそ分け
お話すること
Slide 7
Slide 7 text
● 創業当初は全部CTO１人で開発していた
● 開発はスピード重視で新機能、機能改修
● そこにフルスタックなエンジニアが登場
● AWSにリフト＆シフト
● Rubyベースで当時の開発者と相性の良かったChefを活用
歴史的背景
Slide 8
Slide 8 text
● サーバーサイドのエンジニアがインフラを管理
● Terraformは実績はあったものの運用できていなかった
● php+nginx環境をchef(AWS OpsWorks)で構築、運用
● Vagrantによるローカル環境で開発を行い、リリース前の
動作検証は共通のステージング環境でおこなっていた
私が入社する前の状況
Slide 9
Slide 9 text
● 複数のAmazon EC2インスタンスで構成されるサービスを
開発用に1つに集約する試みをAnsibleで行っていた
● それまでPHPで開発していたが新規開発はGo言語を採用
● AWS上に開発環境のインフラを構築するPythonスクリプ
トが誕生
入社直後の状況
Slide 10
Slide 10 text
構成イメージ
Python製スクリプトでAWSインフラを作成し、Ansibleで
Amazon EC2に開発環境(ミニヤプリ)を作成
Slide 11
Slide 11 text
ここからが俺のターン
Slide 12
Slide 12 text
入社してまずやったこと
Slide 13
Slide 13 text
課題
● ステージング環境と開発環境が同じVPCに同居していた
● 開発環境を量産できるようになったとはいえ、状態がバラ
バラで品質の担保が難しかった
Slide 14
Slide 14 text
● 開発用のAWSアカウントを新設
● 目先で必要なリソースはAWS Cloud Formationを活用
○ AWS IAMの一部のIAMロールとIAMグループ
(サービスが使うロールは別)
○ TerrafomのバックエンドAmazon S3バケット
開発環境の見直し
Slide 15
Slide 15 text
● Terraformに手を付ける前に、手動でAWS VPC、
SecurityGroupなどを作成し、まずは目先の課題を解決
● 長期的には負債になるので、ここからがTerraformの出番
開発環境の作成
Slide 16
Slide 16 text
Terraform活用のはじまり
Slide 17
Slide 17 text
● AWS OpsWorksから距離を置きたかった
● 統一感のない(浸透しない)コード化を整理したかった
● 柔軟性が求められたので AWS CloudFormation もちょっ
と違う
● Terraformは参考事例も多く学習コストが低そうだった
Why Terraform?
Slide 18
Slide 18 text
Terraform活用 その１
Slide 19
Slide 19 text
方針
● まずはAmazon VPC+SecurityGroupから着手
● Moduleを使うぞ
● 汎用的に使えるイケてるテンプレート作ったろ！
Slide 20
Slide 20 text
terraform/
├── modules
│ └─── vpc
│ ├── main.tf
│ ├── output.tf
│ └── variable.tf
└── dev
└── vpc
├── backend.tf
├── main.tf
├── output.tf
├── provider.tf
└── variable.tf
ディレクトリ構成
module "vpc" {
source = "../../modules/vpc"
common = "${var.common}"
vpc = "${var.vpc}"
}
Slide 21
Slide 21 text
振り返り
● 最初から理想が高すぎた
● variable.tfであらゆる環境に対応しようとしていた
○ 本番用VPCと開発用VPCは意外との乖離
○ 同じテンプレート郡にSecurityGroupを含めた
○ 独自Moduleはまだ早かった
Slide 22
Slide 22 text
Terraform活用 その２
Slide 23
Slide 23 text
● 開発環境(ミニヤプリ)のTerraform化に着手
● Pythonスクリプトの内容を愚直に移植することにした
● 前回の反省からModuleを使うのはやめて、できるだけシ
ンプルにすることを心がけた
方針
Slide 24
Slide 24 text
terraform/
└── dev-aws
├── vpc
├── codedeploy
│ ├── backend.tf
│ ├── datasource.tf
│ ├── main.tf
│ ├── output.tf
│ ├── provider.tf
│ └── variable.tf
➚
ディレクトリ構成
➘
└── dev
├── backend.tf
├── datasource.tf
├── main.tf
├── output.tf
├── provider.tf
└── variable.tf
Slide 25
Slide 25 text
● Pythonスクリプトからの移植なので、スムーズに移行
● テンプレートはファイルをコピーしていた
振り返り
Slide 26
Slide 26 text
Terraform活用 その３
Slide 27
Slide 27 text
● 開発環境を量産する前にTerraformのディレクトリ構成、
命名規則、コピー運用を見直すことに
● Templateファイルにシンボリックリンクで参照する方式
を採用
● Workspace機能を使うことに
方針
Slide 28
Slide 28 text
terraform/
├── template
│ ├── service
│ │└── review
│ │ ├── serviceA.tf
│ │ ├── ＜一部省略＞
│ │ ├── provider.tf
│ │ └── variable.tf
│ └── workspace
│ └── base
│ ├── main.tf
│ ├── ＜一部省略＞
│ └── variable.tf
続く
ディレクトリ構成
Slide 29
Slide 29 text
続き
└── {workspace名}
├── service
│ └── review1
│ ├── serviceA.tf -> ../../../templates/service/review/serviceA.tf
│ ├── backend.tf
│ ├── ＜一部省略＞
│ ├── provider.tf -> ../../../templates/service/review/provider.tf
│ └── variable.tf
└── workspace
└── base
├── backend.tf
├── main.tf -> ../../../templates/workspace/base/main.tf
├── ＜一部省略＞
└── variable.tf
ディレクトリ構成
Slide 30
Slide 30 text
● シンボリックリンク運用にしてみたら考えることがシンプ
ルになり効率的に開発できた
● Workspace機能は使って良かった
○ Backendのtfstateディレクトリの切り替えが楽
○ terraform.workspace変数が使えるのが何気に便利
だった
振り返り
Slide 31
Slide 31 text
Terraform導入後の世界
Slide 32
Slide 32 text
● 新機能開発のインフラは原則Terraformで構築
● メンバーが増えたときにもスムーズに引き継ぐ事が出来た
● インフラの変更管理が容易になり、変更をGithubのPRで
レビューできるように
Terraform後の世界
Slide 33
Slide 33 text
開発フローがスムーズに
回り始めた
Slide 34
Slide 34 text
開発フロー
1. 新機能開発時にインフラ構成を検討
2. 既存のパターンなら既存のTerraformテンプレートを流用
3. 新しいパターンならまず手動で構築してみて、方針が固
まったら開発環境にTerraformテンプレートを追加
4. 個別QAが完了したらステージング環境、本番環境に移植
Slide 35
Slide 35 text
まだまだ課題は山積み
Slide 36
Slide 36 text
● 50環境あり作成した時期がバラバラ
○ 機能開発に支障は無いもののインフラ差分が多数発生
● 大規模なリファクタリングを行い、大半を作り直す予定
増えまくる開発環境
Slide 37
Slide 37 text
● モノレポなterraformディレクトリ配下
○ 294 directories, 1597 files
● tfstate
○ 開発環境 45~75 resource、11data source
○ 共通リソース 450 resource、87 data source
● 全体的にディレクトリ構成を見直す予定
Terraformもどんどん成長
Slide 38
Slide 38 text
terraform/
├── template
└── {workspace名} prod/stg/dev
├── service
│ └── review1~50 ←約60リソース×50環境
└── workspace
└── base ↓47ファイル
├── serviceA.tf
├── serviceB.tf
├── ＜一部省略＞
├── serviceXY.tf
├── serviceYZ.tf
└── variable.tf
ディレクトリ構成
Slide 39
Slide 39 text
● Terraform CloudやGithub Actionsで自動化を検討
○ Github ActionsはIAMロールを扱えるのが魅力的
● 人を信頼して強めの権限を利用しているので、権限の見直
しに苦労している
○ 例えばIAMロール、IAMポリシーを作るところとか
ローカルや作業用EC2で実行している
Slide 40
Slide 40 text
● Terraformを初めて使うときは小さく始める
● 当たり前だけど開発環境から手を付けるのが良い
● 可能なら早い段階からインフラをコード化しておく
● 開発スケジュールを優先するときは一旦手動で構築してあ
とからコード化するのもあり
まとめ
Slide 41
Slide 41 text
最後にひとこと
Slide 42
Slide 42 text
https://open.talentio.com/r/1/c/yappli/homes/3493
https://yappli.co.jp/recruit/