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

Slide 1

Slide 1 text

株式会社ユニクエスト小さなお葬式を AWSへ移行したお話

Slide 2

Slide 2 text

自己紹介名前：森亮太    所属：株式会社ユニクエスト   　　　　　　　　　 SREチームテックリード    得意分野：クラウドインフラ    AWS保有資格：SAA、SAP 

Slide 3

Slide 3 text

会社及びサービスについて ● 全国統一料金・セットプランで葬儀ができる、業界初のウェブ集客型葬儀サービス。 ● 2018年の調査以降、5年連続で全国No.1の葬儀実績※を獲得。 ※TPCマーケティングリサーチ調べ

Slide 4

Slide 4 text

小さなお葬式概略図

Slide 5

Slide 5 text

小さなお葬式概略図

Slide 6

Slide 6 text

本日の内容小さなお葬式のWEBサイトをした際に、上手くいったこと失敗したことをご紹介します 1 オンプレからAWSへ移行移行したアプリケーションをフルリニューアル 2

Slide 7

Slide 7 text

２００６年株式会社ユニクエスト創業２００９年小さなお葬式リリース２０１５年入社２０１８年オンプレからAWSに移行２０２０年アプリケーションをリニューアル

Slide 8

Slide 8 text

Slide 9

Slide 9 text

入社当時のインフラ構成（2015年）

Slide 10

Slide 10 text

リリースはFTPでの手動アップロード😥 入社当時のインフラ構成（2015年）

Slide 11

Slide 11 text

アプリケーションとDBが同一サーバーに同居😥 入社当時のインフラ構成（2015年）

Slide 12

Slide 12 text

メディアに取り上げられてもアクセス集中に耐えられず機会損失していた😥 入社当時のインフラ構成（2015年）

Slide 13

Slide 13 text

直ぐにでもAWSに移行したかったが…

Slide 14

Slide 14 text

● 当時、会社の成長フェーズとしては成長期を迎えており、新規機能開発を最優先にする必要があった為、改善タスクの優先度が上がらず実施出来ずにいた。（改善タスクとしては、顧客管理システムなどのAWS移行を優先させていた）直ぐにでもAWSに移行したかったが…

Slide 15

Slide 15 text

Slide 16

Slide 16 text

● サービスが急激に成長（売上高ベースで5〜10倍）して行くにつれて、システムがダウンした際の損失も大きくなってきた。 ● オンプレのデータセンターで大規模停電が発生した。（幸い非常用電源でサービスの停止は免れた）なぜこのタイミングで移行したのか？（2018年）

Slide 17

Slide 17 text

冗長化出来ていない事が会社にとって大きなリスクとなっていた為、AWSへの移行を決意

Slide 18

Slide 18 text

● EC2を使用した冗長化構成にする。 ● アプリケーションのリニューアルは工数が掛かりすぎる為、リプラットフォーム※ でAWSへ移行。 ● 手動アップロードでのリリースをやめる。インフラの設計方針（2018年） ※アプリケーションのコアは機能は変更せずにアーキテクチャの一部（DBをRDSに変更など）をクラウドに最適化

Slide 19

Slide 19 text

AWS移行時のインフラ構成（2018年）

Slide 20

Slide 20 text

AWS移行時のインフラ構成（2018年） EC2を使用した冗長化構成に移行😁 （ただしアプリケーションはレガシーな状態）

Slide 21

Slide 21 text

AWS移行時のインフラ構成（2018年） Capistrano※ でデプロイを自動化😁 ※アプリのデプロイ作業を自動化するツールです

Slide 22

Slide 22 text

なんとかAWSへの移行をやり切ったが…

Slide 23

Slide 23 text

反省点（2018年） ● 全ページを一度に移行するビッグバンリリースになったので色々問題が起きて、収束に時間がかかった。 ● 他のアプリケーションも稼働しているAWSアカウントに構築した為、AWSコンソールがごちゃついた。（ステージング、本番を同じアカウント内で作成した為、ミスが発生しやすい状態になった）

Slide 24

Slide 24 text

２００６年株式会社ユニクエスト創業２００９年小さなお葬式リリース２０１５年入社２０１８年オンプレからAWSに移行２０２０年アプリケーションをフルリニューアル

Slide 25

Slide 25 text

● アプリケーションがレガシー過ぎて改修コストが増大し、会社の成長速度に見合わなくなっていた。 ● 軽微な修正でもエンジニアが対応しなければリリース出来ない開発プロセスが、エンジニアにとって負担になっていた。　　　デザイナーが開発する際の問題点 ○ 開発環境を構築出来ない（構築後もエラーを自己解決出来ない）。 ○ どのテンプレートを修正すれば良いか分からない。 ○ デプロイサーバーにログインしてデプロイコマンドを実行出来ない。なぜこのタイミングでフルリニューアルしたのか？（2020年）

Slide 26

Slide 26 text

● デザイナーでも開発〜リリースまで行える様にする。 ● 開発環境をコンテナに変える事になったので、それに合わせてインフラもECSに変更する。 ● 前回の反省点をふまえて ○ ページ単位での段階的リリースを行う ○ AWSアカウントを分離する　を実施する。インフラの設計方針（2020年）

Slide 27

Slide 27 text

フルリニューアル時のインフラ構成（2020年）

Slide 28

Slide 28 text

フルリニューアル時のインフラ構成（2020年）オンプレからAWSへ移行した際のインフラ

Slide 29

Slide 29 text

フルリニューアル時のインフラ構成（2020年）新規のAWSアカウントで構築😁 （ステージングと本番もアカウント分けた）

Slide 30

Slide 30 text

フルリニューアル時のインフラ構成（2020年）アプリケーションをフロントエンド Nuxt.js（S3）、バックエンド PHP8（ECS）のモダンな構成に移行できた😁

Slide 31

Slide 31 text

フルリニューアル時のインフラ構成（2020年） CloudFrontのビヘイビアで段階的なリリースを実現😁

Slide 32

Slide 32 text

フルリニューアル時のインフラ構成（2020年）ステージング、本番はCircleCIでの自動デプロイ😁 Cloud9、Amplifyでデザイナーの開発環境を用意😁

Slide 33

Slide 33 text

フルリニューアル時のインフラ構成（2020年） Datadogでモニタリング😁 インフラをTerraformでコード化😁 EventBridge + StepFunctionsでバッチ処理を実装😁

Slide 34

Slide 34 text

フルリニューアル作業は現在も絶賛進行中です

Slide 35

Slide 35 text

最後にお伝えしたいこと ● 出来るだけ小さく段階的に移行する事を検討した方が良い ○ 問題が起きた際の影響が最小限に抑えられます ● AWSアカウントは後で変更するのは大変なので初期設計が大事 ○ サービス毎にアカウントを分ける（ステージングと本番も分ける） ■ AWSアカウントが増えていく為、初めから AWS Control Towerで管理した方が良い ● 経営層やビジネス部門と対話して改善タスクの優先度を上げる ○ 一番状況を把握出来ている現場のエンジニアが経営層に伝える事が大事です ■ 経営層がシステムに詳しくない場合は静的解析ツール（PhpMetricsなど）で可視化して伝えるのも良い

Slide 36

Slide 36 text

以上ですご清聴ありがとうございました