translation_ja fix in links

README-jp.md

@@ -262,15 +262,15 @@
 * キャッシング
 * データベースシャーディング
 
-取りうる解決策とそのトレードオフについて議論をしよう。全てのことはトレードオフの関係にある。ボトルネックについては次の項を読むといい。[スケーラブルなシステム設計の原理](#index-of-system-design-topics).
+取りうる解決策とそのトレードオフについて議論をしよう。全てのことはトレードオフの関係にある。ボトルネックについては次の項を読むといい。[スケーラブルなシステム設計の原理](#システム設計目次).
 
 ### ちょっとした暗算問題
 
-ちょっとした推計値を手計算ですることを求められることもあるかもしれません。[索引](#appendix)の以下の項目が役に立つでしょう:
+ちょっとした推計値を手計算ですることを求められることもあるかもしれません。[補遺](#補遺)の以下の項目が役に立つでしょう:
 
 * [チラ裏計算でシステム設計する](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
-* [2の指数表](#powers-of-two-table)
+* [2の乗数表](#2の乗数表)
-* [全てのプログラマーが知っておくべきレイテンシの参考値](#latency-numbers-every-programmer-should-know)
+* [全てのプログラマーが知っておくべきレイテンシの参考値](#全てのプログラマーが知るべきレイテンシー値)
 
 ### 文献とその他の参考資料
 
@@ -457,7 +457,7 @@
 
 レスポンスはノード上にあるデータで最新のものを返します。つまり、最新版のデータが返されるとは限りません。分断が解消された後も、書き込みが反映されるのには時間がかかります。
 
-[結果整合性](#eventual-consistency)　を求めるサービスの際にはAPを採用するのがいいでしょう。もしくは、外部エラーに関わらずシステムが稼働する必要がある際にも同様です。
+[結果整合性](#結果整合性)　を求めるサービスの際にはAPを採用するのがいいでしょう。もしくは、外部エラーに関わらずシステムが稼働する必要がある際にも同様です。
 
 ### その他の参考資料、ページ
 
@@ -467,7 +467,7 @@
 
 ## 一貫性パターン
 
-同じデータの複製が複数ある状態では、クライアントが一貫したデータ表示を受け取るために、どのようにそれらを同期すればいいのかという課題があります。 [CAP 理論](#cap-theorem) における一貫性の定義を思い出してみましょう。全ての読み取りは最新の書き込みデータもしくはエラーを受け取るはずです。
+同じデータの複製が複数ある状態では、クライアントが一貫したデータ表示を受け取るために、どのようにそれらを同期すればいいのかという課題があります。 [CAP 理論](#cap-理論) における一貫性の定義を思い出してみましょう。全ての読み取りは最新の書き込みデータもしくはエラーを受け取るはずです。
 
 ### 弱い一貫性
 
@@ -503,15 +503,15 @@
 
 起動までのダウンタイムはパッシブサーバーが「ホット」なスタンバイ状態にあるか、「コールド」なスタンバイ状態にあるかで変わります。アクティブなサーバーのみがトラフィックを捌きます。
 
-Active-passive failover can also be referred to as master-slave failover.
+アクティブパッシブフェイルオーバーはマスタースレーブフェイルオーバーと呼ばれることもあります。
 
-#### Active-active
+#### アクティブ・アクティブ
 
-In active-active, both servers are managing traffic, spreading the load between them.
+アクティブアクティブ構成では両方のサーバーがトラフィックを捌くことで負荷を分散します。
 
-If the servers are public-facing, the DNS would need to know about the public IPs of both servers.  If the servers are internal-facing, application logic would need to know about both servers.
+これらのサーバーがパブリックなものの場合、DNSは両方のサーバーのパブリックIPを知っている必要があります。もし、プライベートなものな場合、アプリケーションロジックが両方のサーバーの情報について知っている必要があります。
 
-アクティブ・パッシブなフェイルオーバーはマスター・スレーブフェイルオーバーだとも言えるでしょう。
+アクティブ・パッシブなフェイルオーバーはマスター・スレーブフェイルオーバーと呼ばれることもあります。
 
 ### 短所: フェイルオーバー
 
@@ -522,10 +522,10 @@ If the servers are public-facing, the DNS would need to know about the public IP
 
 #### マスター・スレーブ　と　マスター・マスター
 
-このトピックは [Database](#database) セクションにおいてより詳細に解説されています:
+このトピックは [データベース](#データベース) セクションにおいてより詳細に解説されています:
 
-* [マスター・スレーブ レプリケーション](#master-slave-replication)
+* [マスター・スレーブ レプリケーション](#マスタースレーブ-レプリケーション)
-* [マスター・マスター レプリケーション](#master-master-replication)
+* [マスター・マスター レプリケーション](#マスターマスター-レプリケーション)
 
 ## ドメインネームシステム
 
@@ -628,7 +628,7 @@ CDNを用いてコンテンツを配信することで以下の二つの理由
     * [X.509 certificates](https://en.wikipedia.org/wiki/X.509) をそれぞれのサーバーにインストールする必要をなくします
 * **セッション管理** - クッキーを取り扱いウェブアプリがセッション情報を保持していない時などに、特定のクライアントのリクエストを同じインスタンスへと流します。
 
-障害に対応するために、[アクティブ・パッシブ](#active-passive) もしくは [アクティブ・アクティブ](#active-active) モードのいずれに限らず、複数のロードバランサーを配置するのが一般的です。
+障害に対応するために、[アクティブ・パッシブ](#アクティブパッシブ) もしくは [アクティブ・アクティブ](#アクティブアクティブ) モードのいずれに限らず、複数のロードバランサーを配置するのが一般的です。
 
 ロードバランサーは以下のような種々のメトリックを用いてとらふぃっくんルーティングを行うことができます:
 
@@ -636,16 +636,16 @@ CDNを用いてコンテンツを配信することで以下の二つの理由
 * Least loaded
 * セッション/クッキー
 * [ラウンドロビンもしくは荷重ラウンドロビン](http://g33kinfo.com/info/archives/2657)
-* [Layer 4](#layer-4-load-balancing)
+* [Layer 4](#layer-4-ロードバランシング)
-* [Layer 7](#layer-7-load-balancing)
+* [Layer 7](#layer-7-ロードバランシング)
 
 ### Layer 4 ロードバランシング
 
-Layer 4 ロードバランサーは [トランスポートレイヤー](#communication) を参照してどのようにリクエストを配分するか判断します。一般的に、トランスポートレイヤーとしては、ソース、送信先IPアドレス、ヘッダーに記述されたポート番号が含まれますが、パケットの中身のコンテンツは含みません Layer 4 ロードバランサーはネットワークパケットを上流サーバーへ届け、上流サーバーから配信することでネットワークアドレス変換 [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/) を実現します。
+Layer 4 ロードバランサーは [トランスポートレイヤー](#通信) を参照してどのようにリクエストを配分するか判断します。一般的に、トランスポートレイヤーとしては、ソース、送信先IPアドレス、ヘッダーに記述されたポート番号が含まれますが、パケットの中身のコンテンツは含みません Layer 4 ロードバランサーはネットワークパケットを上流サーバーへ届け、上流サーバーから配信することでネットワークアドレス変換 [Network Address Translation (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/) を実現します。
 
 ### Layer 7 ロードバランシング
 
-Layer 7 ロードバランサーは [アプリケーションレイヤー](#communication) を参照してどのようにリクエストを配分するか判断します。ヘッダー、メッセージ、クッキーなどのコンテンツのことです。Layer 7 ロードバランサーはネットワークトラフィックの終端を受け持ち メッセージを読み込み、ロードバランシングの判断をし、選択したサーバーとの接続を繋ぎます。例えば layer 7 ロードバランサーは動画のトラフィックを直接、そのデータをホストしているサーバーにつなぐと同時に、決済処理などのより繊細なトラフィックをセキュリティ強化されたサーバー流すということもできる。
+Layer 7 ロードバランサーは [アプリケーションレイヤー](#通信) を参照してどのようにリクエストを配分するか判断します。ヘッダー、メッセージ、クッキーなどのコンテンツのことです。Layer 7 ロードバランサーはネットワークトラフィックの終端を受け持ち メッセージを読み込み、ロードバランシングの判断をし、選択したサーバーとの接続を繋ぎます。例えば layer 7 ロードバランサーは動画のトラフィックを直接、そのデータをホストしているサーバーにつなぐと同時に、決済処理などのより繊細なトラフィックをセキュリティ強化されたサーバー流すということもできる。
 
 柔軟性とのトレードオフになりますが、 layer 4 ロードバランサーではLayer 7ロードバランサーよりも所要時間、計算リソースを少なく済むことができます。ただし、昨今の汎用ハードウェアではパフォーマンスは最小限のみしか発揮できないでしょう。
 
@@ -657,7 +657,7 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#comm
 
 * 水平的にスケーリングしていくと、複雑さが増す上に、サーバーのクローニングが必要になる
     * サーバーはステートレスである必要がある: ユーザーに関連するセッションや、プロフィール写真などのデータを持ってはいけない
-    * セッションは一元的な[データベース](#database) (SQL, NoSQL)などのデータストアにストアされるか [キャッシュ](#cache) (Redis, Memcached)に残す必要があります。
+    * セッションは一元的な[データベース](#データベース) (SQL, NoSQL)などのデータストアにストアされるか [キャッシュ](#キャッシュ) (Redis, Memcached)に残す必要があります。
 * キャッシュやデータベースなどの下流サーバーは上流サーバーがスケールアウトするにつれてより多くの同時接続を保たなければなりません。
 
 ### 欠点: ロードバランサー
@@ -731,7 +731,7 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#comm
 
  **単一責任の原則** では、小さい自律的なサービスが協調して動くように提唱しています。小さいサービスの小さいチームが急成長のためにより積極的な計画を立てられるようにするためです。
 
-アプリケーション層は[異時性](#asynchronism)もサポートします。
+アプリケーション層は[非同期処理](#非同期処理)もサポートします。
 
 ### マイクロサービス
 
@@ -741,7 +741,7 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#comm
 
 ### Service Discovery
 
-[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](#key-value-store) を持っており、設定データや共有データなどのデータを保存しておくことに使われます。
+[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](#キーバリューストア) を持っており、設定データや共有データなどのデータを保存しておくことに使われます。
 
 ### 欠点: アプリケーション層
 
@@ -790,7 +790,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ
 ##### 欠点: マスタースレーブ レプリケーション
 
 * スレーブをマスターに昇格させるには追加のロジックが必要になる。
-* マスタースレーブ レプリケーション、マスターマスター レプリケーションの **両方** の欠点は次を参照[欠点: レプリケーション](#disadvantages-replication) 
+* マスタースレーブ レプリケーション、マスターマスター レプリケーションの **両方** の欠点は次を参照[欠点: レプリケーション](#欠点-マスタースレーブ-レプリケーション) 
 
 #### マスターマスター レプリケーション
 
@@ -807,7 +807,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ
 * ロードバランサーを導入するか、アプリケーションロジックを変更することでどこに書き込むかを指定しなければならない。
 * 大体のマスターマスターシステムは、一貫性が緩い（ACID原理を守っていない）もしくは、同期する時間がかかるために書き込みのレイテンシーが増加してしまっている。
 * 書き込みノードが追加され、レイテンシーが増加するにつれ書き込みの衝突の可能性が増える。
-* マスタースレーブ レプリケーション、マスターマスター レプリケーションの **両方** の欠点は次を参照[欠点: レプリケーション](#disadvantages-replication) 
+* マスタースレーブ レプリケーション、マスターマスター レプリケーションの **両方** の欠点は次を参照[欠点: レプリケーション](#欠点-マスタースレーブ-レプリケーション) 
 
 ##### 欠点: レプリケーション
 
@@ -875,7 +875,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ
 
 非正規化では、書き込みのパフォーマンスをいくらか犠牲にして読み込みのパフォーマンスを向上させようとします。計算的に重いテーブルの結合などをせずに、複数のテーブルに冗長なデータのコピーが書き込まれるのを許容します。いくつかのRDBMS例えば、[PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL) やOracleはこの冗長な情報を取り扱い、一貫性を保つための[materialized views](https://en.wikipedia.org/wiki/Materialized_view) という機能をサポートしています。
 
-[フェデレーション](#federation) や [シャーディング](#sharding)などのテクニックによってそれぞれのデータセンターに分配されたデータを合一させることはとても複雑な作業です。非正規化によってそのような複雑な処理をしなくて済むようになります。
+[フェデレーション](#federation) や [シャーディング](#シャーディング)などのテクニックによってそれぞれのデータセンターに分配されたデータを合一させることはとても複雑な作業です。非正規化によってそのような複雑な処理をしなくて済むようになります。
 
 多くのシステムで、100対1あるいはは1000対1くらいになるくらい読み取りの方が、書き込みのトラフィックよりも多いことでしょう。読み込みを行うために、複雑なデータベースのジョイン処理が含まれるものは計算的に高価につきますし、ディスクの処理時間で膨大な時間を費消してしまうことになります。
 
@@ -922,7 +922,7 @@ SQLチューニングは広範な知識を必要とする分野で多くの [本
 
 ##### 高負荷なジョインを避ける
 
-* [非正規化](#denormalization) パフォーマンスが必要なところには適用する
+* [非正規化](#非正規化) パフォーマンスが必要なところには適用する
 
 ##### テーブルのパーティション
 
@@ -941,15 +941,15 @@ SQLチューニングは広範な知識を必要とする分野で多くの [本
 
 ### NoSQL
 
-NoSQL は **key-value store**、 **document-store**、 **wide column store**、 もしくは **graph database**によって表現されるデータアイテムの集合です。データは一般的に正規化されておらず、アプリケーション側でジョインが行われます。大部分のNoSQLは真のACIDトランザクションを持たず、 [結果整合性](#eventual-consistency) 的な振る舞いの方を好みます。
+NoSQL は **key-value store**、 **document-store**、 **wide column store**、 もしくは **graph database**によって表現されるデータアイテムの集合です。データは一般的に正規化されておらず、アプリケーション側でジョインが行われます。大部分のNoSQLは真のACIDトランザクションを持たず、 [結果整合性](#結果整合性) 的な振る舞いの方を好みます。
 
-**BASE** はしばしばNoSQLデータベースのプロパティを説明するために用いられます。[CAP Theorem](#cap-theorem) と対照的に、BASEは一貫性よりも可用性を優先します。
+**BASE** はしばしばNoSQLデータベースのプロパティを説明するために用いられます。[CAP Theorem](#cap-理論) と対照的に、BASEは一貫性よりも可用性を優先します。
 
 * **Basically available** - システムは可用性を保証します。
 * **Soft state** - システムの状態は入力がなくても時間経過とともに変化する可能性があります。
 * **結果整合性** - システム全体は時間経過とともにその間に入力がないという前提のもと、一貫性が達成されます。
 
-[SQL or NoSQL](#sql-or-nosql) かを選択するのに加えて、どのタイプのNoSQLがどの使用例に最も適するかを理解するのはとても有益です。このセクションでは **キーバリューストア**、 **ドキュメントストア**、 **ワイドカラムストア**、 と **グラフデータベース** について触れていきます。
+[SQLか？NoSQLか？](#sqlかnosqlか) かを選択するのに加えて、どのタイプのNoSQLがどの使用例に最も適するかを理解するのはとても有益です。このセクションでは **キーバリューストア**、 **ドキュメントストア**、 **ワイドカラムストア**、 と **グラフデータベース** について触れていきます。
 
 #### キーバリューストア
 
@@ -1094,7 +1094,7 @@ NoSQLに適するサンプルデータ:
 
 ### クライアントキャッシング
 
-キャッシュはOSやブラウザーなどのクライアントサイド、[server side](#reverse-proxy) もしくは独立のキャッシュレイヤーに設置することができます。
+キャッシュはOSやブラウザーなどのクライアントサイド、[server side](#リバースプロキシwebサーバー) もしくは独立のキャッシュレイヤーに設置することができます。
 
 ### CDNキャッシング
 
@@ -1102,7 +1102,7 @@ NoSQLに適するサンプルデータ:
 
 ### Webサーバーキャッシング
 
-[リバースプロキシ](#reverse-proxy-web-server) や [Varnish](https://www.varnish-cache.org/) などのキャッシュは静的そして動的なコンテンツを直接配信することができます。 webサーバーもリクエストをキャッシュしてアプリケーションサーバーに接続することなしにレスポンスを返すことができます。
+[リバースプロキシ](#リバースプロキシwebサーバー) や [Varnish](https://www.varnish-cache.org/) などのキャッシュは静的そして動的なコンテンツを直接配信することができます。 webサーバーもリクエストをキャッシュしてアプリケーションサーバーに接続することなしにレスポンスを返すことができます。
 
 ### データベースキャッシング