Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

https://github.com/donnemartin/system-design-primer

Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.
https://github.com/donnemartin/system-design-primer

design design-patterns design-system development interview interview-practice interview-questions programming python system web web-application webapp

Last synced: about 1 month ago
JSON representation

Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.

Lists

README 

        
*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简䜓䞭文](README-zh-Hans.md) ∙ [繁體䞭文](README-zh-TW.md) | [العَرَؚِيَّة‎](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [àŠ¬àŠŸàŠ‚àŠ²àŠŸ](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληΜικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עבךית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국얎](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русскОй язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [àž àž²àž©àž²à¹„àž—àž¢](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [TÃŒrkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)*



# システム蚭蚈入門





  

  





## 動機・目的



> 倧芏暡システムのシステム蚭蚈を孊ぶ

>

> システム蚭蚈面接課題に備える



### 倧芏暡システムの蚭蚈を孊ぶ



スケヌラブルなシステムのシステム蚭蚈を孊ぶこずは、より良い゚ンゞニアになるこずに資するでしょう。



システム蚭蚈はずおも広範なトピックを含みたす。システム蚭蚈原理に぀いおは **むンタヌネット䞊には膚倧な量の文献が散らばっおいたす。**



このリポゞトリは倧芏暡システム構築に必芁な知識を孊ぶこずができる **文献リストを䜓系的にたずめたもの** です。



### オヌプン゜ヌスコミュニティから孊ぶ



このプロゞェクトは、これからもずっず曎新されおいくオヌプン゜ヌスプロゞェクトの初期段階にすぎたせん。



[Contributions](#contributing) は倧歓迎です



### システム蚭蚈面接課題に備える



コヌド技術面接に加えお、システム蚭蚈に関する知識は、倚くのテック䌁業における **技術採甚面接プロセス** で **必芁䞍可欠な芁玠** です。



**システム蚭蚈面接での頻出質問に備え**、自分の解答ず*暡範解答*:ディスカッション、コヌドそしお図衚などを*比范*しお孊びたしょう。



面接準備に圹立぀その他のトピック:



* [孊習指針](#孊習指針)

* [システム蚭蚈面接課題にどのように準備するか](#システム蚭蚈面接にどのようにしお臚めばいいか)

* [システム蚭蚈課題䟋 **ずその解答**](#システム蚭蚈課題䟋ずその解答)

* [オブゞェクト指向蚭蚈課題䟋、 **ずその解答**](#オブゞェクト指向蚭蚈問題ず解答)

* [その他のシステム蚭蚈面接課題䟋](#他のシステム蚭蚈面接䟋題)



## 暗蚘カヌド





  

  





この[Anki甚フラッシュカヌドデッキ](https://apps.ankiweb.net/) は、間隔反埩を掻甚しお、システム蚭蚈のキヌコンセプトの孊習を支揎したす。



* [システム蚭蚈デッキ](resources/flash_cards/System%20Design.apkg)

* [システム蚭蚈緎習課題デッキ](resources/flash_cards/System%20Design%20Exercises.apkg)

* [オブゞェクト指向緎習課題デッキ](resources/flash_cards/OO%20Design.apkg)



倖出先や移動䞭の勉匷に圹立぀でしょう。



### コヌディング技術課題甚の問題: 緎習甚むンタラクティブアプリケヌション



コヌド技術面接甚の問題を探しおいる堎合は[**こちら**](https://github.com/donnemartin/interactive-coding-challenges)





  

  





姉効リポゞトリの [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges)も芋おみおください。远加の暗蚘デッキカヌドも入っおいたす。



* [Coding deck](https://github.com/donnemartin/interactive-coding-challenges/tree/master/anki_cards/Coding.apkg)



## コントリビュヌト



> コミュニティから孊ぶ



プルリク゚スト等の貢献は積極的にお願いしたす:



* ゚ラヌ修正

* セクション内容改善

* 新芏セクション远加

* [翻蚳する](https://github.com/donnemartin/system-design-primer/issues/28)



珟圚、内容の改善が必芁な䜜業䞭のコンテンツは[こちら](#進行䞭の䜜業)です。



コントリビュヌトの前に[Contributing Guidelines](CONTRIBUTING.md)を読みたしょう。



## システム蚭蚈目次



> 賛吊も含めた様々なシステム蚭蚈の各トピックの抂芁。 **党おはトレヌドオフの関係にありたす。**

>

> それぞれのセクションはより孊びを深めるような他の文献ぞのリンクが貌られおいたす。





  

  





* [システム蚭蚈トピック: たずはここから](#システム蚭蚈トピックス-たずはここから)

    * [Step 1: スケヌラビリティに関する動画を芋る](#ステップ-1-スケヌラビリティに関する動画を芳お埩習する)

    * [Step 2: スケヌラビリティに関する蚘事を読む](#ステップ-2-スケヌラビリティに関する資料を読んで埩習する)

    * [次のステップ](#次のステップ)

* [パフォヌマンス vs スケヌラビリティ](#パフォヌマンス-vs-スケヌラビリティ)

* [レむテンシヌ vs スルヌプット](#レむテンシヌ-vs-スルヌプット)

* [可甚性 vs 䞀貫性](#可甚性-vs-䞀貫性)

    * [CAP理論](#cap-理論)

        * [CP - 䞀貫性(consistency)ず分割性(partition)耐性](#cp---䞀貫性ず分断耐性consistency-and-partition-tolerance)

        * [AP - 可甚性(availability)ず分割性(partition)耐性](#ap---可甚性ず分断耐性availability-and-partition-tolerance)

* [䞀貫性 パタヌン](#䞀貫性パタヌン)

    * [匱い䞀貫性](#匱い䞀貫性)

    * [結果敎合性](#結果敎合性)

    * [匷い䞀貫性](#匷い䞀貫性)

* [可甚性 パタヌン](#可甚性パタヌン)

    * [フェむルオヌバヌ](#フェむルオヌバヌ)

    * [レプリケヌション](#レプリケヌション)

* [ドメむンネヌムシステム(DNS)](#ドメむンネヌムシステム)

* [コンテンツデリバリヌネットワヌク(CDN)](#コンテンツデリバリヌネットワヌクcontent-delivery-network)

    * [プッシュCDN](#プッシュcdn)

    * [プルCDN](#プルcdn)

* [ロヌドバランサヌ](#ロヌドバランサヌ)

    * [アクティブ/パッシブ構成](#アクティブパッシブ)

    * [アクティブ/アクティブ構成](#アクティブアクティブ)

    * [Layer 4 ロヌドバランシング](#layer-4-ロヌドバランシング)

    * [Layer 7 ロヌドバランシング](#layer-7-ロヌドバランシング)

    * [氎平スケヌリング](#氎平スケヌリング)

* [リバヌスプロキシ (WEBサヌバヌ)](#リバヌスプロキシwebサヌバヌ)

    * [ロヌドバランサヌ vs リバヌスプロキシ](#ロヌドバランサヌ-vs-リバヌスプロキシ)

* [アプリケヌションレむダヌ](#アプリケヌション局)

    * [マむクロサヌビス](#マむクロサヌビス)

    * [サヌビスディスカバリヌ](#service-discovery)

* [デヌタベヌス](#デヌタベヌス)

    * [リレヌショナルデヌタベヌスマネゞメントシステム (RDBMS)](#リレヌショナルデヌタベヌスマネゞメントシステム-rdbms)

        * [マスタヌ/スレヌブ レプリケヌション](#マスタヌスレヌブ-レプリケヌション)

        * [マスタヌ/マスタヌ レプリケヌション](#マスタヌマスタヌ-レプリケヌション)

        * [フェデレヌション](#federation)

        * [シャヌディング](#シャヌディング)

        * [デノヌマラむれヌション](#非正芏化)

        * [SQL チュヌニング](#sqlチュヌニング)

    * [NoSQL](#nosql)

        * [キヌ/バリュヌストア](#キヌバリュヌストア)

        * [ドキュメントストア](#ドキュメントストア)

        * [ワむドカラムストア](#ワむドカラムストア)

        * [グラフ デヌタベヌス](#グラフデヌタベヌス)

    * [SQL or NoSQL](#sqlかnosqlか)

* [キャッシュ](#キャッシュ)

    * [クラむアントキャッシング](#クラむアントキャッシング)

    * [CDNキャッシング](#cdnキャッシング)

    * [Webサヌバヌキャッシング](#webサヌバヌキャッシング)

    * [デヌタベヌスキャッシング](#デヌタベヌスキャッシング)

    * [アプリケヌションキャッシング](#アプリケヌションキャッシング)

    * [デヌタベヌスク゚リレベルでキャッシングする](#デヌタベヌスク゚リレベルでのキャッシング)

    * [オブゞェクトレベルでキャッシングする](#オブゞェクトレベルでのキャッシング)

    * [い぀キャッシュを曎新するのか](#い぀キャッシュを曎新するか)

        * [キャッシュアサむド](#キャッシュアサむド)

        * [ラむトスルヌ](#ラむトスルヌ)

        * [ラむトビハむンド (ラむトバック)](#ラむトビハむンド-ラむトバック)

        * [リフレッシュアヘッド](#リフレッシュアヘッド)

* [非同期凊理](#非同期凊理)

    * [メッセヌゞキュヌ](#メッセヌゞキュヌ)

    * [タスクキュヌ](#タスクキュヌ)

    * [バックプレッシャヌ](#バックプレッシャヌ)

* [通信](#通信)

    * [䌝送制埡プロトコル (TCP)](#䌝送制埡プロトコル-tcp)

    * [ナヌザデヌタグラムプロトコル (UDP)](#ナヌザデヌタグラムプロトコル-udp)

    * [遠隔手続呌出 (RPC)](#遠隔手続呌出-rpc)

    * [Representational state transfer (REST)](#representational-state-transfer-rest)

* [セキュリティ](#セキュリティ)

* [補遺](#補遺)

    * [2の乗数衚](#2の乗数衚)

    * [党おのプログラマヌが知るべきレむテンシヌ倀](#党おのプログラマヌが知るべきレむテンシヌ倀)

    * [他のシステム蚭蚈面接䟋題](#他のシステム蚭蚈面接䟋題)

    * [実䞖界でのアヌキテクチャ](#実䞖界のアヌキテクチャ)

    * [各䌁業のアヌキテクチャ](#各䌁業のアヌキテクチャ)

    * [䌁業の゚ンゞニアブログ](#䌁業の゚ンゞニアブログ)

* [䜜業䞭](#進行䞭の䜜業)

* [クレゞット](#クレゞット)

* [連絡情報](#contact-info)

* [ラむセンス](#license)



## 孊習指針



> 孊習スパンに応じおみるべきトピックス (short, medium, long)



![Imgur](images/OfVllex.png)



**Q: 面接のためには、ここにあるものすべおをやらないずいけないのでしょうか**



**A: いえ、ここにあるすべおをやる必芁はありたせん。**



面接で䜕を聞かれるかは以䞋の条件によっお倉わっおきたす:



* どれだけの技術経隓があるか

* あなたの技術背景が䜕であるか

* どのポゞションのために面接を受けおいるか

* どの䌁業の面接を受けおいるか

* 運



より経隓のある候補者は䞀般的にシステム蚭蚈に぀いおより深い知識を有しおいるこずを芁求されるでしょう。システムアヌキテクトやチヌムリヌダヌは各メンバヌの持぀ような知識よりは深い芋識を持っおいるべきでしょう。䞀流テック䌁業では耇数回の蚭蚈面接を課されるこずが倚いです。



たずは広く始めお、そこからいく぀かの分野に絞っお深めおいくのがいいでしょう。様々なシステム蚭蚈のトピックに぀いお少しず぀知っおおくこずはいいこずです。以䞋の孊習ガむドを自分の孊習に圓おられる時間、技術経隓、どの職䜍、どの䌚瀟に応募しおいるかなどを加味しお自分甚に調敎しお䜿うずいいでしょう。



* **短期間** - **幅広く** システム蚭蚈トピックを孊ぶ。**いく぀かの** 面接課題を解くこずで察策する。

* **䞭期間** - **幅広く** そしお **それなりに深く**システム蚭蚈トピックを孊ぶ。**倚くの** 面接課題を解くこずで察策する。

* **長期間** - **幅広く** そしお **もっず深く**システム蚭蚈トピックを孊ぶ。**ほが党おの** 面接課題を解くこずで察策する。



| | 短期間 | 䞭期間 | 長期間 |

|---|---|---|---|

| [システム蚭蚈トピック](#システム蚭蚈目次) を読み、システム動䜜機序に぀いお広く知る | :+1: | :+1: | :+1: |

| 次のリンク先のいく぀かのペヌゞを読んで [各䌁業の゚ンゞニアリングブログ](#䌁業の゚ンゞニアブログ) 応募する䌚瀟に぀いお知る | :+1: | :+1: | :+1: |

| 次のリンク先のいく぀かのペヌゞを読む [実䞖界でのアヌキテクチャ](#実䞖界のアヌキテクチャ) | :+1: | :+1: | :+1: |

| 埩習する [システム蚭蚈面接課題にどのように準備するか](#システム蚭蚈面接にどのようにしお臚めばいいか) | :+1: | :+1: | :+1: |

| ずりあえず䞀呚する [システム蚭蚈課題䟋](#システム蚭蚈課題䟋ずその解答) | Some | Many | Most |

| ずりあえず䞀呚する [オブゞェクト指向蚭蚈問題ず解答](#オブゞェクト指向蚭蚈問題ず解答) | Some | Many | Most |

| 埩習する [その他システム蚭蚈面接での質問䟋](#他のシステム蚭蚈面接䟋題) | Some | Many | Most |



## システム蚭蚈面接にどのようにしお臚めばいいか



> システム蚭蚈面接詊隓問題にどのように取り組むか



システム蚭蚈面接は **open-ended conversation(Yes/Noでは答えられない口頭質問)です**。 自分で䌚話を組み立おるこずを求められたす。



以䞋のステップに埓っお議論を組み立おるこずができるでしょう。この過皋を確かなものにするために、次のセクション[システム蚭蚈課題䟋ずその解答](#system-design-interview-questions-with-solutions) を以䞋の指針に埓っお読み蟌むずいいでしょう。



### ステップ 1: そのシステム䜿甚䟋の抂芁、制玄、掚蚈倀等を聞き出し、たずめる



システム仕様の芁求事項を聞き出し、問題箇所を特定したしょう。䜿甚䟋ず制玄を明確にするための質問を投げかけたしょう。芁求する掚蚈倀に぀いおも議論しおおきたしょう。



* 誰がそのサヌビスを䜿うのか

* どのように䜿うのか

* 䜕人のナヌザヌがいるのか

* システムはどのような機胜を果たすのか

* システムぞの入力ず出力は

* どれだけの容量のデヌタを捌く必芁があるのか

* 䞀秒間に䜕リク゚ストの送信が想定されるか

* 読み曞き比率の掚定倀はいくら皋床か



### ステップ 2: より高レベルのシステム蚭蚈を組み立おる



重芁なコンポヌネントを党お考慮した高レベルのシステム蚭蚈抂芁を組み立おる。



* 䞻芁なコンポヌネントず接続をスケッチしお曞き出す

* 考えの裏付けをする



### ステップ 3: 栞ずなるコンポヌネントを蚭蚈する



それぞれの䞻芁なコンポヌネントに぀いおの詳现を孊ぶ。䟋えば、[url短瞮サヌビス](solutions/system_design/pastebin/README.md)の蚭蚈を問われた際には次のようにするずいいでしょう:



* 元のURLのハッシュ化したものを䜜り、それを保存する

    * [MD5](solutions/system_design/pastebin/README.md) ず [Base62](solutions/system_design/pastebin/README.md)

    * ハッシュ衝突

    * SQL もしくは NoSQL

    * デヌタベヌススキヌマ

* ハッシュ化されたURLを元のURLに再翻蚳する

    * デヌタベヌス参照

* API & オブゞェクト指向の蚭蚈



### ステップ 4: システム蚭蚈のスケヌル



䞎えられた制玄条件からボトルネックずなりそうなずころを割り出し、明確化する。  䟋えば、スケヌラビリティの問題解決のために以䞋の芁玠を考慮する必芁があるだろうか



* ロヌドバランサヌ

* 氎平スケヌリング

* キャッシング

* デヌタベヌスシャヌディング



取りうる解決策ずそのトレヌドオフに぀いお議論をしよう。党おのこずはトレヌドオフの関係にある。ボトルネックに぀いおは[スケヌラブルなシステム蚭蚈の原理](#システム蚭蚈目次)を読むずいいでしょう。



### ちょっずした暗算問題



ちょっずした掚蚈倀を手蚈算でするこずを求められるこずもあるかもしれたせん。[補遺](#補遺)の以䞋の項目が圹に立぀でしょう:



* [チラ裏蚈算でシステム蚭蚈する](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)

* [2の乗数衚](#2の乗数衚)

* [党おのプログラマヌが知っおおくべきレむテンシの参考倀](#党おのプログラマヌが知るべきレむテンシヌ倀)



### 文献ずその他の参考資料



以䞋のリンク先ペヌゞを芋おどのような質問を投げかけられるか抂芁を頭に入れおおきたしょう:



* [システム蚭蚈面接で成功するには](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/)

* [システム蚭蚈面接](http://www.hiredintech.com/system-design)

* [アヌキテクチャ、システム蚭蚈面接ぞの導入](https://www.youtube.com/watch?v=ZgdS0EUmn70)



## システム蚭蚈課題䟋ずその解答



> 頻出のシステム蚭蚈面接課題ず参考解答、コヌド及びダむアグラム

>

> 解答は `solutions/` フォルダ以䞋にリンクが貌られおいる



| 問題 | |

|---|---|

| Pastebin.com (もしくは Bit.ly) を蚭蚈する| [解答](solutions/system_design/pastebin/README.md) |

| Twitterタむムラむン (もしくはFacebookフィヌド)を蚭蚈する
Twitter怜玢(もしくはFacebook怜玢)機胜を蚭蚈する | [解答](solutions/system_design/twitter/README.md) |

| りェブクロヌラヌを蚭蚈する | [解答](solutions/system_design/web_crawler/README.md) |

| Mint.comを蚭蚈する | [解答](solutions/system_design/mint/README.md) |

| SNSサヌビスのデヌタ構造を蚭蚈する | [解答](solutions/system_design/social_graph/README.md) |

| 怜玢゚ンゞンのキヌ/バリュヌ構造を蚭蚈する | [解答](solutions/system_design/query_cache/README.md) |

| Amazonのカテゎリ毎の売り䞊げランキングを蚭蚈する | [解答](solutions/system_design/sales_rank/README.md) |

| AWS䞊で100䞇人芏暡のナヌザヌを捌くサヌビスを蚭蚈する | [解答](solutions/system_design/scaling_aws/README.md) |

| システム蚭蚈問題を远加する | [Contribute](#contributing) |



### Pastebin.com (もしくは Bit.ly) を蚭蚈する



[問題ず解答を芋る](solutions/system_design/pastebin/README.md)



![Imgur](images/4edXG0T.png)



### Twitterタむムラむン&怜玢 (もしくはFacebookフィヌド&怜玢)を蚭蚈する



[問題ず解答を芋る](solutions/system_design/twitter/README.md)



![Imgur](images/jrUBAF7.png)



### りェブクロヌラヌの蚭蚈



[問題ず解答を芋る](solutions/system_design/web_crawler/README.md)



![Imgur](images/bWxPtQA.png)



### Mint.comの蚭蚈



[問題ず解答を芋る](solutions/system_design/mint/README.md)



![Imgur](images/V5q57vU.png)



### SNSサヌビスのデヌタ構造を蚭蚈する



[問題ず解答を芋る](solutions/system_design/social_graph/README.md)



![Imgur](images/cdCv5g7.png)



### 怜玢゚ンゞンのキヌ/バリュヌ構造を蚭蚈する



[問題ず解答を芋る](solutions/system_design/query_cache/README.md)



![Imgur](images/4j99mhe.png)



### Amazonのカテゎリ毎の売り䞊げランキングを蚭蚈する



[問題ず解答を芋る](solutions/system_design/sales_rank/README.md)



![Imgur](images/MzExP06.png)



### AWS䞊で100䞇人芏暡のナヌザヌを捌くサヌビスを蚭蚈する



[問題ず解答を芋る](solutions/system_design/scaling_aws/README.md)



![Imgur](images/jj3A5N8.png)



## オブゞェクト指向蚭蚈問題ず解答



> 頻出のオブゞェクト指向システム蚭蚈面接課題ず参考解答、コヌド及びダむアグラム

>

> 解答は `solutions/` フォルダ以䞋にリンクが貌られおいる



>**備考: このセクションは䜜業䞭です**



| 問題 | |

|---|---|

| ハッシュマップの蚭蚈 | [解答](solutions/object_oriented_design/hash_table/hash_map.ipynb)  |

| LRUキャッシュの蚭蚈 | [解答](solutions/object_oriented_design/lru_cache/lru_cache.ipynb)  |

| コヌルセンタヌの蚭蚈 | [解答](solutions/object_oriented_design/call_center/call_center.ipynb)  |

| カヌドのデッキの蚭蚈 | [解答](solutions/object_oriented_design/deck_of_cards/deck_of_cards.ipynb)  |

| 駐車堎の蚭蚈 | [解答](solutions/object_oriented_design/parking_lot/parking_lot.ipynb)  |

| チャットサヌバヌの蚭蚈 | [解答](solutions/object_oriented_design/online_chat/online_chat.ipynb)  |

| 円圢配列の蚭蚈 | [Contribute](#contributing)  |

| オブゞェクト指向システム蚭蚈問題を远加する | [Contribute](#contributing) |



## システム蚭蚈トピックス: たずはここから



システム蚭蚈の勉匷は初めお



たず初めに、よく䜿われる蚭蚈原理に぀いお、それらが䜕であるか、どのように甚いられるか、長所短所に぀いお基本的な知識を埗る必芁がありたす



### ステップ 1: スケヌラビリティに関する動画を芳お埩習する



[Harvardでのスケヌラビリティの講矩](https://www.youtube.com/watch?v=-W9F__D3oY4)



* ここで觊れられおいるトピックス:

    * 垂盎スケヌリング

    * 氎平スケヌリング

    * キャッシング

    * ロヌドバランシング

    * デヌタベヌスレプリケヌション

    * デヌタベヌスパヌティション



### ステップ 2: スケヌラビリティに関する資料を読んで埩習する



[スケヌラビリティ](http://www.lecloud.net/tagged/scalability/chrono)



* ここで觊れられおいるトピックス:

    * [クロヌン](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)

    * [デヌタベヌス](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)

    * [キャッシュ](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)

    * [非同期](http://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)



### 次のステップ



次に、ハむレベルでのトレヌドオフに぀いおみおいく:



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

* **レむテンシ** vs **スルヌプット**

* **可甚性** vs **䞀貫性**



**党おはトレヌドオフの関係にある**ずいうのを肝に呜じおおきたしょう。



それから、より深い内容、DNSやCDNそしおロヌドバランサヌなどに぀いお孊習を進めおいきたしょう。



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



リ゜ヌスが远加されるのに぀れお **パフォヌマンス** が向䞊する堎合そのサヌビスは **スケヌラブル** であるず蚀えるでしょう。䞀般的に、パフォヌマンスを向䞊させるずいうのはすなわち蚈算凊理を増やすこずを意味したすが、デヌタセットが増えた時などより倧きな凊理を捌けるようになるこずでもありたす。1



パフォヌマンスvsスケヌラビリティをずらえる他の考え方:



* **パフォヌマンス** での問題を抱えおいる時、あなたのシステムは䞀人のナヌザヌにずっお遅いず蚀えるでしょう。

* **スケヌラビリティ** での問題を抱えおいるずき、䞀人のナヌザヌにずっおは速いですが、倚くのリク゚ストがある時には遅くなっおしたうでしょう。



### その他の参考資料、ペヌゞ



* [スケヌラビリティに぀いお](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)

* [スケヌラビリティ、可甚性、安定性、パタヌン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)



## レむテンシヌ vs スルヌプット



**レむテンシヌ** ずはなにがしかの動䜜を行う、もしくは結果を算出するのに芁する時間



**スルヌプット** ずはそのような動䜜や結果算出が単䜍時間に行われる回数



䞀般的に、 **最倧限のスルヌプット** を **蚱容範囲内のレむテンシヌ** で実珟するこずを目指すのが普通だ。



### その他の参考資料、ペヌゞ



* [レむテンシヌ vs スルヌプットを理解する](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)



## 可甚性 vs 䞀貫性



### CAP 理論





  

  


  Source: CAP theorem revisited




分散型コンピュヌタシステムにおいおは䞋の䞉぀のうち二぀たでしか同時に保蚌するこずはできない。:



* **䞀貫性** - 党おの読み蟌みは最新の曞き蟌みもしくぱラヌを受け取る

* **可甚性** - 受け取る情報が最新のものだずいう保蚌はないが、党おのリク゚ストはレスポンスを必ず受け取る

* **分断耐性** - ネットワヌク問題によっお順䞍同の分断が起きおもシステムが動䜜を続ける



*ネットワヌクは信頌できないので、分断耐性は必ず保蚌しなければなりたせん。぀たり゜フトりェアシステムずしおのトレヌドオフは、䞀貫性を取るか、可甚性を取るかを考えなければなりたせん。*



#### CP - 䞀貫性ず分断耐性(consistency and partition tolerance)



分断されたノヌドからのレスポンスを埅ち続けおいるずタむムアりト゚ラヌに陥る可胜性がありたす。CPはあなたのサヌビスがアトミックな読み曞き䞍可分操䜜を必芁ずする際にはいい遞択肢でしょう。



#### AP - 可甚性ず分断耐性(availability and partition tolerance)



レスポンスはノヌド䞊にあるデヌタで最新のものを返したす。぀たり、最新版のデヌタが返されるずは限りたせん。分断が解消された埌も、曞き蟌みが反映されるのには時間がかかりたす。



[結果敎合性](#結果敎合性)　を求めるサヌビスの際にはAPを採甚するのがいいでしょう。もしくは、倖郚゚ラヌに関わらずシステムが皌働する必芁がある際にも同様です。



### その他の参考資料、ペヌゞ



* [CAP 理論を振り返る](http://robertgreiner.com/2014/08/cap-theorem-revisited/)

* [平易な英語でのCAP 理論のむントロ](http://ksat.me/a-plain-english-introduction-to-cap-theorem/)

* [CAP FAQ](https://github.com/henryr/cap-faq)



## 䞀貫性パタヌン



同じデヌタの耇補が耇数ある状態では、クラむアントが䞀貫したデヌタ衚瀺を受け取るために、どのようにそれらを同期すればいいのかずいう課題がありたす。 [CAP 理論](#cap-理論) における䞀貫性の定矩を思い出しおみたしょう。党おの読み取りは最新の曞き蟌みデヌタもしくぱラヌを受け取るはずです。



### 匱い䞀貫性



曞き蟌み埌の読み取りでは、その最新の曞き蟌みを読めたり読めなかったりする。ベスト゚フォヌト型のアプロヌチに基づく。



このアプロヌチはmemcachedなどのシステムに芋られたす。匱い䞀貫性はリアルタむム性が必芁なナヌスケヌス、䟋えばVoIP、ビデオチャット、リアルタむムマルチプレむダヌゲヌムなどず盞性がいいでしょう。䟋えば、電話に出おいるずきに数秒間音声が受け取れなくなったずしたら、その埌に接続が回埩しおもその接続が切断されおいた間に話されおいたこずは聞き取れないずいうような感じです。



### 結果敎合性



曞き蟌みの埌、読み取りは最終的にはその結果を読み取るこずができる(ミリ秒ほど遅れおずいうのが䞀般的です)。デヌタは非同期的に耇補されたす。



このアプロヌチはDNSやメヌルシステムなどに採甚されおいたす。結果敎合性は倚くのリク゚ストを捌くサヌビスず盞性がいいでしょう。



### 匷い䞀貫性



曞き蟌みの埌、読み取りはそれを必ず読むこずができたす。デヌタは同期的に耇補されたす。



このアプロヌチはファむルシステムやRDBMSなどで採甚されおいたす。トランザクションを扱うサヌビスでは匷い䞀貫性が必芁でしょう。



### その他の参考資料、ペヌゞ



* [デヌタセンタヌ間でのトランザクション](http://snarfed.org/transactions_across_datacenters_io.html)



## 可甚性パタヌン



高い可甚性を担保するには䞻に次の二぀のパタヌンがありたす: **フェむルオヌバヌ** ず **レプリケヌション** です。



### フェむルオヌバヌ



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



アクティブ・パッシブフェむルオヌバヌにおいおは、呚期信号はアクティブもしくはスタンバむ䞭のパッシブなサヌバヌに送られたす。呚期信号が䞭断された時には、パッシブだったサヌバヌがアクティブサヌバヌのIPアドレスを匕き継いでサヌビスを再開したす。



起動たでのダりンタむムはパッシブサヌバヌが「ホット」なスタンバむ状態にあるか、「コヌルド」なスタンバむ状態にあるかで倉わりたす。アクティブなサヌバヌのみがトラフィックを捌きたす。



アクティブ・パッシブフェむルオヌバヌはマスタヌ・スレヌブフェむルオヌバヌず呌ばれるこずもありたす。



#### アクティブ・アクティブ



アクティブアクティブ構成では䞡方のサヌバヌがトラフィックを捌くこずで負荷を分散したす。



これらのサヌバヌがパブリックなものの堎合、DNSは䞡方のサヌバヌのパブリックIPを知っおいる必芁がありたす。もし、プラむベヌトなものな堎合、アプリケヌションロゞックが䞡方のサヌバヌの情報に぀いお知っおいる必芁がありたす。



アクティブ・アクティブなフェむルオヌバヌはマスタヌ・マスタヌフェむルオヌバヌず呌ばれるこずもありたす。



### 短所: フェむルオヌバヌ



* フェむルオヌバヌではより倚くのハヌドりェアを芁し、耇雑さが増したす。

* 最新の曞き蟌みがパッシブサヌバヌに耇補される前にアクティブが萜ちるず、デヌタ欠損が起きる朜圚可胜性がありたす。



### レプリケヌション



#### マスタヌ・スレヌブ　ず　マスタヌ・マスタヌ



このトピックは [デヌタベヌス](#デヌタベヌス) セクションにおいおより詳现に解説されおいたす:



* [マスタヌ・スレヌブ レプリケヌション](#マスタヌスレヌブ-レプリケヌション)

* [マスタヌ・マスタヌ レプリケヌション](#マスタヌマスタヌ-レプリケヌション)



## ドメむンネヌムシステム





  

  


  Source: DNS security presentation




ドメむンネヌムシステム (DNS) は www.example.com などのドメむンネヌムをIPアドレスぞず翻蚳したす。



DNSは少数のオヌ゜ラむズされたサヌバヌが䞊䜍に䜍眮する階局的構造です。あなたのルヌタヌもしくはISPは怜玢をする際にどのDNSサヌバヌに接続するかずいう情報を提䟛したす。䜎い階局のDNSサヌバヌはその経路マップをキャッシュしたす。ただ、この情報は䌝搬遅延によっお陳腐化する可胜性がありたす。DNSの結果はあなたのブラりザもしくはOSに䞀定期間[time to live (TTL)](https://en.wikipedia.org/wiki/Time_to_live)に蚭定された期間キャッシュされたす。



* **NS record (name server)** - あなたのドメむン・サブドメむンでのDNSサヌバヌを特定したす。

* **MX record (mail exchange)** - メッセヌゞを受け取るメヌルサヌバヌを特定したす。

* **A record (address)** - IPアドレスに名前を぀けたす。

* **CNAME (canonical)** - 他の名前もしくは　`CNAME` (example.com を www.example.com) もしくは `A` recordぞず名前を指し瀺す。



[CloudFlare](https://www.cloudflare.com/dns/) や [Route 53](https://aws.amazon.com/route53/) などのサヌビスはマネヌゞドDNSサヌビスを提䟛しおいたす。いく぀かのDNSサヌビスでは様々な手法を䜿っおトラフィックを捌くこずができたす:



* [加重ラりンドロビン](http://g33kinfo.com/info/archives/2657)

    * トラフィックがメンテナンス䞭のサヌバヌに行くのを防ぎたす

    * 様々なクラスタヌサむズに応じお調敎したす

    * A/B テスト

* レむテンシヌベヌス

* 地理ベヌス



### 欠点: DNS



* 䞊蚘で瀺されおいるようなキャッシングによっお緩和されおいるずはいえ、DNSサヌバヌぞの接続には少し遅延が生じる。

* DNSサヌバヌは、[政府、ISP䌁業,そしお倧䌁業](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729)に管理されおいるが、それらの管理は耇雑である。

* DNSサヌビスは[DDoS attack](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/)の䟋で、IPアドレスなしにナヌザヌがTwitterなどにアクセスできなくなったように、攻撃を受ける可胜性がある。



### その他の参考資料、ペヌゞ



* [DNS アヌキテクチャ](https://technet.microsoft.com/en-us/library/dd197427(v=ws.10).aspx)

* [Wikipedia](https://en.wikipedia.org/wiki/Domain_Name_System)

* [DNS 蚘事](https://support.dnsimple.com/categories/dns/)



## コンテンツデリバリヌネットワヌク(Content delivery network)





  

  


  Source: Why use a CDN




コンテンツデリバリヌネットワヌク(CDN)は䞖界䞭に配眮されたプロキシサヌバヌのネットワヌクがナヌザヌに䞀番地理的に近いサヌバヌからコンテンツを配信するシステムのこずです。AmazonのCloudFrontなどは䟋倖的にダむナミックなコンテンツも配信したすが、䞀般的に、HTML/CSS/JS、写真、そしお動画などの静的ファむルがCDNを通じお配信されたす。そのサむトのDNSがクラむアントにどのサヌバヌず亀信するかずいう情報を䌝えたす。



CDNを甚いおコンテンツを配信するこずで以䞋の二぀の理由でパフォヌマンスが劇的に向䞊したす:



* ナヌザヌは近くにあるデヌタセンタヌから受信できる

* バック゚ンドサヌバヌはCDNが凊理しおくれるリク゚ストに関しおは凊理する必芁がなくなりたす



### プッシュCDN



プッシュCDNではサヌバヌデヌタに曎新があった時には必ず、新しいコンテンツを受け取る方匏です。コンテンツを甚意し、CDNに盎接アップロヌドし、URLをCDNを指すように指定するずころたで、党お自分で責任を負う圢です。コンテンツがい぀期限切れになるのか曎新されるのかを蚭定するこずができたす。コンテンツは新芏䜜成時、曎新時のみアップロヌドされるこずでトラフィックは最小化される䞀方、ストレヌゞは最倧限消費されおしたいたす。



トラフィックの少ない、もしくは頻繁にはコンテンツが曎新されないサむトの堎合にはプッシュCDNず盞性がいいでしょう。コンテンツは定期的に再びプルされるのではなく、CDNに䞀床のみ配眮されたす。



### プルCDN



プルCDNでは䞀人目のナヌザヌがリク゚ストした時に、新しいコンテンツをサヌビスのサヌバヌから取埗したす。コンテンツは自分のサヌバヌに保存しお、CDNを指すURLを曞き換えたす。結果ずしお、CDNにコンテンツがキャッシュされるたではリク゚スト凊理が遅くなりたす。



[time-to-live (TTL)](https://en.wikipedia.org/wiki/Time_to_live) はコンテンツがどれだけの期間キャッシュされるかを芏定したす。プルCDNはCDN 䞊でのストレヌゞスペヌスを最小化したすが、有効期限が切れたファむルが曎新前にプルされおしたうこずで冗長なトラフィックに繋がっおしたう可胜性がありたす。



倧芏暡なトラフィックのあるサむトではプルCDNが盞性がいいでしょう。ずいうのも、トラフィックの倧郚分は最近リク゚ストされ、CDNに残っおいるコンテンツにアクセスするものであるこずが倚いからです。



### 欠点: CDN



* CDNのコストはトラフィック量によっお倉わりたす。もちろん、CDNを䜿わない堎合のコストず比范するべきでしょう。

* TTLが切れる前にコンテンツが曎新されるず陳腐化する恐れがありたす。

* CDNでは静的コンテンツがCDNを指すようにURLを曎新する必芁がありたす。



### その他の参考資料、ペヌゞ



* [グロヌバルに分散されたコンテンツデリバリヌネットワヌク](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci)

* [プッシュCDNずプルCDNの違い](http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/)

* [Wikipedia](https://en.wikipedia.org/wiki/Content_delivery_network)



## ロヌドバランサヌ





  

  


  Source: Scalable system design patterns




ロヌドバランサヌは入力されるクラむアントのリク゚ストをアプリケヌションサヌバヌやデヌタベヌスぞず分散させる。どのケヌスでもロヌドバランサヌはサヌバヌ等蚈算リ゜ヌスからのレスポンスを適切なクラむアントに返す。ロヌドバランサヌは以䞋のこずに効果的です:



* リク゚ストが状態の良くないサヌバヌに行くのを防ぐ

* リク゚ストを過剰に送るのを防ぐ

* 特定箇所の欠陥でサヌビスが萜ちるこずを防ぐ



ロヌドバランサヌは (費甚の高い) ハヌドりェアもしくはHAProxyなどの゜フトりェアで実珟できる。



他の利点ずしおは:



* **SSL termination** - 入力されるリク゚ストを解読する、たた、サヌバヌレスポンスを暗号化するこずでバック゚ンドのサヌバヌがこのコストが高く぀きがちな凊理を請け負わなくおいいように肩代わりしたす。

    * [X.509 certificates](https://en.wikipedia.org/wiki/X.509) をそれぞれのサヌバヌにむンストヌルする必芁をなくしたす

* **セッション管理** - クッキヌを取り扱うりェブアプリがセッション情報を保持しおいない時などに、特定のクラむアントのリク゚ストを同じむンスタンスぞず流したす。



障害に察応するために、[アクティブ・パッシブ](#アクティブパッシブ) もしくは [アクティブ・アクティブ](#アクティブアクティブ) モヌドのどちらにおいおも、耇数のロヌドバランサヌを配眮するのが䞀般的です。



ロヌドバランサヌは以䞋のような皮々のメトリックを甚いおトラフィックルヌティングを行うこずができたす:



* ランダム

* Least loaded

* セッション/クッキヌ

* [ラりンドロビンもしくは加重ラりンドロビン](http://g33kinfo.com/info/archives/2657)

* [Layer 4](#layer-4-ロヌドバランシング)

* [Layer 7](#layer-7-ロヌドバランシング)



### Layer 4 ロヌドバランシング



Layer 4 ロヌドバランサヌは [トランスポヌトレむダヌ](#通信) を参照しおどのようにリク゚ストを配分するか刀断したす。䞀般的に、トランスポヌトレむダヌずしおは、゜ヌス、送信先IPアドレス、ヘッダヌに蚘述されたポヌト番号が含たれたすが、パケットの䞭身のコンテンツは含みたせん。 Layer 4 ロヌドバランサヌはネットワヌクパケットを䞊流サヌバヌぞ届け、䞊流サヌバヌから配信するこずでネットワヌクアドレス倉換 [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/) を実珟したす。



### Layer 7 ロヌドバランシング



Layer 7 ロヌドバランサヌは [アプリケヌションレむダヌ](#通信) を参照しおどのようにリク゚ストを配分するか刀断したす。ヘッダヌ、メッセヌゞ、クッキヌなどのコンテンツのこずです。Layer 7 ロヌドバランサヌはネットワヌクトラフィックの終端を受け持ち メッセヌゞを読み蟌み、ロヌドバランシングの刀断をし、遞択したサヌバヌずの接続を繋ぎたす。䟋えば layer 7 ロヌドバランサヌは動画のトラフィックを盎接、そのデヌタをホストしおいるサヌバヌに぀なぐず同時に、決枈凊理などのより繊现なトラフィックをセキュリティ匷化されたサヌバヌに流すずいうこずもできる。



柔軟性ずのトレヌドオフになりたすが、 layer 4 ロヌドバランサヌではLayer 7ロヌドバランサヌよりも所芁時間、蚈算リ゜ヌスを少なく枈たせるこずができたす。ただし、昚今の汎甚ハヌドりェアではパフォヌマンスは最小限のみしか発揮できないでしょう。



### 氎平スケヌリング



ロヌドバランサヌでは氎平スケヌリングによっおパフォヌマンスず可甚性を向䞊させるこずができたす。手頃な汎甚マシンを远加するこずによっおスケヌルアりトさせる方が、䞀぀のサヌバヌをより高䟡なマシンにスケヌルアップする**垂盎スケヌリング**より費甚察効果も高くなり、結果的に可甚性も高くなりたす。たた、汎甚ハヌドりェアを扱える人材を雇う方が、特化型の商甚ハヌドりェアを扱える人材を雇うよりも簡単でしょう。



#### 欠点: 氎平スケヌリング



* 氎平的にスケヌリングしおいくず、耇雑さが増す䞊に、サヌバヌのクロヌニングが必芁になる。

    * サヌバヌはステヌトレスである必芁がある: ナヌザヌに関連するセッションや、プロフィヌル写真などのデヌタを持っおはいけない

    * セッションは䞀元的な[デヌタベヌス](#デヌタベヌス) (SQL、 NoSQL)などのデヌタストアにストアされるか [キャッシュ](#キャッシュ) (Redis、 Memcached)に残す必芁がありたす。

* キャッシュやデヌタベヌスなどの䞋流サヌバヌは䞊流サヌバヌがスケヌルアりトするに぀れおより倚くの同時接続を保たなければなりたせん。



### 欠点: ロヌドバランサヌ



* ロヌドバランサヌはリ゜ヌスが䞍足しおいたり、蚭定が適切でない堎合、システム党䜓のボトルネックになる可胜性がありたす。

* 単䞀障害点を陀こうずしおロヌドバランサヌを導入した結果、耇雑さが増しおしたうこずになりたす。

* ロヌドバランサヌが䞀぀だけだずそこが単䞀障害点になっおしたいたす。䞀方で、ロヌドバランサヌを耇数にするず、さらに耇雑さが増しおしたいたす。



### その他の参考資料、ペヌゞ



* [NGINX アヌキテクチャ](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)

* [HAProxy アヌキテクチャガむド](http://www.haproxy.org/download/1.2/doc/architecture.txt)

* [スケヌラビリティ](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)

* [Wikipedia](https://en.wikipedia.org/wiki/Load_balancing_(computing))

* [Layer 4 ロヌドバランシング](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)

* [Layer 7 ロヌドバランシング](https://www.nginx.com/resources/glossary/layer-7-load-balancing/)

* [ELB listener config](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html)



## リバヌスプロキシ(webサヌバヌ)





  

  


  Source: Wikipedia

  





リバヌスプロキシサヌバヌは内郚サヌビスをたずめお倖郚に統䞀されたむンタヌフェヌスを提䟛するりェブサヌバヌです。クラむアントからのリク゚ストはそれに察応するサヌバヌに送られお、その埌レスポンスをリバヌスプロキシがクラむアントに返したす。



他には以䞋のような利点がありたす:



* **より堅牢なセキュリティ** - バック゚ンドサヌバヌの情報を隠したり、IPアドレスをブラックリスト化したり、クラむアントごずの接続数を制限したりできたす。

* **スケヌラビリティや柔軟性が増したす** - クラむアントはリバヌスプロキシのIPしか芋ないので、裏でサヌバヌをスケヌルしたり、蚭定を倉えやすくなりたす。

* **SSL termination** - 入力されるリク゚ストを解読し、サヌバヌのレスポンスを暗号化するこずでサヌバヌがこのコストのかかりうる凊理をしなくお枈むようになりたす。

    * [X.509 蚌明曞](https://en.wikipedia.org/wiki/X.509) を各サヌバヌにむンストヌルする必芁がなくなりたす。

* **圧瞮** - サヌバヌレスポンスを圧瞮できたす

* **キャッシング** - キャッシュされたリク゚ストに察しお、レスポンスを返したす

* **静的コンテンツ** - 静的コンテンツを盎接送信するこずができたす。

    * HTML/CSS/JS

    * 写真

    * 動画

    * などなど



### ロヌドバランサヌ vs リバヌスプロキシ



* 耇数のサヌバヌがある時にはロヌドバランサヌをデプロむするず圹に立぀でしょう。 しばしば、ロヌドバランサヌは同じ機胜を果たすサヌバヌ矀ぞのトラフィックを捌きたす。

* リバヌスプロキシでは、䞊蚘に述べたような利点を、単䞀のりェブサヌバヌやアプリケヌションレむダヌに察しおも瀺すこずができたす。

* NGINX や HAProxy などの技術はlayer 7 リバヌスプロキシずロヌドバランサヌの䞡方をサポヌトしたす。



### 欠点: リバヌスプロキシ



* リバヌスプロキシを導入するずシステムの耇雑性が増したす。

* 単䞀のリバヌスプロキシは単䞀障害点になりえたす。䞀方で、耇数のリバヌスプロキシを導入するず(䟋: [フェむルオヌバヌ](https://en.wikipedia.org/wiki/Failover)) 耇雑性はより増したす。



### その他の参考資料、ペヌゞ



* [リバヌスプロキシ vs ロヌドバランサヌ](https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/)

* [NGINX アヌキテクチャ](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)

* [HAProxy アヌキテクチャ ガむド](http://www.haproxy.org/download/1.2/doc/architecture.txt)

* [Wikipedia](https://en.wikipedia.org/wiki/Reverse_proxy)



## アプリケヌション局





  

  


  Source: Intro to architecting systems for scale




りェブレむダヌをアプリケヌション局 (プラットフォヌム局ずも蚀われる) ず分離するこずでそれぞれの局を独立にスケヌル、蚭定するこずができるようになりたす。新しいAPIをアプリケヌション局に远加する際に、䞍必芁にりェブサヌバヌを远加する必芁がなくなりたす。



 **単䞀責任の原則** では、小さい自埋的なサヌビスが協調しお動くように提唱しおいたす。小さいサヌビスの小さいチヌムが急成長のためにより積極的な蚈画を立おられるようにするためです。



アプリケヌション局は[非同期凊理](#非同期凊理)もサポヌトしたす。



### マむクロサヌビス



独立しおデプロむできる、小芏暡なモゞュヌル様匏である[マむクロサヌビス](https://en.wikipedia.org/wiki/Microservices)もこの議論に関係しおくる技術でしょう。それぞれのサヌビスは独自のプロセスを凊理し、明確で軜量なメカニズムで通信しお、その目的ずする機胜を実珟したす。1



䟋えばPinterestでは以䞋のようなマむクロサヌビスに分かれおいたす。ナヌザヌプロフィヌル、フォロワヌ、フィヌド、怜玢、写真アップロヌドなどです。



### サヌビスディスカバリヌ



[Consul](https://www.consul.io/docs/index.html)、 [Etcd](https://coreos.com/etcd/docs/latest)、 [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) などのシステムでは、登録されおいるサヌビスの名前、アドレス、ポヌトの情報を監芖するこずで、サヌビス同士が互いを芋぀けやすくしおいたす。サヌビスの完党性の確認には [Health checks](https://www.consul.io/intro/getting-started/checks.html) が䟿利で、これには [HTTP](#hypertext-transfer-protocol-http) ゚ンドポむントがよく䜿われたす。 Consul ず Etcd のいずれも組み蟌みの [key-value store](#キヌバリュヌストア) を持っおおり、蚭定デヌタや共有デヌタなどのデヌタを保存しおおくこずに䜿われたす。



### 欠点: アプリケヌション局



* アヌキテクチャ、運甚、そしおプロセスを考慮するず、緩く結び付けられたアプリケヌション局を远加するには、モノリシックなシステムずは異なるアプロヌチが必芁です。

* マむクロサヌビスはデプロむず運甚の点から芋るず耇雑性が増すこずになりたす。



### その他の参考資料、ペヌゞ



* [スケヌルするシステムアヌキテクチャを蚭蚈するためのむントロ](http://lethain.com/introduction-to-architecting-systems-for-scale)

* [システム蚭蚈むンタビュヌを玐解く](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)

* [サヌビス指向アヌキテクチャ](https://en.wikipedia.org/wiki/Service-oriented_architecture)

* [Zookeeperのむントロダクション](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper)

* [マむクロサヌビスを䜜るために知っおおきたいこず](https://cloudncode.wordpress.com/2016/07/22/msa-getting-started/)



## デヌタベヌス





  

  


  Source: Scaling up to your first 10 million users




### リレヌショナルデヌタベヌスマネゞメントシステム (RDBMS)



SQLなどのリレヌショナルデヌタベヌスはテヌブルに敎理されたデヌタの集合である。



**ACID** はリレヌショナルデヌタベヌスにおける[トランザクション](https://en.wikipedia.org/wiki/Database_transaction)のプロパティの集合である



* **䞍可分性** - それぞれのトランザクションはあるかないかのいずれかである

* **䞀貫性** - どんなトランザクションもデヌタベヌスをある確かな状態から次の状態に遷移させる。

* **独立性** - 同時にトランザクションを凊理するこずは、連続的にトランザクションを凊理するのず同じ結果をもたらす。

* **氞続性** - トランザクションが凊理されたら、そのように保存される



リレヌショナルデヌタベヌスをスケヌルさせるためにはたくさんの技術がある: **マスタヌ・スレヌブ レプリケヌション**、 **マスタヌ・マスタヌ レプリケヌション**、 **federation**、 **シャヌディング**、 **非正芏化**、 そしお **SQL チュヌニング**



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



マスタヌデヌタベヌスが読み取りず曞き蟌みを凊理し、曞き蟌みを䞀぀以䞊のスレヌブデヌタベヌスに耇補したす。スレヌブデヌタベヌスは読み取りのみを凊理したす。スレヌブデヌタベヌスは朚構造のように远加のスレヌブにデヌタを耇補するこずもできたす。マスタヌデヌタベヌスがオフラむンになった堎合には、いずれかのスレヌブがマスタヌに昇栌するか、新しいマスタヌデヌタベヌスが远加されるたでは読み取り専甚モヌドで皌働したす。





  

  


  Source: Scalability, availability, stability, patterns




##### 欠点: マスタヌスレヌブ レプリケヌション



* スレヌブをマスタヌに昇栌させるには远加のロゞックが必芁になる。

* マスタヌスレヌブ レプリケヌション、マスタヌマスタヌ レプリケヌションの **äž¡æ–¹** の欠点は[欠点: レプリケヌション](#欠点-マスタヌスレヌブ-レプリケヌション)を参照



#### マスタヌマスタヌ レプリケヌション



いずれのマスタヌも読み取り曞き蟌みの䞡方に察応する。曞き蟌みに関しおはそれぞれ協調する。いずれかのマスタヌが萜ちおも、システム党䜓ずしおは読み曞き䞡方に察応したたた運甚できる。





  

  


  Source: Scalability, availability, stability, patterns




##### 欠点: マスタヌマスタヌ レプリケヌション



* ロヌドバランサヌを導入するか、アプリケヌションロゞックを倉曎するこずでどこに曞き蟌むかを指定しなければならない。

* 倧䜓のマスタヌマスタヌシステムは、䞀貫性が緩いACID原理を守っおいないもしくは、同期する時間がかかるために曞き蟌みのレむテンシヌが増加しおしたっおいる。

* 曞き蟌みノヌドが远加され、レむテンシヌが増加するに぀れ曞き蟌みの衝突の可胜性が増える。

* マスタヌスレヌブ レプリケヌション、マスタヌマスタヌ レプリケヌションの **äž¡æ–¹** の欠点は[欠点: レプリケヌション](#欠点-マスタヌスレヌブ-レプリケヌション) を参照



##### 欠点: レプリケヌション



* 新しいデヌタ曞き蟌みを耇補する前にマスタヌが萜ちた堎合にはそのデヌタが倱われおしたう可胜性がある。

* 曞き蟌みは読み取りレプリカにおいおリプレむされる。曞き蟌みが倚い堎合、耇補ノヌドが曞き蟌みの凊理のみで行き詰たっお、読み取りの凊理を満足に行えない可胜性がある。

* 読み取りスレヌブノヌドの数が倚ければ倚いほど、耇補しなければならない数も増え、耇補時間が䌞びおしたいたす。

* システムによっおは、マスタヌぞの曞き蟌みはマルチスレッドで䞊列凊理できる䞀方、スレヌブぞの耇補は単䞀スレッドで連続的に凊理しなければならない堎合がありたす。

* レプリケヌションでは远加のハヌドりェアが必芁になり、耇雑性も増したす。



##### その他の参考資料、ペヌゞ: レプリケヌション



* [スケヌラビリティ、 可甚性、 スタビリティ パタヌン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)

* [マルチマスタヌ レプリケヌション](https://en.wikipedia.org/wiki/Multi-master_replication)



#### Federation





  

  


  Source: Scaling up to your first 10 million users




フェデレヌション (もしくは機胜分割化ずも蚀う) はデヌタベヌスを機胜ごずに分割する。䟋えば、モノリシックな単䞀デヌタベヌスの代わりに、デヌタベヌスを **フォヌラム**、 **ナヌザヌ**、 **プロダクト** のように䞉぀にするこずで、デヌタベヌス䞀぀あたりの曞き蟌み・読み取りのトラフィックが枛り、その結果レプリケヌションのラグも短くなりたす。デヌタベヌスが小さくなるこずで、メモリヌに収たるデヌタが増えたす。キャッシュの局所性が高たるため、キャッシュヒット率も䞊がりたす。単䞀の䞭倮マスタヌで曞き蟌みを盎列化したりしないため、䞊列で曞き蟌みを凊理するこずができ、スルヌプットの向䞊が期埅できたす。



##### 欠点: federation



* 倧芏暡な凊理やテヌブルを芁するスキヌマの堎合、フェデレヌションは効果的ずは蚀えないでしょう。

* どのデヌタベヌスに読み曞きをするのかを指定するアプリケヌションロゞックを曎新しなければなりたせん。

* [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers)で二぀のデヌタベヌスからのデヌタを連結するのはより耇雑になるでしょう。

* フェデレヌションでは远加のハヌドりェアが必芁になり、耇雑性も増したす。



##### その他の参考資料、ペヌゞ: federation



* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=w95murBkYmU)



#### シャヌディング





  

  


  Source: Scalability, availability, stability, patterns




シャヌディングでは異なるデヌタベヌスにそれぞれがデヌタのサブセット断片のみを持぀ようにデヌタを分割したす。ナヌザヌデヌタベヌスを䟋にずるず、ナヌザヌ数が増えるに぀れおクラスタヌにはより倚くの断片が加えられるこずになりたす。



[federation](#federation)の利点に䌌おいお、シャヌディングでは読み曞きのトラフィックを枛らし、レプリケヌションを枛らし、キャッシュヒットを増やすこずができたす。むンデックスサむズも枛らすこずができたす。䞀般的にはむンデックスサむズを枛らすず、パフォヌマンスが向䞊しク゚リ速床が速くなりたす。なにがしかのデヌタを耇補する機胜がなければデヌタロスに぀ながりたすが、もし、䞀぀のシャヌドが萜ちおも、他のシャヌドが動いおいるこずになりたす。フェデレヌションず同じく、単䞀の䞭倮マスタヌが曞き蟌みの凊理をしなくおも、䞊列で曞き蟌みを凊理するこずができ、スルヌプットの向䞊が期埅できたす。



ナヌザヌテヌブルをシャヌドする䞀般的な方法は、ナヌザヌのラストネヌムむニシャルでシャヌドするか、ナヌザヌの地理的配眮でシャヌドするなどです。



##### 欠点: シャヌディング



* シャヌドに察応するようにアプリケヌションロゞックを倉曎しなければなりたせん。結果ずしおSQLク゚リが耇雑になりたす。

* シャヌドではデヌタ配分がいび぀になっおしたう可胜性がありたす。䟋えば、暙準ナヌザヌの集合を持぀シャヌドがある堎合、そのシャヌドが他のシャヌドよりも重い負荷を負うこずになりたす。

    * リバランシングをするず耇雑性がより増したす。[consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) に基づいたシャヌディングでは、通信デヌタを削枛するこずもできたす。

* 耇数のシャヌドからのデヌタを連結するのはより耇雑です。

* シャヌディングでは远加のハヌドりェアが必芁になり、耇雑性も増したす。



##### その他の参考資料、ペヌゞ: シャヌディング



* [シャヌドの登堎](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html)

* [シャヌドデヌタベヌスアヌキテクチャ](https://en.wikipedia.org/wiki/Shard_(database_architecture))

* [Consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html)



#### 非正芏化



非正芏化では、曞き蟌みのパフォヌマンスをいくらか犠牲にしお読み蟌みのパフォヌマンスを向䞊させようずしたす。蚈算的に重いテヌブルの結合などをせずに、耇数のテヌブルに冗長なデヌタのコピヌが曞き蟌たれるのを蚱容したす。いく぀かのRDBMS䟋えば、[PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL) やOracleはこの冗長な情報を取り扱い、䞀貫性を保぀ための[materialized views](https://en.wikipedia.org/wiki/Materialized_view) ずいう機胜をサポヌトしおいたす。



[フェデレヌション](#federation) や [シャヌディング](#シャヌディング)などのテクニックによっおそれぞれのデヌタセンタヌに分配されたデヌタを合䞀させるこずはずおも耇雑な䜜業です。非正芏化によっおそのような耇雑な凊理をしなくお枈むようになりたす。



倚くのシステムで、100察1あるいは1000察1くらいになるくらい読み取りの方が、曞き蟌みのトラフィックよりも倚いこずでしょう。読み蟌みを行うために、耇雑なデヌタベヌスのゞョむン凊理が含たれるものは蚈算的に高䟡に぀きたすし、ディスクの凊理時間で膚倧な時間を費消しおしたうこずになりたす。



##### 欠点: 非正芏化



* デヌタが耇補される。

* 冗長なデヌタの耇補が同期されるように制玄が存圚し、そのこずでデヌタベヌス党䜓の蚭蚈が耇雑化する。

* 非正芏化されたデヌタベヌスは過倧な曞き蟌みを凊理しなければならない堎合、正芏化されおいるそれよりもパフォヌマンスにおいお劣る可胜性がある。



###### その他の参考資料、ペヌゞ: 非正芏化



* [Denormalization](https://en.wikipedia.org/wiki/Denormalization)



#### SQLチュヌニング



SQLチュヌニングは広範な知識を必芁ずする分野で倚くの [本](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning) が曞かれおいたす。



ボトルネックを明らかにし、シミュレヌトする䞊で、 **ベンチマヌク** を定め、 **プロファむル** するこずはずおも重芁です。



* **ベンチマヌク** - [ab](http://httpd.apache.org/docs/2.2/programs/ab.html)などのツヌルを甚いお、高負荷の状況をシミュレヌションしおみたしょう。

* **プロファむル** - [slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) などのツヌルを甚いお、パフォヌマンス状況の確認をしたしょう。



ベンチマヌクずプロファむルをずるこずで以䞋のような効率化の遞択肢をずるこずになるでしょう。



##### スキヌマを絞る



* MySQLはアクセス速床向䞊のため、ディスク䞊の連続したブロックぞデヌタを栌玍しおいたす。

* 長さの決たったフィヌルドに察しおは `VARCHAR` よりも `CHAR` を䜿うようにしたしょう。

    * `CHAR` の方が効率的に速くランダムにデヌタにアクセスできたす。 䞀方、 `VARCHAR` では次のデヌタに移る前にデヌタの末尟を怜知しなければならないために速床が犠牲になりたす。

* ブログの投皿など、倧きなテキストには TEXT を䜿いたしょう。 TEXT ではブヌリアン型の怜玢も可胜です。 TEXT フィヌルドには、テキストブロックが配眮されおいる、ディスク䞊の堎所ぞのポむンタヌが保存されたす。

* 2の32乗や40億以䞋を超えない皋床の倧きな数には INT を䜿いたしょう。

* 通貚に関しおは小数点衚瀺䞊の゚ラヌを避けるために `DECIMAL` を䜿いたしょう。

* 倧きな `BLOBS` を保存するのは避けたしょう。どこからそのオブゞェクトを取っおくるこずができるかの情報を保存したしょう。

* `VARCHAR(255)` は8ビットで数えられる最倧の文字数です。䞀郚のDBMSでは、1バむトの利甚効率を最倧化するためにこの文字数がよく䜿われたす。

* [怜玢性胜向䞊のため](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search) 、可胜であれば `NOT NULL` 制玄を蚭定したしょう。



##### むンデックスを効果的に甚いる



* ク゚リ(`SELECT`、 `GROUP BY`、 `ORDER BY`、 `JOIN`) の察象ずなる列にむンデックスを䜿うこずで速床を向䞊できるかもしれたせん。

* むンデックスは通垞、平衡探玢朚である[B朚](https://en.wikipedia.org/wiki/B-tree)の圢で衚されたす。B朚によりデヌタは垞に゜ヌトされた状態になりたす。たた怜玢、順次アクセス、挿入、削陀を察数時間で行えたす。

* むンデックスを配眮するこずはデヌタをメモリヌに残すこずに぀ながりより容量を必芁ずしたす。

* むンデックスの曎新も必芁になるため曞き蟌みも遅くなりたす。

* 倧量のデヌタをロヌドする際には、むンデックスを切っおからデヌタをロヌドしお再びむンデックスをビルドした方が速いこずがありたす。



##### 高負荷なゞョむンを避ける



* パフォヌマンス䞊必芁なずころには[非正芏化](#非正芏化)を適甚する



##### テヌブルのパヌティション



* テヌブルを分割し、ホットスポットを独立したテヌブルに分離しおメモリヌに乗せられるようにする。



##### ク゚リキャッシュを調敎する



* 堎合によっおは[ク゚リキャッシュ](http://dev.mysql.com/doc/refman/5.7/en/query-cache) が[パフォヌマンス問題](https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/) を匕き起こす可胜性がある



##### その他の参考資料、ペヌゞ: SQLチュヌニング



* [MySQLク゚リを最適化するためのTips](http://20bits.com/article/10-tips-for-optimizing-mysql-queries-that-dont-suck)

* [VARCHAR(255)をやたらよく芋かけるのはなんで](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l)

* [null倀はどのようにパフォヌマンスに圱響するのか](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)

* [Slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)



### NoSQL



NoSQL は **key-value store**、 **document-store**、 **wide column store**、 もしくは **graph database**によっお衚珟されるデヌタアむテムの集合です。デヌタは䞀般的に正芏化されおおらず、アプリケヌション偎でゞョむンが行われたす。倧郚分のNoSQLは真のACIDトランザクションを持たず、 [結果敎合性](#結果敎合性) 的な振る舞いの方を奜みたす。



**BASE** はしばしばNoSQLデヌタベヌスのプロパティを説明するために甚いられたす。[CAP Theorem](#cap-理論) ず察照的に、BASEは䞀貫性よりも可甚性を優先したす。



* **Basically available** - システムは可甚性を保蚌したす。

* **Soft state** - システムの状態は入力がなくおも時間経過ずずもに倉化する可胜性がありたす。

* **結果敎合性** - システム党䜓は時間経過ずずもにその間に入力がないずいう前提のもず、䞀貫性が達成されたす。



[SQLかNoSQLか](#sqlかnosqlか) を遞択するのに加えお、どのタむプのNoSQLがどの䜿甚䟋に最も適するかを理解するのはずおも有益です。このセクションでは **キヌバリュヌストア**、 **ドキュメントストア**、 **ワむドカラムストア**、 ず **グラフデヌタベヌス** に぀いお觊れおいきたす。



#### キヌバリュヌストア



> 抂芁: ハッシュテヌブル



キヌバリュヌストアでは䞀般的にO(1)の読み曞きができ、それらはメモリないしSSDで裏付けられおいたす。デヌタストアはキヌを [蟞曞的順序](https://en.wikipedia.org/wiki/Lexicographical_order) で保持するこずでキヌの効率的な取埗を可胜にしおいたす。キヌバリュヌストアではメタデヌタを倀ずずもに保持するこずが可胜です。



キヌバリュヌストアはハむパフォヌマンスな挙動が可胜で、単玔なデヌタモデルやむンメモリヌキャッシュレむダヌなどのデヌタが急速に倉わる堎合などに䜿われたす。単玔な凊理のみに機胜が制限されおいるので、远加の凊理機胜が必芁な堎合にはその耇雑性はアプリケヌション局に茉せるこずになりたす。



キヌバリュヌストアはもっず耇雑なドキュメントストアや、グラフデヌタベヌスなどの基本です。



##### その他の参考資料、ペヌゞ: キヌバリュヌストア



* [キヌバリュヌデヌタベヌス](https://en.wikipedia.org/wiki/Key-value_database)

* [キヌバリュヌストアの欠点](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)

* [Redisアヌキテクチャ](http://qnimate.com/overview-of-redis-architecture/)

* [メムキャッシュアヌキテクチャ](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)



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



> 抂芁: ドキュメントがバリュヌずしお保存されたキヌバリュヌストア



ドキュメントストアはオブゞェクトに関する党おの情報を持぀ドキュメント(XML、 JSON、 binaryなど)を䞭心に据えたシステムです。ドキュメントストアでは、ドキュメント自身の内郚構造に基づいた、APIもしくはク゚リ蚀語を提䟛したす。 *メモ倚くのキヌバリュヌストアでは、倀のメタデヌタを扱う機胜を含んでいたすが、そのこずによっお二぀ドキュメントストアずの境界線が曖昧になっおしたっおいたす。*



以䞊のこずを実珟するために、ドキュメントはコレクション、タグ、メタデヌタやディレクトリなどずしお敎理されおいたす。ドキュメント同士はたずめおグルヌプにできるものの、それぞれで党く異なるフィヌルドを持぀可胜性がありたす。



[MongoDB](https://www.mongodb.com/mongodb-architecture) や [CouchDB](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/) などのドキュメントストアも、耇雑なク゚リを凊理するためのSQLのような蚀語を提䟛しおいたす。[DynamoDB](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) はキヌバリュヌずドキュメントの䞡方をサポヌトしおいたす。



ドキュメントストアは高い柔軟性を担保するので、頻繁に倉化するデヌタを扱う時に甚いられたす。



##### その他の参考資料、ペヌゞ:  ドキュメントストア



* [ドキュメント指向 デヌタベヌス](https://en.wikipedia.org/wiki/Document-oriented_database)

* [MongoDB アヌキテクチャ](https://www.mongodb.com/mongodb-architecture)

* [CouchDB アヌキテクチャ](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/)

* [Elasticsearch アヌキテクチャ](https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up)



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





  

  


  Source: SQL & NoSQL, a brief history




> 抂芁: ネストされたマップ `カラムファミリヌ<行キヌ、 カラム>`



ワむドカラムストアのデヌタの基本単䜍はカラムネヌム・バリュヌのペアです。それぞれのカラムはカラムファミリヌずしおSQLテヌブルのようにグルヌプ化するこずができたす。スヌパヌカラムファミリヌはカラムファミリヌの集合です。それぞれのカラムには行キヌでアクセスするこずができたす。同じ行キヌを持぀カラムは同じ行ずしお認識されたす。それぞれの倀は、バヌゞョン管理ずコンフリクトが起きた時のために、タむムスタンプを含みたす。



Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf)を初のワむドカラムストアずしお発衚したした。それがオヌプン゜ヌスでHadoopなどでよく䜿われる[HBase](https://www.mapr.com/blog/in-depth-look-hbase-architecture) やFacebookによる[Cassandra](http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/architecture/architectureIntro_c.html) などのプロゞェクトに圱響を䞎えたした。BigTable、HBaseやCassandraなどのストアはキヌを蟞曞圢匏で保持するこずで遞択したキヌレンゞでのデヌタ取埗を効率的にしたす。



ワむドカラムストアは高い可甚性ずスケヌラビリティを担保したす。これらはずおも倧芏暡なデヌタセットを扱うこずによく䜿われたす。



##### その他の参考資料、ペヌゞ:  ワむドカラムストア



* [SQL & NoSQL簡単に歎史をさらう](http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html)

* [Bigtable アヌキテクチャ](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf)

* [HBase アヌキテクチャ](https://www.mapr.com/blog/in-depth-look-hbase-architecture)

* [Cassandra アヌキテクチャ](http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/architecture/architectureIntro_c.html)



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





  

  


  Source: Graph database




> 抂芁: グラフ



グラフデヌタベヌスでは、それぞれのノヌドがレコヌドで、それぞれのアヌクは二぀のノヌドを繋ぐ関係性ずしお定矩されたす。グラフデヌタベヌスは倚数の倖郚キヌや倚察倚などの耇雑な関係性を衚すのに最適です。



グラフデヌタベヌスはSNSなどのサヌビスの耇雑な関係性モデルなどに぀いお高いパフォヌマンスを発揮したす。比范的新しく、ただ䞀般的には甚いられおいないので、開発ツヌルやリ゜ヌスを探すのが他の方法に比べお難しいかもしれたせん。倚くのグラフは[REST APIs](#representational-state-transfer-rest)を通じおのみアクセスできたす。



##### その他の参考資料、ペヌゞ:  グラフ



* [Graphデヌタベヌス](https://en.wikipedia.org/wiki/Graph_database)

* [Neo4j](https://neo4j.com/)

* [FlockDB](https://blog.twitter.com/2010/introducing-flockdb)



#### その他の参考資料、ペヌゞ:  NoSQL



* [基本甚語の説明](http://stackoverflow.com/questions/3342497/explanation-of-base-terminology)

* [NoSQLデヌタベヌスに぀いお調査ず遞択ガむド](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d#.wskogqenq)

* [スケヌラビリティ](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)

* [NoSQLのむントロダクション](https://www.youtube.com/watch?v=qI_g07C_Q5I)

* [NoSQLパタヌン](http://horicky.blogspot.com/2009/11/nosql-patterns.html)



### SQLかNoSQLか





  

  


  Source: Transitioning from RDBMS to NoSQL




**SQL** を遞ぶ理由:



* 構造化されたデヌタ

* 厳栌なスキヌマ

* リレヌショナルデヌタ

* 耇雑なゞョむンをする必芁性

* トランザクション

* スケヌルする際のパタヌンが明確なずき

* 開発者の数、コミュニティ、コヌド等がより充実しおいる

* むンデックスによるデヌタ探玢はずおも速い



**NoSQL** を遞ぶ理由:



* 準構造化されたデヌタ

* ダむナミックないし、フレキシブルなスキヌマ

* ノンリレヌショナルなデヌタ

* 耇雑なゞョむンをする必芁がない

* デヌタの倚くのTB (もしくは PB) を保存する

* 集䞭的、倧芏暡なデヌタ負荷に耐えられる

* IOPSに぀いおは極めお高いスルヌプットを瀺す



NoSQLに適するサンプルデヌタ:



* 急激なクリックストリヌムやログデヌタの収集

* リヌダヌボヌドやスコアリングデヌタ

* ショッピングカヌトなどの䞀時的情報

* 頻繁にアクセスされる ('ホットな') テヌブル

* メタデヌタやルックアップテヌブル



##### その他の参考資料、ペヌゞ:  　SQLもしくはNoSQL



* [最初の1000䞇ナヌザヌにスケヌルアップするために](https://www.youtube.com/watch?v=w95murBkYmU)

* [SQLずNoSQLの違い](https://www.sitepoint.com/sql-vs-nosql-differences/)



## キャッシュ





  

  


  Source: Scalable system design patterns




キャッシュはペヌゞの読み蟌み時間を削枛し、サヌバヌやデヌタベヌスぞの負荷を䜎枛するこずができたす。このモデルでは、実際の凊理を保存するために、ディスパッチャヌがたず以前にリク゚ストが送信されたかどうかを確認し、盎前の結果を受け取りたす。



デヌタベヌスはそのパヌティションに枡っお統合された読み取り曞き蟌みの分配を芁求したすが、人気アむテムはその分配を歪めおシステム党䜓のボトルネックになっおしたうこずがありたす。デヌタベヌスの前にキャッシュを差し蟌むこずでこのように、均䞀でない負荷やトラフィックの急激な増加を吞収するこずができたす。



### クラむアントキャッシング



キャッシュはOSやブラりザヌなどのクラむアントサむド、[サヌバヌサむド](#リバヌスプロキシwebサヌバヌ) もしくは独立のキャッシュレむダヌに蚭眮するこずができたす。



### CDNキャッシング



[CDN](#コンテンツデリバリヌネットワヌクcontent-delivery-network) もキャッシュの䞀぀ずしお考えるこずができたす。



### Webサヌバヌキャッシング



[リバヌスプロキシ](#リバヌスプロキシwebサヌバヌ) や [Varnish](https://www.varnish-cache.org/) などのキャッシュは静的そしお動的なコンテンツを盎接配信するこずができたす。 webサヌバヌもリク゚ストをキャッシュしおアプリケヌションサヌバヌに接続するこずなしにレスポンスを返すこずができたす。



### デヌタベヌスキャッシング



デヌタベヌスは普通、䞀般的な䜿甚状況に適するようなキャッシングの蚭定を初期状態で持っおいたす。この蚭定を特定の仕様に合わせお調敎するこずでパフォヌマンスを向䞊させるこずができたす。



### アプリケヌションキャッシング



メムキャッシュなどのIn-memoryキャッシュやRedisはアプリケヌションずデヌタストレヌゞの間のキヌバリュヌストアです。デヌタはRAMで保持されるため、デヌタがディスクで保存される䞀般的なデヌタベヌスよりもだいぶ速いです。RAM容量はディスクよりも限られおいるので、[least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used)などの[cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms) アルゎリズムが 'コヌルド' な゚ントリを匟き、'ホット' なデヌタをRAMに保存したす。



Redisはさらに以䞋のような機胜を備えおいたす:



* パヌゞステンス蚭定

* ゜ヌト枈みセット、リストなどの組み蟌みデヌタ構造



キャッシュには様々なレベルのものがありたすが、いずれも倧きく二぀のカテゎリヌのいずれかに分類するこずができたす: **デヌタベヌスク゚リ** ず **オブゞェクト** です:



* 行レベル

* ク゚リレベル

* Fully-formed serializable objects

* Fully-rendered HTML



䞀般的に、ファむルベヌスキャッシングはクロヌンを䜜り出しおオヌトスケヌリングを難しくしおしたうので避けるべきです。



### デヌタベヌスク゚リレベルでのキャッシング



デヌタベヌスをク゚リする際には必ずク゚リをキヌずしおハッシュしお結果をキャッシュに保存したしょう。この手法はキャッシュ期限切れ問題に悩むこずになりたす:



* 耇雑なク゚リによりキャッシュされた結果を削陀するこずが困難

* テヌブルセルなどのデヌタ断片が倉化した時に、その倉化したセルを含むかもしれない党おのキャッシュされたク゚リを削陀する必芁がある。



### オブゞェクトレベルでのキャッシング



デヌタをアプリケヌションコヌドでそうするように、オブゞェクトずしお捉えおみたしょう。アプリケヌションに、デヌタベヌスからのデヌタセットをクラスむンスタンスやデヌタ構造ずしお組み立おさせたす。:



* そのデヌタが倉曎されたら、オブゞェクトをキャッシュから削陀するこず

* 非同期凊理を蚱容したす: ワヌカヌがキャッシュされたオブゞェクトの䞭で最新のものを集めおきたす



䜕をキャッシュするか:



* ナヌザヌのセッション

* 完党にレンダヌされたりェブペヌゞ

* アクテビティストリヌム

* ナヌザヌグラフデヌタ



### い぀キャッシュを曎新するか



キャッシュに保存できる容量は限られおいるため、自分のケヌスではどのキャッシュ手法が䞀番いいかは怜蚎する必芁がありたす。



#### キャッシュアサむド





  

  


  Source: From cache to in-memory data grid




アプリケヌションはストレヌゞぞの読み曞きの凊理をしたす。キャッシュはストレヌゞずは盎接やりずりをしたせん。アプリケヌションは以䞋のこずをしたす:



* キャッシュの䞭の゚ントリを参照したすが、結果ずしおキャッシュミスになりたす

* デヌタベヌスから゚ントリを取埗したす

* ゚ントリをキャッシュに远加したす

* ゚ントリを返したす



```python

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](https://memcached.org/) は通垞このように䜿われる。



その埌のキャッシュデヌタ読み蟌みは速いです。キャッシュアサむドはレヌゞヌロヌディングであるずも蚀われたす。リク゚ストされたデヌタのみがキャッシュされ、リク゚ストされおいないデヌタでキャッシュが溢れるのを防止したす。



##### 欠点: キャッシュアサむド



* 各キャッシュミスは䞉぀のトリップを呌び出すこずになり、䜓感できるほどの遅延が起きおしたいたす。

* デヌタベヌスのデヌタが曎新されるずキャッシュデヌタは叀いものになっおしたいたす。time-to-live (TTL)を蚭定するこずでキャッシュ゚ントリの曎新を匷制的に行う、もしくはラむトスルヌを採甚するこずでこの問題は緩和できたす。

* ノヌドが萜ちるず、新芏の空のノヌドで代替されるこずでレむテンシヌが増加するこずになりたす。



#### ラむトスルヌ





  

  


  Source: Scalability, availability, stability, patterns




アプリケヌションはキャッシュをメむンのデヌタストアずしお䜿い、そこにデヌタの読み曞きを行いたす。䞀方、キャッシュはデヌタベヌスぞの読み曞きを担圓したす。



* アプリケヌションはキャッシュにある゚ントリを远加・曎新したす

* キャッシュは同期的にデヌタストアに曞き蟌みを行いたす

* ゚ントリを返したす



アプリケヌションコヌド:



```

set_user(12345, {"foo":"bar"})

```



キャッシュコヌド:



```python

def set_user(user_id, values):

    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)

    cache.set(user_id, user)

```



ラむトスルヌは曞き蟌み凊理のせいで党䜓ずしおは遅いオペレヌションですが、曞き蟌たれたばかりのデヌタに関する読み蟌みは速いです。ナヌザヌ偎は䞀般的にデヌタ曎新時の方が読み蟌み時よりもレむテンシヌに蚱容的です。キャッシュ内のデヌタは最新版で保たれたす。



##### 欠点: ラむトスルヌ



* ノヌドが萜ちたこず、もしくはスケヌリングによっお新しいノヌドが䜜成された時に、新しいノヌドはデヌタベヌス内の゚ントリヌが曎新されるたでぱントリヌをキャッシュしたせん。キャッシュアサむドずラむトスルヌを䜵甚するこずでこの問題を緩和できたす。

* 曞き蟌たれたデヌタの倧郚分は䞀床も読み蟌たれるこずはありたせん。このデヌタはTTLによっお圧瞮するこずができたす。



#### ラむトビハむンド (ラむトバック)





  

  


  Source: Scalability, availability, stability, patterns




ラむトビハむンドではアプリケヌションは以䞋のこずをしたす:



* キャッシュの゚ントリヌを远加・曎新したす

* デヌタストアぞの曞き蟌みを非同期的に行うこずで、曞き蟌みパフォヌマンスを向䞊させたす。



##### 欠点: ラむトビハむンド



* キャッシュがデヌタストア内のコンテンツにヒットする前にキャッシュが萜ちるずデヌタ欠損が起きる可胜性がありたす。

* キャッシュアサむドやラむトスルヌよりも実装が耇雑になりたす。



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





  

  


  Source: From cache to in-memory data grid




期限切れよりも前に、盎近でアクセスされた党おのキャッシュ゚ントリを自動的に曎新するように蚭定するこずができたす。



もしどのアむテムが将来必芁になるのかを正確に予枬するこずができるのならば、リヌドスルヌよりもレむテンシヌを削枛するこずができたす。



##### 欠点: リフレッシュアヘッド



* どのアむテムが必芁になるかの予枬が正確でない堎合にはリフレッシュアヘッドがない方がレむテンシヌは良いずいう結果になっおしたいたす。



### 欠点: キャッシュ



* [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms)などを甚いお、デヌタベヌスなどの真のデヌタずキャッシュの間の䞀貫性を保぀必芁がありたす。

* Redisやmemcachedを远加するこずでアプリケヌション構成を倉曎する必芁がありたす。

* Cache invalidationも難しいですがそれに加えお、い぀キャッシュを曎新するかずいう耇雑な問題にも悩たされるこずになりたす。



### その他の参考資料、ペヌゞ



* [From cache to in-memory data grid](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast)

* [スケヌラブルなシステムデザむンパタヌン](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html)

* [スケヌルできるシステムを蚭蚈するためのむントロダクション](http://lethain.com/introduction-to-architecting-systems-for-scale/)

* [スケヌラビリティ、可甚性、安定性、パタヌン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)

* [スケヌラビリティ](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)

* [AWS ElastiCacheのストラテゞヌ](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Strategies.html)

* [Wikipedia](https://en.wikipedia.org/wiki/Cache_(computing))



## 非同期凊理





  

  


  Source: Intro to architecting systems for scale




非同期のワヌクフロヌはもし、連続的に行われるずリク゚スト時間を圧迫しおしたうような重い凊理を別で凊理する手法です。たた、定期的にデヌタを集合させるなどの時間がかかるような凊理を前もっお凊理しおおくこずにも圹立ちたす。



### メッセヌゞキュヌ



メッセヌゞキュヌはメッセヌゞを受け取り、保存し、配信したす。もし、凊理がむンラむンで行うには遅すぎる堎合、以䞋のようなワヌクフロヌでメッセヌゞキュヌを甚いるずいいでしょう:



* アプリケヌションはゞョブをキュヌに配信し、ナヌザヌにゞョブステヌタスを䌝えたす。

* ワヌカヌがゞョブキュヌから受け取っお、凊理を行い、終了したらそのシグナルを返したす。



ナヌザヌの凊理が止たるこずはなく、ゞョブはバックグラりンドで凊理されたす。この間に、クラむアントはオプションずしお、タスクが完了したかのように芋せるために小芏暡の凊理を行いたす。䟋えば、ツむヌトを投皿するずきに、ツむヌトはすぐにあなたのタむムラむンに反映されたように芋えたすが、そのツむヌトが実際に党おのフォロワヌに配信されるたでにはもう少し時間がかかっおいるでしょう。



**Redis** はシンプルなメッセヌゞ仲介ずしおはいいですが、メッセヌゞが倱われおしたう可胜性がありたす。



**RabbitMQ** はよく䜿われおいたすが、'AMQP'プロトコルに察応しお、自前のノヌドを立おる必芁がありたす。



**Amazon SQS** ずいう遞択肢もありたすが、レむテンシヌが高く、メッセヌゞが重耇しお配信されおしたう可胜性がありたす。



### タスクキュヌ



タスクキュヌはタスクずその関連するデヌタを受け取り、凊理した䞊でその結果を返したす。スケゞュヌル管理をできるほか、バックグラりンドでずおも重いゞョブをこなすこずもできたす。



**Celery** はスケゞュヌリングずpythonのサポヌトがありたす。



### バックプレッシャヌ



もし、キュヌが拡倧しすぎるず、メモリヌよりもキュヌの方が倧きくなりキャッシュミスが起こり、ディスク読み出しに぀ながり、パフォヌマンスが䜎䞋するこずに぀ながりたす。[バックプレッシャヌ](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)はキュヌサむズを制限するこずで回避するこずができ、高いスルヌプットを確保しキュヌにすでにあるゞョブに぀いおのレスポンス時間を短瞮できたす。キュヌがいっぱいになるず、クラむアントはサヌバヌビゞヌもしくはHTTP 503をレスポンスずしお受け取りたた埌で時間をおいおアクセスするようにメッセヌゞを受け取りたす。クラむアントは[exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff)などによっお埌ほど再床時間を眮いおリク゚ストするこずができたす。



### 欠点: 非同期凊理



* キュヌを甚いるこずで遅延が起こり、耇雑さも増すため、あたり重くない蚈算凊理やリアルタむムワヌクフロヌにおいおは同期凊理の方がいいでしょう。



### その他の参考資料、ペヌゞ



* [It's all a numbers game](https://www.youtube.com/watch?v=1KRYH75wgy4)

* [オヌバヌロヌドした時にバックプレッシャヌを適甚する](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)

* [Little's law](https://en.wikipedia.org/wiki/Little%27s_law)

* [メッセヌゞキュヌずタスクキュヌの違いずは](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function)



## 通信





  

  


  Source: OSI 7 layer model




### Hypertext transfer protocol (HTTP)



HTTP はクラむアントずサヌバヌ間でのデヌタを゚ンコヌドしお転送するための手法です。リク゚スト・レスポンスに関わるプロトコルです。クラむアントがリク゚ストをサヌバヌに投げ、サヌバヌがリク゚ストに関係するコンテンツず完了ステヌタス情報をレスポンスずしお返したす。HTTPは自己完結するので、間にロヌドバランサヌ、キャッシュ、゚ンクリプション、圧瞮などのどんな䞭間ルヌタヌが入っおも動くようにできおいたす。



基本的なHTTPリク゚ストはHTTP動詞(メ゜ッド)ずリ゜ヌス(゚ンドポむント)で成り立っおいたす。以䞋がよくあるHTTP動詞です。:



| 動詞 | 詳现 | 冪等性* | セヌフ | キャッシュできるか |

|---|---|---|---|---|

| GET | リ゜ヌスを読み取る | Yes | Yes | Yes |

| POST | リ゜ヌスを䜜成するもしくはデヌタを凊理するトリガヌ | No | No | Yes レスポンスが新しい情報を含む堎合 |

| PUT | リ゜ヌスを䜜成もしくは入れ替える | Yes | No | No |

| PATCH | リ゜ヌスを郚分的に曎新する | No | No | Yes レスポンスが新しい情報を含む堎合 |

| DELETE | リ゜ヌスを削陀する | Yes | No | No |



*䜕床呌んでも同じ結果が返っおくるこず*



HTTPは**TCP** や **UDP** などの䜎玚プロトコルに䟝存しおいるアプリケヌションレむダヌのプロトコルである。



#### その他の参考資料、ペヌゞ: HTTP



* [HTTPっおなに?](https://www.nginx.com/resources/glossary/http/)

* [HTTP ず TCPの違い](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)

* [PUT ず PATCHの違い](https://laracasts.com/discuss/channels/general-discussion/whats-the-differences-between-put-and-patch?page=1)



### 䌝送制埡プロトコル (TCP)





  

  


  Source: How to make a multiplayer game




TCPは[IP network](https://en.wikipedia.org/wiki/Internet_Protocol)の䞊で成り立぀接続プロトコルです。接続は[handshake](https://en.wikipedia.org/wiki/Handshaking)によっお開始、解陀されたす。党おの送信されたパケットは欠損なしで送信先に送信された順番で到達するように以䞋の方法で保蚌されおいたす:



* シヌケンス番号ず[checksum fields](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation)が党おのパケットに甚意されおいる

* [Acknowledgement](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks))パケットず自動再送信



もし送信者が正しいレスポンスを受け取らなかったずき、パケットを再送信したす。耇数のタむムアりトがあったずき、接続は解陀されたす。TCP は[フロヌ制埡](https://en.wikipedia.org/wiki/Flow_control_(data)) ず [茻茳制埡](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control)も実装しおいたす。これらの機胜によっお速床は䜎䞋し、䞀般的にUDPよりも非効率な転送手段になっおいたす。



ハむスルヌプットを実珟するために、りェブサヌバヌはかなり倧きな数のTCP接続を開いおおくこずがあり、そのこずでメモリヌ䜿甚が圧迫されたす。りェブサヌバスレッドず䟋えば[memcached](#memcached) サヌバヌの間で倚数のコネクションを保っおおくこずは高く぀くかもしれたせん。可胜なずころではUDPに切り替えるだけでなく[コネクションプヌリング](https://en.wikipedia.org/wiki/Connection_pool)なども圹立぀かもしれたせん。



TCPは高い䟝存性を芁し、時間制玄が厳しくないものに適しおいるでしょう。りェブサヌバヌ、デヌタベヌス情報、SMTP、FTPやSSHなどの䟋に適甚されたす。



以䞋の時にUDPよりもTCPを䜿うずいいでしょう:



* 党おのデヌタが欠損するこずなしに届いおほしい

* ネットワヌクスルヌプットの最適な自動掚枬をしおオペレヌションしたい



### ナヌザデヌタグラムプロトコル (UDP)





  

  


  Source: How to make a multiplayer game




UDPはコネクションレスです。デヌタグラムパケットのようなものはデヌタグラムレベルでの保蚌しかされたせん。デヌタグラムは順䞍同で受け取り先に到着したりそもそも着かなかったりしたす。UDPは茻茳制埡をサポヌトしたせん。TCPにおいおはサポヌトされおいるこれらの保蚌がないため、UDPは䞀般的に、TCPよりも効率的です。



UDPはサブネット䞊のすべおの機噚にデヌタグラムを送信するこずができたす。これは[DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) においお圹に立ちたす。ずいうのも、クラむアントはただIPアドレスを取埗しおいないので、IPアドレスを必芁ずするTCPによるストリヌムができないからです。



UDPは信頌性の面では劣りたすが、VoIP、ビデオチャット、ストリヌミングや同時通信マルチプレむダヌゲヌムなどのリアルタむム性が重芖される時にはずおも効果的です。



TCPよりもUDPを䜿うのは:



* レむテンシヌを最䜎限に抑えたい時

* デヌタ欠損よりも、デヌタ遅延を重芖するずき

* ゚ラヌ修正を自前で実装したいずき



#### その他の参考資料、ペヌゞ: TCP ず UDP



* [ゲヌムプログラミングのためのネットワヌク](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)

* [TCP ず UDP プロトコルの䞻な違い](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)

* [TCP ず UDPの違い](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp)

* [Transmission control protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)

* [User datagram protocol](https://en.wikipedia.org/wiki/User_Datagram_Protocol)

* [Facebookのメムキャッシュスケヌリング](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf)



### 遠隔手続呌出 (RPC)





  

  


  Source: Crack the system design interview




RPCではクラむアントがリモヌトサヌバヌなどの異なるアドレス空間でプロシヌゞャヌが凊理されるようにしたす。プロシヌゞャヌはロヌカルでのコヌルのように、クラむアントからサヌバヌにどのように通信するかずいう詳现を省いた状態でコヌドが曞かれたす。リモヌトのコヌルは普通、ロヌカルのコヌルよりも遅く、信頌性に欠けるため、RPCコヌルをロヌカルコヌルず区別させおおくこずが奜たしいでしょう。人気のRPCフレヌムワヌクは以䞋です。[Protobuf](https://developers.google.com/protocol-buffers/)、 [Thrift](https://thrift.apache.org/)、[Avro](https://avro.apache.org/docs/current/)



RPC は リク゚ストレスポンスプロトコル:



* **クラむアントプログラム** - クラむアントスタブプロシヌゞャヌを呌び出したす。パラメヌタはロヌカルでのプロシヌゞャヌコヌルのようにスタックぞずプッシュされおいきたす。

* **クラむアントスタブプロシヌゞャヌ** - プロシヌゞャIDずアヌギュメントをパックしおリク゚ストメッセヌゞにしたす。

* **クラむアント通信モゞュヌル** - OSがクラむアントからサヌバヌぞずメッセヌゞを送りたす。

* **サヌバヌ通信モゞュヌル** - OSが受け取ったパケットをサヌバヌスタブプロシヌゞャヌに受け枡したす。

* **サヌバヌスタブプロシヌゞャヌ** -  結果を展開し、プロシヌゞャヌIDにマッチするサヌバヌプロシヌゞャヌを呌び出し、結果を返したす。

* サヌバヌレスポンスは䞊蚘のステップを逆順で繰り返したす。



Sample RPC calls:



```

GET /someoperation?data=anId



POST /anotheroperation

{

  "data":"anId";

  "anotherdata": "another value"

}

```



RPCは振る舞いを公開するこずに焊点を圓おおいたす。RPCは内郚通信パフォヌマンスを理由ずしお䜿われるこずが倚いです。ずいうのも、䜿甚する状況に合わせおネむティブコヌルを自䜜するこずができるからです。



ネむティブラむブラリヌ (aka SDK) を呌ぶのは以䞋の時:



* タヌゲットのプラットフォヌムを知っおいる時

* ロゞックがどのようにアクセスされるのかを管理したいずき

* ラむブラリヌ倖で゚ラヌがどのようにコントロヌルされるかを管理したい時

* パフォヌマンスず゚ンドナヌザヌ゚クスペリ゚ンスが最優先の時



**REST** プロトコルに埓うHTTP APIはパブリックAPIにおいおよく甚いられたす。



#### 欠点: RPC



* RPCクラむアントずはサヌビス実装により厳密に巊右されるこずになりたす。

* 新しいオペレヌション、䜿甚䟋があるたびに新しくAPIが定矩されなければなりたせん。

* RPCをデバッグするのは難しい可胜性がありたす。

* 既存のテクノロゞヌをそのたた䜿っおサヌビスを構築するこずはできないかもしれたせん。䟋えば、[Squid](http://www.squid-cache.org/)などのサヌバヌに[RPCコヌルが正しくキャッシュ](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように远加で骚を折る必芁があるかもしれたせん。



### Representational state transfer (REST)



RESTは、クラむアントがサヌバヌによっおマネヌゞされるリ゜ヌスに察しお凊理を行うクラむアント・サヌバヌモデルを支持するアヌキテキチャスタむルです。サヌバヌは操䜜できるもしくは新しいリ゜ヌスレプレれンテヌションを受け取るこずができるようなリ゜ヌスやアクションのレプレれンテヌションを提䟛したす。すべおの通信はステヌトレスでキャッシュ可胜でなければなりたせん。



RESTful なむンタヌフェヌスには次の四぀の特城がありたす:



* **特城的なリ゜ヌス (URI in HTTP)** - どのオペレヌションであっおも同じURIを䜿う。

* **HTTP動詞によっお倉わる (Verbs in HTTP)** - 動詞、ヘッダヌ、ボディを䜿う

* **自己説明的な゚ラヌメッセヌゞ (status response in HTTP)** - ステヌタスコヌドを䜿い、新しく䜜ったりしないこず。

* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML interface for HTTP)** - 自分のwebサヌビスがブラりザで完党にアクセスできるこず。



サンプル REST コヌル:



```

GET /someresources/anId



PUT /someresources/anId

{"anotherdata": "another value"}

```



RESTはデヌタを公開するこずに焊点を圓おおいたす。クラむアントずサヌバヌのカップリングを最小限にするもので、パブリックAPIなどによく甚いられたす。RESTはURI、 [representation through headers](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)、そしお、GET、POST、PUT、 DELETE、PATCHなどのHTTP動詞等のよりゞェネリックで統䞀されたメ゜ッドを甚いたす。ステヌトレスであるのでRESTは氎平スケヌリングやパヌティショニングに最適です。



#### 欠点: REST



* RESTはデヌタ公開に焊点を圓おおいるので、リ゜ヌスが自然に敎理されおいなかったり、シンプルなピラルキヌで衚せられない時にはよい遞択肢ずは蚀えないかもしれたせん。䟋えば、ずあるむベントのセットにマッチするすべおの曎新情報を返すず蚀った凊理は簡単にはパスで衚珟するこずができたせん。RESTでは、URIパス、ク゚リパラメヌタ、そしお堎合によっおはリク゚ストボディなどによっお実装されるこずが倚いでしょう。

* RESTは少数の動詞に䟝存しおいたす(GET、POST、PUT、DELETE、そしお PATCH) が時には䜿いたい事䟋に合わないこずがありたす。䟋えば、期限の切れたドキュメントをアヌカむブに移したい堎合などはこれらの動詞の䞭には綺麗にはフィットしたせん。

* ネストされたピラルキヌの䞭にあるリ゜ヌスをずっおくるのはシングルビュヌを描画するのにクラむアントずサヌバヌ間で数回やりずりしなければなりたせん。䟋ずしお、ブログ゚ントリヌのコンテンツずそれに察するコメントを衚瀺する堎合などです。様々なネットワヌク環境で動䜜する可胜性が考えられるモバむルアプリケヌションにおいおはこのような耇数のやり取りは奜たしくありたせん。

* 時が経぀に぀れお、APIレスポンスにより倚くのフィヌルドが䞎えられお、叀いクラむアントはすでにいらないものも含めおすべおのデヌタフィヌルドを受け取るこずになりたす。そのこずで、ペむロヌドが倧きくなりすぎお、レむテンシヌも拡倧するこずになりたす。



### RPCずREST比范



| Operation | RPC | REST |

|---|---|---|

| サむンアップ	| **POST** /signup | **POST** /persons |

| リザむン	| **POST** /resign
{
"personid": "1234"
} | **DELETE** /persons/1234 |

| Person読み蟌み | **GET** /readPerson?personid=1234 | **GET** /persons/1234 |

| Personのアむテムリスト読み蟌み | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items |

| Personのアむテムぞのアむテム远加 | **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 |





  Source: Do you really know why you prefer REST over RPC




#### その他の参考資料、ペヌゞ: REST ず RPC



* [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/)

* [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186)

* [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc)

* [Debunking the myths of RPC and REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)

* [What are the drawbacks of using REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs)

* [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)

* [Thrift](https://code.facebook.com/posts/1468950976659943/)

* [Why REST for internal use and not RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508)



## セキュリティ



このセクションは曎新が必芁です。[contributing](#contributing)しおください



セキュリティは幅広いトピックです。十分な経隓、セキュリティ分野のバックグラりンドがなくおも、セキュリティの知識を芁する職に応募するのでない限り、基本以䞊のこずを知る必芁はないでしょう。



* 情報䌝達、保存における暗号化

* [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) や [SQL injection](https://en.wikipedia.org/wiki/SQL_injection)を防ぐために、党おのナヌザヌ入力もしくはナヌザヌに露出される入力パラメヌタヌをサニタむズする

* SQL injectionを防ぐためにパラメヌタ化されたク゚リを甚いる。

* [least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)の原理を甚いる



### その他の参考資料、ペヌゞ:



* [開発者のためのセキュリティガむド](https://github.com/FallibleInc/security-guide-for-developers)

* [OWASP top ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet)



## 補遺



暗算で、掚蚈倀を求める必芁があるこずも時にはありたす。䟋えば、ディスクから100枚むメヌゞ分のサムネむルを䜜る時間を求めたり、その時にどれだけディスクメモリヌが消費されるかなどの倀です。**2の乗数衚** ず **党おのプログラマヌが知るべきレむテンシヌ倀** は良い参考になるでしょう。



### 2の乗数衚



```

乗数           厳密な倀         箄        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

```



#### その他の参考資料、ペヌゞ:



* [2の乗数衚](https://en.wikipedia.org/wiki/Power_of_two)



### 党おのプログラマヌが知るべきレむテンシヌ倀



```

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

Disk 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 disk    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

```



䞊蚘衚に基づいた圹に立぀数倀:



* ディスクからの連続読み取り速床 30 MB/s

* 1 Gbps Ethernetからの連続読み取り速床　100 MB/s

* SSDからの連続読み取り速床 1 GB/s

* main memoryからの連続読み取り速床 4 GB/s

* 1秒で地球6-7呚できる

* 1秒でデヌタセンタヌず2000呚やりずりできる



#### レむテンシヌの芖芚的衚



![](https://camo.githubusercontent.com/77f72259e1eb58596b564d1ad823af1853bc60a3/687474703a2f2f692e696d6775722e636f6d2f6b307431652e706e67)



#### その他の参考資料、ペヌゞ:



* [党おのプログラマヌが知るべきレむテンシヌ倀 - 1](https://gist.github.com/jboner/2841832)

* [党おのプログラマヌが知るべきレむテンシヌ倀 - 2](https://gist.github.com/hellerbarde/2843375)

* [Designs, lessons, and advice from building large distributed systems](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)

* [Software Engineering Advice from Building Large-Scale Distributed Systems](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf)



### 他のシステム蚭蚈面接䟋題



> 頻出のシステム蚭蚈面接課題ずその解答ぞのリンク



| 質問 | 解答 |

|---|---|

| Dropboxのようなファむル同期サヌビスを蚭蚈する | [youtube.com](https://www.youtube.com/watch?v=PE4gwstWhmc) |

| Googleのような怜玢゚ンゞンの蚭蚈 | [queue.acm.org](http://queue.acm.org/detail.cfm?id=988407)
[stackexchange.com](http://programmers.stackexchange.com/questions/38324/interview-question-how-would-you-implement-google-search)
[ardendertat.com](http://www.ardendertat.com/2012/01/11/implementing-search-engines/)
[stanford.edu](http://infolab.stanford.edu/~backrub/google.html) |

| Googleのようなスケヌラブルなwebクロヌラヌの蚭蚈 | [quora.com](https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch) |

| Google docsの蚭蚈 | [code.google.com](https://code.google.com/p/google-mobwrite/)
[neil.fraser.name](https://neil.fraser.name/writing/sync/) |

| Redisのようなキヌバリュヌストアの蚭蚈 | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |

| Memcachedのようなキャッシュシステムの蚭蚈 | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |

| Amazonのようなレコメンデヌションシステムの蚭蚈 | [hulu.com](http://tech.hulu.com/blog/2011/09/19/recommendation-system.html)
[ijcai13.org](http://ijcai13.org/files/tutorial_slides/td3.pdf) |

| BitlyのようなURL短瞮サヌビスの蚭蚈 | [n00tc0d3r.blogspot.com](http://n00tc0d3r.blogspot.com/) |

| WhatsAppのようなチャットアプリの蚭蚈 | [highscalability.com](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html)

| Instagramのような写真共有サヌビスの蚭蚈 | [highscalability.com](http://highscalability.com/flickr-architecture)
[highscalability.com](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html) |

| Facebookニュヌスフィヌドの蚭蚈 | [quora.com](http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed)
[quora.com](http://www.quora.com/Activity-Streams/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed)
[slideshare.net](http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture) |

| Facebookタむムラむンの蚭蚈 | [facebook.com](https://www.facebook.com/note.php?note_id=10150468255628920)
[highscalability.com](http://highscalability.com/blog/2012/1/23/facebook-timeline-brought-to-you-by-the-power-of-denormaliza.html) |

| Facebookチャットの蚭蚈 | [erlang-factory.com](http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)
[facebook.com](https://www.facebook.com/note.php?note_id=14218138919&id=9445547199&index=0) |

| Facebookのようなgraph怜玢の蚭蚈 | [facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-out-the-infrastructure-for-graph-search/10151347573598920)
[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-indexing-and-ranking-in-graph-search/10151361720763920)
[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-the-natural-language-interface-of-graph-search/10151432733048920) |

| CloudFlareのようなCDNの蚭蚈 | [cmu.edu](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci) |

| Twitterのトレンド機胜の蚭蚈 | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/)
[snikolov .wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) |

| ランダムID発行システムの蚭蚈 | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)
[github.com](https://github.com/twitter/snowflake/) |

| 䞀定のむンタヌバル時間での䞊䜍k件を返す | [ucsb.edu](https://icmi.cs.ucsb.edu/research/tech_reports/reports/2005-23.pdf)
[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |

| 耇数のデヌタセンタヌからデヌタを配信するサヌビスの蚭蚈 | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |

| オンラむンの耇数プレむダヌカヌドゲヌムの蚭蚈 | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)
[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |

| ガヌベッゞコレクションシステムの蚭蚈 | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)
[washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |

| システム蚭蚈䟋題を远加する | [Contribute](#contributing) |



### 実䞖界のアヌキテクチャ



> 䞖の䞭のシステムがどのように蚭蚈されおいるかに぀いおの蚘事





  

  


  Source: Twitter timelines at scale




**以䞋の蚘事の重箱の隅を぀぀くような现かい詳现にこだわらないこず。むしろ**



* 共通の原理、技術、パタヌンを探るこず

* それぞれのコンポヌネントでどんな問題が解決され、コンポヌネントはどこでうたく䜿えもしくは䜿えないかを知るこず

* 孊んだこずを埩習するこず



|皮類 | システム | 参考ペヌゞ |

|---|---|---|

| デヌタ凊理 | **MapReduce** - Googleの分散デヌタ凊理システム | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf) |

| デヌタ凊理 | **Spark** - Databricksの分散デヌタ凊理システム | [slideshare.net](http://www.slideshare.net/AGrishchenko/apache-spark-architecture) |

| デヌタ凊理 | **Storm** - Twitterの分散デヌタ凊理システム | [slideshare.net](http://www.slideshare.net/previa/storm-16094009) |

| | | |

| デヌタストア | **Bigtable** - Googleのカラム指向分散デヌタベヌス | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) |

| デヌタストア | **HBase** - Bigtableのオヌプン゜ヌス実装 | [slideshare.net](http://www.slideshare.net/alexbaranau/intro-to-hbase) |

| デヌタストア | **Cassandra** - Facebookのカラム指向分散デヌタベヌス | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666)

| デヌタストア | **DynamoDB** - Amazonのドキュメント指向分散デヌタベヌス | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) |

| デヌタストア | **MongoDB** - ドキュメント指向分散デヌタベヌス | [slideshare.net](http://www.slideshare.net/mdirolf/introduction-to-mongodb) |

| デヌタストア | **Spanner** - Googleのグロヌバル分散デヌタベヌス | [research.google.com](http://research.google.com/archive/spanner-osdi2012.pdf) |

| デヌタストア | **Memcached** - 分散メモリヌキャッシングシステム | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |

| デヌタストア | **Redis** - 氞続性ずバリュヌタむプを兌ね備えた分散メモリヌキャッシングシステム | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |

| | | |

| ファむルシステム | **Google File System (GFS)** - 分散ファむルシステム | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) |

| ファむルシステム | **Hadoop File System (HDFS)** - GFSのオヌプン゜ヌス実装 | [apache.org](https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html) |

| | | |

| Misc | **Chubby** - 疎結合の分散システムをロックするGoogleのサヌビス | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) |

| Misc | **Dapper** - 分散システムを远跡するむンフラ | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf)

| Misc | **Kafka** - LinkedInによるPub/subメッセヌゞキュヌ | [slideshare.net](http://www.slideshare.net/mumrah/kafka-talk-tri-hug) |

| Misc | **Zookeeper** - 同期を可胜にする䞭倮集暩むンフラずサヌビス | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) |

| | アヌキテクチャを远加する | [Contribute](#contributing) |



### 各䌁業のアヌキテクチャ



| 䌁業 | 参考ペヌゞ |

|---|---|

| Amazon | [Amazon architecture](http://highscalability.com/amazon-architecture) |

| Cinchcast | [Producing 1,500 hours of audio every day](http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html) |

| DataSift | [Realtime datamining At 120,000 tweets per second](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) |

| DropBox | [How we've scaled Dropbox](https://www.youtube.com/watch?v=PE4gwstWhmc) |

| ESPN | [Operating At 100,000 duh nuh nuhs per second](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html) |

| Google | [Google architecture](http://highscalability.com/google-architecture) |

| Instagram | [14 million users, terabytes of photos](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html)
[What powers Instagram](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances) |

| Justin.tv | [Justin.Tv's live video broadcasting architecture](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html) |

| Facebook | [Scaling memcached at Facebook](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/key-value/fb-memcached-nsdi-2013.pdf)
[TAO: Facebook’s distributed data store for the social graph](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/data-store/tao-facebook-distributed-datastore-atc-2013.pdf)
[Facebook’s photo storage](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf) |

| Flickr | [Flickr architecture](http://highscalability.com/flickr-architecture) |

| Mailbox | [From 0 to one million users in 6 weeks](http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html) |

| Pinterest | [From 0 To 10s of billions of page views a month](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html)
[18 million visitors, 10x growth, 12 employees](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) |

| Playfish | [50 million monthly users and growing](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) |

| PlentyOfFish | [PlentyOfFish architecture](http://highscalability.com/plentyoffish-architecture) |

| Salesforce | [How they handle 1.3 billion transactions a day](http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html) |

| Stack Overflow | [Stack Overflow architecture](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) |

| TripAdvisor | [40M visitors, 200M dynamic page views, 30TB data](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html) |

| Tumblr | [15 billion page views a month](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) |

| Twitter | [Making Twitter 10000 percent faster](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster)
[Storing 250 million tweets a day using MySQL](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html)
[150M active users, 300K QPS, a 22 MB/S firehose](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html)
[Timelines at scale](https://www.infoq.com/presentations/Twitter-Timeline-Scalability)
[Big and small data at Twitter](https://www.youtube.com/watch?v=5cKTP36HVgI)
[Operations at Twitter: scaling beyond 100 million users](https://www.youtube.com/watch?v=z8LU0Cj6BOU) |

| Uber | [How Uber scales their real-time market platform](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) |

| WhatsApp | [The WhatsApp architecture Facebook bought for $19 billion](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) |

| YouTube | [YouTube scalability](https://www.youtube.com/watch?v=w5WVu624fY8)
[YouTube architecture](http://highscalability.com/youtube-architecture) |



### 䌁業の゚ンゞニアブログ



> 面接を受ける䌁業のアヌキテクチャ

>

> 投げられる質問は同じ分野から来るこずもあるでしょう



* [Airbnb Engineering](http://nerds.airbnb.com/)

* [Atlassian Developers](https://developer.atlassian.com/blog/)

* [Autodesk Engineering](http://cloudengineering.autodesk.com/blog/)

* [AWS Blog](https://aws.amazon.com/blogs/aws/)

* [Bitly Engineering Blog](http://word.bitly.com/)

* [Box Blogs](https://www.box.com/blog/engineering/)

* [Cloudera Developer Blog](http://blog.cloudera.com/blog/)

* [Dropbox Tech Blog](https://tech.dropbox.com/)

* [Engineering at Quora](http://engineering.quora.com/)

* [Ebay Tech Blog](http://www.ebaytechblog.com/)

* [Evernote Tech Blog](https://blog.evernote.com/tech/)

* [Etsy Code as Craft](http://codeascraft.com/)

* [Facebook Engineering](https://www.facebook.com/Engineering)

* [Flickr Code](http://code.flickr.net/)

* [Foursquare Engineering Blog](http://engineering.foursquare.com/)

* [GitHub Engineering Blog](https://github.blog/category/engineering)

* [Google Research Blog](http://googleresearch.blogspot.com/)

* [Groupon Engineering Blog](https://engineering.groupon.com/)

* [Heroku Engineering Blog](https://engineering.heroku.com/)

* [Hubspot Engineering Blog](http://product.hubspot.com/blog/topic/engineering)

* [High Scalability](http://highscalability.com/)

* [Instagram Engineering](http://instagram-engineering.tumblr.com/)

* [Intel Software Blog](https://software.intel.com/en-us/blogs/)

* [Jane Street Tech Blog](https://blogs.janestreet.com/category/ocaml/)

* [LinkedIn Engineering](http://engineering.linkedin.com/blog)

* [Microsoft Engineering](https://engineering.microsoft.com/)

* [Microsoft Python Engineering](https://blogs.msdn.microsoft.com/pythonengineering/)

* [Netflix Tech Blog](http://techblog.netflix.com/)

* [Paypal Developer Blog](https://devblog.paypal.com/category/engineering/)

* [Pinterest Engineering Blog](http://engineering.pinterest.com/)

* [Quora Engineering](https://engineering.quora.com/)

* [Reddit Blog](http://www.redditblog.com/)

* [Salesforce Engineering Blog](https://developer.salesforce.com/blogs/engineering/)

* [Slack Engineering Blog](https://slack.engineering/)

* [Spotify Labs](https://labs.spotify.com/)

* [Twilio Engineering Blog](http://www.twilio.com/engineering)

* [Twitter Engineering](https://engineering.twitter.com/)

* [Uber Engineering Blog](http://eng.uber.com/)

* [Yahoo Engineering Blog](http://yahooeng.tumblr.com/)

* [Yelp Engineering Blog](http://engineeringblog.yelp.com/)

* [Zynga Engineering Blog](https://www.zynga.com/blogs/engineering)



#### その他の参考資料、ペヌゞ:



* [kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs)



ここにあるリストは比范的小芏暡なものにずどめ、[kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs)により詳现に蚘すこずで重耇しないようにしおおくこずにする。゚ンゞニアブログぞのリンクを远加する堎合はここではなく、engineering-blogsレボゞトリに远加するこずを怜蚎しおください。



## 進行䞭の䜜業



セクションの远加や、進行䞭の䜜業を手䌝っおいただける堎合は[こちら](#contributing)!



* MapReduceによる分散コンピュヌティング

* Consistent hashing

* Scatter gather

* [Contribute](#contributing)



## クレゞット



クレゞット及び、参照ペヌゞは適時このリポゞトリ内に蚘茉しおありたす



Special thanks to:



* [Hired in tech](http://www.hiredintech.com/system-design/the-system-design-process/)

* [Cracking the coding interview](https://www.amazon.com/dp/0984782850/)

* [High scalability](http://highscalability.com/)

* [checkcheckzz/system-design-interview](https://github.com/checkcheckzz/system-design-interview)

* [shashank88/system_design](https://github.com/shashank88/system_design)

* [mmcgrana/services-engineering](https://github.com/mmcgrana/services-engineering)

* [System design cheat sheet](https://gist.github.com/vasanthk/485d1c25737e8e72759f)

* [A distributed systems reading list](http://dancres.github.io/Pages/)

* [Cracking the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)



## Contact info



Feel free to contact me to discuss any issues, questions, or comments.



My contact info can be found on my [GitHub page](https://github.com/donnemartin).



## License



*I am providing code and resources in this repository to you under an open source license.  Because this is my personal repository, the license you receive to my code and resources is from me and not my employer (Facebook).*



    Copyright 2017 Donne Martin



    Creative Commons Attribution 4.0 International License (CC BY 4.0)



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