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 full-size slide

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


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

              SREチーム テックリード


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


    AWS保有資格 :SAA、SAP


    View full-size slide

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

    View full-size slide

  4. 小さなお葬式 概略図

    View full-size slide

  5. 小さなお葬式 概略図

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide