リクルートのAWS基盤における Terraform運⽤ 実践的な取り組みと組織づくり 2022.04.21 HashiCorp Virtual Strategy Day Japan Yu SUDO

2022.04.21 SENTO Yu SUDO Cloud Architect @ リクルート インフラソリューションユニット 2 SRE部 クラウドグループ クラウドの横断基盤を管理・運⽤・改善 している組織。 AWS基盤チームSENTOのリーダー。

2022.04.21 SENTO Yu SUDO Cloud Architect @ リクルート ねこを飼っています 娘が産まれました 3

2022.04.21 SENTO 組織の紹介 SENTO基盤とSENTOチーム 4

2022.04.21 SENTO リクルートの主要事業 5

2022.04.21 SENTO ライフスタイル領域・SaaS領域の事業 6 旅⾏、飲⾷、美容、 Air Business Toolsを中⼼に 関連サービスやアプリを提供している事業領域

2022.04.21 SENTO 8〜12 Engineers リクルートのライフスタイル領域・SaaS領域のための AWS基盤 SENTO 104 AWS Accounts 7

2022.04.21 SENTO CCoE Cloud Center of Excellence SENTOチームの特性 IRE Infrastructure Reliability Engineering 8

2022.04.21 SENTO CCoE 規範的・助⾔的活動 プロダクトに対する伴⾛ 新機能の検討・検証 EOSL対応 SENTOチームの特性 IRE 基盤コンポーネント ID管理, 踏み台, VPC管理, 専⽤線, WAF, NWF, メールGW, リアルタイム監査, etc 9

2022.04.21 SENTO SENTOにおけるTerraform 歴史と実践的プラクティスの紹介 10

2022.04.21 SENTO SENTOにおけるTerraformの歴史 11 2016年 2017年 2018年 2019年 初期のSENTOは⼿動構築 アカウント数が増え、すぐに⾃動化したくなった CloudFormationを利⽤してみたものの リソース名にランダムな⽂字列が付くことが コミュニケーション上のネックになりTerraformに移⾏ Terraformでの運⽤が軌道に乗ると 管理アカウントの増⼤にあわせて Terraform Enterpriseを検討・導⼊

2022.04.21 SENTO HCL • 「誰が書いてもほぼ同じ書き⽅になる」Infrastructure as Code向けの⾔語 • 10⼈を超えるチームでこの⾔語特性は⾮常に嬉しい、明⽂化された命名規則があるとなお良い • importなどtfstate管理の⼿段が豊富、AWS以外のクラウドでもスキルが活きる pulumiやCDKは︖ • ⾔語の柔軟性によって「⼈によって書き⽅が異なる」状態が⽣まれやすい • 1⼈〜数⼈では効率化できても、チームが⼤きくなるとレビューや技術継承のコストが重くなりすぎる CloudFormationは︖ • ランダムな⽂字列が付与されたリソースが作られることが⼤きなネック • 多数のアカウントを横断的に運⽤するときに、アカウント横断でリソースを同定するのが難しい • JSON/YAML の可読性・保守性の低さもあり、⼀時採⽤したがやめてTerraformに移⾏した なぜTerraformなのか 12

2022.04.21 SENTO Terraform Enterpriseの構成 13 SENTO GitHub Enterprise … ソースコード管理はGHEを利⽤中 IPホワイトリストによる管理のため Terraform Cloudは採⽤できず NATGWの固定IPを利⽤して Terraform Enterpriseと連携 インフラコスト最適化のため Spot Instanceを AutoScaling Groupで利⽤ on autoscaling spot instance

2022.04.21 SENTO Terraform Enterpriseを導⼊してTerraform v0.10からv0.12に上げた話 https://blog.recruit.co.jp/rls/2019-12-02-terraform-enterprise/ Terraform Enterprise導⼊時のエピソード 14

2022.04.21 SENTO SENTOにおけるTerraformの運⽤フロー GitOpsと⼈間によるapproveの併⽤ 15 PR review and plans check PR merge to develop branch auto apply to develop env manual apply to production env Pull Requestのレビュー時に、⾃動実⾏されるplanもチェック 望ましくない差分が⽣じていないか確認する Pull Request Templateも利⽤して、 このタイミングで影響のあるドキュメントもあわせてレビューする PRがdevelopブランチにmergeされると すべての開発環境にauto applyされていく 本番環境についてはplan内容を⾒てapproveしていく 意図せぬ障害を起こさせないためにこのTerraform Enterpriseの機能が必要だった

2022.04.21 SENTO 390 applies / year Terraform Enterpriseの効果 Before 940 plans / year 16

2022.04.21 SENTO Velocity 2.6x 1020 applies / year Terraform Enterpriseの効果 After Frequency 12.1x 11400 plans / year 17

2022.04.21 SENTO 導⼊前(稟議時)の試算 • TerraformやCI/CDのスペシャリストがTerraformのCI/CDワークフローをメンテナンスし続けるより も、Terraform Enterpriseを購⼊した⽅がTCO(総保有コスト)がやや低い • CI/CDワークフローをメンテナンスするためのエンジニアの稼働を、別の価値発揮に活⽤できる 実際の効果 • 全アカウントに反映する必要がある構成変更にかかる時間が 4分の1〜5分の1 程度に短縮され、 TCOも試算時よりさらに低いことがわかった • ソースコードレビューにおけるplanの確認が早く楽になったことで、PRの修正サイクルが短くなった • にも関わらずAWSアカウント数の増加による稼働増がほとんどなくなった • ⽉に1〜2回アップデートがあり、管理画⾯からアップデートボタンを押すだけで簡単に常に最新版の Terraform Enterpriseを利⽤し続けられる(新しいTerraformランタイムバージョンの導⼊も) Terraform Enterpriseの効果 18

