社内イベント管理システムを1週間でAKSからACAに移行した話し

第50回 Tokyo Jazug Nightで発表させて頂いた資料です
https://jazug.connpass.com/event/335527/

Transcript

1. 社内イベント管理システムを1週間 でAKSからACAに移行した話し 第50回 Tokyo Jazug Night 2024/12/18 Shingo Kawahara 1
2. 自己紹介 • 河原 慎吾 Microsoft MVP for Azure • 株式会社セゾンテクノロジー • R&D組織運営 • クラウド/コンテナ担当 • CCoE Lead • 経歴 • VMwareベースの自社クラウド構築/運営 ⇓⇓⇓ • パブリッククラウド活用推進、組織運営 2 4月に社名 変わったよ
3. Qiita • Azure中心に書き溜めているので参考になればうれしいです! • https://qiita.com/shingo_kawahara • フォローお待ちしております♪ 3
4. Agenda • 社内イベント管理システムとは • AKSとACA • 移行の背景 • 移行のポイント • まとめ 4
5. 社内イベント管理システム 5
6. 社内イベント管理システム? • 全社員が利用可能な、社内イベント管理プラットフォーム • 社内イベント作成＆申し込みに対する課題を解決するためにス クラッチで開発し、2019年にリリースしました • いつどんなイベント、勉強会が開催されているか分からない • スケジュールが一覧で見れない • 自分の予定表に追加するのを忘れる • リマインドされない など 6
7. re:Inventの報告会があったり、 HULFT10 リリースパーティーがあったり、 7
8. インフルエンザ予防接種や、 全社セミナーなんかも、 8
9. こんな感じで、誰でもイベントを作成できる 社内版connpassみたいなシステム 9 • 参加申し込みしたらGraphAPIを介して、自動的にOutlookの予定表に追 加されるので参加忘れの心配なし!
10. AKSとACA 10
11. Azure Kubernetes Service • コンテナー化されたアプリケーションをデプロイして管理するために使用 できるマネージド Kubernetes サービス • 2018年にGA 11 https://learn.microsoft.com/ja-jp/azure/aks/what-is-aks
12. Azure Container Apps • Azure 上でコンテナをデプロイして実行できる、フルマネージドのサー バーレス コンテナー プラットフォーム • Kubernetes上で動いているが、Kubernetesを極力意識させない作りに なっている • kubectlでデプロイとかはしない。K8sのバージョンアップも意識しない。 • でもイングレスなどの用語は出てくるのでk8sの知識があった方が理解しやすい 12 https://learn.microsoft.com/ja-jp/azure/container-apps/containers • 2022年にGA
13. 移行の背景 13
14. 当時なぜAKSを採用したのか? • 社内イベント管理システムは2019年に構築し、まだGAして1 年程のAKSを採用することにした • なぜ当時採用したか? • 一番の理由は使ってみたかったから • アーキテクチャ選定に関わることがあり、実際に使って運用したこと がないサービスは選定しづらい • 小規模な社内システムだったので試すには最適 14
15. どうしてACAに移行することにしたのか? • Let’s Encryptの証明書期限切れに対応しなければならない • そのためにはAKSをバージョンアップする必要があったが、バージョ ンアップするとAPI仕様変更によりcert-managerを作り直すなど、多 くの変更が必要なことが分かった • そもそも運用負荷を下げたかった • AKSのバージョンアップに追従するのがきつく、⾧いことバージョン アップしていなかった • 古いAKSなのでPublic IP Basicを利用しており、2025-09-30 に廃止されるため対応が必要だった 15
16. 移行のポイント 16
17. As-Is 全体像 Helm nginx-Ingress ClusterIP Pod Front Pod Front ClusterIP Pod Backend Pod Backend NameSpace cert-manager Helm cert-manager SQLDB Blob ServiceEndpoint ScaleSets AKS vNet Developer 社員 Internet ACR 社員マスタ ExRoute PublicPeering M365 Entra ID GraphAPI Internet LogAnalytics Monitor Internet push Internet オフィス 17 deploy Nuxt.js Spring Boot
18. To-Be 全体像 Helm nginx-Ingress ClusterIP Pod Front Pod Front ClusterIP Pod Backend Pod Backend NameSpace cert-manager Helm cert-manager SQLDB Blob ServiceEndpoint ScaleSets AKS vNet Developer 社員 ACR 社員マスタ ExRoute PublicPeering M365 Entra ID GraphAPI Internet LogAnalytics Monitor Internet push オフィス 18 deploy vNet Container App Environment backend Subnet frontend Internet データ保存サービス群は 移行せずそのまま流用する Nuxt.js Spring Boot
19. ACAのワークロードプロファイル • アプリを動作させる実行環境 • 従量課金ワークロードはデフォルトで有効 • より多くのリソースが必要な場合は専用の環境をデプロイする 19 各アプリにどれくらいのリ ソースを割り当てるか
20. ざっくり移行の流れ • ほとんど改修が発生しなかったため、1週間程度でシステム切り替えまで 実行 20 アプリ担当 Azure担当 工程 期間 変更点洗い出し＆工数/スケジュール試算 準備期間 1日目 ユーザー通知 アプリ改修＆テスト k8sシークレット値洗い出し 2日目 vNet、ACA構築 CI/CD実装 結合テスト 5日目 既存AKSサーバー停止 リリース 7日目 ドメイン変更
21. 移行における修正ポイント • Blob Storage SDKが古すぎてMaven Centralから参照できな かったのでバージョンアップ • それに伴い他ライブラリもバージョンアップ • Kubernetes secretsの移行 • 各種k8sマニフェストファイルが不要になる • AKSの場合、以下セットが必要 • Bicep、Dockerfile、マニフェストファイル、ソースコード • デプロイ手法の見直し（CI/CD） • カスタムドメインの変更＆DNS設定 21
22. まとめ 22
23. まとめ • 少しはまったのはアプリケーションのライブラリバージョン アップくらいで、AKSからACAへの移行自体は簡単（計画から 1週間でできた） • 副次効果として、コストが8分の1に下がった • これは利用規模によるが、今回は小さいシステムなのにAKS使ってた から高くなっていた • ある程度のアプリケーション規模になるとAKSが選択肢となる 23