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

HashiCorp Japan Tech Update HashiDays 2023 Recap User Session

HashiCorp Japan Tech Update HashiDays 2023 Recap User Session

I talked about our experience in implementing TerraformCloud OPA.

hayata.shimizu

July 07, 2023
Tweet

Other Decks in Technology

Transcript

  1. Money Forward
    with
    Terraform Cloud OPA
    HashiCorp Japan Tech Update
    HashiDays 2023 Recap

    View full-size slide

  2. 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


    View full-size slide

  3. 今日話すこと
    サービス基盤本部について
    OPAとは
    OPA導入の理由
    OPAを導入してみて
    3


    View full-size slide

  4. サービス基盤本部
    について
    4

    View full-size slide

  5. About us (Money Forward)
    5


    View full-size slide

  6. About us (サービス基盤本部)
    「プラットフォームを作る」

    6


    View full-size slide

  7. About us (サービス提供基盤)
    7


    View full-size slide

  8. OPAとは
    Policy-based control for cloud native environments

    出典: Cloud Native Computing Foundation 

    汎用ポリシーエンジンとポリシー定義言語

    9


    View full-size slide

  9. OPAとは
    Policy as Code

    ● Sandboxing

    ● Codification

    ● Version Control

    ● Testing

    ● Automation

    出典: HashiCorp https://docs.hashicorp.com/sentinel/concepts/policy-as-code

    10


    View full-size slide

  10. Terraform & OPA
    OPA on Terraform Cloud

    11


    View full-size slide

  11. OPA導入の理由
    12

    View full-size slide

  12. OPA導入契機
    SG障害
    13

    RDS障害 インフラコスト

    View full-size slide

  13. OPA導入契機
    ● AWS SecurityGroupでインシデント発生


    ● AWS SGのQuota

    ○ SGの設定可能なRule数の上限: 60


    ● SGのRule数上限を超えてApply

    ○ AWS APIの制約上、SG削除->SG再作成が正常な動き 

    ○ 再作成がクォータ上限で失敗 


    ● SGにRuleが存在しない。サービス不通となる障害。

    SG障害
    14

    概要

    View full-size slide

  14. OPA導入契機
    ● AWS SecurityGroupでインシデント発生


    ● AWS SGのQuota

    ○ SGの設定可能なRule数の上限: 60


    ● SGのRule数上限を超えてApply

    ○ AWS APIの制約上、SG削除->SG再作成が正常な動き 

    ○ 再作成がクォータ上限で失敗 


    ● SGにRuleが存在しない。サービス不通となる障害。

    SG障害
    15

    概要

    View full-size slide

  15. OPA導入契機
    ● AWS SecurityGroupでインシデント発生


    ● AWS SGのQuota

    ○ SGの設定可能なRule数の上限: 60


    ● SGのRule数上限を超えてApply

    ○ AWS APIの制約上、SG削除->SG再作成が正常な動き 

    ○ 再作成がクォータ上限で失敗 


    ● SGにRuleが存在しない。サービス不通となる障害。

    SG障害
    16

    概要

    View full-size slide

  16. OPA導入契機
    ● AWS SecurityGroupでインシデント発生


    ● AWS SGのQuota

    ○ SGの設定可能なRule数の上限: 60


    ● SGのRule数上限を超えてApply

    ○ AWS APIの制約上、SG削除->SG再作成が正常な動き 

    ○ 再作成がクォータ上限で失敗 


    ● SGにRuleが存在しない。サービス不通となる障害。

    SG障害
    17

    概要

    View full-size slide

  17. OPA導入契機
    ● Quota上限値を超えていないことを確認してからApply
    すること

    SG障害
    18

    対策

    View full-size slide

  18. OPA導入契機
    ● AWS RDSでインシデント発生

    ○ engine_version = x.y.z 

    ○ auto_minor_version_upgrade = true


    ● AWSとTerraformでengine_versionに差分発生


    ● 差分状態でApplyするとダウングレード

    ○ ダウングレードはインスタンス削除 ->再作成

    ○ データ不整合で再作成に失敗 


    ● インスタンスが不在となり、障害。

    RDS障害
    19

    ※要検証ですが修正されている可能性あり
    概要

    View full-size slide

  19. OPA導入契機
    ● AWS RDSでインシデント発生

    ○ engine_version = x.y.z 

    ○ auto_minor_version_upgrade = true


    ● AWSとTerraformでengine_versionに差分発生


    ● 差分状態でApplyするとダウングレード

    ○ ダウングレードはインスタンス削除 ->再作成

    ○ データ不整合で再作成に失敗 


    ● インスタンスが不在となり、障害。

    RDS障害
    20

    ※要検証ですが修正されている可能性あり
    概要

    View full-size slide

  20. OPA導入契機
    ● AWS RDSでインシデント発生

    ○ engine_version = x.y.z 

    ○ auto_minor_version_upgrade = true


    ● AWSとTerraformでengine_versionに差分発生


    ● 差分状態でApplyするとダウングレード

    ○ ダウングレードはインスタンス削除 ->再作成

    ○ データ不整合で再作成に失敗 


    ● インスタンスが不在となり、障害。

    RDS障害
    21

    ※要検証ですが修正されている可能性あり
    概要

    View full-size slide

  21. OPA導入契機
    ● AWS RDSでインシデント発生

    ○ engine_version = x.y.z 

    ○ auto_minor_version_upgrade = true


    ● AWSとTerraformでengine_versionに差分発生


    ● 差分状態でApplyするとダウングレード

    ○ ダウングレードはインスタンス削除 ->再作成

    ○ データ不整合で再作成に失敗 


    ● インスタンスが不在となり、障害。

    RDS障害
    22

    ※要検証ですが修正されている可能性あり
    概要

    View full-size slide

  22. 以下の設定を強制

    ● deletion_protection = true 

    ● ignore_changes = [engine_version]

    OPA導入契機
    RDS障害
    23

    対策

    View full-size slide

  23. OPA導入契機
    ● サービス基盤本部が全事業部のインフラコストを持って
    いる。


    ● 会社の成長と比例して部のコストが膨らんでいく。


    ● 事業部がどれだけインフラにコストを使っているかを把
    握できないため、コスト意識が薄れていく。

    インフラコスト
    24

    概要

    View full-size slide

  24. OPA導入契機
    AWS provider default_tags の設定を強制

    インフラコスト
    25

    対策

    View full-size slide

  25. 実行方法検討
    人間が確認するの!?
    26


    View full-size slide

  26. ツールの検討
    ● Terraformの書き方を制限したい

    ● 違反した状態でApplyを禁止したい

    ● ツールの運用をしたくない


    ツールの要件

    27


    View full-size slide

  27. ツールの検討
    TerraformCloud Policy の OPAにしました

    ● Terraform以外にも対象を広げることができる

    28


    View full-size slide

  28. 時系列
    2022/09
    RDS障害発生
    2021/?
    SG障害発生
    2022/10
    インフラコスト調査開始
    2022/10
    OPA導入決定
    29


    View full-size slide

  29. 時系列
    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


    View full-size slide

  30. 事象の共通項
    ?
    コスト 障害
    31


    View full-size slide

  31. 事象の共通項
    恐怖
    32


    View full-size slide

  32. 恐怖
    ● 削減の判断ができないコスト
    ● 深夜だからよかったものの、日中帯に起きていたら
    ...
    ● Platformの信頼性→サービスの信頼性→企業の評価
    33

    何を 恐怖 に感じていたのか

    View full-size slide

  33. 恐怖
    ● 削減の判断ができないコスト
    ● 深夜だからよかったものの、日中帯に起きていたら
    ...
    ● Platformの信頼性→サービスの信頼性→企業の評価
    34


    View full-size slide

  34. 恐怖
    恐怖 感じたことありませんか?
    35


    View full-size slide

  35. OPAを導入してみて
    36

    View full-size slide

  36. 導入してよかったと感じた点
    恐怖からの解放

    37


    View full-size slide

  37. 導入してよかったと感じた点
    よかった点
    ● policyを管理したいがためにTerraform versionを最
    新化できた
    ● これまで各人の知識に偏っていたレビューポイントが明
    確化された
    38


    View full-size slide

  38. ● 一時的なポリシー解除が難しい。

    ○ whitelist方式でリソース名を追記し、解除する方式を採用 

    ○ 本来の変更に加え、 whitelistの追加・削除の変更が必要で手間がかかる 

    ● OPA設定がコード化されておらず、Adminが更新する必要がある。

    ○ Terraform CloudではOPAの設定すらもコード化が可能。 (Policy as Code as Code)

    ○ issueとして積まれているので早めに対応したい 

    ● Policyに対するテストが組めていない

    ○ Policy自体のtestをCIに組み込むことでより良い Policyを維持する

    課題に感じている点
    39


    View full-size slide

  39. OPA導入の苦労した点①
    エラー表示が小さく、詳細な説明を残せない。

    40


    View full-size slide

  40. OPA導入の苦労した点①
    Policyに対してコードを発行し、別途用意するドキュメント誘導。

    エンジニアの理解度や納得度が向上

    Terraform Plan結果の画面がスッキリ

    ● Code
    ● Doc URL
    ● Resource name
    ● denyの理由
    ● denyの回避方法
    ● Policy設定の背景
    41


    View full-size slide

  41. OPA導入の苦労した点②
    Lifecycle ignore_changesに対するアプローチ

    「ignore_changesが設定されていること」
    42


    View full-size slide

  42. OPA導入の苦労した点②
    ignore_changesあり

    ignore_changesなし
    ignore_changesなし
    ignore_changesを扱う場合は、直接 before/afterを参照する

    43


    View full-size slide

  43. 我々のOPA導入のきっかけは「恐怖」。
    皆さんも少しでもTerraformの運用で恐怖を感じたことありませんか?
    ぜひ、Policy導入の検討を!
    まとめ
    45


    View full-size slide

  44. 今日の資料
    48


    View full-size slide

  45. 過去の発表や資料
    ● 「TerraformのCI/CD - monorepoとTerraform Cloud」

    ○ HashiTalk 2021

    ○ Makita Riki

    youtube SpeakerDeck
    49


    View full-size slide

  46. 過去の発表や資料
    ● 「組織と事業の急拡大に立ち向かうためのマルチテナントAmazon EKS クラスタ/マ
    ルチアカウントアーキテクチャ」

    ○ AWS Summit Online 2020

    ○ Ogasawara Junya

    SpeakerDeck
    50


    View full-size slide