diff --git a/README-jp.md b/README-jp.md index 51568f2e..abf15e81 100644 --- a/README-jp.md +++ b/README-jp.md @@ -676,7 +676,7 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#comm * [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) -## Reverse proxy (web server) +## リバースプロキシ(webサーバー)

@@ -685,38 +685,38 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#comm

-A reverse proxy is a web server that centralizes internal services and provides unified interfaces to the public. Requests from clients are forwarded to a server that can fulfill it before the reverse proxy returns the server's response to the client. +リバースプロキシサーバーは内部サービスをまとめて外部に統一されたインターフェースを提供するウェブサーバーです。クライアントからのリクエストはそれに対応するサーバーに送られて、その後レスポンスをリバースプロキシがクライアントに返します。 -Additional benefits include: +他には以下のような利点があります: -* **Increased security** - Hide information about backend servers, blacklist IPs, limit number of connections per client -* **Increased scalability and flexibility** - Clients only see the reverse proxy's IP, allowing you to scale servers or change their configuration -* **SSL termination** - Decrypt incoming requests and encrypt server responses so backend servers do not have to perform these potentially expensive operations - * Removes the need to install [X.509 certificates](https://en.wikipedia.org/wiki/X.509) on each server -* **Compression** - Compress server responses -* **Caching** - Return the response for cached requests -* **Static content** - Serve static content directly +* **より堅牢なセキュリティ** - バックエンドサーバーの情報、ブラックリストIP、クライアントごとの接続数などの情報を隠すことができます。 +* **スケーラビリティや柔軟性が増します** - クライアントはリバースプロキシのIPしか見ないので、裏でサーバーをスケールしたり、設定を変えやすくなります。 +* **SSL termination** - 入力’されるリクエストを解読し、サーバーのレスポンスを暗号化することでサーバーがこのコストのかかりうる処理をしなくて済むようになります。 + * [X.509 証明書](https://en.wikipedia.org/wiki/X.509) を各サーバーにインストールする必要がなくなります。 +* **圧縮** - サーバーレスポンスを圧縮できます +* **キャッシング** - キャッシュされたリクエストに対して、レスポンスを返します +* **静的コンテンツ** - 静的コンテンツを直接送信することができます。 * HTML/CSS/JS - * Photos - * Videos - * Etc + * 写真 + * 動画 + * などなど -### Load balancer vs reverse proxy +### ロードバランサー vs リバースプロキシ -* Deploying a load balancer is useful when you have multiple servers. Often, load balancers route traffic to a set of servers serving the same function. -* Reverse proxies can be useful even with just one web server or application server, opening up the benefits described in the previous section. -* Solutions such as NGINX and HAProxy can support both layer 7 reverse proxying and load balancing. +* 複数のサーバーがある時にはロードバランサーをデプロイすると役に立つでしょう。 しばしば、ロードバランサーは同じ機能を果たすサーバー群へのトラフィックを捌きます。 +* リバースプロキシでは、上記に述べたような利点を、単一のウェブサーバーやアプリケーションレイヤーに対しても示すことができます。 +* NGINX や HAProxy などの技術はlayer 7 リバースプロキシとロードバランサーの両方をサポートします。 -### Disadvantage(s): reverse proxy +### 欠点: リバースプロキシ -* Introducing a reverse proxy results in increased complexity. -* A single reverse proxy is a single point of failure, configuring multiple reverse proxies (ie a [failover](https://en.wikipedia.org/wiki/Failover)) further increases complexity. +* リバースプロキシを導入するとシステムの複雑性が増します。 +* 単一のリバースプロキシは単一障害点になりえます。一方で、複数のリバースプロキシを導入すると([フェイルオーバー]など(https://en.wikipedia.org/wiki/Failover)) 複雑性はより増します。 -### Source(s) and further reading +### その他の参考資料、ページ -* [Reverse proxy vs load balancer](https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/) -* [NGINX architecture](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/) -* [HAProxy architecture guide](http://www.haproxy.org/download/1.2/doc/architecture.txt) +* [リバースプロキシ 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) ## Application layer