Web Analytics

system-design-primer

⭐ 318813 stars Japanese by donnemartin

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation このガイドの翻訳にご協力ください！

システム設計入門


動機

大規模システムの設計方法を学ぶ。
>
システム設計面接の準備をする。

大規模システムの設計方法を学ぶ

スケーラブルなシステムの設計方法を学ぶことは、より良いエンジニアになる助けとなります。

システム設計は広範なトピックです。システム設計の原則に関する膨大な量のリソースがウェブ上に散在しています。

このリポジトリは、スケールするシステムの構築方法を学ぶのに役立つ体系的に整理されたリソースのコレクションです。

オープンソースコミュニティから学ぶ

これは継続的に更新されるオープンソースプロジェクトです。

貢献を歓迎します！

システム設計面接の準備

コーディング面接に加えて、多くの技術系企業の技術面接プロセスにはシステム設計が必須の要素となっています。

一般的なシステム設計面接の質問を練習し、議論、コード、図解を含むサンプル解答と比較しましょう。

面接準備のための追加トピック：

Ankiフラッシュカード


提供されているAnkiフラッシュカードデッキは、間隔反復を利用して主要なシステム設計の概念を記憶するのに役立ちます。

外出先での利用に最適です。

コーディングリソース: インタラクティブコーディングチャレンジ

コーディング面接の準備に役立つリソースをお探しですか？


姉妹リポジトリのInteractive Coding Challengesもぜひご覧ください。追加のAnkiデッキが含まれています：

貢献について

コミュニティから学びましょう。

以下のためにプルリクエストを自由に送ってください：

調整が必要なコンテンツは開発中に置かれています。

貢献ガイドラインを確認してください。

システム設計トピックの索引

さまざまなシステム設計トピックの概要、利点と欠点を含む。 すべてはトレードオフです。
>
各セクションには、より詳細なリソースへのリンクが含まれています。


学習ガイド

面接のスケジュールに基づく推奨トピック（短期、中期、長期）。

Imgur

Q: 面接のためにここにあるすべてを知る必要がありますか？

A: いいえ、面接準備のためにここにあるすべてを知る必要はありません。

面接で問われる内容は以下のような変数によって異なります：

経験豊富な候補者は一般的にシステム設計についてより多く知っていることが期待されます。 アーキテクトやチームリーダーは個人貢献者よりも多く知っていることが期待されるかもしれません。 トップテック企業では一つ以上の設計面接ラウンドがある可能性が高いです。

幅広く学び、いくつかの分野で深掘りしましょう。システム設計の主要なトピックについて少し知っておくと役立ちます。以下のガイドは、あなたのスケジュール、経験、面接するポジションや企業に応じて調整してください。

| | 短期間 | 中期間 | 長期間 | |---|---|---|---| | システム設計トピックを読んでシステムの仕組みを広く理解する | :+1: | :+1: | :+1: | | 面接予定の企業の会社のエンジニアリングブログをいくつか読む | :+1: | :+1: | :+1: | | 実世界のアーキテクチャをいくつか読む | :+1: | :+1: | :+1: | | システム設計面接の質問への取り組み方を見直す | :+1: | :+1: | :+1: | | システム設計面接質問と解答に取り組む | 一部 | 多く | ほとんど | | オブジェクト指向設計面接質問と解答に取り組む | 一部 | 多く | ほとんど | | 追加のシステム設計面接質問を見直す | 一部 | 多く | ほとんど |

システム設計面接質問への取り組み方

システム設計面接質問にどう取り組むか。

システム設計面接はオープンエンドな対話です。あなたが主導することが期待されます。

以下のステップを使って議論を進めることができます。このプロセスを確実にするために、システム設計面接質問と解答のセクションを以下のステップに従って取り組みましょう。

ステップ1: ユースケース、制約、仮定の概要を示す

要件を集めて問題の範囲を定めます。ユースケースや制約を明確にするために質問し、仮定を議論します。

ステップ2: 高レベル設計を作成する

すべての重要なコンポーネントを含む高レベル設計の概要を示します。

ステップ3: コアコンポーネントの設計

各コアコンポーネントの詳細に入り込む。たとえば、もしURL短縮サービスを設計するように求められた場合、以下を議論する：

ステップ4: 設計のスケールアップ

制約条件を踏まえてボトルネックを特定し対処する。たとえば、スケーラビリティの問題に対処するために以下が必要か？

潜在的な解決策とトレードオフを議論する。すべてはトレードオフである。スケーラブルなシステム設計の原則を用いてボトルネックに対処する。

おおまかな計算

手計算での見積もりを求められることがある。付録の以下のリソースを参照せよ：

参考文献およびさらなる読書

以下のリンクを確認し、何を期待すべきかの理解を深めよう：

システム設計面接の質問と解答例

一般的なシステム設計面接の質問とサンプルディスカッション、コード、図解。
>
解答は solutions/ フォルダ内の内容にリンク。

| 質問 | | |---|---| | Pastebin.com（または Bit.ly）の設計 | 解答 | | Twitterのタイムラインと検索の設計（またはFacebookのフィードと検索） | 解答 | | ウェブクローラーの設計 | 解答 | | Mint.comの設計 | 解答 | | ソーシャルネットワークのデータ構造の設計 | 解答 | | 検索エンジン用のキー・バリューストアの設計 | 解答 | | Amazonのカテゴリー別売上ランキング機能の設計 | 解答 | | AWSで数百万ユーザーにスケール可能なシステムの設計 | 解答 | | システム設計の質問を追加する | 貢献する |

Pastebin.com（または Bit.ly）の設計

演習と解答を見る

Imgur

Twitterのタイムラインと検索の設計（またはFacebookのフィードと検索）

演習と解答を見る

Imgur

ウェブクローラーの設計

演習と解答を見る

Imgur

Design Mint.com

View exercise and solution

Imgur

Design the data structures for a social network

View exercise and solution

Imgur

Design a key-value store for a search engine

View exercise and solution

Imgur

Design Amazon's sales ranking by category feature

View exercise and solution

Imgur

Design a system that scales to millions of users on AWS

View exercise and solution

Imgur

Object-oriented design interview questions with solutions

Common object-oriented design interview questions with sample discussions, code, and diagrams.
>
Solutions linked to content in the solutions/ folder.

