TANP Blog

株式会社Graciaが運営するギフトEC「TANP」の開発ブログです。

【エンジニア】会員ランクプロジェクトの振り返り

こんにちは、WEBエンジニア・UX(EC)アーキテクトの安達です。

TANPでは2021年4月に「会員ランク機能」がリリースされ、過去の購入金額を元に決定した「ランク」によりポイント還元率がアップする等の特典が受けられるようになりました。その際、「PHP8.0」「Laravel」「ECS」の導入を新たに行ったため、今回は導入の背景やメリットについてお話ししたいと思います。

 

f:id:gracia_tanp:20210430134833p:plain

TANPの会員ランクについて:https://tanp.jp/pages/member-rank

 

1.Laravel、PHP8.0の導入

TANPのシステムの大部分はモノリシックレポジトリで密結合な実装になっており、規模の拡大と共にソースコードを変更した際の影響範囲の予測が難しくなりつつあるという課題がありました。そこで、将来的な保守性の観点から既存のレポジトリに会員のランクの機能を実装するのはなく、別レポジトリにマイクロサービスとして切り出す結論に至りました。

このため、新しいレポジトリではTANPの既存システムの大部分で採用されているCakePHPではなく、PHPのフレームワークとして主流になりつつあるLaravelを採用することが出来ました。また、PHPのバージョンも当時最新のPHP8.0を採用しています。Go言語を取り入れてみようという案もありましたが、後述するECSの導入も控えており、今回のタイミングでは新しい言語を採用するチャレンジは見送ることとなりました。

 

Laravel、PHP8.0を導入して感じたメリット・デメリット

メリット

LaravelにはDIコンテナやDBのRead/Writeの自動切り替え、Slackへのエラー通知の容易さ等、CakePHP3系にはない便利な機能があり重宝しています。今回はバッチ処理が中心のためまだまだ活用しきれていないのですが、Web側でも活用できそうな機能が豊富にありワクワクしています。

PHP8.0については、プロパティの型宣言、コンストラクタのプロパティ省略などPHP7.2にはない機能、将来的なバージョンアップ対応のコストの削減といったメリットを実感しています。 

デメリット

現時点では大きなデメリットは感じていませんが、強いて言えばLaravelのEloquent ORMがActive Revoedパターンを採用しているので、Repositoryパターンで実装する際のベストプラクティスを見つけることには苦戦しました。

 

2.ECSの導入

TANPのバッチ処理の大部分は、ECやECの管理画面と同じインスタンス上で実行されていましたが、サービスの成長に伴ってバッチ処理が使用するリソースも肥大化しており、サーバーに高負荷をかけてしまうという課題がありました。また、今回のプロジェクトではTANPの全会員に対してランクの更新やシステムメール送信の処理を一度に行う必要があることから、既存のインフラで運用していくことは難しいと判断し、既存のバッチ処理の移行先という観点も含めてインフラの選定を行いました。 

AWSでサーバレスなバッチ実行環境としてLambda、ECS、Batch等が挙げられますが、会員ランクに関わる大規模な処理が実行可能で、将来的にECや管理画面のWebアプリケーションの移行先としても検討できるECSを採用することにしました。

AWSシステム構成

f:id:gracia_tanp:20210506135913p:plain

 

AWSのシステム構成としては、下記のような流れとなっています。

1.Githubのコミットを検知してCodePipelineが起動。

2.CodeBuildがDockerイメージをビルドしてECRにプッシュ。

3.ECSのタスク起動時にECRからDockerイメージをpullしてバッチを起動。

 

ECSを導入して感じたメリット・デメリット

メリット
  • バッチジョブの単位でコンテナが立つため、他の処理のリソースを気にする必要がない。
  • CloudWatchのログもジョブ単位で生成されるため、ログを確認しやすい。
  • ローカル環境で使用しているDockerイメージと同等のものを本番環境でも使えるので、環境差異が少ない。
  • コンテナの起動がジョブの実行時のみのため、インフラコストを節約できる。
デメリット

デメリットとして挙げさせていただいていますが、どちらもECSがコンテナ基盤を抽象化してくれているが故に生じるものではあるので、今後裏側の理解を深めていくことでカバーしていきたいと考えています。

  • コンテナの場合、EC2でインスタンス内に入って操作する運用が難しい。
  • 期待通りに動作しなかった場合の原因の切り分けが難しい。

 

会員ランクプロジェクトを振り返って

会員ランクはお客様のお金・資産に関わる重要かつセンシティブな機能であるため、マーケティングの観点のみならず、会計や法務を始めとするコーポレート部門、CS部門など多くの部署を渡り全社的に取り組んだプロジェクトでもありました。

僕個人としては元々人見知りなところもあり部署を渡った調整が少し苦手な面もあったのですが、プロジェクトを通して多くの部署の方と関係性を作ることができ、入社した数ヶ月前に比べ気軽に周囲のメンバーとコミュニケーションが取れるようにもなりました。技術面だけでなく、業務上の関係構築の面でも大きな1歩を踏み出すことができ、ご協力いただいた方々に大変感謝しています。

まとめ

TANPの開発チームは今でこそ正社員10名弱のメンバーを迎えていますが、昨年までは正社員2名、それ以前はCTO1名の体制で開発を続けてきました。力強い業務委託のメンバーにも引き続きご協力をいただいていますが、今後さらにTANPの成長を加速させていくためには、加速に耐えられる安定性や保守性を考慮した基盤の整備が必須です。

これまでサービスの運営を支えてきたコードに敬意を払いながら、よりモダンな、よりサービスの可能性を広げていけるような技術の採用にも注力していきたいと思います。TANPのエンジニアグループでは絶賛採用強化中ですので、少しでもご興味を持っていただけた方はお気軽にご連絡ください!お待ちしております!

 

エンジニア採用サイト:https://gra-cia.co.jp/engineer

Gracia Twitter:https://twitter.com/gracia_tanp

募集職種一覧:https://gra-cia.co.jp/careers

[おすすめ記事]

twitter.com