Upgrade to Pro — share decks privately, control downloads, hide ads and more …

小さなお葬式をAWSに移行したお話

森亮太
January 17, 2023

 小さなお葬式をAWSに移行したお話

「AWS Startup Tech Meetup 関西」で発表した「小さなお葬式をAWSに移行したお話」に関するスライド です。

森亮太

January 17, 2023
Tweet

Other Decks in Technology

Transcript

  1. 株式会社ユニクエスト
    小さなお葬式を
    AWSへ移行したお話

    View Slide

  2. 自己紹介
    名前 :森 亮太


    所属 :株式会社ユニクエスト 

              SREチーム テックリード


    得意分野 :クラウドインフラ


    AWS保有資格 :SAA、SAP


    View Slide

  3. 会社及びサービスについて
    ● 全国統一料金・セットプランで葬儀が
    できる、
    業界初のウェブ集客型葬儀サービス。
    ● 2018年の調査以降、5年連続で全国No.1の
    葬儀実績※を獲得。
    ※TPCマーケティングリサーチ調べ

    View Slide

  4. 小さなお葬式 概略図

    View Slide

  5. 小さなお葬式 概略図

    View Slide

  6. 本日の内容
    小さなお葬式のWEBサイトを
    した際に、上手くいったこと失敗したことをご紹介します
    1 オンプレからAWSへ移行
    移行したアプリケーションをフル
    リニューアル
    2

    View Slide

  7. 2006年
    株式会社ユニクエスト創業
    2009年
    小さなお葬式リリース
    2015年
    入社
    2018年
    オンプレからAWSに移行
    2020年
    アプリケーションをリニューアル

    View Slide

  8. 2006年
    株式会社ユニクエスト創業
    2009年
    小さなお葬式リリース
    2015年
    入社
    2018年
    オンプレからAWSに移行
    2020年
    アプリケーションをリニューアル

    View Slide

  9. 入社当時のインフラ構成(2015年)

    View Slide

  10. リリースはFTPでの手動アップロード😥
    入社当時のインフラ構成(2015年)

    View Slide

  11. アプリケーションとDBが同一サーバーに同居😥
    入社当時のインフラ構成(2015年)

    View Slide

  12. メディアに取り上げられても
    アクセス集中に耐えられず機会損失していた😥
    入社当時のインフラ構成(2015年)

    View Slide

  13. 直ぐにでもAWSに移行したかったが…

    View Slide

  14. ● 当時、会社の成長フェーズとしては成長期を迎えており、新規機能開発
    を最優先にする必要があった為、改善タスクの優先度が上がらず実施
    出来ずにいた。
    (改善タスクとしては、顧客管理システムなどのAWS移行を優先させていた)
    直ぐにでもAWSに移行したかったが…

    View Slide

  15. 2006年
    株式会社ユニクエスト創業
    2009年
    小さなお葬式リリース
    2015年
    入社
    2018年
    オンプレからAWSに移行
    2020年
    アプリケーションをリニューアル

    View Slide

  16. ● サービスが急激に成長(売上高ベースで5〜10倍)して行くにつれて、
    システムがダウンした際の損失も大きくなってきた。
    ● オンプレのデータセンターで大規模停電が発生した。
    (幸い非常用電源でサービスの停止は免れた)
    なぜこのタイミングで移行したのか?(2018年)

    View Slide

  17. 冗長化出来ていない事が会社にとって大
    きなリスクとなっていた為、AWSへの移行
    を決意

    View Slide

  18. ● EC2を使用した冗長化構成にする。
    ● アプリケーションのリニューアルは工数が掛かりすぎる為、
    リプラットフォーム※
    でAWSへ移行。
    ● 手動アップロードでのリリースをやめる。
    インフラの設計方針(2018年)
    ※アプリケーションのコアは機能は変更せずに
    アーキテクチャの一部(DBをRDSに変更など)をクラウドに最適化

    View Slide

  19. AWS移行時のインフラ構成(2018年)

    View Slide

  20. AWS移行時のインフラ構成(2018年)
    EC2を使用した冗長化構成に移行😁
    (ただしアプリケーションはレガシーな状態)

    View Slide

  21. AWS移行時のインフラ構成(2018年)
    Capistrano※
    でデプロイを自動化😁
    ※アプリのデプロイ作業を自動化するツールです

    View Slide

  22. なんとかAWSへの移行をやり切ったが…

    View Slide

  23. 反省点(2018年)
    ● 全ページを一度に移行するビッグバンリリースになったので色々問題が起きて、収
    束に時間がかかった。
    ● 他のアプリケーションも稼働しているAWSアカウントに構築した為、AWSコンソール
    がごちゃついた。
    (ステージング、本番を同じアカウント内で作成した為、ミスが発生しやすい状態に
    なった)

    View Slide

  24. 2006年
    株式会社ユニクエスト創業
    2009年
    小さなお葬式リリース
    2015年
    入社
    2018年
    オンプレからAWSに移行
    2020年
    アプリケーションをフルリニューアル

    View Slide

  25. ● アプリケーションがレガシー過ぎて改修コストが増大し、会社の成長速
    度に見合わなくなっていた。
    ● 軽微な修正でもエンジニアが対応しなければリリース出来ない開発プ
    ロセスが、エンジニアにとって負担になっていた。
       デザイナーが開発する際の問題点
    ○ 開発環境を構築出来ない(構築後もエラーを自己解決出来ない)。
    ○ どのテンプレートを修正すれば良いか分からない。
    ○ デプロイサーバーにログインしてデプロイコマンドを実行出来ない。
    なぜこのタイミングでフルリニューアルしたのか?(2020年)

    View Slide

  26. ● デザイナーでも開発〜リリースまで行える様にする。
    ● 開発環境をコンテナに変える事になったので、それに合わせてインフラ
    もECSに変更する。
    ● 前回の反省点をふまえて
    ○ ページ単位での段階的リリースを行う
    ○ AWSアカウントを分離する
      を実施する。
    インフラの設計方針(2020年)

    View Slide

  27. フルリニューアル時のインフラ構成(2020年)

    View Slide

  28. フルリニューアル時のインフラ構成(2020年)
    オンプレからAWSへ移行した際のインフラ

    View Slide

  29. フルリニューアル時のインフラ構成(2020年)
    新規のAWSアカウントで構築😁
    (ステージングと本番もアカウント分けた)

    View Slide

  30. フルリニューアル時のインフラ構成(2020年)
    アプリケーションをフロントエンド Nuxt.js(S3)、
    バックエンド PHP8(ECS)のモダンな構成に移行できた😁

    View Slide

  31. フルリニューアル時のインフラ構成(2020年)
    CloudFrontのビヘイビアで段階的なリリースを実現😁

    View Slide

  32. フルリニューアル時のインフラ構成(2020年)
    ステージング、本番はCircleCIでの自動デプロイ😁
    Cloud9、Amplifyでデザイナーの
    開発環境を用意😁

    View Slide

  33. フルリニューアル時のインフラ構成(2020年)
    Datadogでモニタリング😁
    インフラをTerraformでコード化😁
    EventBridge + StepFunctionsでバッチ処理を実装😁

    View Slide

  34. フルリニューアル作業は
    現在も絶賛進行中です

    View Slide

  35. 最後にお伝えしたいこと
    ● 出来るだけ小さく段階的に移行する事を検討した方が良い
    ○ 問題が起きた際の影響が最小限に抑えられます
    ● AWSアカウントは後で変更するのは大変なので初期設計が大事
    ○ サービス毎にアカウントを分ける(ステージングと本番も分ける)
    ■ AWSアカウントが増えていく為、初めから AWS Control Towerで管理した方が良い
    ● 経営層やビジネス部門と対話して改善タスクの優先度を上げる
    ○ 一番状況を把握出来ている現場のエンジニアが
    経営層に伝える事が大事です
    ■ 経営層がシステムに詳しくない場合は 静的解析ツール(PhpMetricsなど)で可視化して伝え
    るのも良い

    View Slide

  36. 以上です
    ご清聴ありがとうございました

    View Slide