>Note: This section is under development

| Question | | |---|---| | ハッシュマップを設計する | 解答 | | LRUキャッシュを設計する | 解答 | | コールセンターを設計する | 解答 | | トランプの山札を設計する | 解答 | | 駐車場を設計する | 解答 | | チャットサーバーを設計する | 解答 | | 循環配列を設計する | 貢献する | | オブジェクト指向設計の質問を追加する | 貢献する |

システム設計トピック：ここから始めよう

システム設計は初めてですか？

まず、基本的な共通原則の理解が必要です。これらが何であるか、どのように使われるか、その利点と欠点について学びましょう。

ステップ1：スケーラビリティのビデオ講義を視聴する

ハーバードのスケーラビリティ講義

ステップ2：スケーラビリティの記事を読む

スケーラビリティ

次のステップ

次に、高レベルのトレードオフについて見ていきます：

すべてはトレードオフであることを念頭に置いてください。

その後、DNS、CDN、ロードバランサーなど、より具体的なトピックに踏み込んでいきます。

パフォーマンス vs スケーラビリティ

サービスがスケーラブルであるとは、追加したリソースに比例してパフォーマンスが向上する場合を指します。一般的に、パフォーマンスの向上とはより多くの作業単位を処理することを意味しますが、データセットが増大する場合のように、より大きな作業単位を扱うことも含まれます。1

パフォーマンスとスケーラビリティの別の見方：

参考文献とさらなる読み物

レイテンシ vs スループット

レイテンシは、ある操作を実行するか結果を出すまでの時間です。

スループットは、単位時間あたりのそのような操作や結果の数です。

一般的には、許容可能なレイテンシで最大スループットを目指すべきです。

参考文献とさらなる読み物

可用性 vs 一貫性

CAP定理


出典: CAP定理再考

分散コンピュータシステムでは、次の3つの保証のうち2つだけをサポートできます:

ネットワークは信頼できないため、分割耐性をサポートする必要があります。ソフトウェア上のトレードオフとして、一貫性と可用性のどちらかを選択する必要があります。

#### CP - 一貫性と分割耐性

分割されたノードからの応答を待つとタイムアウトエラーになる可能性があります。ビジネス上の要件が原子性のある読み書きを必要とする場合、CPは良い選択です。

#### AP - 可用性と分割耐性

応答は任意のノードで最も利用可能なバージョンのデータを返しますが、最新ではない場合があります。分割が解消されると書き込みの伝播に時間がかかることがあります。

APは最終的な一貫性を許容する必要がある場合や、外部のエラーがあってもシステムを継続動作させる必要がある場合に適しています。

出典とさらなる参考資料

一貫性パターン

同じデータの複数のコピーが存在する場合、クライアントが一貫したデータビューを持つようにそれらをどのように同期させるかの選択肢があります。CAP定理の一貫性の定義を思い出してください - すべての読み取りは最新の書き込みを受け取るか、エラーになる。

弱い一貫性

書き込み後に読み取りがそれを見える場合も見えない場合もあります。ベストエフォートのアプローチです。

このアプローチはmemcachedのようなシステムで見られます。弱い一貫性はVoIP、ビデオチャット、リアルタイムマルチプレイヤーゲームなどのリアルタイムユースケースでよく機能します。例えば、電話中に数秒間通信が途切れた場合、接続が回復してもその間に話された内容は聞こえません。

最終的整合性

書き込み後、読み取りは最終的にそれを参照します（通常は数ミリ秒以内）。データは非同期に複製されます。

このアプローチはDNSやメールのようなシステムで見られます。最終的整合性は高可用性システムでうまく機能します。

強い整合性

書き込み後、読み取りはそれを参照します。データは同期的に複製されます。

このアプローチはファイルシステムやRDBMSで見られます。強い整合性はトランザクションを必要とするシステムでうまく機能します。

出典およびさらなる読み物

可用性パターン

高可用性をサポートするための相補的なパターンが二つあります：フェイルオーバーとレプリケーション。

フェイルオーバー

#### アクティブ-パッシブ

アクティブ-パッシブフェイルオーバーでは、アクティブサーバーと待機中のパッシブサーバー間でハートビートが送信されます。ハートビートが中断された場合、パッシブサーバーがアクティブのIPアドレスを引き継ぎサービスを再開します。

ダウンタイムの長さは、パッシブサーバーがすでに「ホット」スタンバイで稼働しているか、「コールド」スタンバイから起動する必要があるかで決まります。トラフィックを処理するのはアクティブサーバーのみです。

アクティブ-パッシブフェイルオーバーはマスター-スレーブフェイルオーバーとも呼ばれます。

#### アクティブ-アクティブ

アクティブ-アクティブでは、両方のサーバーがトラフィックを管理し、負荷を分散しています。

サーバーが公開向けの場合、DNSは両方のサーバーのパブリックIPを認識する必要があります。サーバーが内部向けの場合、アプリケーションロジックが両方のサーバーを認識する必要があります。

アクティブ-アクティブフェイルオーバーはマスター-マスターフェイルオーバーとも呼ばれます。

欠点：フェイルオーバー

複製

#### マスター・スレーブおよびマスター・マスター

このトピックはデータベースセクションでさらに詳しく説明されています：

可用性の数値

可用性はしばしばサービスが利用可能な時間の割合としてアップタイム（またはダウンタイム）で定量化されます。可用性は一般的に「9の数」で測定され、99.99%の可用性を持つサービスは「4つの9」と表現されます。

#### 99.9%の可用性 - 3つの9

| 期間 | 許容ダウンタイム | |---------------------|--------------------| | 年間ダウンタイム | 8時間45分57秒 | | 月間ダウンタイム | 43分49.7秒 | | 週間ダウンタイム | 10分4.8秒 | | 1日あたりのダウンタイム | 1分26.4秒 |

#### 99.99%の可用性 - 4つの9

| 期間 | 許容ダウンタイム | |---------------------|--------------------| | 年間ダウンタイム | 52分35.7秒 | | 月間ダウンタイム | 4分23秒 | | 週間ダウンタイム | 1分5秒 | | 1日あたりのダウンタイム | 8.6秒 |

#### 並列可用性と直列可用性

サービスが障害を起こしやすい複数のコンポーネントで構成されている場合、サービス全体の可用性はコンポーネントが直列か並列かによって異なります。

