Merge pull request #2969 from cncf/dev-ja

[ja] Merge dev-ja into main (for the third Japanese localization live version)

Author: seokho-son

content/ja/abstraction.md

@@ -0,0 +1,17 @@
+---
+title: 抽象化
+status: Completed
+category: プロパティ
+tags: ["基礎", "", ""]
+---
+
+コンピューティングのコンテキストでは、抽象化とは[サービス](/ja/service/)の消費者(消費者はコンピュータープログラムまたは人間)から詳細を隠す表現であり、システムをより一般的にして理解しやすくします。
+良い例は、ラップトップのオペレーティングシステム(OS)です。
+コンピューターがどのように動作するかの詳細を、すべて抽象化します。
+CPUやメモリ、プログラムの扱い方について何も知る必要はなく、OSを操作するだけで細かい部分はOSが処理してくれます。
+これらすべての詳細は、OSの「カーテン」または抽象化の背後に隠されています。
+
+通常、システムには複数の抽象化レイヤーがあります。
+これにより、開発が大幅に簡素化されます。
+プログラミングの際、開発者は特定の抽象化レイヤーと互換性のあるコンポーネントを構築するため、非常に異質な可能性があるすべての下層レイヤーの詳細について心配する必要はありません。
+抽象化レイヤーで動作する場合は、内部に何があるかに関係なく、システムでも動作します。

content/ja/blue-green-deployment.md

@@ -0,0 +1,27 @@
+---
+title: ブルーグリーンデプロイメント
+status: Completed
+category: コンセプト
+tags: ["方法論", "アプリケーション", ""]
+---
+
+ブルーグリーンデプロイメントは、最小限のダウンタイムで稼働中のコンピュータシステムを更新する戦略です。
+オペレーターは、"ブルー"と"グリーン"と呼ばれる2つの環境を維持します。
+一方は本番トラフィックを処理し(現在すべてのユーザーが使用しているバージョン)、もう一方が更新されます。
+アクティブではない(グリーン)環境のテストが終了すると、本番トラフィックは(しばしばロードバランサーを使用して)切り替えられます。
+ブルーグリーンデプロイメントは通常、多くのサービスを含む全環境を一度に切り替えることを意味します。
+紛らわしいことに、時々この用語はシステム内の個々の[サービス](/ja/service/)に関して使用されます。
+このあいまいさを避けるため、個々のコンポーネントを指す場合には"ゼロダウンタイムデプロイメント"という用語が好まれます。
+
+## 解決すべき問題はなんですか
+
+ブルーグリーンデプロイメントは、後方互換性がないために"ロックステップ"で変更する必要があるソフトウェアを更新する際に最小限のダウンタイムを可能にします。
+例えば、ウェブサイトとデータベースから成るオンラインストアの更新を考えます。
+新しいバージョンのデータベースが古いバージョンのウェブサイトと互換性がなく、その逆も同様である場合、ブルーグリーンデプロイメントが適しています。
+このインスタンスでは、両方を同時に変更する必要があります。
+これが本番システムで行われた場合、顧客はダウンタイムに気付くでしょう。
+
+## どのように役に立つのでしょうか
+
+ブルーグリーンデプロイメントは、最小限のダウンタイムで更新する必要がある、クラウドネイティブではないソフトウェアに適した戦略です。
+しかし、その使用は通常レガシーソフトウェアが再設計され、コンポーネントを個別に更新できるようにする必要があるという"臭い"を放ちます。

content/ja/canary-deployment.md

@@ -0,0 +1,28 @@
+---
+title: カナリアデプロイメント
+status: Completed
+category: コンセプト
+tags: ["方法論", "アプリケーション", ""]
+---
+
+カナリアデプロイメントは、2つの環境から始まるデプロイメント戦略です。
+一つはライブトラフィックがある環境で、もう一つは更新されたコードを含む、ライブトラフィックがない環境です。
+トラフィックは徐々にアプリケーションの元のバージョンから更新されたバージョンへ移行します。
+最初にライブトラフィックの1％を移行し、次に10％、25％と続け、すべてのトラフィックが更新されたバージョンを流れるまで続けます。
+組織は本番環境で新しいバージョンのソフトウェアをテストし、フィードバックを得て、エラーを診断し、必要に応じて安定したバージョンに迅速にロールバックすることができます。
+
+「カナリア」という用語は、「炭鉱のカナリア」という慣習に由来します。
+この慣習では、カナリア鳥を炭鉱に連れて行き、鉱夫の安全を確保していました。
+無臭の有害ガスが存在すると、鳥は死んでしまい鉱夫は迅速に避難する必要があることを知りました。
+同様に、更新されたコードに何か問題が発生した場合、ライブトラフィックは元のバージョンに「避難」されます。
+
+## 解決すべき問題はなんですか
+
+テスト戦略をいかに徹底していても、本番環境では常にいくつかのバグが発見されます。
+アプリの100%のトラフィックをあるバージョンから別のバージョンに移行することは、より影響力のある障害につながる可能性があります。
+
+## どのように役に立つのでしょうか
+
+カナリアデプロイメントにより、組織は新しいソフトウェアが実際のシナリオでどのように振る舞うかを、新しいバージョンに大量のトラフィックを移行する前に確認することができます。
+この戦略により、組織はダウンタイムを最小限に抑え、新しいデプロイメントに問題がある場合に迅速にロールバックすることができます。
+また、全体的なユーザーエクスペリエンスに大きな影響を与えることなく、徹底的な本番アプリケーションのテストを可能にします。

