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
540
小さなお葬式をAWSに移行したお話
「AWS Startup Tech Meetup 関西」で発表した「小さなお葬式をAWSに移行したお話」に関するスライド です。
森亮太
January 17, 2023
Tweet
Share
Other Decks in Technology
See All in Technology
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
440
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
270
Modern Linux
oracle4engineer
PRO
0
150
まずはマネコンでちゃちゃっと作ってから、それをCDKにしてみよか。
yamada_r
2
120
5年目から始める Vue3 サイト改善 #frontendo
tacck
PRO
3
220
Firestore → Spanner 移行 を成功させた段階的移行プロセス
athug
1
490
roppongirb_20250911
igaiga
1
240
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
340
Webブラウザ向け動画配信プレイヤーの 大規模リプレイスから得た知見と学び
yud0uhu
0
230
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
260
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
270
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
580
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
820
Agile that works and the tools we love
rasmusluckow
330
21k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
920
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
Docker and Python
trallard
46
3.6k
How STYLIGHT went responsive
nonsquared
100
5.8k
KATA
mclloyd
32
14k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
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など)で可視化して伝え るのも良い
以上です ご清聴ありがとうございました