###### 直列の場合

全体の可用性は、可用性が100%未満の2つのコンポーネントが直列に接続されている場合に低下します:

Availability (Total) = Availability (Foo) * Availability (Bar)

もし Foo と Bar の両方がそれぞれ99.9%の可用性を持っている場合、それらが直列に接続されると合計の可用性は99.8%になります。

###### 並列の場合

可用性が100%未満の2つのコンポーネントを並列に配置すると、全体の可用性は向上します：

Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
もし Foo と Bar の両方がそれぞれ99.9%の可用性を持っている場合、並列での総可用性は99.9999%になります。

ドメインネームシステム


出典: DNSセキュリティプレゼンテーション

ドメインネームシステム（DNS）は、www.example.comのようなドメイン名をIPアドレスに変換します。

DNSは階層構造を持ち、最上位にいくつかの権威サーバーがあります。ルーターやISPは、名前解決時にどのDNSサーバーに連絡すべきかの情報を提供します。下位のDNSサーバーはマッピングをキャッシュしますが、DNS伝播遅延により古くなることがあります。DNSの結果はブラウザやOSによっても一定期間キャッシュされ、その期間はTTL（Time to Live）によって決まります。

CloudFlareやRoute 53のようなサービスはマネージドDNSサービスを提供しています。一部のDNSサービスは以下のような様々な方法でトラフィックをルーティングできます：

DNSの欠点

参考文献とさらなる情報

コンテンツ配信ネットワーク


出典: なぜCDNを使うのか

コンテンツ配信ネットワーク（CDN）は、ユーザーに近い場所からコンテンツを配信する、世界中に分散したプロキシサーバーのネットワークです。一般的に、HTML/CSS/JS、写真、動画などの静的ファイルはCDNから配信されますが、AmazonのCloudFrontのように動的コンテンツをサポートするCDNもあります。サイトのDNS解決はクライアントにどのサーバーに接続すべきかを伝えます。

CDNからコンテンツを配信することで、次の2つの方法でパフォーマンスが大幅に向上します：

プッシュCDN

プッシュCDNはサーバーで変更があるたびに新しいコンテンツを受け取ります。コンテンツ提供の全責任はあなたにあり、直接CDNにアップロードし、URLを書き換えてCDNを指すようにします。コンテンツの有効期限や更新タイミングを設定できます。コンテンツは新規または変更時のみアップロードされるため、トラフィックを最小限に抑えつつ、ストレージを最大限に活用します。

トラフィックが少ないサイトや更新頻度の低いコンテンツのサイトではプッシュCDNが適しています。コンテンツは一度CDNに配置され、定期的に再取得されることはありません。

プルCDN

プルCDNは最初のユーザーがコンテンツをリクエストした際にあなたのサーバーから新しいコンテンツを取得します。コンテンツはサーバー上に残し、URLを書き換えてCDNを指すようにします。そのため、コンテンツがCDNにキャッシュされるまではリクエストが遅くなります。

TTL（Time-to-Live）はコンテンツがキャッシュされる期間を決定します。プルCDNはCDN上のストレージ使用を最小限に抑えますが、ファイルの期限切れ後に実際には変更されていない場合でも再取得されることで冗長なトラフィックが発生する可能性があります。

トラフィックが多いサイトではプルCDNが適しており、最近リクエストされたコンテンツのみがCDNに残り、トラフィックがより均等に分散されます。

デメリット：CDN

出典および参考文献

ロードバランサー


出典: スケーラブルシステム設計パターン

ロードバランサーは、アプリケーションサーバーやデータベースなどのコンピューティングリソースに対するクライアントからのリクエストを分散します。 各ケースで、ロードバランサーはコンピューティングリソースからのレスポンスを適切なクライアントに返します。 ロードバランサーは以下に効果的です：

ロードバランサーはハードウェア（高価）やHAProxyのようなソフトウェアで実装可能です。

追加の利点には以下があります：

障害に備えて、ロードバランサーはアクティブ-パッシブまたはアクティブ-アクティブモードで複数台構成することが一般的です。

ロードバランサーは以下のような様々な指標に基づいてトラフィックをルーティングできます：

レイヤー4ロードバランシング

レイヤー4ロードバランサーはリクエスト分散のためにトランスポート層の情報を参照します。 一般的には、ヘッダー内の送信元・宛先IPアドレスとポートを使いますが、パケットの内容は見ません。 レイヤー4ロードバランサーはアップストリームサーバーへのネットワークパケットを転送し、ネットワークアドレス変換（NAT）を行います。

レイヤー7ロードバランシング

レイヤー7のロードバランサーは、リクエストをどのように分配するかを決定するためにアプリケーション層を参照します。これはヘッダー、メッセージ、クッキーの内容を含む場合があります。レイヤー7のロードバランサーはネットワークトラフィックを終端し、メッセージを読み込み、負荷分散の決定を行い、選択されたサーバーへの接続を開きます。例えば、レイヤー7のロードバランサーは動画トラフィックを動画をホストするサーバーに、より機密性の高いユーザー請求トラフィックをセキュリティ強化されたサーバーに振り分けることができます。

柔軟性の代償として、レイヤー4のロードバランシングはレイヤー7よりも少ない時間と計算資源を必要としますが、最新の汎用ハードウェアではパフォーマンスへの影響は最小限です。

水平スケーリング

ロードバランサーは水平スケーリングにも役立ち、パフォーマンスと可用性を向上させます。汎用マシンを使用してスケールアウトすることは、より高価なハードウェア上で単一のサーバーをスケールアップする（垂直スケーリングと呼ばれる）よりもコスト効率が高く、可用性も向上します。また、専門的な企業システムよりも汎用ハードウェアで働く人材を採用する方が容易です。

#### 欠点：水平スケーリング

欠点：ロードバランサー

参考文献およびさらなる読み物

リバースプロキシ（ウェブサーバー）


出典: ウィキペディア

リバースプロキシは、内部サービスを集中管理し、一般向けに統一されたインターフェースを提供するウェブサーバーです。 クライアントからのリクエストは、それを満たすことができるサーバーに転送され、リバースプロキシはそのサーバーの応答をクライアントに返します。

追加の利点には以下が含まれます：

ロードバランサーとリバースプロキシの違い

リバースプロキシの欠点

