hashitalks_2023_ktc_shimakawa

Terraformを抽象化し環境構築の工数を削減する取り組みについて

https://events.hashicorp.com/hashitalksjapan
で登壇した資料になります。おまけ資料あり

Transcript

1. Terraformを抽象化し環境構築の 工数を削減する取り組みについて HashiTalks: Japan 2023/09/14 Jukiya Shimakawa
2. KINTOテクノロジーズ株式会社について（グループ組織） トヨタ自動車株式会社 トヨタファイナンシャルサービス株式会社（TFS） 海外販売金融 現地事業会社 世界40以上の国と地域で サービスを展開 KINTOテクノロジーズ 株式会社 株式会社KINTO トヨタファイナンス 株式会社 販売金融・クレジット カードなど
3. KINTO ONEとは？ クルマにかかる諸費用がコミコミ！ 他に必要なのは「ガソリン代・駐車場代・高速代」など 自動車税 自動車保険 車検 メンテナンス 消耗品 故障修理・代車 車両代＋登録諸費用
4. 自己紹介 - Jukiya Shimakawa - KINTOテクノロジーズ株式会社 - Cloud Infrastructure Engineer - :x: @exitjuki - 🧖 /🎮 /🀄 /🛵 /🏕️
5. プラットフォームグループ Team Role Platform Group Cloud Infrastructure Platform Engineering SRE DBRE MSP CCoE クラウドエンジニアリング業務(ネットワーク/システムの設計、構築、運用、インフラ障害対応)を通じて安定的なインフラ環境を提供 クラウド(AWS/Google Cloud)エンジニア、IaCによるシステム構築やシステム変更などの運用業務を担いながら、システムパックのリリース やアプリケーションモニタリングなど改善業務も実施するグループの中核。 クラウドシステム運用に関わるツールの管理・開発・運用（問い合わせ対応）を提供 Managed Serviceを積極的に利用した運用・設計・構築で必要なツールを開発、運用、導入推進を行いツールにてプロダクトを支える SLA改善提案を推進することで安心安全なサービスの提供を実現 未来のプロダクト信頼性を担うエンジニア。信頼性向上のためにどんな事ができるのかをSREヒエラルキーを下から積み上げながらSREガ イドラインを作成中。プロダクトを絞って開発グループへのSREサポートも並行して実施しております。 データベース専門知識を用いて再帰性のあるプロセスや戦略決定を実現 データベースのスペシャリスト。データベースの信頼性向上のために見える化するツール提供から、セキュリティ対策やマスキング対策など の施策も順次準備中。 アプリケーション運用サポートにより間接的な開発スピードと品質向上に貢献する アプリケーションの障害・問い合わせ受付業務を行う「サービスデスク」と障害の１次オペレーションや定型作業を実施する「一次システム 保守」の２つの役割を担っていただける協力会社との連携を行う事務局的役割。 適切なポリシーで統制されたセキュアなクラウド環境の実現 クラウドセキュリティのスペシャリスト集団。クラウドセキュリティガイドラインの作成から、ガードレールの実装やAWS/GCPの教育サ ポートまでを手がける。
6. 01 02 03 04 お話しすること 📣 品質を担保したAWSインフラ環境を 30分で用意している方法をお伝えします KTCのIaCへの取り組み KTCが管理する環境について packの詳細 まとめ
7. KTCのIaCへの取り組み
8. - Terraform始めました時代 - とりあえずベタ書き - とにかく環境構築をする必要があった - プロジェクト数は数個 - 😭 何も分からない/ナレッジがない 📆 初期構築完了まで約2週間 - 共通化(モジュール化)を始めたころ - サービスごとにモジュール化 - プロジェクト数が加速度的に増加 - プロジェクト数は10個↑ - 😭 モジュールの依存関係がない 📆初期構築完了まで約1週間 - packモジュールを開発し始めたころ - 変数定義のみでシステム構築が可能に - 現在もこれで運用中 - プロジェクト数は30個↑ - 😆 効率的に運用が可能に 📆初期構築完了まで1日 Phase 3 📗今日はここのお話しです!! Phase 2 Phase 1 KTCのIaCへの取り組み 2020年5月～ 2021年前半 2021年後半
9. インフラチームで管理している環境
10. ⛅（全体規模） プロダクト数 ※開発中含む ≒80 環境数 開発、ステージング、本番など 11 インフラ基盤はAWS インフラ担当者は現在7名
11. ? 多数のプロダクト/環境を どう構築・運用そして 管理していくか
12. 🤔 IaCにおける様々な課題 🧷 書き方が人それぞれ - レビュー時間増 - 運用フェーズにおける 編集難易度が高い 🧷 コスト/セキュリティ /ガバナンスの統制が難 しい 🧷 共通設定変更の影響 範囲が図り知れない コード管理の見直しで解決することに 👉
13. packモジュール モジュールの最大活用
14. - 開発スピードを最大化 - 品質、ガバナンスをデフォルトで確保 - 属人化しないコードを 👉 テンプレートに沿って変数定義するだけで いい感じにリソース作成をしてくれるモジュールを作成 “packモジュール” packモジュール ECS モジュール EC2 モジュール Lambda モジュール テンプレート これだけ書けばOK ALB モジュール CloudFront モジュール
15. packモジュール ECS モジュール EC2 モジュール Lambda モジュール テンプレート これだけ書けばOK 抽象化 locals.tfのみ resourceすら書かせない 分解/集約 各モジュールを呼び 出す 作成 指定されたリソースを作成
16. packモジュールの 中身 関連するリソースのコントロールも全て担っている
17. それぞれの課題がどう解決されたか
18. 🧷 書き方が人それぞれ - localsの変数定義のみで完結するよ うに - 使いたいサービスのみ記載 - 各オプションもここで定義可能 - レビュー対象は基本この1ファイル 作成時間、レビュー時間ともに大幅削減
19. 🧷コスト/セキュリティ/ガバナンスの統制が難しい - モジュール側でデフォルト値を記載 - 直接オプションを指定しない場合は必ずこの設定が有効 化される - 作成側は意識せずコスト/セキュリ ティ/ガバナンスのルールを設定す ることができている 例：Auroraのログの有効/削除保護をデフォルトで定義している
20. 🧷共通設定変更の影響範囲が図り知れない - 共通設定はpackで集約しているた め、改めてterraformを実行するだけ で良い - 共通設定の変更ファイルが最小限に 済む 変更の必要なし
21. 導入による効果
22. 😎 packモジュールに導入よる効果 記載方法をシンプルに レビュー時間の削減 デフォルト値の定義 インフラ環境構築の大幅な工数削減 早ければ30分で1つの環境構築が可能💪
23. 👨‍🔬 構築とモジュールの開発を別軸で - 既存の運用をしつつ、全体システムの最適化を行っていかなければならな い状況だが、そこを別軸で考えられるので開発スピードを緩めることなく 運用ができている
24. 今後の展開
25. 🏃‍♂️ 今後の展開 - SaaS製品や他クラウドプロバイダーなどのサービスへの対応 - マルチプロバイダーを利用できるTerraformの強みを生かす - アプリケーション担当者でも構築可能に - packの仕組みを活用し検証のための環境構築などを簡単に作成できるようにする - Terraform Cloud No-Code Provisioningとも比較 - Stateの効率的かつ適切な管理、運用を目指して - StateをTerraform Cloudで管理 → Stateそのものの管理＆可視化 - Terraform CloudによるDriftの検知 → 横串で環境の整合性を保つ
26. まとめ
27. 🦴まとめ - packというterraformコードの記載を抽象化する独自のモジュールを実装 - packを利用することで環境構築、運用にかかる工数を大幅に削減した - 条件が揃えばわずか30分ほどで構築が可能
29. ディレクトリ構造
30. terraform/ modules/ prod/ product A/ product B/ locals.tf これだけ編集すればOK(templates) main.tf regions.tf terraform.tf outputs.tf dev/ aws/ pack/ env/ s3.tf ec2.tf alb.tf … ec2/ locals.tf outputs.tf main.tf … s3/ main.tf … … …
31. terraform/ modules/ prod/ product A/ product B/ locals.tf これだけ編集すればOK(templates) main.tf regions.tf terraform.tf outputs.tf dev/ aws/ pack/ env/ s3.tf ec2.tf alb.tf … ec2/ locals.tf outputs.tf main.tf … s3/ main.tf … … … 環境-プロダクトごとにstateを管理
32. テンプレート部分 - locals.tfのみを記載 - stateはここで管理 - 実態はS3 - productディレクトリはツールで 自動生成
33. テンプレートのサンプル - 作成したいサービスを記載 - 作成したくないサービスはコードか ら削除 or コメントアウト
34. ディレクトリの自動生成ツール - 環境、リージョンの設定を同時に行う
35. packモジュール部分 - locals.tfの全文がここに渡される - サービスブロックを判断して呼び出すモ ジュールを判断している - 関連リソースもここで判断して作成判断 を行っている - ECSで利用するIAMロールの作成など
36. envモジュール部分 - ベタ書きする必要のある情報を記載 - パブリックIPアドレスの一覧 - アカウントID - 各リージョンのタイムゾーン - WAFのIpset - etc - locals.tf側では`module.env.ktc_ip_list`のよ うにして呼び出すことができる
37. serviceモジュール部分 - 各サービスをモジュール化しているもの - 基本的にpackモジュールからのみ呼び出さ れる - 単体で呼び出すことも可能