タグで閲覧します
用語集の用語を分類しています。フィルターを使って、タグごとに用語を閲覧することができます。
APIゲートウェイは、いくつかのアプリケーションAPIを集約し、それらを一か所で利用可能にするツールです。 これにより認証や認可、またはアプリケーション間のリクエスト数を制限するなどの重要な機能を中央管理された場所に集約することができます。 APIゲートウェイは、(しばしば外部の)APIの利用者に対する共通のインターフェースとして機能します。
解決すべき問題はなんですか 外部の利用者にAPIを提供する場合、すべてのアクセスを管理・制御するための一つのエントリーポイントが必要になります。 さらに、それらのやり取りに機能を適用する必要がある場合、APIゲートウェイを使用するとアプリのコードを変更することなく、すべてのトラフィックに対して一様にそれを適用することができます。
どのように役に立つのでしょうか アプリケーション内のさまざまなAPIに対して単一のアクセスポイントを提供するAPIゲートウェイは、組織の横断的なビジネスロジックやセキュリティロジックを一箇所に集中して適用するのを容易にします。 また、アプリケーションの利用者がすべてのニーズに対して単一のアドレスを通じてアクセスできるようにもします。 APIゲートウェイは、システム内のすべてのウェブサービスへのリクエストに対して単一のアクセスポイントを提供することで、セキュリティやオブザーバビリティなどの運用上の懸念を簡素化することができます。 すべてのリクエストがAPIゲートウェイを通過するため、メトリクス収集、レート制限、認証などの機能を追加するための単一の場所となります。..
DevOpsは、アプリケーション開発から本番運用までの全過程をチームが所有する方法論で、それゆえDevOpsと呼ばれます。 これは一連の技術を実装することを超えて、文化やプロセスの完全な変革を必要とします。 DevOpsは、(全体の機能ではなく)小さなコンポーネントに取り組むエンジニアのグループを求め、エラーの一般的な原因である引き渡しの回数を減らします。
解決すべき問題はなんですか 従来、密結合なモノリシックアプリを持つ複雑な組織では、通常、作業は複数のグループ間で断片化されていました。 これにより多くの引き渡しと長いリードタイムが発生しました。 コンポーネントやアップデートが準備できるたびに、それは次のチームのキューに置かれました。 個々の担当者はプロジェクトの一部分のみを扱うため、このアプローチは所有権の欠如につながりました。 彼らの目標は、作業を次のグループに渡すことであり、顧客に適切な機能を提供することではありませんでした。 これは明らかな優先順位のずれです。
コードが最終的に本番環境に入る頃には、多くの開発者を経由し、多くのキューで待機していたため、コードが動作しない場合の問題の原因を追跡するのが難しくなりました。 DevOpsはこのアプローチを根本から覆します。
どのように役に立つのでしょうか アプリケーションの全ライフサイクルを一つのチームが担当することで、引き渡しを最小限に抑え、本番環境へデプロイする際のリスクを減少させ、チームが本番環境でのコードのパフォーマンスにも責任を持つことでコード品質が向上し、より多くの自律性と所有権により従業員の満足度も高まります。..
DevSecOpsという用語は、開発、運用、およびセキュリティの責任の文化的統合を指します。 これは、開発と運用のワークフローを最小限に乱すことなく、セキュリティの優先順位を含むようにDevOpsアプローチを拡張します。 DevOpsと同様に、DevSecOpsは採用された技術によって推進される文化的変革であり、独自の適用方法があります。
解決すべき問題はなんですか DevOpsの実践には、継続的インテグレーション、継続的デリバリー、および継続的デプロイメントが含まれ、アプリケーションの開発とリリースサイクルを加速します。 残念ながら、自動化されたリリースプロセスが組織のすべてのステークホルダーを適切に表現できない場合には、既存の問題を悪化させる可能性があります。 セキュリティのニーズを考慮せずに構築された新しいソフトウェアを迅速にリリースするプロセスは、組織のセキュリティ態勢を低下させる可能性があります。
どのように役に立つのでしょうか DevSecOpsは、チームのサイロを壊し、安全な自動化されたワークフローの作成を促進することに焦点を当てています。 セキュリティアプリケーションを選択する際、組織は開発者を支援する自動化されたCI/CDワークフローとポリシーの施行を活用する必要があります。 障害物になることではなく、セキュリティポリシーを施行しつつ、ユーザーにプロジェクトを前進させる方法に関する正確な情報を提供することが目標です。 適切に実装された場合、組織はより良いチームコミュニケーションを得て、セキュリティ事故と関連コストを減らすことができます。..
eBPF (extended Berkeley Packet Filter)は、Linuxカーネルのソースコードを修正したりカーネルモジュールを導入したりすることなく、サンドボックス化された小さなプログラムやスクリプトをLinuxシステムのカーネル空間で実行できる技術です。
Linuxシステムには2種類の空間があります。カーネル空間とユーザー空間です。 カーネルはOSのコアにあたり、ハードウェアに無制限でアクセスできる唯一の部分です。
アプリケーションはユーザー空間で動作し、高位の権限が必要な場合にカーネルへ要求を送ります。 ハードウェアへの直接アクセスなど、より柔軟性を必要とするアプリケーションについては、「Linuxカーネルモジュール」として知られるアプローチでカーネルを拡張することができます。 このアプローチによりカーネルの標準機能は拡張され、アプリケーションは基礎となる要素へより深くアクセスできるようになります。 しかしこのアプローチはセキュリティリスクももたらすため、eBPFが魅力的な代替となります。
解決すべき問題はなんですか 一般的に、アプリケーションはユーザー空間で動作し、アプリケーションがカーネルから(例えばハードウェアへのアクセスなどの)権限を要求するときは、いわゆる「システムコール」を介して要求します。 多くの場合、このアプローチはうまく働きますが、低水準なシステムに対するより柔軟なアクセスを開発者が必要とする場合があります。 オブザーバビリティ、セキュリティやネットワーク機能はこういった場合の良い例です。 この実現のため、Linuxカーネルモジュールを使ってカーネルのソースコードを修正することなくカーネルの基礎を拡張することができます。 Linuxカーネルモジュールの使用には利点もありますが、セキュリティリスクももたらします。 Linuxカーネルモジュールはカーネル空間の内部で動作するため、カーネルをクラッシュさせる可能性があり、カーネルがクラッシュするということは機器全体もクラッシュすることになります。 加えて、カーネルモジュールは特権を持ち、システムリソースに直接アクセスします。 もし適切に保護されていない場合、攻撃者は攻撃のためカーネルモジュールを悪用できてしまいます。
どのように役に立つのでしょうか eBPFはユーザー定義プログラムの実行環境として、Linuxカーネルモジュールよりも制御、制限された環境を提供します。 eBPFプログラムはカーネル内のサンドボックス化された環境で動作することで、隔離を提供しリスクを低減します。 もしeBPFプログラム中の脆弱性や欠陥が悪用されたとしても、一般的にその影響はサンドボックス化された環境に抑えられます。 さらに、eBPFプログラムがカーネル内で動作を開始する前に、プログラムはいくつかの検証を通る必要があります。 検証器は、範囲外メモリーアクセス、無限ループや承認されていないカーネル関数の使用といった潜在的な安全違反がないかeBPFプログラムを確認します。 このようにして、プログラムが無限ループに入り、カーネルをクラッシュさせないことを確かにします。 これらの安全制御によって、Linuxカーネル内でアプリケーションを動かすための選択肢としてeBPFはLinuxカーネルモジュールよりも安全なものになっています。..
Function as a Service (FaaS)は、サーバーレス、クラウドコンピューティング、サービスの一種であり、イベントによってコードを実行することを可能にします。 これは通常、マイクロサービスアプリケーションの構築や立ち上げに関連する、複雑なインフラストラクチャのメンテナンスを必要としません。 FaaSを使用すると、ユーザーは関数とデータのみを管理し、クラウドプロバイダーがアプリケーションを管理します。 これにより、開発者はコードが実行されていないときにサービスの費用を支払うことなく、必要な機能を得ることができます。
解決すべき問題はなんですか 従来のオンプレミスシナリオでは、企業は自社のデータセンターの管理や維持をします。 企業はサーバー、ストレージ、ソフトウェア、その他の技術に投資し、ITスタッフや請負業者を雇ってすべての機器やライセンスの購入、管理、更新を行う必要があります。 データセンターは、作業負荷が減少しリソースがアイドリング状態の時期があるにも関わらず、ピーク需要に対応できるように建設されなければなりません。 逆にビジネスが急速に成長する場合、IT部門は追いつくのに苦労するかもしれません。 標準的なInfrastructure-as-a-Service (IaaS)クラウドコンピューティングモデルでは、ユーザーは事前に容量ユニットを購入します。 つまりアプリを実行するために、サーバーコンポーネントを常時起動させ、それに対する支払いをパブリッククラウドプロバイダーに行います。 需要が高まる時にサーバー容量を増やし、その容量が不要になった時に減らすのはユーザーの責任です。 アプリが使用されていないときでも、そのアプリを実行するためのクラウドインフラは稼働しています。
どのように役に立つのでしょうか FaaSはサーバーを管理することなく、イベントに応じてウェブアプリケーションを実行するための抽象化を開発者に提供します。 例えば、ファイルのアップロードがそのファイルを様々な形式にトランスコードするカスタムコードのトリガーとなるかもしれません。 FaaSのインフラストラクチャは、頻繁に使用するコードを自動的にスケールアップし、開発者はスケーラビリティのためのコード構築に時間やリソースを費やす必要がありません。 課金は計算時間のみに基づいているため、機能が使用されていない時には企業は支払いをする必要がありません。..
Infrastructure as a service (IaaS)は、クラウドコンピューティングのサービスモデルの一つであり、物理的または仮想化されたコンピューティングリソース、ストレージ、ネットワークリソースをオンデマンドで提供し、従量課金モデルに基づいて利用できます。 クラウドプロバイダーはハードウェアとソフトウェアを所有、運用し、これらをパブリック、プライベート、またはハイブリッドクラウドの形態で消費者に提供します。
解決すべき問題はなんですか 従来のオンプレミス環境では、組織はコンピューティングリソースの有効活用にしばしば苦労していました。 データセンターは、1%の時間しか必要とされない、潜在的なピーク需要に対応するために構築されなければなりません。 需要が低い時期には、これらのコンピューティングリソースはアイドル状態になります。 また、予想を超えるワークロードが発生した場合、処理するためのコンピューティングリソースが不足します。 このようなスケーラビリティの欠如は、コストの増加とリソースの非効率的な使用につながります。
どのように役に立つのでしょうか IaaSを利用することで、組織はアプリケーション用のコンピューティングリソースやデータセンターのスペースを購入し、維持する必要がなくなります。 オンデマンドインフラを使用することで、必要に応じてコンピューティングリソースをレンタルし、CAPEXと呼ばれる大規模な資本支出を延期しながら、スケールアップあるいはスケールダウンする柔軟性を得ることができます。
IaaSは、新しいアプリケーションを実験したり試したりする際の初期コストを削減し、インフラストラクチャを迅速に展開する施設を提供します。 クラウドプロバイダーは、開発者が実験し革新するために役立つ、開発あるいはテスト環境にとって優れた選択肢です。..
Infrastructure as Codeは、インフラストラクチャの定義を一つあるいは複数のファイルで保存する実践を指します。 これは、通常はシェルスクリプトや他の設定ツールを用いたInfrastructure as a Serviceを手動でプロビジョニングする従来のモデルに代わるものです。
解決すべき問題はなんですか クラウドネイティブな方法でアプリケーションを構築するには、インフラストラクチャを使い捨てできるようにし、かつ再現可能にする必要があります。 また自動化された繰り返し可能な方法で、人の手が介入することなくオンデマンドにスケールする必要があります。 手動でのプロビジョニングは、クラウドネイティブアプリケーションの応答性とスケーラビリティを満たすことができません。 手動でのインフラストラクチャの変更は再現不可能で、すぐにスケールの限界に達し、設定ミスのエラーを引き起こします。
どのように役に立つのでしょうか サーバー、ロードバランサー、サブネットのようなデータセンターのリソースをコードとして表現することで、インフラチームはすべての設定について単一の正しい情報源を持つことができます。 また、CI/CDパイプラインでデータセンターを管理することができます。 これにより、バージョン管理とデプロイメント戦略を実装することができます。..
Ingressは、クラスター内で動作するコンテナあるいはコンテナ群への外部からのインターネットトラフィックを管理するためのルールセットです。 これにはIngressリソースとIngressコントローラーという二つの要素があります。 Ingressリソースは、他のマニフェストファイルと共に存在する設定ファイルで、管理者が外部からのトラフィックのルーティングを設定することを可能にします。 Ingressコントローラーは、実際にIngressリソースの設定に従ってトラフィックをルーティングするウェブサーバー技術です。
解決すべき問題は何ですか クラウドネイティブのウェブアプリケーションは複数のサービスで構成されており、しばしば、それらのサービスは、ブラウザを使用してユーザーがインターネット経由でアクセスする必要があります。 これらのサービスをユーザーがアクセスできるようにしながら、このアプリケーションを実行するためにKubernetesを使用する場合、各アプリケーションサービスを全世界に向けて公開する必要があります。 最も簡単な方法は、KubernetesのLoad Balancer Serviceを使用することです。 しかし、このようなサービスを作成すると、基盤となるインフラストラクチャ上に新たなコンポーネントが生まれます。 これは新しいコストと管理のオーバーヘッドを導入するだけでなく、新しく作成された各ロードバランサーには独自の外部IPアドレスがあります。 これは悪いユーザーエクスペリエンスにつながります。 なぜならユーザーは、アプリケーションにアクセスするために異なるURLをブラウズしたくないからです。
どのように役に立つのでしょうか Ingressリソースを使用すると、アプリケーションのサービスへのトラフィックのバランスとルーティング方法を設定できます。 Ingressコントローラーは、URLを通じて単一のエントリポイント(例: <a href="https://www.example-url.com">www.example-url.com</a>)を公開し、異なるURLパス(例: <a href="https://www.example-url.com/path">www.example-url.com/path</a>)に基づいて実際のルーティングとバランシングを行います。 Ingressコントローラーは、クラスター内で動作するコンポーネントであり、Ingressリソースで定義されたルールを解釈します。 ウェブアプリが動作するクラスターの運用者が、Nginx、Traefik、HAProxyなどの使用可能な技術セットから特定のIngressコントローラーを選択することができます。 それにより、アプリケーションが複数のサービスで構成されている場合、ユーザーは単一のURLを使用してアクセスできます。 これは、インフラストラクチャレベルで数多くの個別のロードバランサーが不要になり、各サービスのファイアウォールとロードバランサーのルールの設定が容易になります。 トラフィックのルーティングと設定の取り扱いを一元化することで、Ingressはスケーラビリティの効率化を提供し、リソース利用を最適化し、コストを削減し、クラスター内で実行されるアプリケーションの全体的な管理のしやすさを向上させます。..
Kubernetesは、しばしばK8sと略される、オープンソースのコンテナオーケストレーターです。 Kubernetesは、モダンなインフラストラクチャ上でコンテナ化されたアプリケーションのライフサイクルを自動化し、分散システム全体でアプリケーションを管理するデータセンターのオペレーティングシステムとして機能します。
Kubernetesは、クラスター内のノードにまたがってコンテナをスケジュールし、ロードバランサーや永続ストレージなど、いくつかのインフラストラクチャリソースを束ねてコンテナ化されたアプリケーションを実行します。
Kubernetesは自動化と拡張性を実現し、ユーザーが宣言的に(以下参照)かつ再現可能な方法でアプリケーションをデプロイできるようにします。 KubernetesはAPIを介して拡張可能であり、経験豊富なKubernetesの専門家が自分たちのニーズに応じて拡張することができます。
解決すべき問題はなんですか インフラストラクチャの自動化と宣言的な設定の管理は長い間重要な概念でしたが、クラウドコンピューティングが人気になるにつれて、その重要性がさらに増していきました。 計算機リソースへの需要が増加し、組織がより少ないエンジニアでより多くの運用機能を提供する必要が生じる中、その需要に応えるためには新しい技術や作業方法が求められています。
どのように役に立つのでしょうか 従来のInfrastracture as Codeツールと同様にKubernetesは自動化を支援しますが、コンテナを用いて動作するという利点があります。 コンテナは仮想マシンや物理マシンよりも設定のずれに対する耐性があります。
さらにKubernetesは宣言的に動作します。 つまり、オペレータがマシンに何かを行う方法を指示するのではなく、インフラストラクチャがどのようにあるべきかを記述します。 これは通常、マニフェストファイル(例えばYAML)として記述されます。 その後、Kubernetesが実行方法の詳細を管理します。 これにより、KubernetesはInfrastracture as Codeと非常に互換性が高くなっています。
またKubernetesはセルフヒーリングを行います。 セルフヒーリングによって、クラスターの実際の状態は、常にオペレータの望む状態と一致します。 Kubernetesがマニフェストファイルで記述された内容と異なる点を検出した場合、Kubernetesコントローラーがそれを修正します。 Kubernetesが使用するインフラストラクチャは絶えず変化しているかもしれませんが、Kubernetesは常に自動的に変化に適応し、望ましい状態と一致するように保証します。..
Kubernetes環境の中では、Podは最も基本的なデプロイ可能ユニットとして機能します。 これはコンテナ化されたアプリケーションをデプロイし、管理するための基本的な構成要素を表しています。 各Podには単一のアプリケーションインスタンスが含まれ、一つ以上のコンテナを保持することができます。 Kubernetesは、より大規模なDeploymentの一部としてPodを管理し、必要に応じてPodを垂直スケーリングまたは水平スケーリングすることができます。
解決すべき問題はなんですか コンテナは一般的に、特定のワークロードを実行し制御する独立した単位として機能しますが、コンテナが密接に相互作用し、適切に連携して制御される必要がある場合もあります。
これらの密接に関連するコンテナがそれぞれ個別に管理される場合、冗長な管理作業が発生します。 たとえば、オペレーターは関連するコンテナの配置を繰り返し判断し、それらが一緒に保たれるようにしなければなりません。 また、これらの関連するコンテナのライフサイクルは同期される必要がありますが、個別にしか管理できません。
どのように役に立つのでしょうか Podは密接に関連するコンテナを単一のユニットにまとめることで、コンテナ操作を大幅に簡素化します。 たとえば、補助的なコンテナは、追加機能を提供したり、グローバルな設定を行うために主コンテナと一緒に使用されることがよくあります。 これには、基本設定を主コンテナに注入して適用するコンテナ、 sidecar (コンテナ)であり、主コンテナのためのネットワークトラフィックルーティングを処理する(サービスメッシュを参照)、あるいは各コンテナと連動してログを収集するコンテナなどが含まれます。
メモリとCPUの割り当ては、Podレベルで定義することも、コンテナごとに定義することもできます。 Podレベルで定義すると、内部のコンテナがリソースを柔軟に共有できます。..
Policy as Codeは、ポリシー定義を機械的に読み取り可能かつ処理可能な形式で、1つ以上のファイルに保存する方法です。 これは、別々の文書に人間が読める形式でポリシーが文書化されていた従来の方式を置き換えます。
解決すべき問題はなんですか アプリケーションやインフラストラクチャの構築には、しばしば組織が定義した多数のポリシーにより制約が課されます。 たとえば、シークレット情報をソースコードへの埋め込むことを禁止するセキュリティポリシーや、スーパーユーザー権限でコンテナの実行を禁止するポリシー、あるいは特定の地理的位置以外にデータを保存することを禁止するポリシーなどがあります。 開発者やレビュアーにとって、アプリケーションやインフラストラクチャが文書化されたポリシーに従っているかを手動で確認することは非常に労力がかかり、エラーも発生しやすいです。 手動のプロセスでは、クラウドネイティブアプリケーションの応答性やスケールの要件を満たせません。
どのように役に立つのでしょうか コードを通じてポリシーを記述することは、再現性を持たせることができ、手動で行う場合と比べてエラーが減少します。 Policy as Codeの他の利点は、コードがGitのようなバージョン管理システムで管理できることです。 Gitは変更履歴を作成し、これはなにかが期待通りに機能しない際にとりわけ役に立ちます。 これにより、誰が変更を行ったのかを確認し、以前のバージョンに戻すことが可能になります。..
Transport Layer Security (TLS)は、ネットワーク上での通信のセキュリティを高めるために設計されたプロトコルです。 インターネット上で送信されるデータの安全な配信を保証し、データの監視や改ざんを避けることができます。 このプロトコルは、メッセージングや電子メールなどのアプリケーションで幅広く使用されています。
解決すべき問題はなんですか TLSがないと、日常的なブラウジング、電子メールでのやりとり、オンラインチャット、ビデオ会議などの機密情報が、転送中に他者によって簡単に追跡され変更される可能性があります。 サーバーとクライアントアプリケーションがTLSをサポートすることで、それらの間で転送されるデータが暗号化され、第三者によって閲覧されないことが保証されます。
どのように役に立つのでしょうか TLSは、ネットワーク上でデータを転送する際のセキュリティを提供するために、さまざまな符号化技術を組み合わせて使用します。 TLSにより、例えばウェブブラウザと銀行サイトのように、クライアントアプリケーションとサーバーとの間の暗号化された接続が可能になります。 また、クライアントアプリケーションが呼び出すサーバーを正確に識別できるようになるため、クライアントが不正なサイトと通信するリスクが減少します。 これにより、TLSを使用してアプリケーション間で転送されるデータを第三者が閲覧し、監視することができなくなります。 結果として、クレジットカード番号、パスワード、位置情報などの機密および個人情報が保護されます。..
サーバーレスは、開発者がサーバーの管理を気にすることなくアプリケーションの構築と実行を可能にするクラウドネイティブの開発モデルです。 サーバーレスパラダイム内にサーバーは存在しますが、アプリケーション開発プロセスから抽象化されています。 クラウドプロバイダーがサーバーインフラのプロビジョニング、維持、およびスケーリングの日常的な作業を処理します。 開発者は、デプロイのためにコードをコンテナに便利にパッケージできます。 一度デプロイされると、サーバーレスアプリは需要に応じて自動的にスケールアップおよびダウンします。 パブリッククラウドプロバイダーからのサーバーレスの提供は通常、イベント駆動型の実行モデルによってオンデマンドで課金されます。 その結果、サーバーレス機能がアイドル状態にあるとき、関連するコストは発生しません。
解決すべき問題はなんですか 標準的なInfrastructure as a Service (IaaS)のクラウドコンピューティングモデルでは、 ユーザーはキャパシティの単位を事前に購入します。 つまり、アプリを実行するために常時稼働するサーバーコンポーネントの料金をパブリッククラウドプロバイダーに支払うことになります。 高需要時にサーバーのキャパシティをスケールアップしたり、キャパシティが必要なくなったときにスケールダウンしたりするのは、ユーザーの責任です。 アプリケーションが使用されていないときであっても、アプリケーションを運用するために必要なクラウドインフラストラクチャーはアクティブなままです。
どのように役に立つのでしょうか 従来のアプローチとは対照的に、サーバーレスアーキテクチャは必要なときにのみアプリケーションを起動します。 イベントがアプリコードの実行をトリガーすると、パブリッククラウドプロバイダーは、そのコードのためのリソースを動的に割り当てます。 コードの実行が終了すると、ユーザーは支払いを停止します。 コストと効率の利点に加えて、サーバーレスは開発者をアプリのスケーリングとサーバーのプロビジョニングに関連する日常的で単調なタスクから解放します。 サーバーレスを使用すると、オペレーティングシステムとファイルシステムの管理、セキュリティパッチ、ロードバランシング、キャパシティ管理、スケーリング、ログ、監視などの日常的なタスクは、すべてクラウドサービスプロバイダーに委ねられます。..
ITの分野において、サービスという言葉には複数の意味があります。 この定義では、より伝統的な意味でのサービス、つまりマイクロサービスとしてのサービスに焦点を当てます。 サービスがマイクロサービスとどのように異なるのかは微妙であり、人によって異なる意見を持つかもしれません。 高レベルの定義としては、これらを同じものとして扱います。 マイクロサービスの定義を参照してください。..
サービスディスカバリーはサービスを構成する個々のインスタンスを見つけるプロセスです。 サービスディスカバリーツールは、サービスを構成するさまざまなノードやエンドポイントを追跡します。
解決すべき問題はなんですか クラウドネイティブアーキテクチャは、動的かつ流動的で常に変化しています。 コンテナ化されたアプリケーションは、その寿命の中で複数回起動と停止をする可能性があります。 起動や停止が起きるたびに新しいアドレスを持つことになり、それを見つけたい任意のアプリケーションは、新しい位置情報を提供するツールを必要とします。
どのように役に立つのでしょうか サービスディスカバリーは、ネットワーク内のアプリケーションを追跡し、必要な時にお互いを見つけられるようにします。 そして、個々のサービスを識別し見つけるための共通の場所を提供します。 サービスディスカバリーエンジンはデータベースのようなツールで、どのようなサービスが存在し、それらをどのように配置するかについての情報を保存します。..
サービスプロキシは、特定のサービスへの、あるいはそこからのトラフィックをインターセプトします。 そして、それに対して何らかのロジックを適用した後、そのトラフィックを別のサービスに転送します。 これは、ネットワークトラフィックに関する情報を収集したり、ルールを適用したりする仲介者として機能します。
解決すべき問題はなんですか サービス間のコミュニケーション(通称: ネットワークトラフィック)を追跡し、それを変換したりリダイレクトしたりするためには、データを収集する必要があります。 従来、データ収集とネットワークトラフィック管理を行うコードは、各アプリケーション内に組み込まれていました。
どのように役に立つのでしょうか サービスプロキシにより、この機能を外部化することができます。 もはやアプリ内に組み込む必要はありません。 代わりに、プラットフォームレイヤー(アプリが実行される場所)に組み込まれるようになりました。
サービス間のゲートキーパーとして、プロキシはどのような種類のコミュニケーションが行われているかについての洞察を提供します。 その洞察に基づき、特定のリクエストをどこに送るかを決定したり、完全に拒否したりします。
プロキシは重要なデータを収集し、ルーティングを管理します(トラフィックをサービス間で均等に分散させたり、一部のサービスが故障した場合には再ルーティングしたり)。 また、接続を暗号化し、コンテンツをキャッシュします(リソース消費を減らします)。..
マイクロサービスの世界では、アプリケーションは複数の小さなサービスに分割され、それらがネットワークを介して通信します。 あなたのWi-Fiネットワークのように、コンピューターネットワークは本質的には信頼性が低く、ハッキングされやすく、しばしば遅いものです。 サービスメッシュは、サービス間のトラフィック(すなわち通信)を管理することによって、この新しい課題に対処します。 サービスメッシュは、すべてのサービスにわたって信頼性、オブザーバビリティ、およびセキュリティ機能を均一に追加します。
解決すべき問題はなんですか マイクロサービスアーキテクチャに移行したことで、エンジニアは数百、場合によっては数千ものサービスを扱うようになり、それらすべてが相互に通信を必要としています。 つまり、ネットワーク上で大量のトラフィックが行き交っています。 その上、個々のアプリケーションは、必須の要件をサポートするために通信を暗号化する必要があるかもしれません。 あるいは運用チームに共通のメトリクスを提供する必要があるかもしれませんし、問題の診断に役立つ、トラフィックに関する詳細な洞察を提供する必要があるかもしれません。 これらの機能が個々のアプリケーションに組み込まれている場合、それぞれがチーム間の摩擦を引き起こし、新機能の開発を遅らせる原因となります。
どのように役に立つのでしょうか サービスメッシュは、コードの変更を必要とせずに、クラスタ全体のすべてのサービスに対して、信頼性、オブザーバビリティ、およびセキュリティ機能を均一に追加します。 サービスメッシュが登場する前は、その機能をすべての個々のサービスに組み込む必要があり、バグや技術的負債の潜在的な原因となっていました。..
アジャイルソフトウェア開発は、繰り返しの開発サイクルと自己組織化チームを重視する一連の実践です。 プロジェクトの最後にのみ価値が生み出されるウォーターフォール型のプロジェクトとは対照的に、アジャイルソフトウェア開発は、継続的かつ段階的な価値の提供とプロセス自体の進化的な改善に焦点を当てています。
解決すべき問題はなんですか ソフトウェアプロジェクトにおいて、すべての関係者に対して要件を定義し、それを伝え理解させることは、不可能ではないにせよ非常に難しいです。 しかし、顧客は自分たちのソフトウェアプロジェクトが時間通りに、良い品質で、予算内で、スコープ内で届けられることを望んでいます。 その循環的な性質により、アジャイルソフトウェア開発は要件に継続的に適応することを可能にします。 これはウォーターフォール型の戦略とは対照的で、他のすべての状況に適応することをより迅速に行うことができます。
どのように役に立つのでしょうか アジャイルソフトウェア開発は、従来の(ウォーターフォール型の)戦略の全てのフェーズを含んでいます。 これには要件定義、計画、実装、レビュー、テスト、納品などが含まれます。 最大の違いは、ソフトウェアプロジェクトの全期間がイテレーションに分割され、そのそれぞれが全てのフェーズを含むことです。 各イテレーションの後、顧客と一緒に作成された価値をレビューし、最終目標に向けて要件を調整することができます。 さらに、開発チームはプロセス自体を改善するために取るべき行動を振り返ります。..
APIは、コンピュータープログラム同士が互いにやり取りする方法です。 人間がウェブページを介してウェブサイトとやり取りするように、APIはコンピュータープログラムが相互に通信するための手段を提供します。 人間のやり取りとは異なり、APIには何が要求できるか、あるいはできないかについての制限があります。 この制限によって、プログラム間で安定的で機能的なコミュニケーションが実現されます。
解決すべき問題はなんですか アプリケーションが複雑になるにつれて、小さなコードの変更が他の機能に大きな影響を及ぼす可能性があります。 アプリケーションが成長しながらも安定性を維持するために、機能にモジュラーなアプローチを採用する必要があります。 APIがなければ、アプリケーション同士が相互に通信するための枠組みが不足します。 共有された枠組みがないと、アプリケーションがスケールし、統合することが困難になります。
どのように役に立つのでしょうか APIは、コンピュータープログラムやアプリケーションが定義された理解しやすい方法で相互に通信し、情報を共有することを可能にします。 これは現代のアプリケーションの構成要素であり、開発者にアプリケーションを統合するための方法を提供します。 マイクロサービスが連携して動作しているのであれば、それはAPIを用いて相互に通信していると推測できます。..
イベントストリーミングは、ソフトウェアが一つのアプリケーションから別のアプリケーションにイベントデータを送信し、何をしているかを継続的に通信するアプローチです。 あるサービスが行うすべてのことを他のすべてのサービスにブロードキャストする様子を想像してください。 サービスによって行われる各活動はイベントと呼ばれ、これがイベントストリーミングの由来です。 たとえば、NASDAQは毎秒、株価と商品価格の更新を受け取ります。 特定の株式セットを監視するアプリケーションを動かすとしたら、その情報をほぼリアルタイムで受け取りたいでしょう。 Yahoo! Financeは、NASDAQから引っ張ってきたデータを引用し、その情報(またはイベント)を購読するアプリケーションに送信(またはストリーム)するAPIを提供しています。 送信されるデータおよびそのデータ(株価)の変化がイベントであり、それらをアプリケーションに配信するプロセスがイベントストリーミングです。
解決すべき問題はなんですか 従来、Yahoo! Financeは単一のTCPリクエストを使用していました。 これは、イベントごとに接続を確立する必要があるため、非常に非効率的です。 データがよりリアルタイム性を帯びるにつれて、そのような解決策をスケーリングすることは非効率的になります。 接続を一度開いてイベントが流れるようにすることは、リアルタイム収集として理想的です。 生成されるデータの量は指数関数的に増加しており、それに伴いデータの状態は絶えず変動しています。 開発者とユーザーは、そのデータをほぼリアルタイムで見ることができる必要があります。
どのように役に立つのでしょうか イベントストリーミングにより、データの変更をソースから受信者に通信できます。 情報を要求するためにサービスが待つ代わりに、サービスはそのすべてのイベント(または活動)を継続的にストリームします。 情報がどうなるかについては関心を持ちません。 必要なことを行い、それをブロードキャストするだけで、他のどのサービスとも完全に独立しています。..
イベント駆動アーキテクチャは、イベントの作成、処理、および消費を促進するソフトウェアアーキテクチャです。 イベントとは、アプリケーションの状態に対する任意の変更を指します。 例えば、ライドシェアリングアプリで乗車を依頼することは、イベントを代表しています。 このアーキテクチャは、イベントがそのソース(乗車を要求するアプリ)から望ましいレシーバー(近くの利用可能なドライバーのアプリ)へ適切にルーティングされる構造を作り出します。
解決すべき問題はなんですか より多くのデータがリアルタイムになるにつれて、イベントがキャプチャされ、イベントリクエストを処理する必要がある適切なサービスへ正確にルーティングされる信頼性の高い方法を見つけることがますます困難になります。 イベントを処理する従来の方法は、メッセージが適切にルーティングされたか、あるいは実際に送信または受信されたかを保証する方法がないことがしばしばあります。 アプリケーションがスケールするにつれて、イベントをオーケストレーションすることがより困難になります。
どのように役に立つのでしょうか イベント駆動アーキテクチャは、すべてのイベントのためのセントラルハブ(例えばKafka)を確立します。 次に、イベントプロデューサー(ソース)とコンシューマー(レシーバー)を定義し、セントラルハブがイベントの流れを保証します。 このアーキテクチャは、サービス同士が疎結合のまま、イベントがプロデューサーからコンシューマーに適切にルーティングされることを保証します。 プロデューサーは、通常はHTTPプロトコルによって受信イベントを取り、イベント情報をルーティングします。..
イミュータブルインフラストラクチャとは、一度デプロイされると変更することができないコンピューターインフラストラクチャ(仮想マシンやコンテナ、ネットワーク機器)を指します。 これは許可されていない変更を自動的に上書きするプロセスや、最初から変更を許可しないシステムによって強制されます。 コンテナはイミュータブルインフラストラクチャの良い例です。 なぜならコンテナに永続的な変更を加えるには、新しいバージョンのコンテナを作成するか、イメージから既存のコンテナを再度作成するしかないからです。
許可されていない変更の防止や特定により、イミュータブルインフラストラクチャはセキュリティリスクの特定と軽減を容易にします。 このようなシステムの運用ははるかに簡単になります。 なぜなら、管理者がそれについての前提を立てやすくなるためです。 結局のところ、誰も間違いを犯していないことや、伝え忘れた変更を行っていないことが分かっています。 イミュータブルインフラストラクチャはInfrastructure as Codeと密接に関連しており、インフラストラクチャを作成するために必要なすべての自動化がバージョン管理(たとえばGit)されています。 この不変性とバージョン管理の組み合わせにより、システムへのすべての許可された変更に対して、耐久性のある監査ログが存在します。..
エッジコンピューティングは、ストレージと計算能力の一部を主要なデータセンターからデータソースに移行する分散システムのアプローチです。 収集されたデータは、中央のデータセンターで処理や分析されるのではなく、ローカルに(例えば工場内や店内、あるいは街の全域にわたって)計算されます。 これらのローカル処理ユニットやデバイスがシステムのエッジを表し、データセンターがその中心です。 エッジで計算された出力は、さらなる処理のために主要なデータセンターに送信されます。 エッジコンピューティングの例には、リストバンド型ガジェットや交通量を分析するためのコンピューターが含まれます。
解決すべき問題はなんですか この10年間で、私たちはエッジデバイス(例えば携帯電話、スマートウォッチ、センサー)の増加を目の当たりにしてきました。 場合によっては、リアルタイムデータ処理は単なる便利な機能ではなく、非常に重要です。 自動運転を行う車を考えてみてください。 車のセンサーが取得したデータが、適切な反応をするために車両へ送り返される前に、データセンターで処理される必要があると考えてみてください。 このネットワークの遅延は致命的になり得ます。 これは極端な例ですが、ほとんどのユーザーはすぐにフィードバックを提供できないスマートデバイスを使いたいとは思わないでしょう。
どのように役に立つのでしょうか 上述した通り、エッジデバイスが有用であるためには、ユーザーにほぼリアルタイムのフィードバックを提供する必要があります。 そのために少なくとも一部の処理と分析をローカルで行います。 これはデータセンターからデータが生成される場所、つまりエッジデバイスに一部のストレージと処理リソースを移動させることで達成されます。 処理済みおよび未処理のデータはその後、さらなる処理とストレージのためにデータセンターに送信されます。 要するに、効率と速度がエッジコンピューティングの主要な推進力です。..
データセンターはコンピューター(その多くはサーバー)を収容するために設計された特別な建物または施設です。 これらのデータセンターがクラウドコンピューティングに重点を置いている場合、高速なインターネット回線に接続される傾向があります。 データセンターが入っている建物には、停電時に電力を供給する発電機や、発熱するコンピューターを冷却する強力な空調機など、停電が発生した場合でもサービスを維持できる設備が備えられています。
解決すべき問題は何ですか 1990年代後半にデータセンターが普及するまでは、主に特定の業務プロセスを実行するための専用のコンピューターであり、または個人が作業を行うためにコンピューターが使用されていました。 ただし、コンピューターのリソース(ハードディスク、メモリ、CPU)は限られているため、その上で実行されるアプリケーションには厳しい制約があり、実行できるアプリケーションの種類が制限されます。 データセンターが普及する前は、アプリケーションの規模が実行されているコンピューターの容量によって制限されていました。 しかし、GmailやNetflixのような大規模なアプリケーション(携帯電話やコンピューターのユーザーインターフェースではなくサーバーサイドアプリ)について考えてみると、1 台のコンピューターが提供できる能力よりも多くのコンピューティング能力が必要になります。 そこでデータセンターが登場します。
どのように役に立つのでしょうか ユーザーはさまざまなサーバーに接続することで、「スーパーコンピューター」のように機能する分散システムを構築できます。 複数のマシンの能力を統合しているため、より大規模なサーバーサイドアプリや業務プロセスを実行したり、より強力な計算タスクを処理したりできるようになりました。 私たちが日常的に使用するほとんどのアプリケーションがデータセンターで実行されています。 パブリッククラウドはクライアントにコンピューターリソースを貸し出すデータセンターです。ここ数年、企業所有のデータセンターからパブリッククラウドへ移行している事例が多数あります。..
オートスケーリングとは、システムが自動的にスケールする能力のことで、通常はコンピューティングリソースにおいて行われます。 オートスケーリングシステムでは、必要に応じて自動的にリソースが追加され、変動するユーザーの需要に応じてスケールできます。 オートスケーリングのプロセスは様々で、メモリーやプロセス時間などの異なるメトリクスに基づいてスケールするように設定可能です。 マネージドクラウドサービスには通常、オートスケーリング機能が関連しています。 これは、ほとんどのオンプレミス環境へのデプロイよりも多くのオプションと実装が利用可能であるためです。
以前はインフラストラクチャとアプリケーションが、システムのピーク使用量を考慮して設計されていました。 このアーキテクチャにより、多くのリソースが未使用であり、消費者需要の変化に対して非弾力的でした。 非弾力性は、ビジネスへの高コストと、過剰な需要によって発生する障害の営業損失を意味します。
クラウドを活用し、アプリケーションとその依存関係を仮想化およびコンテナ化することで、組織はユーザーの需要に応じてスケールするアプリケーションを構築できます。 彼らはアプリケーションの需要を監視し、自動的にスケールさせ、最適なユーザーエクスペリエンスを提供できます。 例えば、毎週金曜日の夕方に発生する、Netflixの視聴者数の増加を考えて見てください。 オートスケールアウトは、動的により多くのリソースを追加することを意味します。 例えば、ビデオストリーミングのためのサーバー数を増やし、需要が正常化されたらスケールバックすることです。
関連する用語はありますか 水平スケーリング 垂直スケーリング..
ノードとは、他のコンピューター、つまり他のノードと協力して共通のタスクを達成するコンピューターのことです。 例えばあなたのラップトップ、モデム、プリンターを考えてみてください。 これらはすべてあなたのWi-Fiネットワークを介して接続されており、通信し協力しており、それぞれが一つのノードを表しています。 クラウドコンピューティングにおいて、ノードは物理的なコンピューターであったり、仮想コンピューター、つまりVM(バーチャルマシン)であったり、またはコンテナであることもあります。
解決すべき問題はなんですか アプリケーションは1台のマシン上で動作させることができます(そして実際に多くのアプリケーションがそうしています)が、それにはいくつかのリスクが伴います。 具体的には、基盤となるシステムの故障がアプリケーションの中断を引き起こすことです。 これに対処するために、開発者たちは分散アプリケーションを作り始めました。 これは、各プロセスがそれぞれのノード上で動作します。 それゆえ、ノードはアプリやプロセスを実行し、共通の目標を達成するために協力するノードのクラスター、またはグループの一部として機能します。
どのように役に立つのでしょうか ノードはクラスタに割り当てることができる計算上の明確な違いがある単位(メモリ、CPU、ネットワーク)を提供します。 クラウドネイティブプラットフォームやアプリでは、ノードは作業を行うことができる単一のユニットを表します。 理想的には個々のノードには区別がなく、特定のタイプのあるノードは、同じタイプの他のノードと区別がつかないものとされます。..
オブザーバビリティとは、システムが実用的な洞察をどの程度出力できるかを決める性質のことを指します。 オブザーバビリティにより、ユーザーはシステム外部への出力を元にそのシステムの状態を理解し、(是正)措置を取ることが可能になります。
コンピューターシステムは、CPU時間・メモリ・ディスク容量といった低水準のシグナルや、APIの応答時間・エラー数・秒間トランザクション数などを含む高水準でビジネスに直結するシグナルを観測することで評価されます。 可観測なシステムは、いわゆるオブザーバビリティツールと言われる専門のツールで観測(もしくは監視)されます。 オブザーバビリティツールの一覧はクラウドネイティブ ランドスケープのオブザーバビリティセクションで見られます。
可観測なシステムは、有意義かつ実用的なデータを運用者に提供し、運用者が(インシデントへのより素早い対応や開発者の生産性向上といった)好ましい結果を出すことを可能にします。 システムのダウンタイムとともに、手間のかかる手作業での仕事も少なくなります。
結果として、システムの運用コストと開発コストは、そのシステムがどれだけ可観測なのかに大きく影響を受けるでしょう。..
ソフトウェアの特性であるポータビリティは、再利用性の一つの形態です。 クラウドプロバイダー、オペレーティングシステムやベンダーなどの特定の運用環境へのロックインを避けるのに役立ちます。
伝統的に、ソフトウェアは特定の環境(例えばAWSやLinux)向けに構築されがちです。 一方、ポータブルなソフトウェアは、大規模な作業を必要とせずに、異なる運用環境で機能します。 アプリケーションがポータブルであるとは、新しい環境に適応させるために要求される労力が合理的な範囲内であることを指します。 「ポートする」というフレーズは、ソフトウェアを修正しそれを異なるコンピューターシステム上で動作可能にすることを意味します。..
ロールベースアクセス制御(RBAC)は、チームあるいはより大きな組織内での個々のロールに基づいてシステムやネットワーク、リソースへのアクセスを管理するセキュリティ方法です。 RBACは、管理者に特定の職務を持つすべてのユーザーに必要なアクセスレベルを割り当て、事前に定義された一連の権限を持つ役割をそれらのユーザーに割り当てる権限を与えます。 組織はRBACを利用して、従業員ごとの役割と責任に合わせた、さまざまなレベルのアクセスを提供します。
解決すべき問題はなんですか RBACは、特にアプリケーションとチームメンバーの数が増えるにつれて、チームメンバーやアプリケーションがアクセスできるリソース、および彼らが実行できる操作を制御するという課題に対処します。 管理者は、各ユーザーがアクセスする必要があるリソースに対して正しい権限を持っていることを確認する必要がありますが、これは構造化されたアクセス制御メカニズムがなければ煩雑で間違いが生じやすい作業になります。
どのように役に立つのでしょうか RBACは、ITチームにグループ内のすべてのユーザーの権限を同時に簡単に管理したり、役割を割り当てたり削除することで、個々のユーザーのアクセスレベルをすばやく調整する能力を提供します。 これにより、機密データを保護し従業員が職務に必要な情報のみにアクセスし、行動できるようにします。 結果として、RBACはアクセス管理やセキュリティを強化し、組織内の運用効率を向上させます。..
カオスエンジニアリング(CE)とは、本番環境の分散システムに実験する学問分野です。 分散システムが乱雑で予期せぬ状況に耐えるシステムの能力に対する信頼を築くことを目指します。
解決すべき問題はなんですか SREやDevOpsの実践は、プロダクトの回復力と信頼性を高める技術に焦点を当てています。 システムが障害を許容しつつ適切なサービス品質を保証する能力は、通常のソフトウェア開発の要件です。 インフラストラクチャ、プラットフォーム、あるいは(マイクロサービスベースの)アプリケーションの他の動作部分のように、アプリケーションの停止につながる可能性のある複数の側面が関与しています。 本番環境に新機能を高頻度でデプロイすることは、高い確率でダウンタイムと重大なインシデントをもたらし、ビジネスに重大な影響を及ぼす可能性があります。
どのように役に立つのでしょうか カオスエンジニアリングは、回復力の要件を満たすための技術です。 インフラストラクチャ、プラットフォーム、そしてアプリケーションの障害に対する回復力を達成するために使用されます。 カオスエンジニアは、アプリケーション、インフラストラクチャ、あるいはプラットフォームが自己修復でき障害が顧客に目立った影響を与えないことを検証するために、プロアクティブにランダムな障害を注入するカオス実験を行います。 カオス実験の目的は、盲点(例えば、モニタリングや自動スケーリング技術)を発見し、重大なインシデントの最中にチーム間のコミュニケーションを改善することです。 このアプローチは、特に本番環境において、複雑なシステムにおける回復力とチームの自信を高めるのに役立ちます。..
カナリアデプロイメントは、2つの環境から始まるデプロイメント戦略です。 一つはライブトラフィックがある環境で、もう一つは更新されたコードを含む、ライブトラフィックがない環境です。 トラフィックは徐々にアプリケーションの元のバージョンから更新されたバージョンへ移行します。 最初にライブトラフィックの1%を移行し、次に10%、25%と続け、すべてのトラフィックが更新されたバージョンを流れるまで続けます。 組織は本番環境で新しいバージョンのソフトウェアをテストし、フィードバックを得て、エラーを診断し、必要に応じて安定したバージョンに迅速にロールバックすることができます。
「カナリア」という用語は、「炭鉱のカナリア」という慣習に由来します。 この慣習では、カナリア鳥を炭鉱に連れて行き、鉱夫の安全を確保していました。 無臭の有害ガスが存在すると、鳥は死んでしまい鉱夫は迅速に避難する必要があることを知りました。 同様に、更新されたコードに何か問題が発生した場合、ライブトラフィックは元のバージョンに「避難」されます。
解決すべき問題はなんですか テスト戦略をいかに徹底していても、本番環境では常にいくつかのバグが発見されます。 アプリの100%のトラフィックをあるバージョンから別のバージョンに移行することは、より影響力のある障害につながる可能性があります。
どのように役に立つのでしょうか カナリアデプロイメントにより、組織は新しいソフトウェアが実際のシナリオでどのように振る舞うかを、新しいバージョンに大量のトラフィックを移行する前に確認することができます。 この戦略により、組織はダウンタイムを最小限に抑え、新しいデプロイメントに問題がある場合に迅速にロールバックすることができます。 また、全体的なユーザーエクスペリエンスに大きな影響を与えることなく、徹底的な本番アプリケーションのテストを可能にします。..
クライアントサーバーアーキテクチャでは、アプリケーションを構築するロジック(あるいはコード)が2つ以上のコンポーネントに分割されます。 それは作業の実行を要求するクライアント(例えばウェブブラウザで実行されるGmailのウェブアプリケーション)と、その要求を満たす1つ以上のサーバー(例えばクラウド内のGoogleのコンピューターで実行されるメール送信サービス)です。 この例では、あなたが書いた送信メールは、クライアント(ウェブブラウザで実行されるウェブアプリケーション)によってサーバー(あなたの送信メールを受信者に転送するGmailのコンピューター)へ送られます。
これは、(例えばデスクトップアプリケーションのような)すべての作業を一つの場所で行う自己完結型のアプリケーションとは対照的です。 例えば、Microsoft Wordのようなワードプロセッサープログラムは、あなたのコンピューター上にインストールされ完全にあなたのコンピューター上で実行されます。
解決すべき問題はなんですか クライアントサーバーアーキテクチャは、自己完結型のアプリケーションが抱える、定期的な更新という大きな課題を解決します。 自己完結型アプリでは、更新のたびにユーザーは最新バージョンをダウンロードしてインストールする必要があります。 Amazonの商品カタログ全体を、ブラウジングする前に自分のコンピューターにダウンロードすることを想像してみてください!
どのように役に立つのでしょうか リモートサーバーやサービスでアプリケーションロジックを実装することにより、オペレーターはクライアント側のロジックを変更することなく、それを更新できます。 これによって更新をより頻繁に行うことができます。 データをサーバー上に保存することで、多くのクライアントが同じデータを見て共有することができます。 オンラインのワードプロセッサーを使用することと、従来のオフラインのワードプロセッサーを使用することの違いを考えてみてください。 前者ではファイルはサーバー側に存在し、他のユーザーがサーバーからダウンロードするだけで共有することができます。 従来の世界では、ファイルはリムーバブルメディア(フロッピーディスク!)にコピーされ、個別に共有される必要がありました。..
クラウドコンピューティングは、CPU、ネットワーク、ディスクなどの計算資源をインターネット上でオンデマンドで提供し、ユーザーは物理的に離れた場所にある計算能力にアクセスし、使用することができるようにします。 一般に、クラウド基盤が組織専用のものか、オープンな公共サービスのために共有されているかによって、プライベートクラウドとパブリッククラウドに区別されます。
解決すべき問題はなんですか 組織は従来、コンピューティングパワーを拡大しようとする際、主に2つの課題に直面していました。 物理的なサーバーとネットワークをホストするための(新しい)設備を取得、サポート、設計するか、既存の設備を拡張、維持するかです。 クラウドコンピューティングは、企業がコンピューティングニーズの一部をアウトソースできるようにすることで、この課題を解決しています。
どのように役に立つのでしょうか クラウドプロバイダーは、企業がオンデマンドでコンピューティングリソースを借り、使用量に応じて料金を支払うことを可能にし、2つの重要な利点をもたらします。 第一に、企業は新しい物理的なインフラストラクチャを待つことなく、計画し、リソースを費やすことなく、製品やサービスに集中することができます。 そして2つ目は、必要に応じてオンデマンドで拡張できることです。 クラウドコンピューティングでは、必要な分だけインフラを導入することができます。..
クラウドネイティブアプリケーションは、クラウドコンピューティングの技術革新を活用するため特別に設計されています。 これらのアプリケーションは、それぞれのクラウドアーキテクチャと容易に統合でき、クラウドのリソースとスケーリング機能を活用できます。 また、クラウドコンピューティングによるインフラストラクチャの技術革新を活用するアプリケーションのことも指します。 今日のクラウドネイティブアプリケーションには、クラウドプロバイダーのデータセンターで実行されるアプリケーションと、オンプレミスのクラウドネイティブプラットフォームで実行されるアプリケーションがあります。
解決すべき問題はなんですか 従来、オンプレミス環境では、コンピューティングリソースをかなり特化した方法で提供していました。 各データセンターは、アプリケーションを特定の環境に密結合するサービスを持っており、多くの場合、仮想マシンやサービスのようなインフラストラクチャの提供は手作業に大きく依存していました。 その結果、開発者とそのアプリケーションは、特定のデータセンターに制約されることになりました。 クラウド用に設計されていないアプリケーションは、クラウド環境の耐障害性やスケーリング機能を活用することができません。 例えば、正しく起動するために手作業が必要なアプリケーションは、自動的にスケーリングすることができず、障害発生時に自動的に再起動することもできません。
どのように役に立つのでしょうか クラウドネイティブアプリケーションへの万能な道はありませんが、いくつかの共通点はあります。 クラウドネイティブアプリケーションは弾力性があり、管理しやすく、それに付随する一連のクラウドサービスによって支援されます。 さまざまなクラウドサービスによって、高度なオブザーバビリティが有効になり、ユーザーは問題が深刻化する前に発見して対処することができます。 堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、インパクトの大きい変更を頻繁にかつ予想通りに行うことができます。..
クラウドネイティブセキュリティは、セキュリティをクラウドネイティブアプリケーションに組み込むアプローチです。 開発から本番に至るまで、アプリケーションのライフサイクル全体にセキュリティが組み込まれていることを保証します。 クラウドネイティブセキュリティは、従来のセキュリティモデルと同じ基準を保証しつつ、クラウドネイティブ環境の特性、すなわち迅速なコード変更や非常に短命な1インフラストラクチャに適応することを目指します。 クラウドネイティブセキュリティは、DevSecOpsと呼ばれるプラクティスと非常に関係があります。
解決すべき問題はなんですか 従来のセキュリティモデルは、もはや有効でない多くの前提のもとに構築されていました。 クラウドネイティブアプリケーションは頻繁に変わり、多数のオープンソースツールやライブラリを使用し、多くの場合ベンダーが管理するインフラストラクチャで実行され、急速なインフラストラクチャの変更に影響を受けることがあります。 コードレビューや長い品質保証サイクル、ホストベースの脆弱性スキャン、直前のセキュリティレビューは、クラウドネイティブアプリケーションに対応することはできません。
どのように役に立つのでしょうか クラウドネイティブセキュリティは、従来のセキュリティモデルから、リリースサイクルのすべての段階でセキュリティが関与するモデルへと移行することにより、アプリケーションを保護する新しい方法を導入します。 手作業による監査と監視は、大部分が自動スキャンに取って代わられます。 迅速なコードリリースパイプラインは、コンパイル前にコードの脆弱性をスキャンするツールと統合されます。 オープンソースライブラリは、信頼できるソースから取得され脆弱性がないか監視されています。 クラウドネイティブセキュリティモデルは、緩やかな変化ではなく、脆弱性のあるコンポーネントを頻繁に更新したり、インフラストラクチャを定期的に交換したりすることを受け入れます。
訳注:必要に応じてリソースを動的に拡張したり縮小したりするといった性質を持つ ↩︎..
クラウドネイティブテクノロジーは、クラウドネイティブスタックとも呼ばれ、クラウドネイティブアプリケーションを構築するために使用される技術です。 これらの技術により、組織がスケーラブルなアプリケーションを、パブリックやプライベート、ハイブリッドクラウドのようなモダンでダイナミックな環境で、クラウドコンピューティングの利点を最大限に活用しながら、構築や実行することができます。 コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャなど、クラウドコンピューティングの機能を活用するために1から設計されたアプローチです。
解決すべき問題はなんですか クラウドネイティブスタックには多くの異なる技術カテゴリーがあり、様々な課題に対応しています。 CNCFクラウドネイティブランドスケープを見ると、いかに多くの異なる領域に触れているかわかると思います。 しかし高いレベルでは、主に従来のIT運用モデルのマイナス面に取り組んでいます。 含まれる課題としては、拡張性がありフォールトトレラントな自己修復型アプリケーションの実現が困難であること、リソースの活用が非効率であることなどが挙げられます。
どのように役に立つのでしょうか それぞれの技術は特定の問題に対応していますが、全体として、クラウドネイティブテクノロジーは弾力性があり管理可能で観測可能な疎結合のシステムを実現します。 堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で影響力の大きい変更を頻繁にかつ予測通りに行うことができます。 クラウドネイティブシステムの望ましい特性は、クラウドネイティブスタックで実現することが容易になりました。..
クラウドネイティブ用語集 クラウドネイティブ用語集は、技術者だけでなくビジネスサイドの人々にもわかりやすく伝えることで、複雑なことで有名なクラウドネイティブの領域を、人々にとってよりシンプルにすることを目指しています。そのために、シンプルであること(例:バズワードを使わないシンプルな言葉、テクノロジーを使う人なら誰でも共感できる例、不必要な詳細は省くなど)に重点を置いています。この用語集は、CNCFビジネスバリュー分科会(BVS, Business Value Subcommittee)が主導するプロジェクトです。
貢献 クラウドネイティブ用語集の変更、追加、改良を提案することを歓迎します。 私たちは、共有語彙目録を開発・改良するために、CNCFが管理するコミュニティ主導のプロセスを採用しています。 この用語集は、クラウドネイティブテクノロジーに関する共有語彙を整理するために、ベンダーニュートラルなプラットフォームを提供します。 プロジェクトの目的と憲章を遵守するすべての参加者からの投稿を歓迎します。
貢献したい人は、GitHubのissueを提出するか、プルリクエストを作成することができます。 スタイルガイドに従うことを確認し、貢献の方法ドキュメントを読み, CNCF Slackの#glossary チャンネルに参加してください。 また、用語集を母国語に翻訳する手伝いをしたい人のために、#glossary-localizations チャンネルがあります。
謝辞 クラウドネイティブ用語集は、CNCFマーケティング委員会(ビジネスバリュー分科会)によって始められ、 Catherine Paganini, Chris Aniszczyk, Daniel Jones, Jason Morgan, Katelin Ramer, Mike Foster その他多くの貢献者による貢献が含まれています。 全ての貢献者リストについては、GitHub page を参照してください。
用語集は Seokho Son, Noah Ispas, Jihoon Seo, Nate W. そしてJorge Castroによってメンテナンスされています。
Catherine Paganini, Jason Morgan は名誉メンテナーであり、長年にわたる彼らの貴重な貢献に深く感謝しています。
クラウドネイティブ用語集の日本語化は、Kaito Ii、Kohei Ota、Yuichi Nakamura、MItabashi、HANABE926、Junya Okabe、Akira Aiura、shizhenhu、Nao Nishijimaの貢献を通じて開始されました。 クラウドネイティブ用語集の日本語への翻訳とローカライゼーションに興味のある方は、#glossary-localization-japanese チャンネルにご参加ください。
ライセンス すべてのコードの貢献はApache 2.0ライセンスに基づいています。 ドキュメントはCC BY 4.0に基づいて配布されます。..
クラスターは、共通の目的に向けて連携して働くコンピューターやアプリケーションのグループです。 クラウドネイティブコンピューティングの文脈では、この用語は通常Kubernetesに適用されます。 Kubernetesクラスターは、通常異なるマシン上でそれぞれのコンテナ内で実行される一連のサービス(あるいはワークロード)です。 これらすべてのコンテナ化されたサービスの集合がネットワーク上で接続され、クラスターを形成しています。
解決すべき問題はなんですか 単一のコンピューター上で動作するソフトウェアには、単一障害点があります。 もしそのコンピューターがクラッシュしたり、誰かが誤って電源ケーブルを抜いたりした場合、 ビジネス上重要なシステムが利用できなくなる可能性があります。 そのため、モダンなソフトウェアは一般的に分散アプリケーションとして構築され、クラスターとしてまとめられます。
どのように役に立つのでしょうか クラスター化された分散アプリケーションは複数のマシン上で実行され、単一障害点がなくなります。 しかし、分散システムを構築することは非常に難しいです。 実際、分散システムはコンピューターサイエンスの中で一つの分野として扱われています。 グローバルなシステムの必要性と長い年月をかけた試行錯誤が、クラウドネイティブ技術と呼ばれる新たなタイプの技術スタックの開発につながりました。 これらの新しい技術は、分散システムの運用と作成を容易にするための構成要素となります。..
コンテナは、コンピューターのオペレーティングシステムがリソースと機能面での制限を管理する、実行中のプロセスです。 コンテナプロセスで利用可能なファイルは、コンテナイメージとしてパッケージ化されています。 コンテナは一つのマシン上で同時に実行されますが、通常オペレーティングシステムは別々のコンテナプロセスが互いに干渉するのを防ぎます。
解決すべき問題は何ですか コンテナが利用可能になる前は、アプリケーションを実行するためには別々のマシンが必要でした。 各マシンはそれぞれのオペレーティングシステムを必要とし、CPU、メモリ、ディスクスペースを消費します。 これらは全て個々のアプリケーションが動作するために必要なものです。 さらに、オペレーティングシステムのメンテナンス、アップグレード、起動は大きな手間のかかる作業です。
どのように役に立つのでしょうか コンテナはオペレーティングシステムとそのマシンリソースを共有し、オペレーティングシステムのリソースオーバーヘッドを分散させ、物理マシンを効率的に使用します。 これは通常コンテナが互いに干渉することが制限されているため、実現できます。 これにより、同じ物理マシン上で多くのアプリケーションを実行することができます。
しかし、いくつかの制限もあります。 コンテナは同じオペレーティングシステムを共有するため、プロセスは代替手段と比べて安全性が低いと考えられます。 またコンテナは、共有されるリソースへの制限を必要とします。 リソースを保証するために、管理者はメモリやCPUの使用を制限し、他のアプリケーションのパフォーマンスが低下しないようにする必要があります。..
コンテナオーケストレーションとは、流動的な環境において、コンテナ化されたアプリケーションのライフサイクルを管理し自動化することを指します。 これはコンテナオーケストレータ(ほとんどの場合はKubernetes)を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。 オーケストレーションという言葉は比喩です。 オーケストレーションツールは、音楽指揮者のようにコンテナを指揮し、すべてのコンテナ(または音楽家)が適切に機能するようにします。
解決すべき問題は何ですか スケールに応じてマイクロサービス、セキュリティ、ネットワーク通信や一般的な分散システムを管理することは、手動で行うには難しく、場合によっては不可能です。 コンテナオーケストレーションにより、これらすべての管理タスクを自動化することができます。
どのように役に立つのでしょうか コンテナオーケストレーションツールは、ユーザーがシステムの状態を決定することを可能にします。 まず、システムがどのようにあるべきかを宣言します(例えばx個のコンテナ、y個のPodなど)。 その後、オーケストレーションツールは自動的にインフラを監視し、現状が宣言した状態から逸脱した場合には修正します(例えばコンテナがクラッシュした場合に新しいコンテナを立ち上げるなど)。 この自動化により、プロビジョニング、デプロイメント、スケーリング(増減)、ネットワーキング、ロードバランシングといった、エンジニアリングチームが手作業で行う複雑な運用タスクが大幅に簡素化されます。..
コンテナ化は、アプリケーションとその依存関係をコンテナイメージにまとめるプロセスです。 コンテナのビルドプロセスでは、Open Container Initiative(OCI)標準への準拠が必要です。 出力がこの標準に準拠したコンテナイメージであれば、どのコンテナ化ツールを使用しても問題ありません。
解決すべき問題は何ですか コンテナが普及する前は、組織は仮想マシン(VM)に依存して、単一のベアメタルマシン上で複数のアプリケーションをオーケストレーションしていました。 VMはコンテナよりも非常に大きく、実行にはハイパーバイザーが必要です。 これらの大きなVMテンプレートのストレージ、バックアップ、転送により、VMテンプレートの作成もより遅くなります。 さらに、VMは不変性の原則に反する構成ドリフトに悩まされることがあります。
どのように役に立つのでしょうか コンテナイメージは(従来のVMとは異なり)軽量です。 またコンテナ化のプロセスには依存関係のリストが記載されたファイルが必要です。 このファイルはバージョン管理が可能で、ビルドプロセスを自動化できます。 これにより組織は他の優先事項に集中でき、自動化されたプロセスがビルドを担当します。 コンテナイメージは、その厳密な内容と設定に関連付けられた一意の識別子によって保存されます。 コンテナがスケジュールされ再スケジュールされると、常に初期状態にリセットされるため、構成ドリフトが解消されます。..
サイト信頼性エンジニアリング(SRE: Site Reliability Engineering)は、オペレーションとソフトウェアエンジニアリングを組み合わせた分野です。 後者では、特にインフラストラクチャとオペレーションの問題に応用されます。 つまり製品機能を構築する代わりに、サイト信頼性エンジニアは、アプリケーションを実行するためのシステムを構築します。 DevOpsとの類似点がありますが、DevOpsがコードを本番環境に導入することに焦点を当てているのに対し、SREは本番環境で実行中のコードが適切に機能することを保証します。
解決すべき問題はなんですか アプリケーションを高い信頼性で実行するためには、パフォーマンスモニタリング、アラート、デバッグ、トラブルシューティングなど、複数の機能が必要です。 これらがなければ、システムオペレーターは問題に対応するだけで、積極的にそれらを回避しようとすることはできません。 — ダウンタイムは時間の問題となるだけです。
どのように役に立つのでしょうか SREのアプローチは、基盤となるシステムを継続的に改善することで、ソフトウェア開発プロセスのコスト、時間、労力を最小限に抑えます。 システムは、インフラストラクチャとアプリケーションコンポーネントを継続的に測定し監視します。 何か問題が発生した場合、システムはサイト信頼性エンジニアにいつ、どこで、どのように修正するかを指摘します。 このアプローチを用いて運用タスクを自動化することで、高度にスケーラブルで信頼性の高いソフトウェアシステムを作成するのに役立ちます。..
シフトレフトの「レフト」はソフトウェア開発ライフサイクルのより初期のステージを指します。 ライフサイクルをステージが左から右へと実行される線と考えます。 シフトレフトは、テストやセキュリティなどの開発プラクティスをソフトウェア開発ライフサイクルの終盤ではなく、早い段階で実施することです。
もともとはテストプロセスを早い段階で行うことを指していましたが、現在ではセキュリティやデプロイなど、ソフトウェア開発やDevOpsの他の側面にも適用されることがあります。
解決すべき問題はなんですか セキュリティ問題や、バグ、ソフトウェアの欠陥は開発サイクルの後期やデプロイ後に発見された場合、とりわけソフトウェアが既に本番環境へデプロイされていた場合、修正はより難しく高コストになる可能性があります。
どのように役に立つのでしょうか ソフトウェア開発におけるシフトレフトの考え方を適用することで、チームは開発ライフサイクル全体を通してテストやセキュリティを実装することができます。 テストとセキュリティに対する責任はソフトウェアエンジニアから品質保証、運用まで開発チーム全体にわたって共有さるものであるため、誰もがアプリケーションの安定性とセキュリティを担保する役割を果たします。
加えて、シフトレフトは継続的な改善を可能とし、ウォーターフォール開発よりもアジャイル開発により実践されます。 チームは小さな改善を繰り返し行い、より早い段階で問題を特定することができます。 このアプローチにより、エンジニアは設計とアーキテクチャフェーズにおいて、セキュリティと安全な開発プラクティスを適用することが可能になります。 開発サイクル全体を通してテストを行うことは、ソフトウェアのリリース前に必要となるテスト時間を短縮します。
多数のソフトウェアツールやSaaSソリューションは、これらのプラクティスを左にシフトすることを支援します。 ただし、シフトレフトはチーム内のプロセスの改善や文化の改革を通しても実践することができます。..
スケーラビリティは、システムがどれだけ拡張できるのかを示す特性を指します。
この特性により、システムが行うべき任意の処理に対して、その処理能力を増強することが可能となります。
例として、Kubernetesクラスタは、コンテナ化されたアプリの数を増減することでスケールしますが、そのスケーラビリティはいくつかの要素に依存します。 ノードの数、各ノードが処理できるコンテナの数、コントロールプレーンがサポート可能なレコードとオペレーションの規模と関係しています。
スケーラブルなシステムは、キャパシティの追加を容易に行えます。
私たちはスケーリングアプローチを2種類に分類します。 水平スケーリングでは、増加した負荷を処理するためにより多くのノードを追加します。 一方で、垂直スケーリングでは、個々のノードがより多くのトランザクションを実行するために性能向上します(例えば、個別のマシンにより多くのメモリやCPUを追加すること)。
スケーラブルなシステムは、容易に変更することができ、ユーザーのニーズに応えることができます。..
ステートフル(およびステートレス)アプリについて話すとき、ステートとは、アプリが設計通りに機能するために必要なあらゆるデータを指します。 例えば、カートの情報を保存しているオンラインショップなどはステートフルアプリです。
今日、私たちが使用するほとんどのアプリケーションは少なくとも部分的にステートフルです。 しかし、クラウドネイティブ環境では、ステートフルアプリは難しいです。 これは、クラウドネイティブアプリが非常に動的だからです。 これらはスケーリング、再起動、別の場所への移動が可能ですが、それでもそのステートにアクセスできる必要があります。
そのため、ステートフルアプリには、データベースのようにどこからでもアクセス可能な何らかのストレージが必要です。..
ステートレスアプリケーションは、送信される各リクエストをそれが初めて送信されたかのように処理します。 このアプリは以前の相互通信やユーザーセッションデータを覚えていません。 以前の相互通信からのデータはステートと呼ばれ、そのデータがどこにも保存されていないため、これらのアプリはステートレスです。 例を挙げると、検索エンジンを使用していて、その検索が中断された場合(例えばウィンドウを閉じた場合)その検索結果は失われます。 最初からやり直す必要があります。
一方、以前の相互通信を考慮しながらリクエストを処理するアプリケーションはステートフルアプリケーションと呼ばれます。..
このスタイルガイドは、用語集の読者、定義の構造、必要な詳細度、一貫したスタイルを維持する方法について理解するのに役立ちます。
クラウドネイティブ用語集は、CNCFリポジトリのデフォルトスタイルガイドに従っています。 さらに、以下のルールにも従っています:
専門用語や流行語は避け、シンプルでわかりやすい言葉を使う。 口語を避ける 書き言葉や具体的な言葉を使う 前置詞と冠詞の縮約を含めない 受動態は慎重に使う 肯定形でのフレーズを目指す 引用符以外の感嘆符を使用しない 誇張しないこと 繰り返しを避ける 簡潔であること 読者 用語集は、技術者および技術者以外の読者を対象として書かれています。 技術的な知識を前提とせず、定義が簡単な言葉で説明されていることを確認してください。詳しくは、以下の定義をご覧ください。
最小限の定義 私たちの目標は、クラウドネイティブの用語を誰でも本当に簡単に理解できるようにすることです。 そのため、シンプルであることに重点を置いています。 つまり、テクノロジーを使っている人なら誰でも共感できるような例を用いて、明確でシンプルな言葉を使うということです(詳しくは後述します)。また、少なくとも技術的な観点からは、最小限の定義を提供します。 文脈や例を節約するつもりはありません。結局のところ、それらは読者がコンセプトを理解するのに役立ちますが、技術的な詳細が理解に必要でない場合は、それを省略します。 目標は、物事を複雑にし過ぎないことです。読者が基本的なコンセプトを理解したら、他のリソースでより深く掘り下げることができるようにします。その部分はこの用語集の範囲外です。
定義のテンプレート 各用語はマークダウンファイルに格納され、このテンプレートに従います:
— title: status: category: — 技術やコンセプトの簡単な要約。 ## 解決すべき問題はなんですか 取り組んでいる問題について数行。 ## どのように役に立つのでしょうか それがどのように問題を解決するのか数行。 タイトル タイトル ラベルは、常に定義レイアウトの先頭に位置し、その値はタイトルケースであるべきです。
— title: Definition Template 状態 状態 ラベルは、タイトルラベルの後に表示されます。状態ラベルは、定義が十分に吟味されているか、より多くの努力を必要とするかを示します。
有効な値は以下の通りです:
Completed(完了) Feedback Appreciated(フィードバックが必要です) Not Started(未着手) 完了した定義に対して、いつでもissueを開くことができます。定義が流動的な場合、そのステータスはFeedback Appreciatedに変更されます。
— title: Definition Template status: Feedback Appreciated タグ ステータスラベルの後に、タグ ラベルが続きます。 タグが意味を持ち、結果としてユーザーの役に立つためには、タグを厳密な意味で使うことになります。 多くのタグを付けると、その意味が薄れるだけです。 他のクラウドネイティブの概念を理解するために必要な用語であることを示すfundamental(基礎)を除き、ほとんどの用語のタグは1つだけとなる可能性があります。
注意: 管理者の承認がない限り、新しいタグを導入しないでください。エントリにタグを追加する場合は、以下のリストにあるように正確に綴るようにしてください(単数形、タイプミスなし)。
現在のタグは以下の通りです:..
セキュリティカオスエンジニアリング(SCE)は、カオスエンジニアリングに基づく規律です。 SCEは、分散システムに対して積極的なセキュリティ実験を行い、乱雑や悪意のある条件に耐えるシステムの能力に信頼を築くために行われます。 セキュリティカオスエンジニアは、定常状態、仮説、継続的検証、学習した教訓、および緩和の実施を含む科学的方法のループを使用してこれを達成します。
解決すべき問題はなんですか サイト信頼性エンジニア(SRE)とサイバーセキュリティエンジニアの主な優先事項は、できるだけ早くサービスを復旧させ、ゼロダウンタイムを目指してビジネスへの影響を最小限に抑えることです。 SREおよびサイバーセキュリティエンジニアは、障害発生前および障害発生後のインシデント状況の両方に対処します。 ほとんどのセキュリティ問題は、迅速に発見および修正が難しく、アプリケーションやシステムの機能に影響を与えます。 さらに、セキュリティインシデントは、開発フェーズ中に発見するのが通常難しいものです。
どのように役に立つのでしょうか セキュリティカオスエンジニアリングは、オブザーバビリティとサイバーレジリエンスの実践を中心に構築されています。 これは「未知の未知」を明らかにし、システムに自信を持ち、サイバーレジリエンスを向上させ、オブザーバビリティを改善することを目指しています。
エンジニアリングチームは、複雑なインフラストラクチャ、プラットフォーム、および分散システム内のセキュリティ問題に関する理解を徐々に向上させます。 SCEは、製品全体のサイバーレジリエンスを改善し、隠されたセキュリティ問題を明らかにし、典型的な盲点を露呈し、チームを重要なエッジケースに備えさせます。 このアプローチは、SRE、DevOps、およびDevSecOpsエンジニアが、システムに自信を持ち、サイバーレジリエンスを向上させ、オブザーバビリティを改善するのに役立ちます。..
ゼロトラストアーキテクチャは、ITシステムの設計と実装において信頼を完全に取り除くアプローチを推奨します。 その核心の原則は「決して信頼せず、常に検証する」であり、デバイスやシステムは、システムの他のコンポーネントと通信する際に常に事前に自分自身を検証します。 今日の多くのネットワークは、企業ネットワークの信頼された境界内にあるため、システムやデバイスは互いに自由に通信することができます。 ゼロトラストアーキテクチャは、ネットワークの境界内にあっても、システム内のコンポーネントは通信する前に検証しなければならないという正反対のアプローチを取ります。
解決すべき問題はなんですか 伝統的な信頼ベースのアプローチでは、企業ネットワークの境界内に存在するシステムやデバイスに対して、信頼があるため問題がないという前提があります。 しかし、ゼロトラストアーキテクチャは、その信頼が脆弱性になると認識しています。 攻撃者が信頼されたデバイスへのアクセスを獲得した場合、そのデバイスに与えられている信頼のレベルとアクセスに依存してシステムは攻撃に対して脆弱になります。 なぜなら、攻撃者は信頼されたネットワークの境界内におり、システム内を横断的に移動することができるからです。 ゼロトラストアーキテクチャでは、信頼が取り除かれるため攻撃者はシステム内をさらに横断する前に検証を強いられ、結果としてアタックサーフェスが縮小します。
どのように役に立つのでしょうか ゼロトラストアーキテクチャを採用することで、主な利点としてセキュリティが向上し、アタックサーフェスが縮小します。 企業システムから信頼を取り除くことで、攻撃者がシステムの他の領域へアクセスするために通過しなければならないセキュリティゲートの数と強度が増加します。..
ブルーグリーンデプロイメントは、最小限のダウンタイムで稼働中のコンピューターシステムを更新する戦略です。 オペレーターは、“ブルー"と"グリーン"と呼ばれる2つの環境を維持します。 一方は本番トラフィックを処理し(現在すべてのユーザーが使用しているバージョン)、もう一方が更新されます。 アクティブではない(グリーン)環境のテストが終了すると、本番トラフィックは(しばしばロードバランサーを使用して)切り替えられます。 ブルーグリーンデプロイメントは通常、多くのサービスを含む全環境を一度に切り替えることを意味します。 紛らわしいことに、時々この用語はシステム内の個々のサービスに関して使用されます。 このあいまいさを避けるため、個々のコンポーネントを指す場合には"ゼロダウンタイムデプロイメント"という用語が好まれます。
解決すべき問題はなんですか ブルーグリーンデプロイメントは、後方互換性がないために"ロックステップ"で変更する必要があるソフトウェアを更新する際に最小限のダウンタイムを可能にします。 例えば、ウェブサイトとデータベースから成るオンラインストアの更新を考えます。 新しいバージョンのデータベースが古いバージョンのウェブサイトと互換性がなく、その逆も同様である場合、ブルーグリーンデプロイメントが適しています。 このインスタンスでは、両方を同時に変更する必要があります。 これが本番システムで行われた場合、顧客はダウンタイムに気付くでしょう。
どのように役に立つのでしょうか ブルーグリーンデプロイメントは、最小限のダウンタイムで更新する必要がある、クラウドネイティブではないソフトウェアに適した戦略です。 しかし、その使用は通常レガシーソフトウェアが再設計され、コンポーネントを個別に更新できるようにする必要があるという"臭い"を放ちます。..
ベアメタルとは物理コンピューターを意味し、具体的にはサーバーのことでありオペレーティングシステムが1つしかないものです。 最近のコンピューティングでは、サーバーの多くが仮想マシンであるため、この区別は重要です。 物理サーバーは、一般的に強力なハードウェアを内蔵したかなり大型のコンピューターです。 仮想化せずに、物理ハードウェア上にオペレーティングシステムをインストールし直接アプリケーションを実行することを"ベアメタル"上で実行すると呼ばれます。
解決すべき問題はなんですか 1つのオペレーティングシステムと1台の物理コンピューターの組み合わせはコンピューティングの原型です。 物理コンピューターのすべてのリソースがオペレーティングシステムで直接利用可能であり、仮想化レイヤーが存在しないため、オペレーティングシステムの命令をハードウェアに変換する際に人工的な遅延が発生しません。
どのように役に立つのでしょうか コンピューターのすべての計算リソースを単一のオペレーティングシステムに割り当てることで、オペレーティングシステムに最高のパフォーマンスを提供できる可能性があります。 ハードウェアリソースに極めて高速にアクセスしなければならないワークロードを実行する必要がある場合、ベアメタルが適切なソリューションかもしれません。
クラウドネイティブアプリケーションのコンテキストでは、私たちは一般的にパフォーマンスを、水平スケーリング(リソースプールにマシンを追加する)で処理できる多数の並行イベントへのスケーリングという観点から考えます。 しかし、ワークロードによっては垂直スケーリング(既存の物理マシンにさらにパワーを追加する)が必要な場合や、極めて高速な物理ハードウェアのレスポンスが必要になる場合はベアメタルが適しています。 また、ベアメタルにおいては、タスクを達成するために、物理ハードウェアや場合によってはハードウェアドライバをチューニングすることもできます。..
マイクロサービスアーキテクチャは、アプリケーションを個々の独立した(マイクロ)サービスに分割するアーキテクチャ手法で、各サービスは特定の機能に焦点を当てています。 これらのサービスは密接に連携して動作し、エンドユーザーには単一のエンティティとして見えます。 例として、Netflix を考えてみます。そのインターフェイスは、ビデオへのアクセス、検索、プレビューが可能です。 これらの機能は、ブラウザでの認証、検索、プレビューの実行など、それぞれ一つの機能を扱う小さなサービスによって実現されている可能性が高いです。
このアーキテクチャ手法により、モノリシックアプリケーション(以下に詳細あり)のようにすべてが密接に結合している場合よりも、開発者は新機能を迅速に導入したり機能を更新したりすることができます。
解決すべき問題はなんですか アプリケーションは、さまざまなパーツで構成され、それぞれが特定の能力を担当します。 特定の機能に対する需要は、アプリケーションの他のパーツに対する需要と連動して必ず増減するわけではありません。 Netflix の例に戻りましょう。 例えば、大規模なマーケティングキャンペーンの後で、Netflix の契約者数が急増したが、その日の早い時間帯におけるストリーミングは概ね安定しているとします。 契約者数の急増は、平常時より多くのキャパシティを要求します。 伝統的な手法(モノリシックアプローチ)の場合では、増加に対応するためにアプリ全体をスケールアップする必要がありました。 これは非常に非効率的なリソースの使い方です。
また、モノリシックアーキテクチャは、開発者が設計の落とし穴に陥りやすくするものです。 すべてのコードが一か所にあるため、そのコードが密結合になりやすく、関心の分離の原則を適用することが難しくなります。 さらに、多くの場合、モノリスはデプロイする前にコードベース全体を理解する必要性を生じさせます。 マイクロサービスアーキテクチャは、こうした課題への対応策です。
どのように役に立つのでしょうか 機能を異なるマイクロサービスに分離することにより、それらを独立してデプロイ、アップデート、スケールすることが容易になります。 また、意図せずアプリケーションの他のパーツに悪影響を与えることなく、大きなアプリケーションの一部に対して複数のチームが同時に作業することを可能にします。 マイクロサービスアーキテクチャは多くの問題を解決しますが、デプロイして追跡する必要があるものが桁違いに増えるため、運用上のオーバーヘッドも発生させます。 多くのクラウドネイティブテクノロジーは、マイクロサービスのデプロイと管理を容易にすることを目指しています。..
マルチテナンシーとは、複数のテナントにサービスを提供する単一のソフトウェアインストールを指します。 テナントとは、自身のデータセットでソフトウェアを利用するユーザー、アプリケーション、あるいはそれらのグループのことです。 これらのテナントは(所有者による明示的な指示がある場合を除いて)データを共有せず、互いの存在を意識することもありません。
テナントは、1人の独立したユーザーで1つのログインIDを持つほど小さくなり得ます。 例えば、個人の生産性を高めるソフトウェアを考えてみてください。 あるいは、何千ものログインIDを持つ企業全体ほど大きくもなり得ます。 これらは、それぞれが独自の権限を持ちつつも多方面で相互に関連しています。 マルチテナントソフトウェアの例には、Google Mail、Google Docs、Microsoft Office 365、Salesforce CRM、Dropboxなどがあり、完全または部分的にマルチテナントソフトウェアとして分類されます。
解決すべき問題はなんですか マルチテナンシーがなければ、各テナントに専用のソフトウェアインストールが必要になります。 これはリソース利用とメンテナンスの労力を増加させ、最終的にはソフトウェアコストを増加させます。
どのように役に立つのでしょうか マルチテナントソフトウェアは、各テナントに分離された環境(作業データ、設定、認証情報リストなど)を提供し、同時に複数のテナントにサービスを提供します。 テナントの観点から見れば、各々が専用のソフトウェアインストールを持っているように見えますが、実際にはすべてが1つを共有しています。 これはソフトウェアをサーバー上で実行し、テナントがインターフェイスおよび/あるいはAPIを通じてネットワーク経由で接続できるようにすることで実現されます(クライアントサーバーアーキテクチャも参照)。 マルチテナントソフトウェアを使用すると、テナントはお互いに影響を与えることなく定義された制御された方法でのみ、1つのインストールのリソースを共有することができます。 ソフトウェア提供者側の結果としてのリソース節約は、テナントに渡されユーザーにとってのソフトウェアコストを大幅に削減することができます(改めてウェブベースのEメールやドキュメントエディターを考えてみてください)。
関連する用語はありますか マルチテナンシーはSaaSと同義ではありません。 しかし、SaaSがマルチテナントであることは非常に一般的であり、その主要な利点の1つとしてマルチテナンシーを特徴づけることがあります。..
モノリシックアプリケーションは単独で配置できるプログラムにすべての機能を格納しており、アプリケーションを開発する時に最も簡単かつ手軽な出発点とされています。 しかし、アプリケーションが複雑になると、モノリスのメンテナンスが難しくなることがあります。 また、同じコードベースで作業する開発者が増えるため、変更が競合したり、開発者の間で直接コミュニケーションを取る必要性が高まります。
解決すべき問題はなんですか アプリケーションをマイクロサービスに移行するとテスト、デプロイ、実行などの運用オーバーヘッドが増加します。 そのため、製品ライフサイクルの初期段階には製品を複雑化させる物は先送り、製品が成功したと判断されるまでモノリシックアプリーケーションで設計することが有利な場合もあります。
どのように役に立つのでしょうか 適切に設計されたモノリスはアプリケーションを起動して実行する最も簡単な方法であるため、簡潔さを維持できます。 モノリシックアプリーケーションがビジネス的に価値があると証明されれば、アプリケーションを分割し、マイクロサービス化させる事も可能です。 価値が証明される前に技術的努力を費やし、マイクロサービス基盤でアプリケーションを開発することは早計である可能性があります。 アプリケーションが価値を生まなければ、その努力も無駄になるためです。..
一般的に、ランタイムはソフトウェアの一部を実行します。 これは、プログラムのコマンドをオペレーティングシステムのアクションに変換する、下層レイヤーとなるオペレーティングシステムの抽象化です。
クラウドネイティブの文脈では、ランタイム は一般的にコンテナランタイムを指します。 コンテナランタイムは、Open Container Initiativeの仕様を具体的に実装します。 これは異なるコンテナオーケストレーション技術の間で一貫した取り扱いを保証するためです。
解決すべき問題はなんですか コンテナランタイムの抽象化がなければ、アプリケーションは各オペレーティングシステムのすべての技術を取り扱う必要があります。 結果としてアプリの実行の複雑さが増します。
どのように役に立つのでしょうか コンテナランタイムは、Kubernetesのようなコンテナオーケストレーターに必要なコンポーネントです。 これらは主に3つのことを行う、コンテナライフサイクルを処理します。 まずコンテナイメージがどのように指定され、ランタイムがそれらをどのように取得するかを定義します。 次にこれらのイメージがどのように展開、レイヤー化、マウント、実行されるかを扱います。 さらにランタイムは、これらのオペレーティングシステムレベルのアクションの面倒を見ることで、ハードウェアリソースを管理します。 これにはリソースの割り当てと隔離が含まれます。 時間が経つにつれて、さまざまなコンテナランタイム製品が進化し、OCIの仕様がコンテナランタイムの標準となりました。
この標準を導入することにより、エンドユーザーは任意のOCIに準拠したランタイムを、任意のOCIに準拠したコンテナオーケストレーター(例えばKubernetes)と組み合わせることができます。
関連する用語はありますか クラウドネイティブ コンテナ化 コンテナオーケストレーション マイクロサービスアーキテクチャ..
仮想マシン(VM)とは、特定のハードウェアに縛られないコンピューターとそのオペレーティングシステムのことです。 VMは、1台の物理コンピューターを複数の仮想コンピューターに分割する仮想化に依存しています。 この分割は、組織やインフラプロバイダーに、下層のハードウェアに影響を与えることなく、VMを簡単に作成、破棄することを可能にします。
解決すべき問題はなんですか 仮想マシンは仮想化を利用しています。ベアメタルマシンは単一のオペレーティングシステムに縛られているので、マシンのリソースをどれだけ使えるかはある程度制限されます。また、オペレーティングシステムも単一の物理マシンに縛られているので、その可用性はハードウェアに直結します。 物理マシンがメンテナンスやハードウェア故障によりオフラインになると、オペレーティングシステムもオフラインになります。
どのように役に立つのでしょうか オペレーティングシステムと物理マシンとの直接的な関係を取り除くことで、プロビジョニングの時間やハードウェア利用率、弾力性といったベアメタルマシンが抱えるいくつかの問題を解決することができます。
新しいハードウェアの購入やインストール、あるいはそれをサポートするための設定が必要ないため、新しいコンピューターのプロビジョニングの時間が劇的に短縮されます。 VMは、1台の物理マシン上に複数の仮想マシンを配置することで、既存の物理ハードウェアリソースをより有効に活用できます。 特定の物理マシンに縛られないため、VMは物理マシンよりも耐障害性に優れています。 物理マシンがオフラインになる必要がある場合、その上で稼働しているVMを、ほとんどない、あるいは全く停止時間なしで別のマシンに移動させることができます。..
クラウドネイティブコンピューティングにおける仮想化とは、 サーバーとも呼ばれる物理コンピューターを確保し、その上で複数の隔離されたオペレーティングシステムを動かせるようにするプロセスを指します。 そういった隔離されたオペレーティングシステムとそれらに割り当てられた計算資源(CPU、メモリ、ネットワーク)は、仮想マシンやVMと呼ばれます。 仮想マシンはソフトウェア的に作り出されたコンピューターを意味します。 仮想マシンは実際のコンピューターのように見えたり動作したりしますが、他の仮想マシンとハードウェアを共有しています。 クラウドコンピューティングは主に仮想化技術の恩恵を受け提供されています。 例えば、AWSで作成し使用できる「コンピューター」は実際のところはVMです。
解決すべき問題はなんですか 仮想化によって、我々は多くの課題に対処することができます。 例えば、仮想化によって同じ物理的なハードウェア上により多くのアプリケーションを互いに隔離しつつ動かすことができるので、セキュリティを保ったまま物理マシンの使用率を改善することができます。
どのように役に立つのでしょうか 仮想マシン上で動作しているアプリケーションは、お互いが物理的なコンピューターを共有していることを意識しません。 また、データセンター利用者は仮想化によって新たなコンピューター(すなわちVM)を数分以内に起動できるようになります。 その際に新しいコンピューターをデータセンターに追加する際の物理的な制約を気にする必要はありません。..
継続的インテグレーション(CI)とは、コードの変更を可能な限り定期的に統合することを指します。 CIは継続的デリバリー(CD)の前提条件です。 伝統的に、CIのプロセスはバージョンコントロールシステム(GitやMercurial、あるいはSubversion)にコードの変更がコミットされることで開始し、CDシステムで利用できるようになったテスト済みの成果物で終了します。
解決すべき問題はなんですか ソフトウェアシステムはしばしば大規模で複雑であり、多くの開発者が維持や更新をしています。 システムの異なる部分で並行して作業を行う開発者たちは、意図せずに互いの作業を壊すような矛盾した変更を加えることがあります。 さらに、同じプロジェクトに複数の開発者が取り組む場合、テストやコード品質の計測といった日常的なタスクは、各開発者によって繰り返される必要があり、時間の無駄になります。
どのように役に立つのでしょうか CIソフトウェアは、開発者が変更をコミットするたびに、コードの変更がスムーズにマージできることを自動的に確認します。 CIサーバーを使用してコードの品質チェック、テスト、さらにはデプロイメントを行うことは、広範囲にわたって一般的に行われる実践です。 そのため、CIはチーム内の品質管理を具体的に実行する方法となります。 CIを利用することで、ソフトウェアチームはすべてのコードのコミットを、具体的な失敗か実用的なリリース候補のいずれかにすることができます。
関連する用語はありますか 継続的デリバリー 継続的デプロイメント..
継続的デプロイメント(しばしばCDと略される)は、完成したソフトウェアを直接本番環境にデプロイするという点で継続的デリバリーより一歩進んでいます。 継続的デプロイメント(CD)は継続的インテグレーション(CI)と密接に関連しており、しばしばCI/CDと呼ばれます。 CIプロセスは特定のアプリケーションへの変更が有効であるかどうかをテストし、CDプロセスはコードの変更を自動的に組織のテスト環境や本番環境にデプロイします。
解決すべき問題はなんですか 新しいソフトウェアバージョンのリリースは、労力がかかりエラーが発生しやすいプロセスです。 また本番環境でのインシデントを避け、エンジニアが通常の業務時間外に対応する時間を減らすため、組織が頻繁に行わないことも多いです。 伝統的なソフトウェアデプロイメントモデルでは、ソフトウェアのリリースプロセスが組織の安定性と機能の速度の両方に関するニーズを満たせず、組織を悪循環に陥らせます。
どのように役に立つのでしょうか リリースサイクルを自動化し、組織が頻繁に本番環境へのリリースを強制することにより、CDは運用チームに対して、CIが開発チームにもたらした効果を実現します。 具体的には、運用チームが本番へのデプロイメントの際に煩雑でエラーが発生しやすい部分を自動化するように促し、全体的なリスクを減少させます。 また組織が本番環境の変更を受け入れ、適応する能力を向上させ、より高い安定性につながります。
関連する用語はありますか 継続的インテグレーション 継続的デリバリー..
継続的デリバリー(しばしばCDと略される)は、コードの変更が自動的に受け入れ環境にデプロイされる(または継続的デプロイメントの場合、本番環境にデプロイされる)一連の実践を指します。 CDは、ソフトウェアがデプロイメント前に適切にテストされていることを保証する手順を重要視し、必要と判断された場合に変更をロールバックする方法を提供します。 継続的インテグレーション(CI)は継続的デリバリーに向けた最初のステップです(つまり、テストやデプロイがされる前に、変更がうまく統合されなければなりません。)
解決すべき問題は何ですか 大規模な環境では、信頼性の高いアップデートのデプロイが問題となります。 理想的には、エンドユーザーにより良い価値を提供するために、頻繁にデプロイを行いたいところです。 しかし、それを手動で行うと変更ごとに高いトランザクションコストが発生します。 歴史的に、これらのコストを避けるために、組織は頻繁にリリースを行わず、一度に多くの変更をデプロイしてきましたが、これにより何かが間違ってしまうリスクが高まります。
どのように役に立つのでしょうか CD戦略は、完全に自動化された本番環境へのパスを作成し、カナリアやブルーグリーンリリースなどの様々なデプロイメント戦略を使用してソフトウェアをテストしデプロイします。 これにより、開発者は頻繁にコードをデプロイすることができ、新しいリビジョンがテストされていることを安心して受け入れることができます。
関連する用語はありますか 継続的インテグレーション 継続的デプロイメント..
ようこそ クラウドネイティブ用語集の貢献ガイドへようこそ。 このプロジェクトに貢献できる方法はいくつかありますが、ここではその詳細を説明します:
既存の課題に取り組む 新しい用語の提案 既存の用語を更新する 用語集を翻訳する CNCF用語集レビュー この用語集のゴールは、複雑なことで有名なクラウドネイティブの空間をシンプルにすることで、より多くの人に親しんでもらうことです。
クラウドネイティブ用語集のコンテンツはGitHub repo に保存されています。 ここには、用語集に関するissues, pull request (PRs), そしてdiscussions のリストがあります。
誰が貢献できるのか? このプロジェクトにどのように参加できるかは、クラウドネイティブの専門知識のレベルによって異なります。 複雑な概念を簡略化するには、そのトピックに関する深い知識が必要です。 したがって、新しい用語を寄稿するには、その用語に精通している必要があります。 貢献者は通常、これらの技術にしばらく携わってきたエンジニアや、クラウドネイティブに焦点を当てたアカデミックの経験者です。
複雑な概念を簡単な言葉で説明するのは 本当 に難しいので、そのノウハウが必要です。そして、消化しやすく、ユーザーフレンドリーな結果は簡単に見えるかもしれませんが、望ましいシンプルさを実現するためには、クラウドネイティブの専門家たちの努力と協力が必要です。
もしあなたがまだクラウドネイティブの専門家ではないが、それでも貢献したいのであれば、専門家とチームを組むことをお勧めします。 その専門家が、その用語がコンセプトを正確に表現していると確信したら、最初の用語集への投稿の準備ができました。
翻訳は、他言語に精通した初心者が用語集に貢献できる貴重な場です。 英語での定義がしっかりしていれば、経験の浅い貢献者でも、用語を目標の言語に翻訳することができます。既存の翻訳チームに参加することも、新しいチームを作ることもできます。このガイドの用語集の翻訳を支援するのセクションを読んで、開始方法を学んでください。
始める前に 用語集へ貢献する旅を始める前に、必ず以下のステップを完了してください:
GitHub アカウントを持っていなければ作成する。 貢献者ライセンス契約書 (CLA)にサインする。 コミット署名を確認する GitHubアカウントで警戒モードを有効にすると、コミット時に検証ステータスが表示されます。 ベストプラクティス レビューを容易にするため、セマンティック改行を使用してください(例:1文につき1行など)。 私たちは、GitHubでマークダウンテキストを正しくフォーマットするために、このマークダウンのチートシートを確認することをお勧めします(例:ハイパーリンク、ボールド、イタリック)。 また、.md ファイルに名前をつけるときは、単語を区切るために小文字とスペースではなくハイフンを使い括弧は避けてください。
スタイルガイド スタイルガイドを読んで、文書のフォーマットや書き方に関するガイドラインを理解し、投稿プロセスをより効率的にしてください。
用語集コミュニティに参加する! 定期的に貢献したい場合は、毎月開催されるGlossary Working Groupのミーティングに参加することを検討してください。 ミーティングの詳細は、CNCFカレンダーで確認できます。 また、CNCF Slackの#glossaryチャンネルで、メンテナや他の貢献者とつながることもできます。あなたにお会いできるのを楽しみにしています!
既存の課題に取り組む 用語集のGitHub issuesに行くと、利用可能なissueのリストが見つかります。 ラベル(例:English language、help needed、good first issue)を使って、課題をフィルタリングすることができます。
選択した用語がすでに誰かに割り当てられていないことを確認してください。 例えば、ここでは、最初の3つの用語は利用可能ですが、4番目の用語はすでに割り当てられていることがわかります。
取り組むべき用語を選択したら、そのissueに対してコメントする。
さらに、CNCF Slackの#glossaryチャンネルでメンテナに通知してください、そして @Catherine Paganini, @Seokho Son, @Jihoon Seo, および/または @iamnoah をタグ付けして、メンテナが見逃さないようにします。..
<p>こんにちは!👋 CNCFクラウドネイティブ用語集プロジェクトへの貢献に関心をお寄せいただきありがとうございます。新しい用語を投稿する、用語集を母国語にローカライズするのを手伝う、または他の人が用語集を始めるのを手助けするなど、このコミュニティのアクティブメンバーになる方法はたくさんあります。このドキュメントでは、プロジェクト内におけるそれぞれの貢献者の役割と、それに伴う責任と権限の概要を説明します。</p>
<ol>
<li>貢献者 用語集はすべての人のためのものです。このプロジェクトに貢献するだけで、誰でも用語集の貢献者になることができます。すべての貢献者は、CNCF行動規範に従うことが期待されています。
プロジェクトに貢献するには、以下のようなさまざまな方法があります:
コンテンツの貢献者: 既存の用語を改良したり、新しい用語を投稿する方々 ローカライゼーションの貢献者: 用語集を他の言語に翻訳するのを手伝ってくれる方 ヘルパー:GitHubやSlackなど、コミュニティメンバーがサポートを必要としている場所で助ける方 アンバサダー:多くの人にメッセージを伝え、コミュニティに貢献の仕方やその理由について教えてくれる方 貢献者は、複数の役割を持つことも、1つの分野のみに集中することもできます。これらの貢献はすべて等しく重要であり、活気あるコミュニティの育成に貢献します。コンテンツとローカライゼーションへの貢献については、貢献方法とスタイルガイドを参照してください。</li>
<li>承認者 承認者は、PRに対するフィードバックを提供しPRを承認します。アクティブな投稿者なら誰でも承認者になれます(承認者になるを参照)。用語集では、(1)英語用語集の承認者と(2)ローカライズチームの承認者の2つの承認者を区別しています。
用語集の承認者には次のことが期待されます:
PRが技術的に正確かどうかを確認します 貢献者に課題を割り当て、適切なラベルを付けます 貢献者にフィードバックを提供し、必要に応じて指導します 提出物の校正と編集します 承認者が上記の職務に興味がなくなったり、遂行できなくなった場合は、メンテナにその旨を伝え辞任すべきです。
英語用語集の承認者 承認者には3つのタイプがあります:
強力な技術的背景を持つ承認者 確かな文章力を持つ承認者 両方に精通した承認者 技術承認者:しっかりとした英文のライティングスキルがなくても、技術的なバックグラウンドが強力な人なら承認者になれます。ただし、技術的な利点に基づいてPRを承認する場合は、必ず(編集)承認者によるレビューをしなければなりません。
編集者:編集者は用語を校正し、スタイルガイドに従って簡単な言葉で説明されていることを確認します。用語が大幅に編集されている場合、編集者は意味が変更されていないことを確認するため、技術承認者に再度校閲を依頼しなければなりません。
ローカライゼーションの承認者 用語集にはローカライゼーション承認者もいます。この承認者は、ローカライゼーションチーム (用語集を翻訳するチーム) の承認者です。ローカライゼーションの承認者は、自分のチームの承認者の職務のみを行うことができ、PRを専用の開発ブランチにマージすることができます。ローカライゼーションの承認者は、要件を満たせば英語用語集の承認者になることもできます。
承認者になる 承認者候補は、高品質のPRを提出し、他の人がPRをマージ可能な状態にするのを支援してきた実績があるべきです。また、タイムゾーンが許せば用語集ワーキンググループのミーティングに定期的に出席してください。
承認者になるには、興味があることを既存のメンテナーに伝えることから始めましょう。既存のメンテナーはあなたに、彼らの指導のもとでPRを投稿したり、レビューをしたり、その他の仕事をしたり上記の資格を証明するよう求めます。しばらく一緒に仕事をした後、メンテナーはあなたに承認者の資格を与えるかどうかを決定します。この決定は、あなたが示した熟練度と対応能力に基づいて行われます。</li>
<li>メンテナー メンテナーもPRをマージすることができます。誰でも用語集のメンテナーになることができます(メンテナーになるを参照)。メンテナーには、以下のような期待があります:
積極的かつ迅速な承認者であること(上記参照) サイトの設定、パーミッション、Issueテンプレート、GitHubワークフローなど、リポジトリのメンテナンスをサポートします 用語集のSlackチャンネルを監視し可能な限り協力します 用語集ワーキンググループミーティングに定期的に出席します(タイムゾーンが許せば) もしメンテナーが上記の職務に興味がなくなったり、遂行できなくなったりした場合は、名誉メンテナーに移行する必要があります。
メンテナーになる メンテナーは、承認者として成功し、質の高いPRを提出してきた実績があるべきです。また、タイムゾーンが許せば用語集ワーキンググループのミーティングに定期的に出席する必要があります。
メンテナーになるには、興味があることを既存のメンテナーに伝えることから始めましょう。既存のメンテナーはあなたに、彼らの指導のもとでPRを投稿したり、レビューをしたり、その他の仕事をしたり上記の資格を証明するよう求めます。しばらく一緒に仕事をした後、メンテナーはあなたにメンテナーの地位を与えるかどうかを決定します。この決定は、あなたが示した熟練度と対応能力に基づいて行われます。</li>
<li>コミュニティマネージャー コミュニティマネージャーは、有効的で魅力的なコミュニティの育成を支援します。コミュニティメンバーは誰でもコミュニティマネージャーになることができます。コミュニティマネージャーには次のことが求められます:
新しいメンバーを歓迎し、必要な情報が得られるようにします コミュニティからの質問に答えたり、手助けできる人を探すのを手伝います Slackでの会話をモデレートします コミュニティマネージャーになる 用語集のコミュニティマネージャーは誰でもなることができます。コミュニティマネージャーは、貢献とローカライゼーションのプロセスをしっかりと理解し、他者との交流や手助けを楽しむことが求められます。コミュニティマネージャーになるには、興味があることを既存のメンテナーに伝えることから始めましょう。オンボード/トライアル期間を経て、メンテナーは実績に基づいてコミュニティマネージャーのステータスを付与するかどうかを決定します。
非自主的な解任 貢献者の非自主的な解任は、責任と要求が満たされない場合に行われます。これには、度重なる活動停止、長期の活動停止、および/または行動規範違反などが含まれます。このプロセスは、コミュニティとその成果物を保護すると同時に、新しい貢献者が参入する機会を開くという意味で重要です。
退任/名誉職のプロセス 貢献者のコミットメントレベルが変化した場合、貢献者は退任(貢献者のラダーを下げること1)か名誉職(プロジェクトから完全に離れる)かを検討することができます。
役職への復帰 以前の貢献者の役割に戻ることができる人材がいれば、プロジェクトリーダーはそれを手配し、検討することができます。
訳注:例えば、メンテナ―から承認者に貢献レベルを落とす ↩︎</li>
</ol>..
自己修復システムは、人の手の介入なしに特定のタイプの障害から回復することができます。 このシステムには「収束」あるいは「制御」するループがあり、システムの実際の状態を積極的に確認して、運用者が初めに望んだ状態と比較します。 もし違いがある(例えば、望まれているよりも実行中のアプリケーションのインスタンスが少ない)場合、修正するための行動を行います(例えば、新しいインスタンスを起動します)。..
クラウドネイティブの観点から見ると、信頼性とはシステムが障害にどれだけうまく対応するかを指します。 インフラストラクチャが変化し、個々のコンポーネントが故障しても動作し続ける分散システムがあれば、それは信頼性があります。 一方で、容易に故障し、運用者が手動で介入して動作を維持する必要がある場合、それは信頼性がないです。 クラウドネイティブアプリケーションの目標は、本質的に信頼性の高いシステムを構築することです。..
垂直スケーリング(「スケールアップおよびスケールダウン」とも呼ばれる)は、個別のノードにCPUとメモリを追加することでシステムの処理能力を強化する方法です。 例えば、4GB RAMのコンピューターを持っていて、その容量を16GB RAMに増やしたい場合、垂直スケーリングすることは、16GB RAMシステムに切り替えることを意味します。 (別のスケーリングアプローチについては、水平スケーリングを参照してください。)
解決すべき問題はなんですか アプリケーションへの需要が現在のアプリケーションインスタンスの処理能力を超えると、システムに処理能力を強化する方法が必要です。 既存のノードにさらなる計算リソースを追加する(垂直スケーリング)か、システムにより多くのノードを追加する(水平スケーリング)ことができます。 スケーラビリティは、競争力、効率、評判、品質に貢献します。
どのように役に立つのでしょうか 垂直スケーリングは、アプリケーションのコードを変更せずにサーバーの処理能力を変更することができます。 一方で、水平スケーリングの場合、アプリケーションがスケールするために複製可能でなければなりません。 コードの変更が必要になる可能性もあります。 垂直スケーリングは、計算リソースを追加することで既存のアプリケーションの処理能力を強化し、アプリケーションがより多くのリクエストを処理し、より多くの作業を同時に行うことを可能にします。
関連する用語はありますか 水平スケーリング オートスケーリング..
水平スケーリングは、より多くのノードを追加することでシステムの処理能力を向上させる手法です。 個別のノードにより多くの計算リソースを追加する手法とは異なります(後者は垂直スケーリングとして知られています)。 たとえば、RAM容量4GBのシステムを持っていて、そのRAMを16GBに増やしたい場合、水平スケーリングはRAM 16GBのシステムに切り替えるのではなく、RAM 4GBのマシン4台で対応します。
このアプローチは、新しいインスタンスまたはノードを追加することで、負荷をより効果的に分散し、アプリケーションのパフォーマンスを向上させます。 簡単に言えば、個別のサーバーの処理能力を強化することではなく、個別のサーバーの負荷を減らすことを目指しています。
解決すべき問題はなんですか アプリケーションに対する需要がそのアプリケーションインスタンスの現在の処理能力を超えた場合、システムに処理能力をスケールする(処理能力を向上させる)方法が必要になります。
システムにノードを追加する(水平スケーリング)か、既存のノードにより多くの計算リソースを追加する(垂直スケーリング)かのいずれかが可能です。
どのように役に立つのでしょうか 水平スケーリングにより、アプリケーションは基礎となるクラスターが提供する限界までスケールすることができます。
システムにより多くのインスタンスを追加することで、アプリケーションはより多くのリクエストを処理することができます。
例えば、1つのノードが1秒あたり1,000リクエストを処理できるとすると、ノードを1つ追加するごとに、システム全体で1秒あたり処理できる総リクエストが約1,000リクエスト増えることになります。 これにより、アプリケーションは特定のノードの処理能力を強化することなく、より多くの処理を同時に行うことができます。
関連する用語はありますか 垂直スケーリング オートスケーリング..
疎結合アーキテクチャは、アプリケーションの構成要素それぞれが互いに独立して構築されるようなアーキテクチャです(その逆は密結合アーキテクチャと呼ばれます)。 マイクロサービスとよく呼ばれる個々の構成要素は、その他多くのサービスから利用できるような方法で、特定の機能を果たすよう構築されます。 疎結合アーキテクチャは密結合アーキテクチャより一般的に実装が遅くなりますが、特にアプリケーションがスケールする際に多くの利点があります。
アプリケーションが疎結合だと、チームは独立して機能開発、デプロイ、スケールすることが可能です。 よって組織は個々の構成要素における開発サイクルを素早く反復することができます。 アプリケーション開発はより速くなり、チームは能力に基づいて構成され、特定のアプリケーションに注力することができます。..
相互TLS認証(mTLS)は、2つのサービス間で送信されるメッセージを認証し、暗号化するために使用される技術です。 相互TLS認証は、標準のTransport Layer Security (TLS)プロトコルですが、一方の接続元だけを検証するのではなく、その両方が検証されます。
解決すべき問題はなんですか マイクロサービスはネットワーク上で通信します。 そして、あなたのWi-Fiネットワークのように、そのネットワーク上での通信はハッキングされる可能性があります。 mTLSは、関係者以外が盗聴したり、正当なリクエストになりすましたりすることを防ぎます。
どのように役に立つのでしょうか mTLSは、クライアントとサーバー間の双方向のトラフィックが安全で信頼できることを保証します。 また、ネットワークやアプリケーションにログインするユーザーのための追加のセキュリティ層を提供します。 これは例えばIoTデバイスのように、ログインプロセスを行わずに接続するクライアントデバイスからの接続も検証します。 オンパス攻撃、スプーフィング攻撃、クレデンシャルスタッフィング、ブルートフォース攻撃などの攻撃は、mTLSによって防ぐことができます。..
コンピューティングのコンテキストでは、抽象化とはサービスの消費者(消費者はコンピュータープログラムまたは人間)から詳細を隠す表現であり、システムをより一般的にして理解しやすくします。 良い例は、ラップトップのオペレーティングシステム(OS)です。 コンピューターがどのように動作するかの詳細を、すべて抽象化します。 CPUやメモリ、プログラムの扱い方について何も知る必要はなく、OSを操作するだけで細かい部分はOSが処理してくれます。 これらすべての詳細は、OSの「カーテン」または抽象化の背後に隠されています。
通常、システムには複数の抽象化レイヤーがあります。 これにより、開発が大幅に簡素化されます。 プログラミングの際、開発者は特定の抽象化レイヤーと互換性のあるコンポーネントを構築するため、非常に異質な可能性があるすべての下層レイヤーの詳細について心配する必要はありません。 抽象化レイヤーで動作する場合は、内部に何があるかに関係なく、システムでも動作します。..
分散アプリケーションは、機能が複数の独立したより小さな要素に分割されたアプリケーションです。 分散アプリケーションは通常、広範なアプリケーション内で異なる機能を担う個々のマイクロサービスから構成されます。 クラウドネイティブ環境において、個々のコンポーネントはクラスター内のコンテナとして実行されます。
解決すべき問題はなんですか 単一のコンピューター上で動作している単一のアプリケーションは単一障害点となります。 もしそのコンピューターが故障した場合、そのアプリケーションは利用できなくなります。 分散アプリケーションは、しばしばモノリシックアプリケーションと比較されます。 モノリシックアプリケーションは、様々なコンポーネントが独立してスケールできないために、スケールが難しい場合があります。 さらに、それらは成長するにつれて開発者の速度の妨げになることもあります。 なぜなら、より多くの開発者が明確に定義された境界を持つとはかぎらない共有のコードベースで作業する必要があるからです。
どのように役に立つのでしょうか 単一のアプリケーションを異なる部分に分割し、それらを多くの場所で実行すると、システム全体としてはより障害を許容できるようになります。 また、単一のアプリケーションでは利用できなかったスケーリング機能を活用できるようになります。 つまり、水平スケーリングができるようになります。 しかしながら、これには複雑さの増加と運用のオーバーヘッドによるコストがかかります。 こうして、単一のアプリケーションではなく多くのアプリケーションのコンポーネントを実行することになります。..
分散システムは、ネットワーク上で接続された自立型のコンピューティング要素の集合であり、ユーザーから見ると1つの統一されたシステムとして見えます。 一般的にはノードと言われるこれらの要素は、ハードウェアデバイス(例: コンピューターや携帯電話)やソフトウェアのプロセスです。 ノードは共通の目標を達成するためにプログラムされており、連携するためにネットワーク上でメッセージを交換します。
解決すべき問題はなんですか 現代の多くのアプリケーションは、運用するのにスーパーコンピューターが必要になるほど大規模です。 GmailやNetflixを考えてみて下さい。 単一のコンピューターでは、アプリケーション全体を提供するのに十分な性能がありません。 複数のコンピューターを接続することで、計算能力はほとんど無制限になります。 分散コンピューティングなしでは、今日、我々が頼りにしている多くのアプリケーションは実現できないでしょう。
従来、システムは垂直にスケールするものでした。 これは、個々のマシンにCPUやメモリを追加するときのことを指します。 垂直スケーリングには時間がかかり、ダウンタイムを必要とし、また、すぐに限界に達します。
どのように役に立つのでしょうか 分散システムは水平スケーリング(例えば、必要に応じてシステムにノードを追加すること)を可能にします。 これは自動化できるため、システムは急激なワークロードやリソース消費の増加に対応できるようになります。
分散システムでないシステムは、1台のマシンが故障するとシステム全体が故障するというリスクにさらされます。 分散システムは、いくつかのマシンがダウンしたとしても、システム全体としては同じ結果を返し続けるように設計することができます。..
密結合アーキテクチャは、アプリケーション構成要素の多くが互いに依存しているようなアーキテクチャを指します (その逆は疎結合アーキテクチャと呼ばれます)。 密結合であることは、ある構成要素に対する変更がその他の構成要素に影響を与えうることを意味します。 一般的に、密結合アーキテクチャはより疎結合なアーキテクチャと比較して簡単に実装できますが、カスケード障害と呼ばれる連鎖的な障害に対してシステムがより弱くなる可能性があります。 また、しばしば構成要素を協調してロールアウトする必要が生じるため、開発者の生産性に対する足かせとなる可能性があります。
密結合なアプリケーションアーキテクチャはかなり古典的なアプリケーション構築方法です。 マイクロサービス開発のベストプラクティス全てには必ずしも整合しませんが、密結合アーキテクチャは特定の場合に有用です。 密結合アーキテクチャでの開発は、実装がより簡潔で早くなる傾向があり、モノリシックアプリケーションとよく似て初期開発サイクルを加速させる可能性があります。..
数学やコンピューターサイエンスにおいて、冪等性とは、何度実行しても常に同じ結果になる操作を指します。 パラメーターが同じであれば、冪等な操作を複数回実行しても、追加の効果はありません。..