参考文献とさらなる読み物

アプリケーション層


出典：システムをスケールさせるためのアーキテクチャ入門

ウェブ層をアプリケーション層（プラットフォーム層とも呼ばれる）から分離することで、両層を独立してスケールおよび構成できます。新しいAPIを追加する場合、必ずしも追加のウェブサーバーを増やすことなくアプリケーションサーバーを追加できます。単一責任の原則は、小さく自律的なサービスが連携して動作することを推奨します。小さなチームと小さなサービスは、急速な成長に対してより積極的な計画が可能です。

アプリケーション層のワーカーは、非同期処理の実現も支援します。

マイクロサービス

この議論に関連するのがマイクロサービスであり、独立してデプロイ可能な小さくモジュール化されたサービス群として説明できます。各サービスは独自のプロセスを実行し、ビジネス目標を達成するために定義された軽量の通信手段を通じて連携します。1

例えばPinterestでは、ユーザープロファイル、フォロワー、フィード、検索、写真アップロードなどのマイクロサービスが存在する可能性があります。

サービスディスカバリ

Consul、Etcd、およびZookeeperなどのシステムは、登録された名前、アドレス、ポートを追跡することでサービス同士の検出を支援します。ヘルスチェックはサービスの健全性を検証し、多くの場合HTTPエンドポイントを使用して行われます。ConsulとEtcdは共に構成値やその他の共有データを保存するのに便利な組み込みのkey-valueストアを備えています。

欠点：アプリケーション層

出典および参考資料

データベース


出典：最初の1000万人ユーザーへのスケーリング

リレーショナルデータベース管理システム（RDBMS）

リレーショナルデータベース（SQLのようなもの）は、テーブルに整理されたデータ項目の集合です。

ACID はリレーショナルデータベースのトランザクションの特性のセットです。

リレーショナルデータベースをスケールさせる手法は多数あります：マスター・スレーブレプリケーション、マスター・マスターレプリケーション、フェデレーション、シャーディング、非正規化、およびSQLチューニング。

#### マスター・スレーブレプリケーション

マスターは読み書きを提供し、書き込みを一つ以上のスレーブにレプリケートします。スレーブは読み込みのみを提供します。スレーブはさらに木構造のように別のスレーブにレプリケートすることもできます。マスターがオフラインになった場合、スレーブがマスターに昇格されるか新しいマスターが用意されるまで、システムは読み取り専用モードで動作を続けられます。


出典: Scalability, availability, stability, patterns

##### 欠点：マスター・スレーブレプリケーション

#### マスター・マスターレプリケーション

両方のマスターが読み書きを提供し、書き込みに関しては互いに調整します。どちらかのマスターがダウンしても、システムは読み書きの両方を継続して動作できます。


出典: Scalability, availability, stability, patterns

##### 欠点：マスター・マスターレプリケーション

##### 欠点：レプリケーション

##### 参考文献および詳細：レプリケーション

#### フェデレーション


出典：初めての1000万人ユーザーへのスケーリング

フェデレーション（または機能的パーティショニング）は、データベースを機能ごとに分割します。例えば、単一のモノリシックなデータベースの代わりに、フォーラム、ユーザー、製品の3つのデータベースを持つことで、各データベースへの読み書きトラフィックが減り、その結果レプリケーション遅延が少なくなります。小さいデータベースはメモリに収まるデータが増え、キャッシュの局所性が向上するためキャッシュヒット率が上がります。単一の中央マスターが書き込みを直列化しないため、並列に書き込むことができ、スループットが向上します。

##### 欠点：フェデレーション

##### 参考文献および詳細：フェデレーション

#### シャーディング


出典：スケーラビリティ、可用性、安定性、パターン

シャーディングはデータを異なるデータベースに分散させ、各データベースがデータのサブセットのみを管理できるようにします。ユーザーデータベースを例に取ると、ユーザー数が増えるにつれて、クラスターにシャードが追加されます。

federationの利点と同様に、シャーディングは読み書きトラフィックの減少、レプリケーションの減少、キャッシュヒットの増加をもたらします。インデックスサイズも減少し、一般的にクエリの高速化によってパフォーマンスが向上します。1つのシャードがダウンしても他のシャードは稼働し続けますが、データ損失を防ぐために何らかのレプリケーションを追加する必要があります。federationと同様に、書き込みを直列化する単一の中央マスターがないため、スループットを増加させて並列書き込みが可能です。

ユーザーテーブルをシャーディングする一般的な方法は、ユーザーの姓のイニシャルや地理的位置によるものです。

##### 欠点：シャーディング

##### 出典およびさらなる参考資料：シャーディング

#### 非正規化

非正規化は書き込み性能を一部犠牲にして読み取り性能を向上させることを試みます。高価な結合を避けるために、冗長なデータコピーを複数のテーブルに書き込みます。PostgreSQLやOracleなど一部のRDBMSは、冗長情報の保持とコピーの一貫性維持を処理するマテリアライズドビューをサポートしています。

federationやshardingのような技術でデータが分散されると、データセンター間の結合管理はさらに複雑になります。非正規化はそのような複雑な結合の必要性を回避するかもしれません。

ほとんどのシステムでは、読み取りが書き込みを100:1または1000:1で大幅に上回ることがあります。複雑なデータベース結合を伴う読み取りは非常にコストがかかり、多くの時間をディスク操作に費やします。

##### 欠点：非正規化

###### 出典およびさらなる参考資料：非正規化 #### SQL チューニング

SQL チューニングは広範なトピックであり、多くの書籍が参考資料として書かれています。

ベンチマークおよびプロファイリングを行い、ボトルネックをシミュレートして発見することが重要です。

ベンチマークとプロファイリングによって、次の最適化が示唆されることがあります。

##### スキーマを厳密にする

##### 良いインデックスを使う

##### 高コストなジョインを避ける

##### テーブルをパーティション分割する

##### クエリキャッシュの調整

##### 出典および参考文献：SQLチューニング

NoSQL

NoSQLはキー・バリュー・ストア、ドキュメントストア、ワイドカラムストア、またはグラフデータベースで表現されるデータ項目の集合である。 データは非正規化されており、結合は一般的にアプリケーションコード内で行われる。 多くのNoSQLストアは真のACIDトランザクションを欠き、最終的整合性を重視する。

