Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
小さなお葬式をAWSに移行したお話
Search
森亮太
January 17, 2023
Technology
2
500
小さなお葬式をAWSに移行したお話
「AWS Startup Tech Meetup 関西」で発表した「小さなお葬式をAWSに移行したお話」に関するスライド です。
森亮太
January 17, 2023
Tweet
Share
Other Decks in Technology
See All in Technology
CARTA HOLDINGS エンジニア向け 採用ピッチ資料 / CARTA-GUIDE-for-Engineers
carta_engineering
0
27k
Dataverseの検索列について
miyakemito
1
180
AIにおけるソフトウェアテスト_ver1.00
fumisuke
1
360
kernelvm-brain-net
raspython3
0
430
Notion x ポストモーテムで広げる組織の学び / Notion x Postmortem
isaoshimizu
1
150
Previewでもここまで追える! Azure AI Foundryで始めるLLMトレース
tomodo_ysys
2
540
非root化Androidスマホでも動く仮想マシンアプリを試してみた
arkw
0
120
正式リリースされた Semantic Kernel の Agent Framework 全部紹介!
okazuki
1
920
Новые мапы в Go. Вова Марунин, Clatch, МТС
lamodatech
0
1.9k
MySQL InnoDB Data Recovery - The Last Resort
lefred
0
110
テストって楽しい!開発を加速させるテストの魅力 / Testing is Fun! The Fascinating of Testing to Accelerate Development
aiandrox
0
160
Databricksで完全履修!オールインワンレイクハウスは実在した!
akuwano
0
150
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
105
19k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Rails Girls Zürich Keynote
gr2m
94
13k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
33k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
420
KATA
mclloyd
29
14k
[RailsConf 2023] Rails as a piece of cake
palkan
54
5.5k
BBQ
matthewcrist
88
9.6k
Transcript
株式会社ユニクエスト 小さなお葬式を AWSへ移行したお話
自己紹介 名前 :森 亮太 所属 :株式会社ユニクエスト SREチーム
テックリード 得意分野 :クラウドインフラ AWS保有資格 :SAA、SAP
会社及びサービスについて • 全国統一料金・セットプランで葬儀が できる、 業界初のウェブ集客型葬儀サービス。 • 2018年の調査以降、5年連続で全国No.1の 葬儀実績※を獲得。 ※TPCマーケティングリサーチ調べ
小さなお葬式 概略図
小さなお葬式 概略図
本日の内容 小さなお葬式のWEBサイトを した際に、上手くいったこと失敗したことをご紹介します 1 オンプレからAWSへ移行 移行したアプリケーションをフル リニューアル 2
2006年 株式会社ユニクエスト創業 2009年 小さなお葬式リリース 2015年 入社 2018年 オンプレからAWSに移行 2020年 アプリケーションをリニューアル
2006年 株式会社ユニクエスト創業 2009年 小さなお葬式リリース 2015年 入社 2018年 オンプレからAWSに移行 2020年 アプリケーションをリニューアル
入社当時のインフラ構成(2015年)
リリースはFTPでの手動アップロード😥 入社当時のインフラ構成(2015年)
アプリケーションとDBが同一サーバーに同居😥 入社当時のインフラ構成(2015年)
メディアに取り上げられても アクセス集中に耐えられず機会損失していた😥 入社当時のインフラ構成(2015年)
直ぐにでもAWSに移行したかったが…
• 当時、会社の成長フェーズとしては成長期を迎えており、新規機能開発 を最優先にする必要があった為、改善タスクの優先度が上がらず実施 出来ずにいた。 (改善タスクとしては、顧客管理システムなどのAWS移行を優先させていた) 直ぐにでもAWSに移行したかったが…
2006年 株式会社ユニクエスト創業 2009年 小さなお葬式リリース 2015年 入社 2018年 オンプレからAWSに移行 2020年 アプリケーションをリニューアル
• サービスが急激に成長(売上高ベースで5〜10倍)して行くにつれて、 システムがダウンした際の損失も大きくなってきた。 • オンプレのデータセンターで大規模停電が発生した。 (幸い非常用電源でサービスの停止は免れた) なぜこのタイミングで移行したのか?(2018年)
冗長化出来ていない事が会社にとって大 きなリスクとなっていた為、AWSへの移行 を決意
• EC2を使用した冗長化構成にする。 • アプリケーションのリニューアルは工数が掛かりすぎる為、 リプラットフォーム※ でAWSへ移行。 • 手動アップロードでのリリースをやめる。 インフラの設計方針(2018年) ※アプリケーションのコアは機能は変更せずに
アーキテクチャの一部(DBをRDSに変更など)をクラウドに最適化
AWS移行時のインフラ構成(2018年)
AWS移行時のインフラ構成(2018年) EC2を使用した冗長化構成に移行😁 (ただしアプリケーションはレガシーな状態)
AWS移行時のインフラ構成(2018年) Capistrano※ でデプロイを自動化😁 ※アプリのデプロイ作業を自動化するツールです
なんとかAWSへの移行をやり切ったが…
反省点(2018年) • 全ページを一度に移行するビッグバンリリースになったので色々問題が起きて、収 束に時間がかかった。 • 他のアプリケーションも稼働しているAWSアカウントに構築した為、AWSコンソール がごちゃついた。 (ステージング、本番を同じアカウント内で作成した為、ミスが発生しやすい状態に なった)
2006年 株式会社ユニクエスト創業 2009年 小さなお葬式リリース 2015年 入社 2018年 オンプレからAWSに移行 2020年 アプリケーションをフルリニューアル
• アプリケーションがレガシー過ぎて改修コストが増大し、会社の成長速 度に見合わなくなっていた。 • 軽微な修正でもエンジニアが対応しなければリリース出来ない開発プ ロセスが、エンジニアにとって負担になっていた。 デザイナーが開発する際の問題点 ◦ 開発環境を構築出来ない(構築後もエラーを自己解決出来ない)。 ◦
どのテンプレートを修正すれば良いか分からない。 ◦ デプロイサーバーにログインしてデプロイコマンドを実行出来ない。 なぜこのタイミングでフルリニューアルしたのか?(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など)で可視化して伝え るのも良い
以上です ご清聴ありがとうございました