このサービス、どの技術スタック？

技術選定をするとき、「あのサービスは何を使っているんだろう」とふと気になることがあります。

自分でもたまに調べるのですが、断片的な情報が多くてなかなか全体像がつかめません。そこで今回、身近な有名サービス8つについて、バックエンド・フロントエンド・データベース・インフラをひと通り調べてみました。

各サービスの公式エンジニアリングブログや技術カンファレンスの発表をもとにまとめています。ただし、内部の人間ではないので、あくまで公開情報ベースである点はご了承ください。

SNS系サービス

X (Twitter)

バックエンド: Scala, Java, C++, Go
フロントエンド: React, TypeScript
データベース: MySQL, Manhattan（自社開発分散KVS）
インフラ: 自社データセンター + AWS/GCP、Kubernetes

XはもともとRuby on Railsで作られていたそうです。それが2009年頃、ユーザー数の急増をきっかけにScala/Javaベースへと移行しました。Railsからの移行事例としてはかなり有名な話です。

データストアには、MySQLに加えて「Manhattan」という自社開発の分散KVSが使われているとのこと。また、メッセージングにはApache Kafkaが使われており、大量のイベント処理を支えているようです。

Elon Musk氏の買収後にインフラの大幅な縮小・最適化が行われたことも話題になりました。

Instagram

バックエンド: Python (Django), C++
フロントエンド: React (Web), React Native (モバイル), GraphQL
データベース: PostgreSQL, Cassandra, Redis
インフラ: AWS

調べていて一番驚いたのがInstagramです。なんと世界最大規模のDjangoモノリスで、数百万行のPythonコードが一つのモノリスとして動いているとのこと。

正直、「Djangoでこの規模が動くのか」と思いましたが、パフォーマンスが求められる部分ではC++やCythonが使われているそうです。Meta（Facebook）の共通基盤であるGraphQLも活用されており、Metaの技術資産がフル活用されている印象です。

TikTok

バックエンド: Go (gRPC), Python, C++
フロントエンド: ネイティブ (Swift, Kotlin) + Lynx（自社開発FW）
データベース: PostgreSQL, Cassandra, Redis
インフラ: ハイブリッド（自社サーバー + GCP + AWS）、Kubernetes

TikTokはバックエンドにGoを中心に据え、gRPCでサービス間通信をしているようです。推薦アルゴリズムにはPython、動画処理にはC++と、用途ごとに言語を使い分けています。

個人的に面白いと思ったのが、2025年にOSS公開されたLynxです。React Nativeの対抗馬として作られた自社開発のクロスプラットフォームUIフレームワークで、Rustを基盤にしています。TikTok内部で実際に使われている技術がそのまま公開された形で、今後の動向が気になります。

Discord

バックエンド: Elixir/Erlang, Rust, Python
フロントエンド: React (Web), React Native (モバイル), Electron (デスクトップ)
データベース: ScyllaDB, PostgreSQL
インフラ: GCP

Discordで目を引いたのが、Elixir×Rustという組み合わせです。リアルタイムのWebSocket通信をElixir/Erlangで処理し、パフォーマンスが必要な部分にRustを使っているとのこと。公式ブログによると、この構成で1,100万の同時接続を実現しているそうです。

データベースの変遷も面白くて、MongoDB → Cassandra → ScyllaDBと2回も移行しています。サービスの成長フェーズごとに最適なDBが変わっていく様子が見えて、これだけで一本記事が書けそうな話です。

SaaS / 業務系サービス

Slack

バックエンド: Hack (PHP系), Java
フロントエンド: React + Redux (Web), Electron (デスクトップ), Swift (iOS), Kotlin (Android)
データベース: MySQL (Vitess), Elasticsearch, Redis
インフラ: AWS、Kubernetes

SlackはもともとピュアなPHPで書かれていたそうですが、Facebook（現Meta）が開発したHackという言語に移行しています。PHPの上位互換のような言語で、型安全性とスケーラビリティの向上が目的だったようです。

データベースはMySQLですが、注目したいのはVitessというスケーリング技術の採用です。もともとYouTubeで生まれたMySQLの水平スケーリング技術で、こうした実績のあるOSSを上手く活用している点が印象的でした。

Notion

バックエンド: Node.js, Python (Django)
フロントエンド: React, TypeScript, Next.js (Web), Electron (デスクトップ), React Native (モバイル)
データベース: PostgreSQL（480論理シャード）, DynamoDB, Redis
インフラ: AWS、Kubernetes

Notionの技術スタックで驚いたのは、PostgreSQLの規模感です。公式ブログによると、480の論理シャードを96の物理インスタンスに分散させているそうです。サービスの成長に合わせてシャード数を拡大してきたとのこと。

あの滑らかなリアルタイム共同編集はCRDT（Conflict-free Replicated Data Type）という技術がベースになっているようです。複数ユーザーが同時に編集してもコンフリクトが起きない仕組みで、使っている側としては「こうやって実現していたのか」と納得しました。

