インフラ構築を完全に自動化してみる

はじめに

本業ではGo,Laravelでバックエンド開発したり、ECS,CDKを使ってDevOps周りを整えようと頑張ったりしてます。
今回はアプリケーションチームがインフラチームにインフラ構築依頼を出さなくても自律して環境構築ができるようにBackstageを利用するプランを考えて実装をしてみました。

対象読者

• プラットフォームエンジニアリングに興味がある方

目次

• 解決したい課題
• 参考書籍
• 採用技術
• 解決策
• 解決できた課題
• 解決できていない課題とその解決策
• 感じたこと

解決したい課題

インフラ構築にかかるコストが大きい

見積もりよりもインフラ構築にかかるコストが大きくなっていました。CDKによるインフラのコード化は行なっていますが、必要な情報を揃えるまでに時間がかかっています。その原因としては以下の２つが考えられました。

• アプリケーション担当者とインフラ担当者の間でのコミュニケーションコスト
  • お互いがお互いの作業完了を待ってしまう
• 責任範囲をどう区切るかが難しいこと（Dockerfile,log出力,環境変数ファイルの編集）
  • インフラ担当者がアプリケーションを構築する場合、アプリケーションの理解が必要
  • アプリケーション担当者がDockerfileを作成しようとすると、技術的な難しさがあることも多い

参考書籍

「LeanとDevOpsの科学」

この読んで、デリバリーのパフォーマンスの重要性を再認識しました。
特に重要だと思った部分としては

 - デプロイ頻度
 - コミットから本番デプロイまでの時間
 - 障害復旧時間
 - 変更失敗率

の４つが

 - 収益性
 - 市場占有率
 - 生産性

と明らかな相関関係があるというところでした。デプロイ頻度が多く、コミットから本番デプロイまでの時間が短いほど、ビジネス的にも大きな価値を生み出しているようです。
さらに、

 - デプロイ頻度
 - コミットから本番デプロイまでの時間
 - 障害復旧時間
 - 変更失敗率

の４つのパフォーマンスが良い組織では

 - テストの自動化
 - テストデータの管理
 - デプロイの自動化
 - トランクベースの開発
 - 情報セキュリティのシフトレフト
 - 疎結合のアーキテクチャ
 - バージョン管理
 - 監視
 - プロアクティブな通知

などを採用している割合が多いとのことでした。

「チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計」

特に重要だと感じた部分は

• コンウェイの法則
  • システムを設計する組織は、その組織のコミュニケーション構造をコピーした構造の設計を作り出す
  • 逆コンウェイ戦略：採用したいアーキテクチャに合わせてコミュニケーション構造をデザインする
• チームファースト
  • ベストなやり方→チームに仕事が流れる状態
  • チーム対個人→チームのパフォーマンスが勝つ
  • チーム同士の連携方法が重要→高凝集、疎結合を達成できるように
• ４つのチーム
• ３つのインタラクションモード

の４つです。

実装内容

概要

Backstageで.envやビルドする際のパス、アプリケーションの名前などの情報を入力するとそのサービスが起動できるようにしました。

採用技術

• Backstage
• CDK python
• Github Actions
• AWS

概要図

短期的にできるようにしたいこと

• 指定できるAWSリソースの追加
  • Redis
  • メールサーバー
  • HTTPS対応
  • ドメイン自動取得

中長期的にできるようにしたいこと

• プロジェクトのテンプレート追加
  • huskyの設定
  • prettier,eslintの設定
  • dockerfile,docker-compose.yaml
  • 各ライブラリ、言語などのバージョン指定
• セキュリティテスト
• 負荷テスト

実装によって達成できそうなこと

• インフラ構築の効率化・自動化
• 責任範囲の明確化
• インフラチームとアプリケーションチームとの疎結合化→お互いに作業の完了を待つ必要がなくなる
  

副作用的に達成できそうなこと

• 環境変数のバージョン管理
  • S3で環境変数を管理することが強制されたことでバージョン管理できるようになりました
• 監視
  • github actionsによりCDKが実行されることでインフラ構築のログ監視が可能になりました。
    

解決できない課題

• アプリケーションチームの技術習得コスト

イネイブリングチームを置くことで対応？

感じたこと

• CDKがめちゃくちゃいい
  • AWSの現在のリソース状況をデータベースとして扱って、そのデータに応じて操作を変更できる

新しく起きそうな問題

• CDKコードとBackstageの開発、管理
  • 後方互換を基本的に保つ
  • 保てなくなったらバージョン変更
    ->メンテナンスチームで解決？

終わりに

今回はインフラ構築をアプリケーションチームに自律して行なってもらう方法を考えて実装してみました。
運用はこれからなので、その中で出てくる課題・解決策に関してもまた記事にしていこうと思います。