Terraform による運用効率化の取り組みと最新のテストアプローチの紹介

Transcript

1. Terraform による運用効率化の取り 組みと最新のテストアプローチの紹介 テクノロジー戦略室 SRE チーム 中野竜之介
2. 【目次】 1. 自己紹介、発表概要 2. これまでの運用効率化の取り組み 3. Terraform でのテストアプローチ 4. Policy as Code を用いた設定検証 5. 今後の展望 6. 参考情報
3. 1 自己紹介、発表概要
4. • 名前：中野竜之介 (33歳) • 所属：テクノロジー戦略室 SRE チーム • 出身：三重県伊勢市 • 趣味：温泉、自然散策・登山、鉄道等 • 経歴： ◦ 2017年4月 〜 2022年6月 ▪ HR ビッグデータ事業、 IT ソリューション事業の会社に新卒入社 ◦ 2022年6月 〜 2025年2月 ▪ レバレジーズに中途入社し、テク戦 SRE チームに所属して活動 プロフィール
5. 【ミッション】 SRE 化を通して、 Developer Experience の改善、事業拡大への対応、お客様に信 頼されるサービスの提供を実現する 【ゴール】 • リソース最適配置を最大限配慮したシステム設計がされており、定期的に見直しや改善を 行う体制になっている • 事業部毎にユーザー視点に立った SLO が設定され、SLO の達成のために合理的に動け る様な仕組みが整っている • ベストプラクティスが社内全体で水平展開出来ている • システム課題を持続的に改善する文化が根付いている テク戦 SRE のミッション・ゴール
6. 【理想】 SLI / SLO の運用体制の構築を通して、開発生産性の向上、顧客 (社内外) に信頼さ れるサービスの提供、事業拡大への対応を実現する 【目標】 事業部の開発組織に Product SRE を導入し、 SRE の教育・運用の体制構築を実施 し、Embedded SRE が自然と SLI/SLO の導入・運用を実施出来る様にする テク戦 SRE の中長期の理想・ 目標
7. 社内の今後の目指すべき SRE 体制 • Evangelist SRE Role ◦ テク戦 SRE メンバーのことを指す ◦ 全社を横断し、運用効率化のツール・仕組みの提供、ノウハウの提供・吸い上げ、アー キテクチャー相談等を実施する • Product SRE Role ◦ 事業部の開発組織を横断する SRE メンバーのことを指す ◦ 開発組織内の SRE 化の支援・浸透や運用効率化の推進等を実施する • Embedded SRE Role ◦ サービス開発チームに所属の SRE メンバーのことを指す ◦ SRE プラクティスを適用したり、サービスインフラの構築・運用等を実施する
8. 社内の今後の目指すべき SRE 体制
9. 本セッションでお話すること • 全社へのナレッジ・ノウハウの展開を考え、主に次をお話します ◦ テク戦 SRE による、これまでの運用効率化に関する動き ◦ 現在のインフラ設定のテストにおける考え方・実施方法等 • 発表時間を踏まえ、基本知識・詳細・周辺事項等には触れません ◦ セッション内容について、ざっくりと理解頂ければ幸いです ◦ 参考情報を共有しておきますので、良ければご確認ください
10. 2 これまでの運用 効率化の取り組み
11. • サービス運用の効率化を進めるため、まずはインフラ・監視基盤の IaC 化による整備を推進し、管理・運用の省力化を進めていた • 実際には開発チームにより IaC ツールの選定にバラツキがあり、開発 チームとテク戦 SRE の双方で次の様な課題感が顕在化し始めた ◦ ツールの理解度や習熟度がバラついているため、開発チーム間でのナレッ ジやノウハウの共有が困難である ◦ 開発チームの採用技術、理解度や習熟度に合わせてインフラ・監視基盤の 整備を支援するため、負荷が高い 従来の運用における課題感・打ち手
12. 従来の運用における課題感・打ち手
13. • 開発チームのインフラ・監視基盤の整備や、テク戦 SRE からの整備支 援を低工数・低負荷で進めるには、次の取り組みが必要だと考えた ◦ 社内標準となる IaC ツールの選定 ▪ Terraform、OpenTofu、AWS CDK、CDKTF、Pulumi から検討 ◦ IaC 関連のライブラリ・テンプレートの作成 ▪ 社内のインフラ標準構成に基づく Terraform Modules の開発 ▪ Terraform CI/CD 向けの GitHub Composite Actions の開発 ▪ Terraform のコード管理用の GitHub Repository Template の開発 従来の運用における課題感・打ち手
14. • IaC ツールの認知度・利用度の高さを考え、次を選択肢とした ◦ Terraform、OpenTofu、AWS CDK、CDKTF、Pulumi • 社内状況に適した IaC ツールを選定するために、次を優先条件とした ◦ なるべく幅広いサービスで同一ツールが利用可能である ◦ ライブラリ・モジュール等で同一パターンを容易に適用可能にする仕組みを持っている ◦ ツールにおける学習コストが高くない • 次の観点で比較評価を行い、 Terraform・OpenTofu が高評価だった ◦ 成熟度・カバー範囲、ツールの学習負荷、構築・変更の負荷、状態変更の容易性、 Gen AI との相性 社内標準としての IaC ツールの選定：比較評価
15. 社内標準としての IaC ツールの選定：比較評価 比較観点 評価理由 成熟度・カバー範囲 殆どのパブリッククラウドやその他の SaaS におけるプロバイダーが利用可能 で、関連するコミュニティ、知識・知見、ツール等が充実している。 ツールの学習負荷 HCL は JSON ライクで学習しやすく、設定が宣言的で見通しが良い。 構築・変更の負荷 設定が宣言的であるため、クラウドサービスの作成・更新・削除において、コード 変更とズレの無い状態差分で期待通りに適用することが出来る。 状態変更の容易性 専用のブロック設定 (import / moved / removed blocks) を用いて、状態のイン ポート、変更、除外の操作をコードベースで容易に実施出来る。 Gen AI との相性 宣言的でシンプルな設定が大半なため、変数設定の手直しは必要だが、簡単な プロンプトで一定以上のクオリティでサンプルコードを生成出来る。
16. • 比較評価だけでなく、ツールの将来的なリスクも考える必要があり、主にライセ ンス変更による Terraform の利用制限について調査した • 通常の利用においては概ね従来通りで利用可能であり、利用制限に関するリス クは見られなかった ◦ 社内・個人による HashiCorp 製品の利用においては、利用制限は無い ◦ HashiCorp 製品を埋め込んでいる競合製品が提供されている場合、この様な競合製 品は Terraform のライセンスに抵触する (例：Terratest) • 今後の HashiCorp クラウドサービスとのシームレスな連携・統合の検討可能性 も踏まえ、 OpenTofu ではなく Terraform の方が良いと考えた 社内標準としての IaC ツールの選定：リスク調査
17. • 比較評価やリスク調査の結果、 Terraform を社内標準なツールとして採 用し、Terraform で IaC 化を推進していくことになった • Terraform の導入・移行における費用対効果が必ずしも高くは無いパ ターンも考えられるため、導入・移行の例外事項を規定した ◦ Terraform へのツール移行 ◦ Terraform によるサポートが弱い部分への IaC 化 ◦ 外部サービスの仕組みにおける Terraform の導入 ◦ 一時的な利用のシステムへの Terraform の導入 社内標準としての IaC ツールの選定： 検討結果
18. 社内標準としての IaC ツールの選定： 例外事項 例外パターン 対応方針 Terraform へのツール移行 他ツールで管理下のパブリッククラウドや SaaS では、移行コストと改善 効果性のバランスを考え、 Terraform への移行を検討する。 Terraform によるサポート が弱い部分への IaC 化 Terraform へのサポートが未対応、またはサポート範囲が狭い部分では 他ツールの利用を認める。 外部サービスの仕組みにお ける Terraform の導入 パブリッククラウドや SaaS で提供される仕組みにおいて、 Terraform 以 外の手段で構築されている場合は、その手段の利用を認める。 一時的な利用のシステムへ の Terraform の導入 プロトタイプや実験的な環境等の、一時的な利用が確実に見込まれる様 なシステムでは、 Terraform による IaC 化は強制しない。
19. • 開発チームやテク戦 SRE のサポートメンバーにヒアリングすると、 IaC 化における下記の課題感が明らかになった ◦ 実装の際にクラウドサービスの仕様把握が必要で、実装負荷が高い ◦ 宣言的な設定のためシンプルで分かりやすいが、リソースが多くなると設定 管理における認知負荷が高まる ◦ CI/CD やコード管理の標準構成が無く、設計や構築で時間がかかる • これらを解決するには、社内の標準構成に基づいたライブラリ・テンプ レートが必要だと考え、これらを開発することになった IaC 化の推進における課題感・打ち手
20. ライブラリ・テンプレートの開発： Terraform Modules • 全社最適のパターンを考え、次のモジュール構成方針を考え出した ◦ (1) 個別最適の手段を組み合わせることで、全社最適を図る ▪ 社内のサービス・システムに合わせたモジュール ◦ (2) 個々に依存せず全社をカバーする形で、全社最適を図る ▪ クラウドサービスのリソースに対応するモジュール • 主に利用負荷、メンテナンス性、拡張性、汎用性から 案 (2) を採用した • 当時のモジュール構成管理の推奨事項や社内の既存ライブラリの設計思想を 参考に、負荷軽減も考慮して 2種類のモジュール を開発した
21. ライブラリ・テンプレートの開発： Terraform Modules モジュール構成方針 方針の評価内容 社内のサービス・システムに 合わせたモジュール サービス・システム毎に特化したモジュールのため、極力少ない設定でイ ンフラの構築・運用が可能である。 しかし、各々の構成変更に追従してメンテナンスする必要があり、メンテ ナンス面で大きな課題が見られた。 クラウドサービスのリソース に対応するモジュール サービス・システムの個別の設定・構成に依存せずに全社に展開出来る ため、メンテナンス面の課題は小さい。 社内要件やクラウドサービスにより推奨される設定・構成をベースに作り 込めば、インフラ構築・運用の作業負荷を軽減可能だと考えた。
22. ライブラリ・テンプレートの開発： Terraform Modules モジュールの種類 モジュールの概要 Component Modules クラウドサービスの単体リソースに対応する様なモジュール。 例えば、ELB・ECS・EC2・RDS 等のリソース毎に、対応するモジュー ルで管理する。 Catalog Modules クラウドサービスの複数リソースに対応する様なモジュール。 例えば、ELB・ECS、CloudFront・WAF 等のリソース群をモジュール でまとめて管理する。
23. ライブラリ ・テンプレート の開発：GitHub Composite Actions • 下記の理由で GitHub Actions を採用しており、この処理共通化に関する開発 を行うことになった ◦ 社内における CI/CD サービスの利用状況 ◦ CI/CD サービスの GitHub 向け連携機能の充実さ • 主に3種類の共通化の方法があり、処理共通化のパターンやコード管理の方針 をもとに、 案 (2) を採用することにした ◦ (1) GitHub Custom Actions ◦ (2) GitHub Composite Actions ◦ (3) GitHub Reusable Actions
24. ライブラリ・テンプレートの開発： GitHub Composite Actions • 以下は、ライブラリ・テンプレートのコード管理の前提・方針である ◦ テク戦、開発チームの GitHub Organization は別々である ◦ ライブラリ・テンプレートの管理元の GitHub Repository は、テク戦の GitHub Organization の配下で管理されている ◦ ライブラリ・テンプレート用の、開発チーム用の GitHub Repository の可視性は Internal or Private である • テク戦推奨の Terraform CI/CD の構成をもとに GitHub Composite Actions を作り、Terraform CI/CD の処理共通化・テンプレート作成を行った
25. ライブラリ・ テンプレートの開発： GitHub Repository Template • 社内で AWS が多く利用されているため、優先的に AWS・Terraform に関する GitHub Repository Template を優先して作成した • テク戦推奨の Terraform のコード管理構成をもとに、 Template のファイルや ディレクトリの構成雛形を考えた • スクリプトで Template を一気に書き換え、コード・資料の情報を利用者に合わ せた情報に変更出来る様にした • 更に、Template に AWS・Terraform に関する初期設定・構築作業等の手順・ 雛形も含めて提供している
26. ライブラリ・テンプレートの開発： GitHub Repository Template • Terraform 向け Repository の作成だけでなく、以下の作業も簡単になる ◦ Slack への通知に関する初期設定 ▪ 通知チャンネルの作成、 Webhook 連携の設定 ◦ Terraform 関連の初期設定・構築 ▪ Terraform Backend の構築 ▪ CI/CD 用の IAM リソースの作成 ▪ CI/CD の設定作成・有効化 ◦ AWS サービスの初期設定・構築 ▪ 月額予算アラートの作成 ▪ 監査ログやセキュリティの検知・検出リソースの作成 ▪ 監視アラートの通知基盤に関するリソースの作成
27. 3 Terraform での テストアプローチ
28. 従来・現在のテストの実施方法 • 従来はテスト用のツール・機能が充実しておらず、モジュール毎にサンプルコー ドを用意し、下記を用いて構築検証を行っていた ◦ サンドボックス用の AWS アカウント ◦ LocalStack 等の擬似的な専用の環境 • 構築後は、コマンドやプログラムでネットワーク疎通やシステム環境のコンポー ネント間連携等を検証し、リソースを破棄していた • 現在はチェック・テストに関するツール・機能が充実してきており、先述の手動で の検証プロセスが概ね自動で実施可能になっている
29. 従来・現在のテストの実施方法 テストの種類 ツール・機能の例 静的解析 TFLint、Terraform CLI、Terraform Custom Conditions セキュリティチェック Trivy、Checkov、Synk、Terrascan コンプライアンスチェック terraform-compliance ポリシーチェック Open Policy Agent、Conftest、Hashicorp Sentinel 単体・結合テスト Terratest、Terraform Testing Framework サーバテスト InSpec、Serverspec、Goss
30. 従来・現在のテストの実施方法 テストの種類 ツール・機能の例 静的解析 TFLint、Terraform CLI、Terraform Custom Conditions セキュリティチェック Trivy、Checkov、Synk、Terrascan コンプライアンスチェック terraform-compliance ポリシーチェック (PaC) Open Policy Agent、Conftest、Hashicorp Sentinel 単体・結合テスト Terratest、Terraform Testing Framework サーバテスト InSpec、Serverspec、Goss
31. Terraform Custom Conditions • ここでは、 Terraform のテスト・バリデーションに焦点を当て、下記の機 能について概説したい ◦ Terraform Custom Conditions ▪ Input Variable Varidation ▪ Preconditions・Postconditions ◦ Terraform Testing Framework 　※ Custom Conditions の Checks with Assertion は、ここでは触れない 　※ Policy as Code の概要・主要なツール等は、次のセクションで紹介する
32. Custom Conditions：Input Variable Validations • Terraform v0.13 から、Input Variables で Validation Block という変数設定 のバリデーション機能が追加された • variable block 内に validation block を宣言し、バリデーションの条件とエラー メッセージをそれぞれ condition・error_message で設定する
33. Custom Conditions：Input Variable Validations • Input Variable Validations による設定検証は、 plan の処理時に実行される • condition が false となれば、 error_message が出力され、異常終了する • 複数の validation block の設定は可能で、少なくとも 1つの block で検証エ ラーが発生すれば異常終了する
34. Custom Conditions：Input Variable Validations • 従来は、condition では validation block の設定先の Input Variable と、組み 込み関数の組み合わせでしか設定出来なかった • v1.9 のリリースでこの制約が解消され、他の Input Variable や Data Source 等も condition で参照可能になった • 後述の Preconditions と遜色無いレベルになったが、基本的には変数のバリ デーションに留める形で実装すると良さそう • ルートモジュールでは Local Values を用いることが多いため、基本的には再利 用可能モジュールで仕込むと良さそう
35. Custom Conditions：Preconditions・Postconditions • Terraform v1.2 から Preconditions・Postconditions という、Resource、 Data Source、Outputs の設定検証の機能が追加された
36. Custom Conditions：Preconditions・Postconditions • lifecycle block 内で precondition block や postcondition block を設定する ことにより、これらの機能を利用することが出来る
37. Custom Conditions：Preconditions・Postconditions • Preconditions による設定検証は plan の処理時に、 Postconditions による 設定検証は apply の処理時にそれぞれ実行される
38. Custom Conditions：Preconditions・Postconditions • Terraform のコード設定のチェックでは Preconditions を、リソースの構築後に 想定通りになっているか確認する場合は Postconditions を利用する
39. Terraform Testing Framework：概要・ディレクトリ構成 • Terraform v1.6 から、Testing Framework というモ ジュールテストを実施する機能が追加された • ルートモジュール配下に tests フォルダを作り、そこで tftest.hcl 拡張子のファイルを作成する • その後、Terraform CLI の test コマンドをルートモ ジュール直下で実行し、テストを実施出来る ◦ デフォルトでは、ルートモジュール 直 下 、またはそのサ ブディレクトリの tests でファイルが探索される ◦ ファイルの格納場所を指定する場合は、 test コマンドの test-directory オプションを実行の際に利用する
40. Terraform Testing Framework：テスト処理の基本設定 • テスト処理の設定は、 tftest.hcl ファイルで run block を用いて宣言する • 主要な引数は command・assert 、これらの設定方法は下記の通りである ◦ command には、plan / apply を指定しテストの実行フェーズを設定する ◦ assert block には、Custom Conditions と同様で condition・error_message を設定する
41. Terraform Testing Framework：テスト処理の実行順序 • test コマンドを実行すると、次の通りでテスト処理が実行される ◦ 格納場所から tftest.hcl ファイルのパス一覧を取得する ◦ 名前のアルファベット順に、 tftest.hcl ファイル毎にテストを実施する ▪ tftest.hcl ファイル内では、 run block をファイル上部から順番に実行する ▪ run block の実行後、この逆順でリソースのクリーンアップを実行する ▪ テスト・クリーンアップが完了すると、ファイル内の処理実行は完了する ◦ 各 tftest.hcl ファイルにおける処理が完了すると、テストは終了する
42. Terraform Testing Framework：State の管理方法 • テスト用の State が次の様に生成され、メモリで管理・破棄される ◦ テストの設定ファイル毎に、 State が生成される ◦ run block の設定に関する State は、次の通りで生成される ▪ モジュールを参照する run block の設定は、専用の State として生成される ▪ モジュールを参照しない run block の設定は、設定ファイルの State に統合され る ▪ 同一モジュールを参照する run block が複数存在する場合は、同一の専用の State に統合される ◦ クリーンアップでは、テストの逆順で State の破棄が実施される ▪ ある設定に対応する State が破棄済みの場合は、破棄がスキップされる
43. Terraform Testing Framework：Mocks の概要・利用方法 • Terraform v1.7 から、Mocks というテスト関連の機能が追加された • この機能で、全体的または部分的にモックオブジェクトを利用出来る • モジュールの外部依存な部分を Mocks でモック化し、 API の呼び出し やプロバイダー認証を極力無くす形でテスト出来る • つまり、本来のソフトウェアの単体テストに近い形で、モジュールの機能 を高速・正確にテスト出来る様になったのである
44. Terraform Testing Framework：全体的なモック化 • mock_provider block により、 Provider、Resource、Data Source のモック化が出来る • モック化された Provider とそうで ないものを使い分けたい場合は alias を利用すれば良い
45. Terraform Testing Framework：全体的なモック化 • mock_resource、mock_data で、Resource、Data Source の モックオブジェクトの属性値を指 定出来る • 例えば、右の実装例の様に設定 すると、S3 のモックオブジェクトの ARN を指定出来る
46. Terraform Testing Framework：全体的なモック化 • mock_resource、mock_data は別のファイルに切り出せる • 右の実装例の様に、 tfmock.hcl の拡張子のファイルに切り出し て、mock_provider の source で参照パスを指定すれば良い
47. Terraform Testing Framework：部分的なモック化 • Mocks の Override 機能により、特定の既存の Resource、Module、Data Source を参照し、モックオブジェクトを作成出来る ◦ Resource の場合、override_resource でモック化出来る ◦ Module の場合、override_module でモック化出来る ◦ Data Source の場合、override_data でモック化出来る • override_resource、override_data では、values で属性値を指定出来る • override_module では、outputs で属性値を指定可能である
48. Terraform Testing Framework：部分的なモック化
49. Terraform Testing Framework：部分的なモック化
50. 4 Policy as Code を用いた設定検証
51. Policy as Code とは何か？ • Policy as Code (PaC) とは、組織やシステムの遵守事項をポリシーの コードとして宣言し、ポリシーを運用・管理する手法である • この手法を用いることで、ポリシーの変更管理や各種設定への一貫した 適用等が容易かつ効率的になる • 主に、セキュリティ、コンプライアンス、リソース設 定 等の要 件やルール の順守における検証で利用される
52. 主要な PaC ツールの紹介： Open Policy Agent・Conftest • Open Policy Agent (OPA) とは、OSS のポリシーエンジンである • ポリシーエンジンとは、ポリシーに違反した情報が無いかチェックし、事 前に定義されたアクションを実行する機構である • OPA を用いる場合、 Rego という言語でポリシーを宣言し、 OPA CLI を 実行してポリシーに則った検証を行う
53. 主要な PaC ツールの紹介： Open Policy Agent・Conftest • Conftest とは、OPA をエンジンとしたポリシーの検証ツールである • OPA と同様で、 Rego でポリシーを宣言して Conftest CLI を実行して ポ リシーに則った検証を行う • Dockerfile、HCL / HCL2、JSON、YAML、XML 等の様々なファイルを 検証可能であり、実際に導入する場合は Conftest の方が良い
54. 主要な PaC ツールの紹介 ：Open Policy Agent・Conftest
55. 主要な PaC ツールの紹介： Hashicorp Sentinels • Hashicorp Sentinel とは、Hashicorp により提供される PaC の言語や フレームワークである (Rego とは異なる言語が用いられる ) • 無料利用は可能だが、基本的に Hashicorp のクラウドサービスとの連 携を前提とした機能が多く、実際は有料機能の検討が必要になる • Hashicorp のクラウドサービスを導入予定の場合はこのツールが望ま しいが、そうでは無い場合は Conftest で運用するのが良い
56. どの様にテストを組み込むか？ • 基本的には、まずは現在の必要最小限なテストパターンを洗い出し、それらを自 動化して運用し始めるのが良い • 私見だが、従来のテスト手法と各種機能で出来ることを整理すると、初めの内は 下記のみから組み込み始めるだけでも十分に良いと考えている ◦ Terraform Custom Conditions：Input Variable Validation、Preconditions • 実際に運用し始めて、必要に迫られた時に以下も追加で検討すれば良い ◦ TFLint、Trivy ◦ Terraform Testing Framework (with Mocks) ◦ Policy as Code：Conftest
57. 5 今後の展望
58. 今後のテク戦 SRE の動き • 今後は、特に Terraform Modules に焦点を当て、開発・展開をさらに迅速に進 めるために、体制構築・負荷軽減の取り組みにも専念する予定です ◦ メンテナー体制の構築 ▪ メンテナー向けのガイドラインの作成 ▪ 機能開発・テスト等のフローの自動化 ◦ 利用者向けの負荷軽減 ▪ 利用者向けのガイドラインの作成 ▪ 機能・仕様情報のガイドラインに沿った修正 ◦ リリース展開・FB 吸い上げの体制の構築
59. 6 参考情報
60. 参考情報のリンク一覧 • これまでの運用効率化の取り組み ◦ レバレジーズテックブログ • Terraform でのテストアプローチ ◦ Terraform Custom Conditions ◦ Terraform Testing Framework ◦ Terraform CLI：Testing ◦ Terraform Tutorials：Write Terraform Tests
61. 参考情報の リンク一覧 • Policy as Code を用いた設定検証 ◦ Open Policy Agent ◦ Conftest ◦ Hashicorp Sentinel • その他 ◦ 詳解 Terraform 第3版 (O'Reilly) ◦ Infrastructure as Code (O'Reilly)
62. ご清聴、ありがとうございました！