🗒️

IaCを加速させるSandbox環境とそのコスト対策の工夫 | Resilire Tech Blog

2024/02/16に公開

Terraform

サプライチェーンマネジメント SaaS のSREエンジニア採用中です!

サプライチェーンリスク管理クラウドサービスResilireでテックリードをしている@teruhiky です。
Resilireでは主にBackend, Infra領域の実装をしながら、アーキテクチャやプロダクトロジックの設計・レビューを行なっております。

今日はInfra領域でResilireが行なっているTerraformによるInfrastructure as Code(IaC)を推進するための取り組みを紹介させていただきます。
IaCそのものについてはAWSのドキュメントなどをご覧ください。

プロダクト概要とインフラ戦略

まず、なぜインフラをTerraformでコード管理することを重要視しているのかについて、プロダクト概要を紹介させていただきつつ説明できればと思います。

サプライチェーンの複雑性とリスク管理

Resilireは、物理的なグローバルサプライチェーンを対象に、原料調達、製造、輸送で災害リスク影響の早期検知と対応促進を行なっております。

車やスマートフォンなど高度に発達した現代の製品を製造するためのサプライチェーンは、広くグローバルに繋がり合い、また関わる会社の数も膨れ上がっております。
その中で地震などの様々な自然災害だけでなく、工場の爆発のような人災までを踏まえながら持続的にサプライチェーンを維持していくためには、サプライチェーンの見える化を行い早期検知に繋げていく必要があります。

Resilireではそんなプロダクトの非常時を支えるインフラとしてプロダクトを作っております。

BCP設計と東京・大阪でのリソース配備

このプロダクトを支えるためには、通常のDev環境やテスト環境のような本番同様の環境を複数用意するだけでなく、以下の図で示すように東京で大きな災害があってもResilireのプロダクトは動き続けるようBCP（事業継続計画・Business Continuity Plan）を意識しておく必要があります。
そのため、インフラのリソースを東京と同様の設定で大阪にも作る必要があり、手作業による環境整備よりも設定の同一性を管理しやすくするためにIaCが必要不可欠となっております。

グローバル展開を見据えたBCP設計

IaCを進める上での悩みを解決するSandbox環境

Terraformによるインフラのコード化を進める時に難しいのは、実際にインフラリソースを作ってみないと分からない部分があるのにいきなりコード化するのは難しいということです。

Terraformのドキュメントには使用可能なフィールドやその用途などの記載がありますが、実際には文字数バリデーションや他フィールドとの依存関係などGCP上で設定してみないと分からない部分も多々あります。

コード管理なしで自由に設定を試せる環境の必要性

私自身はResilireでの経験とは別ですが、過去の案件でGoogle Interconnectの設定について、実際に設定してみないとわからないところが多く困った経験があります。

そんな場合に、GCP上でコード管理せずに自由に設定を試せるSandbox環境を用意できれば、使用感まで把握してからコードに落とし込めるのでスムーズなTerraform実装とレビューのサイクルが回ると考えました。

Sandbox環境を綺麗に保つ自動化とコスト管理の必要性

Sandbox環境を実際に運用し始める場合にマネジメント側でネックになると予想されたのがコストです。

リソース削除を確実にするためのセーフガード

Sandbox環境では、自由にリソース作成できるようにすると同時に、取り決めとして必要なくなったリソースは随時削除してもらうようにしています。
ただし、GCP上で削除操作をしても付随的に作成されてしまったリソースなどは、どうしても気付かず残ってしまうというようなことがあるかと思います。
そういったコストが積み重なって恒常的に意図しないコストがかかり続けないようにするためのセーフガード的な取り組みが必要と考えました。

GitHub Actionsを利用した自動化の具体例

上記を踏まえまして、以下のようなCronジョブで自動実行されるGitHub Actionsを作成しました。

Sandbox環境はTerraformにて”resilire-sandbox-2024-pj”のように年度を含めた形でSandbox環境用にProjectを作成しています。
以下のGitHub Actionsでは毎年元日に自動でTerraformの変数定義の年度数字を置換してプルリクを作るようにしています。

name: Auto-Create Pull Request by Cron Job

on:
  workflow_dispatch: # this is for debugging
  schedule:
    # 毎年1/1 10:00に自動実行
    - cron: '0 1 1 1 *'

jobs:
  cron-pull-request:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Get current year
        id: date
        run: |
          echo "year=$(date +'%Y')" >> $GITHUB_OUTPUT
          echo "last_year=$(( $(date +'%Y') - 1 ))" >> $GITHUB_OUTPUT

      - name: Override TFVAR files
        run: |
          sed -i -e "s/\(CURRENT_YEAR *= *\)${{ steps.date.outputs.last_year }}/\1${{ steps.date.outputs.year }}/g" terraform/gcp/admin/_env_tfvars/admin.tfvars
          rm -f terraform/gcp/admin/_env_tfvars/admin.tfvars-e

      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v4
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          commit-message: "Automatically committed by a cron/dispatch job"
          branch: chore/auto_cron_pr
          delete-branch: true
          title: "Auto-generated pull request triggered by Cron Job"
          draft: false
          body: |
            # OVERVIEW / 概要

            **WHAT**:
            - create a new PR by cron job

            **WHY**:
            - GCP sandbox project needs to be renewed

このGitHub Actionsで作成されたプルリクをマージすることで過去年度のSandbox環境は廃棄されて完全に新しいSandbox環境を用意できます。
現状はありがたいことに各自リソースをしっかりと削除してくださっており環境の刷新は1年周期で行っています。今後は状況を見ながら頻度を上げていく場合もこのCron設定を更新することで柔軟に対応していく予定です。

今回割愛したこと

今回はSandboxでのIaCの推進に注目するために、”Sandbox環境には誰が触れるのか”、”その権限管理はどうやっている？”といった部分は割愛させていただきました。

Resilireでは権限管理も運用に無理がない範囲内である程度粒度を粗くしながらもコード管理を行なっております。そういったところの取り組みはまた別の記事で紹介させていただければと思います。

エンジニア採用強化中

株式会社 Resilire (レジリア) では、サプライチェーンリスク管理クラウドサービスResilireの開発メンバーを募集中です。

まずは情報交換程度に気軽に話して聞いてみたいという方もウェルカムです！