こんにちは。 Azure Cloud Solution Architect の秋山です。 今回は前回に引き続き弊社の Mamoru Biz で k8s に移行した話について書きます。
- Vol.1 App Service から AKS へ移行の決断
- Vol.2 AKS(k8s) 移行の下準備 <- 本記事
- Vol.3 AKS(k8s) 移行
Vol.2 AKS(k8s) 移行の下準備
前回の記事 で移行することは決めました。 次のステップは移行を始めるためのリソースの確保とチームへの説明です。
リソース確保
前回の記事に書いたとおり、インフラエンジニアは兼任です。 Azure のレイヤーは自分でどうにかするとして、 k8s, DevOps レイヤーを実装できるメンバが必要でした。 このプロジェクトでは、 DevOps 領域で仕事をしている ジェホ さんとともに取り組むことにしました。
AKS(k8s) 移行のようなプロジェクトでは DevOps 環境の整備はマストです。 自社の SaaS ビジネスとはいえ受託ビジネスのくらまねとやることは大差ありません。 参考: サーバーレス/コンテナ導入支援 | くらまね
大まかなコスト感とスコープ、スケジュールを決めて動き始めました。 技術的な部分については後の記事で記載します。
チームへの説明
チームへの説明は段階を踏んで徐々に行いました。 大まかに分けると以下の4ステップです。
プロジェクト開始前
- インフラメンバー(説明とプロジェクトへの勧誘)
- 事業責任者とアプリケーションエンジニアのコアメンバー(説明と合意形成)
プロジェクト進行中
- アプリケーションエンジニア(説明と予習の促進)
- チーム全体(説明)
各メンバーへの説明(説得)材料は 前回の記事 に書いた通りです。 Mamoru Biz では 15-20 人とそこそこの人数がアクティブに関わるため、チーム全体への説明は移行プロジェクトの終盤で行いました。
英語で。
というのも、上記の 15-20 人のうち、半数近くは日本人ではありません。 ミーティングやチャットは日常的に英語で行っています。 今回の説明会も英語なのは当然です。 これは私にとって人生で初めての英語のプレゼンテーションでした。
以下は当時のスクリプトの一部です。
少し真面目でないスクリプトを入れたくて 「(k8s 導入で) Developer はもっと給与を手に入れられるようになる！」 と話したところ、 誰もくすりともしなかったのはいい思い出です。。 (リモートだからかな)
まとめ
ここまで移行の準備や根回しについて書きました。 次回はいよいよ移行の技術的な部分について書きます。
