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