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
420
小さなお葬式をAWSに移行したお話
「AWS Startup Tech Meetup 関西」で発表した「小さなお葬式をAWSに移行したお話」に関するスライド です。
森亮太
January 17, 2023
Tweet
Share
Other Decks in Technology
See All in Technology
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
soudai
20
5k
滑空スポーツ講習会2023 航空安全講習会 第4回 日常整備に役立ちそうな雑情報 / JSA Safety Seminar 2023 glider maintenance
jsaseminar
0
110
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
0
1.1k
AWS IAM の結果整合性を避けるためセッションポリシーを用いてポリシーの動作確認を行う、を解説する
yukihirochiba
0
380
AIエージェントが変えるソフトウェアのパラダイム
masahiro_nishimi
0
200
人工衛星管制システムにおけるCICD / CICD in satellite control systems
iselegant
5
900
小さく始めるAnsible
stopendy
0
210
サイボウズのQAエンジニア育成
cybozuinsideout
PRO
3
570
なんでもかんでもコンテナ化すればいいってもんでもないけど なんでもかんでもコンテナ化したらスッキリしました
saramune
1
160
Beginner's Guide to Partitioning vs. Sharding in Postgres | Claire Giordano | Nordic PGDay 2024
clairegiordano
0
210
Node-AI のリッチな WEB フロントエンドを支える技術
nenonaninu
2
980
10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡 / legacy-php-app-migration
toshimaru
0
710
Featured
See All Featured
Docker and Python
trallard
33
2.6k
Web Components: a chance to create the future
zenorocha
304
41k
Designing for humans not robots
tammielis
247
25k
Optimizing for Happiness
mojombo
369
69k
For a Future-Friendly Web
brad_frost
170
8.8k
How to train your dragon (web standard)
notwaldorf
71
5k
Happy Clients
brianwarren
91
6.3k
Typedesign – Prime Four
hannesfritz
36
2k
Fireside Chat
paigeccino
19
2.5k
How to Ace a Technical Interview
jacobian
272
22k
In The Pink: A Labor of Love
frogandcode
137
21k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
242
20k
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など)で可視化して伝え るのも良い
以上です ご清聴ありがとうございました