Yappli Tech Blog

株式会社ヤプリの開発メンバーによるブログです。最新の技術情報からチーム・働き方に関するテーマまで、日々の熱い想いを持って発信していきます。

ヤプリのサーバサイドで使われている技術について紹介してみた

どうもこんにちわ、サーバサイドエンジニアの山田です。

今年も残すところ1ヶ月を切りましたね!この1年は大きな前進を感じられたでしょうか。


さて、度々ですがヤプリは開発力アップを目指して全力でエンジニア採用に取り組んでます。カジュアル面談や面接ではQ&Aの時間を設けてますが、使われている技術についてよく聞かれます。

ヤプリで使われている技術は こちらの記事 にもまとめてますが「GoもPHPも触るんですか?」とか「AWSとGCPはどう使い分けてるの?」など実際の業務において各技術がどのように使われているのかといった質問は多いです。

そこで、今回は質問の多いヤプリのサーバサイド技術について業務でどのように利用されているのかを紹介します!

ヤプリの技術変遷について

まず、ヤプリのサーバサイドエンジニアの開発主言語はGoです!
そしたらPHPは何に使われてるの?という流れがテンプレで、ヤプリ史に触れて説明します。

ヤプリは創業メンバーであり現CTOでもある佐野が単身で作りあげたPHP製のサービスです。 すごい!サノさんナニモンだよ!!という方は是非こちらの記事を拝見ください。
note.com

この単身で作り上げた土台は数年の歳月を経て沢山のユーザを支える巨大なサービスに成長し、同時に複数人がメンテするにはコードの運用保守性に大きな課題を感じるようになりました。「いや、こんなに大きくなるとは思ってなかったから!」という佐野さんの後日談。ですよね。

この課題を技術負債とし、今後の成長に備え2018年からCMSの刷新プロジェクトがスタート。これを期にCMSの完全な技術刷新が行われ全面的にGoが採用されるようになりました。

なお、当時Goが採用された経緯については組織として精通していた訳ではなく、静的型付けの硬さやパフォーマンス、今後のトレンドや適度な難易度といった諸々の要素を踏まえての技術選定でした。

これ以降、基本的には新機能開発の際にはGoでの実装が行われます。

ただしこの刷新で全てのコードが刷新されたわけではなく、アプリが利用するAPIや一部のバックエンド処理についてはスコープ外でした。(これらについては技術負債の認識を持ちながらもビジネス的な旨味を天秤にかけ、結果リソースを割かない判断をしています)

結論として今のヤプリはGoベースの新環境とPHPベースの旧環境が入り混じった状態で運用されています。
ではヤプリの技術変遷に触れたところで、特によく使われている技術について紹介していきます!

Go

ヤプリのサーバサイドにおける主言語です。

CMSのバックエンド開発やアプリが参照するAPI、バッチ処理など幅広いシーンで使われてます。 Goについてはチームの技術力を伸ばす為に外部顧問としてエヴァンジュリストであるtenntennさんを招いて勉強会もやっており、組織としても強くバックアップしてます。

PHP

ヤプリのサーバサイドにおける過去の主言語です。

現在は積極的に新規実装される事はありませんが現役で動いてるコードが多数残っておりこれらの機能拡張やバグFIXにおいて多々触れる事があります。 一部は素のPHPによるCTO佐野オリジナルフレームワークだったり、一部はLaravelを利用してたりなど歴史の変遷を噛みしめる事ができます。

gRPC

バックエンドにおける通信ではgRPCが利用されておりProtocol Buffersでスキーマ定義を行ってます。 プロキシはEnvoyを利用しており、CMSにおいてフロントとの通信はgRPC-Webを、アプリのAPI開発においてはgRPC-gatewayでREST APIでの実装を実現してます。

ドメイン駆動開発

巷で大人気のDDDですが、ヤプリのサーバサイドもアーキテクチャとしてDDDを採用しております。

導入されたのはGoによるCMS刷新と同タイミングで現在もDDDによる開発アプローチを続けてます。これもGo同様に元々メンバーに知見などあった訳ではなく、導入を決めてからチーム全員エヴァンス本でDDDを学びなが勉強会等行ったりしてました。

今では全員がDDDで俳句を読めるくらいのレベルに達しています。 適当言いました。

MySQL

主として使われるRDBはMySQLです。

AWSのAuroraを利用しており、中身は億を超える大量レコードや歴史の変遷を感じる癖のあるテーブル構造など、味わい深い仕上がりになってます。

SQLite3

なぜここでSQLite...と思われるかもしれませんが、背景等詳しくは以下の記事でも紹介してます。 tech.yappli.io

端的に説明するとアプリごとにDBファイルを分けることでマルチテナントの要件を満たしつつコンテンツ情報のプレビュー・本番の切り替えもアクセス先のファイルを切り替えるだけで実現できて取り回しがとても楽です。是非記事を読んでみてください。

GitHub

コードはGitHubで管理してます。 思想としてはマイクロサービスではなくモノレポに寄ってますが、フロントやバックエンドのSQLiteアクセス部分は別リポジトリに分けてます。

なお、余談ですが主リポジトリ名は温泉名が採用されており主リポジトリの名前はatamiです。(DDDとかは一旦置いておこ) 採用背景はCMSの完全刷新が終わったら会社からご褒美もらってatamiに行こうというノリからでした。

あれ...そういえばまだatami行けてないΣ(゜゜)

クラウドサービス

主にAWSを利用してます。直近はECS/Fargateによるコンテナ管理を行ってますがPHPをベースにした旧資産についてはEC2上で稼働してます。 他にもCloudWatchLogsやS3、Lambda、etcと基本的なサービスは色々使ってます。

またAWSで要件を満たし辛い場合にGCPも活用しており、特に大量データ検索目的でBigQueryを活用してます。

CI/CD

CircleCIを利用してます。
ここの設定はサーバサイドが触ることもあれば、インフラチームが触ることもあります。

ログ管理・監視

サービスはAWS上で管理されておりサーバログは大体CloudWatchLogsに格納されてます。 また監視/APMツールとしてはNew Relicを利用してます。(技術一覧にはDatadogも書いてますが現在移行中です)

最後に

以上、ヤプリのサーバサイドエンジニアの主要技術について簡単に紹介させていただきました。

上記紹介した以外にも沢山の技術を活用しており、これらは現場エンジニアが主体となって技術選定を行ってます。直近では商品データを高速に検索する機能を実現する為にサーバー/インフラチームで協力し技術選定や導入調査を行うなどチームドリブンな開発が行われてます。

ヤプリでは日々アーキテクチャの改善を続けていますので、ヤプリの開発に興味がある方は是非お声がけください!
( ゚∀゚) やっぷりヤプリ!