content/ja/chaos-engineering.md

@@ -0,0 +1,24 @@
+---
+title: カオスエンジニアリング
+status: Completed
+category: コンセプト
+tags: ["方法論", "", ""]
+---
+
+カオスエンジニアリング(CE)とは、本番環境の[分散システム](/ja/distributed-systems/)に実験する学問分野です。
+分散システムが乱雑で予期せぬ状況に耐えるシステムの能力に対する信頼を築くことを目指します。
+
+## 解決すべき問題はなんですか
+
+[SRE](/ja/site-reliability-engineering/)や[DevOps](/ja/devops/)の実践は、プロダクトの回復力と[信頼性](/ja/reliability/)を高める技術に焦点を当てています。
+システムが障害を許容しつつ適切なサービス品質を保証する能力は、通常のソフトウェア開発の要件です。
+インフラストラクチャー、プラットフォーム、あるいは([マイクロサービス](/ja/microservices-architecture)ベースの)アプリケーションの他の動作部分のように、アプリケーションの停止につながる可能性のある複数の側面が関与しています。
+本番環境に新機能を高頻度でデプロイすることは、高い確率でダウンタイムと重大なインシデントをもたらし、ビジネスに重大な影響を及ぼす可能性があります。
+
+## どのように役に立つのでしょうか
+
+カオスエンジニアリングは、回復力の要件を満たすための技術です。
+インフラストラクチャー、プラットフォーム、そしてアプリケーションの障害に対する回復力を達成するために使用されます。
+カオスエンジニアは、アプリケーション、インフラストラクチャー、あるいはプラットフォームが自己修復でき障害が顧客に目立った影響を与えないことを検証するために、プロアクティブにランダムな障害を注入するカオス実験を行います。
+カオス実験の目的は、盲点(例えば、モニタリングや自動スケーリング技術)を発見し、重大なインシデントの最中にチーム間のコミュニケーションを改善することです。
+このアプローチは、特に本番環境において、複雑なシステムにおける回復力とチームの自信を高めるのに役立ちます。

content/ja/container-orchestration.md

@@ -4,7 +4,7 @@ status: Completed
 category: コンセプト
 ---
 
-[コンテナ](/ja/container/)オーケストレーションとは、流動的な環境において、コンテナ化されたアプリケーションのライフサイクルを管理し自動化することを指します。
+[コンテナ](/ja/container/)オーケストレーションとは、流動的な環境において、[コンテナ化](/ja/containerization)されたアプリケーションのライフサイクルを管理し自動化することを指します。
 これはコンテナオーケストレータ(ほとんどの場合は[Kubernetes](/ja/kubernetes))を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。
 オーケストレーションという言葉は比喩です。
 オーケストレーションツールは、音楽指揮者のようにコンテナを指揮し、すべてのコンテナ(または音楽家)が適切に機能するようにします。

content/ja/containerization.md

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

content/ja/continuous-delivery.md

@@ -10,7 +10,7 @@ tags: ["方法論", "アプリケーション", ""]
 (または継続的デプロイメントの場合、本番環境にデプロイされる)一連の実践を指します。
 CDは、ソフトウェアがデプロイメント前に適切にテストされていることを保証する手順を重要視し、
 必要と判断された場合に変更をロールバックする方法を提供します。
-継続的インテグレーション(CI)は継続的デリバリーに向けた最初のステップです
+[継続的インテグレーション(CI)](/ja/continuous-integration/)は継続的デリバリーに向けた最初のステップです
 (つまり、テストやデプロイがされる前に、変更がうまく統合されなければなりません。)
 
 ## 解決すべき問題は何ですか

content/ja/distributed-apps.md

