Upgrade to Pro — share decks privately, control downloads, hide ads and more …

リクルートのAWS基盤におけるTerraform運用_実践的な取り組みと組織づくり / Has...

Recruit
April 22, 2022

リクルートのAWS基盤におけるTerraform運用_実践的な取り組みと組織づくり / HashiCorpVirtualStrategyDay_sudo

2022/04/21_HashiCorp Virtual Strategy Day Japan Vol.2での、須藤の講演資料になります

Recruit

April 22, 2022
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. 2022.04.21 SENTO Yu SUDO Cloud Architect @ リクルート インフラソリューションユニット 2

    SRE部 クラウドグループ クラウドの横断基盤を管理・運⽤・改善 している組織。 AWS基盤チームSENTOのリーダー。
  2. 2022.04.21 SENTO SENTOにおけるTerraformの歴史 11 2016年 2017年 2018年 2019年 初期のSENTOは⼿動構築 アカウント数が増え、すぐに⾃動化したくなった

    CloudFormationを利⽤してみたものの リソース名にランダムな⽂字列が付くことが コミュニケーション上のネックになりTerraformに移⾏ Terraformでの運⽤が軌道に乗ると 管理アカウントの増⼤にあわせて Terraform Enterpriseを検討・導⼊
  3. 2022.04.21 SENTO HCL • 「誰が書いてもほぼ同じ書き⽅になる」Infrastructure as Code向けの⾔語 • 10⼈を超えるチームでこの⾔語特性は⾮常に嬉しい、明⽂化された命名規則があるとなお良い •

    importなどtfstate管理の⼿段が豊富、AWS以外のクラウドでもスキルが活きる pulumiやCDKは︖ • ⾔語の柔軟性によって「⼈によって書き⽅が異なる」状態が⽣まれやすい • 1⼈〜数⼈では効率化できても、チームが⼤きくなるとレビューや技術継承のコストが重くなりすぎる CloudFormationは︖ • ランダムな⽂字列が付与されたリソースが作られることが⼤きなネック • 多数のアカウントを横断的に運⽤するときに、アカウント横断でリソースを同定するのが難しい • JSON/YAML の可読性・保守性の低さもあり、⼀時採⽤したがやめてTerraformに移⾏した なぜTerraformなのか 12
  4. 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
  5. 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の機能が必要だった
  6. 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
  7. 2022.04.21 SENTO 2週間1スプリントのScrumスタイル • インフラ組織だけど、アジャイルアプリケーション 開発のプラクティスを実践している • 新しいAWSの機能をすぐさま基盤改善に取 り込めるように、 Fail

    Fastができるように • 毎⽇の朝会/デイリースクラムでの各種ダッシュ ボードの確認と相談・議論 • やった⽅が良い、と思うことを各⾃が提案して、 チームとして判断していく Agile/Scrum 87% SENTOチームのアジャイルプロセス 21
  8. 2022.04.21 SENTO 輪番 • スプリントごとに輪番担当を⼊れ替える、定型 業務と運⽤改善を⾏ったり来たりする • 定型業務はプランニングせず、利⽤者からの 問合せやアラート通知を起点に対応する •

    プロダクトとのコミュニケーションや定型業務の 中から「不」を⾒つけ、改善や⾃動化を考える 機会に • 定型業務の⽐率は、当初40%近くあったが、 改善や⾃動化を繰り返して割合を減らした SENTOチームのアジャイルプロセス 定形業務 13% 22
  9. 2022.04.21 SENTO 5 Days to All Done Terraform AWS Provider

    v4.0.0 S3 Breaking Changes Released 219 Files Affected 24
  10. 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
  11. 2022.04.21 SENTO TCO(総保有コスト)を考慮しましょう︕ • CodeBuild+CodePipelineやCircleCI、SSM Automation、Jenkinsなど⾃前で CI/CDパイプラインを構築することもできたが、TCOが優れたTerraform Enterpriseを選択した • 世の中に既にあるもの・⾞輪の再発明は、⼤きい組織ではTCOが重くなりがち

    Fail Fast、Continuous Enhancement • クラウドでただ運⽤だけしていたら腐る、改善し続けることがスタートライン • より良い⽅法を常に探し、素早く失敗し、素早く改善する⽂化を作り込む • ⽇々選択肢を議論しあい、失敗を糧として喜び、良い打ち⼿を装着していく エンタープライズ企業のTerraform運⽤で考えること 28
  12. 2022.04.21 SENTO ソースコード/stateレベルで統制がとれるチームづくり • ソースコードの読み書きレビューができるレベルのマネージャー(リーダー)&サブリーダーを置きましょう • 短いサイクルでソースコードレビュー込みでのシステム変更ができることは競争⼒の源泉 • クラウドの新機能、Terraformの新バージョン等のキャッチアップに時間を割くこと メンバーが⼊れ替わってもチームが継続できるか︖

    • ⾃動化してもドキュメントが不⾜すると継承されない、全員が誰かに交代する前提を持とう • ソースコードの変更、プロセスの改善、ドキュメント化をセットで仕組み化しよう • 年間2〜3⼈⼊れ替わっても⼤丈夫なチーム、成⻑し⾶び⽴つことができるチーム エンタープライズ企業のTerraform運⽤で考えること 29