タグで閲覧します

用語集の用語を分類しています。フィルターを使って、タグごとに用語を閲覧することができます。

APIゲートウェイ

APIゲートウェイは、いくつかのアプリケーションAPIを集約し、それらを一か所で利用可能にするツールです。これにより認証や認可、またはアプリケーション間のリクエスト数を制限するなどの重要な機能を中央管理された場所に集約することができます。 APIゲートウェイは、(しばしば外部の)APIの利用者に対する共通のインターフェースとして機能します。解決すべき問題はなんですか外部の利用者にAPIを提供する場合、すべてのアクセスを管理・制御するための一つのエントリーポイントが必要になります。さらに、それらのやり取りに機能を適用する必要がある場合、APIゲートウェイを使用するとアプリのコードを変更することなく、すべてのトラフィックに対して一様にそれを適用することができます。どのように役に立つのでしょうかアプリケーション内のさまざまなAPIに対して単一のアクセスポイントを提供するAPIゲートウェイは、組織の横断的なビジネスロジックやセキュリティロジックを一箇所に集中して適用するのを容易にします。また、アプリケーションの利用者がすべてのニーズに対して単一のアドレスを通じてアクセスできるよう...

DevOps

DevOpsは、アプリケーション開発から本番運用までの全過程をチームが所有する方法論で、それゆえDevOpsと呼ばれます。これは一連の技術を実装することを超えて、文化やプロセスの完全な変革を必要とします。 DevOpsは、(全体の機能ではなく)小さなコンポーネントに取り組むエンジニアのグループを求め、エラーの一般的な原因である引き渡しの回数を減らします。解決すべき問題はなんですか従来、密結合なモノリシックアプリを持つ複雑な組織では、通常、作業は複数のグループ間で断片化されていました。これにより多くの引き渡しと長いリードタイムが発生しました。コンポーネントやアップデートが準備できるたびに、それは次のチームのキューに置かれました。個々の担当者はプロジェクトの一部分のみを扱うため、このアプローチは所有権の欠如につながりました。彼らの目標は、作業を次のグループに渡すことであり、顧客に適切な機能を提供することではありませんでした。これは明らかな優先順位のずれです。コードが最終的に本番環境に入る頃には、多くの開発者を経由し、多くのキューで待機していたため、コードが動作しない場合の...

DevSecOps

DevSecOpsという用語は、開発、運用、およびセキュリティの責任の文化的統合を指します。これは、開発と運用のワークフローを最小限に乱すことなく、セキュリティの優先順位を含むようにDevOpsアプローチを拡張します。 DevOpsと同様に、DevSecOpsは採用された技術によって推進される文化的変革であり、独自の適用方法があります。解決すべき問題はなんですか DevOpsの実践には、継続的インテグレーション、継続的デリバリー、および継続的デプロイメントが含まれ、アプリケーションの開発とリリースサイクルを加速します。残念ながら、自動化されたリリースプロセスが組織のすべてのステークホルダーを適切に表現できない場合には、既存の問題を悪化させる可能性があります。セキュリティのニーズを考慮せずに構築された新しいソフトウェアを迅速にリリースするプロセスは、組織のセキュリティ態勢を低下させる可能性があります。どのように役に立つのでしょうか DevSecOpsは、チームのサイロを壊し、安全な自動化されたワークフローの作成を促進することに焦点を当てています。セキュリティアプリケーションを...

eBPF

eBPF (extended Berkeley Packet Filter)は、Linuxカーネルのソースコードを修正したりカーネルモジュールを導入したりすることなく、サンドボックス化された小さなプログラムやスクリプトをLinuxシステムのカーネル空間で実行できる技術です。 Linuxシステムには2種類の空間があります。カーネル空間とユーザー空間です。カーネルはOSのコアにあたり、ハードウェアに無制限でアクセスできる唯一の部分です。アプリケーションはユーザー空間で動作し、高位の権限が必要な場合にカーネルへ要求を送ります。ハードウェアへの直接アクセスなど、より柔軟性を必要とするアプリケーションについては、「Linuxカーネルモジュール」として知られるアプローチでカーネルを拡張することができます。このアプローチによりカーネルの標準機能は拡張され、アプリケーションは基礎となる要素へより深くアクセスできるようになります。しかしこのアプローチはセキュリティリスクももたらすため、eBPFが魅力的な代替となります。解決すべき問題はなんですか一般的に、アプリケーションはユーザー空間で動作...

Function as a Service (FaaS)

Function as a Service (FaaS)は、サーバーレス、クラウドコンピューティング、サービスの一種であり、イベントによってコードを実行することを可能にします。これは通常、マイクロサービスアプリケーションの構築や立ち上げに関連する、複雑なインフラストラクチャのメンテナンスを必要としません。 FaaSを使用すると、ユーザーは関数とデータのみを管理し、クラウドプロバイダーがアプリケーションを管理します。これにより、開発者はコードが実行されていないときにサービスの費用を支払うことなく、必要な機能を得ることができます。解決すべき問題はなんですか従来のオンプレミスシナリオでは、企業は自社のデータセンターの管理や維持をします。企業はサーバー、ストレージ、ソフトウェア、その他の技術に投資し、ITスタッフや請負業者を雇ってすべての機器やライセンスの購入、管理、更新を行う必要があります。データセンターは、作業負荷が減少しリソースがアイドリング状態の時期があるにも関わらず、ピーク需要に対応できるように建設されなければなりません。逆にビジネスが急速に成長する場合、IT部門は追い...

Infrastructure as a Service (IaaS)

Infrastructure as a service (IaaS)は、クラウドコンピューティングのサービスモデルの一つであり、物理的または仮想化されたコンピューティングリソース、ストレージ、ネットワークリソースをオンデマンドで提供し、従量課金モデルに基づいて利用できます。クラウドプロバイダーはハードウェアとソフトウェアを所有、運用し、これらをパブリック、プライベート、またはハイブリッドクラウドの形態で消費者に提供します。解決すべき問題はなんですか従来のオンプレミス環境では、組織はコンピューティングリソースの有効活用にしばしば苦労していました。データセンターは、1%の時間しか必要とされない、潜在的なピーク需要に対応するために構築されなければなりません。需要が低い時期には、これらのコンピューティングリソースはアイドル状態になります。また、予想を超えるワークロードが発生した場合、処理するためのコンピューティングリソースが不足します。このようなスケーラビリティの欠如は、コストの増加とリソースの非効率的な使用につながります。どのように役に立つのでしょうか IaaSを利用すること...

Infrastructure as Code (IaC)

Infrastructure as Codeは、インフラストラクチャの定義を一つあるいは複数のファイルで保存する実践を指します。これは、通常はシェルスクリプトや他の設定ツールを用いたInfrastructure as a Serviceを手動でプロビジョニングする従来のモデルに代わるものです。解決すべき問題はなんですかクラウドネイティブな方法でアプリケーションを構築するには、インフラストラクチャを使い捨てできるようにし、かつ再現可能にする必要があります。また自動化された繰り返し可能な方法で、人の手が介入することなくオンデマンドにスケールする必要があります。手動でのプロビジョニングは、クラウドネイティブアプリケーションの応答性とスケーラビリティを満たすことができません。手動でのインフラストラクチャの変更は再現不可能で、すぐにスケールの限界に達し、設定ミスのエラーを引き起こします。どのように役に立つのでしょうかサーバー、ロードバランサー、サブネットのようなデータセンターのリソースをコードとして表現することで、インフラチームはすべての設定について単一の正しい情報源を持つことが...

Ingress

Ingressは、クラスター内で動作するコンテナあるいはコンテナ群への外部からのインターネットトラフィックを管理するためのルールセットです。これにはIngressリソースとIngressコントローラーという二つの要素があります。 Ingressリソースは、他のマニフェストファイルと共に存在する設定ファイルで、管理者が外部からのトラフィックのルーティングを設定することを可能にします。 Ingressコントローラーは、実際にIngressリソースの設定に従ってトラフィックをルーティングするウェブサーバー技術です。解決すべき問題は何ですかクラウドネイティブのウェブアプリケーションは複数のサービスで構成されており、しばしば、それらのサービスは、ブラウザを使用してユーザーがインターネット経由でアクセスする必要があります。これらのサービスをユーザーがアクセスできるようにしながら、このアプリケーションを実行するためにKubernetesを使用する場合、各アプリケーションサービスを全世界に向けて公開する必要があります。最も簡単な方法は、KubernetesのLoad Balancer...

Kubernetes

Kubernetesは、しばしばK8sと略される、オープンソースのコンテナオーケストレーターです。 Kubernetesは、モダンなインフラストラクチャ上でコンテナ化されたアプリケーションのライフサイクルを自動化し、分散システム全体でアプリケーションを管理するデータセンターのオペレーティングシステムとして機能します。 Kubernetesは、クラスター内のノードにまたがってコンテナをスケジュールし、ロードバランサーや永続ストレージなど、いくつかのインフラストラクチャリソースを束ねてコンテナ化されたアプリケーションを実行します。 Kubernetesは自動化と拡張性を実現し、ユーザーが宣言的に（以下参照）かつ再現可能な方法でアプリケーションをデプロイできるようにします。 KubernetesはAPIを介して拡張可能であり、経験豊富なKubernetesの専門家が自分たちのニーズに応じて拡張することができます。解決すべき問題はなんですかインフラストラクチャの自動化と宣言的な設定の管理は長い間重要な概念でしたが、クラウドコンピューティングが人気になるにつれて、その重要性がさらに増していき...

Pod

