From 88e61cdad41f0b45ee8d7be5e906d960e8f9fced Mon Sep 17 00:00:00 2001 From: Junya Okabe Date: Sat, 20 Jan 2024 04:53:21 +0900 Subject: [PATCH 01/15] feat: translate stateless-apps.md into Japanese Signed-off-by: Junya Okabe --- content/ja/stateless-apps.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 content/ja/stateless-apps.md diff --git a/content/ja/stateless-apps.md b/content/ja/stateless-apps.md new file mode 100644 index 0000000000..31ddb6af13 --- /dev/null +++ b/content/ja/stateless-apps.md @@ -0,0 +1,14 @@ +--- + title: ステートレスアプリケーション + status: Completed + category: プロパティ + tags: ["基礎", "アプリケーション", "プロパティ"] +--- + +ステートレスアプリケーションは、送信される各リクエストをそれが初めて送信されたかのように処理します。 +このアプリは以前の相互通信やユーザーセッションデータを覚えていません。 +以前の相互通信からのデータはステートと呼ばれ、そのデータがどこにも保存されていないため、これらのアプリはステートレスです。 +例を挙げると、検索エンジンを使用していて、その検索が中断された場合(例えばウィンドウを閉じた場合)その検索結果は失われます。 +最初からやり直す必要があります。 + +一方、以前の相互通信を考慮しながらリクエストを処理するアプリケーションは[ステートフルアプリケーション](/ja/stateful-apps/)と呼ばれます。 From 9f0cdbcf75fff3d25d179a75dcc45333c946d513 Mon Sep 17 00:00:00 2001 From: Junya Okabe Date: Sat, 20 Jan 2024 04:55:22 +0900 Subject: [PATCH 02/15] del: unnecessary empty Signed-off-by: Junya Okabe --- content/ja/stateless-apps.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/stateless-apps.md b/content/ja/stateless-apps.md index 31ddb6af13..fccdd09069 100644 --- a/content/ja/stateless-apps.md +++ b/content/ja/stateless-apps.md @@ -1,8 +1,8 @@ --- - title: ステートレスアプリケーション - status: Completed - category: プロパティ - tags: ["基礎", "アプリケーション", "プロパティ"] +title: ステートレスアプリケーション +status: Completed +category: プロパティ +tags: ["基礎", "アプリケーション", "プロパティ"] --- ステートレスアプリケーションは、送信される各リクエストをそれが初めて送信されたかのように処理します。 From bca1f3e68aed6b116afaf758e4ebd084a1cd321a Mon Sep 17 00:00:00 2001 From: Junya Okabe Date: Mon, 29 Jan 2024 16:17:48 +0900 Subject: [PATCH 03/15] fix: ja/_index.md Signed-off-by: Junya Okabe --- content/ja/_index.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/content/ja/_index.md b/content/ja/_index.md index 5d875efdc0..cfb97904c7 100755 --- a/content/ja/_index.md +++ b/content/ja/_index.md @@ -29,16 +29,19 @@ 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) チャンネルにご参加ください。 @@ -46,4 +49,4 @@ status: Completed ## ライセンス すべてのコードの貢献はApache 2.0ライセンスに基づいています。 -ドキュメントはCC BY 4.0に基づいて配布されます。 \ No newline at end of file +ドキュメントはCC BY 4.0に基づいて配布されます。 From a67ba627711a4a59fed53b4ceb2116ea56c779b4 Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Wed, 31 Jan 2024 21:16:51 +0900 Subject: [PATCH 04/15] [ja] Localize Service Mesh for Japanese (#2798) Signed-off-by: Junya Okabe Signed-off-by: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> --- content/ja/service-mesh.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 content/ja/service-mesh.md diff --git a/content/ja/service-mesh.md b/content/ja/service-mesh.md new file mode 100644 index 0000000000..cd8c26398a --- /dev/null +++ b/content/ja/service-mesh.md @@ -0,0 +1,26 @@ +--- +title: サービスメッシュ +status: Completed +category: テクノロジー +tags: ["ネットワーキング", "", ""] +--- + +[マイクロサービス](/ja/microservices-architecture/)の世界では、アプリケーションは複数の小さな[サービス](/ja/service/)に分割され、それらがネットワークを介して通信します。 +あなたのWi-Fiネットワークのように、コンピューターネットワークは本質的には信頼性が低く、ハッキングされやすく、しばしば遅いものです。 +サービスメッシュは、サービス間のトラフィック(すなわち通信)を管理することによって、この新しい課題に対処します。 +サービスメッシュは、すべてのサービスにわたって[信頼性](/ja/reliability/)、[可観測性](/ja/observability/)、およびセキュリティ機能を均一に追加します。 + +## 解決すべき問題はなんですか + +マイクロサービスアーキテクチャに移行したことで、エンジニアは数百、 +場合によっては数千ものサービスを扱うようになり、それらすべてが相互に通信を必要としています。 +つまり、ネットワーク上で大量のトラフィックが行き交っています。 +その上、個々のアプリケーションは、必須の要件をサポートするために通信を暗号化する必要があるかもしれません。 +あるいは運用チームに共通のメトリクスを提供する必要があるかもしれませんし、問題の診断に役立つ、トラフィックに関する詳細な洞察を提供する必要があるかもしれません。 +これらの機能が個々のアプリケーションに組み込まれている場合、それぞれがチーム間の摩擦を引き起こし、新機能の開発を遅らせる原因となります。 + +## どのように役に立つのでしょうか + +サービスメッシュは、コードの変更を必要とせずに、クラスタ全体のすべてのサービスに対して、 +信頼性、可観測性、およびセキュリティ機能を均一に追加します。 +サービスメッシュが登場する前は、その機能をすべての個々のサービスに組み込む必要があり、バグや技術的負債の潜在的な原因となっていました。 From 25421cf5411736778f04c5ecd09fda69fef88621 Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Wed, 31 Jan 2024 21:35:18 +0900 Subject: [PATCH 05/15] [ja] Localize Agile Software Development into Japanese (#2828) Signed-off-by: Junya Okabe Signed-off-by: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Co-authored-by: Kaito Ii --- content/ja/agile-software-development.md | 25 ++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 content/ja/agile-software-development.md diff --git a/content/ja/agile-software-development.md b/content/ja/agile-software-development.md new file mode 100644 index 0000000000..98adba0bf2 --- /dev/null +++ b/content/ja/agile-software-development.md @@ -0,0 +1,25 @@ +--- +title: アジャイルソフトウェア開発 +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +アジャイルソフトウェア開発は、繰り返しの開発サイクルと自己組織化チームを重視する一連の実践です。 +プロジェクトの最後にのみ価値が生み出されるウォーターフォール型のプロジェクトとは対照的に、 +アジャイルソフトウェア開発は、継続的かつ段階的な価値の提供とプロセス自体の進化的な改善に焦点を当てています。 + +## 解決すべき問題はなんですか + +ソフトウェアプロジェクトにおいて、すべての関係者に対して要件を定義し、それを伝え理解させることは、不可能ではないにせよ非常に難しいです。 +しかし、顧客は自分たちのソフトウェアプロジェクトが時間通りに、良い品質で、予算内で、スコープ内で届けられることを望んでいます。 +その循環的な性質により、アジャイルソフトウェア開発は要件に継続的に適応することを可能にします。 +これはウォーターフォール型の戦略とは対照的で、他のすべての状況に適応することをより迅速に行うことができます。 + +## どのように役に立つのでしょうか + +アジャイルソフトウェア開発は、従来の(ウォーターフォール型の)戦略の全てのフェーズを含んでいます。 +これには要件定義、計画、実装、レビュー、テスト、納品などが含まれます。 +最大の違いは、ソフトウェアプロジェクトの全期間がイテレーションに分割され、そのそれぞれが全てのフェーズを含むことです。 +各イテレーションの後、顧客と一緒に作成された価値をレビューし、最終目標に向けて要件を調整することができます。 +さらに、開発チームはプロセス自体を改善するために取るべき行動を振り返ります。 From 9d206fcf573c70fa1b5e8c18dec2b912818a2c7b Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Wed, 31 Jan 2024 21:48:09 +0900 Subject: [PATCH 06/15] [ja] Localize Immutable Infrastructure into Japanese (#2857) Signed-off-by: Junya Okabe Signed-off-by: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> --- content/ja/immutable-infrastructure.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 content/ja/immutable-infrastructure.md diff --git a/content/ja/immutable-infrastructure.md b/content/ja/immutable-infrastructure.md new file mode 100644 index 0000000000..c6347009b2 --- /dev/null +++ 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)されています。 +この不変性とバージョン管理の組み合わせにより、システムへのすべての許可された変更に対して、耐久性のある監査ログが存在します。 From b6ca2bac44522a7f1767fc7ccc57038355217126 Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Thu, 1 Feb 2024 14:54:33 +0900 Subject: [PATCH 07/15] [ja] Localize Runtime into Japanese (#2861) Signed-off-by: Junya Okabe Signed-off-by: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> --- content/ja/runtime.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 content/ja/runtime.md diff --git a/content/ja/runtime.md b/content/ja/runtime.md new file mode 100644 index 0000000000..2c4bae31e8 --- /dev/null +++ b/content/ja/runtime.md @@ -0,0 +1,37 @@ +--- +title: ランタイム +status: Completed +category: コンセプト +tags: ["アプリケーション", "", ""] +--- + +一般的に、ランタイムはソフトウェアの一部を実行します。 +これは、プログラムのコマンドをオペレーティングシステムのアクションに変換する、下層レイヤーとなるオペレーティングシステムの[抽象化](/ja/abstraction/)です。 + +[クラウドネイティブ](/ja/cloud-native-apps/)の文脈では、_ランタイム_ は一般的にコンテナランタイムを指します。 +コンテナランタイムは、[Open Container Initiative](https://opencontainers.org/)の仕様を具体的に実装します。 +これは異なるコンテナオーケストレーション技術の間で一貫した取り扱いを保証するためです。 + +## 解決すべき問題はなんですか + +コンテナランタイムの抽象化がなければ、アプリケーションは各オペレーティングシステムのすべての技術を取り扱う必要があります。 +結果としてアプリの実行の複雑さが増します。 + +## どのように役に立つのでしょうか + +コンテナランタイムは、Kubernetesのようなコンテナオーケストレーターに必要なコンポーネントです。 +これらは主に3つのことを行う、コンテナライフサイクルを処理します。 +まずコンテナイメージがどのように指定され、ランタイムがそれらをどのように取得するかを定義します。 +次にこれらのイメージがどのように展開、レイヤー化、マウント、実行されるかを扱います。 +さらにランタイムは、これらのオペレーティングシステムレベルのアクションの面倒を見ることで、ハードウェアリソースを管理します。 +これにはリソースの割り当てと隔離が含まれます。 +時間が経つにつれて、さまざまなコンテナランタイム製品が進化し、OCIの仕様がコンテナランタイムの標準となりました。 + +この標準を導入することにより、エンドユーザーは任意のOCIに準拠したランタイムを、任意のOCIに準拠したコンテナオーケストレーター(例えばKubernetes)と組み合わせることができます。 + +## 関連する用語はありますか + +- [クラウドネイティブ](https://glossary.cncf.io/ja/cloud-native-apps/) +- [コンテナ化](https://glossary.cncf.io/ja/containerization/) +- [コンテナオーケストレーション](https://glossary.cncf.io/ja/container-orchestration/) +- [マイクロサービスアーキテクチャ](https://glossary.cncf.io/ja/microservices-architecture/) From 1afb21296f3e23fd647b12de3ee5b1b54a321422 Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Thu, 1 Feb 2024 15:06:56 +0900 Subject: [PATCH 08/15] [Update term] Continuous Delivery for Japanese (#2879) Signed-off-by: Junya Okabe --- content/ja/continuous-delivery.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/continuous-delivery.md b/content/ja/continuous-delivery.md index 907599e3d2..bb57939168 100644 --- 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戦略では、フィーチャーブランチやプルリクエストとは対照的に、トランクベースの開発を行います。 ## 関連する用語はありますか From e03eb70d52c890ce315189d618a709d0259d7773 Mon Sep 17 00:00:00 2001 From: shizhenhu Date: Fri, 2 Feb 2024 19:18:16 +0900 Subject: [PATCH 09/15] Localize horizontal scaling for Japanese (#2890) Signed-off-by: shizhenhu --- content/ja/horizontal-scaling.md | 33 ++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 content/ja/horizontal-scaling.md diff --git a/content/ja/horizontal-scaling.md b/content/ja/horizontal-scaling.md new file mode 100644 index 0000000000..2ab37f55ad --- /dev/null +++ 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/) From 555347a2d6e2ae7b26bada35e2de7ea2aa571cd4 Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Mon, 5 Feb 2024 21:48:52 +0900 Subject: [PATCH 10/15] [ja] Localize Infrastructure as Code (IaC) into Japanese (#2892) Signed-off-by: Junya Okabe Signed-off-by: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> --- content/ja/infrastructure-as-code.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 content/ja/infrastructure-as-code.md diff --git a/content/ja/infrastructure-as-code.md b/content/ja/infrastructure-as-code.md new file mode 100644 index 0000000000..20cf537402 --- /dev/null +++ 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/)パイプラインでデータセンターを管理することができます。 +これにより、バージョン管理とデプロイメント戦略を実装することができます。 From 7c8daf2e42a1a383d503a698f0abaf17d14c99b0 Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Mon, 5 Feb 2024 22:06:18 +0900 Subject: [PATCH 11/15] [ja] Localize Autoscaling into Japanese (#2866) Signed-off-by: Junya Okabe Signed-off-by: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> --- content/ja/auto-scaling.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 content/ja/auto-scaling.md diff --git a/content/ja/auto-scaling.md b/content/ja/auto-scaling.md new file mode 100644 index 0000000000..d3371ffe38 --- /dev/null +++ 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/) From e9efaa5256d33d9964c3dc379c5f605bb60344eb Mon Sep 17 00:00:00 2001 From: Junya Okabe Date: Mon, 5 Feb 2024 23:25:20 +0900 Subject: [PATCH 12/15] feat: translate transport-layer-security.md Signed-off-by: Junya Okabe --- content/ja/transport-layer-security.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 content/ja/transport-layer-security.md diff --git a/content/ja/transport-layer-security.md b/content/ja/transport-layer-security.md new file mode 100644 index 0000000000..ae86ea7dae --- /dev/null +++ b/content/ja/transport-layer-security.md @@ -0,0 +1,23 @@ +--- +title: Transport Layer Security (TLS) +status: Completed +category: コンセプト +tags: ["セキュリティ", "ネットワーキング", ""] +--- + +Transport Layer Security (TLS)は、ネットワーク上での通信のセキュリティを高めるために設計されたプロトコルです。 +インターネット上で送信されるデータの安全な配信を保証し、データの監視や改ざんを避けることができます。 +このプロトコルは、メッセージングや電子メールなどのアプリケーションで幅広く使用されています。 + +## 解決すべき問題はなんですか + +TLSがないと、日常的なブラウジング、電子メールでのやりとり、オンラインチャット、ビデオ会議などの機密情報が、転送中に他者によって簡単に追跡され変更される可能性があります。 +サーバーとクライアントアプリケーションがTLSをサポートすることで、それらの間で転送されるデータが暗号化され、第三者によって閲覧されないことが保証されます。 + +## どのように役に立つのでしょうか + +TLSは、ネットワーク上でデータを転送する際のセキュリティを提供するために、さまざまな符号化技術を組み合わせて使用します。 +TLSにより、例えばウェブブラウザと銀行サイトのように、クライアントアプリケーションとサーバーとの間の暗号化された接続が可能になります。 +また、クライアントアプリケーションが呼び出すサーバーを正確に識別できるようになるため、クライアントが不正なサイトと通信するリスクが減少します。 +これにより、TLSを使用してアプリケーション間で転送されるデータを第三者が閲覧し、監視することができなくなります。 +結果として、クレジットカード番号、パスワード、位置情報などの機密および個人情報が保護されます。 From f05cce5cd800e471602d9bd4f67524717f07796d Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Thu, 8 Feb 2024 00:01:37 +0900 Subject: [PATCH 13/15] [ja] Localize Ingress for Japanese (#2808) Signed-off-by: Junya Okabe Signed-off-by: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> --- content/ja/ingress.md | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 content/ja/ingress.md diff --git a/content/ja/ingress.md b/content/ja/ingress.md new file mode 100644 index 0000000000..d0a54a5f5c --- /dev/null +++ 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を使用することです。 +このような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はスケーラビリティの効率化を提供し、 +リソース利用を最適化し、コストを削減し、クラスター内で実行されるアプリケーションの全体的な管理のしやすさを向上させます。 From 12c745ec58fa656c1ffd82c618c3ab1076d31b2d Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Mon, 12 Feb 2024 20:33:13 +0900 Subject: [PATCH 14/15] [ja] Localize Portability into Japanese (#2900) Signed-off-by: Junya Okabe Signed-off-by: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> --- content/ja/portability.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 content/ja/portability.md diff --git a/content/ja/portability.md b/content/ja/portability.md new file mode 100644 index 0000000000..60d8f0eb62 --- /dev/null +++ b/content/ja/portability.md @@ -0,0 +1,14 @@ +--- +title: 可搬性 +status: Completed +category: プロパティ +tags: ["基礎", "プロパティ", ""] +--- + +ソフトウェアの特性である可搬性は、再利用性の一つの形態です。 +クラウドプロバイダー、オペレーティングシステムやベンダーなどの特定の運用環境へのロックインを避けるのに役立ちます。 + +伝統的に、ソフトウェアは特定の環境(例えばAWSやLinux)向けに構築されがちです。 +一方、ポータブルなソフトウェアは、大規模な作業を必要とせずに、異なる運用環境で機能します。 +アプリケーションがポータブルであるとは、新しい環境に適応させるために要求される労力が合理的な範囲内であることを指します。 +「ポートする」というフレーズは、ソフトウェアを修正しそれを異なるコンピューターシステム上で動作可能にすることを意味します。 From 2bfeefa602ec54fce109b05223e52bf67ab3d8ef Mon Sep 17 00:00:00 2001 From: Junya Okabe <86868255+Okabe-Junya@users.noreply.github.com> Date: Mon, 12 Feb 2024 20:34:00 +0900 Subject: [PATCH 15/15] [Update term] Ingress for Japanese (#2917) Signed-off-by: Junya Okabe --- content/ja/ingress.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/ingress.md b/content/ja/ingress.md index d0a54a5f5c..76bcf38280 100644 --- a/content/ja/ingress.md +++ b/content/ja/ingress.md @@ -19,7 +19,7 @@ Ingressコントローラーは、実際にIngressリソースの設定に従っ このアプリケーションを実行するために[Kubernetes](/ja/kubernetes/)を使用する場合、 各アプリケーションサービスを全世界に向けて公開する必要があります。 最も簡単な方法は、KubernetesのLoad Balancer Serviceを使用することです。 -このようなKubernetesのLoad Balancer Serviceを作成すると、基盤となるインフラストラクチャー上に新たなコンポーネントが生まれます。 +しかし、このようなサービスを作成すると、基盤となるインフラストラクチャー上に新たなコンポーネントが生まれます。 これは新しいコストと管理のオーバーヘッドを導入するだけでなく、新しく作成された各ロードバランサーには独自の外部IPアドレスがあります。 これは悪いユーザーエクスペリエンスにつながります。 なぜならユーザーは、アプリケーションにアクセスするために異なるURLをブラウズしたくないからです。 @@ -27,7 +27,7 @@ Ingressコントローラーは、実際にIngressリソースの設定に従っ ## どのように役に立つのでしょうか Ingressリソースを使用すると、アプリケーションのサービスへのトラフィックのバランスとルーティング方法を設定できます。 -Ingressコントローラーはウェブサーバーで、URLを通じて単一のエントリポイント(例: www.example-url.com)によるアクセスを許可し、 +Ingressコントローラーは、URLを通じて単一のエントリポイント(例: www.example-url.com)を公開し、 異なるURLパス(例: www.example-url.com/path)に基づいて実際のルーティングとバランシングを行います。 Ingressコントローラーは、クラスター内で動作するコンポーネントであり、Ingressリソースで定義されたルールを解釈します。 ウェブアプリが動作するクラスターの運用者が、