イオンスマートテクノロジーとTerraformの歩み、そしてPlaftorm Engineering/AEON Smart Technology with Terraform

NIKKEI Tech Talk #29 【日経×東京ガス×イオンスマートテクノロジー】IaCで加速する内製開発と組織の発展 ( https://nikkei.connpass.com/event/337801/ )　での発表資料です。

Transcript

1. イオンスマートテクノロジーと Terraformの歩み、 そしてPlatform Engineering イオンスマートテクノロジー株式会社 DevSecOps Div. SREチーム 齋藤光 2025年1⽉23⽇ NIKKEI Tech Talk #29 ⽇経×東京ガス×イオンスマートテクノロジー】IaCで加速する内製開発と組織の発展
2. 自己紹介
3. ⾃⼰紹介 齋藤光( @hikkie13 ) イオンスマートテクノロジー株式会社(AST) DevSecOps Div SREチーム所属 (2022/5⼊社） ⼊社以来、SREを組織にインストールすることに従事 直近の登壇： - PagerDuty on Tour TOKYO 2024 - HashiConf Global 2024 趣味：ヨガ(RYT200)
4. 会社紹介
5. イオングループ紹介 - 関連数字 https://www.aeon.info/company/ - "INFOGRAPHICS 数字で見るイオングループ"
6. 会社紹介
7. iAEONアプリについて 膨⼤なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを⼀つのアプリに統合しています。
8. iAEONアプリについて 膨⼤なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを⼀つのアプリに統合しています。 https://prtimes.jp/main/html/rd/p/000004399.000007505.html
9. Agenda • SREチームの⽴ち位置 • イオンスマートテクノロジーとTerraformの歴史 • Platform Engineeringを⽀えるためにTerraformと向き合う • まとめ
10. SREチームの⽴ち位置
11. SREチームにまつわるトポロジー Stream-Aligned Team Platform Team Enabling Team SREチーム https://amzn.asia/d/9e7akXD 2つの側⾯を持ち合わせる Enabling ※最近はEmbeddedアプローチも併⽤ • Stream-Aligned(SA)チームへSREのインストール • 整備したツール/基盤の伝承と伴⾛ • 定点観測会など定期的にSAチームとcommunication Platform • インフラ基盤⾃体の改善(Azure) • セルフサービスの提供（徐々に拡⼤中） • ツール/基盤の整備
12. イメージ 情報共有&連携 SREチーム プロダクトA プロダクトB プロダクトD プロダクトC Platform ツール など 課題や要望を⼀般化 Enabling Enabling Enabling Enabling
13. イオンスマートテクノロジーとTerraformの歴史
14. AST with HashiCorp Products :全体像 SREチーム 開発チーム 開発チーム
15. AST with HashiCorp Products :全体像 SREチーム 開発チーム 開発チーム
16. イオンスマートテクノロジーとTerraformの歴史 ⼤きく分けて、3つの期に分かれる 第1期: Terraform利⽤開始 第2期: HCP Terraform導⼊ & ⼤規模リファクタリング 第3期: TerraformとPlatform Engineering（ ←Now! ）
17. 第1期: Terraform利⽤開始 内容： • 構築時からTerraformでのIaC管理を試みる • Azure PipelinesでのCI/CD、state fileはStorage Accountで管理 以下の課題に直⾯： • ⼿組みでCI/CDパイプラインを組むダルさ • 「IaCはインフラチームのもの」のマインドに拍⾞がかかる • 「⼿作業からのコード反映」 の横⾏ • 各種規則がないこと等に起因する修正容易性の低いコード • State fileの管理/秘匿情報の管理
18. 第2期: HCP Terraform導⼊ & ⼤規模リファクタリング 内容： • HCP Terraformの導⼊ • CI/CD、実⾏環境、state file管理など運⽤に必要 な様々なsomethingを容易に。 • ⼤規模リファクタリングの実施 • コーディング規約の整備 • リファクタリングに⼈的リソースを割いて実施
19. 第3期: TerraformとPlatform Engineering 内容： • 開発者⾃⾝で作業できる領域を展開 • Platform Engineeringの考えに則り、 開発者⾃⾝でできることを展開することでフ ローを⾼める試み • 例：アカウント作成（SSO化による効率化含む）、APIの管理など • SREチーム内で、明確に “SRE Team” と “Platform Team”を分離 • Platform Engineeringを⽀えるためにTerraformと向き合うための環境づくり
20. Platform Engineeringを⽀えるためにTerraformと向き合う
21. Terraformと向き合う • Terraform/HCP Terraformを導⼊したら安⼼ということはなく、運⽤していると様々 な問題に直⾯する。基本的なものだが、例えば以下。 • バージョンアップ • リポジトリやworkspaceの分割単位 • Terraform管理の範囲
22. バージョンアップ • Azureのリソース管理では、AzureRM Providerを使う • 直近だと、v3→v4にメジャーバージョンが上がった(2024/8) • メジャーバージョンが上がると、設定パラメータが変更されTerraformの修正を余 儀なくされる • マイナーバージョンが上がっても、パラメータが追加されて動かなくなることがあ る（とてもつらい）
23. バージョンアップ • バージョン指定について • Terraform : 基本、常に最新 • HCP Terraformでは、コミュニティ版 Terraform の最新が反映されるわけではない • そのため、最新になったことによるトラブルは起きにくいと判断 • Azure RM Provider :基本、常に最新 • Drift検知を利⽤しておかしくなったものは拾って対処 • ⼤掛かりなものは、定期的に案件として対応 → ここにリソースがかかる認識を持つ • バージョンを完全固定をしてる場合の⽅が、いざバージョンを上げようと思った時にかなり 困る & バージョンを固定しててもいつか動かなくなる
24. リポジトリやworkspaceの分割単位 • リポジトリやworkspaceの分割は組織のフェーズによって異なる。 • リソースが多くなると、planの時間が⻑くなる • 責任範囲‧関⼼事に対して関係あるものだけを⾒せる ↓ • “ちょうど良さ”は 組織の状況、フェーズ、チームトポロジーなどによって変わるので 最適解を探り続ける • そのために定期的な振り返り、ディスカッションが必要 • DR(Decision Record)を常に残す
25. Terraform管理の範囲 • 気合いで全てをIaC化するんだ！ は⾮現実的と割り切る • Providerが対応してないこともある • 極端な例として、⼀度だけしか実⾏しないであろう内容を10時間かけてIaC化して得 られるアウトカムは低い • 試⾏錯誤やチューニングを⾏っている段階で、IaCを開発者向けに強制するのは本当 にフローが⾼い状態なのか ‧探り続けるための定期的な振り返り、ディスカッション(⼤事なことなので2回⽬) ‧DR(Decision Record)を常に残す(⼤事なことなので2回⽬)
26. まとめ
27. まとめ • イオンスマートテクノロジーでのTerraform利⽤の歴史をご紹介 • エンジニアリングに終わりはない。TerraformコードやHCP Terraformを作成‧設定したら 終わりではない。 • 常に組織とエンジニアリングのコンディションを確認して⾒直す • ⾒直しとリファクタリングを定期的に実施することを前提としておくと、 組織として良い付き合い⽅ができるのでは？
28. 以下、告知
29. 告知 https://findy.connpass.com/event/341035/ https://findy-tools.connpass.com/event/341029/ https://inhouse-dev-summit.findy-tools.io/2025
30. 募集しています！