Kubernetes環境の中では、Podは最も基本的なデプロイ可能ユニットとして機能します。これはコンテナ化されたアプリケーションをデプロイし、管理するための基本的な構成要素を表しています。各Podには単一のアプリケーションインスタンスが含まれ、一つ以上のコンテナを保持することができます。 Kubernetesは、より大規模なDeploymentの一部としてPodを管理し、必要に応じてPodを垂直スケーリングまたは水平スケーリングすることができます。解決すべき問題はなんですかコンテナは一般的に、特定のワークロードを実行し制御する独立した単位として機能しますが、コンテナが密接に相互作用し、適切に連携して制御される必要がある場合もあります。これらの密接に関連するコンテナがそれぞれ個別に管理される場合、冗長な管理作業が発生します。たとえば、オペレーターは関連するコンテナの配置を繰り返し判断し、それらが一緒に保たれるようにしなければなりません。また、これらの関連するコンテナのライフサイクルは同期される必要がありますが、個別にしか管理できません。...

Policy as Code (PaC)

Policy as Codeは、ポリシー定義を機械的に読み取り可能かつ処理可能な形式で、１つ以上のファイルに保存する方法です。これは、別々の文書に人間が読める形式でポリシーが文書化されていた従来の方式を置き換えます。解決すべき問題はなんですかアプリケーションやインフラストラクチャの構築には、しばしば組織が定義した多数のポリシーにより制約が課されます。たとえば、シークレット情報をソースコードへの埋め込むことを禁止するセキュリティポリシーや、スーパーユーザー権限でコンテナの実行を禁止するポリシー、あるいは特定の地理的位置以外にデータを保存することを禁止するポリシーなどがあります。開発者やレビュアーにとって、アプリケーションやインフラストラクチャが文書化されたポリシーに従っているかを手動で確認することは非常に労力がかかり、エラーも発生しやすいです。手動のプロセスでは、クラウドネイティブアプリケーションの応答性やスケールの要件を満たせません。どのように役に立つのでしょうかコードを通じてポリシーを記述することは、再現性を持たせることができ、手動で行う場合と比べてエラーが減少しま...

Transport Layer Security (TLS)

Transport Layer Security (TLS)は、ネットワーク上での通信のセキュリティを高めるために設計されたプロトコルです。インターネット上で送信されるデータの安全な配信を保証し、データの監視や改ざんを避けることができます。このプロトコルは、メッセージングや電子メールなどのアプリケーションで幅広く使用されています。解決すべき問題はなんですか TLSがないと、日常的なブラウジング、電子メールでのやりとり、オンラインチャット、ビデオ会議などの機密情報が、転送中に他者によって簡単に追跡され変更される可能性があります。サーバーとクライアントアプリケーションがTLSをサポートすることで、それらの間で転送されるデータが暗号化され、第三者によって閲覧されないことが保証されます。どのように役に立つのでしょうか TLSは、ネットワーク上でデータを転送する際のセキュリティを提供するために、さまざまな符号化技術を組み合わせて使用します。 TLSにより、例えばウェブブラウザと銀行サイトのように、クライアントアプリケーションとサーバーとの間の暗号化された接続が可能になります。また、ク...

WebAssembly

WebAssembly(しばしばWasmと略される)は、C、C++、Rustなどの高級言語をコンパイルするための可搬性のあるターゲットとして設計されたバイナリ命令形式です。これは、クライアントサイドおよびサーバーサイドのアプリケーションのためにウェブ上でのデプロイを可能にします。 WebAssemblyは、通常ウェブブラウザに統合されている仮想マシンで実行される低レベルのバイトコード形式です。当初はウェブ用に開発されましたが、WebAssemblyはユニバーサルランタイムです。 IoTやエッジデバイスなどのウェブではない環境でも利用されています。解決すべき問題はなんですか長年にわたり、LAMP(Linux、Apache、MySQL、PHP)はウェブベースのアプリケーションのテンプレートでした。その後、JavaScriptがフロントエンドアプリケーション開発の王者となり、Node.jsベースのアプリケーションが標準となりました。ウェブに関する技術が進化するにつれて、インタープリタ型の言語が大いに支持されるようになりましたが、これらは通常コンパイル型の言語よりもパフォーマンスが...

サーバーレス

サーバーレスは、開発者がサーバーの管理を気にすることなくアプリケーションの構築と実行を可能にするクラウドネイティブの開発モデルです。サーバーレスパラダイム内にサーバーは存在しますが、アプリケーション開発プロセスから抽象化されています。クラウドプロバイダーがサーバーインフラのプロビジョニング、維持、およびスケーリングの日常的な作業を処理します。開発者は、デプロイのためにコードをコンテナに便利にパッケージできます。一度デプロイされると、サーバーレスアプリは需要に応じて自動的にスケールアップおよびダウンします。パブリッククラウドプロバイダーからのサーバーレスの提供は通常、イベント駆動型の実行モデルによってオンデマンドで課金されます。その結果、サーバーレス機能がアイドル状態にあるとき、関連するコストは発生しません。解決すべき問題はなんですか標準的なInfrastructure as a Service (IaaS)のクラウドコンピューティングモデルでは、ユーザーはキャパシティの単位を事前に購入します。つまり、アプリを実行するために常時稼働するサーバーコンポーネントの料金をパ...

サービス

ITの分野において、サービスという言葉には複数の意味があります。この定義では、より伝統的な意味でのサービス、つまりマイクロサービスとしてのサービスに焦点を当てます。サービスがマイクロサービスとどのように異なるのかは微妙であり、人によって異なる意見を持つかもしれません。高レベルの定義としては、これらを同じものとして扱います。マイクロサービスの定義を参照してください。

サービスディスカバリー

サービスディスカバリーはサービスを構成する個々のインスタンスを見つけるプロセスです。サービスディスカバリーツールは、サービスを構成するさまざまなノードやエンドポイントを追跡します。解決すべき問題はなんですかクラウドネイティブアーキテクチャは、動的かつ流動的で常に変化しています。コンテナ化されたアプリケーションは、その寿命の中で複数回起動と停止をする可能性があります。起動や停止が起きるたびに新しいアドレスを持つことになり、それを見つけたい任意のアプリケーションは、新しい位置情報を提供するツールを必要とします。どのように役に立つのでしょうかサービスディスカバリーは、ネットワーク内のアプリケーションを追跡し、必要な時にお互いを見つけられるようにします。そして、個々のサービスを識別し見つけるための共通の場所を提供します。サービスディスカバリーエンジンはデータベースのようなツールで、どのようなサービスが存在し、それらをどのように配置するかについての情報を保存します。

サービスプロキシ

サービスプロキシは、特定のサービスへの、あるいはそこからのトラフィックをインターセプトします。そして、それに対して何らかのロジックを適用した後、そのトラフィックを別のサービスに転送します。これは、ネットワークトラフィックに関する情報を収集したり、ルールを適用したりする仲介者として機能します。解決すべき問題はなんですかサービス間のコミュニケーション(通称: ネットワークトラフィック)を追跡し、それを変換したりリダイレクトしたりするためには、データを収集する必要があります。従来、データ収集とネットワークトラフィック管理を行うコードは、各アプリケーション内に組み込まれていました。どのように役に立つのでしょうかサービスプロキシにより、この機能を外部化することができます。もはやアプリ内に組み込む必要はありません。代わりに、プラットフォームレイヤー(アプリが実行される場所)に組み込まれるようになりました。サービス間のゲートキーパーとして、プロキシはどのような種類のコミュニケーションが行われているかについての洞察を提供します。その洞察に基づき、特定のリクエストをどこに送るかを決...

サービスメッシュ

マイクロサービスの世界では、アプリケーションは複数の小さなサービスに分割され、それらがネットワークを介して通信します。あなたのWi-Fiネットワークのように、コンピューターネットワークは本質的には信頼性が低く、ハッキングされやすく、しばしば遅いものです。サービスメッシュは、サービス間のトラフィック(すなわち通信)を管理することによって、この新しい課題に対処します。サービスメッシュは、すべてのサービスにわたって信頼性、オブザーバビリティ、およびセキュリティ機能を均一に追加します。解決すべき問題はなんですかマイクロサービスアーキテクチャに移行したことで、エンジニアは数百、場合によっては数千ものサービスを扱うようになり、それらすべてが相互に通信を必要としています。つまり、ネットワーク上で大量のトラフィックが行き交っています。その上、個々のアプリケーションは、必須の要件をサポートするために通信を暗号化する必要があるかもしれません。あるいは運用チームに共通のメトリクスを提供する必要があるかもしれませんし、問題の診断に役立つ、トラフィックに関する詳細な洞察を提供する必要があるかもし...

アジャイルソフトウェア開発

アジャイルソフトウェア開発は、繰り返しの開発サイクルと自己組織化チームを重視する一連の実践です。プロジェクトの最後にのみ価値が生み出されるウォーターフォール型のプロジェクトとは対照的に、アジャイルソフトウェア開発は、継続的かつ段階的な価値の提供とプロセス自体の進化的な改善に焦点を当てています。解決すべき問題はなんですかソフトウェアプロジェクトにおいて、すべての関係者に対して要件を定義し、それを伝え理解させることは、不可能ではないにせよ非常に難しいです。しかし、顧客は自分たちのソフトウェアプロジェクトが時間通りに、良い品質で、予算内で、スコープ内で届けられることを望んでいます。その循環的な性質により、アジャイルソフトウェア開発は要件に継続的に適応することを可能にします。これはウォーターフォール型の戦略とは対照的で、他のすべての状況に適応することをより迅速に行うことができます。どのように役に立つのでしょうかアジャイルソフトウェア開発は、従来の(ウォーターフォール型の)戦略の全てのフェーズを含んでいます。これには要件定義、計画、実装、レビュー、テスト、納品などが含まれます。...

