この記事は 株式会社TRAILBLAZER Advent Calendar 2024 の5日目の記事です。
はじめに
はじめまして！9月にインフラエンジニアとしてTRAILBLAZERに入社した高野です。現在は、社内のエンジニアやデータサイエンティストにむけたR&D用途のAWS環境の構築を進めてます。
今回は「創業間もない会社でゼロからインフラ環境を構築する面白さ」について、皆さんにお話ししたいと思います。
目次
前置き
複数のSIer企業でインフラエンジニアとして働いてきました。
当時は、AWSなどの開発・運用環境は社内の別部門がセットアップし、私たちはその環境をそのまま使う形でした。
しかし今の環境では、すべてを自分たちでゼロから整えなければなりません。初めて自分でAWS環境の初期セットアップから関わることができて、前職では味わえなかった貴重な機会を楽しんでいます。創業間もない企業だからこその貴重な経験だと思います。
ゼロからインフラを作る経験を通じて感じた「面白さ」や「難しさ」を、この記事でぜひ共有できればと思います！
ゼロからインフラを作るって、どんな感じ？
SIer時代には、提供された環境を使って開発や運用を行うことが主でした。例えば、AWSのアカウントやセキュリティ設定、ユーザー管理、ネットワーク構成などがすでに整っており、私たちエンジニアはその上でインフラ構築やアプリケーションの開発に集中できました。
しかし、今は違います。AWSの環境そのものの事前セットアップから設計・構築していくわけです。
正直、最初は戸惑うことも多かったですが、その分、自由に設計できる楽しさを味わっています。
具体的にどんなことをやっているのか、いくつか紹介します！
AWS Organizationsでのアカウント/組織単位(Organization Unit:OU)の設計
将来的な利用用途を想像しながら、AWSルートアカウント配下の組織構造やアカウントの管理方針を設計します。
セキュリティやガバナンスの設定はOU単位で行うため、将来の用途を見越して組織構造を設計できるかが、長期的な目線での運用性を左右します。
OU設計やSecurity Control Policy(SCP)の設計と実装は、事前セットアップの段階でないと関与する機会がなく、これらを自分で設計できるのは、本当に貴重な経験だと思います。（セットアップ済み環境を利用する側はむしろ権限上、これらの設定は「見られない/触れない」状態になっていることが多いですよね。）
AWS Control Towerでのセキュリティ・ガバナンスの強化
セキュリティとコンプライアンスを強化するために、Control Towerを活用して、マルチアカウント環境を一元管理する設計を行っています。AWSを安全に利用するためには、Control Towerを使用して組織全体のセキュリティポリシーやベストプラクティスに準拠することが重要です。とはいえ、R&D用途で利用する環境のため、セキュリティレベルをガチガチに高めてしまうと、アジリティの低下というデメリットがあるため、セキュリティとのトレードオフを考慮しながら設計を進める必要がありました。バランスを取りながら設計するのは難しかったですが、それもまた面白さの一つでした。
AWS Identity Centerでのユーザー管理
Identity Centerを用いて、マルチアカウントでのAWS利用ユーザーを一元管理しています。
具体的には、社内ですでに利用しているIdpを認証基盤としつつ、認可の機能をIdentity Centerで実現させています。認証・認可それぞれ複数の方式パターンを比較検討しましたが、将来的にマルチクラウド構成を採用する可能性を見越し、認証に関してはAWSで持たずIdpにて実現する方式を採用しました。
このように、拡張性を考えた認証認可の設計も、面白く貴重な学びでした。
運用性の高いIaCコードの作成
上述した設定はすべてterraformを使って実装・管理しています。
現段階ではインフラエンジニアである私が管理していますが、将来的には社内システム担当者による運用も想定されるため、IaCでの運用性を高めることも重要な設計要素のひとつです。
意識した点としては、第三者がコード内容の全容を理解せずともユーザーの追加やSCPの修正運用をできるように、直観的に更新可能な変数ファイル(.tfvars)となるよう記述の構造を工夫しました。
コードの具体例は以下の通りです。
groups = {
"system_admin" = {
description = "system admin group"
account_id = [
"123456789012",
"234567890123",
"345678901234"
]
permission_set_name = [
"AdministratorAccess",
"ReadOnlyAccess"
]
},
"audit" = {
description = "audit group"
account_id = [
"345678901234"
]
permission_set_name = [
"ReadOnlyAccess"
]
}
}
users = {
"user1@example.com" = {
display_name = "user1"
last_name = "User"
first_name = "One"
assigned_groups = [
"system_admin"
]
},
"user2@example.com" = {
display_name = "user2"
last_name = "User"
first_name = "Two"
assigned_groups = [
"audit"
]
}
}
AWSアカウントが追加されたり、ユーザーが追加・削除された場合も、上記の変数ファイルの必要箇所に情報を追加するだけで、.tfファイル側は意識しなくてもよい構造となってます。
エンジニア主体で管理するリソースの場合は、.tfvarsよりリソース定義ファイル(.tf)の可読性に重きを置いてコーディングしていましたが、今回は社内システム担当者による運用を見越して、.tfvarsの可読性により重点を置いてます。
現在取り組んでいること＆これからのチャレンジ
現在、Github Actionsを利用したCICDのワークフロー構築を実施しています。
当面はTerraformコードをデプロイするために利用しますが、将来的には以下のような仕組みも実装したいと考えてます。
- Idp側のユーザー追加や削除をトリガーに、自動更新された
.tfvarsファイルでのデプロイが走り、AWS側に自動的にユーザー増減が反映される仕組み - AWSアカウントの新規発行/削除依頼リクエストをトリガーに、AFT(Account Factory for Terraform)にてAWSアカウントを自動発行/削除する仕組み
実現できた際には、改めて記事にしたいと思いますので、ぜひ楽しみにしていてください！
最後に
ゼロからインフラ環境を整えていくというのは、昨今のクラウド時代において非常にまれな経験ではないかと思います。このような経験を積むことができるのも、創業したての会社だからこその醍醐味ではないでしょうか。
今回はAWS環境の構築にフォーカスした記事となりましたが、他にも随所で新しい会社ならではの新鮮な面白みを感じる機会があると思います。この記事を読んで、少しでも弊社での仕事に興味を持っていただけたら嬉しいです。