はじめに
レバレジーズ株式会社 テクノロジー戦略室 SREチームの中野です。レバレジーズでは「SRE化を通して、Developer Experienceの改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する」をミッションとして、Embedded SREメンバーと協力しながら、サービス改善の文化的土俵の構築や開発生産性の向上を進めています。
この記事では、開発体験を向上させるための取り組みとして、社内標準となるIaCツールの選定、IaC化の負荷軽減への取り組みについてご紹介します。具体的には、社内標準ツールの選定では決定に至るまでのプロセスや方法をご紹介し、IaC化の作業負荷の軽減への取り組みでは、全体最適を狙った下記のライブラリ・テンプレートの作成についてご紹介します。
- Terraform Modules
- GitHub Composite Actions
- GitHub Repository Template
また、この記事を通して、弊社の開発体験の向上における取り組みを知って頂くと共に、全社最適を狙ったIaC化の推進について是非ともご参考頂ければ幸いです。それでは、以下で背景を挟みつつ具体的な取り組みについてご紹介します。
背景
サービス開発体制のSRE化を進めやすくするために、インフラ構築・管理の省力化でIaC化を進めています。しかし、実際にはAWS CDK、AWS CloudFormation、Terraform等の複数のツールが利用されており、開発チーム・SREチームの双方において作業負荷がかかってしまっています。
実際、ツールの乱立により、開発チームではIaCツールの理解度・習熟度がバラついており、開発チーム間でのナレッジ・ノウハウの共有が困難だったりします。SREチームでも、開発チーム毎に異なるサポートが必要となり、サポート負荷が高くなりがちです。
この様な状況を解消するためには、ツールの乱立を最小限に抑え、IaC化を低負荷・低工数で進められる様にする必要があると考え、社内標準となるIaCツールの選定と、IaCツールやCI/CDにおけるライブラリ・テンプレートの作成を進めることになりました。
社内標準となるIaCツールの選定
ツール比較
まずは、社内標準となるIaCツールの比較から始めました。ツールの認知度・利用度の高さを考えてTerraform・AWS CDK・Pulumi・CDKTF・OpenTofuから比較し、Terraform・OpenTofuが最良の選択肢として残りました。理由は下表の通りです。
| 比較観点 | 評価理由 |
|---|---|
| 成熟度・カバー範囲 | 殆どのパブリッククラウドに対応しており、SaaSでも対応範囲が広い。 |
| ツールの学習負荷 | HCLはJSONライクで学習しやすく、リソース設定が宣言的で見通しが良い。 |
| 構築・変更の負荷 | リソース設定が宣言的なため、クラウドサービスの構築・更新でコード変更とズレの無い状態差分で期待通りに適用出来る。 |
| 状態変更の容易性 | import・moved・removed等のブロック設定により、ツールで管理される状態の追加・変更・削除をコードベースで容易に実施出来る。 |
| GenAIとの相性 | リソース設定が宣言的なため、簡単なプロンプトで一定以上のクオリティでサンプルコードを生成出来る。 |
リスク調査
ツール比較でTerraform・OpenTofuが最良の選択肢として残りましたが、今後IaC化を問題無く推進していくためにツールの将来的なリスクも考えておく必要があり、ライセンス変更によるTerraformの利用制限の可能性について調査しました。
ライセンスに関する公式情報によれば、Terraformの利用範囲は従来通りでリスクはありませんでした。実際、HashiCorpの競合製品においてはHashiCorp製品が埋め込まれていれば利用制限が発生しますが、社内/個人によるHashiCorp製品の利用においては制限は無いとのことでした。
一方で、OpenTofuは今後のツールとしての安定性・充実性が現時点では見込めなさそうなため、Terraformの方がより安定的でリスクが低いツールであると判断しました。
www.hashicorp.com www.hashicorp.com www.hashicorp.com
選定結果・例外
以上の比較・調査の結果を踏まえ、Terraform を社内標準ツールとして採用しました。今後はTerraformでIaC化を推進していく予定です。しかし、Terraformの導入・移行における費用対効果が必ずしも高く無いパターンもあり、下表を例外として規定しました。これらを考慮しながらIaC化を進めていきます。
| 例外パターン | 対応方針 |
|---|---|
| Terraformへのツール移行 | 他ツールで管理されているパブリッククラウドやSaaSでは、移行コストと改善効果性のバランスを考え、Terraformへの移行を検討する。 |
| Terraformによるサポートが弱い部分へのIaC化 | Terraformのサポートが未対応、またはサポート範囲が狭い部分では他ツールの利用を認める。 |
| 外部サービスの仕組みにおけるTerraformの導入 | パブリッククラウドやSaaSで提供される仕組みにおいて、Terraform以外の手段で構築されている場合は、その手段の使用を認める。 |
| 一時的な利用のシステムへのTerraformの導入 | プロトタイプや実験的な環境等の、一時的な利用が確実に見込まれる様なシステムでは、TerraformによるIaC化は強制しない。 |
ライブラリ・テンプレートの作成
次に、IaC化を低負荷・低工数で推進するために、IaCの移植性・再利用性等を高める様なプラクティスの検討を進めました。Terraformを利用している開発チームにヒアリングしたところ、下記の課題感が出てきました。
- 実装の際にクラウドサービスの仕様把握が必要で、実装における作業負荷が高い
- 宣言的な設定のため、リソースが多くなると設定管理における認知負荷が高まる
- Git RepositoryやCI/CDにおける社内標準の構成が無く、設計・初期作業で時間がかかる
これらを解決するためには、Terraformにおける社内標準のライブラリ・テンプレートを作成する必要があると考え、Terraform Modules・GitHub Composite Actions・GitHub Repository Templateを全社向けに開発することになりました。
管理方針
SREチームがライブラリ・テンプレートをメンテナンスしていく予定のため、テクノロジー戦略室向けのGitHub Organizationの配下でライブラリ・テンプレートを管理することにしました。また、ローカルやCI/CDでライブラリを利用する際に、PATをベースとしたアクセス認証でライブラリをダウンロードする様にしました。
作成方針
Terraform Modules
全社最適のパターンとして、個々に依存しない手段を用いて全社最適を図るか、または個別最適の手段を組み合わせて全社最適を図るかの2種類が考えられ、そこからTerraform Modulesにおける次の構成方針を洗い出しました。
- (1) 社内のサービス・システムに合わせたTerraform Modules
- (2) クラウドサービスのリソースに対応するTerraform Modules
検討の結果、(2)の方針でTerraform Modulesの構成を考えることにしました。実際、(1)の方針ではサービス・システム毎に特化したTerraform Modulesのため、極力少ない設定でインフラ構築・運用が可能です。しかし、サービス毎のシステム構成の変更に追従してTerraform Modulesをメンテナンスしていく必要があり、メンテナンス面で課題がありました。
一方、(2)の方針では、サービス・システムの個別の設定・構成に依存せずに全社に展開出来るため、メンテナンス面の課題は小さめでした。また、社内要件やクラウドサービスにより推奨される設定をベースとして作り込めば、インフラ構築・運用における作業負荷を軽減可能だと考えました。結果として、メンテナンス性・利用者の負荷軽減のバランスの取れた(2)の方針が最良となりました。
とは言え、単にクラウドサービス毎にTerraform Modulesを作ってしまうと、汎用性やメンテナンス性は高められるがサービス・システム毎の最適化には繋がらないため、次の2種類のTerraform Modulesを作成することにしました。
| 種別 | 説明 | 用途例 |
|---|---|---|
| Component Modules | クラウドサービスの単体のインフラリソースに対応するTerraform Modules | ELB・ECS・EC2・RDS等のリソース毎にModulesで作成する |
| Catalog Modules | クラウドサービスの複数のインフラリソースに対応するTerraform Modules | ELB・ECS、CloudFront・WAF等のリソース群をModulesで作成する |
また、社内のサービス・システムの構成パターンを考えたところ、AWSを利用しているものが大半であり、かつCloudFront・WAF・ELB・ECS・RDS・ElastiCacheを用いた構成が多いため、この様なAWSインフラ構成におけるComponent/Catalog Modulesの開発を優先的に進めることになりました。
GitHub Composite Actions
社内におけるCI/CDツールの利用状況や、CI/CDツールにおけるGitHub向けの連携機能の充実さを考慮し、GitHub Actionsを利用してTerraform CI/CDのパッケージを作成することにしました。
GitHub Actionsの処理共通化を調べると、Custom Actions、Composite Actions、Reusable Workflowsのいずれかを用いれば良いことが分かり、処理共通化が容易かどうか、下記を満たす形で運用が可能かどうかを考え、Composite Actionsを採用しました。
- テクノロジー戦略室のOrganization、開発チームのOrganizationは別々である
- ライブラリ・テンプレートのRepositoryは、テクノロジー戦略室のOrganization管理下である
- ライブラリ・テンプレートのRepository、開発チーム向けのRepositoryはPrivateである
GitHub Repository Template
大半の社内サービス・システムでAWSが利用されているため、Terraform・AWS用のGitHub Repository Templateを優先して作ることにしました。また、開発チームのGitHub Repositoryで最適と思われるものを基準にして、GitHub Repository Templateの構成を考えました。
Repositoryの生成・設定については、テンプレート内のコード・資料等をスクリプトで書き換える様な仕組みを導入し、テンプレートからTerraform用のRepositoryを低工数で設定出来る様にしました。
更に、Terraformの管理基盤を構築する際に、Repositoryの設定だけでなく下記の作業も対応する必要があり、下記における設定手順の資料やTerraformの設定ファイルをテンプレートに含め、Terraformの導入における初期作業を全体的に低工数で済む様にしました。
- Slack通知の初期設定
- 通知チャンネルの作成
- Webhook連携の設定
- Terraformの初期設定
- Terraform Backendの構築
- CI/CD用のIAMロールの作成
- CI/CDの設定作成・有効化
- クラウドサービスの初期設定
- 月額予算アラートの設定
- 監査ログ、セキュリティ検知の設定
- アラート通知の仕組みの構築
今後の活動
以上の様に、社内標準のIaCツールの選定と、IaCツールのライブラリ・テンプレートの作成を進めてきました。しかし、現状ではライブラリ・テンプレートにおける開発のルール・フローや全社展開・要望吸い上げの体制が整い切れていないため、今後はこれらを整備してIaC化を推進していく予定です。
また、現在はAWSを対象にIaCツールのライブラリ・テンプレートを作成していますが、今後はGoogle Cloud、Datadog、GitHub等のAWS以外のクラウドサービスも検討し、ライブラリ・テンプレートの対象範囲を広げていきたいとも考えています。
最後に
レバレジーズでは、全社のSRE導入に向けて、サービス改善の文化的土俵の構築や開発生産性の向上のための取り組みを手伝って頂けるエンジニアを募集しています。
SREの文化・体制に興味があったり創っていきたい方や、これからフルスタックエンジニアになっていきたい方は、是非ともご応募をお待ちしております。