アプリケーションプログラミングインタフェース(API)

APIは、コンピュータープログラム同士が互いにやり取りする方法です。人間がウェブページを介してウェブサイトとやり取りするように、APIはコンピュータープログラムが相互に通信するための手段を提供します。人間のやり取りとは異なり、APIには何が要求できるか、あるいはできないかについての制限があります。この制限によって、プログラム間で安定的で機能的なコミュニケーションが実現されます。解決すべき問題はなんですかアプリケーションが複雑になるにつれて、小さなコードの変更が他の機能に大きな影響を及ぼす可能性があります。アプリケーションが成長しながらも安定性を維持するために、機能にモジュラーなアプローチを採用する必要があります。 APIがなければ、アプリケーション同士が相互に通信するための枠組みが不足します。共有された枠組みがないと、アプリケーションがスケールし、統合することが困難になります。どのように役に立つのでしょうか APIは、コンピュータープログラムやアプリケーションが定義された理解しやすい方法で相互に通信し、情報を共有することを可能にします。これは現代のアプリケーションの構...

イベントストリーミング

イベントストリーミングは、ソフトウェアが一つのアプリケーションから別のアプリケーションにイベントデータを送信し、何をしているかを継続的に通信するアプローチです。あるサービスが行うすべてのことを他のすべてのサービスにブロードキャストする様子を想像してください。サービスによって行われる各活動はイベントと呼ばれ、これがイベントストリーミングの由来です。たとえば、NASDAQは毎秒、株価と商品価格の更新を受け取ります。特定の株式セットを監視するアプリケーションを動かすとしたら、その情報をほぼリアルタイムで受け取りたいでしょう。 Yahoo! Financeは、NASDAQから引っ張ってきたデータを引用し、その情報(またはイベント)を購読するアプリケーションに送信(またはストリーム)するAPIを提供しています。送信されるデータおよびそのデータ(株価)の変化がイベントであり、それらをアプリケーションに配信するプロセスがイベントストリーミングです。解決すべき問題はなんですか従来、Yahoo! Financeは単一のTCPリクエストを使用していました。これは、イベントごとに接続を確立す...

イベント駆動アーキテクチャ

イベント駆動アーキテクチャは、イベントの作成、処理、および消費を促進するソフトウェアアーキテクチャです。イベントとは、アプリケーションの状態に対する任意の変更を指します。例えば、ライドシェアリングアプリで乗車を依頼することは、イベントを代表しています。このアーキテクチャは、イベントがそのソース(乗車を要求するアプリ)から望ましいレシーバー(近くの利用可能なドライバーのアプリ)へ適切にルーティングされる構造を作り出します。解決すべき問題はなんですかより多くのデータがリアルタイムになるにつれて、イベントがキャプチャされ、イベントリクエストを処理する必要がある適切なサービスへ正確にルーティングされる信頼性の高い方法を見つけることがますます困難になります。イベントを処理する従来の方法は、メッセージが適切にルーティングされたか、あるいは実際に送信または受信されたかを保証する方法がないことがしばしばあります。アプリケーションがスケールするにつれて、イベントをオーケストレーションすることがより困難になります。どのように役に立つのでしょうかイベント駆動アーキテクチャは、すべてのイベン...

イミュータブルインフラストラクチャ

イミュータブルインフラストラクチャとは、一度デプロイされると変更することができないコンピューターインフラストラクチャ(仮想マシンやコンテナ、ネットワーク機器)を指します。これは許可されていない変更を自動的に上書きするプロセスや、最初から変更を許可しないシステムによって強制されます。コンテナはイミュータブルインフラストラクチャの良い例です。なぜならコンテナに永続的な変更を加えるには、新しいバージョンのコンテナを作成するか、イメージから既存のコンテナを再度作成するしかないからです。許可されていない変更の防止や特定により、イミュータブルインフラストラクチャはセキュリティリスクの特定と軽減を容易にします。このようなシステムの運用ははるかに簡単になります。なぜなら、管理者がそれについての前提を立てやすくなるためです。結局のところ、誰も間違いを犯していないことや、伝え忘れた変更を行っていないことが分かっています。イミュータブルインフラストラクチャはInfrastructure as Codeと密接に関連しており、インフラストラクチャを作成するために必要なすべての自動化がバージョン管...

エッジコンピューティング

エッジコンピューティングは、ストレージと計算能力の一部を主要なデータセンターからデータソースに移行する分散システムのアプローチです。収集されたデータは、中央のデータセンターで処理や分析されるのではなく、ローカルに(例えば工場内や店内、あるいは街の全域にわたって)計算されます。これらのローカル処理ユニットやデバイスがシステムのエッジを表し、データセンターがその中心です。エッジで計算された出力は、さらなる処理のために主要なデータセンターに送信されます。エッジコンピューティングの例には、リストバンド型ガジェットや交通量を分析するためのコンピューターが含まれます。解決すべき問題はなんですかこの10年間で、私たちはエッジデバイス(例えば携帯電話、スマートウォッチ、センサー)の増加を目の当たりにしてきました。場合によっては、リアルタイムデータ処理は単なる便利な機能ではなく、非常に重要です。自動運転を行う車を考えてみてください。車のセンサーが取得したデータが、適切な反応をするために車両へ送り返される前に、データセンターで処理される必要があると考えてみてください。このネットワークの...

データセンター

データセンターはコンピューター(その多くはサーバー)を収容するために設計された特別な建物または施設です。これらのデータセンターがクラウドコンピューティングに重点を置いている場合、高速なインターネット回線に接続される傾向があります。データセンターが入っている建物には、停電時に電力を供給する発電機や、発熱するコンピューターを冷却する強力な空調機など、停電が発生した場合でもサービスを維持できる設備が備えられています。解決すべき問題は何ですか 1990年代後半にデータセンターが普及するまでは、主に特定の業務プロセスを実行するための専用のコンピューターであり、または個人が作業を行うためにコンピューターが使用されていました。ただし、コンピューターのリソース(ハードディスク、メモリ、CPU)は限られているため、その上で実行されるアプリケーションには厳しい制約があり、実行できるアプリケーションの種類が制限されます。データセンターが普及する前は、アプリケーションの規模が実行されているコンピューターの容量によって制限されていました。しかし、GmailやNetflixのような大規模なアプリケーシ...

オートスケーリング

オートスケーリングとは、システムが自動的にスケールする能力のことで、通常はコンピューティングリソースにおいて行われます。オートスケーリングシステムでは、必要に応じて自動的にリソースが追加され、変動するユーザーの需要に応じてスケールできます。オートスケーリングのプロセスは様々で、メモリーやプロセス時間などの異なるメトリクスに基づいてスケールするように設定可能です。マネージドクラウドサービスには通常、オートスケーリング機能が関連しています。これは、ほとんどのオンプレミス環境へのデプロイよりも多くのオプションと実装が利用可能であるためです。以前はインフラストラクチャとアプリケーションが、システムのピーク使用量を考慮して設計されていました。このアーキテクチャにより、多くのリソースが未使用であり、消費者需要の変化に対して非弾力的でした。非弾力性は、ビジネスへの高コストと、過剰な需要によって発生する障害の営業損失を意味します。クラウドを活用し、アプリケーションとその依存関係を仮想化およびコンテナ化することで、組織はユーザーの需要に応じてスケールするアプリケーションを構築できます。 ...

ノード

ノードとは、他のコンピューター、つまり他のノードと協力して共通のタスクを達成するコンピューターのことです。例えばあなたのラップトップ、モデム、プリンターを考えてみてください。これらはすべてあなたのWi-Fiネットワークを介して接続されており、通信し協力しており、それぞれが一つのノードを表しています。クラウドコンピューティングにおいて、ノードは物理的なコンピューターであったり、仮想コンピューター、つまりVM（バーチャルマシン）であったり、またはコンテナであることもあります。解決すべき問題はなんですかアプリケーションは1台のマシン上で動作させることができます(そして実際に多くのアプリケーションがそうしています)が、それにはいくつかのリスクが伴います。具体的には、基盤となるシステムの故障がアプリケーションの中断を引き起こすことです。これに対処するために、開発者たちは分散アプリケーションを作り始めました。これは、各プロセスがそれぞれのノード上で動作します。それゆえ、ノードはアプリやプロセスを実行し、共通の目標を達成するために協力するノードのクラスター、またはグループの一部とし...

オブザーバビリティ(可観測性)

オブザーバビリティとは、システムが実用的な洞察をどの程度出力できるかを決める性質のことを指します。オブザーバビリティにより、ユーザーはシステム外部への出力を元にそのシステムの状態を理解し、(是正)措置を取ることが可能になります。コンピューターシステムは、CPU時間・メモリ・ディスク容量といった低水準のシグナルや、APIの応答時間・エラー数・秒間トランザクション数などを含む高水準でビジネスに直結するシグナルを観測することで評価されます。可観測なシステムは、いわゆるオブザーバビリティツールと言われる専門のツールで観測(もしくは監視)されます。オブザーバビリティツールの一覧はクラウドネイティブランドスケープのオブザーバビリティセクションで見られます。可観測なシステムは、有意義かつ実用的なデータを運用者に提供し、運用者が(インシデントへのより素早い対応や開発者の生産性向上といった)好ましい結果を出すことを可能にします。システムのダウンタイムとともに、手間のかかる手作業での仕事も少なくなります。結果として、システムの運用コストと開発コストは、そのシステムがどれだけ可観測なのかに大...

