サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<p>こんにちは。</p>

<blockquote>
<p><a href="https://qiita.com/advent-calendar/2021/dmm" target="_blank">DMMグループ Advent Calendar 2021</a>&nbsp;3日目はVPoEグループの飯田 涼太が担当します！</p>
</blockquote>

<p>趣旨を理解の上、お楽しみください。</p>

<h2>はじめに</h2>

<p>インフラ構成をコードで書く、いわゆるIaCもそう珍しいものではなくなったと感じています。</p>

<p>とくに私の周りでは、クラウドインフラの管理としてCloudFormationやterraformなどを利用しているケースをよく耳にするようになりました。</p>

<p>本記事では、すべてを闇雲にコード化するのではなく、運用を考慮して部分的にコード化するアプローチについて紹介していきます。</p>

<p>※terraform分は少なめで、どちらかというと設計めいた話であるのをご理解し、お読みください</p>

<h2>TL;DR;</h2>

<p>すべてをコード管理するのではなく、構成管理の要素が少ないものを意図的に外してみるアプローチも一考の価値がありそうなので、お試しいただきたいです。 たとえば、WAFとそれに利用するIPリストであれば、IPリストを作る部分はコード化しつつ、構成管理の要素が少ないリスト内容の更新は別管理にします。そうすると、「構成の更新」と「IPリストの更新」のそれぞれがバッティングしないため、運用懸念が減ります。</p>

<h2>やりがちなこと</h2>

<p>金槌を持つと出っ張りがすべて釘に見えるようなもので、なまじコードで表現できると手当たり次第コードで表現したくなりますよね。</p>

<p>ただ、これはこれで良い面もあり、100%な悪手ではないです。 すべてがそこに書かれているというのも、思った以上に安心感があります。</p>

<p>では、どういうときに困るのでしょうか。 具体的なケースについて紹介していきます。</p>

<h2>例　IPリストとアクセス制限の構成を管理する</h2>

<p>私が直近で対応した、AWS上に構築されたアプリケーションのアクセス制限の事例がまさにそれだったので、こちらを例に紹介します。</p>

<p>すでに構築済みのwebアプリケーション（ELB &rarr; ECS）に、IPリストで許可されたIPからのみ、アクセスを受け付ける（AWS WAFの導入）という事例です。</p>

<p>要件の概要は次の通りです。</p>

<ul>
	<li>環境ごとにアクセスできるIPリストは異なる</li>
	<li>既存クラウドインフラの構成管理に利用しているterraformに含めたい</li>
	<li>IPリストの更新は度々あり、要請があってからなるべく早めに適応したい</li>
</ul>

<p>新たに構成する必要があるリソースはこれらを想定しました。</p>

<ul>
	<li>適用したいルールセット（AWS WAFのWebACL）</li>
	<li>接続を許可するIPリスト（AWS WAFのIPSet）</li>
</ul>

<p><img alt="f:id:dmmadcale2021:20211125193056p:plain" height="401" src="https://image.dmm-corp.com/9dzvgnck0kc1rm6pus3br0e3pf1q" width="508" /></p>

<p style="text-align: center;">AWS WAFの追加イメージ</p>

<h3>作成・更新・削除、すべてをコードで管理する</h3>

<p>あちこち確認しなくても、すべてがここに書いてあるのは分かりやすいですね。 コードの該当部分を抜粋すると、こんなイメージです。</p>

<pre>
<code>##################################
# WAFV2 aws_wafv2_ip_set
##################################
resource "aws_wafv2_ip_set" "access_white_list" {
  name               = "${var.env}_access_white_list"
  description        = "IP white list for http access"
  scope              = "REGIONAL"
  ip_address_version = "IPV4"
  addresses          = []
}