BASEはNoSQLデータベースの特性を表すために使われることが多い。 CAP定理と比較すると、BASEは一貫性よりも可用性を優先する。

SQLかNoSQLかの選択に加えて、どのタイプのNoSQLデータベースがユースケースに最適かを理解することが有用である。 次節ではキー・バリュー・ストア、ドキュメントストア、ワイドカラムストア、グラフデータベースをレビューする。

#### キー・バリュー・ストア

抽象化：ハッシュテーブル

キー・バリュー・ストアは一般的にO(1)の読み書きを可能にし、メモリまたはSSDでバックアップされることが多い。 データストアは辞書式順序でキーを保持でき、キー範囲の効率的な取得を可能にする。 キー・バリュー・ストアは値にメタデータを格納することもできる。

キー・バリュー・ストアは高いパフォーマンスを提供し、シンプルなデータモデルやインメモリキャッシュ層のような急速に変化するデータによく使われる。 限られた操作セットのみを提供するため、追加の操作が必要な場合は複雑さがアプリケーション層に移る。

キー・バリュー・ストアはドキュメントストアや場合によってはグラフデータベースのようなより複雑なシステムの基礎となる。

##### 出典および参考文献：キー・バリュー・ストア

#### ドキュメントストア

抽象化: ドキュメントを値として格納するキー・バリュー・ストア

ドキュメントストアはドキュメント（XML、JSON、バイナリなど）を中心に設計されており、ドキュメントは特定のオブジェクトに関するすべての情報を格納します。ドキュメントストアは、ドキュメント内部の構造に基づいてクエリを実行するためのAPIやクエリ言語を提供します。注：多くのキー・バリュー・ストアは値のメタデータを扱う機能を含んでおり、これら二つのストレージタイプの境界を曖昧にしています。

基盤となる実装により、ドキュメントはコレクション、タグ、メタデータ、またはディレクトリによって組織化されます。ドキュメントはグループ化されることもありますが、ドキュメント同士が全く異なるフィールドを持つ場合もあります。

MongoDBやCouchDBのような一部のドキュメントストアは、複雑なクエリを実行するためのSQLに似た言語も提供しています。DynamoDBはキー・バリューとドキュメントの両方をサポートしています。

ドキュメントストアは高い柔軟性を持ち、時折変更されるデータを扱う場合によく使われます。

##### 参考文献およびさらなる学習: ドキュメントストア

#### ワイドカラムストア


出典: SQL & NoSQL、簡単な歴史

抽象化: ネストされたマップ ColumnFamily>

ワイドカラムストアの基本データ単位はカラム（名前/値のペア）です。カラムはカラムファミリー（SQLのテーブルに類似）にグループ化されます。スーパーカラムファミリーはさらにカラムファミリーをグループ化します。行キーで各カラムに独立してアクセスでき、同じ行キーのカラムが行を形成します。各値にはバージョニングや競合解決のためのタイムスタンプが含まれます。

Googleは最初のワイドカラムストアとしてBigtableを導入し、これがHadoopエコシステムでよく使われるオープンソースのHBaseやFacebookのCassandraに影響を与えました。BigTable、HBase、Cassandraなどのストアはキーを辞書順で保持し、選択的なキー範囲の効率的な取得を可能にしています。

ワイドカラムストアは高い可用性と高いスケーラビリティを提供し、非常に大規模なデータセットによく使用されます。

##### 参考文献およびさらなる学習: ワイドカラムストア

#### グラフデータベース


出典：グラフデータベース

抽象化：グラフ

グラフデータベースでは、各ノードがレコードであり、各アークが2つのノード間の関係を表します。グラフデータベースは、多数の外部キーや多対多の関係を持つ複雑な関係を表現するように最適化されています。

グラフデータベースは、ソーシャルネットワークのような複雑な関係を持つデータモデルに対して高いパフォーマンスを提供します。比較的新しい技術であり、まだ広く使われていないため、開発ツールやリソースを見つけるのが難しい場合があります。多くのグラフはREST APIでのみアクセス可能です。

##### 出典および追加資料：グラフ

#### 出典および追加資料：NoSQL

SQLまたはNoSQL


出典：RDBMSからNoSQLへの移行

SQLを選ぶ理由:

NoSQLを選ぶ理由:

NoSQLに適したサンプルデータ:

##### 出典およびさらなる参考資料: SQLまたはNoSQL

キャッシュ


出典: スケーラブルなシステム設計パターン

キャッシュはページの読み込み時間を改善し、サーバーやデータベースの負荷を軽減できます。このモデルでは、ディスパッチャーがまずリクエストが以前に行われたかどうかを確認し、実際の実行を省くために以前の結果を返そうとします。

データベースは通常、パーティション全体で読み書きが均等に分布することで恩恵を受けます。人気のあるアイテムは分布を偏らせ、ボトルネックを引き起こす可能性があります。データベースの前にキャッシュを置くことで、不均等な負荷やトラフィックの急増を吸収できます。

クライアントキャッシュ

キャッシュはクライアント側（OSやブラウザ）、サーバー側、または独立したキャッシュ層に配置できます。

CDNキャッシュ

CDNはキャッシュの一種と見なされます。

ウェブサーバーキャッシュ

リバースプロキシやVarnishのようなキャッシュは静的および動的コンテンツを直接提供できます。ウェブサーバーもリクエストをキャッシュし、アプリケーションサーバーに連絡せずにレスポンスを返せます。

データベースキャッシュ

データベースは通常、デフォルト設定で何らかのキャッシュレベルを含み、汎用的なユースケースに最適化されています。特定の使用パターンに合わせてこれらの設定を調整すると、さらにパフォーマンスを向上させることができます。

アプリケーションキャッシュ

MemcachedやRedisのようなインメモリキャッシュは、アプリケーションとデータストレージの間にあるキー・バリューストアです。データがRAMに保持されるため、通常ディスクに保存されるデータベースよりもはるかに高速です。RAMはディスクよりも容量が限られているため、キャッシュ無効化アルゴリズム（例えば最も最近使われていない（LRU）)）が「冷たい」エントリを無効化し、「熱い」データをRAMに保持するのに役立ちます。

Redisには以下の追加機能があります：

キャッシュできるレベルは複数あり、大きく分けてデータベースクエリとオブジェクトの2種類があります：