ポータビリティ(可搬性)

ソフトウェアの特性であるポータビリティは、再利用性の一つの形態です。クラウドプロバイダー、オペレーティングシステムやベンダーなどの特定の運用環境へのロックインを避けるのに役立ちます。伝統的に、ソフトウェアは特定の環境(例えばAWSやLinux)向けに構築されがちです。一方、ポータブルなソフトウェアは、大規模な作業を必要とせずに、異なる運用環境で機能します。アプリケーションがポータブルであるとは、新しい環境に適応させるために要求される労力が合理的な範囲内であることを指します。「ポートする」というフレーズは、ソフトウェアを修正しそれを異なるコンピューターシステム上で動作可能にすることを意味します。

ロールベースアクセス制御(RBAC)

ロールベースアクセス制御(RBAC)は、チームあるいはより大きな組織内での個々のロールに基づいてシステムやネットワーク、リソースへのアクセスを管理するセキュリティ方法です。 RBACは、管理者に特定の職務を持つすべてのユーザーに必要なアクセスレベルを割り当て、事前に定義された一連の権限を持つ役割をそれらのユーザーに割り当てる権限を与えます。組織はRBACを利用して、従業員ごとの役割と責任に合わせた、さまざまなレベルのアクセスを提供します。解決すべき問題はなんですか RBACは、特にアプリケーションとチームメンバーの数が増えるにつれて、チームメンバーやアプリケーションがアクセスできるリソース、および彼らが実行できる操作を制御するという課題に対処します。管理者は、各ユーザーがアクセスする必要があるリソースに対して正しい権限を持っていることを確認する必要がありますが、これは構造化されたアクセス制御メカニズムがなければ煩雑で間違いが生じやすい作業になります。どのように役に立つのでしょうか RBACは、ITチームにグループ内のすべてのユーザーの権限を同時に簡単に管理したり、役割を割り当て...

カオスエンジニアリング

カオスエンジニアリング(CE)とは、本番環境の分散システムに実験する学問分野です。分散システムが乱雑で予期せぬ状況に耐えるシステムの能力に対する信頼を築くことを目指します。解決すべき問題はなんですか SREやDevOpsの実践は、プロダクトの回復力と信頼性を高める技術に焦点を当てています。システムが障害を許容しつつ適切なサービス品質を保証する能力は、通常のソフトウェア開発の要件です。インフラストラクチャ、プラットフォーム、あるいは(マイクロサービスベースの)アプリケーションの他の動作部分のように、アプリケーションの停止につながる可能性のある複数の側面が関与しています。本番環境に新機能を高頻度でデプロイすることは、高い確率でダウンタイムと重大なインシデントをもたらし、ビジネスに重大な影響を及ぼす可能性があります。どのように役に立つのでしょうかカオスエンジニアリングは、回復力の要件を満たすための技術です。インフラストラクチャ、プラットフォーム、そしてアプリケーションの障害に対する回復力を達成するために使用されます。カオスエンジニアは、アプリケーション、インフラストラクチ...

カナリアデプロイメント

カナリアデプロイメントは、2つの環境から始まるデプロイメント戦略です。一つはライブトラフィックがある環境で、もう一つは更新されたコードを含む、ライブトラフィックがない環境です。トラフィックは徐々にアプリケーションの元のバージョンから更新されたバージョンへ移行します。最初にライブトラフィックの1％を移行し、次に10％、25％と続け、すべてのトラフィックが更新されたバージョンを流れるまで続けます。組織は本番環境で新しいバージョンのソフトウェアをテストし、フィードバックを得て、エラーを診断し、必要に応じて安定したバージョンに迅速にロールバックすることができます。「カナリア」という用語は、「炭鉱のカナリア」という慣習に由来します。この慣習では、カナリア鳥を炭鉱に連れて行き、鉱夫の安全を確保していました。無臭の有害ガスが存在すると、鳥は死んでしまい鉱夫は迅速に避難する必要があることを知りました。同様に、更新されたコードに何か問題が発生した場合、ライブトラフィックは元のバージョンに「避難」されます。解決すべき問題はなんですかテスト戦略をいかに徹底していても、本番環境では常にいく...

クライアントサーバーアーキテクチャ

クライアントサーバーアーキテクチャでは、アプリケーションを構築するロジック(あるいはコード)が2つ以上のコンポーネントに分割されます。それは作業の実行を要求するクライアント(例えばウェブブラウザで実行されるGmailのウェブアプリケーション)と、その要求を満たす1つ以上のサーバー(例えばクラウド内のGoogleのコンピューターで実行されるメール送信サービス)です。この例では、あなたが書いた送信メールは、クライアント(ウェブブラウザで実行されるウェブアプリケーション)によってサーバー(あなたの送信メールを受信者に転送するGmailのコンピューター)へ送られます。これは、(例えばデスクトップアプリケーションのような)すべての作業を一つの場所で行う自己完結型のアプリケーションとは対照的です。例えば、Microsoft Wordのようなワードプロセッサープログラムは、あなたのコンピューター上にインストールされ完全にあなたのコンピューター上で実行されます。解決すべき問題はなんですかクライアントサーバーアーキテクチャは、自己完結型のアプリケーションが抱える、定期的な更新という大きな課題...

クラウドコンピューティング

クラウドコンピューティングは、CPU、ネットワーク、ディスクなどの計算資源をインターネット上でオンデマンドで提供し、ユーザーは物理的に離れた場所にある計算能力にアクセスし、使用することができるようにします。一般に、クラウド基盤が組織専用のものか、オープンな公共サービスのために共有されているかによって、プライベートクラウドとパブリッククラウドに区別されます。解決すべき問題はなんですか組織は従来、コンピューティングパワーを拡大しようとする際、主に2つの課題に直面していました。物理的なサーバーとネットワークをホストするための（新しい）設備を取得、サポート、設計するか、既存の設備を拡張、維持するかです。クラウドコンピューティングは、企業がコンピューティングニーズの一部をアウトソースできるようにすることで、この課題を解決しています。どのように役に立つのでしょうかクラウドプロバイダーは、企業がオンデマンドでコンピューティングリソースを借り、使用量に応じて料金を支払うことを可能にし、2つの重要な利点をもたらします。第一に、企業は新しい物理的なインフラストラクチャを待つことなく、計画...

クラウドネイティブアプリケーション

クラウドネイティブアプリケーションは、クラウドコンピューティングの技術革新を活用するため特別に設計されています。これらのアプリケーションは、それぞれのクラウドアーキテクチャと容易に統合でき、クラウドのリソースとスケーリング機能を活用できます。また、クラウドコンピューティングによるインフラストラクチャの技術革新を活用するアプリケーションのことも指します。今日のクラウドネイティブアプリケーションには、クラウドプロバイダーのデータセンターで実行されるアプリケーションと、オンプレミスのクラウドネイティブプラットフォームで実行されるアプリケーションがあります。解決すべき問題はなんですか従来、オンプレミス環境では、コンピューティングリソースをかなり特化した方法で提供していました。各データセンターは、アプリケーションを特定の環境に密結合するサービスを持っており、多くの場合、仮想マシンやサービスのようなインフラストラクチャの提供は手作業に大きく依存していました。その結果、開発者とそのアプリケーションは、特定のデータセンターに制約されることになりました。クラウド用に設計されていないアプリ...

クラウドネイティブセキュリティ

クラウドネイティブセキュリティは、セキュリティをクラウドネイティブアプリケーションに組み込むアプローチです。開発から本番に至るまで、アプリケーションのライフサイクル全体にセキュリティが組み込まれていることを保証します。クラウドネイティブセキュリティは、従来のセキュリティモデルと同じ基準を保証しつつ、クラウドネイティブ環境の特性、すなわち迅速なコード変更や非常に短命な1インフラストラクチャに適応することを目指します。クラウドネイティブセキュリティは、DevSecOpsと呼ばれるプラクティスと非常に関係があります。解決すべき問題はなんですか従来のセキュリティモデルは、もはや有効でない多くの前提のもとに構築されていました。クラウドネイティブアプリケーションは頻繁に変わり、多数のオープンソースツールやライブラリを使用し、多くの場合ベンダーが管理するインフラストラクチャで実行され、急速なインフラストラクチャの変更に影響を受けることがあります。コードレビューや長い品質保証サイクル、ホストベースの脆弱性スキャン、直前のセキュリティレビューは、クラウドネイティブアプリケーションに対応する...

クラウドネイティブテクノロジー

クラウドネイティブテクノロジーは、クラウドネイティブスタックとも呼ばれ、クラウドネイティブアプリケーションを構築するために使用される技術です。これらの技術により、組織がスケーラブルなアプリケーションを、パブリックやプライベート、ハイブリッドクラウドのようなモダンでダイナミックな環境で、クラウドコンピューティングの利点を最大限に活用しながら、構築や実行することができます。コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャなど、クラウドコンピューティングの機能を活用するために1から設計されたアプローチです。解決すべき問題はなんですかクラウドネイティブスタックには多くの異なる技術カテゴリーがあり、様々な課題に対応しています。 CNCFクラウドネイティブランドスケープを見ると、いかに多くの異なる領域に触れているかわかると思います。しかし高いレベルでは、主に従来のIT運用モデルのマイナス面に取り組んでいます。含まれる課題としては、拡張性がありフォールトトレラントな自己修復型アプリケーションの実現が困難であること、リソースの活用が非効率であることなどが挙げ...

クラウドネイティブ用語集