Shopify

バックエンド: Ruby on Rails
フロントエンド: React, TypeScript, Hydrogen（自社開発のRemixベースFW）, React Native (モバイル)
データベース: MySQL（Pod分離アーキテクチャ）, Redis
インフラ: GCP、Kubernetes、Kafka

今回調べた中で一番印象に残ったのがShopifyです。世界最大級のRuby on Railsアプリケーションで、2025年のBlack Fridayではピーク時に毎分4.89億リクエスト、毎秒5,300万のDBクエリを処理したそうです。

「Railsでそこまでいけるのか」という驚きもありますが、もっと面白いのはそのアプローチです。Railsから逃げるのではなく、YJITというRust製のRuby JITコンパイラを自社開発し、Rubyそのものを速くする道を選んでいます。Sorbet（Ruby静的型チェッカー）の導入やPodアーキテクチャによる水平スケーリングなど、Railsのエコシステムごと進化させている姿勢は、技術選定を考えるうえでとても参考になります。

Netflix

バックエンド: Java (Spring Boot), Python, Node.js
フロントエンド: React + Node.js (SSR)
データベース: Cassandra, CockroachDB, DynamoDB, MySQL
インフラ: AWS、Open Connect（自社CDN）

Netflixの技術スタックで広く知られているのは、AWS全面採用と自社CDN「Open Connect」 の組み合わせです。コンピューティングやストレージはAWSに任せつつ、コンテンツ配信だけはISPの拠点に自社エッジサーバーを設置する構成を取っているとのことです。

また、Zuul（APIゲートウェイ）やEureka（サービスディスカバリ）など、自社開発のインフラツールをNetflix OSSとして積極的にOSS公開しています。意図的に障害を発生させてシステムの耐障害性を検証する「Chaos Engineering」の先駆者でもあり、「Chaos Monkey」というツールは有名です。

横断的に見えてくること

8つのサービスを並べてみると、いくつか共通する傾向が見えてきました。

Reactの普及率がすごい。 フロントエンドは8サービス中ほぼ全てがReact（またはReact Native）でした。ここまで揃うと、フロントエンドの選択においてReactが事実上のデフォルトになっていると言ってよさそうです。

GoとRustの存在感。 バックエンドのパフォーマンスが求められる部分ではGoの採用が目立ちます（X, TikTok, Netflix）。Rustも、Discordの同時接続処理、TikTokのLynx、ShopifyのYJITと、それぞれ違う形で重要な役割を担っています。

DB移行は珍しくない。 DiscordのMongoDB→Cassandra→ScyllaDB、SlackのPHP→Hackなど、サービスの成長に伴う技術移行はどのサービスも経験しています。最初の選択が「間違い」だったというより、規模に応じて最適解が変わるということなのだと思います。

モノリスも現役。 InstagramのDjangoモノリス、ShopifyのRailsモノリスが世界規模のトラフィックを処理しています。「マイクロサービスにしなければスケールしない」というわけではないことを、実例として示しているのが面白いです。

まとめ

最後に、8サービスの技術スタックを一覧にまとめます。

X — バックエンド: Scala, Java, Go / フロントエンド: React / DB: MySQL, Manhattan / インフラ: 自社DC + AWS/GCP

Instagram — バックエンド: Python (Django) / フロントエンド: React, React Native / DB: PostgreSQL, Cassandra / インフラ: AWS

TikTok — バックエンド: Go, Python, C++ / フロントエンド: ネイティブ + Lynx / DB: PostgreSQL, Cassandra / インフラ: ハイブリッド

Discord — バックエンド: Elixir, Rust / フロントエンド: React, React Native / DB: ScyllaDB, PostgreSQL / インフラ: GCP

Slack — バックエンド: Hack, Java / フロントエンド: React, Electron / DB: MySQL (Vitess) / インフラ: AWS

Notion — バックエンド: Node.js, Python / フロントエンド: React, Next.js / DB: PostgreSQL (480シャード) / インフラ: AWS

Shopify — バックエンド: Ruby on Rails / フロントエンド: React, Hydrogen / DB: MySQL / インフラ: GCP

Netflix — バックエンド: Java, Python / フロントエンド: React / DB: Cassandra, CockroachDB / インフラ: AWS + Open Connect

調べてみて感じたのは、技術選定に唯一の正解はないということです。同じ「大規模サービス」でもアプローチは全然違います。

「あのサービスと同じ構成だから安心」ではなく、「あのサービスはこの課題にこう対処した」という視点で眺めると、自分の技術選定にも活かせる部分が見つかるかもしれません。

この記事は2026年3月時点の公開情報に基づいています。各サービスの技術スタックは常に進化しており、最新の状況とは異なる場合があります。

keyaki. AI