身近なBtoCサービスを支えるアーキテクチャ大解剖　技術選定のポイントと今後の展望

アソビュー株式会社

アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー！」やD2C型SaaS「ウラカタ」を始め、1,000万会員/1万施設を超える顧客に複数サービスを提供しています。

アーキテクチャ選択の背景や意図

基本となるアーキテクチャとして、システム横断でのデータ再利用や迅速な開発のための「集約」と、負荷分散や権限分離などの「分割」を使い分ける戦略を採用しています。

• モノレポ
  　　全ソースを単一リポジトリに集約、独立して開発するため各サービスのパッケージ分割やCI/CDを分離
  
• モジュラモノリス+マイクロサービス
  　　コア機能をモジュラモノリスに集約、既存システムや一部マイクロサービスとして切り出し開発効率と独立性を維持
  
• マルチテナントシングルクラスター
  　　単一のEKSクラスターで全ステムを集約、モジュラモノリスの起動モードやマイクロサービスにより、水平スケールや可用性分離を実現
  
• マルチテナントDBの垂直、水平スケール
  　　マルチテナントDBでデータを集約、Amazon Aurora Serverless v2による垂直スケールやカスタムエンドポイントを用いた読み込みDBの可用性分離、Google Cloud Spannerを利用した書き込みDBの水平スケール
  
• 同期/非同期通信
  　　Protocol Buffersでスキーマ定義。同期通信はgRPC、非同期イベントは単一イベントバスに集約、分散システム間での連携
  
• データ基盤
  　　分散されたデータをBigQueryに集約し、分析や機械学習へ活用
  

現在のアーキテクチャの課題と今後の改善予定

様々な課題は残っていますが、代表的なものは以下です。

• マルチテナントにおけるノイジーネイバー
  　　サービス性質上、特定テナントにトラフィックや負荷が集中するノイジーネイバー問題があります。これに対し、動的なトラフィック制御やテナントのハイブリッドモデル化などスケーラビリティと開発効率の両立を実現する必要があります。
• システム統廃合と拡張性
  　　ここで紹介した以外にも様々なシステムを扱っているため、統廃合を行い開発生産性や拡張性を加速させていくことが重要です。また、販売商品を拡張していく上で、I/Fやサービスレベルが様々な外部システムと柔軟かつ安定した連携、プラットフォーム外の機能をサードパーティとして追加できるカスタマイズ性を実現するアーキテクチャも求められています。
  

◆執筆：兼平大資 アソビュー株式会社 技術戦略部 部長 / VPoT @disc99_

【サービス公式サイト】
https://www.asoview.com/

【アソビュー株式会社のエンジニア求人】
【SRE・地方フルリモート可・フルフレックス】4,000rpsを超える1,000万会員EC×1万施設マルチテナントSaaSのSREを募集！ 等
https://findy-code.io/companies/822/jobs

株式会社エブリー

エブリーは「前向きなきっかけを、ひとりひとりの日常にとどける。」をミッションに、ライフスタイルに根ざした事業を展開しています。3,000万人以上が利用しているレシピ動画サービス「 DELISH KITCHEN」をはじめ「トモニテ」「TIMELINE」を運営。オンライン・オフライン関係なくパーソナライズ化された最適な情報を届け、日々の生活における不安や悩みを解消することを目指しています。 今回は、「 DELISH KITCHEN」のアーキテクチャについて解説します。

アーキテクチャ選択の背景や意図

DELISH KITCHENには、ユーザーデータよりマスターデータへのアクセスが多い(特に取得系)、 お昼や⼣⽅など料理を⾏う時間のアクセスが多い、画像や動画などのメディアを多く扱っているなどのサービスとしての特徴があります。
DELISH KITCHENではこの特徴に沿ってアーキテクチャを選択しており、例えば、マスターデータへのアクセスに関してはキャッシュを⾏うことでDBへの負荷を軽減しています。 その他には、時間帯によるアクセスの増減に関してはオートスケーリングで対応していたり、メディアへのアクセスに関してはCloud Front経由でアクセスを⾏うことでコンテンツをユーザー様に⾼速に届けるような⼯夫をしています。 また、api serverの責務が⼤きくなってきたため、ライブ配信サービスや課⾦システムといったものは本体から切り出して別サービスとして稼働させています。

現在のアーキテクチャの課題と今後の改善予定

Elasticache for Redisを使⽤したリモートキャッシュで表されていますが、キャッシュはElasticacheだけでなくfargateのメモリにも載せています。 fargate上のメモリにキャッシュを載せていることが原因でパフォーマンスに影響があるため、Elasticacheへの移⾏を実施中です。
その他にも、プッシュ通知などは運⽤が安定してからほとんど改修されていないのですが、年々キューに積んでから実際に通知されるまでの時間がかかるようになっているため、今後の改善が必要になってきています。

◆執筆：DELISH KITCHEN開発部 ヘルスケアグループ リーダー ／ 本丸真人

【サービス公式サイト】
https://delishkitchen.tv/

