こんにちは、インターン生の南波です。SDBの日吉事業部では学生インターンを中心に、Linyではカバーしきれない個別案件や新規プロダクトの開発を行なっています。そこ結果、複数のプロダクトの本番運用を行っていますが、この記事ではどのようにAWSインフラを整備していったか、組織として何を考えて動いたかについてをご紹介します。
現状分析
自分がインフラチームを立ち上げた1年前は部署内にインフラを扱える人材が自分と部長の2人のみでした。当時は本番稼働している案件が2個しかなかったので部長と自分のみでインフラの管理は行えていましたが、今後本番運用の案件が増えるにつれて、運用コストが上がることは明白でした。また、先人の残したCloud Formationで最初のインフラ構築を行なっていましたが、1回構築した後はGUIからぽちぽちして構成することが多く、Infrasttucture as Code(IaC)として意味を成していない上に、Cloud Formationについての知見が少なく、中身を理解しているとは言えない状態でした。そのため、
- インフラ管理の見える化
- インフラ人材の育成と組織化
の2つが急務でした。
インフラ管理の見える化
Terraformへの移行
まずはIaCの整備から始めました。AWSのIaCツールとして有名なものにはCloud Formationの他にTerraformやCDKなどが存在します。どのツールにもメリットとデメリットが存在すると思いますが、他の部署の社員さんや自分がCloud FormationよりTerraformの知見があることを考慮し、Terraformを利用することにしました。既存リソースのimportのしやすさや後述するテンプレートを作成するためにmoduleや変数が扱いやすいというのも大きいです。
そこで、既存のインフラ管理をTerraformに移行/新規インフラのためのTerraform作成をすることにしました。
属人化排除→標準化
前述の通り、弊部署にはインフラ人材が足りていません。一方で案件数やプロダクト開発者は多く、検証環境を含めると日常茶飯事的に案件のデプロイが走っていました。誰でも簡単にインフラの構築ができるような仕組み(インフラチームへの属人化を排除した仕組み)を作ろうとしました。プロダクトはECSのサービス1つで運用できる規模のものがほとんどだったのでテンプレート化できると考え、簡単な環境変数設定とterraform applyのみでインフラを構築できるTerraformファイルのテンプレートを作ろうとしました。しかし、以下の問題点が出てきました。
- プロダクトごとに若干の構成の差異がある
ある程度の構成差異はフラグやパラメータで管理できるようにしています。例えば、
-
NATを用いるかどうか
-
S3やSES(メールサーバ)との接続のためのIAM
-
RDSかAuroraか
-
各インスタンスのスペックやパラメータ
しかし、Route53のレコードやS3バケットなどは既存リソースを利用することも多く、どうしても設定時にAWSの知識が必要になってしまうことがわかりました。
- シークレットをどう取り扱うか
Terraformでシークレットをどう取り扱うかは永遠の課題です。GitHubにシークレットを載せないのはもちろんのこと、tfstateに情報が残ってしまう以上、暗号化はもちろんのこと、S3に対するIAMを絞る必要があります。
DBパスワード作成を完全自動化することは不可能ではなさそうですが(参考)、ローテーションの無効化がTerraformからできないといった問題点があります。そこで、シークレットに関してだけは、AWSのSecret Managerに手動で入力し、arnを設定ファイルに入れるという運用をしています。
以上のように、AWSを知らない人がこのテンプレートを用いてterraform applyを実行するのはだいぶ無理があります。そこで属人化排除を諦め、インフラ人材を増やすことにしました。そしてこのテンプレートは"属人化排除"のためのテンプレートではなく、この組織における"標準"としてのテンプレートとして位置付けることにしました。ECSのサービス1つで運用できる規模のインフラであれば、プロダクトの特性に合わせて構成を変えることによるメリットより、複数種類の構成のインフラを見る運用コストの方が高くなります。
インフラに知見がある人が少ない組織だからこそ、デプロイ時に考えないといけない要素を減らし、またシークレットや環境変数の取り扱いを統一することでミスオペレーションを減らしています。
移行作業
Cloud Formation管理しているプロダクトをTerraform管理に移行する際は既存のリソースをimportするのではなく、Terraformで新しくリソースを作成し、DNSのルーティングを切り替えるという方式にしました。importの方がコストが少なく済むのですが、Cloud Formationでの構成を把握していない以上、importすると前述したテンプレートから乖離してしまう可能性があったため新たにリソースを作成することにしました。
データベースも本来ならimportをして、既存リソースを使い回すべきだったのですが、importを十分に検証する時間的猶予がなかったのと、ダウンタイムをとることが許されたので、新しくTerraformでインスタンスを作成し、dumpでデータを移行しました。
ダウンタイムは甘え、とはよく言いますが案件の発注者やSLOと相談してダウンタイムを取りつつ安全かつ複雑にならない方法をとるのも大切です。
組織にインフラ知識を浸透させる
デプロイの完全属人化排除が難しい以上、インフラ知見のある人材を増やす必要があります。そこで、既存のインターン生の中でインフラに興味のある人にハンズオンを実施したりインフラのタスクを渡すなどして、インフラ人材の育成を行いました。その結果、各プロダクトに専任のインフラエンジニアをつけることができ、自分が割と自由に動けるようになりました。
一言で運用と言っても様々な業務があります。最低限以下の2種類4業務があるでしょう。
- デプロイ:
- 構成変更
- CI/CD(アプリケーション)
- 監視:
- 監視基盤
- 監視業務
これらを一挙にインフラチームが行うのは負担ですし、CI/CD(アプリケーション)や監視業務などはプロダクト開発側が面倒を見ないと、インフラチームは各プロダクトのことを何も知らないので手出しできません。そこで、インフラ人材だけでなく、PM(弊部署ではPMも開発します)にもインフラ教育を実施することにしました。その結果PMが開発だけでなく運用も見ることができるようになりました。各プロダクトの週定例に参加し、運用定例(毎定例でログやメトリクスを必ず確認する)を行うように促しました。その結果、障害発生時や処理が重い時などはPMが進んでメトリクスやログを確認するようになりました。
(embedded SREのembeddingフェーズを意識して、enablementというワードを使いました)
インフラ教育を積極的に実施している理由には他にも、0->1でアプリケーションを作れる人材を増やしたいという側面もあります。インフラの知見は環境構築などにも役に立つので、0->1でプロダクトを作れる人になるためには必須です。フロント、バックエンド、インフラの全ての汎用的な知識を身につけ、爆速でPoCを作成できるような人材を育てどんどん案件を回していくのが弊部署の目標です。
定例会議で行なっていること
インフラチームの定例会議では各プロダクトの運用に関すること(例えばメトリクスやログの確認)については取り扱っていません。前述の通り各プロダクトの運用は各プロダクトが責任を持って行うことにしており、監視は各プロダクトチームが行なっています。弊チームはプラットフォームを持たないので、共通コンポーネントのようなものもなく、インフラチームが監視対象とするリソースはありません。
インフラチームは各プロダクト開発チームが回収できないようなインフラタスクは回収しています。
インフラチームの定例会議では各プロダクト担当のインフラエンジニアが各プロダクトのインフラの問題点を共有します。インフラチームはそれに対して解決策を考え、インフラチーム内で検証し、各プロダクトに還元します。
プロダクトチームが運用を見ることができるようになったからこそ、インフラチームはセキュリティや監視システムの改善などに重点をおいて活動できるようになりました。
今後の展望
moduleの活用
テンプレートは日々アップデートしていますが、デプロイのたびにテンプレートをコピーして
各プロダクトのレポジトリに配置している上に、moduleが活用されていません。そのため、テンプレートをアップデートしても昔デプロイした案件にそのアプデが反映されないという問題が起きています。moduleを整理し、各インフラ設定を最新のモジュールを参照する(要はテンプレートではなくmoduleとしての運用をする)ように整備していきたいです。
より安全な運用(Terraform CI/CDの整備)
現在はTerraformファイルをGitHubで管理していますが、手元でapply後にmergeしているので、GitOpsとはほど遠い状態です。またtfstateのコンフリが起こらないようにSlackで報告しないといけない仕組みになっていたり、Terraformの操作が面倒臭くGUIから設定を変更する人もいる状態です。今後は、より厳格なIaC管理を行なっていくために、TerraformのCI/CD整備を行なっていきたいです。
最後までお読みいただきありがとうございました。
Discussion