[登壇レポート] AWS Service CatalogのTerraform Reference Engineを検証している話をしました #tora_tech
あしざわです。
先日開催された Toranomon Tech Hub 第一回 -好きなクラウドサービス紹介 LT大会-にて、『AWS Control Tower歴2年で初めてService Catalogと向き合ってみた』というタイトルで10分枠でLTをする機会がありました。
本ブログでは、当日お話しした内容をレポートします。
LT資料
LT概要
今回のLTでは、社内の部活動的な取り組みの中で検証しているシステムにてAWS Service Catalogを利用したアーキテクチャを検討しており、そのシステムにまつわる話をさせていただきました。
これまでの個人的なAWS Service Catalogの印象は「Control Towerの裏で動いている、とっつきにくく難しいサービス」でした。
改めて概要の把握から始めてみてわかったのですが、Service Catalogには独自の用語があり、まずそこから覚えておいた方が良さそうです。
具体的には、以下の図の「製品」「制約」「ポートフォリオ」です。他のサービスではあまり出てこないものですが、「これはこういうものなのだ」とざっくり理解しました。
その他Service Catalogについては、こちらのブログでインプットしました。
そして今回の本題にあたるアーキテクチャに関する話に移ります。
私は最近、以下のアーキテクチャでいう「何か」に当てはまるものを探していました。特別な要件は特になく、できればコストが安くて、維持管理コストが少ない方がいい程度です。
「何か」に当てはまる候補がこちらです。
- AFT (Account Factory for Terraform)
- CloudFormation StackSets
- Service Catalog (Terraform)
この中から『Service Catalog (Terraform) 』を選択し、検証を進めています。
この方法に決めた理由は、消去法で残ったからです。
『AFT (Account Factory for Terraform) 』が合わないと感じた理由は、アカウント払い出し機能が要件的に過剰である点、インフラ維持コストが気になった点でした。AFTのアーキテクチャについてはこちらのブログがわかりやすかったです。
『CloudFormation StackSets』を外した理由は、要件としてはあっていたがCloudFormationテンプレートを半ば強引に(?)Terraformの中で表現することになるように見えたため、いけてない構成なのではと感じたからです。
最終的に残った『Service Catalog (Terraform) 』も必ずいけるという確証はなく、とりあえずこれで進めてみよう、くらいの温度感でした。
Service CatalogでTerraformコードを実行するには『Terraform Reference Engine』の利用が前提になります。
やることは、このGitHubリポジトリのデプロイです。
GitHubのREADMEを見ても良いのですが、こちらのブログに倣って行えば基本的にOKでした。
注意点は1点だけで、製品登録時の製品タイプを「外部」に変える必要ありました。ブログで紹介されている「Terraform のオープンソース」は諸事情あり廃止になったようです。
そのまま製品の起動までうまくできたのですが、1点比較的大きなBadポイントが見つかりました。
それはAFT同様、インフラリソースの維持管理コストが発生する点です。NAT Gateway2つを維持し続けるのはかなり厳しいなと思いました。
というところで、急ですが今回の内容は終了です。直近の出来事かつ未解決の事項でしたのでこのような形になっています。
まだまだ課題が残っていますが、より良いアーキテクチャを追い求めながら引き続き検証していきたいと思います。
さいごに
Toranomon Tech Hubにて行ったLTの内容について紹介しました。
イベント後の懇親会にて、Terraform Reference Engineのコスト削減ができるデプロイオプションがあるという情報をいただきました。それを知ることができただけでも登壇して良かったなと思います。
後日、GitHubのISSUEを確認したところ、以下のような記述があったのでできそうです。やり方はこれから調べてみようと思います。
The default deployment uses 3 AZs and 1 EC2 instance, but these can be customized.
以上です。