私の後悔をAWS DMSで解決した話

2025年8月28日に行われた、
AWS10分LT会 vol.6(https://aws-likers.connpass.com/event/363359/ )に
登壇した時の資料になります。

Transcript

1. 私の を on AWS 10分LT会 Vol.6 2025/8/28(木) 19:30 ～ 22:30 ハッシュタグ : #AWS10分LT会 AWS DMS で解決した話
2. 2 自己紹介 HN：平目＠インフラエンジニア 所属：地方の一般企業 ロール：クラウドエンジニアリングマネージャ この辺りのどこかに います！！ AWS 10分LT会Vol.4に出させて頂きました
3. 3 どうしてあの時 こうしなかったんだ… 今日のテーマ
4. 4 今日のテーマ 誰でも後悔してることの ひとつやふたつ… あるよね。
5. 5 経 緯
6. 6 社内で生成AI利用の機運が高まる！ 生成AIを従業員が使えるように環境を整える
7. 7 AIの社内導入について考える ・一般企業で、従業員はほぼ非エンジニア ・エンジニアでなく生成AIをあまり使ってない従業員に、 いきなり有料アカウントを配布するのはコスパが悪い ・従量課金制のサービスを使う方がコスト戦略的に良い ・AI利用ガイドライン制定 ・基礎リテラシー教育 サービスに関する要件 運用に関する要件 他に戦略的に大事な要件があった
8. 8 サービスの納品を とにかく急ぐこと！
9. 9 何故サービスの納品を急ぐのか えらいひと おともだち
10. 10 導入について考える（再） ・一般企業で、従業員はほぼ非エンジニア ・エンジニアでなく生成AIをあまり使ってない従業員に、 いきなり有料アカウントを配布するのはコスパが悪い ・従量課金制のサービスを使う方がコスト戦略的に良い ・リリース出来る環境をいち早く用意して 機先を制したい ・AI利用ガイドライン制定 ・基礎リテラシー教育 サービスに関する要件 運用に関する要件
11. 11 結論 Amazon EC2 Amazon Bedrock
12. 12 Difyとは ・DifyはAIのプラットフォームサービス(OSS) ・実態はLinux等のOSにて利用するDocker Composer ・WebサーバやUIなどのフロントエンドから 各AIサービスへの接続用のバックエンドまでまとめて提供
13. 13 構成図 ・シンプルな２層アーキテクチャ ・AWS構築自体はterraformで構成(IaC管理) ・EC2内部はansibleで構成(IaC管理) セキュリティ要件などを満たして、 検討開始から１週間程度でリリース準備が出来た
14. 14 その後の普及の流れ 社内会議でDify採用の提案 ガイドラインの制定 社内での生成AI基礎勉強会
15. 15 何を後悔したん？
16. 16 について
17. 17 普及を始めて ・適切に生成AIが普及した ・社内での利用率は従業員の45~50％程に向上 ・良くも悪くも後戻りが出来なくなった
18. 18 運用していて気になる事 Amazon EC2 EC2の管理
19. 19 DifyをホストしているEC2の管理 Amazon EC2 ・Amazon Linux2023のセキュリティアップデート ・定期的に配信されるDifyのverup対応 ・DBがローカルに存在 ・データ永続性に問題がある
20. 20 構成図（再掲） 本構成だとDBがEC2内部に構成されている EC2インスタンスの建て直しが困難 （バックアップ運用は可能ではある）
21. 21 Amazon EC2 EC2インスタンス…私たち「ズッ友」だよ…！！！
22. 22 Amazon EC2 EC2インスタンス…私たち「ズッ友」だよ…！！！
23. 23 どうしてあの時 三層アーキテクチャに しなかったんだ… 私の後悔
24. 24 e!? ここからでも入れる保険があるんですか!? Amazon RDS AWS DMS
25. 25 ここまでの経緯のまとめ
26. 26 AWS DMSによる データ移行
27. 27 構成図（新） AWS DMS データ移行について ・DB移行をDMSにて実施する ・シンプルなフルロード+ CDCにより同期 構造について ・二層アーキテクチャを三層アーキテクチャに ・アプリケーションの情報をRDSに移管
28. 28 データ移行(DMS) データ移行 ・DMSにてフルロード + CDCを実行 初期準備 ・Difyデータベースのスキーマ調査 ・RDS上に同名データベースとユーザを作成 ・両DBに移行用ユーザを作成 ・接続用経路／セキュリティの確保 ・DMSインスタンスとエンドポイントの作成
29. 29 仕向け先切り替え 仕向け先切り替え ・Difyのdocker-compose.yamlの調整 （docker-compose.overload.yamlで行う) ・データベース仕向け先をRDSに ・Docker Composeの再起動 後始末 ・AWS DMS及び関連リソースの削除 ・移行用ユーザの削除
30. 30 反省
31. 31 要件の深堀り・調査が不完全だった 初動の問題 ・私の考えが甘かった ・Difyのリリース頻度とEC2の管理の観点から、RDS+ElasticCache構成で作るべきだった しかしながら… ・本件に関われるエンジニアが自分以外にいなかったという側面もある ・リリース速度的に仕方が無かった部分は許容出来る ・後からリファクタリングで解決出来ることが分かったのは大きな収穫 （リファクタリングしないで済むに越したことは無いのは当然）
32. 32 ご清聴、どうもありがとうございました。