【株式会社エブリーのエンジニア求人】
【Go】ユーザー数5,500万人以上！リアル×Webの大規模サービス「DELISH KITCHEN」|買い物から「日常」を彩るテックリード候補（Backend）<リモート・フレックス> 等
https://findy-code.io/companies/1231/jobs

株式会社一休

株式会社一休は、一休.com、一休.comレストラン、Yahoo!トラベルを軸に計9事業を展開しております。「心に贅沢を」というコンセプトのもとサービスを作りこみ、独自の強みである「高級」や「上質」に特化した"尖ったマーケティング戦略"で成長し続けています。今回は、一休.comレストランのアーキテクチャについてご説明します。

アーキテクチャ選択の背景や意図

運用コストを下げるため、およそ7年前にデータセンターからクラウドにすべてのサービスを移行しました。以後、AWSを中心に、クラウドのみを利用しています。
コンピューティングリソースは、クラウド移行当初は、AWS ElasticBeanstalkを利用していましたが、今は、AWS EKSを利用して、コンテナのメリットを最大限享受できるようにしています。
簡易にコンテナのワークロードを扱えるようにするため、現在は、Google Cloud Run/Cloud Run Jobsも利用しています。
また、fastlyをリバースプロキシ兼CDNとして利用することで、トラフィックのコントロールや各種アクセス制御を行っています。

現在のアーキテクチャの課題と今後の改善予定

データベースが、クラウドが提供するマネージドDBではなく、EC2インスタンス上にマニュアルで構築したSQL Severクラスタになっています。
これによって、Windowsクラスタに関する細かな知識を持ち続ける必要があります。
今後は、マネージドなDBサービスへの移行を検討しています。また、レガシーなWindows系のバッチ処理など、いくつかコンテナ化できていないワークロードがあります。これらを、コンテナ化して可搬性/リソースの効率性を確保したいと思っています。

◆執筆：黒田 翔太 CTO室プラットフォームチーム

【サービス公式サイト】
https://restaurant.ikyu.com/

【株式会社一休のエンジニア求人】
【テックリード/リモートOK/Go/TypeScript】会員数1,500万人を超える「一休.com」「一休.comレストラン」の開発を牽引するテックリードを募集！ 等
https://findy-code.io/companies/830/jobs

株式会社ミラティブ

ミラティブは「わかりあう願いをつなごう」というミッションのもと、ゲーム配信プラットフォーム『Mirrativ』の開発/運営を行っています。
Mirrativはリリース以降、スマホ1台でゲーム配信ができる手軽さが好評を博し、累計配信者数が500万人を突破した「 スマホゲーム配信者数国内No.1 」の配信プラットフォームへと成長してきました。今回は、大規模配信プラットフォームである「Mirrativ」のアーキテクチャについて解説します。

アーキテクチャ選択の背景や意図

このアーキテクチャは一言で言えば「適材適所」です。
Mirrativは、スマホの画面を共有しながらライブ配信が行えるサービスを提供しているのですが、ライブ配信の特徴として、トラフィックの大きい映像/音声とトラフィックはそこまで大きくないAPI通信の大きく2種類に分けられます。
Google Cloud では、高いスケーラビリティを活かしてバックエンドサービスを構築しています。また、カスタマイズ豊富なSaaSサービスを用いてCI/CDや社内アプリ等もGoogle Cloud上で構築しています。

IDCF Cloud では、物理的なハードウェア占有サーバ(ベアメタルサーバ)を活用して高トラフィックを処理しています。高いスケーラビリティは確保できませんが、代わりにハードウェアロードバランサーによる高可用性を確保しています。ネットワーク周りにおいても帯域契約となっているため、一般的なパブリッククラウドと比べてネットワークコストも抑えられるようになっているのも特徴です。

現在のアーキテクチャの課題と今後の改善予定

バックエンドアプリケーションと配信基盤で取り組んでいることを紹介します。

• バックエンドアプリケーション
  MirrativのバックエンドではPerlとGoの2つの言語を使って運用しており、昨今はGoアプリケーションへ移行を進めています。Perlで書かれたアプリケーションは仕組みそのものが古くなりがちで、Deployフローが古くどうしても時間が掛かってしまっています。
  そこで、Deployの高速化とアプリケーション構成のモダナイズ化をしています。
  

- 配信基盤
配信基盤は過去に外部製品を用いて構成していたのですが、現在では全て内製化しています。
これによって、Mirrativ上の映像/音声は全て配信基盤上に流れるようになっているため、映像/音声を用いた機能拡張が行いやすくなりました。最近では配信文字起こし機能をGPUマシンを用意して実装することができ、低コストでありながらチューニングしやすくリリースできています。
今後も映像/音声に特化したさまざまな機能拡張を行っていく予定です。

◆執筆：漢 祐介　株式会社ミラティブ/技術戦略本部/基盤開発部/インフラストリーミングマネージャー　 @octu0

【公式ストアページ】
iOS
Android