一般的に、ファイルベースのキャッシュはクローン作成やオートスケーリングを難しくするため避けるべきです。

データベースクエリレベルでのキャッシュ

データベースをクエリするたびに、クエリをキーとしてハッシュ化し、その結果をキャッシュに保存します。この方法は有効期限の問題があります：

オブジェクトレベルでのキャッシュ

データをアプリケーションコードと同様にオブジェクトとして見なします。アプリケーションがデータベースからのデータセットをクラスインスタンスやデータ構造に組み立てます：

キャッシュすべきものの提案：

キャッシュを更新するタイミング

キャッシュに保存できるデータ量は限られているため、ユースケースに最適なキャッシュ更新戦略を決定する必要があります。

#### Cache-aside


出典: From cache to in-memory data grid

アプリケーションがストレージからの読み書きを担当します。キャッシュはストレージと直接やり取りしません。アプリケーションの動作は以下の通りです：

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user
Memcached は一般的にこのように使用されます。

キャッシュに追加されたデータの後続の読み取りは高速です。Cache-asideはレイジーローディングとも呼ばれます。要求されたデータのみがキャッシュされ、要求されていないデータでキャッシュが埋まるのを防ぎます。

##### 欠点: cache-aside

#### ライトスルー


出典: Scalability, availability, stability, patterns

アプリケーションはキャッシュを主要なデータストアとして使用し、読み書きを行い、キャッシュはデータベースへの読み書きを担当します：

アプリケーションコード：

set_user(12345, {"foo":"bar"})
キャッシュコード：

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)

ライトスルーは書き込み操作のため全体的に遅いですが、直後に書き込まれたデータの読み取りは高速です。ユーザーはデータの更新よりも読み取り時の遅延を一般的により許容します。キャッシュ内のデータは古くありません。

##### デメリット：ライトスルー

#### ライトビハインド（ライトバック）


出典：スケーラビリティ、可用性、安定性パターン

ライトビハインドでは、アプリケーションは以下を行います：

##### デメリット：ライトビハインド

#### リフレッシュアヘッド


出典：キャッシュからインメモリデータグリッドへ

キャッシュは自動的に最近アクセスされたキャッシュエントリを期限切れ前にリフレッシュするよう設定できます。

リフレッシュアヘッドは、キャッシュが将来必要とされる可能性のあるアイテムを正確に予測できれば、リードスルーよりもレイテンシを低減できます。

##### デメリット：リフレッシュアヘッド

欠点: キャッシュ

参考文献およびさらなる読み物

非同期処理


出典: スケールのためのシステム設計入門

非同期ワークフローは、インラインで実行すると高コストな操作のリクエスト時間を短縮するのに役立つ。また、定期的なデータ集約など、時間のかかる作業を事前に行うことにも役立つ。

メッセージキュー

メッセージキューはメッセージの受信、保持、配信を行う。操作がインラインで行うには遅すぎる場合、以下のワークフローでメッセージキューを利用できる。

ユーザーはブロックされず、ジョブはバックグラウンドで処理される。この間、クライアントはタスクが完了したかのように見せるために少量の処理を行うことがある。たとえば、ツイートを投稿する場合、ツイートは即座にタイムラインに表示されるが、実際にすべてのフォロワーに配信されるまでには時間がかかることがある。

Redis はシンプルなメッセージブローカーとして有用だが、メッセージが失われる可能性がある。

RabbitMQ は人気があるが、'AMQP'プロトコルに適応し、自分でノードを管理する必要がある。 Amazon SQS はホスト型ですが、高遅延が発生する可能性があり、メッセージが二重に配信される可能性があります。

タスクキュー

タスクキューはタスクと関連データを受け取り、それを実行し、結果を届けます。スケジューリングをサポートでき、計算負荷の高いジョブをバックグラウンドで実行するのに利用可能です。

Celery はスケジューリングをサポートし、主にPythonでのサポートがあります。

バックプレッシャー

キューのサイズが大幅に増加すると、キューサイズがメモリ容量を超え、キャッシュミスやディスク読み込みが発生し、さらにパフォーマンスが低下します。バックプレッシャー はキューサイズを制限することで、スループット率を維持し、キュー内のジョブに対して良好な応答時間を保つのに役立ちます。キューが満杯になると、クライアントはサーバービジーやHTTP 503ステータスコードを受け取り、後で再試行を促されます。クライアントは後でリクエストを再試行でき、指数バックオフを用いることもあります。

デメリット：非同期性

出典および参考文献

通信


出典: OSI 7層モデル

ハイパーテキスト転送プロトコル（HTTP）

HTTPはクライアントとサーバー間でデータをエンコードし転送する方法です。リクエスト/レスポンス型のプロトコルであり、クライアントはリクエストを発行し、サーバーは関連コンテンツとリクエストの完了状態情報を含むレスポンスを返します。HTTPは自己完結型であり、多くの中間ルーターやサーバーを経由してロードバランシング、キャッシュ、暗号化、圧縮を行いながらリクエストとレスポンスが流れます。

基本的なHTTPリクエストは動詞（メソッド）とリソース（エンドポイント）で構成されます。以下は一般的なHTTP動詞です：

| 動詞 | 説明 | 冪等* | 安全 | キャッシュ可能 | |---|---|---|---|---|

| GET | リソースを読み取る | はい | はい | はい | | POST | リソースを作成するか、データを処理するプロセスをトリガーする | いいえ | いいえ | レスポンスに新鮮さ情報が含まれる場合ははい | | PUT | リソースを作成または置き換える | はい | いいえ | いいえ | | PATCH | リソースを部分的に更新する | いいえ | いいえ | レスポンスに新鮮さ情報が含まれる場合ははい | | DELETE | リソースを削除する | はい | いいえ | いいえ |

HTTPは、TCPやUDPなどの下位プロトコルに依存するアプリケーション層プロトコルです。

#### 出典およびさらなる読み物: HTTP

トランスミッションコントロールプロトコル（TCP）


出典：マルチプレイヤーゲームの作り方

TCPはIPネットワーク上のコネクション指向プロトコルです。接続はハンドシェイクを使って確立および終了されます。送信されるすべてのパケットは、次の方法で元の順序で破損なく宛先に届くことが保証されます：

