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
480
小さなお葬式をAWSに移行したお話
「AWS Startup Tech Meetup 関西」で発表した「小さなお葬式をAWSに移行したお話」に関するスライド です。
森亮太
January 17, 2023
Tweet
Share
Other Decks in Technology
See All in Technology
Fintech SREの挑戦 PCI DSS対応をスマートにこなすインフラ戦略/Fintech SRE’s Challenge: Smart Infrastructure Strategies for PCI DSS Compliance
maaaato
0
450
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
890
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.4k
データの品質が低いと何が困るのか
kzykmyzw
6
1k
家電アプリ共通PF "Linova" のAPI利用とPostman活用事例ご紹介
yukiogawa
0
130
スクラムのイテレーションを導入してチームの雰囲気がより良くなった話
eccyun
0
110
30分でわかる『アジャイルデータモデリング』
hanon52_
9
2.2k
日経電子版 x AIエージェントの可能性とAgentic RAGによって提案書生成を行う技術
masahiro_nishimi
1
290
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
kanny
3
410
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
1
1.3k
目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts
soudai
22
5.8k
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
130
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
31
2.1k
Making Projects Easy
brettharned
116
6k
Designing for humans not robots
tammielis
250
25k
Scaling GitHub
holman
459
140k
Optimising Largest Contentful Paint
csswizardry
34
3.1k
GitHub's CSS Performance
jonrohan
1030
460k
GraphQLとの向き合い方2022年版
quramy
44
13k
Six Lessons from altMBA
skipperchong
27
3.6k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
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など)で可視化して伝え るのも良い
以上です ご清聴ありがとうございました