2022.04.21 SENTO Terraform運⽤のための 組織づくり 19

2022.04.21 SENTO Agile/Scrum 87% SENTOチームのアジャイルプロセス 定形業務 13% 20

2022.04.21 SENTO 2週間1スプリントのScrumスタイル • インフラ組織だけど、アジャイルアプリケーション 開発のプラクティスを実践している • 新しいAWSの機能をすぐさま基盤改善に取 り込めるように、 Fail Fastができるように • 毎⽇の朝会/デイリースクラムでの各種ダッシュ ボードの確認と相談・議論 • やった⽅が良い、と思うことを各⾃が提案して、 チームとして判断していく Agile/Scrum 87% SENTOチームのアジャイルプロセス 21

2022.04.21 SENTO 輪番 • スプリントごとに輪番担当を⼊れ替える、定型 業務と運⽤改善を⾏ったり来たりする • 定型業務はプランニングせず、利⽤者からの 問合せやアラート通知を起点に対応する • プロダクトとのコミュニケーションや定型業務の 中から「不」を⾒つけ、改善や⾃動化を考える 機会に • 定型業務の⽐率は、当初40%近くあったが、 改善や⾃動化を繰り返して割合を減らした SENTOチームのアジャイルプロセス 定形業務 13% 22

2022.04.21 SENTO スプリントプランニングの⼯夫 「通常スプリント」と「割込スプリント」 • プランニングでは通常スプリントに計画したタスクとストーリーポイントを積むが、 緊急度の⾼い対応が発⽣したら割込スプリントにタスクとストーリーポイントを積む →チームの動きが硬直化しないようにタスクの優先度変更を常時許容する スプリント内での感謝を伝えるMVPコーナー • インフラ組織は動いて当然、感謝されることは少ない →価値の⾼い取り組みや助かったことにフォーカスして、感謝を伝え合う SENTOチームのアジャイルプロセス 23

2022.04.21 SENTO 5 Days to All Done Terraform AWS Provider v4.0.0 S3 Breaking Changes Released 219 Files Affected 24

2022.04.21 SENTO 社員3⼈で、パートナー9⼈のソースコードを必ずレビューしている • Terraformのソースコードを読み書きできる社員は最低でも2⼈必要 • 適切なレビューがされないままのIaCはメンバー交代で運⽤が回らなくなり悲惨な結末を迎える • ソースコードに対してOwnershipをしっかり持つこと、IaCにおいてソースコードは基盤そのもの • Pull Request Templateでチケットや関連ドキュメントまで確認し運⽤まで担保 Terraformのコードレビューはアプリケーションと異なる観点を持つ • module化が適切か、既存のstateがどうなるか、AWSの使い⽅として適切か • resource名変更はアプリの変数名変更より運⽤コストが⾼い、DBのスキーマ変更に近い • TerraformバージョンとProviderバージョンそれぞれにポリシーを持っておくとよい • 我々はTerraformバージョンは固定し年に1〜2回バージョンアップ、Providerは最新に追随 Terraformコードレビュー 25

2022.04.21 SENTO Terraform AWS Provider v4.0.0 Contribute AWS WAFv2 WebACL Managed Rule Group Version Support 26

2022.04.21 SENTO エンタープライズ企業の Terraform運⽤で考えること 27

2022.04.21 SENTO TCO(総保有コスト)を考慮しましょう︕ • CodeBuild+CodePipelineやCircleCI、SSM Automation、Jenkinsなど⾃前で CI/CDパイプラインを構築することもできたが、TCOが優れたTerraform Enterpriseを選択した • 世の中に既にあるもの・⾞輪の再発明は、⼤きい組織ではTCOが重くなりがち Fail Fast、Continuous Enhancement • クラウドでただ運⽤だけしていたら腐る、改善し続けることがスタートライン • より良い⽅法を常に探し、素早く失敗し、素早く改善する⽂化を作り込む • ⽇々選択肢を議論しあい、失敗を糧として喜び、良い打ち⼿を装着していく エンタープライズ企業のTerraform運⽤で考えること 28

2022.04.21 SENTO ソースコード/stateレベルで統制がとれるチームづくり • ソースコードの読み書きレビューができるレベルのマネージャー(リーダー)&サブリーダーを置きましょう • 短いサイクルでソースコードレビュー込みでのシステム変更ができることは競争⼒の源泉 • クラウドの新機能、Terraformの新バージョン等のキャッチアップに時間を割くこと メンバーが⼊れ替わってもチームが継続できるか︖ • ⾃動化してもドキュメントが不⾜すると継承されない、全員が誰かに交代する前提を持とう • ソースコードの変更、プロセスの改善、ドキュメント化をセットで仕組み化しよう • 年間2〜3⼈⼊れ替わっても⼤丈夫なチーム、成⻑し⾶び⽴つことができるチーム エンタープライズ企業のTerraform運⽤で考えること 29

ありがとうございました 30