fix: broken link 2 (#17)

dwango · Jun 14, 2022 · bf1665e · bf1665e
1 parent d27898c
commit bf1665e
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 4 deletions.
diff --git a/content/docs/migrate-practice/migrate-docker-swarm-to-kubernetes.md b/content/docs/migrate-practice/migrate-docker-swarm-to-kubernetes.md
@@ -29,7 +29,7 @@ Apache による経路変更はパス単位（URI 単位）で実施できるた
 4. Kubernetes内への疎通も確認できた後、istio-ingressgatewayのTraffic Weightを完全に切り替える
 
 rps がそこまで高くない BFF はこの手順を繰り返すことで移行を淡々とすすめることができました。
-高 rps の BFF サーバーはこの手順でやるにはリスクが高いので、トラフィックのミラーリングを実施して Gateway と Kubernetes クラスター全体の状態を確認していきます。
+高rpsのBFFサーバーはこの手順でやるにはリスクが高いので、トラフィックのミラーリングを実施してGatewayと Kubernetes クラスター全体の状態を確認していきます。
 [アクセスログ](../../service-mesh/access-log)で紹介したようにPodにログ出力のための`nginx`が含まれるため、二重計上されないために`NodePort`を`istio-proxy`に向けたものをミラーリングのためのポートとして提供しています。
 nginxのミラーリングによって高rpsの時間変化がDataDogに蓄積され、そこから[対応表](../../scalability/horizontal-pod-autoscaler/#リソースの値をどうやって決めるか)を用いてリソースの逆算を実施し、移行フェーズへステップを進めることができました。
 

diff --git a/content/docs/network/architecture.md b/content/docs/network/architecture.md
@@ -33,9 +33,9 @@ ApacheによるLoad Balanceは移行前のDocker Swarmと同じですが、全
 
 また、Rate Limitなどnginxで実施していたシステムの防衛処理はKubernetesクラスター全体に対するGlobal Rate LimitとPod単位のLocal Rate Limitに機能を分割しました。これらの詳細は別のページで紹介しています。
 
-* [Rate Limitに関して](../rate-limit/global-ratelimit)
-* [Istio Ingress Gatewayに関して](../service-mesh/istio-ingress-gateway)
-* [アクセスログに関して](../service-mesh/access-log)
+* [Rate Limitに関して](../../rate-limit/global-ratelimit)
+* [Istio Ingress Gatewayに関して](../../service-mesh/traffic-management)
+* [アクセスログに関して](../../service-mesh/access-log)
 
 ## Apacheを移行時のロードバランサーとして選定した理由