[ja] Enable link checking, and normalize links, add missing (#3205)

Signed-off-by: Junya Okabe <[email protected]>

Author: Okabe-Junya

.htmltest.yml

@@ -3,6 +3,6 @@ DirectoryPath: public
 # IgnoreDirectoryMissingTrailingSlash: true # FIXME
 IgnoreInternalEmptyHash: true # FIXME
 IgnoreDirs:
-  - ^(bn|de|es|fr|hi|it|ja|ko|pt.*?|ru|tr|ur|zh.*?)/
+  - ^(bn|de|es|fr|hi|it|ko|pt.*?|ru|tr|ur|zh.*?)/
 IgnoreURLs: # list of regexs of paths or URLs to be ignored
   - ^/pagefind

content/ja/chaos-engineering.md

@@ -12,7 +12,7 @@ tags: ["方法論", "", ""]
 
 [SRE](/ja/site-reliability-engineering/)や[DevOps](/ja/devops/)の実践は、プロダクトの回復力と[信頼性](/ja/reliability/)を高める技術に焦点を当てています。
 システムが障害を許容しつつ適切なサービス品質を保証する能力は、通常のソフトウェア開発の要件です。
-インフラストラクチャ、プラットフォーム、あるいは([マイクロサービス](/ja/microservices-architecture)ベースの)アプリケーションの他の動作部分のように、アプリケーションの停止につながる可能性のある複数の側面が関与しています。
+インフラストラクチャ、プラットフォーム、あるいは([マイクロサービス](/ja/microservices-architecture/)ベースの)アプリケーションの他の動作部分のように、アプリケーションの停止につながる可能性のある複数の側面が関与しています。
 本番環境に新機能を高頻度でデプロイすることは、高い確率でダウンタイムと重大なインシデントをもたらし、ビジネスに重大な影響を及ぼす可能性があります。
 
 ## どのように役に立つのでしょうか

content/ja/container-orchestration.md

@@ -4,14 +4,14 @@ status: Completed
 category: コンセプト
 ---
 
-[コンテナ](/ja/container/)オーケストレーションとは、流動的な環境において、[コンテナ化](/ja/containerization)されたアプリケーションのライフサイクルを管理し自動化することを指します。
-これはコンテナオーケストレータ(ほとんどの場合は[Kubernetes](/ja/kubernetes))を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。
+[コンテナ](/ja/container/)オーケストレーションとは、流動的な環境において、[コンテナ化](/ja/containerization/)されたアプリケーションのライフサイクルを管理し自動化することを指します。
+これはコンテナオーケストレータ(ほとんどの場合は[Kubernetes](/ja/kubernetes/))を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。
 オーケストレーションという言葉は比喩です。
 オーケストレーションツールは、音楽指揮者のようにコンテナを指揮し、すべてのコンテナ(または音楽家)が適切に機能するようにします。
 
 ## 解決すべき問題は何ですか
 
-スケールに応じて[マイクロサービス](/ja/microservices-architecture)、セキュリティ、ネットワーク通信や一般的な[分散システム](/ja/distributed-systems)を管理することは、手動で行うには難しく、場合によっては不可能です。
+スケールに応じて[マイクロサービス](/ja/microservices-architecture/)、セキュリティ、ネットワーク通信や一般的な[分散システム](/ja/distributed-systems/)を管理することは、手動で行うには難しく、場合によっては不可能です。
 コンテナオーケストレーションにより、これらすべての管理タスクを自動化することができます。
 
 ## どのように役に立つのでしょうか

content/ja/containerization.md

@@ -11,7 +11,7 @@ tags: ["アプリケーション", "", ""]
 
 ## 解決すべき問題は何ですか
 
-[コンテナ](/ja/container)が普及する前は、組織は仮想マシン(VM)に依存して、単一の[ベアメタルマシン](/ja/bare-metal-machine/)上で複数のアプリケーションをオーケストレーションしていました。
+[コンテナ](/ja/container/)が普及する前は、組織は仮想マシン(VM)に依存して、単一の[ベアメタルマシン](/ja/bare-metal-machine/)上で複数のアプリケーションをオーケストレーションしていました。
 VMはコンテナよりも非常に大きく、実行にはハイパーバイザーが必要です。
 これらの大きなVMテンプレートのストレージ、バックアップ、転送により、VMテンプレートの作成もより遅くなります。
 さらに、VMは[不変性](/ja/immutable-infrastructure/)の原則に反する構成ドリフトに悩まされることがあります。

content/ja/horizontal-scaling.md

@@ -9,7 +9,7 @@ tags: ["インフラストラクチャ", "", ""]
 個別の[ノード](/ja/nodes/)により多くの計算リソースを追加する手法とは異なります(後者は[垂直スケーリング](/ja/vertical-scaling/)として知られています)。
 たとえば、RAM容量4GBのシステムを持っていて、そのRAMを16GBに増やしたい場合、水平スケーリングはRAM 16GBのシステムに切り替えるのではなく、RAM 4GBのマシン4台で対応します。
 
-このアプローチは、新しいインスタンスまたは[ノード](/ja/nodes)を追加することで、負荷をより効果的に分散し、アプリケーションのパフォーマンスを向上させます。
+このアプローチは、新しいインスタンスまたは[ノード](/ja/nodes/)を追加することで、負荷をより効果的に分散し、アプリケーションのパフォーマンスを向上させます。
 簡単に言えば、個別のサーバーの処理能力を強化することではなく、個別のサーバーの負荷を減らすことを目指しています。
 
 ## 解決すべき問題はなんですか

content/ja/loosely-coupled-architecture.md

@@ -6,7 +6,7 @@ tags: ["基礎", "アーキテクチャ", "プロパティ"]
 ---
 
 疎結合アーキテクチャは、アプリケーションの構成要素それぞれが互いに独立して構築されるようなアーキテクチャです(その逆は[密結合アーキテクチャ](/ja/tightly-coupled-architecture/)と呼ばれます)。
-[マイクロサービス](/ja/microservice/)とよく呼ばれる個々の構成要素は、その他多くのサービスから利用できるような方法で、特定の機能を果たすよう構築されます。
+[マイクロサービス](/ja/microservices-architecture/)とよく呼ばれる個々の構成要素は、その他多くのサービスから利用できるような方法で、特定の機能を果たすよう構築されます。
 疎結合アーキテクチャは密結合アーキテクチャより一般的に実装が遅くなりますが、特にアプリケーションがスケールする際に多くの利点があります。
 
 アプリケーションが疎結合だと、チームは独立して機能開発、デプロイ、スケールすることが可能です。

content/ja/stateful-apps.md

@@ -10,7 +10,7 @@ tags: ["基礎", "アプリケーション", "プロパティ"]
 
 今日、私たちが使用するほとんどのアプリケーションは少なくとも部分的にステートフルです。
 しかし、クラウドネイティブ環境では、ステートフルアプリは難しいです。
-これは、[クラウドネイティブアプリ](/ja/cloud-native-apps)が非常に動的だからです。
+これは、[クラウドネイティブアプリ](/ja/cloud-native-apps/)が非常に動的だからです。
 これらはスケーリング、再起動、別の場所への移動が可能ですが、それでもそのステートにアクセスできる必要があります。
 
 そのため、ステートフルアプリには、データベースのようにどこからでもアクセス可能な何らかのストレージが必要です。

content/ja/tightly-coupled-architecture.md

@@ -12,5 +12,5 @@ tags: ["基礎", "アーキテクチャ", "プロパティ"]
 また、しばしば構成要素を協調してロールアウトする必要が生じるため、開発者の生産性に対する足かせとなる可能性があります。
 
 密結合なアプリケーションアーキテクチャはかなり古典的なアプリケーション構築方法です。
-[マイクロサービス](/ja/microservices/)開発のベストプラクティス全てには必ずしも整合しませんが、密結合アーキテクチャは特定の場合に有用です。
+[マイクロサービス](/ja/microservices-architecture/)開発のベストプラクティス全てには必ずしも整合しませんが、密結合アーキテクチャは特定の場合に有用です。
 密結合アーキテクチャでの開発は、実装がより簡潔で早くなる傾向があり、[モノリシックアプリケーション](/ja/monolithic-apps/)とよく似て初期開発サイクルを加速させる可能性があります。