クラウドネイティブ用語集クラウドネイティブ用語集は、技術者だけでなくビジネスサイドの人々にもわかりやすく伝えることで、複雑なことで有名なクラウドネイティブの領域を、人々にとってよりシンプルにすることを目指しています。そのために、シンプルであること（例：バズワードを使わないシンプルな言葉、テクノロジーを使う人なら誰でも共感できる例、不必要な詳細は省くなど）に重点を置いています。この用語集は、CNCFビジネスバリュー分科会（BVS, Business Value Subcommittee）が主導するプロジェクトです。貢献クラウドネイティブ用語集の変更、追加、改良を提案することを歓迎します。私たちは、共有語彙目録を開発・改良するために、CNCFが管理するコミュニティ主導のプロセスを採用しています。この用語集は、クラウドネイティブテクノロジーに関する共有語彙を整理するために、ベンダーニュートラルなプラットフォームを提供します。プロジェクトの目的と憲章を遵守するすべての参加者からの投稿を歓迎します。貢献したい人は、GitHubのissueを提出するか、プルリクエストを作成することが...

クラスター

クラスターは、共通の目的に向けて連携して働くノードと呼ばれるコンピューターやアプリケーションのグループです。クラウドネイティブコンピューティングでは、この用語は通常Kubernetesに適用されます。これは、ノードがより密結合している特定の種類の分散システムとして捉えることができます。解決すべき問題はなんですか単一のコンピューター上で動作するソフトウェアには、単一障害点があります。もしそのコンピューターがクラッシュしたり、誰かが誤って電源ケーブルを抜いたりした場合、ビジネス上重要なシステムが利用できなくなる可能性があります。そのため、モダンなソフトウェアは一般的に分散アプリケーションとして構築され、クラスターとしてまとめられます。どのように役に立つのでしょうかクラスター化された分散アプリケーションは複数のマシン上で実行され、単一障害点がなくなります。しかし、分散システムを構築することは非常に難しいです。実際、分散システムはコンピューターサイエンスの中で一つの分野として扱われています。グローバルなシステムの必要性と長い年月をかけた試行錯誤が、クラウドネイティブ技術...

コンテナ

コンテナは、コンピューターのオペレーティングシステムがリソースと機能面での制限を管理する、実行中のプロセスです。コンテナプロセスで利用可能なファイルは、コンテナイメージとしてパッケージ化されています。コンテナは一つのマシン上で同時に実行されますが、通常オペレーティングシステムは別々のコンテナプロセスが互いに干渉するのを防ぎます。解決すべき問題は何ですかコンテナが利用可能になる前は、アプリケーションを実行するためには別々のマシンが必要でした。各マシンはそれぞれのオペレーティングシステムを必要とし、CPU、メモリ、ディスクスペースを消費します。これらは全て個々のアプリケーションが動作するために必要なものです。さらに、オペレーティングシステムのメンテナンス、アップグレード、起動は大きな手間のかかる作業です。どのように役に立つのでしょうかコンテナはオペレーティングシステムとそのマシンリソースを共有し、オペレーティングシステムのリソースオーバーヘッドを分散させ、物理マシンを効率的に使用します。これは通常コンテナが互いに干渉することが制限されているため、実現できます。これによ...

コンテナオーケストレーション

コンテナオーケストレーションとは、流動的な環境において、コンテナ化されたアプリケーションのライフサイクルを管理し自動化することを指します。これはコンテナオーケストレータ(ほとんどの場合はKubernetes)を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。オーケストレーションという言葉は比喩です。オーケストレーションツールは、音楽指揮者のようにコンテナを指揮し、すべてのコンテナ(または音楽家)が適切に機能するようにします。解決すべき問題は何ですかスケールに応じてマイクロサービス、セキュリティ、ネットワーク通信や一般的な分散システムを管理することは、手動で行うには難しく、場合によっては不可能です。コンテナオーケストレーションにより、これらすべての管理タスクを自動化することができます。どのように役に立つのでしょうかコンテナオーケストレーションツールは、ユーザーがシステムの状態を決定することを可能にします。まず、システムがどのようにあるべきかを宣言します(例えばx個のコンテナ、y個のPodなど)。その後、オーケストレー...

コンテナ化

コンテナ化は、アプリケーションとその依存関係をコンテナイメージにまとめるプロセスです。コンテナのビルドプロセスでは、Open Container Initiative(OCI)標準への準拠が必要です。出力がこの標準に準拠したコンテナイメージであれば、どのコンテナ化ツールを使用しても問題ありません。解決すべき問題は何ですかコンテナが普及する前は、組織は仮想マシン(VM)に依存して、単一のベアメタルマシン上で複数のアプリケーションをオーケストレーションしていました。 VMはコンテナよりも非常に大きく、実行にはハイパーバイザーが必要です。これらの大きなVMテンプレートのストレージ、バックアップ、転送により、VMテンプレートの作成もより遅くなります。さらに、VMは不変性の原則に反する構成ドリフトに悩まされることがあります。どのように役に立つのでしょうかコンテナイメージは(従来のVMとは異なり)軽量です。またコンテナ化のプロセスには依存関係のリストが記載されたファイルが必要です。このファイルはバージョン管理が可能で、ビルドプロセスを自動化できます。これにより組織は他の優先事...

サイドカーコンテナ

サイドカーコンテナはサイドカーパターンの実装です。別のコンテナ上にデプロイされたアプリケーションが並行して動作し、メインコンテナ上で動いている主要なアプリケーションとライフサイクルを共有します。解決すべき問題はなんですかログ、モニタリング、トレースだけでなくセキュリティやネットワーキングのようなシナリオに対処するために、複数のコンテナとそれらのライフサイクルをまとめて扱うのが都合の良いクロスプラットフォームの状況があります。このアプローチ以前は、ログは通常、コンテナ内のアプリケーションコードの中で実装されていました。これにより、開発者やアプリケーションによってロジックの実装方法が異なり、結果として保守や運用がより複雑なシステムになることが多かったです。たとえば、ログロジックの更新が実行時のアプリケーションに影響を与え、運用リスクが増大する可能性があります。どのように役に立つのでしょうか関心の分離の原則を強制し、主要なアプリケーションのコードを変更することなく、別のコンテナ上で動作する分離されたプロセスを使って機能を拡張できます。サイドカーコンテナはメインコンテナと同じ...

サイト信頼性エンジニアリング(SRE)

サイト信頼性エンジニアリング(SRE: Site Reliability Engineering)は、オペレーションとソフトウェアエンジニアリングを組み合わせた分野です。後者では、特にインフラストラクチャとオペレーションの問題に応用されます。つまり製品機能を構築する代わりに、サイト信頼性エンジニアは、アプリケーションを実行するためのシステムを構築します。 DevOpsとの類似点がありますが、DevOpsがコードを本番環境に導入することに焦点を当てているのに対し、SREは本番環境で実行中のコードが適切に機能することを保証します。解決すべき問題はなんですかアプリケーションを高い信頼性で実行するためには、パフォーマンスモニタリング、アラート、デバッグ、トラブルシューティングなど、複数の機能が必要です。これらがなければ、システムオペレーターは問題に対応するだけで、積極的にそれらを回避しようとすることはできません。 — ダウンタイムは時間の問題となるだけです。どのように役に立つのでしょうか SREのアプローチは、基盤となるシステムを継続的に改善することで、ソフトウェア開発プロセスのコ...

シフトレフト

シフトレフトの「レフト」はソフトウェア開発ライフサイクルのより初期のステージを指します。ライフサイクルをステージが左から右へと実行される線と考えます。シフトレフトは、テストやセキュリティなどの開発プラクティスをソフトウェア開発ライフサイクルの終盤ではなく、早い段階で実施することです。もともとはテストプロセスを早い段階で行うことを指していましたが、現在ではセキュリティやデプロイなど、ソフトウェア開発やDevOpsの他の側面にも適用されることがあります。解決すべき問題はなんですかセキュリティ問題や、バグ、ソフトウェアの欠陥は開発サイクルの後期やデプロイ後に発見された場合、とりわけソフトウェアが既に本番環境へデプロイされていた場合、修正はより難しく高コストになる可能性があります。どのように役に立つのでしょうかソフトウェア開発におけるシフトレフトの考え方を適用することで、チームは開発ライフサイクル全体を通してテストやセキュリティを実装することができます。テストとセキュリティに対する責任はソフトウェアエンジニアから品質保証、運用まで開発チーム全体にわたって共有さるものであるため、...

スケーラビリティ

スケーラビリティは、システムがどれだけ拡張できるのかを示す特性を指します。この特性により、システムが行うべき任意の処理に対して、その処理能力を増強することが可能となります。例として、Kubernetesクラスタは、コンテナ化されたアプリの数を増減することでスケールしますが、そのスケーラビリティはいくつかの要素に依存します。ノードの数、各ノードが処理できるコンテナの数、コントロールプレーンがサポート可能なレコードとオペレーションの規模と関係しています。スケーラブルなシステムは、キャパシティの追加を容易に行えます。私たちはスケーリングアプローチを2種類に分類します。水平スケーリングでは、増加した負荷を処理するためにより多くのノードを追加します。一方で、垂直スケーリングでは、個々のノードがより多くのトランザクションを実行するために性能向上します（例えば、個別のマシンにより多くのメモリやCPUを追加すること）。スケーラブルなシステムは、容易に変更することができ、ユーザーのニーズに応えることができます。

ステートフルアプリケーション

