GreenSnap TECH BLOG

GreenSnapのエンジニアチームの取り組みや使っている技術を紹介します

GreenSnapのCTOとして2021年やったこと

こんにちは。 GreenSnapの取締役CTOの高畑です。2021年の8月にCTOに就任してから早くも4ヶ月が経ちました。 そこから正式に開発チームを任されるようになりましたが、それ以前からも開発チームのマネージャーとして色々と自由にやらさせてもらっていたので、GreenSnapのサービスと開発チームにどういう変化が起こったのか、自分がどんなことをしていたのかを今年1年の振り返りと共にサマリーを紹介します。

SLOを決める

GreenSnapのサービスにSLOがなく、サーバーのエラーやAPIのレスポンス速度などの品質が悪くユーザーのレビューでも「アプリが重い」や「エラーがよく発生する」などのレビューが上がってくることが多かったです。アプリを使っていて動作がすごくもっさりしており、どうにかしないと気が済まなかったです。元々NewRelicによる監視ツールが導入されていたので

  • NewRelicによる稼働率99.9%
  • すべてのAPIのレスポンス速度を500ms以下にする

の2点を最低限の目標としそれが下回るとNewRelicからSlackへ通知が来るようにしてアプリのパフォーマンスを改善しました。
稼働率は現在99.9%以上を維持しています。
すべてのAPIのレスポンス速度を500ms以下にするは、一部ほぼリクエストが来ないAPIで達成できていないものがありますがほぼ改善しつつあります。 来年も引き続き稼働率とパフォーマンスを意識して開発を進めます。 この辺りの監視は入門監視を参考にしてとにかくユーザー体験に関わる部分から手をつけ始めました。 www.oreilly.co.jp

データベースをAuroraに移行

GreenSnapの本番環境でのデータベースはEC2インスタンスにMySQLを入れたものをDBサーバーとして運用していましたがデータ量の増加にともないバックアップの取得や、もしMySQLに何かあった時の復旧方法などの手順がなかったので、Auroraに移行してAWSに基本おまかせするようにしました。

タイムラインの機能に使ってるRedisのクラスター化

GreenSnapにはタイムラインの機能があり、ユーザーが投稿やフォローなどのアクションを行うたびにそのユーザーのアクションに関連するユーザーのタイムラインにデータを書き込みに行くのですが、そのデータの書き込み先が1台のRedisで行われていました。
しかしRedisのCPU利用率が常に100%近くになっており、スペックを上げてもどうにもなりませんでした。
それと同時にユーザーからタイムラインに反映されない、または反映されるのが遅いという声をいただいていたのでElastiCacheのクラスターモードをONにしたRedisを新規に立てて移行して、負荷分散を行いました。
ざっくり現在のタイムラインの構成は以下のようになっており、メッセージキューにはkafkaが使われています。 f:id:masahide318:20211230172924p:plain

教えてカメラのバージョンアップ

教えてカメラの大幅バージョンアップを行いました。
これに関しては協力していただいた。株式会社トリプルアイズ様に感謝にです。幅広い品種に対応しているので皆さんも家にある花や、散歩がてら道端に咲いてる植物などで試してください。
レビューでたまに「AIの判定結果があたらない」という声をいただいていましたが、アップデートしてからそういう内容のレビューが今のところ0件になりました。 greensnap.jp

EC2インスタンスの刷新

GreenSnapのアプリケーションサーバーがCentOS6で動いていたのですがサポートも切れており、後述にあるデータ基盤を作成するのにAWSとの連携で色々とやり辛かったのでAmazon Linux2に刷新しました。

GreenSnapSTOREとGreenSnapの連携

GreenSnapSTOREにはshopifyが使われておりますが、色々とデータ連携や運用改善のツールを作ってました。

  • 商品情報をGreenSnapのDBと連携させてアプリ側に商品情報を出したり
  • 在庫が切れそうな商品を自動で通知してくれるようにしたり
  • アプリでshopifyのクーポンを配布したり
  • 注文が入った時自動でユーザーに配送予定日をお知らせるするメールを送ったり

