Fix broken link (#16)

content/docs/ci/argo-cd.md

@@ -111,7 +111,7 @@ spec:
     automated:
 ```
 
-一見するとファイル数はとても多くなりますが、[TypeScriptでManifestを生成している](/docs/03/manifest-management/)ため、ファイル数の量は問題ではありません。
+一見するとファイル数はとても多くなりますが、[TypeScriptでManifestを生成している](../../manifest/manifest-management)ため、ファイル数の量は問題ではありません。
 
 
 ## フロントエンドが管理するマイクロサービスのためのManifestのリポジトリ
@@ -133,12 +133,12 @@ spec:
 
 1. 全体最適化が容易になる
 1. Webフロントエンドのアプリケーションは1つのhostに対してルーティングが存在するため全体を見て調整するケースが有る
-   - 後述しますが[Global RateLimit](/docs/06/global-ratelimit/)などがその例
+   - 後述しますが[Global RateLimit](../../rate-limit/global-ratelimit)などがその例
 2. 1つのマイクロサービスに複数のルーティング先が存在するが、デプロイ単位として分割したい場合の管理
 
 これらはWebフロントエンドの開発時にnpmパッケージをモノレポで管理しているところからの発想もあり、モノレポのほうが開発や保守効率が圧倒的に早いことが経験則としてわかっていることも決め手の背景としてあります。
 
-[Slack Botによる自動化](/docs/04/slack-bot/)で改めて紹介しますが、結果的にモノレポで管理した事によってBotによる更新が容易になり、マニフェストの変更から本番デプロイまでが5分以内で終わるスピーディなリポジトリなっています。もはやBotユーザーしかリポジトリの更新をしていない状態です。
+[Slack Botによる自動化](../../ci/slack-bot)で改めて紹介しますが、結果的にモノレポで管理した事によってBotによる更新が容易になり、マニフェストの変更から本番デプロイまでが5分以内で終わるスピーディなリポジトリなっています。もはやBotユーザーしかリポジトリの更新をしていない状態です。
 
 ## `infrastructure`リポジトリのブランチ設計
 

content/docs/ci/argo-rollouts.md

@@ -25,7 +25,7 @@ Istio自体はすでに利用可能な状態にあったため、Traffic Managem
 * [Istio - Traffic Management](https://argoproj.github.io/argo-rollouts/features/traffic-management/istio/)
 
 他と比較はできていませんが、IstioでTraffic Managementをすると、IstioのService Meshの恩恵をそのまま得られることができCanaryデプロイ時にTraffic Weightが変化していることが観測できるようになります。
-なお、[Istio Ingress Gatewayの設定](/docs/05/traffic-management/)でその他の機能についても紹介しています。
+なお、[Istio Ingress Gatewayの設定](../../service-mesh/traffic-management)でその他の機能についても紹介しています。
 
 ## Canary Deployを実施する
 

content/docs/ci/slack-bot.md

@@ -22,7 +22,7 @@ Argo CDによるGitOpsの実現は同時にGitOpsを開発者に強制します
 @bot update version:2.0.0 app:servive-a
 ```
 
-これを受け取ったbotサーバーは、メッセージの入力者を判別したり、コマンド(`update version`)をパースしたりします。コマンドに応じてGitHub APIをCallし、[JSONで記述されたファイル](/docs/03/kubernetes-manifest-generator-architecture/)(User Config)を書き換え、commitします。
+これを受け取ったbotサーバーは、メッセージの入力者を判別したり、コマンド(`update version`)をパースしたりします。コマンドに応じてGitHub APIをCallし、[JSONで記述されたファイル](../../manifest/kubernetes-manifest-generator-architecture)(User Config)を書き換え、commitします。
 その後Pull Requestを作成して、結果をユーザーに返します。
 
 作成されたPull RequestをさらにSlackからマージします。

content/docs/manifest/manifest-management.md

@@ -13,7 +13,7 @@ description: BFFにおけるKubernetesのManifest管理について問題の整
 
 ## 移行後の各Componentのファイル数の規模感
 
-[導入](/docs/01/introduction/#kubernetesでの稼働規模)でも提示していますが改めて、**フロントエンドに関係するマイクロサービス**のManifestは以下の規模で存在しています。
+[導入](../../../#移行後のkubernetesの規模感)でも提示していますが改めて、**フロントエンドに関係するマイクロサービス**のManifestは以下の規模で存在しています。
 これは簡単に管理するとは言えないコンポーネント数があり、これからも増えていきます。
 
 | Component                                  | ファイル数 |

content/docs/migrate-practice/migrate-docker-swarm-to-kubernetes.md

@@ -30,10 +30,10 @@ Apache による経路変更はパス単位（URI 単位）で実施できるた
 
 rps がそこまで高くない BFF はこの手順を繰り返すことで移行を淡々とすすめることができました。
 高 rps の BFF サーバーはこの手順でやるにはリスクが高いので、トラフィックのミラーリングを実施して Gateway と Kubernetes クラスター全体の状態を確認していきます。
-[アクセスログ](/docs/05/ingress-gateway/)で紹介したようにPodにログ出力のための`nginx`が含まれるため、二重計上されないために`NodePort`を`istio-proxy`に向けたものをミラーリングのためのポートとして提供しています。
-nginxのミラーリングによって高rpsの時間変化がDataDogに蓄積され、そこから[対応表](/docs/07/horizontal-pod-autoscaler/#リソースの値をどうやって決めるか)を用いてリソースの逆算を実施し、移行フェーズへステップを進めることができました。
+[アクセスログ](../../service-mesh/access-log)で紹介したようにPodにログ出力のための`nginx`が含まれるため、二重計上されないために`NodePort`を`istio-proxy`に向けたものをミラーリングのためのポートとして提供しています。
+nginxのミラーリングによって高rpsの時間変化がDataDogに蓄積され、そこから[対応表](../../scalability/horizontal-pod-autoscaler/#リソースの値をどうやって決めるか)を用いてリソースの逆算を実施し、移行フェーズへステップを進めることができました。
 
-[![リクエストのミラーリング概略図](../../performance/mirroring.svg)](/docs/08/loadtest/#proxyからリクエストをmirroringする)
+[![リクエストのミラーリング概略図](../../performance/mirroring.svg)](../../performance/load-test/#proxyからリクエストをmirroringする)
 
 ## ロールバック設計
 
@@ -74,7 +74,7 @@ Manifestにアプリケーションのルーティングの仕様が明示的に
 しかしながら、高頻度で更新されるアプリケーションはこれが手間であるため、Slackからリリースに必要な準備一式が整うように調整しました。
 
 Docker Swarmからのデプロイ手順はSlack上でコマンドを打つことで準備ができるようになり、
-Kubernetesどころかリポジトリそのものを意識することが減りました。より詳細は[Slack Botによる自動化](/docs/04/slack-bot/)に書いています。
+Kubernetesどころかリポジトリそのものを意識することが減りました。より詳細は[Slack Botによる自動化](../../ci/slack-bot)に書いています。
 
 ## まとめ
 

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に関して](/docs/06/)
-* [Istio Ingress Gatewayに関して](/docs/05/ingress-gateway/)
-* [アクセスログに関して](/docs/05/ingress-gateway/)
+* [Rate Limitに関して](../rate-limit/global-ratelimit)
+* [Istio Ingress Gatewayに関して](../service-mesh/istio-ingress-gateway)
+* [アクセスログに関して](../service-mesh/access-log)
 
 ## Apacheを移行時のロードバランサーとして選定した理由
 

content/docs/performance/load-test.md

@@ -28,7 +28,7 @@ Docker SwarmからKubernetesに移行するにあたり、移行前のスペッ
 これらの情報を元に、常設のreplicasの見積りや、Horizontal Pod AutoscalerのためのCPUのlimit設定、
 共倒れを防ぐためのRate Limit設定を割り出していきます。
 
-合わせて[リソースの値をどうやって決めるか](/docs/07/horizontal-pod-autoscaler/#リソースの値をどうやって決めるか)を確認してみてください。
+合わせて[リソースの値をどうやって決めるか](../../scalability/horizontal-pod-autoscaler/#リソースの値をどうやって決めるか)を確認してみてください。
 
 ## 試験方法
 

content/docs/rate-limit/local-ratelimit.md

@@ -8,7 +8,7 @@ description: PodのサイドカーでRate Limitを実施することにより、
 
 **Global RateLimitとの違い**
 
-Local RateLimitと[Global RateLimit](/docs/06/global-ratelimit/)の違いは守るスコープの違いにあります。
+Local RateLimitと[Global RateLimit](../../rate-limit/global-ratelimit)の違いは守るスコープの違いにあります。
 Global RateLimitはUpstream側のシステムを守るため、RateLimitのマイクロサービス間でリクエスト数を共有するためのストア(redisなど)を外側に持っています。
 それに対し、Local RateLimitはRateLimitを提供するProxyだけがリクエスト数を保持でいればよいためインメモリーで実装することができます。
 
@@ -108,5 +108,5 @@ http {
 ## 今後どうするか
 
 Podを構成する要素としてProxyが2段構えになっているのは多少格好は悪いですが、うまく機能しています。
-ただし、後述しますが、envoyやnginxのRateLimitでは[負荷の上昇を防げないパターン問題点](/docs/06/ratelimit-is-unless/)もあります。
+ただし、後述しますが、envoyやnginxのRateLimitでは[負荷の上昇を防げないパターン問題点](../../rate-limit/ratelimit-is-unless)もあります。
 アクセス傾向やPodのMetricsなどを総合的に鑑みてRate Limitの構成と設定値を決めていく必要があります。

content/docs/scalability/horizontal-pod-autoscaler.md

@@ -72,10 +72,10 @@ BFFを含むPodの大きな特徴として、
 途中で比例グラフが破綻するか、正常レスポンスを返せなくなるところがあります。
 図中の`Pod Performance Limit`はこれを示しています。
 
-また、([Global](/docs/06/global-ratelimit/) / [Local](/docs/06/local-ratelimit/)) Rate Limitで流量制御はPodが`Pod Performance Limit`のrpsよりも低く、
+また、([Global](../../rate-limit/global-ratelimit) / [Local](../../rate-limit/local-ratelimit)) Rate Limitで流量制御はPodが`Pod Performance Limit`のrpsよりも低く、
 HPAが発動するRPSよりも大きく指定する必要があります。
 
-これらの値を決定するためには[負荷試験](/docs/08/loadtest/)を実施することで値を予測することが可能になります。
+これらの値を決定するためには[負荷試験](../../performance/load-test)を実施することで値を予測することが可能になります。
 
 ## バースト性のあるリクエストをどうやって耐えるか
 

content/docs/service-mesh/access-log.md

@@ -283,7 +283,7 @@ spec:
 `/tmp/sidecar-nginx`に対してUnix Socket用のEmpty Directoryを作成し、Pod内でシェアすることでPodとして見たときにポータビリティが確保できます。
 
 IstioOperatorで新しくContainerやVolumeを追加する場合は現状 `k8s.overlays` で頑張って追加するしかありませんが、
-[ManifestをTypeScriptで管理](/docs/03/kubernetes-manifest-written-by-typescript/)しているため、管理が難しいなどの問題は発生しませんでした。
+[ManifestをTypeScriptで管理](../../manifest/kubernetes-manifest-written-by-typescript)しているため、管理が難しいなどの問題は発生しませんでした。
 
 ただしバージョンアップに伴ってIstioOperatorが作成するIngressGatewayのDeploymentを確認する必要があります。
 早々バージョン更新の頻度は高くないので、バージョン更新後の検証と同時にやっても問題ないでしょう。

content/docs/service-mesh/istio.md

@@ -23,7 +23,7 @@ Istio のコンポーネント紹介します。
 
 Envoyはそれ自体がProxyであり、nginxやApacheなどのL7 LBと似たような機能を提供しています。
 大きな違いとして、Envoy はテレメトリが標準で豊富だったり、APIによる構成変更が可能だったりプログラマブルにコントロールできる機能を豊富に持っています。
-すなわち再起動をせずに構成変更が容易であり、[Argo RolloutsのCanary Deploy](/docs/04/argo-rollouts/#canary-deployを実施する)で紹介したように Traffic Weight を柔軟に変更することが可能になります。
+すなわち再起動をせずに構成変更が容易であり、[Argo RolloutsのCanary Deploy](../../ci/argo-rollouts/#canary-deployを実施する)で紹介したように Traffic Weight を柔軟に変更することが可能になります。
 
 IstioはこのEnvoyを利用して、Kubernetes上で稼働するマイクロサービス間の通信を観測するために Control Plane から各 Pod に Sidecar として注入します。
 Istioから提供されているEnvoyのDocker Imageは`istio-proxy`という名前で提供されており、`kubectl get pod [podname]`などで構成を確認すると`istio-proxy`という名前を確認することができます。
@@ -84,7 +84,7 @@ kubectl get deployment -n istio-operator -l operator.istio.io/component=IstioOpe
 kubectl set env deployment/istio-operator-1-11-4 WATCH_NAMESPACE="istio-system,myteam" -n istio-operator
 ```
 
-Ingress Gatewayの具体的な設定は[次の節](/docs/05/traffic-management/)で紹介しています。
+Ingress Gatewayの具体的な設定は[次の節](../../service-mesh/traffic-management)で紹介しています。
 
 ## istio-proxyのサイドカーが不要なケース
 
@@ -118,4 +118,4 @@ BFFはその特性上、各マイクロサービスから情報をかき集め
 特定のバージョンから悪化しているのであればロールバックを実行したり、
 Client Side Rendering可能な情報であれば最初のHTMLを構成するためのクリティカルパスから除外したりすることが可能です。
 少なくとも、継続的な監視は問題を明確にし、物事の優先度を合理的に決定することができます。
-[負荷試験](/docs/08/loadtest/)や[モニタリング](/docs/08/monitoring/)の節で具体的なMetricsの可視化を紹介しています。
+[負荷試験](../../performance/load-test)や[モニタリング](../../performance/monitoring)の節で具体的なMetricsの可視化を紹介しています。