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
770
コード化できていなかったヤプリを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
880
Fargateでサクっとバッチ処理実行してみる/quick-batch-processing-in-Fargate.
motokihabuchi
0
65
re:Inventラスベガスはこうやって楽しむんや / lasvegas-tanoshimu2019
motokihabuchi
0
1.1k
re:Inventはこうやって楽しむんや / reinvent-wa-ko-yatte-tanoshimunnya
motokihabuchi
0
820
ヤプリの完全にモダンとは言いづらいけど、そこそこ攻めてるインフラ環境をもっと良くしたいエンジニアを募集しています。 / Yappli's infrastructure environment
motokihabuchi
0
2.2k
【AWS re:Invent報告会 by Yappli】で、結局re:Inventって何なの? / What is re: Invent?
motokihabuchi
0
1.4k
【YappliMeetup#3】Fargateでサクッと作る開発環境 / Make development environment with Fargate
motokihabuchi
0
440
【JAWS-UGさいたま】20170610_CFnでALBとWAFを連携
motokihabuchi
0
380
Other Decks in Technology
See All in Technology
ソフトウェアテスト 最初の一歩 〜テスト設計技法をワークで体験しながら学ぶ〜 #JaSSTTokyo / SoftwareTestingFirstStep
nihonbuson
PRO
4
280
正解のない未知(インボイス制度対応)をフルサイクル開発で乗り越える方法 / How to overcome the unknown invoice system with full cycle development
carta_engineering
0
160
Azure × MCP 入門
ry0y4n
8
2k
MagicPod MCPサーバー開発の裏側とAIエージェント活用の展望
magicpod
0
290
Vibe Coding Tools
ijin
1
290
Kaigi Effect 2025 #rubykaigi2025_after
sue445
0
200
大規模サーバーレスプロジェクトのリアルな零れ話
maimyyym
3
260
Software Delivery Observability CI・CD , DORA metrics も Datadog で可視化しよう / datadog-ci-cd-observability
parupappa2929
0
160
PCNW20250514(情シスはAIとどう向き合う?事例から学ぶ活用法)
suguru0719
0
100
Coding Agentに値札を付けろ
watany
3
580
encoding/json v2を予習しよう!
yuyu_hf
PRO
1
220
激動の一年を通じて見えてきた「技術でリードする」ということ
ktr_0731
8
8.3k
Featured
See All Featured
The Language of Interfaces
destraynor
158
25k
The Invisible Side of Design
smashingmag
299
50k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Thoughts on Productivity
jonyablonski
69
4.6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
19
1.2k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Build The Right Thing And Hit Your Dates
maggiecrowley
35
2.7k
Producing Creativity
orderedlist
PRO
344
40k
KATA
mclloyd
29
14k
Designing for Performance
lara
608
69k
Building Adaptive Systems
keathley
41
2.5k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
33k
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/