ステートフル(およびステートレス)アプリについて話すとき、ステートとは、アプリが設計通りに機能するために必要なあらゆるデータを指します。例えば、カートの情報を保存しているオンラインショップなどはステートフルアプリです。今日、私たちが使用するほとんどのアプリケーションは少なくとも部分的にステートフルです。しかし、クラウドネイティブ環境では、ステートフルアプリは難しいです。これは、クラウドネイティブアプリが非常に動的だからです。これらはスケーリング、再起動、別の場所への移動が可能ですが、それでもそのステートにアクセスできる必要があります。そのため、ステートフルアプリには、データベースのようにどこからでもアクセス可能な何らかのストレージが必要です。

ステートレスアプリケーション

ステートレスアプリケーションは、送信される各リクエストをそれが初めて送信されたかのように処理します。このアプリは以前の相互通信やユーザーセッションデータを覚えていません。以前の相互通信からのデータはステートと呼ばれ、そのデータがどこにも保存されていないため、これらのアプリはステートレスです。例を挙げると、検索エンジンを使用していて、その検索が中断された場合(例えばウィンドウを閉じた場合)その検索結果は失われます。最初からやり直す必要があります。一方、以前の相互通信を考慮しながらリクエストを処理するアプリケーションはステートフルアプリケーションと呼ばれます。

スタイルガイド

このスタイルガイドは、用語集の読者、定義の構造、必要な詳細度、一貫したスタイルを維持する方法について理解するのに役立ちます。クラウドネイティブ用語集は、CNCFリポジトリのデフォルトスタイルガイドに従っています。さらに、以下のルールにも従っています：専門用語や流行語は避け、シンプルでわかりやすい言葉を使う。口語を避ける書き言葉や具体的な言葉を使う前置詞と冠詞の縮約を含めない受動態は慎重に使う肯定形でのフレーズを目指す引用符以外の感嘆符を使用しない誇張しないこと繰り返しを避ける簡潔であること読者用語集は、技術者および技術者以外の読者を対象として書かれています。技術的な知識を前提とせず、定義が簡単な言葉で説明されていることを確認してください。詳しくは、以下の定義をご覧ください。最小限の定義私たちの目標は、クラウドネイティブの用語を誰でも本当に簡単に理解できるようにすることです。そのため、シンプルであることに重点を置いています。つまり、テクノロジーを使っている人なら誰でも共感できるような例を用いて、明確でシンプルな言葉を使うということです（詳しくは後述し...

セキュリティカオスエンジニアリング

セキュリティカオスエンジニアリング(SCE)は、カオスエンジニアリングに基づく規律です。 SCEは、分散システムに対して積極的なセキュリティ実験を行い、乱雑や悪意のある条件に耐えるシステムの能力に信頼を築くために行われます。セキュリティカオスエンジニアは、定常状態、仮説、継続的検証、学習した教訓、および緩和の実施を含む科学的方法のループを使用してこれを達成します。解決すべき問題はなんですかサイト信頼性エンジニア(SRE)とサイバーセキュリティエンジニアの主な優先事項は、できるだけ早くサービスを復旧させ、ゼロダウンタイムを目指してビジネスへの影響を最小限に抑えることです。 SREおよびサイバーセキュリティエンジニアは、障害発生前および障害発生後のインシデント状況の両方に対処します。ほとんどのセキュリティ問題は、迅速に発見および修正が難しく、アプリケーションやシステムの機能に影響を与えます。さらに、セキュリティインシデントは、開発フェーズ中に発見するのが通常難しいものです。どのように役に立つのでしょうかセキュリティカオスエンジニアリングは、オブザーバビリティとサイバーレジリエ...

ゼロトラストアーキテクチャ

ゼロトラストアーキテクチャは、ITシステムの設計と実装において信頼を完全に取り除くアプローチを推奨します。その核心の原則は「決して信頼せず、常に検証する」であり、デバイスやシステムは、システムの他のコンポーネントと通信する際に常に事前に自分自身を検証します。今日の多くのネットワークは、企業ネットワークの信頼された境界内にあるため、システムやデバイスは互いに自由に通信することができます。ゼロトラストアーキテクチャは、ネットワークの境界内にあっても、システム内のコンポーネントは通信する前に検証しなければならないという正反対のアプローチを取ります。解決すべき問題はなんですか伝統的な信頼ベースのアプローチでは、企業ネットワークの境界内に存在するシステムやデバイスに対して、信頼があるため問題がないという前提があります。しかし、ゼロトラストアーキテクチャは、その信頼が脆弱性になると認識しています。攻撃者が信頼されたデバイスへのアクセスを獲得した場合、そのデバイスに与えられている信頼のレベルとアクセスに依存してシステムは攻撃に対して脆弱になります。なぜなら、攻撃者は信頼されたネット...

デジタル証明書

(デジタル)証明書、しばしば公開鍵証明書やSSL証明書とも呼ばれるものは、ネットワーク上の通信を保護するために使われるデジタル文書です。証明書により、通信相手が本当にその主張どおりの存在であることを知ることができます。また送受信するデータを暗号化することで、通信が第三者に覗かれないようにし、プライバシーを保つことも可能にします。解決すべき問題はなんですかデバイスがネットワーク上で通信するとき、特定のデバイスがその名乗っている通りの存在であるという保証は、本質的には存在しないです。さらに、任意の2つのデバイス間のトラフィックが第三者に傍受されないという保証もないです。したがって、あらゆる通信は傍受される可能性があり、ユーザー名やパスワードのような機密情報が漏洩するリスクがあります。どのように役に立つのでしょうか証明書を利用する現代のメールクライアントは、送信者の身元が正しいかどうかを通知することができます。ウェブブラウザも同様であり(アドレスバーの前に表示される小さな鍵アイコンを見てください)、送信者の正当性を示します。一方で、証明書はインターネット上のエンティティ間...

ブルーグリーンデプロイメント

ブルーグリーンデプロイメントは、最小限のダウンタイムで稼働中のコンピューターシステムを更新する戦略です。オペレーターは、“ブルー"と"グリーン"と呼ばれる2つの環境を維持します。一方は本番トラフィックを処理し(現在すべてのユーザーが使用しているバージョン)、もう一方が更新されます。アクティブではない(グリーン)環境のテストが終了すると、本番トラフィックは(しばしばロードバランサーを使用して)切り替えられます。ブルーグリーンデプロイメントは通常、多くのサービスを含む全環境を一度に切り替えることを意味します。紛らわしいことに、時々この用語はシステム内の個々のサービスに関して使用されます。このあいまいさを避けるため、個々のコンポーネントを指す場合には"ゼロダウンタイムデプロイメント"という用語が好まれます。解決すべき問題はなんですかブルーグリーンデプロイメントは、後方互換性がないために"ロックステップ"で変更する必要があるソフトウェアを更新する際に最小限のダウンタイムを可能にします。例えば、ウ...

プラットフォームエンジニアリング

プラットフォームエンジニアリングとは、ソフトウェア開発者を支援するツールとプロセスを構築する技術です。開発者がソフトウェアを作る過程全体で必要とするものを満たすように設計されたセルフサービスステーションを作るようなものです。これらのツールとワークフローを提供することで、プラットフォームエンジニアリングは開発者がより速く、より効率的に作業できるようにします。解決すべき問題はなんですかプラットフォームエンジニアリングは、遅く非効率なソフトウェア開発という課題に取り組みます。かつて開発者は、環境構築やツール設定のような反復的な作業に多くの時間を費やしていました。プラットフォームエンジニアリングはこれらのプロセスを合理化し、開発者が革新的なコードを書くという本質的な作業に集中できるようにします。どのように役に立つのでしょうかプラットフォームエンジニアリングは、あらかじめ構築されたツールキットを開発者に提供することでソフトウェア開発の非効率性に対処します。このツールキットは、しばしばInfrastructure as a Service (IaaS)やベアメタル上に構築されてお...

ベアメタルマシン

ベアメタルとは物理コンピューターを意味し、具体的にはサーバーのことでありオペレーティングシステムが1つしかないものです。最近のコンピューティングでは、サーバーの多くが仮想マシンであるため、この区別は重要です。物理サーバーは、一般的に強力なハードウェアを内蔵したかなり大型のコンピューターです。仮想化せずに、物理ハードウェア上にオペレーティングシステムをインストールし直接アプリケーションを実行することを"ベアメタル"上で実行すると呼ばれます。解決すべき問題はなんですか 1つのオペレーティングシステムと1台の物理コンピューターの組み合わせはコンピューティングの原型です。物理コンピューターのすべてのリソースがオペレーティングシステムで直接利用可能であり、仮想化レイヤーが存在しないため、オペレーティングシステムの命令をハードウェアに変換する際に人工的な遅延が発生しません。どのように役に立つのでしょうかコンピューターのすべての計算リソースを単一のオペレーティングシステムに割り当てることで、オペレーティングシステムに最高のパフォーマンスを提供できる可能性があります。...

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャは、アプリケーションを個々の独立した（マイクロ）サービスに分割するアーキテクチャ手法で、各サービスは特定の機能に焦点を当てています。これらのサービスは密接に連携して動作し、エンドユーザーには単一のエンティティとして見えます。例として、Netflix を考えてみます。そのインターフェイスは、ビデオへのアクセス、検索、プレビューが可能です。これらの機能は、ブラウザでの認証、検索、プレビューの実行など、それぞれ一つの機能を扱う小さなサービスによって実現されている可能性が高いです。このアーキテクチャ手法により、モノリシックアプリケーション（以下に詳細あり）のようにすべてが密接に結合している場合よりも、開発者は新機能を迅速に導入したり機能を更新したりすることができます。解決すべき問題はなんですかアプリケーションは、さまざまなパーツで構成され、それぞれが特定の能力を担当します。特定の機能に対する需要は、アプリケーションの他のパーツに対する需要と連動して必ず増減するわけではありません。 Netflix の例に戻りましょう。例えば、大規模なマーケティングキ...