その他色々と連携させて、アプリとSTOREの連携を強めてまいりました

データ基盤の作成(途中)

GreenSnapのサービスに関するデータを横断して解析できるようなデータ基盤がなかったので現在作成中です。
現在の構想ではS3 + Athena + QuickSightで可視化の流れを考えています。
ある程度のデータはS3に集まってきていますがGreenSnapSTOREのデータがまだ同期されていないので来年はSTOREの受注データや商品データも統合して、アプリ内のユーザーの行動データと購買データを突き合わせて分析できる基盤を用意していきます。 f:id:masahide318:20211230165921p:plain

これまで以上にGreenSnapをテック企業として成長させ、さらにデータをもとに仮説・検証を素早く行える組織を目指していきます。

社内勉強会の開始

「開発チームが抱える課題の解決になりそう」 + 「みんなが興味を持てる本」を選んで読書会をしました。 週に1回業務時間内でメンバー持ち回りで担当者を決めて発表してます。 これまでに以下の本を読みました。

特にドメイン駆動設計入門はいわゆる軽量DDDという形での導入になってますが、ソースコードを書く上でチームの意識を統一させるのにすごく役立っています。 人によってどのロジックをどこに書くか?というのがバラバラだったのがこのロジックはこの層に書くべき、このロジックはこのクラスの責務であるべき、ServiceクラスやRepositoryクラスの依存関係はこうあるべきなどの判断基準が統一でき、ソースレビューのレビュー観点を持てたのがよかったです。

Google RecommendationsAIの導入

GreenSnapSTOREの商品とアプリとの連携において、おすすめの商品などを独自のロジックをもとに商品を表示していましたが試しにGoogleRecommendationsAIを導入しました。結果アプリからSTOREへのCVRが平均で0.5%ほど向上しました。まだまだ満足のいくレベルではないので、このあたりのおすすめ商品は先ほどのデータ基盤をもとに将来的に内製化しようと思います。

Notion + スクラムの導入

開発wiki的なものがなく、仕様書や設計書なども整備されておらず。お互いに暗黙知だらけでした。 チーム内でも何かドキュメントサービスを導入したいという声があがっていたのでNotionを導入することに決めました。 Notionの導入と同時に、それまでタスク管理ツールはClickUpを使っていたのですがタスクのチケットとwikiが別になるのも不便なのでClickUpのSprintのタスク管理機能とほぼ同じ使いみちになるようなテンプレートをNotionでつくって、タスク管理も仕様書も運用などもすべてNotion内で完結できるようにしました。 詳しくはこちらのブログを見てください。

greensnap-tech.hatenablog.com

ポストモーテムの導入

過去に発生した障害の内容やどう対応したかの資料が欲しいという声と、Notionの導入 + そのタイミングでいくつか障害が発生したのでこれを機にポストモーテムを導入しました。 ポストモーテムを作成する基準や内容などは SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム を参考にしています。

エンジニアブログの開始

GreenSnapはテック企業としては知名度は高くないと課題を感じているので広報も兼ねてこのブログを始めました。 これからも定期的に発信していけるよう新しいことに挑戦し続けられる環境にしていきます。

最後に

今年自分ってどんなことしたかな?と思い書き出してみるとちゃんと色々な取り組みを始められていて良かったです。今回あげたもののいくつかは個別のブログとして切り出してもよさそうですね。
何よりも1年前に比べて開発チームの雰囲気や結束みたいなものは良くなってきたんじゃないかなぁと思います。
もともと自分はAndroidアプリのエンジニアだったのですが、今年やったこと振り返るともうその影も形もありませんね……。
来年も引き続き多くのチャレンジをしたと思えるような環境を作っていきます。 弊社では絶賛エンジニア募集中です。サーバーサイド、iOS、Androidエンジニアはもちろんのこと これから作成するデータ基盤とそれを活用できるデータサイエンティストの方も募集しています。

www.wantedly.com