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
530
小さなお葬式をAWSに移行したお話
「AWS Startup Tech Meetup 関西」で発表した「小さなお葬式をAWSに移行したお話」に関するスライド です。
森亮太
January 17, 2023
Tweet
Share
Other Decks in Technology
See All in Technology
見てわかるテスト駆動開発
recruitengineers
PRO
6
1.8k
Microsoft Fabric のネットワーク保護のアップデートについて
ryomaru0825
1
110
【 LLMエンジニアがヒューマノイド開発に挑んでみた 】 - 第104回 Machine Learning 15minutes! Hybrid
soneo1127
0
160
AI時代に非連続な成長を実現するエンジニアリング戦略
sansantech
PRO
1
100
AIエージェント就活入門 - MCPが履歴書になる未来
eltociear
0
640
AIエージェントの開発に必須な「コンテキスト・エンジニアリング」とは何か──プロンプト・エンジニアリングとの違いを手がかりに考える
masayamoriofficial
0
450
Devinを使ったモバイルアプリ開発 / Mobile app development with Devin
yanzm
0
210
実践データベース設計 ①データベース設計概論
recruitengineers
PRO
4
1.2k
認知戦の理解と、市民としての対抗策
hogehuga
0
400
アジャイルテストで高品質のスプリントレビューを
takesection
0
140
衝突して強くなる! BLUE GIANTと アジャイルチームの共通点とは ― いきいきと活気に満ちたグルーヴあるチームを作るコツ ― / BLUE GIANT and Agile Teams
naitosatoshi
0
170
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
30k
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
For a Future-Friendly Web
brad_frost
179
9.9k
Optimizing for Happiness
mojombo
379
70k
Embracing the Ebb and Flow
colly
87
4.8k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Become a Pro
speakerdeck
PRO
29
5.5k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Automating Front-end Workflow
addyosmani
1370
200k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
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など)で可視化して伝え るのも良い
以上です ご清聴ありがとうございました