Azure移行とリリースプロセス再構築(2024.3.8 第2回JAZUG for Women)

2024.3.8 第2回JAZUG for Womenでの発表資料です

Transcript

1. Azure移行とリリースプロセス再構築 2024.3.8 第2回JAZUG for Women shinhori
2. 自己紹介: shinhori • 2016.2～コンテンツワークス株式会社 ◦ カスタマーサポート職として入社 →社内異動でエンジニア • 担当 ◦ 開発・運用（バックエンド /インフラ/基盤） ◦ スクラムマスター
3. 主力事業:Photoback(フォトバック) フォトブックの印刷・製本 →思い出をカタチに残す
4. 今日のテーマ • 自社サービスのオンプレミス→Azure移行に伴い、リリースプロセスをどのように再 構築・改善したのか • まだまだ改善点はありますが…！Azure知識ゼロの状態から対応して得た学びや 感想をシェアします • よろしければ併せてご覧ください👀 ◦ JAZUG for Woman第1回 ◦ 同僚のほくりんさんが、移行時の体験談などお話されています
5. Azure移行の進め方
6. プロジェクトチームで対応 • 2021.11-2022.4　IaaS化検討 • 2022.5　PaaS化に方針転換 • 2022.7　Azure Light-up ※後述 • 2022.8-2023.6　移行準備 ◦ Azureリソース構築 ◦ アプリケーション改修 ◦ 順次できるところから移行 • 2023.6末　移行完了 ◦ ここからがスタートライン！ ◦ 移行したことで見えてきた課題の解決・改善に向けて、現在も対応中
7. プロジェクトメンバー全員Azure初心者 • どのAzureリソースを使ったら何ができるのか知らない • どんな課題があるか、どんな解決方法があるのか思いつかない😱
8. 外部スペシャリストの力もお借りして乗り越えました！ • 移行のパートナー＝株式会社ゼンアーキテクツ様 • 2022.7　Azure Light-up ◦ ハッカソン形式でシステム構成の検討、 PaaS化やってみるところまで ◦ 当初想定していたIaaSでなくPaaSにチャレンジすることに • 2022.8～現在　ZEN Advisor利用 ◦ Azure スペシャリストによる QA サポート
9. せっかくAzure移行するなら…チャレンジ！ • 今まで解決できなかったリリースプロセスの課題 • Azureの仕組みを生かして、良い感じに解決できる…？
10. リリースプロセス課題
11. Staging 環境 ビルド デプロイ Staging DB demo環境 ※本番DBに接続して 最終確認する用 ビルド デプロイ 本番DB 本番環境 demo環境から 本番にコピー
12. 定期リリース@毎週水AM • 水PM～金　実装→developブランチマージ→Staging環境に反映 • 月　Staging環境に反映、リリース予告 • 火　demo環境に反映 • 水AM　本番環境リリース ※各環境でテストも必要
13. リリース作業担当者の負荷が高い💣 • 作業ステップが多い+手動が多い ◦ Jenkinsジョブを手動実行×3 ◦ リリース内容に応じて ▪ SQL実行 ▪ Web.config修正 ◦ リリース予告連絡・完了連絡 ◦ Publish Release • ミスしないか、漏れが無いか不安 • 担当者が休みの場合、引き継ぎが必要 ◦ 作業担当者＝サービス毎に 1人ずつ
14. Web.configをテキストエディタで手動更新📝 • 手順 ◦ プルリクエストをマージ ◦ 各環境のテキストエディタで configを開く ◦ プルリクエストを見ながら手動で書き換え ◦ 保存 • 実際発生した障害 ◦ 間違った箇所を更新、誤った値で更新 ◦ 更新必要な箇所の見落とし ◦ ⇒サイトが表示されない、特定の機能を利用できない
15. シークレット管理に難あり🔑 • シークレット ◦ 接続文字列 ◦ API Key ◦ … • シークレットは基本Gitにあげない • 各環境のWeb.configシークレット追加・更新時 ◦ configをテキストエディタで開く ◦ 管理台帳EXCELや他アプリケーションの configからコピー ◦ ペースト、保存 • 変更履歴を追いにくい ◦ 定期的にバックアップ保存はしているが、いつどの値が変わったか確認しにくい
16. リリースまでの待ちが発生🕑 • 定期リリース@毎週水AM ◦ クリティカルなバグが発生した場合、 hotfixブランチを切って緊急リリース • 水PMにStaging環境でのテストが終わっていても、翌週水AMまでリリース待ち • お客様への価値提供まで時間がかかる
17. 課題をまとめると • リリース作業担当者の負荷が高い • Web.configをテキストエディタで手動更新 • シークレット管理に難あり • リリースまでの待ちが発生
18. 理想 • 作業ステップが少ない • 手動作業がない • リリース作業担当者に頼らない • 準備でき次第、随時リリースできる →どう実現する？
19. Azure移行で対応したこと
20. Jenkins →Github Actions
21. Github Actionsを使わない手は無い！ • Github Actions ◦ あらかじめ定義した処理と条件の組合せ（＝ワークフロー）を実行できる ▪ 例：ビルド、デプロイ、プルリク作成 … ◦ プルリクエストやブランチ作成などのイベントをトリガーに自動実行可 • 2017 自社ソースコード管理をGithubに切り替え • Azure移行でWebアプリケーション→(主に)AppServiceへ ◦ 一部 ▪ 静的Webアプリ ▪ Functionに置き換え ▪ FrontDoor経由でストレージアカウントの Blob参照
22. GithubActionsワークフロー：プルリク～Staging環境 • developブランチへのプルリクをApprove&マージ ◦ developブランチからreleaseブランチを作成 • releaseブランチ作成 ◦ master<-releaseプルリク作成 ◦ ビルド ◦ Staging環境のStagingスロットへデプロイ ◦ Stagingスロットと運用スロットをスワップ (=Staging環境更新)
23. GithubActionsワークフロー：リリース • master<-releaseプルリクをApprove&マージ ◦ ビルド ◦ 本番環境のStagingスロットへデプロイ ◦ Stagingスロットと運用スロットをスワップ (=本番リリース) ◦ Publish Release
24. Staging 環境 ビルド デプロイ Staging DB demo環境 ビルド デプロイ 本番DB 本番環境 demoから 本番にコピー
25. Staging環境 stagingスロット Staging環境 運用スロット スワップ ビルド デプロイ 統合DB 本番環境 stagingスロット 本番環境 運用スロット スワップ ビルド デプロイ 本番DB ※functionもGithubActionでビルド・デプロイ
26. リリース作業担当者でなくてもリリースしやすく • プルリクを操作していけばリリースまで完了できる
27. Web.config →テキストエディタで手動 更新しない
28. 以下の組み合わせで実現 • KeyVault • AppServiceのアプリケーション設定 • Terraform • Web.config変換
29. シークレット管理はKeyVaultで • KeyVaultとは ◦ シークレットを安全に保管＆アクセス • KeyVault管理にしたシークレット例 ◦ Azureリソースの接続文字列系 ▪ DB(SQL Managed Instance) ▪ ストレージアカウント ◦ Azureリソース以外 ▪ SendGrid API Key ▪ 自社フォトブック作成 APIのシークレット
30. AppServieからKeyVault参照 • AppService→構成→アプリケーション設定→値にKeyVaultのURIを指定 ◦ @Microsoft.KeyVault(SecretUri=https://kv-all-***.vault.azure.net/secrets/***ConnectionString) • アプリケーション設定が優先される仕様 ◦ Web.configに同じ設定が入っている場合
32. AppServiceはTerraformでコード管理 • Terraform=インフラの構成をソースコードとして管理できるツール • AppServiceをTerraformで管理 ◦ ソースコードはGithubへ ◦ いつ何が変更されたのか履歴管理可 ◦ アプリケーション設定の変更もコードレビューできるように！
33. Web.config変換 • Web.configを、発行先やビルド構成に応じて自動的に変更する機能 ◦ 自社サービスは.NET Framework • 変更時に、元のWeb.configの指定箇所を書き換え可能 • Web.{{Azureリソース名}}.configファイルに、環境ごとの設定値を書く • 要素ごとに以下書き換えが可能 ◦ 値置き換え ◦ 属性追加 ◦ 削除 ◦ 追加
34. Web.config変換の例 • アプリケーション設定で持たせるためRemove ◦ 接続文字列 ▪ <connectionStrings xdt:Transform="Remove"/> • 環境(Staging/本番)によって値を置き換え ◦ サイトのBaseURL ▪ <add key="SITE_URL" value="https://photoback.****.jp/" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />
35. リリース予告/完了報告 →自動化 ※Azure関係なし
36. 今まで：リリース作業担当者が手動で予告・報告 • 予告 ◦ その週のリリース内容をまとめる Backlogチケットを作成 ◦ 必要な部分をコピーして Slack投稿 • 完了報告 ◦ 「リリース完了しました」と Slack投稿
37. 目的 • 何がいつリリースされるのか&されたのか、開発者以外にも共有必要 ◦ カスタマーサポート ▪ お客様対応の準備をしたい • 動作確認 • FAQや対応マニュアル更新 ◦ マーケティング・営業　 ▪ お客様へ提供する内容に問題ないか最終チェック
38. プルリクマージをSlack通知だとダメ？ • 検討しましたが△ • マージごとに都度通知が届く→確認が大変 • チケットベースで予告がベター
39. 予告：Google Apps Scriptで自動化 • Backlogから今日以降リリースのチケット情報を取得 ◦ BacklogのAPIでGet • リリース予定リスト（Googleドキュメント）を更新 • Slack投稿 ◦ 2営業日以内リリース予定のチケットが ▪ あり　チケットのキー +タイトル(リンクつき) ▪ なし　リリース予定リストのリンク
40. 完了報告：Github Actions×GithubのSlack連携 • GithubでのPublish Release時にSlackへ通知 • GithubActions ◦ masterブランチへのマージをトリガーに以下実行 ▪ 本番リリース(App Serviceのスロットをスワップ ) ▪ Publish Release • Github×Slack ◦ SlackにGithubアプリ追加 ◦ リリース予告・完了報告チャンネルでコマンド実行 ▪ /github subscribe {organizationName}/{repositoryName} releases
42. 実現できたことを 振り返ると…
43. 再掲：課題まとめ • Web.configをテキストエディタで手動更新　⇒解決！ • シークレット管理に難あり　⇒解決！ • リリース作業担当者の負荷が高い　⇒解決！ • リリースまでの待ちが発生 →上3つ解決 →”いつでもリリース(随時リリース)”を導入 →4つ目も解決🎉
44. 再掲：理想 • 作業ステップが少ない　⇒減らせた • 手動作業がない　⇒減らせた、けど残っている(後述 • リリース作業担当者に頼らない　⇒誰でもできる…？(後述 • 準備でき次第、随時リリースできる　⇒できた
45. 残っている課題＋今後の展望
46. まだまだ手動でのテスト実行に頼っている • テスト種別 ◦ ブラウザから手動で UIテスト ◦ PostmanからAPIテスト ◦ 整備中 ▪ e2eテスト ▪ UnitTest
47. 自動テストを取り入れたい • プルリクエスト作成→Unitテストが自動実行→成功しないとマージ不可 • 本番リリース→e2eテストが自動実行
48. GithubActionsの心理的ハードルを下げたい • Azure移行チーム以外、Github Actionsのワークフロー実装に携わっていない • デザイナーは今までリリース作業に一切関わっていなかった • 今までより簡単になったとは言いつつ… ◦ 「間違えたらお客様にも社内にも迷惑がかかるのでは …」 ◦ 「何をトリガーに何が実行されるのか覚えられない」 • 対策 ◦ 間違えても大丈夫なワークフロー設計にする ◦ 社内勉強会でGithubActionsを知ってもらう
49. 自動化しきれていない部分 • SQL実行 ◦ 実行タイミングをコントロールできない …？仕方ないか… ▪ リリースまで終わってから実行したい SQL ▪ リリース前に実行必要な SQL
50. 終わりに
51. 感想 • 先人達が試行錯誤を経て作り上げてきたプロセスでも、改善の余地がある ◦ 主力事業のPhotobackは今年20周年 ◦ 技術環境の変化や社内環境の変化に応じて改善してきた ▪ メールでなくSlackへ ▪ Backlogでのチケット管理 ◦ 「こういうものだ」と諦めていたことでも、解決方法はある • 移行自体は完了したが、ここがスタートライン • 現状に満足せず改善をまわしていく ◦ 小さな改善も大きな改善も大事
52. ご清聴ありがとうございました👋