小さなお葬式をAWSに移行したお話

「AWS Startup Tech Meetup 関西」で発表した「小さなお葬式をAWSに移行したお話」に関するスライド です。

Transcript

1. 株式会社ユニクエスト 小さなお葬式を AWSへ移行したお話
2. 自己紹介 名前 ：森 亮太
 
 所属 ：株式会社ユニクエスト 
 　　　　　　　　　 SREチーム テックリード
 
 得意分野 ：クラウドインフラ
 
 AWS保有資格 ：SAA、SAP

3. 会社及びサービスについて • 全国統一料金・セットプランで葬儀が できる、 業界初のウェブ集客型葬儀サービス。 • 2018年の調査以降、5年連続で全国No.1の 葬儀実績※を獲得。 ※TPCマーケティングリサーチ調べ
4. 小さなお葬式 概略図
5. 小さなお葬式 概略図
6. 本日の内容 小さなお葬式のWEBサイトを した際に、上手くいったこと失敗したことをご紹介します 1 オンプレからAWSへ移行 移行したアプリケーションをフル リニューアル 2
7. ２００６年 株式会社ユニクエスト創業 ２００９年 小さなお葬式リリース ２０１５年 入社 ２０１８年 オンプレからAWSに移行 ２０２０年 アプリケーションをリニューアル
8. ２００６年 株式会社ユニクエスト創業 ２００９年 小さなお葬式リリース ２０１５年 入社 ２０１８年 オンプレからAWSに移行 ２０２０年 アプリケーションをリニューアル
9. 入社当時のインフラ構成（2015年）
10. リリースはFTPでの手動アップロード😥 入社当時のインフラ構成（2015年）
11. アプリケーションとDBが同一サーバーに同居😥 入社当時のインフラ構成（2015年）
12. メディアに取り上げられても アクセス集中に耐えられず機会損失していた😥 入社当時のインフラ構成（2015年）
13. 直ぐにでもAWSに移行したかったが…
14. • 当時、会社の成長フェーズとしては成長期を迎えており、新規機能開発 を最優先にする必要があった為、改善タスクの優先度が上がらず実施 出来ずにいた。 （改善タスクとしては、顧客管理システムなどのAWS移行を優先させていた） 直ぐにでもAWSに移行したかったが…
15. ２００６年 株式会社ユニクエスト創業 ２００９年 小さなお葬式リリース ２０１５年 入社 ２０１８年 オンプレからAWSに移行 ２０２０年 アプリケーションをリニューアル
16. • サービスが急激に成長（売上高ベースで5〜10倍）して行くにつれて、 システムがダウンした際の損失も大きくなってきた。 • オンプレのデータセンターで大規模停電が発生した。 （幸い非常用電源でサービスの停止は免れた） なぜこのタイミングで移行したのか？（2018年）
17. 冗長化出来ていない事が会社にとって大 きなリスクとなっていた為、AWSへの移行 を決意
18. • EC2を使用した冗長化構成にする。 • アプリケーションのリニューアルは工数が掛かりすぎる為、 リプラットフォーム※ でAWSへ移行。 • 手動アップロードでのリリースをやめる。 インフラの設計方針（2018年） ※アプリケーションのコアは機能は変更せずに アーキテクチャの一部（DBをRDSに変更など）をクラウドに最適化
19. AWS移行時のインフラ構成（2018年）
20. AWS移行時のインフラ構成（2018年） EC2を使用した冗長化構成に移行😁 （ただしアプリケーションはレガシーな状態）
21. AWS移行時のインフラ構成（2018年） Capistrano※ でデプロイを自動化😁 ※アプリのデプロイ作業を自動化するツールです
22. なんとかAWSへの移行をやり切ったが…
23. 反省点（2018年） • 全ページを一度に移行するビッグバンリリースになったので色々問題が起きて、収 束に時間がかかった。 • 他のアプリケーションも稼働しているAWSアカウントに構築した為、AWSコンソール がごちゃついた。 （ステージング、本番を同じアカウント内で作成した為、ミスが発生しやすい状態に なった）
24. ２００６年 株式会社ユニクエスト創業 ２００９年 小さなお葬式リリース ２０１５年 入社 ２０１８年 オンプレからAWSに移行 ２０２０年 アプリケーションをフルリニューアル
25. • アプリケーションがレガシー過ぎて改修コストが増大し、会社の成長速 度に見合わなくなっていた。 • 軽微な修正でもエンジニアが対応しなければリリース出来ない開発プ ロセスが、エンジニアにとって負担になっていた。 　　　デザイナーが開発する際の問題点 ◦ 開発環境を構築出来ない（構築後もエラーを自己解決出来ない）。 ◦ どのテンプレートを修正すれば良いか分からない。 ◦ デプロイサーバーにログインしてデプロイコマンドを実行出来ない。 なぜこのタイミングでフルリニューアルしたのか？（2020年）
26. • デザイナーでも開発〜リリースまで行える様にする。 • 開発環境をコンテナに変える事になったので、それに合わせてインフラ もECSに変更する。 • 前回の反省点をふまえて ◦ ページ単位での段階的リリースを行う ◦ AWSアカウントを分離する 　 を実施する。 インフラの設計方針（2020年）
27. フルリニューアル時のインフラ構成（2020年）
28. フルリニューアル時のインフラ構成（2020年） オンプレからAWSへ移行した際のインフラ
29. フルリニューアル時のインフラ構成（2020年） 新規のAWSアカウントで構築😁 （ステージングと本番もアカウント分けた）
30. フルリニューアル時のインフラ構成（2020年） アプリケーションをフロントエンド Nuxt.js（S3）、 バックエンド PHP8（ECS）のモダンな構成に移行できた😁
31. フルリニューアル時のインフラ構成（2020年） CloudFrontのビヘイビアで段階的なリリースを実現😁
32. フルリニューアル時のインフラ構成（2020年） ステージング、本番はCircleCIでの自動デプロイ😁 Cloud9、Amplifyでデザイナーの 開発環境を用意😁
33. フルリニューアル時のインフラ構成（2020年） Datadogでモニタリング😁 インフラをTerraformでコード化😁 EventBridge + StepFunctionsでバッチ処理を実装😁
34. フルリニューアル作業は 現在も絶賛進行中です
35. 最後にお伝えしたいこと • 出来るだけ小さく段階的に移行する事を検討した方が良い ◦ 問題が起きた際の影響が最小限に抑えられます • AWSアカウントは後で変更するのは大変なので初期設計が大事 ◦ サービス毎にアカウントを分ける（ステージングと本番も分ける） ▪ AWSアカウントが増えていく為、初めから AWS Control Towerで管理した方が良い • 経営層やビジネス部門と対話して改善タスクの優先度を上げる ◦ 一番状況を把握出来ている現場のエンジニアが 経営層に伝える事が大事です ▪ 経営層がシステムに詳しくない場合は 静的解析ツール（PhpMetricsなど）で可視化して伝え るのも良い
36. 以上です ご清聴ありがとうございました