Slide 1
Slide 1 text
Money Forward
with
Terraform Cloud OPA
HashiCorp Japan Tech Update
HashiDays 2023 Recap
Slide 2
Slide 2 text
2022/04 - Now Money Forward, inc.
サービス基盤本部インフラ部Platformグループ所属
全社で利用されるサービス提供基盤の運用/開発。AWS
上で構築されたk8sを中心とした基盤
自己紹介 - 清水 速太 (Shimizu Hayata)
2017/04 - 2022/03 AP Communications Co., Ltd.
NW/SVエンジニアとして勤務。
物理NW機器の運用からキャリアを始め、運用自動化
/CICD/IaC/クラウドを経験
2
Slide 3
Slide 3 text
今日話すこと
サービス基盤本部について
OPAとは
OPA導入の理由
OPAを導入してみて
3
Slide 4
Slide 4 text
サービス基盤本部
について
4
Slide 5
Slide 5 text
About us (Money Forward)
5
Slide 6
Slide 6 text
About us (サービス基盤本部)
「プラットフォームを作る」
6
Slide 7
Slide 7 text
About us (サービス提供基盤)
7
Slide 8
Slide 8 text
OPAとは
8
Slide 9
Slide 9 text
OPAとは
Policy-based control for cloud native environments
出典: Cloud Native Computing Foundation
汎用ポリシーエンジンとポリシー定義言語
9
Slide 10
Slide 10 text
OPAとは
Policy as Code
● Sandboxing
● Codification
● Version Control
● Testing
● Automation
出典: HashiCorp https://docs.hashicorp.com/sentinel/concepts/policy-as-code
10
Slide 11
Slide 11 text
Terraform & OPA
OPA on Terraform Cloud
11
Slide 12
Slide 12 text
OPA導入の理由
12
Slide 13
Slide 13 text
OPA導入契機
SG障害
13
RDS障害 インフラコスト
Slide 14
Slide 14 text
OPA導入契機
● AWS SecurityGroupでインシデント発生
● AWS SGのQuota
○ SGの設定可能なRule数の上限: 60
● SGのRule数上限を超えてApply
○ AWS APIの制約上、SG削除->SG再作成が正常な動き
○ 再作成がクォータ上限で失敗
● SGにRuleが存在しない。サービス不通となる障害。
SG障害
14
概要
Slide 15
Slide 15 text
OPA導入契機
● AWS SecurityGroupでインシデント発生
● AWS SGのQuota
○ SGの設定可能なRule数の上限: 60
● SGのRule数上限を超えてApply
○ AWS APIの制約上、SG削除->SG再作成が正常な動き
○ 再作成がクォータ上限で失敗
● SGにRuleが存在しない。サービス不通となる障害。
SG障害
15
概要
Slide 16
Slide 16 text
OPA導入契機
● AWS SecurityGroupでインシデント発生
● AWS SGのQuota
○ SGの設定可能なRule数の上限: 60
● SGのRule数上限を超えてApply
○ AWS APIの制約上、SG削除->SG再作成が正常な動き
○ 再作成がクォータ上限で失敗
● SGにRuleが存在しない。サービス不通となる障害。
SG障害
16
概要
Slide 17
Slide 17 text
OPA導入契機
● AWS SecurityGroupでインシデント発生
● AWS SGのQuota
○ SGの設定可能なRule数の上限: 60
● SGのRule数上限を超えてApply
○ AWS APIの制約上、SG削除->SG再作成が正常な動き
○ 再作成がクォータ上限で失敗
● SGにRuleが存在しない。サービス不通となる障害。
SG障害
17
概要
Slide 18
Slide 18 text
OPA導入契機
● Quota上限値を超えていないことを確認してからApply
すること
SG障害
18
対策
Slide 19
Slide 19 text
OPA導入契機
● AWS RDSでインシデント発生
○ engine_version = x.y.z
○ auto_minor_version_upgrade = true
● AWSとTerraformでengine_versionに差分発生
● 差分状態でApplyするとダウングレード
○ ダウングレードはインスタンス削除 ->再作成
○ データ不整合で再作成に失敗
● インスタンスが不在となり、障害。
RDS障害
19
※要検証ですが修正されている可能性あり
概要
Slide 20
Slide 20 text
OPA導入契機
● AWS RDSでインシデント発生
○ engine_version = x.y.z
○ auto_minor_version_upgrade = true
● AWSとTerraformでengine_versionに差分発生
● 差分状態でApplyするとダウングレード
○ ダウングレードはインスタンス削除 ->再作成
○ データ不整合で再作成に失敗
● インスタンスが不在となり、障害。
RDS障害
20
※要検証ですが修正されている可能性あり
概要
Slide 21
Slide 21 text
OPA導入契機
● AWS RDSでインシデント発生
○ engine_version = x.y.z
○ auto_minor_version_upgrade = true
● AWSとTerraformでengine_versionに差分発生
● 差分状態でApplyするとダウングレード
○ ダウングレードはインスタンス削除 ->再作成
○ データ不整合で再作成に失敗
● インスタンスが不在となり、障害。
RDS障害
21
※要検証ですが修正されている可能性あり
概要
Slide 22
Slide 22 text
OPA導入契機
● AWS RDSでインシデント発生
○ engine_version = x.y.z
○ auto_minor_version_upgrade = true
● AWSとTerraformでengine_versionに差分発生
● 差分状態でApplyするとダウングレード
○ ダウングレードはインスタンス削除 ->再作成
○ データ不整合で再作成に失敗
● インスタンスが不在となり、障害。
RDS障害
22
※要検証ですが修正されている可能性あり
概要
Slide 23
Slide 23 text
以下の設定を強制
● deletion_protection = true
● ignore_changes = [engine_version]
OPA導入契機
RDS障害
23
対策
Slide 24
Slide 24 text
OPA導入契機
● サービス基盤本部が全事業部のインフラコストを持って
いる。
● 会社の成長と比例して部のコストが膨らんでいく。
● 事業部がどれだけインフラにコストを使っているかを把
握できないため、コスト意識が薄れていく。
インフラコスト
24
概要
Slide 25
Slide 25 text
OPA導入契機
AWS provider default_tags の設定を強制
インフラコスト
25
対策
Slide 26
Slide 26 text
実行方法検討
人間が確認するの!？
26
Slide 27
Slide 27 text
ツールの検討
● Terraformの書き方を制限したい
● 違反した状態でApplyを禁止したい
● ツールの運用をしたくない
ツールの要件
27
Slide 28
Slide 28 text
ツールの検討
TerraformCloud Policy の OPAにしました
● Terraform以外にも対象を広げることができる
28
Slide 29
Slide 29 text
時系列
2022/09
RDS障害発生
2021/?
SG障害発生
2022/10
インフラコスト調査開始
2022/10
OPA導入決定
29
Slide 30
Slide 30 text
時系列
2022/09
RDS障害発生
2021/?
SG障害発生
2022/10
インフラコスト調査開始
2022/10
OPA導入決定
2022/10/31
OPA(SG)導入
2022/11/16
OPA(RDS)導入
2022/11/28
OPA(Cost)導入
30
Slide 31
Slide 31 text
事象の共通項
?
コスト 障害
31
Slide 32
Slide 32 text
事象の共通項
恐怖
32
Slide 33
Slide 33 text
恐怖
● 削減の判断ができないコスト
● 深夜だからよかったものの、日中帯に起きていたら
...
● Platformの信頼性→サービスの信頼性→企業の評価
33
何を 恐怖 に感じていたのか
Slide 34
Slide 34 text
恐怖
● 削減の判断ができないコスト
● 深夜だからよかったものの、日中帯に起きていたら
...
● Platformの信頼性→サービスの信頼性→企業の評価
34
Slide 35
Slide 35 text
恐怖
恐怖 感じたことありませんか？
35
Slide 36
Slide 36 text
OPAを導入してみて
36
Slide 37
Slide 37 text
導入してよかったと感じた点
恐怖からの解放
37
Slide 38
Slide 38 text
導入してよかったと感じた点
よかった点
● policyを管理したいがためにTerraform versionを最
新化できた
● これまで各人の知識に偏っていたレビューポイントが明
確化された
38
Slide 39
Slide 39 text
● 一時的なポリシー解除が難しい。
○ whitelist方式でリソース名を追記し、解除する方式を採用
○ 本来の変更に加え、 whitelistの追加・削除の変更が必要で手間がかかる
● OPA設定がコード化されておらず、Adminが更新する必要がある。
○ Terraform CloudではOPAの設定すらもコード化が可能。 (Policy as Code as Code)
○ issueとして積まれているので早めに対応したい
● Policyに対するテストが組めていない
○ Policy自体のtestをCIに組み込むことでより良い Policyを維持する
課題に感じている点
39
Slide 40
Slide 40 text
OPA導入の苦労した点①
エラー表示が小さく、詳細な説明を残せない。
40
Slide 41
Slide 41 text
OPA導入の苦労した点①
Policyに対してコードを発行し、別途用意するドキュメント誘導。
エンジニアの理解度や納得度が向上
Terraform Plan結果の画面がスッキリ
● Code
● Doc URL
● Resource name
● denyの理由
● denyの回避方法
● Policy設定の背景
41
Slide 42
Slide 42 text
OPA導入の苦労した点②
Lifecycle ignore_changesに対するアプローチ
「ignore_changesが設定されていること」
42
Slide 43
Slide 43 text
OPA導入の苦労した点②
ignore_changesあり
ignore_changesなし
ignore_changesなし
ignore_changesを扱う場合は、直接 before/afterを参照する
43
Slide 44
Slide 44 text
まとめ
Slide 45
Slide 45 text
我々のOPA導入のきっかけは「恐怖」。
皆さんも少しでもTerraformの運用で恐怖を感じたことありませんか？
ぜひ、Policy導入の検討を！
まとめ
45
Slide 46
Slide 46 text
46
Slide 47
Slide 47 text
Appendix
47
Slide 48
Slide 48 text
今日の資料
48
Slide 49
Slide 49 text
過去の発表や資料
● 「TerraformのCI/CD - monorepoとTerraform Cloud」
○ HashiTalk 2021
○ Makita Riki
youtube SpeakerDeck
49
Slide 50
Slide 50 text
過去の発表や資料
● 「組織と事業の急拡大に立ち向かうためのマルチテナントAmazon EKS クラスタ/マ
ルチアカウントアーキテクチャ」
○ AWS Summit Online 2020
○ Ogasawara Junya
SpeakerDeck
50