##################################
# WAFV2 aws_wafv2_web_acl
##################################
resource "aws_wafv2_web_acl" "cf_web_acl" {
  depends_on = [aws_wafv2_ip_set.access_white_list]
  name        = "${var.env}_cf_web_acl"
  description = "web acl for private http access."
  scope       = "REGIONAL"

  default_action {
    block {}
  }

  rule {
    name     = "access_white_list"
    priority = 1

    action {
      allow {}
    }

    statement {
      ip_set_reference_statement {
        arn = aws_wafv2_ip_set.access_white_list.arn
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "${var.env}_web_acl_rule_watch"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "${var.env}_web_acl_watch"
      sampled_requests_enabled   = true
  }
}</code></pre>

<p>何か変更があれば、コードを変更して更新分を適用する運用となります。</p>

<p>しかし、私はこのやり方を採用しませんでした。</p>

<h3>なぜ全コード管理を選ばなかったのか</h3>

<p>その理由を説明します。</p>

<p>一見すると、すべて構成管理として一括りにできそうです。</p>

<p>アクセスできるIPリストは構成管理すべきだと考えましたが、その中身はどうでしょうか？ これは構成という観点には含まれない、と私は判断しました。</p>

<p>なぜならIPリストの中身がどれだけ変更されても、ルールセットとルールという構成自体に変化がないからです。</p>

<h3>2つの目的が混在している時に、懸念になりうること</h3>

<ul>
	<li>構成を管理したい（便宜的にAとする）</li>
	<li>IPリストを管理したい（便宜的にBとする）</li>
</ul>

<p>この2つのユースケースを1つのコードで表現していることが懸念として挙げられました。</p>

<p>実際の運用中を想像してみると、Aの変更とBの変更が同時期に提出されることがあり得ます。</p>

<p>Bだけ適用したい場合、工夫なしにAの変更を含めざるを得ないです（その逆もまた然り）。</p>

<h3>実際の解決策</h3>

<p>IPリストを作るところまでは、構成管理に含めましたが、リスト自体の更新は含めませんでした。（terraform上はIPSetのリソース定義のlifecycleにignore_changesを指定する）</p>

<p>私もこちらの方法を選択しました。</p>

<p>ただ、IPリストはコード管理していないかというと、そうではありません。</p>

<p>あくまで構成管理のterraformからは除外しましたが、IPリストの管理は別のコード管理としました。 ※本題からずれるため、こちらは割愛します</p>

<p>構成の更新とIPリストの更新を並行して行うこともできますし、terraformの知識がなくてもIPリストの更新ができるのは、運用として扱いやすい形に仕上げられたと感じています。</p>

<h2>おわりに</h2>

<p>本記事では、運用も見据えてterraformで作るけど、あえて更新を含めない選択肢について紹介をしました。解決したいことを見失わずに、上手に付き合っていく一助になれば幸いです。</p>

<p>明日の記事もお楽しみに。</p>


アドベントカレンダー2021

terraformでどこまでやる？運用を見据えた部分的な管理アプローチ

プラットフォーム開発本部

facebook

twitter

DMM TV

DMMブックス

DMM pictures

DMM GAMES

DMMオンクレ

DMMスクラッチ

DMMくじ

DMM Factory

DMM FILMS

ぷらさぷ ～＋SURPRISE～

DMMオンラインサロン

DMMいろいろレンタル

DMM DVD／CDレンタル

DMM通販

DMMオンラインクリニック

デジタルコミック事業

DMMチャットブースト

DMM英会話

DMM FX

DMMかりゆし水族館

ベルリング

ハッシャダイソーシャル

ヤンキーインターン

シント=トロイデンVV

DMM 地方創生

DMM.make 3Dプリント

DMM.make PRODUCTS

Seamoon Protcol by DMM Crypto

DMMバヌーシー

DMM EV ON

DMM WEBCAMP

DMMぱちタウン

DMM競輪

Waitinglist

Algoage

DMMポイントクラブ

社会課題

エンターテインメント

動画

電子書籍

アニメ

ゲーム

アプリゲーム

コミュニティ

オンラインサロン

PCゲーム

通販

オンラインイベント

ビジネスソリューション

教育

英会話

水族館

ハードウェア・プロダクト

救急車両

消防車両

モノづくり施設

サッカー

スポーツ

地方創生

VR体験

Web3

生成AI

研究開発

アプリ

ブロックチェーン

プラットフォーム

横断開発

社会インフラ

アミューズメント

ダイバーシティ

同人

サーバサイド

バックエンド

フロントエンド

ネットワーク

セキュリティ

ITインフラ

配信基盤

ペイメント

Android

データベース

ビッグデータ

データ分析

機械学習（ML）

MLOps

VR開発

フルスタック

プロトタイピング

グラフィックデザイン

イラスト作成

3DCG

モーショングラフィック

terraformでどこまでやる？運用を見据えた部分的な管理アプローチ

シェア

関連する記事