マルチテナンシー

マルチテナンシーとは、複数のテナントにサービスを提供する単一のソフトウェアインストールを指します。テナントとは、自身のデータセットでソフトウェアを利用するユーザー、アプリケーション、あるいはそれらのグループのことです。これらのテナントは(所有者による明示的な指示がある場合を除いて)データを共有せず、互いの存在を意識することもありません。テナントは、1人の独立したユーザーで1つのログインIDを持つほど小さくなり得ます。例えば、個人の生産性を高めるソフトウェアを考えてみてください。あるいは、何千ものログインIDを持つ企業全体ほど大きくもなり得ます。これらは、それぞれが独自の権限を持ちつつも多方面で相互に関連しています。マルチテナントソフトウェアの例には、Google Mail、Google Docs、Microsoft Office 365、Salesforce CRM、Dropboxなどがあり、完全または部分的にマルチテナントソフトウェアとして分類されます。解決すべき問題はなんですかマルチテナンシーがなければ、各テナントに専用のソフトウェアインストールが必要になります。...

モノリシックアプリケーション

モノリシックアプリケーションは単独で配置できるプログラムにすべての機能を格納しており、アプリケーションを開発する時に最も簡単かつ手軽な出発点とされています。しかし、アプリケーションが複雑になると、モノリスのメンテナンスが難しくなることがあります。また、同じコードベースで作業する開発者が増えるため、変更が競合したり、開発者の間で直接コミュニケーションを取る必要性が高まります。解決すべき問題はなんですかアプリケーションをマイクロサービスに移行するとテスト、デプロイ、実行などの運用オーバーヘッドが増加します。そのため、製品ライフサイクルの初期段階には製品を複雑化させる物は先送り、製品が成功したと判断されるまでモノリシックアプリーケーションで設計することが有利な場合もあります。どのように役に立つのでしょうか適切に設計されたモノリスはアプリケーションを起動して実行する最も簡単な方法であるため、簡潔さを維持できます。モノリシックアプリーケーションがビジネス的に価値があると証明されれば、アプリケーションを分割し、マイクロサービス化させる事も可能です。価値が証明される前に技術的努力を...

ランタイム

一般的に、ランタイムはソフトウェアの一部を実行します。これは、プログラムのコマンドをオペレーティングシステムのアクションに変換する、下層レイヤーとなるオペレーティングシステムの抽象化です。クラウドネイティブの文脈では、ランタイムは一般的にコンテナランタイムを指します。コンテナランタイムは、Open Container Initiativeの仕様を具体的に実装します。これは異なるコンテナオーケストレーション技術の間で一貫した取り扱いを保証するためです。解決すべき問題はなんですかコンテナランタイムの抽象化がなければ、アプリケーションは各オペレーティングシステムのすべての技術を取り扱う必要があります。結果としてアプリの実行の複雑さが増します。どのように役に立つのでしょうかコンテナランタイムは、Kubernetesのようなコンテナオーケストレーターに必要なコンポーネントです。これらは主に3つのことを行う、コンテナライフサイクルを処理します。まずコンテナイメージがどのように指定され、ランタイムがそれらをどのように取得するかを定義します。次にこれらのイメージがどのように展...

仮想マシン

仮想マシン（VM）とは、特定のハードウェアに縛られないコンピューターとそのオペレーティングシステムのことです。 VMは、1台の物理コンピューターを複数の仮想コンピューターに分割する仮想化に依存しています。この分割は、組織やインフラプロバイダーに、下層のハードウェアに影響を与えることなく、VMを簡単に作成、破棄することを可能にします。解決すべき問題はなんですか仮想マシンは仮想化を利用しています。ベアメタルマシンは単一のオペレーティングシステムに縛られているので、マシンのリソースをどれだけ使えるかはある程度制限されます。また、オペレーティングシステムも単一の物理マシンに縛られているので、その可用性はハードウェアに直結します。物理マシンがメンテナンスやハードウェア故障によりオフラインになると、オペレーティングシステムもオフラインになります。どのように役に立つのでしょうかオペレーティングシステムと物理マシンとの直接的な関係を取り除くことで、プロビジョニングの時間やハードウェア利用率、弾力性といったベアメタルマシンが抱えるいくつかの問題を解決することができます。新しいハードウェアの...

仮想化

クラウドネイティブコンピューティングにおける仮想化とは、サーバーとも呼ばれる物理コンピューターを確保し、その上で複数の隔離されたオペレーティングシステムを動かせるようにするプロセスを指します。そういった隔離されたオペレーティングシステムとそれらに割り当てられた計算資源(CPU、メモリ、ネットワーク)は、仮想マシンやVMと呼ばれます。仮想マシンはソフトウェア的に作り出されたコンピューターを意味します。仮想マシンは実際のコンピューターのように見えたり動作したりしますが、他の仮想マシンとハードウェアを共有しています。クラウドコンピューティングは主に仮想化技術の恩恵を受け提供されています。例えば、AWSで作成し使用できる「コンピューター」は実際のところはVMです。解決すべき問題はなんですか仮想化によって、我々は多くの課題に対処することができます。例えば、仮想化によって同じ物理的なハードウェア上により多くのアプリケーションを互いに隔離しつつ動かすことができるので、セキュリティを保ったまま物理マシンの使用率を改善することができます。どのように役に立つのでしょうか仮想マシン上で...

継続的インテグレーション(CI)

継続的インテグレーション(CI)とは、コードの変更を可能な限り定期的に統合することを指します。 CIは継続的デリバリー(CD)の前提条件です。伝統的に、CIのプロセスはバージョンコントロールシステム(GitやMercurial、あるいはSubversion)にコードの変更がコミットされることで開始し、CDシステムで利用できるようになったテスト済みの成果物で終了します。解決すべき問題はなんですかソフトウェアシステムはしばしば大規模で複雑であり、多くの開発者が維持や更新をしています。システムの異なる部分で並行して作業を行う開発者たちは、意図せずに互いの作業を壊すような矛盾した変更を加えることがあります。さらに、同じプロジェクトに複数の開発者が取り組む場合、テストやコード品質の計測といった日常的なタスクは、各開発者によって繰り返される必要があり、時間の無駄になります。どのように役に立つのでしょうか CIソフトウェアは、開発者が変更をコミットするたびに、コードの変更がスムーズにマージできることを自動的に確認します。 CIサーバーを使用してコードの品質チェック、テスト、さらにはデプロ...

継続的デプロイメント(CD)

継続的デプロイメント(しばしばCDと略される)は、完成したソフトウェアを直接本番環境にデプロイするという点で継続的デリバリーより一歩進んでいます。継続的デプロイメント(CD)は継続的インテグレーション(CI)と密接に関連しており、しばしばCI/CDと呼ばれます。 CIプロセスは特定のアプリケーションへの変更が有効であるかどうかをテストし、CDプロセスはコードの変更を自動的に組織のテスト環境や本番環境にデプロイします。解決すべき問題はなんですか新しいソフトウェアバージョンのリリースは、労力がかかりエラーが発生しやすいプロセスです。また本番環境でのインシデントを避け、エンジニアが通常の業務時間外に対応する時間を減らすため、組織が頻繁に行わないことも多いです。伝統的なソフトウェアデプロイメントモデルでは、ソフトウェアのリリースプロセスが組織の安定性と機能の速度の両方に関するニーズを満たせず、組織を悪循環に陥らせます。どのように役に立つのでしょうかリリースサイクルを自動化し、組織が頻繁に本番環境へのリリースを強制することにより、CDは運用チームに対して、CIが開発チームにもたらし...

継続的デリバリー(CD)

継続的デリバリー(しばしばCDと略される)は、コードの変更が自動的に受け入れ環境にデプロイされる(または継続的デプロイメントの場合、本番環境にデプロイされる)一連の実践を指します。 CDは、ソフトウェアがデプロイメント前に適切にテストされていることを保証する手順を重要視し、必要と判断された場合に変更をロールバックする方法を提供します。継続的インテグレーション(CI)は継続的デリバリーに向けた最初のステップです(つまり、テストやデプロイがされる前に、変更がうまく統合されなければなりません。) 解決すべき問題は何ですか大規模な環境では、信頼性の高いアップデートのデプロイが問題となります。理想的には、エンドユーザーにより良い価値を提供するために、頻繁にデプロイを行いたいところです。しかし、それを手動で行うと変更ごとに高いトランザクションコストが発生します。歴史的に、これらのコストを避けるために、組織は頻繁にリリースを行わず、一度に多くの変更をデプロイしてきましたが、これにより何かが間違ってしまうリスクが高まります。どのように役に立つのでしょうか CD戦略は、完全に自動化された本番...

貢献の方法

ようこそクラウドネイティブ用語集の貢献ガイドへようこそ。このプロジェクトに貢献できる方法はいくつかありますが、ここではその詳細を説明します：既存の課題に取り組む新しい用語の提案既存の用語を更新する用語集を翻訳する CNCF用語集レビューこの用語集のゴールは、複雑なことで有名なクラウドネイティブの空間をシンプルにすることで、より多くの人に親しんでもらうことです。クラウドネイティブ用語集のコンテンツはGitHub repo に保存されています。ここには、用語集に関するissues, pull request (PRs), そしてdiscussions のリストがあります。誰が貢献できるのか？このプロジェクトにどのように参加できるかは、クラウドネイティブの専門知識のレベルによって異なります。複雑な概念を簡略化するには、そのトピックに関する深い知識が必要です。したがって、新しい用語を寄稿するには、その用語に精通している必要があります。貢献者は通常、これらの技術にしばらく携わってきたエンジニアや、クラウドネイティブに焦点を当てたアカデミックの経験者です。複雑な概念を...

