【エンジニア】Graciaの技術スタックについて

こんにちは、GraciaのCTOの林です。

前回の記事ではGraciaの開発体制について紹介しましたが、今回はGraciaが採用している技術スタックについて紹介します。

f:id:gracia_tanp:20210317134922p:plain

サービス構成の概要

弊社では「TANP」というギフトに特化したネットショップを運営しています。自社で倉庫を抱え、在庫の管理からラッピング等のギフト関連のオペレーションも含め、物流面も全て自社で行なっています。EC側だけでなく、物流のシステム面を司る「基幹業務システム」も社内でフルスクラッチしており、煩雑なギフトオペレーションの効率化により、注文から最短即日で発送することを可能にしています。

※基幹業務システムについては、下記の記事にて詳細を記載しています。是非ご参照ください。

2020年7月29日公開のプレスリリース内「資金調達の背景と使途」：
https://gra-cia.co.jp/releases/1
エンジニア採用サイト内「エンジニア採用資料」「社内インタビュー」：
https://gra-cia.co.jp/engineer

また、TANPサービス関連のアプリケーションと、全体の大まかな構成は以下になります。

Web版TANP
基幹業務システム

倉庫管理システム（WMS）
パートナー様向け管理画面
社内向けデータ管理画面
会計システム

スマホアプリ（iOS/Android版TANP）

f:id:gracia_tanp:20210322160853p:plain

Web（Web版TANP + 基幹業務システム）

当社では大部分の開発にPHP、フレームワークとしてCakePHPを使用しており、メール配信等で使用するバッチ処理や、会計システムなど一部のプロジェクトではLaravelを使用しています。

フロントエンドではReactとTypeScriptを使用し、EC関連の一部の機能開発を行なっています。また、基幹業務システムの一部である倉庫管理システムではReactでSPAでのUI開発を行なっています。

インフラ

AWSを使用しており、基本的にアプリケーションはEC2上で動かしています。

また、セッション管理はRedis、DBはAuroraを使用しています。Auroraはマスター + リーダー複数台の構成になっており、アプリケーション側で読み込み処理をリーダーに向けることで負荷分散を実現しています。

CSS/JSなどの静的ファイルの配信にはS3, CloudFrontを使用しています。CodePipelineでのビルド時に自動でS3にアップロードされるようになっています。

また、TANPでは商品等の画像を大量に掲載しており、それらのCDN配信にはCloudinaryを使用しています。動的な画像サイズの変換や、各ブラウザに最適な拡張子での配信を行なってくれるので重宝しています。

アカウント管理にはAWS Organizationを使用しており、サービスドメインや環境（本番/テスト等）毎にAWSアカウントを作成しています。これにより安全にアカウントや権限を管理することが出来ています。

AWS Organizations（AWS アカウント全体の一元管理）| AWS

インフラの監視にはDatadogを使用しており、各種メトリクス、APMを用いたパフォーマンスの監視等を行なっています。処理の遅い箇所やその原因を調査しながら、日々パフォーマンスの改善を行なっています。

APMと分散型トレーシング

開発環境・CI/CD

開発環境にはDocker、ソースコード管理はGitHubを使用しています。

CI/CDにはGitHub Actions、CodePipelineを使用しており、GitHub上でマージすると下記が自動で走るようになっています。

ユニットテスト(PHPUnit)とコードの静的解析(PHPStan)
ビルド、デプロイ

また、検証環境ではブランチにプッシュした際に自動デプロイが走るようになっていますが、本番環境でのデプロイの際は事故防止のため手動での承認作業を噛ませています。

データ基盤

f:id:gracia_tanp:20210322162401p:plain

ECという業態もあり、データ分析には重きを置いています。データ基盤には主にBigQueryを使用し、Redashと繋ぎ込むことで開発メンバー以外も積極的にデータを取得できるような体制を作っています。集約されているデータは主に下記のようなものです。

個人情報がマスキングされた本番DBのデータ
商品のインプレッションやクリックなどのWebアプリケーションのイベントログ
iOS、Androidのイベントログ

Redashは複数のデータソースを用いたデータの抽出、可視化、各種定期処理まで一貫して行うことができるため、施策の振り返りやKPIのモニタリングに重宝しています。

開発メンバー以外がデータに触れる環境を整備することで、プロダクト改善は飛躍的に加速します。事業の拡大に伴いデータ分析基盤は改善を進めていますが、社内全体でデータ活用がしやすい体制づくりには今後も注力したいと考えています。

iOS, Androidアプリ

iOSアプリはSwift、AndroidアプリはKotlinで開発しています。

API定義にはSwagger(OpenAPI3.0)を使用していて、

yamlファイルでAPI定義を記述
openapi-generatorでAPIクライアントを自動生成
Swift, Kotlinのコードに取り込む

という流れになっています。

サーバーとクライアントの実装をうまく連携しながら進めることができるので、API定義を書いて開発する方式にして良かったなと思っています。

今後の展望について

フロントエンドの刷新

創業期からフロントエンドは主にjQueryを使用してきましたが、コードの規模が拡大するにつれ、可読性や保守性の担保が困難になってきています。今後さらに規模が拡大することが見込まれるため、ここからはReact、TypeScriptでの機能開発や既存コードのリプレイスを行っていき、開発スピードとメンテナンス性の向上を目指していきます。

PHPのバージョンアップ

昨年、PHP8.0が新しくリリースされました。現在弊社ではPHP7系を使用していますが、7系のサポートの期限が近付いていることもあり、8.0へのバージョンアップを行うことを検討しています。基礎的なことかもしれませんが、新しいバージョンを新規プロジェクトなどで試して知見を溜めておくこと、ユニットテストのカバレッジ向上に取り組むことなどは日常的に意識しています。