hikarun@技術猫

家に猫がいます。

試用期間中に会社の主力事業のAWS環境をゼロからTerraform化した


はじめに

これは KWC Advent Calendar 2022 の1日目の記事です。

こんにちは。KWCでSREを担当する、福岡県在住の@hikarun です。
2022年5月よりKWCに入社し、フルリモートで日々業務に邁進しております。
私がこれまで行ってきたAWS環境のTerraform化について、紹介させていただきます。

CPIとは*1

ビジネス向けレンタルサーバーサービスです。1997年に創業して以来、一貫してビジネス向けのサービスとして、企業のホームページ、サービスサイト、キャンペーンサイトなどを構築する際や、独自ドメインでのメール運用で、必要なインフラ部分であるサーバーを提供し続けており、業界でも20年以上続く老舗ブランドとして知られています。

CPIで利用しているクラウドサービス

オンプレミスで提供するCPIのサービスですが、バックオフィスシステムやマイクロサービスの一部はAWSやAzureを利用しています。
このクラウド環境についてTerraform*2化を行ってまいりました。

Terraform化するまでの険しい道程

1. 現状分析

入社後、今クラウドリソースがどのように用意され、誰が運用管理をしているのかを知る必要があったので社内で聞き込み調査を行いはじめました。

そこで見えてきたのが、以下の 3つの問題点 です。

  •  その1 どんなリソースがあるか分からない
  •  その2 誰が作ったのか・何が必要なのか分からない
  •  その3 全て手作業で構築運用が行われている

何もない所にやる気が出るタイプの筆者なので、クラウドリソースの可視化という目標に燃えました。

2. 問題解決開始

現状分析により浮き彫りとなった3つの問題を解決するため、クラウドリソースのTerraform化を始めることにしました。
これまでクラウドリソースの構築運用が全て手作業で行われていたので、もちろんTerraformの実行環境はありません。
自身の経験を元に、ゼロからのTerraform化の開始です。

Terraform実行環境の用意

大まかに以下の手順を行いました。

1. GitHubでTerraform用のリポジトリを新規作成

会社のGitHub運用ルールや命名規則に基づいて、リポジトリを作成します。

2. Terraformのディレクトリ構成検討

既存のリソースを、本番環境やステージング環境等ごとに比較したところ、全環境同じ設定で作られている事が分かりました。
そのため、モジュールを使ったコード管理を行うことに決めました。*3

イメージは以下の様な感じです。(便宜上簡略化しております。)

terraform
|─ cpi
   |─ modules
      |─ alb.tf
      |─ api-gateway.tf
      |─ cloudfront.tf
      |─ variables.tf
      ︙
   |─ prd
      |─ main.tf
      |─ variables.tf
      ︙
   |─ stg
︙ ︙ ︙
3. Terraformに必要なソースや設定、スクリプトの用意

Terraformの差分検知等はGitHub Actions側に仕込むのは当然の事ですが、ローカルPCでterraform planができると便利なので、そのための設定も用意しました。
Makefile等を用意するも良し、コマンドエイリアスで対応するも良し、お好きな方法で問題ないと思います。

4. GitHub ActionsでのCI/CDの構築

GitHub Actionsを用いて、CI/CDの構築も行いました。
持たせた機能は以下の通りです。

  • ・メインブランチに向けてPull Requestを作成
      > terraform planを実行Pull Requestにコメント投稿
  • ・リリースブランチにメインブランチをMerge
      > terraform applyを実行Pull Requestにコメント投稿
  • ・毎日朝9時にterraform planを実行
      > 差分があったらSlackに通知

Pull Requestへのコメント登録は以下のように行っています。

      # comment
      # メインブランチとの変更差分がない場合はskip
      - name: comment
        if: steps.diff.outputs.diff
        uses: actions/github-script@v6.1.0
        env:
          # terraform planの結果をPLANに格納して内容表示
          PLAN: "terraform¥n${{ steps.plan.outputs.stdout }}"
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `## \`${{ matrix.dir }}\`
            #### Terraform Plan 📖\`${{ steps.plan.outcome }}\`

            <details><summary>Show Plan</summary>

            \`\`\`${process.env.PLAN}\`\`\`

            </details>`;

            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })

実際の投稿はこんな感じになります。

3. 既存リソースのインポート作業

terraform import コマンドを利用して、既存リソースをインポートしていきます。
インポート対象ですが、ざっと計算して驚異の2500リソース超ありました…。

回り道はありません…
ひたすら terraform import を実行するのみです!

まとめ

Terraformの基盤をゼロから作り、主力事業のリソースをTerraform化するまでに掛かった日数…

_人人人人人人人人人人人_
> 176日!(5ヶ月と23日) <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄


無事、完遂することができました!
今後のクラウドリソースの構築運用が幾分楽になることでしょう。

おわりに

最後まで読んでいただきありがとうございます。
これからクラウドリソースの可視化をご検討されているSREやインフラ管理者の皆様の参考になれば幸いです。

KWC Advent Calendar 2022 はまだまだ続きます!明日の投稿もお楽しみに!

*1:サービス紹介- CPIより引用。

*2:詳細はTerraformをご覧ください。

*3:モジュールにリソースを定義することで、各環境でモジュールの読み込みを行うだけのシンプルな構成を実現できます。