貢献者のラダー

こんにちは！👋 CNCFクラウドネイティブ用語集プロジェクトへの貢献に関心をお寄せいただきありがとうございます。新しい用語を投稿する、用語集を母国語にローカライズするのを手伝う、または他の人が用語集を始めるのを手助けするなど、このコミュニティのアクティブメンバーになる方法はたくさんあります。このドキュメントでは、プロジェクト内におけるそれぞれの貢献者の役割と、それに伴う責任と権限の概要を説明します。 1. 貢献者用語集はすべての人のためのものです。このプロジェクトに貢献するだけで、誰でも用語集の貢献者になることができます。すべての貢献者は、CNCF行動規範に従うことが期待されています。プロジェクトに貢献するには、以下のようなさまざまな方法があります：コンテンツの貢献者: 既存の用語を改良したり、新しい用語を投稿する方々ローカライゼーションの貢献者: 用語集を他の言語に翻訳するのを手伝ってくれる方ヘルパー：GitHubやSlackなど、コミュニティメンバーがサポートを必要としている場所で助ける方アンバサダー：多くの人にメッセージを伝え、コミュニティに貢献の仕方やその理由につい...

自己修復

自己修復システムは、人の手の介入なしに特定のタイプの障害から回復することができます。このシステムには「収束」あるいは「制御」するループがあり、システムの実際の状態を積極的に確認して、運用者が初めに望んだ状態と比較します。もし違いがある(例えば、望まれているよりも実行中のアプリケーションのインスタンスが少ない)場合、修正するための行動を行います(例えば、新しいインスタンスを起動します)。

信頼性

クラウドネイティブの観点から見ると、信頼性とはシステムが障害にどれだけうまく対応するかを指します。インフラストラクチャが変化し、個々のコンポーネントが故障しても動作し続ける分散システムがあれば、それは信頼性があります。一方で、容易に故障し、運用者が手動で介入して動作を維持する必要がある場合、それは信頼性がないです。クラウドネイティブアプリケーションの目標は、本質的に信頼性の高いシステムを構築することです。

垂直スケーリング

垂直スケーリング(「スケールアップおよびスケールダウン」とも呼ばれる)は、個別のノードにCPUとメモリを追加することでシステムの処理能力を強化する方法です。例えば、4GB RAMのコンピューターを持っていて、その容量を16GB RAMに増やしたい場合、垂直スケーリングすることは、16GB RAMシステムに切り替えることを意味します。 (別のスケーリングアプローチについては、水平スケーリングを参照してください。) 解決すべき問題はなんですかアプリケーションへの需要が現在のアプリケーションインスタンスの処理能力を超えると、システムに処理能力を強化する方法が必要です。既存のノードにさらなる計算リソースを追加する(垂直スケーリング)か、システムにより多くのノードを追加する(水平スケーリング)ことができます。スケーラビリティは、競争力、効率、評判、品質に貢献します。どのように役に立つのでしょうか垂直スケーリングは、アプリケーションのコードを変更せずにサーバーの処理能力を変更することができます。一方で、水平スケーリングの場合、アプリケーションがスケールするために複製可能でなければなり...

水平スケーリング

水平スケーリングは、より多くのノードを追加することでシステムの処理能力を向上させる手法です。個別のノードにより多くの計算リソースを追加する手法とは異なります(後者は垂直スケーリングとして知られています)。たとえば、RAM容量4GBのシステムを持っていて、そのRAMを16GBに増やしたい場合、水平スケーリングはRAM 16GBのシステムに切り替えるのではなく、RAM 4GBのマシン4台で対応します。このアプローチは、新しいインスタンスまたはノードを追加することで、負荷をより効果的に分散し、アプリケーションのパフォーマンスを向上させます。簡単に言えば、個別のサーバーの処理能力を強化することではなく、個別のサーバーの負荷を減らすことを目指しています。解決すべき問題はなんですかアプリケーションに対する需要がそのアプリケーションインスタンスの現在の処理能力を超えた場合、システムに処理能力をスケールする(処理能力を向上させる)方法が必要になります。システムにノードを追加する(水平スケーリング)か、既存のノードにより多くの計算リソースを追加する(垂直スケーリング)かのいずれかが可能で...

疎結合アーキテクチャ

疎結合アーキテクチャは、アプリケーションの構成要素それぞれが互いに独立して構築されるようなアーキテクチャです(その逆は密結合アーキテクチャと呼ばれます)。マイクロサービスとよく呼ばれる個々の構成要素は、その他多くのサービスから利用できるような方法で、特定の機能を果たすよう構築されます。疎結合アーキテクチャは密結合アーキテクチャより一般的に実装が遅くなりますが、特にアプリケーションがスケールする際に多くの利点があります。アプリケーションが疎結合だと、チームは独立して機能開発、デプロイ、スケールすることが可能です。よって組織は個々の構成要素における開発サイクルを素早く反復することができます。アプリケーション開発はより速くなり、チームは能力に基づいて構成され、特定のアプリケーションに注力することができます。

相互TLS認証(mTLS)

相互TLS認証(mTLS)は、2つのサービス間で送信されるメッセージを認証し、暗号化するために使用される技術です。相互TLS認証は、標準のTransport Layer Security (TLS)プロトコルですが、一方の接続元だけを検証するのではなく、その両方が検証されます。解決すべき問題はなんですかマイクロサービスはネットワーク上で通信します。そして、あなたのWi-Fiネットワークのように、そのネットワーク上での通信はハッキングされる可能性があります。 mTLSは、関係者以外が盗聴したり、正当なリクエストになりすましたりすることを防ぎます。どのように役に立つのでしょうか mTLSは、クライアントとサーバー間の双方向のトラフィックが安全で信頼できることを保証します。また、ネットワークやアプリケーションにログインするユーザーのための追加のセキュリティ層を提供します。これは例えばIoTデバイスのように、ログインプロセスを行わずに接続するクライアントデバイスからの接続も検証します。オンパス攻撃、スプーフィング攻撃、クレデンシャルスタッフィング、ブルートフォース攻撃などの攻撃...

抽象化

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

分散アプリケーション

分散アプリケーションは、機能が複数の独立したより小さな要素に分割されたアプリケーションです。分散アプリケーションは通常、広範なアプリケーション内で異なる機能を担う個々のマイクロサービスから構成されます。クラウドネイティブ環境において、個々のコンポーネントはクラスター内のコンテナとして実行されます。解決すべき問題はなんですか単一のコンピューター上で動作している単一のアプリケーションは単一障害点となります。もしそのコンピューターが故障した場合、そのアプリケーションは利用できなくなります。分散アプリケーションは、しばしばモノリシックアプリケーションと比較されます。モノリシックアプリケーションは、様々なコンポーネントが独立してスケールできないために、スケールが難しい場合があります。さらに、それらは成長するにつれて開発者の速度の妨げになることもあります。なぜなら、より多くの開発者が明確に定義された境界を持つとはかぎらない共有のコードベースで作業する必要があるからです。どのように役に立つのでしょうか単一のアプリケーションを異なる部分に分割し、それらを多くの場所で実行すると、シ...

分散システム

分散システムは、ネットワーク上で接続された自立型のコンピューティング要素の集合であり、ユーザーから見ると1つの統一されたシステムとして見えます。一般的にはノードと言われるこれらの要素は、ハードウェアデバイス(例: コンピューターや携帯電話)やソフトウェアのプロセスです。ノードは共通の目標を達成するためにプログラムされており、連携するためにネットワーク上でメッセージを交換します。解決すべき問題はなんですか現代の多くのアプリケーションは、運用するのにスーパーコンピューターが必要になるほど大規模です。 GmailやNetflixを考えてみて下さい。単一のコンピューターでは、アプリケーション全体を提供するのに十分な性能がありません。複数のコンピューターを接続することで、計算能力はほとんど無制限になります。分散コンピューティングなしでは、今日、我々が頼りにしている多くのアプリケーションは実現できないでしょう。従来、システムは垂直にスケールするものでした。これは、個々のマシンにCPUやメモリを追加するときのことを指します。垂直スケーリングには時間がかかり、ダウンタイムを必要と...

密結合アーキテクチャ

密結合アーキテクチャは、アプリケーション構成要素の多くが互いに依存しているようなアーキテクチャを指します (その逆は疎結合アーキテクチャと呼ばれます)。密結合であることは、ある構成要素に対する変更がその他の構成要素に影響を与えうることを意味します。一般的に、密結合アーキテクチャはより疎結合なアーキテクチャと比較して簡単に実装できますが、カスケード障害と呼ばれる連鎖的な障害に対してシステムがより弱くなる可能性があります。また、しばしば構成要素を協調してロールアウトする必要が生じるため、開発者の生産性に対する足かせとなる可能性があります。密結合なアプリケーションアーキテクチャはかなり古典的なアプリケーション構築方法です。マイクロサービス開発のベストプラクティス全てには必ずしも整合しませんが、密結合アーキテクチャは特定の場合に有用です。密結合アーキテクチャでの開発は、実装がより簡潔で早くなる傾向があり、モノリシックアプリケーションとよく似て初期開発サイクルを加速させる可能性があります。

冪等性

数学やコンピューターサイエンスにおいて、冪等性とは、何度実行しても常に同じ結果になる操作を指します。パラメーターが同じであれば、冪等な操作を複数回実行しても、追加の効果はありません。