Merge pull request #2872 from cncf/dev-ja

seokho-son · web-flow · commit 4812a5fb1068 · 2024-02-14T11:45:37.000+09:00
Merge dev-ja into main (for the second Japanese localization live version)
diff --git a/content/ja/_index.md b/content/ja/_index.md
@@ -29,21 +29,24 @@ status: Completed
 [Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), 
 [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), 
 [Katelin Ramer](https://www.linkedin.com/in/katelinramer/), 
-[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), 
+[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca)
 その他多くの貢献者による貢献が含まれています。
 全ての貢献者リストについては、[GitHub page](https://github.com/cncf/glossary/graphs/contributors) を参照してください。
 
 用語集は 
-[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/)、
-[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/)、
-[Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/)、
-[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/)、
-そして [Seokho Son](https://www.linkedin.com/in/seokho-son/)によってメンテナンスされています.
+[Seokho Son](https://www.linkedin.com/in/seokho-son/),
+[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), 
+[Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/),
+[Nate W.](https://www.linkedin.com/in/nate-double-u/)
+そして[Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/)によってメンテナンスされています。
+
+[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/)
+は名誉メンテナーであり、長年にわたる彼らの貴重な貢献に深く感謝しています。
 
 クラウドネイティブ用語集の日本語化は、[Kaito Ii](https://github.com/kaitoii11)、[Kohei Ota](https://github.com/inductor)、[Yuichi Nakamura](https://github.com/yuichi-nakamura)、[MItabashi](https://github.com/bashi8128)、[HANABE926](https://github.com/HANABE926)、[Junya Okabe](https://github.com/Okabe-Junya)、[Akira Aiura](https://github.com/A-aiura)、[shizhenhu](https://github.com/shizhenhu)、[Nao Nishijima](https://github.com/naonishijima)の貢献を通じて開始されました。
 クラウドネイティブ用語集の日本語への翻訳とローカライゼーションに興味のある方は、[#glossary-localization-japanese](https://app.slack.com/client/T08PSQ7BQ/C057F81GFUG) チャンネルにご参加ください。
 
 ## ライセンス
 
 すべてのコードの貢献はApache 2.0ライセンスに基づいています。
-ドキュメントはCC BY 4.0に基づいて配布されます。
+ドキュメントはCC BY 4.0に基づいて配布されます。
diff --git a/content/ja/agile-software-development.md b/content/ja/agile-software-development.md
@@ -0,0 +1,25 @@
+---
+title: アジャイルソフトウェア開発
+status: Completed
+category: コンセプト
+tags: ["方法論", "", ""]
+---
+
+アジャイルソフトウェア開発は、繰り返しの開発サイクルと自己組織化チームを重視する一連の実践です。
+プロジェクトの最後にのみ価値が生み出されるウォーターフォール型のプロジェクトとは対照的に、
+アジャイルソフトウェア開発は、継続的かつ段階的な価値の提供とプロセス自体の進化的な改善に焦点を当てています。
+
+## 解決すべき問題はなんですか
+
+ソフトウェアプロジェクトにおいて、すべての関係者に対して要件を定義し、それを伝え理解させることは、不可能ではないにせよ非常に難しいです。
+しかし、顧客は自分たちのソフトウェアプロジェクトが時間通りに、良い品質で、予算内で、スコープ内で届けられることを望んでいます。
+その循環的な性質により、アジャイルソフトウェア開発は要件に継続的に適応することを可能にします。
+これはウォーターフォール型の戦略とは対照的で、他のすべての状況に適応することをより迅速に行うことができます。
+
+## どのように役に立つのでしょうか
+
+アジャイルソフトウェア開発は、従来の(ウォーターフォール型の)戦略の全てのフェーズを含んでいます。
+これには要件定義、計画、実装、レビュー、テスト、納品などが含まれます。
+最大の違いは、ソフトウェアプロジェクトの全期間がイテレーションに分割され、そのそれぞれが全てのフェーズを含むことです。
+各イテレーションの後、顧客と一緒に作成された価値をレビューし、最終目標に向けて要件を調整することができます。
+さらに、開発チームはプロセス自体を改善するために取るべき行動を振り返ります。
diff --git a/content/ja/auto-scaling.md b/content/ja/auto-scaling.md
@@ -0,0 +1,27 @@
+---
+title: オートスケーリング
+status: Completed
+category: プロパティ
+tags: ["インフラストラクチャー", "", ""]
+---
+
+オートスケーリングとは、システムが自動的に[スケール](/ja/scalability/)する能力のことで、通常はコンピューティングリソースにおいて行われます。
+オートスケーリングシステムでは、必要に応じて自動的にリソースが追加され、変動するユーザーの需要に応じてスケールできます。
+オートスケーリングのプロセスは様々で、メモリーやプロセス時間などの異なるメトリクスに基づいてスケールするように設定可能です。
+マネージドクラウドサービスには通常、オートスケーリング機能が関連しています。
+これは、ほとんどのオンプレミス環境へのデプロイよりも多くのオプションと実装が利用可能であるためです。
+
+以前はインフラストラクチャーとアプリケーションが、システムのピーク使用量を考慮して設計されていました。
+このアーキテクチャにより、多くのリソースが未使用であり、消費者需要の変化に対して非弾力的でした。
+非弾力性は、ビジネスへの高コストと、過剰な需要によって発生する障害の営業損失を意味します。
+
+クラウドを活用し、アプリケーションとその依存関係を[仮想化](/ja/virtualization/)および[コンテナ化](/ja/containerization/)することで、組織はユーザーの需要に応じてスケールするアプリケーションを構築できます。
+彼らはアプリケーションの需要を監視し、自動的にスケールさせ、最適なユーザーエクスペリエンスを提供できます。
+例えば、毎週金曜日の夕方に発生する、Netflixの視聴者数の増加を考えて見てください。
+オートスケールアウトは、動的により多くのリソースを追加することを意味します。
+例えば、ビデオストリーミングのためのサーバー数を増やし、需要が正常化されたらスケールバックすることです。
+
+## 関連する用語はありますか
+
+* [水平スケーリング](/ja/horizontal-scaling/)
+* [垂直スケーリング](/ja/vertical-scaling/)
diff --git a/content/ja/continuous-delivery.md b/content/ja/continuous-delivery.md
@@ -26,7 +26,6 @@ CDは、ソフトウェアがデプロイメント前に適切にテストされ
 CD戦略は、完全に自動化された本番環境へのパスを作成し、
 [カナリア](/ja/canary-deployment/)や[ブルーグリーン](/ja/blue-green-deployment/)リリースなどの様々なデプロイメント戦略を使用してソフトウェアをテストしデプロイします。
 これにより、開発者は頻繁にコードをデプロイすることができ、新しいリビジョンがテストされていることを安心して受け入れることができます。
-通常CD戦略では、フィーチャーブランチやプルリクエストとは対照的に、トランクベースの開発を行います。
 
 ## 関連する用語はありますか
 
diff --git a/content/ja/horizontal-scaling.md b/content/ja/horizontal-scaling.md
@@ -0,0 +1,33 @@
+---
+title: 水平スケーリング
+status: Completed
+category: コンセプト
+tags: ["インフラストラクチャー", "", ""]
+---
+
+水平スケーリングは、より多くのノードを追加することでシステムの処理能力を向上させる手法です。個別の[ノード](/ja/nodes/)により多くの計算リソースを追加する手法とは異なります(後者は[垂直スケーリング](/ja/vertical-scaling/)として知られています)。
+たとえば、RAM容量4GBのシステムを持っていて、そのRAMを16GBに増やしたい場合、水平スケーリングはRAM 16GBのシステムに切り替えるのではなく、RAM 4GBのマシン4台で対応します。
+
+このアプローチは、新しいインスタンスまたは[ノード](/ja/nodes)を追加することで、負荷をより効果的に分散し、アプリケーションのパフォーマンスを向上させます。
+簡単に言えば、個別のサーバーの処理能力を強化することではなく、個別のサーバーの負荷を減らすことを目指しています。
+
+## 解決すべき問題はなんですか
+
+アプリケーションに対する需要がそのアプリケーションインスタンスの現在の処理能力を超えた場合、システムに処理能力を[スケール](/ja/scalability/)する(処理能力を向上させる)方法が必要になります。
+
+
+システムにノードを追加する(水平スケーリング)か、既存のノードにより多くの計算リソースを追加する(垂直スケーリング)かのいずれかが可能です。
+
+## どのように役に立つのでしょうか
+
+水平スケーリングにより、アプリケーションは基礎となるクラスターが提供する限界までスケールすることができます。
+
+システムにより多くのインスタンスを追加することで、アプリケーションはより多くのリクエストを処理することができます。
+
+例えば、1つのノードが1秒あたり1,000リクエストを処理できるとすると、ノードを1つ追加するごとに、システム全体で1秒あたり処理できる総リクエストが約1,000リクエスト増えることになります。
+これにより、アプリケーションは特定のノードの処理能力を強化することなく、より多くの処理を同時に行うことができます。
+
+## 関連する用語はありますか
+
+* [垂直スケーリング](/ja/vertical-scaling/)
+* [オートスケール](/ja/auto-scaling/)
diff --git a/content/ja/immutable-infrastructure.md b/content/ja/immutable-infrastructure.md
@@ -0,0 +1,18 @@
+---
+title: イミュータブルインフラストラクチャー
+status: Completed
+category: プロパティ
+tags: ["インフラストラクチャー", "プロパティ", ""]
+---
+
+イミュータブルインフラストラクチャーとは、一度デプロイされると変更することができないコンピューターインフラストラクチャー([仮想マシン](/ja/virtual-machine/)や[コンテナ](/ja/container/)、ネットワーク機器)を指します。
+これは許可されていない変更を自動的に上書きするプロセスや、最初から変更を許可しないシステムによって強制されます。
+コンテナはイミュータブルインフラストラクチャーの良い例です。
+なぜならコンテナに永続的な変更を加えるには、新しいバージョンのコンテナを作成するか、イメージから既存のコンテナを再度作成するしかないからです。
+
+許可されていない変更の防止や特定により、イミュータブルインフラストラクチャーはセキュリティリスクの特定と軽減を容易にします。
+このようなシステムの運用ははるかに簡単になります。
+なぜなら、管理者がそれについての前提を立てやすくなるためです。
+結局のところ、誰も間違いを犯していないことや、伝え忘れた変更を行っていないことが分かっています。
+イミュータブルインフラストラクチャーは[Infrastructure as Code](/ja/infrastructure-as-code/)と密接に関連しており、インフラストラクチャーを作成するために必要なすべての自動化がバージョン管理(たとえばGit)されています。
+この不変性とバージョン管理の組み合わせにより、システムへのすべての許可された変更に対して、耐久性のある監査ログが存在します。
diff --git a/content/ja/infrastructure-as-code.md b/content/ja/infrastructure-as-code.md
@@ -0,0 +1,22 @@
+---
+title: Infrastructure as Code (IaC)
+status: Completed
+category: コンセプト
+tags: ["インフラストラクチャー", "方法論", ""]
+---
+
+Infrastructure as Codeは、インフラストラクチャーの定義を一つあるいは複数のファイルで保存する実践を指します。
+これは、通常はシェルスクリプトや他の設定ツールを用いたInfrastructure as a Serviceを手動でプロビジョニングする従来のモデルに代わるものです。
+
+## 解決すべき問題はなんですか
+
+クラウドネイティブな方法でアプリケーションを構築するには、インフラストラクチャーを使い捨てできるようにし、かつ再現可能にする必要があります。
+また自動化された繰り返し可能な方法で、人の手が介入することなくオンデマンドに[スケール](/ja/scalability/)する必要があります。
+手動でのプロビジョニングは、[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)の応答性とスケーラビリティを満たすことができません。
+手動でのインフラストラクチャーの変更は再現不可能で、すぐにスケールの限界に達し、設定ミスのエラーを引き起こします。
+
+## どのように役に立つのでしょうか
+
+サーバー、ロードバランサー、サブネットのようなデータセンターのリソースをコードとして表現することで、インフラチームはすべての設定について単一の正しい情報源を持つことができます。
+また、[CI](/ja/continuous-integration/)/[CD](/ja/continuous-delivery/)パイプラインでデータセンターを管理することができます。
+これにより、バージョン管理とデプロイメント戦略を実装することができます。
diff --git a/content/ja/ingress.md b/content/ja/ingress.md
@@ -0,0 +1,39 @@
+---
+title: Ingress
+status: Completed
+category: テクノロジー
+tags: ["基礎"]
+---
+
+Ingressは、クラスター内で動作するコンテナあるいはコンテナ群への外部からのインターネットトラフィックを管理するためのルールセットです。
+これにはIngressリソースとIngressコントローラーという二つの要素があります。
+Ingressリソースは、他のマニフェストファイルと共に存在する設定ファイルで、
+管理者が外部からのトラフィックのルーティングを設定することを可能にします。
+Ingressコントローラーは、実際にIngressリソースの設定に従ってトラフィックをルーティングするウェブサーバー技術です。
+
+## 解決すべき問題は何ですか
+
+クラウドネイティブのウェブアプリケーションは複数のサービスで構成されており、しばしば、
+それらの[サービス](/ja/service/)は、ブラウザを使用してユーザーがインターネット経由でアクセスする必要があります。
+これらのサービスをユーザーがアクセスできるようにしながら、
+このアプリケーションを実行するために[Kubernetes](/ja/kubernetes/)を使用する場合、
+各アプリケーションサービスを全世界に向けて公開する必要があります。
+最も簡単な方法は、KubernetesのLoad Balancer Serviceを使用することです。
+しかし、このようなサービスを作成すると、基盤となるインフラストラクチャー上に新たなコンポーネントが生まれます。
+これは新しいコストと管理のオーバーヘッドを導入するだけでなく、新しく作成された各ロードバランサーには独自の外部IPアドレスがあります。
+これは悪いユーザーエクスペリエンスにつながります。
+なぜならユーザーは、アプリケーションにアクセスするために異なるURLをブラウズしたくないからです。
+
+## どのように役に立つのでしょうか
+
+Ingressリソースを使用すると、アプリケーションのサービスへのトラフィックのバランスとルーティング方法を設定できます。
+Ingressコントローラーは、URLを通じて単一のエントリポイント(例: www.example-url.com)を公開し、
+異なるURLパス(例: www.example-url.com/path)に基づいて実際のルーティングとバランシングを行います。
+Ingressコントローラーは、クラスター内で動作するコンポーネントであり、Ingressリソースで定義されたルールを解釈します。
+ウェブアプリが動作するクラスターの運用者が、
+Nginx、Traefik、HAProxyなどの使用可能な技術セットから特定のIngressコントローラーを選択することができます。
+それにより、アプリケーションが複数のサービスで構成されている場合、ユーザーは単一のURLを使用してアクセスできます。
+これは、インフラストラクチャーレベルで数多くの個別のロードバランサーが不要になり、
+各サービスのファイアウォールとロードバランサーのルールの設定が容易になります。
+トラフィックのルーティングと設定の取り扱いを一元化することで、Ingressはスケーラビリティの効率化を提供し、
+リソース利用を最適化し、コストを削減し、クラスター内で実行されるアプリケーションの全体的な管理のしやすさを向上させます。
diff --git a/content/ja/portability.md b/content/ja/portability.md
@@ -0,0 +1,14 @@
+---
+title: 可搬性
+status: Completed
+category: プロパティ
+tags: ["基礎", "プロパティ", ""]
+---
+
+ソフトウェアの特性である可搬性は、再利用性の一つの形態です。
+クラウドプロバイダー、オペレーティングシステムやベンダーなどの特定の運用環境へのロックインを避けるのに役立ちます。
+
+伝統的に、ソフトウェアは特定の環境(例えばAWSやLinux)向けに構築されがちです。
+一方、ポータブルなソフトウェアは、大規模な作業を必要とせずに、異なる運用環境で機能します。
+アプリケーションがポータブルであるとは、新しい環境に適応させるために要求される労力が合理的な範囲内であることを指します。
+「ポートする」というフレーズは、ソフトウェアを修正しそれを異なるコンピューターシステム上で動作可能にすることを意味します。
diff --git a/content/ja/runtime.md b/content/ja/runtime.md
diff --git a/content/ja/service-mesh.md b/content/ja/service-mesh.md
diff --git a/content/ja/stateless-apps.md b/content/ja/stateless-apps.md
diff --git a/content/ja/transport-layer-security.md b/content/ja/transport-layer-security.md
