この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
prismatix事業部の中山です
先日、久しぶりに登壇しました。
詰め込みすぎて時間がなくて細かい点を説明できなかったので、ここで少し解説したいと思います。
【4/11（火）東京】新オフィス初イベント「DevelopersIO Day One」開催！ #devio_day1 | DevelopersIO
資料
解説
prismatixの特徴
「EC / CRM特化型プラットフォーム」であるprismatix自体の機能はサービスサイトをご覧いただきたいのですが、インフラに影響する以下の様な特徴があります。
- 注⽂や決済といった各機能のまとまりをマイクロサービス化 / APIとして提供
- 顧客毎に専用の環境を提供（シングルテナント）
これにより、管理対象が以下の様になります。
- 顧客毎に異なるバージョンを利用かつ必要な機能（マイクロサービス）だけをデプロイするため、構成パターンが非常に多い
- AWSアカウントが多い
- 顧客数×環境数（本番 / ステージング / 開発 / 他）
- 現在、100以上のAWSアカウントを運用・管理
このため、IaCのようなソリューションは必須で、それだけではなくより安全かつ効率的なオペレーションを実現する必要があります。 また、DatadogのようなAWS以外のサービスも利用しているのでTerraformがとてもマッチしていると感じています。
なぜAtlantisを利用するのか
AtlantisはTerraformの各種オペレーションを自動化してくれるツールです。
prismatixでは、以下の様に安全かつ効率的なオペレーションを実現しています（私が異動してきたときには既に運用されていましたが、導入してくれた方には感謝しかないです）。
- GitHubと連携して、自動plan / Apply前のレピューを必須化 / コメントによるApply
- 複数環境を単一のAtlantisで管理（Stateも集約）
Atlantisについては少し古いですが紹介ブログもあるので参考にしてみてください。
TerraformをPull Request上のコマンドで実行！Atlantisを試してみた | DevelopersIO
ちなみに、Fargate上でAtlantisを動作させるモジュールもあるので、これを利用すればすぐ構築できます。
ただ、ストレージにEFSを利用するオプションが有効な状態だとうまく動かないバグがあるっぽい（デモ環境の用意で実際にハマった）ので、その際には enable_ephemeral_storage を有効にしてみてください。
prismatixの課題（インフラ的な意味で）と現在の取り組み
今回のプレゼンテーション内では触れませんでしたが、prismatixのインフラには大きな課題があります。
事業が2016年からスタートしたということもあり、事業の成長と共に機能追加やアーキテクチャの改善が行われ、その過程で環境の構築および運用手順が複雑化しているというものです。 私が異動したのはちょうど1年前ですが、あまりの複雑さに正直頭を抱えました。
具体的には、Cloudformation（と独自のGradle plugin）、Python/Ruby/Go/Shell Scriptで実装された様々な独自ツール、Terraformを併用している状態です。 もちろん、最初からこうだったわけではなく、時間と共に増えていったのだと思います。
そこで、SREチームではこれをTerraformに全面的に集約する作業を進めています。 現時点でTerraform moduleの実装はほぼ完了しており、一部の環境で試験的に利用を開始しています。 展開できる品質である事を確認でき次第、既存環境のImportの作業を進めていく計画です。 これが完了すると、Terraformと多少のPython/ShellScriptのツールで環境構築や運用作業ができるようになる見込みです。 ちなみに、Terraformの管理外になるのはデータベース（ユーザー管理やマイグレーション）およびElasticsearchなどです。
このTerraform moduleの開発を進めるにあたり、開発・保守の効率化と品質の維持を意図して以下のツールをGitHub Actionsを通して利用し始めています。
- tflint
- Trivy
- terraform-docs
tflintに期待すること
tflintを利用する事で非推奨の構文や未使用の変数定義を検出する事ができます。 以下の例では、非推奨の構文と未使用のdataが検出されています。
Run tflint -f compact --chdir module --module
tflint -f compact --chdir module --module
shell: /usr/bin/bash -e {0}
2 issue(s) found:
Warning: module/main.tf:27:12: Warning - Interpolation-only expressions are deprecated in Terraform v0.12.14 (terraform_deprecated_interpolation)
Warning: module/main.tf:18:1: Warning - data "aws_caller_identity" "current" is declared but not used (terraform_unused_declarations)
Error: Process completed with exit code 2.私が異動してきた時点でTerraformのバージョンが揃っていなかった（0.12から1.2が混在）ので、1.3に揃えるバージョンアップ作業を行ったのですが、その際に多くの非推奨の構文を修正する対応を実施しました。 tflintのようなツールで恒常的にテストを行えば、バージョンアップ時の工数も抑えることができるのではないと思います。
また、Terraform moduleの実装にあたっては既存のCloudFormationテンプレートを基本的にはそのまま移行したのですが未使用の変数がいくつかあり、tflintでこれらの検出がすぐに行えました。 保守するにあたってシンプルな状態を維持することはあらゆる面で重要ですので、引き続き利用していく予定です。
Trivyに期待すること
Trivyを利用する事で、Terraformで定義したリソースのセキュリティリスクを検出できます。
AWSのサービス・リソースの種類は多岐にわたり、それらの設定項目全てを把握・理解することは困難で、完全な知識をレビュアーに求めるのは無理があります。 検出されたリスクに対応する必要があるかはケースバイケースですが、リスクの存在を認識でいるという意味でこういったテストはとても重要だと考えます。
同様のツールとしてtfsecも有名ですが、Aqua SecurityとしてはTrivyに注力していく方針のようなので、利用中の方は移行を検討いただくとよさそうです。
terraform-docsに期待すること
terraform-docsは、Terraformで作成したリソース・入力・出力等をまとめたドキュメントを生成できます。
モジュールが巨大化した場合、ドキュメントを人力で作成することは現実的ではありません。 なので、このようなツールの活用は必須だと思います。
ちなみに、Terraform moduleの規模がそれなり大きい場合、リソース・入力・出力の命名規則がてきとうだと非常に読みにくくなると思いますので注意した方が良いと思います。 また、tflintで未使用の入力を検出して削除することで少しでもシンプルな状態にすることも重要だと思います。
まとめ
今回のイベントでは、prismatixにおけるTerraform活用について紹介しました。
いろいろ取り組んではいますが、まだまだやらないといけないことも多い状況です。 とは言っても時間は有限なので、現実的な範疇で（保守できる・引き継げる範囲で）インフラのコード化や自動化を進めつつ、改善を図っていこうと思います。
4
