ECサイト（小規模）のリニューアルを一人でやりきった話
◼️概要
みなさん、こんにちは。
アスタスタでソフトウェアエンジニアをしている塚本です。
私が以前に手がけたECサイトのリニューアルを行うことになり、約2年かかって完了しました。
書籍のチュートリアルや ChatGPT をはじめとするAIの力を借りて、なんとかリリースまで持っていけましたので、その道のりを書き残しておこうと思います。
Nuxt.js で作られたECサイトをリニューアル
今回手がけることになったのは、2019年にローンチしたECサイトのリニューアル案件でした。
当時も私一人で制作したのですが、ちょうど Nuxt.js についてよく聞く頃だったことと、個人的にも SPA（SSR）サイトに興味があったことから Nuxt.js を使うことにしました。
サイトは受注生産のためのECシステムで、購入フローなども独特なものだったため、既存のEC構築パッケージやオンラインショップでの展開が難しいものでした。
以前にEC-Cubeを触っていたことがあったので、構造を参考にしながらほぼフルスクラッチで構築していました。
そのサイトが古くなり、デザインも変更したいという要望がありました。
Next.js v2系はサポート切れが近く（当時）、デプロイ先が海外サーバーであったことからレスポンスも良くなかったため、AWS東京リージョンに新しいアプリを作成することになりました。
Nest.js & Next.js
サイトには React を採用し、利便性から React のフレームワークである Next.js を使うことにしました。個人的に React を使うことが増えてきていること、Nuxt.js v3系は大幅に変わってしまったという話をよく聞いていたため、React / Next.js に乗り換えることを決定しました。
また、Nuxt.js v2系では Express を使って API を作ることができていたため、バックエンド処理を記述することができていましたが、Nuxt.js v3系では同様の作り方ができないようだったので Nest.js による API サーバーも作ることにしました。
バックエンドとフロントエンド、どちらも TypeScript で記述できることもこの組み合わせにした理由です。
ORM の変更
元プロジェクトでは ORM に Sequelize を使っていましたが、TypeScript に対応している ORM に変えたいと考え、 Prisma に乗り換えることにしました。
API の移植
Express で書いていた API は、Nest.js に適合するように書き直しました。
とはいっても JavaScript で書かれているため、コピペしてから修正という流れになります。
Sequelize から Prisma に移行する部分はどうしても書き換えが必要ですが、メソッドが似通っているため大幅な修正はあまりなかったです。
TypeScript 化のために型を割り当てるのが面倒でしたが、曖昧さを減らせるという点でよかったと思います。
Nest.js ではモジュールという単位で機能分割を行うことになります。
受注、金額計算、問い合わせ、アップロードなどの機能ごとにモジュールを分けています。
もともとのAPIもモジュール化を考慮して作っていたので移植はスムーズでした。
Nuxt から Next
Nuxt で書かれた旧サイトは Vuetify を使用していました。
コンポーネントが豊富なことと、スタイルの適用が割と直感的にできたためです。
これを今回、Next.js に書き換えていきました。
Next.js では App Router を使用しています。
制作を始めたころ、 shadcn/ui が盛り上がっているという話を聞き、実際に使ったところ非常に使いやすかったため UI ライブラリとして採用しました。
コンポーネントの種類が豊富な上に Tailwind CSS を使ったスタイルが適用されていて、そのまま使っても問題のないライブラリでした。ただ、支給されたデザインに合わせるために微調整は行なっています。
コンテナ用 AWS インフラ構築
別案件の話ですが、 Elastic Container Service(ECS) で運用しているアプリがあります。
Nuxt.js v2 で作られたアプリを動かしているため、今回もコンテナを使おうと考えていました。
この環境は私が作ったものではなかったため、自分で作れるようになるための勉強が必要でした。
参考書として以下の本を読み、チュートリアルをやることにしたのですが非常に勉強になりました。基本的なインフラは CloudFormation で構築を行い、そのあとの設定はマネジメントコンソールから行なっていくというスタイルです。
AWSコンテナ設計・構築[本格]入門 | SBクリエイティブ
チュートリアルに出てくる構成は、バックエンドとフロントエンドそれぞれを ECS Fargate で稼働させるというもので、まさに私がやろうとしているものだったのです。
VPC を作り、サブネットを適切に分割し、ロードバランサーを配置してアプリケーションに接続するという方法を学べたのは、実際の構築時に役立ちました。
インフラを Terraform で構築
しかし、環境を作るのにマネジメントコンソールでポチポチやっていくのは正直しんどかったです。コンテナが立ち上がってもポート番号が違って接続できない、セキュリティグループの設定が間違っていてこれまた接続できない、などなど。
さらに本番環境だけでなくステージング環境を作ることになっていたため、同じことの繰り返しの辛さに加えて間違える可能性が高いことから、コードによる環境構築にチャレンジしてみることにしました。 Infrastructure as Code(IaC) というやつですね。
この分野は経験がなかったのですが、いろいろなところで話を聞くことが多かった Terraform を使ってみることにしました。書籍を買って手を動かすことで理解が進んでいきましたが、それでも分からないことは ChatGPT に教えてもらいました。
基本的なインフラ部分はコンテナ本の CloudFormation のコードを参考にして、というよりは ChatGPT に Terraform 用コードに変換してもらいました。
ただ、モジュール化をしたかったので CloudFormation を丸ごと変換してもらうのではなく、モジュール単位でコードの意味を教えてもらいながら作っていった感じです。
この作業で AWS リソースの関連性などを具体的にイメージできるようになったと思っています。
また、モジュール化を進めていったため、本番環境とステージング環境それぞれでモジュールを使うコードを定義し、与える変数の値を変えることで簡単に別環境を作れるようになりました。
IaC の威力と便利さを覚えてしまったため、社内プロジェクトで使えるようなテンプレートをいくつか作りたいと思っています。
CI/CDパイプライン
前述の別案件でコンテナアプリを動かしているのですが、コンテナイメージはローカル環境でビルドを行なっています。そして環境ごとにイメージをプッシュしているのですが、ある時プッシュ先を間違えてしまうという事故を起こしてしまいました。
手動で行う作業ではこういった間違いが起こる可能性があります。
その解決策として、AWS の提供する CI/CD を利用することにしました。
GitHub の特定のブランチにプッシュされると、それをトリガーとして AWS 内でビルド、イメージのプッシュとデプロイを自動化してくれるというもので、コンテナ本のチュートリアルにあったものを参考にしています。
プッシュするブランチを間違えなければ、あとは自動でデプロイまで完了できるので安全で便利です。
今まで使ってこなかったのが勿体無いと思えるほどです。
この構成は最初マネジメントコンソールから手動で構築したのですが、Terraform のインポート機能を使ってコード化を行い、コードから構築ができるようにしました。
別環境を作る時に CI/CD パイプラインも含まれているのは便利すぎました！
◼️まとめ
アプリケーションの作り直しからインフラの構築まで、一人でやりきれるか不安はありました。
しかし書籍や AI の助けを借りたりして何とか達成できました。
これまでやったことのない技術を取り入れるのは大変でしたが、そのおかげでミスのない作業を実現することができ、満足しています。
この経験を他の業務でも活かせるよう、まずは Terraform から社内に導入していきたいと思っています
Discussion