コード化できていなかったヤプリをTerraform文化に変えていった話

20220825 HashiTalks: Japan の発表資料です。
https://events.hashicorp.com/hashitalksjapan

Transcript

1. コード化できていなかったヤプリを Terraform文化に変えていった話 株式会社ヤプリ　羽渕元紀
2. • 羽渕元紀 /　　@modokkin • 株式会社ヤプリ • 2018年 インフラエンジニア第一号として入社 • インフラ周りからYoutubeまで • Terraform歴 4年ちょっと 自己紹介
4. • アプリ開発・運用・分析をノーコードで 提供するアプリプラットフォーム • 年間200以上のアップデート • 導入実績600社以上 • 累計アプリ数1億DL以上 • 2013年創業、2020年上場 Yappli について
5. Yappli のサービスイメージ
6. • かっこ悪いかもしれないけど我々の開発フローの改善、 Terraform活用の取り組みをお話します • 同じ轍を踏まないためのヒントをおすそ分け お話すること
7. • 創業当初は全部CTO１人で開発していた • 開発はスピード重視で新機能、機能改修 • そこにフルスタックなエンジニアが登場 • AWSにリフト＆シフト • Rubyベースで当時の開発者と相性の良かったChefを活用 歴史的背景
8. • サーバーサイドのエンジニアがインフラを管理 • Terraformは実績はあったものの運用できていなかった • php+nginx環境をchef(AWS OpsWorks)で構築、運用 • Vagrantによるローカル環境で開発を行い、リリース前の 動作検証は共通のステージング環境でおこなっていた 私が入社する前の状況
9. • 複数のAmazon EC2インスタンスで構成されるサービスを 開発用に1つに集約する試みをAnsibleで行っていた • それまでPHPで開発していたが新規開発はGo言語を採用 • AWS上に開発環境のインフラを構築するPythonスクリプ トが誕生 入社直後の状況
10. 構成イメージ Python製スクリプトでAWSインフラを作成し、Ansibleで Amazon EC2に開発環境(ミニヤプリ)を作成
11. ここからが俺のターン
12. 入社してまずやったこと
13. 課題 • ステージング環境と開発環境が同じVPCに同居していた • 開発環境を量産できるようになったとはいえ、状態がバラ バラで品質の担保が難しかった
14. • 開発用のAWSアカウントを新設 • 目先で必要なリソースはAWS Cloud Formationを活用 ◦ AWS IAMの一部のIAMロールとIAMグループ (サービスが使うロールは別) ◦ TerrafomのバックエンドAmazon S3バケット 開発環境の見直し
15. • Terraformに手を付ける前に、手動でAWS VPC、 SecurityGroupなどを作成し、まずは目先の課題を解決 • 長期的には負債になるので、ここからがTerraformの出番 開発環境の作成
16. Terraform活用のはじまり
17. • AWS OpsWorksから距離を置きたかった • 統一感のない(浸透しない)コード化を整理したかった • 柔軟性が求められたので AWS CloudFormation もちょっ と違う • Terraformは参考事例も多く学習コストが低そうだった Why Terraform?
18. Terraform活用 その１
19. 方針 • まずはAmazon VPC+SecurityGroupから着手 • Moduleを使うぞ • 汎用的に使えるイケてるテンプレート作ったろ！
20. 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}"
 }

21. 振り返り • 最初から理想が高すぎた • variable.tfであらゆる環境に対応しようとしていた ◦ 本番用VPCと開発用VPCは意外との乖離 ◦ 同じテンプレート郡にSecurityGroupを含めた ◦ 独自Moduleはまだ早かった
22. Terraform活用 その２
23. • 開発環境(ミニヤプリ)のTerraform化に着手 • Pythonスクリプトの内容を愚直に移植することにした • 前回の反省からModuleを使うのはやめて、できるだけシ ンプルにすることを心がけた 方針
24. 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
25. • Pythonスクリプトからの移植なので、スムーズに移行 • テンプレートはファイルをコピーしていた 振り返り
26. Terraform活用 その３
27. • 開発環境を量産する前にTerraformのディレクトリ構成、 命名規則、コピー運用を見直すことに • Templateファイルにシンボリックリンクで参照する方式 を採用 • Workspace機能を使うことに 方針
28. terraform/ ├── template │ ├── service │ │└── review │ │ ├── serviceA.tf │ │ ├── ＜一部省略＞ │ │ ├── provider.tf │ │ └── variable.tf │ └── workspace │ └── base │ ├── main.tf │ ├── ＜一部省略＞ │ └── variable.tf 続く ディレクトリ構成
29. 続き └── {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 ディレクトリ構成
30. • シンボリックリンク運用にしてみたら考えることがシンプ ルになり効率的に開発できた • Workspace機能は使って良かった ◦ Backendのtfstateディレクトリの切り替えが楽 ◦ terraform.workspace変数が使えるのが何気に便利 だった 振り返り
31. Terraform導入後の世界
32. • 新機能開発のインフラは原則Terraformで構築 • メンバーが増えたときにもスムーズに引き継ぐ事が出来た • インフラの変更管理が容易になり、変更をGithubのPRで レビューできるように Terraform後の世界
33. 開発フローがスムーズに 回り始めた
34. 開発フロー 1. 新機能開発時にインフラ構成を検討 2. 既存のパターンなら既存のTerraformテンプレートを流用 3. 新しいパターンならまず手動で構築してみて、方針が固 まったら開発環境にTerraformテンプレートを追加 4. 個別QAが完了したらステージング環境、本番環境に移植
35. まだまだ課題は山積み
36. • 50環境あり作成した時期がバラバラ ◦ 機能開発に支障は無いもののインフラ差分が多数発生 • 大規模なリファクタリングを行い、大半を作り直す予定 増えまくる開発環境
37. • モノレポなterraformディレクトリ配下 ◦ 294 directories, 1597 files • tfstate ◦ 開発環境 45~75 resource、11data source ◦ 共通リソース 450 resource、87 data source • 全体的にディレクトリ構成を見直す予定 Terraformもどんどん成長
38. terraform/ ├── template └── {workspace名} prod/stg/dev ├── service │ └── review1~50 ←約60リソース×50環境 └── workspace └── base ↓47ファイル ├── serviceA.tf ├── serviceB.tf ├── ＜一部省略＞ ├── serviceXY.tf ├── serviceYZ.tf └── variable.tf ディレクトリ構成
39. • Terraform CloudやGithub Actionsで自動化を検討 ◦ Github ActionsはIAMロールを扱えるのが魅力的 • 人を信頼して強めの権限を利用しているので、権限の見直 しに苦労している ◦ 例えばIAMロール、IAMポリシーを作るところとか ローカルや作業用EC2で実行している
40. • Terraformを初めて使うときは小さく始める • 当たり前だけど開発環境から手を付けるのが良い • 可能なら早い段階からインフラをコード化しておく • 開発スケジュールを優先するときは一旦手動で構築してあ とからコード化するのもあり まとめ
41. 最後にひとこと
42. https://open.talentio.com/r/1/c/yappli/homes/3493 
 https://yappli.co.jp/recruit/