送信者が正しい応答を受け取らない場合、パケットを再送します。タイムアウトが複数回発生すると接続は切断されます。TCPはまた、フロー制御と輻輳制御も実装しています。これらの保証は遅延を引き起こし、一般的にUDPより効率の悪い伝送となります。

高スループットを確保するために、ウェブサーバーは多数のTCP接続を開いたままにでき、その結果メモリ使用量が増加します。ウェブサーバースレッドと例えばmemcachedサーバー間で多数の開いた接続を持つことはコストがかかります。コネクションプーリングは、適用可能な場合はUDPへの切り替えに加えて役立ちます。

TCPは高い信頼性が必要で時間的制約が比較的少ないアプリケーションに有用です。例としてウェブサーバー、データベース情報、SMTP、FTP、SSHなどがあります。

UDPよりTCPを使う場合：

ユーザーデータグラムプロトコル（UDP）


出典: マルチプレイヤーゲームの作り方

UDPはコネクションレスです。データグラム（パケットに類似）はデータグラムレベルでのみ保証されます。データグラムは順序が入れ替わって届くことや、全く届かないこともあります。UDPは輻輳制御をサポートしません。TCPがサポートする保証がないため、UDPは一般的により効率的です。

UDPはブロードキャストが可能で、サブネット上の全デバイスにデータグラムを送信します。これはクライアントがまだIPアドレスを受け取っていないため、TCPがIPアドレスなしでストリームを送る方法を妨げるDHCPで有用です。

UDPは信頼性は低いですが、VoIP、ビデオチャット、ストリーミング、リアルタイムマルチプレイヤーゲームなどのリアルタイム用途に適しています。

UDPをTCPの代わりに使うのは以下の場合です：

#### 出典およびさらなる読み物: TCPとUDP

リモートプロシージャコール（RPC）


出典: システム設計面接を攻略する

RPCでは、クライアントが通常リモートサーバーの異なるアドレス空間でプロシージャを実行させます。プロシージャはローカルプロシージャコールのようにコード化されており、クライアントプログラムからサーバーとの通信方法の詳細を抽象化しています。リモートコールは通常ローカルコールより遅く信頼性が低いため、RPCコールとローカルコールを区別することが有用です。代表的なRPCフレームワークにはProtobuf、Thrift、Avroがあります。

RPCはリクエスト-レスポンスプロトコルです：

サンプルRPC呼び出し:

GET /someoperation?data=anId
POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}
RPCは動作の公開に焦点を当てています。RPCは内部通信でパフォーマンス上の理由からよく使用されます。ネイティブ呼び出しを手作業で作成してユースケースにより適合させることができるためです。

ネイティブライブラリ（別名SDK）を選択する場合：

RESTに従ったHTTP APIは、より一般的に公開APIで使われる傾向があります。

#### 欠点：RPC

表現状態転送（REST）

RESTはクライアント/サーバーモデルを強制するアーキテクチャスタイルで、クライアントはサーバーが管理するリソースの集合に対して動作します。サーバーはリソースの表現と、リソースを操作したり新しい表現を取得したりするためのアクションを提供します。全ての通信はステートレスでキャッシュ可能でなければなりません。

RESTfulインターフェースには4つの特徴があります：

RESTのサンプル呼び出し：

GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
RESTはデータの公開に焦点を当てています。クライアント/サーバー間の結合度を最小限に抑え、公共のHTTP APIでよく使用されます。RESTはURIを通じてリソースをより一般的かつ均一な方法で公開し、ヘッダーによる表現やGET、POST、PUT、DELETE、PATCHなどの動詞によるアクションを使用します。ステートレスであるため、RESTは水平スケーリングやパーティショニングに適しています。

#### 欠点: REST

RPCとREST呼び出しの比較

| 操作 | RPC | REST | |---|---|---| | サインアップ | POST /signup | POST /persons | | 退会 | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | 人物情報取得 | GET /readPerson?personid=1234 | GET /persons/1234 | | 人物のアイテムリスト取得 | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | 人物のアイテムに追加 | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | アイテム更新 | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | アイテム削除 | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

出典: RESTをRPCより好む理由を本当に知っていますか

#### 出典およびさらなる参考資料: RESTとRPC

セキュリティ

このセクションは更新が必要です。貢献をご検討ください！

セキュリティは広範なテーマです。 かなりの経験やセキュリティの背景があるか、セキュリティ知識が必要な職に応募していない限り、おそらく基本的なこと以上を知る必要はありません:

参考資料およびさらなる読み物

付録

時折「ざっとした」見積もりを求められることがあります。 例えば、ディスクから100枚の画像サムネイルを生成するのにどれくらい時間がかかるか、またはデータ構造がどれほどのメモリを必要とするかを見積もる場合です。 2のべき乗表 と すべてのプログラマーが知っておくべきレイテンシ数値 は便利な参考資料です。

2のべき乗表

Power           Exact Value         Approx Value        Bytes
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

#### 参照元およびさらなる読書資料

すべてのプログラマーが知っておくべきレイテンシーの数値

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
HDD seek                            10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from HDD     30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms
Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns
上記の数値に基づく便利な指標：

#### レイテンシー数値の可視化

#### 出典およびさらなる参考資料

追加のシステム設計面接質問

一般的なシステム設計の面接質問と、それぞれの解決方法へのリンク集。

| 質問 | 参考リンク | |---|---| | Dropboxのようなファイル同期サービスを設計せよ | youtube.com | | Googleのような検索エンジンを設計せよ | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | Googleのようなスケーラブルなウェブクローラーを設計せよ | quora.com | | Googleドキュメントを設計せよ | code.google.com
neil.fraser.name | | Redisのようなキー・バリューストアを設計せよ | slideshare.net | | Memcachedのようなキャッシュシステムを設計せよ | slideshare.net | | Amazonのようなレコメンデーションシステムを設計せよ | hulu.com
ijcai13.org | | BitlyのようなTinyURLシステムを設計せよ | n00tc0d3r.blogspot.com | | WhatsAppのようなチャットアプリを設計せよ | highscalability.com | Instagramのような写真共有システムを設計せよ | highscalability.com
highscalability.com | | Facebookのニュースフィード機能を設計せよ | quora.com
quora.com
slideshare.net | | Facebookのタイムライン機能を設計せよ | facebook.com
highscalability.com | | Facebookのチャット機能を設計せよ | erlang-factory.com
facebook.com |

