こんにちは。Azure Cloud Solution Architect 兼 DevOps Engineer の秋山です。
自社サービスのインフラリードを担当しています。
前回書いたブログが2年前になってしまいましたので、ここで最近のインフラの状況についてまとめてみます。
自社サービス Mamoru Biz で AKS 導入1周年で振り返る
プロダクト開発チームの増加に伴う効率化
最も大きい変化はこれです。
2年前は自社サービスイコール Mamoru Biz(現在の Colorkrew Biz) でしたが、現在は「Colorkrew ID」「Colorkrew Intra」「AI Chatシステム」や開発中のプロダクトなど多岐にわたります。
いずれの製品もクラウドインフラを活用しているため、新しいシステムのインフラ構築を効率的に行う必要があります。
自社サービスのインフラチームは私を含めて現在4人、全員受託案件など他の業務と兼任しています。
直近の1,2年ではおおまかに以下の内容を進めることで、インフラ業務が滞らない状況を作り上げてきました。
- プロダクト開発チームからの依頼テンプレート化
- インフラ・デプロイコードのモジュール化
- 最新技術のトライアンドエラーとフィードバック
本エントリではこれらを順に説明します。
プロダクト開発チームからの依頼テンプレート化
弊社ではソースコード管理に GitHub を利用しています。
新しいプロダクトの開発が始まるタイミングや既存プロダクトで新たなクラウドインフラが必要になったときに、GitHub Issue に内容をインフラチームが自身でまとめるようにしました。
そしてそれが大体パターン化されてきたため、 Issue テンプレートを用意して、プロダクト開発チームに記載してもらうようにしました。
ref: リポジトリ用に Issue テンプレートを設定する
内容は以下です
- 必要なクラウドインフラリソース(DB, Storage, …etc)
- Kubernetes リソース(Pod, CronJob, …etc)
- デプロイフロー
- 環境別の期日(Debug は ASAP, Prod は2か月後, …etc)
チャットのラリーで必要な情報を埋めていくのは非効率なため、一度で大半の情報を網羅できるのは効率的です。
また、プロダクト開発チームは別のプロダクトのインフラ依頼内容を参考にすることで、サイロ化を防ぎ横のつながりや理解にもわずかながらつながるという副次的な効果も見えています。
インフラ・デプロイコードのモジュール化
インフラ – Terraform
私たちのチームでは自社サービスのインフラ管理のために、 Terraform を利用しています。
Terraform では Modules という機能が用意されており、これを活用して再利用性や保守性の向上を狙っています。
(残念ながらすべて Module にはなっていません。一度書いたデプロイ済みのコードを Module に書き換えるのはそれなりに労力がかかりますね。。)
ref: Modules Overview
Kubernetes – Helm
Kubernetes のリソースについては Helm を使ってマニフェストを管理しています。
各アプリケーションはいくつかのパターンの技術スタック(Laravel, Go lang など) で作られているため、これに対応できる共通のテンプレートを用意して、各アプリケーション側で独自のマニフェスト定義が極力発生しないようにしています。
ref: Library Charts
アプリケーション – GitHub Action
アプリケーションのデプロイには GitHub Action を利用しています。
GitHub Action には Reusing workflows という機能が用意されています。
アプリケーションのリポジトリは一つずつ別のリポジトリで管理しているため、 GitHub Action のテンプレートが都度コピーされると管理が煩雑になるため、このテンプレートは重要でした。
ref: Reusing workflows
モジュール化によって、共通部分のメンテナンスがかなりやりやすくなり、均一な品質を各製品で享受しやすくなりました。
最新技術のトライアンドエラーとフィードバック
単に以前作ったことがあるものをそのまま踏襲するだけならここまでの内容で済みますが、日進月歩の IT 技術において最新技術を試行錯誤することは重要です。
発表された新しい技術や機能は積極的に小さく試して、うまくいったものは全体にフィードバックする、ということをしています。
たとえば Web サービスのフロントエンドとして Azure Static Web Apps はちょうどよいサービスです。
それまでは Azure Kubernetes Service 内でホスティングしていたため、 Docker イメージのセキュリティアップデートが必要だったり、デプロイのためにはビルドが必要でした。
新しい製品で問題なく動作しているため、少しずつ他の製品にも適用しています。
まとめ
Colorkrew の自社サービスは拡大を続けており、インフラとしても開発者個人としても、より高いクオリティやパフォーマンスを実現するための活動が日々求められています。
Colorkrew では自社サービスの開発と受託ビジネスの両方を経験できる環境があります。
もし弊社にご興味がある方がいらっしゃいましたら、 採用ページ からエントリーしてみてください。