@@ -0,0 +1,27 @@
+---
+title: 分散アプリケーション
+status: Completed
+category: コンセプト
+tags: ["アーキテクチャ", "", ""]
+---
+
+分散アプリケーションは、機能が複数の独立したより小さな要素に分割されたアプリケーションです。
+分散アプリケーションは通常、広範なアプリケーション内で異なる機能を担う個々の[マイクロサービス](/ja/microservices-architecture/)から構成されます。
+クラウドネイティブ環境において、個々のコンポーネントは[クラスター](/ja/cluster/)内の[コンテナ](/ja/container/)として実行されます。
+
+## 解決すべき問題はなんですか
+
+単一のコンピュータ上で動作している単一のアプリケーションは単一障害点となります。
+もしそのコンピュータが故障した場合、そのアプリケーションは利用できなくなります。
+分散アプリケーションは、しばしば[モノリシックアプリケーション](/ja/monolithic-apps/)と比較されます。
+モノリシックアプリケーションは、様々なコンポーネントが独立してスケールできないために、スケールが難しい場合があります。
+さらに、それらは成長するにつれて開発者の速度の妨げになることもあります。
+なぜなら、より多くの開発者が明確に定義された境界を持つとはかぎらない共有のコードベースで作業する必要があるからです。
+
+## どのように役に立つのでしょうか
+
+単一のアプリケーションを異なる部分に分割し、それらを多くの場所で実行すると、システム全体としてはより障害を許容できるようになります。
+また、単一のアプリケーションでは利用できなかったスケーリング機能を活用できるようになります。
+つまり、[水平スケーリング](/ja/horizontal-scaling/)ができるようになります。
+しかしながら、これには複雑さの増加と運用のオーバーヘッドによるコストがかかります。
+こうして、単一のアプリケーションではなく多くのアプリケーションのコンポーネントを実行することになります。

content/ja/ebpf.md

@@ -0,0 +1,35 @@
+---
+title: eBPF
+status: Completed
+category: テクノロジー
+tags: ["アーキテクチャ", "ネットワーキング", "セキュリティ"]
+---
+
+eBPF (extended Berkeley Packet Filter)は、Linuxカーネルのソースコードを修正したりカーネルモジュールを導入したりすることなく、サンドボックス化された小さなプログラムやスクリプトをLinuxシステムのカーネル空間で実行できる技術です。
+
+Linuxシステムには2種類の空間があります。カーネル空間とユーザー空間です。
+カーネルはOSのコアにあたり、ハードウェアに無制限でアクセスできる唯一の部分です。
+
+アプリケーションはユーザー空間で動作し、高位の権限が必要な場合にカーネルへ要求を送ります。
+ハードウェアへの直接アクセスなど、より柔軟性を必要とするアプリケーションについては、「Linuxカーネルモジュール」として知られるアプローチでカーネルを拡張することができます。
+このアプローチによりカーネルの標準機能は拡張され、アプリケーションは基礎となる要素へより深くアクセスできるようになります。
+しかしこのアプローチはセキュリティリスクももたらすため、eBPFが魅力的な代替となります。
+
+## 解決すべき問題はなんですか
+一般的に、アプリケーションはユーザー空間で動作し、アプリケーションがカーネルから(例えばハードウェアへのアクセスなどの)権限を要求するときは、いわゆる「システムコール」を介して要求します。
+多くの場合、このアプローチはうまく働きますが、低水準なシステムに対するより柔軟なアクセスを開発者が必要とする場合があります。
+可観測性、セキュリティやネットワーク機能はこういった場合の良い例です。
+この実現のため、Linuxカーネルモジュールを使ってカーネルのソースコードを修正することなくカーネルの基礎を拡張することができます。
+Linuxカーネルモジュールの使用には利点もありますが、セキュリティリスクももたらします。
+Linuxカーネルモジュールはカーネル空間の内部で動作するため、カーネルをクラッシュさせる可能性があり、カーネルがクラッシュするということは機器全体もクラッシュすることになります。
+加えて、カーネルモジュールは特権を持ち、システムリソースに直接アクセスします。
+もし適切に保護されていない場合、攻撃者は攻撃のためカーネルモジュールを悪用できてしまいます。
+
+## どのように役に立つのでしょうか
+eBPFはユーザー定義プログラムの実行環境として、Linuxカーネルモジュールよりも制御、制限された環境を提供します。
+eBPFプログラムはカーネル内のサンドボックス化された環境で動作することで、隔離を提供しリスクを低減します。
+もしeBPFプログラム中の脆弱性や欠陥が悪用されたとしても、一般的にその影響はサンドボックス化された環境に抑えられます。
+さらに、eBPFプログラムがカーネル内で動作を開始する前に、プログラムはいくつかの検証を通る必要があります。
+検証器は、範囲外メモリーアクセス、無限ループや承認されていないカーネル関数の使用といった潜在的な安全違反がないかeBPFプログラムを確認します。
+このようにして、プログラムが無限ループに入り、カーネルをクラッシュさせないことを確かにします。
+これらの安全制御によって、Linuxカーネル内でアプリケーションを動かすための選択肢としてeBPFはLinuxカーネルモジュールよりも安全なものになっています。