はじめに
この記事は、SEN アドベントカレンダー 2024の18日目の記事です！
本記事は、ものづくり部で撮影事業者向けのプロダクト開発をしている daitasuがお送りします。
千について
事業について
千株式会社は、「保育業界の課題をITで解決し、子どもたちの心と身体を強く育む」というテーマを掲げて、幼保業界を支えるプロダクトを数多く展開しています。
千におけるエンジニア組織の多くのチームは、それらのサービスの主幹となる、「はいチーズ！フォト」というインターネット写真販売サービスの開発に携わっています。
ひとえに写真販売サービスといっても、事業構造上、プロダクトのステークホルダーが非常に多く、
- 保育園の先生向けシステム
- 写真撮影事業者向けシステム
- 自社カメラマン向けシステム
- 印刷会社との連携システム
- 社内向け管理画面
などなど、多岐に渡るプロダクトを作成しています。
本日のお話は、そのうちの1つである、撮影事業者向けのプロダクト のお話です。
チーム状況
私達のチームは、2024年5月(今年)に上記のサービスの専属チームとして発足 しました。
今までは、事業単位で切らずに組織構成がなされていたのですが、開発組織も人が増え、今年、撮影事業者向けシステムの開発を加速するために、部隊が専属として切り出された形になります。
チームは現在、
- エンジニア 4名(内、業務委託 1名)
- デザイナー 1名
- プロダクトマネージャー 1名
という体制で構成されており、日々事業部サイドとプロダクトバックログの精査やSprint Review での議論を繰り返しながら開発しています。
システム状況
プロダクトとしては20年近く運営されているサービスで、内部コードとして レガシーな部分( ethnam ) がいまだ多く残っており、今後
新規にプロダクト価値を生み出していくにしても、
DBのデータ構造を大きく変化させる必要があったり、
- それに向けて Frontend / Backend / Infra 基盤含めた全体的なリプレイスが必要だったり
と、プロダクトとして大きくリニューアルを迎えようとしているフェーズ になります。
私達の撮影事業者向けシステムも同様で、今後の開発を見据えてリプレイスへと舵を切りました。
インフラをプロダクトチームで作っていく
社内にはSREチームがいて、日々の監視であったり、全体的なインフラ基盤を統括しています。
しかし、上記のように、社内には多くのプロダクトがあり、それらが各チームでリプレイスが走り出しています。
これらすべての立ち上げや基本的な運用を SRE チームで持つと、負荷が大きく身が持ちません。
千の開発組織では、
- インフラ構成図の検討
- 監視や運用まわりの設計
- 実際の構築と運用
を各プロダクト開発チームで新規に設立するシステムを一通り担う方針 で動いています。
そうした中、
私達のチームは、インフラに深い知見や 0 to 1 のプロダクション環境の立ち上げ経験があるメンバーが不在で、試行錯誤しつつ無事にリリースまでたどり着いたため、そうした変遷をお話していきます！
ステージ1: ADR を書く
まず初めに、完全に新規に作り直すシステムなので、アプリケーションレイヤの技術スタック構成、AWSのシステム構成など諸々を Architecture Decision Record (ADR)としてドキュメント化しました。
ADRについては、先日チームの取り組みを書いたので、こちらをご参照ください。
最初のAWS システム構成図は、チームでBackend に尖った技術リードの方が叩きを作成してくれました。
ADRには、
- AWS アカウントを基幹システムと分けるか
- (分けた場合に)どっちにどの機能を持つか
- 構成要素の新規リソースでの概算コスト
- ログイン認証まわりのセキュリティをどう担保するか
などを調査・検討して設計しました。
これをもとに、SREチームと幾度か相談を重ね、ひとまずのアーキテクチャが完成しました。
ステージ2: AWS CLI で Development 環境を立てていく
千の開発では、各インフラで Development / Staging / Production 環境の最低 3つの環境を立てています。
ある程度アプリケーション開発が進んできたところで、QAテストに向けたDevelopment 環境を立て始めました。
この部分は主に筆者が担当したのですが、筆者は主にFrontend 領域を中心とした仕事を多くやってきており、恥ずかしながらAWSは業務や個人で触ったり一定のサービス理解はあるものの、
大規模プロダクトのインフラ基盤の0 to 1 システムリプレイスなどはほとんど初の試みでした。
色々な企業の事例を見たり、AWSの手厚いDocumentを眺めたり、生成AI に概念的な壁打ちをお願いしたりと試行錯誤しつつ理解を温めていったのですが、
- 「まずは動くものを。後で全消しするつもりで良い。」
という気持ちで、Infrastructure as Code(IaC) 対応も検討にありましたが、まずは基本的な現状立てた設計の理解を深めようと、AWS CLI で黙々と立てていきました。
この工程はおよそ整理した後に、Document に書き起こしておき、何かあったときにヘルプできるように、また、工程を書いておくことで今後同じくリプレイスに挑戦していくチームの助けになればと思い書いていました。
このように、いくつかに分解して実行を進めていきました。
ドキュメントにログをぼやき始めたことで、社内のインフラつよつよエンジニアから助け舟のお声がかかります。
いくつかのつまづきポイントがありましたが、助け舟のおかげで無事に乗り越えることができ、Development 環境を作ることが出来ました。
また、実際に構築を進める中で見えていった課題がいくつかあり、コスト面やセキュリティ面、運用面の改善のため、初期に立てた構成図から少し修正を加えていくなどしました。
ステージ3: Terraform ハンズオン
Development 環境が一通り立ち、いよいよ本番構築も近づいてきたところで、IaC 化に踏み切ります。
その前に、事前に上記のほかチームのエンジニアの方が「Terraform ハンズオン」を主催いただき、
- Terraform の基本的なこと
- Terraform化する前に知っておかないといけないこと
- Terraform は銀の弾丸ではないこと
- AWS Organization の実際の構築ハンズオン
を行い、チームのベースの知識が整いました。
ステージ4: Terraform化
Terraform化自体は、事前に AWS CLI で一通り立てていたログを残していたのもあって、ひたすらリソースの定義をTerraform に書き直していくだけなので、ほとんどのところで躓かずに済みました。
多くの躓きポイントは、AWS の機能の不理解や Terraform で構築する際は必要になるAWS の設定フラグなどが抜け漏れていたりなどで、Terraform 自体はとても理解しやすくて進めやすかったです。
ADR、AWS CLI やハンズオンで解像度が高まっていたおかげなので、事前のドキュメント化は本当に重要だなと改めて感じました。
この際に、下記の書籍を読んでいたのですが、基本的な事項のレシビ集として助けになりました。
ステージ5: 本番リリース
本番リリース前に、SREチームに改めて相談のMTGを開きました。
最新の構成図を見せつつ、リリース後の運用方針や監視まわり、セキュリティ面で抑えていたほうが良いことなどを整理して相談をしました。
それらの修正などを Terraform に再度反映し、リリース作業へと移ります。
本番リリース作業時も多少環境差異でうまくいかない部分などが発生したのですが、インフラに強い方々をハドルにお呼びするなどして、無事にリリースまで到達することが出来ました。
ステージ6: 全員Terraform やっていき
最初のリリースは、まだ少数のユーザにだけ使ってもらうような仕様だったため、最低限のリソースだけを構築した状態で出していました。
ここまでは、筆者がADRを書いたメンバーとでレビューしあったりして進めた点が多かったのですが、チーム全員でインフラ運営を今後担って行きたいこともあり、
アプリケーション開発の方を推し進めて頂いていたメンバーたちも、足りていないリソースの追加作業などでTerraform に順次挑戦していきました。
- QA 環境の破壊とTerraform再構築
- Chatbot での通知
- NAT Gateway の構築
- etc...
各作業工程は、Slack にスレを立ててlogging していくことで後で見返したり、ヘルプを頼みやすいようにしています。
今では、チーム内で相互にTerraform についてレビューし合ったり、リソース設計について全メンバーが議論しあえるような状態となっており、チームとしてのインフラ力がとても高まっています。
おわりに
今後は、
- 社内のほかチームで運用しているリソースの理解と再利用
- Terraform Cloud への移行
- 監視まわりのさらなる改善
などやることはまだまだありますが、「SREの民主化」となる一歩をチームとして歩めたことは非常に大きいです。
チームとしてさらに技術の裾野をこれからも拡げていきたいと思います！
