Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コード化できていなかったヤプリをTerraform文化に変えていった話
Search
MotokiHabuchi
August 25, 2022
Technology
2
830
コード化できていなかったヤプリをTerraform文化に変えていった話
20220825 HashiTalks: Japan の発表資料です。
https://events.hashicorp.com/hashitalksjapan
MotokiHabuchi
August 25, 2022
Tweet
Share
More Decks by MotokiHabuchi
See All by MotokiHabuchi
ヤプリにおけるAWS Control Towerの活用 / Using AWS ControlTower in Yappli
motokihabuchi
0
930
Fargateでサクっとバッチ処理実行してみる/quick-batch-processing-in-Fargate.
motokihabuchi
0
70
re:Inventラスベガスはこうやって楽しむんや / lasvegas-tanoshimu2019
motokihabuchi
0
1.1k
re:Inventはこうやって楽しむんや / reinvent-wa-ko-yatte-tanoshimunnya
motokihabuchi
0
860
ヤプリの完全にモダンとは言いづらいけど、そこそこ攻めてるインフラ環境をもっと良くしたいエンジニアを募集しています。 / Yappli's infrastructure environment
motokihabuchi
0
2.3k
【AWS re:Invent報告会 by Yappli】で、結局re:Inventって何なの? / What is re: Invent?
motokihabuchi
0
1.5k
【YappliMeetup#3】Fargateでサクッと作る開発環境 / Make development environment with Fargate
motokihabuchi
0
450
【JAWS-UGさいたま】20170610_CFnでALBとWAFを連携
motokihabuchi
0
390
Other Decks in Technology
See All in Technology
Oracle Audit Vault and Database Firewall 20 概要
oracle4engineer
PRO
3
1.7k
“社内”だけで完結していた私が、AWS Community Builder になるまで
nagisa53
1
400
Windows 11 で AWS Documentation MCP Server 接続実践/practical-aws-documentation-mcp-server-connection-on-windows-11
emiki
0
990
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
4
840
製造業からパッケージ製品まで、あらゆる領域をカバー!生成AIを利用したテストシナリオ生成 / 20250627 Suguru Ishii
shift_evolve
PRO
1
140
地図も、未来も、オープンに。 〜OSGeo.JPとFOSS4Gのご紹介〜
wata909
0
110
Observability в PHP без боли. Олег Мифле, тимлид Altenar
lamodatech
0
350
第9回情シス転職ミートアップ_テックタッチ株式会社
forester3003
0
240
"サービスチーム" での技術選定 / Making Technology Decisions for the Service Team
kaminashi
1
140
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
290
Welcome to the LLM Club
koic
0
190
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
4
540
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
A designer walks into a library…
pauljervisheath
207
24k
Docker and Python
trallard
44
3.4k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
YesSQL, Process and Tooling at Scale
rocio
173
14k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Building Applications with DynamoDB
mza
95
6.5k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
For a Future-Friendly Web
brad_frost
179
9.8k
Transcript
コード化できていなかったヤプリを Terraform文化に変えていった話 株式会社ヤプリ 羽渕元紀
• 羽渕元紀 / @modokkin • 株式会社ヤプリ • 2018年 インフラエンジニア第一号として入社 • インフラ周りからYoutubeまで
• Terraform歴 4年ちょっと 自己紹介
None
• アプリ開発・運用・分析をノーコードで 提供するアプリプラットフォーム • 年間200以上のアップデート • 導入実績600社以上 • 累計アプリ数1億DL以上 •
2013年創業、2020年上場 Yappli について
Yappli のサービスイメージ
• かっこ悪いかもしれないけど我々の開発フローの改善、 Terraform活用の取り組みをお話します • 同じ轍を踏まないためのヒントをおすそ分け お話すること
• 創業当初は全部CTO1人で開発していた • 開発はスピード重視で新機能、機能改修 • そこにフルスタックなエンジニアが登場 • AWSにリフト&シフト • Rubyベースで当時の開発者と相性の良かったChefを活用
歴史的背景
• サーバーサイドのエンジニアがインフラを管理 • Terraformは実績はあったものの運用できていなかった • php+nginx環境をchef(AWS OpsWorks)で構築、運用 • Vagrantによるローカル環境で開発を行い、リリース前の 動作検証は共通のステージング環境でおこなっていた
私が入社する前の状況
• 複数のAmazon EC2インスタンスで構成されるサービスを 開発用に1つに集約する試みをAnsibleで行っていた • それまでPHPで開発していたが新規開発はGo言語を採用 • AWS上に開発環境のインフラを構築するPythonスクリプ トが誕生 入社直後の状況
構成イメージ Python製スクリプトでAWSインフラを作成し、Ansibleで Amazon EC2に開発環境(ミニヤプリ)を作成
ここからが俺のターン
入社してまずやったこと
課題 • ステージング環境と開発環境が同じVPCに同居していた • 開発環境を量産できるようになったとはいえ、状態がバラ バラで品質の担保が難しかった
• 開発用のAWSアカウントを新設 • 目先で必要なリソースはAWS Cloud Formationを活用 ◦ AWS IAMの一部のIAMロールとIAMグループ (サービスが使うロールは別)
◦ TerrafomのバックエンドAmazon S3バケット 開発環境の見直し
• Terraformに手を付ける前に、手動でAWS VPC、 SecurityGroupなどを作成し、まずは目先の課題を解決 • 長期的には負債になるので、ここからがTerraformの出番 開発環境の作成
Terraform活用のはじまり
• AWS OpsWorksから距離を置きたかった • 統一感のない(浸透しない)コード化を整理したかった • 柔軟性が求められたので AWS CloudFormation もちょっ
と違う • Terraformは参考事例も多く学習コストが低そうだった Why Terraform?
Terraform活用 その1
方針 • まずはAmazon VPC+SecurityGroupから着手 • Moduleを使うぞ • 汎用的に使えるイケてるテンプレート作ったろ!
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}" }
振り返り • 最初から理想が高すぎた • variable.tfであらゆる環境に対応しようとしていた ◦ 本番用VPCと開発用VPCは意外との乖離 ◦ 同じテンプレート郡にSecurityGroupを含めた ◦
独自Moduleはまだ早かった
Terraform活用 その2
• 開発環境(ミニヤプリ)のTerraform化に着手 • Pythonスクリプトの内容を愚直に移植することにした • 前回の反省からModuleを使うのはやめて、できるだけシ ンプルにすることを心がけた 方針
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
• Pythonスクリプトからの移植なので、スムーズに移行 • テンプレートはファイルをコピーしていた 振り返り
Terraform活用 その3
• 開発環境を量産する前にTerraformのディレクトリ構成、 命名規則、コピー運用を見直すことに • Templateファイルにシンボリックリンクで参照する方式 を採用 • Workspace機能を使うことに 方針
terraform/ ├── template │ ├── service │ │└── review │
│ ├── serviceA.tf │ │ ├── <一部省略> │ │ ├── provider.tf │ │ └── variable.tf │ └── workspace │ └── base │ ├── main.tf │ ├── <一部省略> │ └── variable.tf 続く ディレクトリ構成
続き └── {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 ディレクトリ構成
• シンボリックリンク運用にしてみたら考えることがシンプ ルになり効率的に開発できた • Workspace機能は使って良かった ◦ Backendのtfstateディレクトリの切り替えが楽 ◦ terraform.workspace変数が使えるのが何気に便利 だった
振り返り
Terraform導入後の世界
• 新機能開発のインフラは原則Terraformで構築 • メンバーが増えたときにもスムーズに引き継ぐ事が出来た • インフラの変更管理が容易になり、変更をGithubのPRで レビューできるように Terraform後の世界
開発フローがスムーズに 回り始めた
開発フロー 1. 新機能開発時にインフラ構成を検討 2. 既存のパターンなら既存のTerraformテンプレートを流用 3. 新しいパターンならまず手動で構築してみて、方針が固 まったら開発環境にTerraformテンプレートを追加 4. 個別QAが完了したらステージング環境、本番環境に移植
まだまだ課題は山積み
• 50環境あり作成した時期がバラバラ ◦ 機能開発に支障は無いもののインフラ差分が多数発生 • 大規模なリファクタリングを行い、大半を作り直す予定 増えまくる開発環境
• モノレポなterraformディレクトリ配下 ◦ 294 directories, 1597 files • tfstate ◦
開発環境 45~75 resource、11data source ◦ 共通リソース 450 resource、87 data source • 全体的にディレクトリ構成を見直す予定 Terraformもどんどん成長
terraform/ ├── template └── {workspace名} prod/stg/dev ├── service │ └──
review1~50 ←約60リソース×50環境 └── workspace └── base ↓47ファイル ├── serviceA.tf ├── serviceB.tf ├── <一部省略> ├── serviceXY.tf ├── serviceYZ.tf └── variable.tf ディレクトリ構成
• Terraform CloudやGithub Actionsで自動化を検討 ◦ Github ActionsはIAMロールを扱えるのが魅力的 • 人を信頼して強めの権限を利用しているので、権限の見直 しに苦労している
◦ 例えばIAMロール、IAMポリシーを作るところとか ローカルや作業用EC2で実行している
• Terraformを初めて使うときは小さく始める • 当たり前だけど開発環境から手を付けるのが良い • 可能なら早い段階からインフラをコード化しておく • 開発スケジュールを優先するときは一旦手動で構築してあ とからコード化するのもあり まとめ
最後にひとこと
https://open.talentio.com/r/1/c/yappli/homes/3493 https://yappli.co.jp/recruit/