はじめに
はじめまして！SRE (Service Reliability Engineering) 部の村上です。好きな技術はTerraformです！！
Terraform、めっちゃ好きなんですよね。
私がTerraformを初めて使ったのが2019年頃で、それ以来とても愛着があるツールでして。
クラウドインフラを少人数で安定的に捌くためには必須なツールだと思っておりますし、チームで利用しても便利なツールだと思っております。
ということで、私の最初の記事はTerraformをピックアップさせていただきました！
全2回の予定で、Terraformの話にお付き合いいただければと思います！
Advertising-Flowとは
本題に入る前に、私が携わらせていただいているAdvertising-Flow（https://advertising-flow.com/）について簡単に紹介させてください。
Advertising-Flow（以下A-Flowと呼びます）は、プロダクト開発センターで開発されているサービスであり、複数媒体の多様な広告をAIの力で一元管理する広告運用ツールです。
GoogleやYahoo等の様々な媒体が存在するweb広告を一元管理できる他、独自アルゴリズムの「Sophia AI」を活用し、予算を消化しながら広告効果を最大化するように自動で広告運用を実施できます。
また、スケジュールを設定したり予算消化率に対して閾値を設定したりすることで、広告を自動的に停止させるといったこともできます。
これは、web広告の運用の手間を削減することに寄与し、広告に携わる人達がよりクリエイティブなタスクにリソースを割けるようにするものです。
A-Flowの構成と、リアーキテクチャ
A-Flowは、ユーザが操作するためのGUI用サブシステムと、GUIから操作された設定を元に広告の運用を行うワークフロー用サブシステムを持ちます。
実は、現在のA-Flowは2代目であると言えます。
以前は、共通のAWSアカウント上に手動設定によって構築されており、ワークフロー用サブシステムはsidekiqが採用されていました。
しかし、よりスケールし、よりセキュアにシステムを構築する必要性が生まれてきました。
そこで、A−Flow全体を違うAWSアカウントに切り出し、ワークフロー用サブシステムをメッセージングを利用した分散システムとするように改修を行うことになり、私はこの改修版のインフラ構築を担当することになりました。
インフラ構築を行う中で考えたことは様々ありますが、特に重要だった項目の1つが「いかにヒューマンエラーや、実装の手間を減らすか」という点でした。
人員や工数には限りがありました。
もしAWSリソースの設計をスプレッドシートで行い、それらを手作業で設定したらそれだけで時間が過ぎてしまうし、今後の変更も手間である。
更にヒューマンエラーも発生する可能性が格段に上がり運用ができなくなる。
これらの問題を解消する上で鍵となるのがTerraformです。
Terraformとは
Terraformとは、インフラストラクチャをコード（Infrastructure as Code、IaC）として管理するためのツールです。
簡単に言うと、サーバーやネットワーク、データベースなど、クラウド上のインフラの設定をコードで書いて管理できるようにするものです。
例えば、普段AWSの設定をするにあたって、管理画面を開いて手動で作業を行っている方もいらっしゃるかと思います。
しかし、Terraformでは設定ファイルとして記述し実行することで、必要なインフラを自動的に構築・変更・削除できます。
Terraformを使えば、手作業のミスを減らし、インフラ管理を効率化できます。
コードベースでのやり取りができるため、GitHub等を利用してチーム開発や履歴管理が可能です。
このタイミングでのTerraform投入の理由
実は、リアーキテクチャ以前は、Terraform等のIaCは特に整備されていませんでした。
リアーキテクチャという大規模改修において、構成が大規模に変化する中でA-Flowにとって新規技術であるTerraformをあえて投入した理由はなんでしょうか？
これは、私がTerraformを得意技術としており、且つこれの有用性を即座に証明し展開できたからでした。
Terraformを使えば、命名や構成について秩序立てて実装ができる、そのためのアイディアが私にある。
Terraformを使えば、知らないAWSサービスであってもサンプルコードを拾ってきて検証ができ、更にそのサンプルコードを適宜改修すれば本番に持ち込める。
Terraformを使えば、CI/CDを構築し手作業とそれに伴う心理的ストレスや工数を大幅に削減できる。
このように伝えて、幾許かの工数をいただき技術的な証明をしました。
その結果、現場投入に足りるという判断をいただき、Terraformが採用されることになりました。
リアーキテクチャで最初にやったことその1: CI/CDの実装
このリアーキテクチャの取り組みに際して、まずやったことが2点あります。 それは、「CI/CDの実装」と「ディレクトリ構成の決定」です。
本記事では「CI/CDの実装」まで説明させていただければと思っております。
ところでCI/CDとはなんでしょうか？
CIとは
CIとは、Continuous Integration（継続的インテグレーション）の略で、今回はざっくりと「自動テストの仕組み」位に捉えていただければと思います。
これがあると、例えばPull Requestを出したときに文法エラーやtypo等があったときにエラーを出すようにすることができ、Review前に単純な修正ができます。
あるいは、Terraformを実行したときの実行計画をGitHubのコメントに自動で投稿されるように設定することで、Terraformの記述の妥当性を確認することができます。
これらによって、バグを早く発見できて、開発のスピードが上がります。
CDとは
CDとは、Continuous Delivery（継続的デリバリー）、もしくはContinuous Deployment（継続的デプロイ）の略で、やはり今回はざっくり「Pull Requestがmergeされたら自動で環境に適用される仕組み」位に捉えていただければと思います。
これがあると、例えばPull Requestがmergeされた後に手動でTerraformのコマンドを都度実行するといったことをせずに済みます。
例えば、Production環境やStaging環境などが存在したときに、production branch へのPull Requestがmergeされたときは、Production環境にその変更が自動で適用されるといったようなことができます。
CI/CDの実装を最初にやった理由
これらは、手間を削減するために重要な施策ということは同意いただけると思いますが、一番最初にやるべきことだったかについて疑問を持たれる方がいらっしゃるかもしれません。
なぜこれらを最初に実装したか、それは「導入が早ければ早いほどその恩恵を受けられるから」です。
「この程度の変更だったら大丈夫だろう」と思ってテストを行わずにPull Requestを作成し、そういったPull Requestをいくつかまとめてmergeし、いざコマンドを実行しようとしたらコマンドが謎に通らない、原因がすぐに分からない…といった経験はないでしょうか？私は当然あります。
しかし、少ない工数の中で完遂するためには、こういった無用なトラブルに付き合ってる余裕はありません。こういった事象への対処は非常に心理的ストレスになりますし、勿論工数も消費されます。
結果、更にバグを作り出す可能性が上がり、最悪の場合収拾がつかなくなります。これではプロジェクトの完遂が困難になってしまいます。
CI/CDは、こういったトラブルを抑制する効果があり、結果的に（極僅かかもしれませんが）余裕を生み出すことができます。
期間が短いとはいえ、しかし数ヶ月単位で遂行されるプロジェクトにおいては、自分自身の、そしてチームの余裕を少しでも確保することはプロジェクトの成功のために必要なことであり、それを生み出すためにCI/CDは絶対に必要でした。
また、Terraformは前述の通りコードベースで設定を記述するツールであるため、CI/CDとの親和性が極めて高く、比較的容易にCI/CDを実装することができたのも重要です。 TerraformなどのIaCツールを利用していなければまず有り得ない世界線です。
これらの結果、リアーキテクチャの遂行中は期待通りその恩恵に与ることができ、現在に至るまでその恩恵を受けられていると感じています。
実は、最初は記事を分けるつもりはなかったのですが、筆が乗ってかなりボリューミーになってしまいました、、
というわけで続きは次回！引き続きよろしくお願いします。