| Facebookのようなグラフ検索機能を設計する | facebook.com
facebook.com
facebook.com | | CloudFlareのようなコンテンツ配信ネットワークを設計する | figshare.com | | Twitterのようなトレンドトピックシステムを設計する | michael-noll.com
snikolov .wordpress.com | | ランダムID生成システムを設計する | blog.twitter.com
github.com | | 一定時間内のトップkリクエストを返す | cs.ucsb.edu
wpi.edu | | 複数のデータセンターからデータを提供するシステムを設計する | highscalability.com | | オンラインマルチプレイヤーカードゲームを設計する | indieflashblog.com
buildnewgames.com | | ガベージコレクションシステムを設計する | stuffwithstuff.com
washington.edu | | APIレートリミッターを設計する | https://stripe.com/blog/ | | 株式取引所（NASDAQやBinanceのような）を設計する | Jane Street
Golang Implementation
Go Implementation | | システム設計の質問を追加する | Contribute |

実世界のアーキテクチャ

実際のシステムがどのように設計されているかに関する記事。


出典: 大規模Twitterタイムライン

以下の記事では細かい詳細にこだわらず、代わりに：

|種類 | システム | 参照 | |---|---|---| | データ処理 | MapReduce - Googleの分散データ処理 | research.google.com | | データ処理 | Spark - Databricksの分散データ処理 | slideshare.net | | データ処理 | Storm - Twitterの分散データ処理 | slideshare.net | | | | | | データストア | Bigtable - Googleの分散カラム指向データベース | harvard.edu | | データストア | HBase - Bigtableのオープンソース実装 | slideshare.net | | データストア | Cassandra - Facebookの分散カラム指向データベース | slideshare.net | | データストア | DynamoDB - Amazonのドキュメント指向データベース | harvard.edu | | データストア | MongoDB - ドキュメント指向データベース | slideshare.net | | データストア | Spanner - Googleのグローバル分散データベース | research.google.com | | データストア | Memcached - 分散メモリキャッシュシステム | slideshare.net | | データストア | Redis - 永続性と値タイプを備えた分散メモリキャッシュシステム | slideshare.net | | | | | | ファイルシステム | Google File System (GFS) - 分散ファイルシステム | research.google.com | | ファイルシステム | Hadoop File System (HDFS) - GFSのオープンソース実装 | apache.org | | | | | | その他 | Chubby - Googleの疎結合分散システム用ロックサービス | research.google.com | | その他 | Dapper - 分散システムのトレーシングインフラストラクチャ | research.google.com | | その他 | Kafka - LinkedInのPub/Subメッセージキュー | slideshare.net | | その他 | Zookeeper - 同期を可能にする集中型インフラとサービス | slideshare.net | | | アーキテクチャを追加 | Contribute |

企業アーキテクチャ

| 企業 | 参照 | |---|---| | Amazon | Amazonアーキテクチャ | | Cinchcast | 毎日1,500時間のオーディオ制作 | | DataSift | 毎秒120,000ツイートのリアルタイムデータマイニング | | Dropbox | Dropboxのスケーリング方法 | | ESPN | 毎秒100,000回の操作 | | Google | Googleアーキテクチャ | | Instagram | 1400万人のユーザー、テラバイトの写真
Instagramの動力源 | | Justin.tv | Justin.Tvのライブビデオ放送アーキテクチャ | | Facebook | Facebookでのmemcachedのスケーリング
TAO: Facebookのソーシャルグラフ用分散データストア
Facebookの写真ストレージ
Facebookが80万人の同時視聴者にライブ配信する方法 | | Flickr | Flickrアーキテクチャ | | Mailbox | 6週間で0から100万人のユーザーへ | | Netflix | Netflixスタックの360度ビュー
Netflix：再生ボタンを押すと何が起こるか | | Pinterest | 月間数百億ページビューへのスケーリング
1800万人の訪問者、10倍の成長、従業員12名 | | Playfish | 月間5,000万人のユーザー数と成長 | | PlentyOfFish | PlentyOfFishアーキテクチャ | | Salesforce | 1日13億件のトランザクションを処理する方法 | | Stack Overflow | Stack Overflowアーキテクチャ | | TripAdvisor | 4,000万人の訪問者、2億の動的ページビュー、30TBのデータ | | Tumblr | 月間150億ページビュー | | Twitter | Twitterを1万倍高速化
MySQLで1日2.5億ツイートを保存
1億5,000万人のアクティブユーザー、30万QPS、22MB/sのファイアホース
大規模なタイムライン
Twitterのビッグ＆スモールデータ
Twitterの運用：1億ユーザー超のスケーリング
Twitterが毎秒3,000枚の画像を処理する方法 | | Uber | Uberのリアルタイムマーケットプラットフォームのスケーリング方法
Uberのスケーリング教訓：2000エンジニア、1000サービス、8000 Gitリポジトリ | | WhatsApp | Facebookが190億ドルで買収したWhatsAppのアーキテクチャ | | YouTube | YouTubeのスケーラビリティ
YouTubeアーキテクチャ |

企業のエンジニアリングブログ

面接を受ける企業のアーキテクチャ。
>
出題される質問は同じドメインから来ることがあります。

#### 出典およびさらなる参考資料

ブログを追加したいですか？ 重複作業を避けるために、以下のリポジトリにあなたの会社のブログを追加することを検討してください：

開発中

セクションを追加したり、進行中のものを完成させるのを手伝いたいですか？ 貢献する！

クレジット

クレジットと出典はこのリポジトリ全体にわたって提供されています。

特別な感謝：

連絡先情報

ご質問やご意見、ご不明な点がございましたら、お気軽にご連絡ください。

私の連絡先情報はGitHubページに記載されています。

ライセンス

このリポジトリのコードおよびリソースはオープンソースライセンスのもとで提供しています。これは私個人のリポジトリであるため、コードおよびリソースに対するライセンスは私から直接提供されており、私の勤務先（Facebook）からではありません。

著作権 2017 Donne Martin

クリエイティブ・コモンズ 表示 4.0 国際 ライセンス (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/

--- Tranlated By Open Ai Tx | Last indexed: 2025-08-09 ---

Original README: View on GitHub

Translated by OpenAiTx | Last updated: 2025-09-16