【株式会社ミラティブのエンジニア求人】
【フルリモート/Go】スマホゲーム配信者数国内No.1！急速拡大する市場に挑むソフトウェアエンジニア（バックエンド）募集＜フレックス＞ 等
https://findy-code.io/companies/478/jobs

株式会社マイベスト

mybestは、商品購入やサービス登録など、ありとあらゆる選択という行動をサポートするために、実際に購入した商品を自社で検証・相対比較し、その情報をデータベース化したうえで、ユーザーの多様な選択ニーズに合わせた情報提供を行っています。

アーキテクチャ選択の背景や意図

マイベストのインフラでは、AWSのマネージドサービスを積極的に活用しています。
1ページあたりの情報量が多いサービスのため、すべてのアクセスにCloudFrontを適用しています。特に画像については、大半の素材を自社で撮影しており、様々な画像関連の要望に応えるためimgixを導入し、柔軟性とパフォーマンスを確保しています。
サービスは日本以外にも8か国と地域で展開しているため、上記の構成が各国分存在しますが、ソースコードは共通で、データベースと翻訳ファイルで各国切り替えることで対応しています。デプロイにはChatOpsを採用しており、全世界への簡易デプロイを実現しています。
バックエンドはRuby・Ruby on Rails・GraphQL、フロントエンドはReact(WebがNext.js、モバイルがReactNative)と技術スタックを統一することで、開発効率の向上を図っています。

現在のアーキテクチャの課題と今後の改善予定

マイベストは自社で検証した様々な情報を取り扱っていますが、それ以外にも商品情報を起点として様々な情報を扱うケースが増えてきています。しかし、これらを運用する体制と仕組みが現状に追いついていないため、その整備が大きな課題の1つとなっています。
直近はこの課題に対して、Goで開発・運用しているバッチ処理のRubyに置き換えや、エラー検知や障害時の対応の見直しを進めており、今後は、ワークフローエンジンの導入やインシデント管理ツールの導入も検討しつつ、ユーザーの選択インフラとして信頼できる情報を安定して提供できるような体制と仕組み作りに取り組んでいきたいと考えています。

◆執筆：渡邊直登　取締役 CTO 兼 執行役員｜プロダクト開発部 部長　 @miraoto

【サービス公式サイト】
https://my-best.com/

【株式会社マイベストのエンジニア求人】
【1人目専任SRE】月間3000万UU！高トラフィックサービスの安定稼働/信頼性向上/DX改善などをリードするSREを募集！ 等
https://findy-code.io/companies/656/jobs

株式会社Voicy

「Voicy」は国内最大級の音声プラットフォームです。2016年のサービスローンチから順調に拡大し、会員登録者数は200万人を突破しました。より多くの人々に音声を届け、声で心を動かす体験の創出を目指しています。

アーキテクチャ選択の背景や意図

アプリケーションロジックはAWS、データ分析基盤はGCPを採用しています。
データ分析基盤でGCPを採用している理由はBigQueryを利用したかったからです。

アプリケーションロジックはサービス初期から変遷を繰り返し現在の形になっております。
プロダクトの立ち上げ時期はAWS Elastic Beanstalkを採用してJavaで実装されていました。その後開発生産性を上げるためにGCPのGoogle Kubernetes Engineにサービスを移し始めたのですが、途中で担当者の退職により移行プロジェクトが頓挫しました。

AWSとGCPの両方を運用してた時代を経て、メインのコンピューティングをAmazon Elastic Kubernetes Service に移すことを意思決定して、途中でJavaをGoでの実装に変更しながら、現在のインフラの状態になりました。
またデータベースはしばらくAmazon Auroraを利用していましたが、今後のスケール性とコストパフォーマンスのメリットがありTiDBに移行しました。

現在のアーキテクチャの課題と今後の改善予定

現在のアーキテクチャの課題は複数のサービスが同一のデータベースに接続しており、似たロジックを複数のサービスで実装しなければならず、スピードや品質面で問題がありました。
また中途半端にマイクロサービスを取り入れてしまったため、複数サービスに跨る実装時にオーバーヘッドが存在しており、開発生産性も低くなっていました。
それらの課題を解決するために、現在はモジュラーモノリスへの大型リファクタリンクを実施しており、アプリケーションのコアロジックを集約し、開発生産性をあげて、開発スピードや品質を上げようとしています。

◆執筆：山元亮典 / エンジニア部門責任者 　@yamagenii

【サービス公式サイト】
https://voicy.jp/

【株式会社Voicyのエンジニア求人】
【登録者数200万人突破】急成長中の音声テック市場にて「Voicy」のモバイルアプリ開発を中心に技術牽引を担うテックリードを募集 等
https://findy-code.io/companies/393/jobs

---

Findy Toolsでは「システム全体のアーキテクチャ」「データ分析基盤のアーキテクチャ」「機械学習のアーキテクチャ」等を今後継続してご紹介していく予定です。アーキテクチャを掲載させて頂ける企業様がいらっしゃいましたら、企画担当までご連絡頂けますと幸いです。
アーキテクチャ特集 企画担当 中山 　E-mail：ayaka.nakayama[アットマーク]findy.co.jp