ソーシャルPLUS 開発チームリーダーの id:tmd45 です。ごきげんよう。
ソーシャルPLUS チームではバックエンドエンジニアの絶賛採用活動中なのですが、そのときにまとめた技術スタックについて、採用メディアにだけ使うのももったいないと思ったので、普通にブログ記事に書いてみることにしました。よろしくおねがいします。'`ｨ (ﾟдﾟ)/
ソーシャルPLUS って？
おそらく知らない方が大半だと思うので、かんたんにサービス紹介をば。
ソーシャルPLUS は、WEB サイトでの会員登録や再ログインがかんたんになる「ソーシャルログイン」を複数プラットフォームまとめて一括で実装できる BtoBtoC の ID 連携サービスです。
対応するプラットフォーム（認可プロバイダ）には LINE、Yahoo! JAPAN、Google、Facebook、Twitter があります。とくに 2016年からは LINE Messaging API によるメッセージ配信や 1to1 トークに対応し、コンシューマー（エンドユーザー）への継続的なリーチや商品購入後のカスタマーサポートなどが可能になりました。ID 連携によりエンドユーザーとのコミュニケーションチャネルが広がり、さらに精度も高められるようになります。
企業の課題を解決するだけでなく、企業が実現したい事の先にいるエンドユーザーにとってメリットがあるかを重要視したユーザーファーストの考え方で、機能追加やサービスの活用提案を行なっています。
2012 年 4 月からサービスを開始し、7 年目となる今年もまだまだ成長しているサービスです。
システムの役割
ソーシャルPLUS では大きく以下の２つの Rails アプリケーションが中心になっています。
ソーシャルログインサービス
- ソーシャルログインの提供
- プロバイダからのユーザ情報取得
- API 提供
- 設定管理画面
こちらはサービス稼働当初から存在する、コアとなる機能を扱っています。昔ながらの MVC すべてを Rails で構築しているアプリケーションです。
瞬間的なアクセス増加に耐える運用設計や、パフォーマンス改善、プロバイダの仕様変更への追従が、最近の主なタスクでした。
技術スタックは後述しますが、「ソーシャルログインの提供」と「設定管理画面」が１つのアプリケーションとして動いているのは、可用性も保守性もいまいちなので近々分離したいと考えている部分です。
LINE メッセージ配信サービス
- スケジュール一括配信
- メッセージ（Webhook）受信
- 1to1 メッセージ（チャットのようにエンドユーザーと対話できる機能）
- API 提供
- 新機能: ステップ配信機能 開発中
メッセージ配信サービスは 2017 年 4 月から提供を始めた（このプロダクトのなかでは）比較的新しいサービスです。
フロントエンドを React & Redux で、サーバーサイドを Rails の API モードで構築しています。
これまでエンドユーザーからのメッセージを漏れなく受信するためのアーキテクチャや、メッセージ配信のパフォーマンスを上げる施策に取り組んできました。直近ではデザイナーが参加し、より使いやすい UI や UX を意識しながら新機能の開発を進めています。
技術スタックの紹介
現在、ソーシャルPLUS チームには８名の開発者が在籍していますが、メンバーの得意な技術領域によってバックエンド、フロントエンド、インフラのタスクを分けて取り掛かり、相互にフォローしながらチーム開発を進めています。
もちろん本人が希望すればどんな仕事でも関わってもらって構いません。実際、フルスタックを志して手が空けばいろんなタスクを消化しているメンバーもいます。
バックエンド（サーバーサイド）
- ソーシャルログインサービスは Ruby on Rails 4.2（
来年中にはバージョンアップ予定2020年9月 バージョンアップしました！） - LINE メッセージ配信サービスは SPA（Single Page Application）として構築しており、サーバーサイドは Ruby on Rails 5.2 の API モードを利用
- いずれも RDB は MySQL、インメモリデータストアは Redis を利用
- RSpec による機能テスト（85 〜 91 % のカバレッジ）
- Bugsnag, Scout によるアプリケーションレイヤーの監視
- Google BigQuery へのログ集積
- システムの一部に AWS Lambda, Amazon DynamoDB, Amazon Kinesis などを利用
フロントエンド
- React, TypeScript, Firebase, PWA などを用いた BtoB 向け SPA
- Atomic Design をベースに UI を構造化、Storybook でコンポーネントを管理
- Flux アーキテクチャにはおなじみの Redux を用い、ファイル構造は re-ducks パターンを採用
- モジュールのテスト、E2E テストや ビジュアル回帰テスト等にてプロダクトの品質を維持
- Bugsnag, LogRocket によるフロントエンドアプリケーションレイヤーの監視
インフラストラクチャ
- AWS を中心に構成。Route 53, ALB, EC2, Aurora MySQL ほか
- 複数 AZ（Availability Zone）に冗長化、構成変更は Blue/Green Deployment
- EKS や ECS へのコンテナ化移行を検討中（技術検証や運用コストを踏まえて慎重に検証を重ねています）
- Infrastructure as Code に従って Terraform や Chef でコード管理
- 作業の自動化を意識。サーバー台数の増減はほぼ自動で行われる仕組みを実現
- Datadog を利用した監視、異常は Slack へ通知
その他
- 全体で Slack, GitHub, CircleCI, Redash を利用
- リリース作業を ChatOps 化（中継に Jenkins を利用）
- リモートペアプロも挑戦中（おもに Slack Call と画面共有。方法は模索中）
モニタリング内容やアラート、タスクカード（GitHub Project）はチームの席近くにある大型ディスプレイに表示して、朝会やイテレーションミーティングで眺められるようにしています。リモートじゃないモブプログラミングなんかもここでやります。
おわりに
すべての技術スタックについて細かに説明すると相当長くなるので、ざっくりになりました。技術スタックだけでなく、チームの仕事の仕方なんかも今後公開していければと思います。
弊社ではカジュアル面談も行っていますが、ビジネスの説明からこういった技術スタックの解説まで、私やチームメンバーからさせていただいてます。
選考というフローに進む前にぜひ会社やプロダクトについて知ってもらえればと思っておりますので、気になる部分があればお気軽にご質問ください〜 (・ω・)ノ
