こんにちはへたれです。
株式会社アイデミーでエンジニアとして、材料開発のためのデータ活用プラットフォームLab Bankを開発、運用しています。
はじめに
現在Lab Bankグループではエンジニア5名体制で開発を進めています。
フロントエンドはNext.js, バックエンドはFastify, インフラはAWSという構成です。
しかし自分以外のメンバーではインフラの開発・運用が得意な方がいません...全員アプリケーションエンジニアです。
自分がバスに轢かれるとサービス運用が立ち行かなくなります...
そこでサービスの立ち上げから現在に至るまで、チーム全体にインフラの構成や運用を理解・実践してもらえるよう取り組んできたことを記事にしました。
時系列・手順としては以下のような流れでした。
- 「読んだらわかる」状態を残しておく
- インフラの基礎を理解してもらう
- 手順書を作る
- ペアプロで場慣れしてもらう
1. 「読んだらわかる」状態を残しておく
サービス立ち上げ当初からインフラを理解してもらうような活動をする余裕はありません。
ですが何かしらの形で残さないと、全て自分の頭から捻り出して説明する必要があります。
ドキュメント・構成図
概観を掴んでもらいやすいよう構成図やドキュメントは書きました。
ただし最新状態を常に追いかけようとすると運用コストが嵩んでしまうため、ドキュメントの更新は意図的に行いません。
構成変更が生じた際は新しく書き出し、それらをNotionデータベース化しました。
(DesignDocに近いものをイメージしました)
IaC
Lab BankではTerraformを採用しており、インフラとして構築するものは全てコードとして残るようにしています。
また途中からレビュワーとしてアプリケーションエンジニアを巻き込むことで、「自分たちが開発した機能がどのような仕組みの上で動くようになっているのか」を徐々に理解してもらうようにしました。
2. インフラの基礎を理解してもらう
1節でのレビューでは部分的に今の構成を理解することにとどまっており、インフラそのものを深く掘り下げて理解するところまでの提供ができていませんでした。
開発が進むにつれて、社内勉強会を実施する余裕ができるようになった頃、勉強会を開いてAWSへの根本的な理解を促しました。
- IAM系
- IAM User, IAM Role, IAM Policy
- Assume Roleの仕組み
- ネットワーク系
- Route53
- ALB
- Security Group
- コンテナ系
- ECS (Task Definition, Task, Service, Clusterの関係)
- ECR
特にネットワーク系はTerraformに書くリソースの種類が多く、混乱しがちなので以下のような例と図を用意して丁寧に説明しました。
また「単純にAWS理解した」で終わらないよう、プロダクトのTerraformコードを参照しながら「ここが対応しています」という説明をしたらとてもウケが良かったです。
3. 手順書を作る
インフラの運用といえば手順書ですよね。
手順書は2種類あり、それぞれ役割が異なります。
- 各種作業の手順書
- 過去の作業履歴
各種作業の手順書
こちらは一般的に想像される手順書ではないでしょうか。
ある目的(デプロイ、再起動、ログ確認 etc)に対して必要な手順をコマンドレベルまで書き下したものになります。
手順書例
事前作業
- 対象顧客に実施時間と内容をメールにて告知
告知テンプレート
- GitHub上でリリースを作成
当日作業 - インフラの変更
$ terraform plan
$ terraform apply
- ECSのサービスアップデート
...
手順書を作る際は上から順に実施すれば目的を達成できるようにしておき、
- 事前作業
- 当日作業
- 動作確認
と構成しています。
少し話は逸れますが、チーム内ではクレデンシャル情報の管理もaws-vaultに統一しています。
これにより使用するロール等もコマンドレベルで統一可能です。
過去の作業履歴
各種作業の手順書を作ったとはいえ、インフラの肌感がわからないメンバーは作業を組み立てるのはまだ難しいです。
ワンショットな作業もあるため、新しい作業のたびに手順書を増やすのも管理が煩雑です。
そこで実際に行った作業を作業履歴としてNotionデータベース化しました。
また実際に作業を実施する前に作業履歴に書き出しておき、先にレビューしておくことでより安心して作業にとりかかることが可能です。
4. ペアプロで場慣れしてもらう
実際の作業経験の有無でいざという時の心理的抵抗は変わります。
Lab Bankグループではなるべく2人以上でインフラ作業に当たっています。
ダブルチェックというよりは慣れを作るためのペアプログラミングの側面を重視しており、担当者を2役に分けています。
コマンダー: 作業内容の指示を出す・作業内容をチェックする人
ドライバー: コマンダーに従い作業を実施する人
作業毎にメンバーと役割をシャッフルし、手順を考えること・実際に手を動かすことの両方に慣れてもらいました。
終わりに
今回は殆どがアプリケーションエンジニアである開発チームの中で、どうやってインフラの運用を広めていくかという話をしました。
Lab Bankグループでのインフラ布教もまだまだ道半ばですが、他メンバーがインフラ作業もできるようになってきました。
努力が実った実感があり、とても嬉しいです。
こういったシチュエーションはサービスローンチ直後のフェイズなどでは良くあることではないでしょうか？
少しでも誰かの参考になれば嬉しいです。
またアイデミーでは一緒に働く仲間を募集中です！
今回の記事を読んで興味が湧いた方、まずはカジュアル面談からでもお待ちしております！
Discussion