分散システムは、ネットワーク上で連携して動作する独立したコンピューターとデバイスの集合であり、外部からは単一の統合システムであるように見えます。
分散システムでは、同時に稼働する多数のマシンで作業とデータを分割するため、完了するまでに大規模なマシン1週間かかったかもしれないジョブが、数時間、あるいは数分で完了することもあります。システム内の各マシン、つまり「ノード」には独自のCPU、メモリー、そして多くの場合、独自のストレージがあります。ノードは相互にメッセージを送信してデータ共有を調整し、作業を分割し、共通の目標に向けて作業を組み合わせることができます。
分散システムでは、マシンは(データセンターの)同じサーバー・ラックにあるかもしれないし、異なるデータセンターにまたがっているかもしれないし、世界中に広がるハイブリッドクラウド環境にあるかもしれない。構成に関わらず、分散システムは、ユーザーやクライアント・アプリケーションが、個々のサーバーの集合体ではなく、あたかも単一のサービス(「データベース」、「ウェブサイト」、「ストレージ・サービス」など)であるかのように操作できるように設計されています。
分散システムは、現代のコンピューティングにおける差し迫った課題に対するソリューションを企業に提供します。今日のアプリケーションの多くは、大きすぎたり、多すぎたり、非常に重要すぎたりして、1台のマシンで適切に実行できません。これらのアプリケーションは、単一のサーバーを過負荷にする可能性のある大量のデータと要求を頻繁に処理します。これらは、アジャイルなロード・バランシング機能を必要とする急激なトラフィック・フローに対処します。大規模なダウンタイムは致命的となる可能性があるミッションクリティカルなプロセス(銀行システムなど)を管理するため、
分散システムは、ワークロードを多数のノードに分散させ、必要に応じてネットワークにノードを自動的に追加することができます。この拡張性により、トラフィック・フローが予測不可能であっても、より多くのユーザーとデータに対応できます。例えば、ストリーミング・プラットフォームが世界中の何百万人ものユーザーに、多くの場合同時にサービスを提供できるのは、分散システムの拡張性があるからです。
分散システムは、ITアーキテクチャーの信頼性と耐障害性の最適化にも役立ちます。1つのノードに障害が発生しても、他のノードがその作業を引き継ぐことができ、サービス全体が実行し続けることができます。この機能は単一障害点を減らし、企業が高可用性システムを維持する上で役立ちます。これは、ほぼ100%のアップタイムを必要とするシステムにとって非常に重要です。
さらに、分散システムでは、別々のノードが緊密に連携しますが、それぞれ独自のデータベースとストレージ・システムを持っています。この配置により、ITチームは、システムのさまざまな部分を独立して拡張し、進化できるモジュール式アーキテクチャーを簡単に構築できます。
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
分散システムはさまざまなアーキテクチャーで構成されていますが、すべてに共通する一連のコア特性があります。
分散システム内のマシンは、データ、ストレージ、処理能力、サービスをプールできます。参考情報共有により、最も必要とされる場所に参考情報をプールして使用できるため、システム全体の効率が向上します。
同時実行により、分散システムの複数の部分を同時に実行できるため、異なるノードがデータ要求を同時に処理できます。ノード同期により、システム全体のスループットが向上します。
拡張性により、分散システムでは、システム全体を置き換えるのではなく、マシンを追加することで、より多くのユーザーとデータを処理できます。例えば、ストリーミング・サービスでは、より多くの人が同時にライブ・イベントの視聴を開始するため、サーバーをさらに追加できます。
可用性とフォールト・トレランスは、複製(システムが複数のノードにデータとサービスのコピーを保管する)と呼ばれるプロセスを使用して、システムのダウンタイムを最小限に抑えることに重点を置いた関連する概念です。
可用性があると、一部の部品が利用できない場合でもユーザーがシステムにアクセスできるようになります。フォールト・トレランスにより、1つ以上のノードに障害が発生した場合でも、レプリカを使用して分散システムを次に進むことができます。
異種性とは、分散システムがさまざまな種類のハードウェア、オペレーティング・システム、プログラミング言語、ミドルウェアを含む可能性があり、実際にそうである可能性が高いことを意味します。ネットワーク・ノードは同一である必要がないため、チームは相互運用性を損なうことなく新しいマシンを追加し、各ジョブに最適なツールを自動的に選択するアーキテクチャーを構築できます。
統合により、分散システムはその内部の複雑さをユーザーから隠すことができます。ユーザーは、どのサーバーがリクエストに応答したのか、データが物理的にどこにあるのかを知る必要はありません。1つの統合システムと対話できれば十分です。
分散システムがどのように機能するかを理解するために、大規模マルチプレイヤー・オンライン・ゲーム(MMOG)を例に挙げてみましょう。
MMOGは、多数のサーバーとノードが連携して1つの永続的なゲーム世界を維持する分散アーキテクチャーを使用しているため、何千人ものプレイヤーが同時に飛行、取引、戦闘、探索を行うことができます。
ゲームの世界は巨大で、プレイヤー数も非常に多いため、ゲームのバックエンドは単一のシステムで処理されるのではなく、マシンのクラスターに分割されます。1セットのサーバーはゲーム世界の機能(プレイヤーの位置、損害、インベントリー)を追跡し、インフラストラクチャーの他の部分はユーザー・ログイン、チャット機能、世界の永続性を処理します。この分割により、多くのプレイヤーが同時に同じ地域でアクティブになっている場合でも、ゲームの即応性を維持できます。
各ゲームセッション中、システムはすべてのプレイヤー間でゲームの状態を同期させておく必要があります。プレイヤーが行動(例えば、艦隊戦闘中に船を移動させるなど)を行うと、クライアントはゲーム世界のその部分に適したサーバーにアクションを送信します。その後、サーバーは共有ゲームの状態をリアルタイムで更新し、その結果を確認する必要のある他のプレイヤーと共有します。
さらに、分散ゲーム・システムでは特殊なプロトコルを使用して、すべてのプレイヤーが同じゲーム・イベントがほぼ同時に発生するのを確認できます。
ゲームプレイ中にサーバーに障害が発生した場合、他のサーバーは引き継ぎによって正常に稼働し続けるように設計されているため、プレイヤーは中断を経験することがありません。
分散システムは、集中型システムとは機能的に反対です。分散システムがデバイスの集合を使用してオペレーションを強化する場合、集中型システムは1台のメイン・サーバーに依存します。
集中型システムでは、1つの中央ノードがほとんどまたはすべてのオペレーションを調整します。通常、クライアントはそのノードにリクエストを送信し、ノードがその処理方法を決定します。この動的性により、権限が1か所にまとめられ、システムが理解しやすくなります。
ただし、単一ノードは単一障害点を意味します。集中型システムでは、中央サーバーがダウンすると、システム全体が利用できなくなるため、高可用性が重要な状況では、集中化は重大な問題を引き起こす可能性があります。
集中型システムは多くの場合、垂直方向に拡張します。ITチームがメイン・サーバーを改善したい場合、プロセッサ、メモリー、またはストレージを増やして改善します。残念ながら、垂直スケーリングは長期的に持続可能な方法ではありません。時間が経つにつれて、ハードウェアの要求が過剰になり、高価になりすぎます。
そのため、集中型システムは、超高レジリエンスよりもアーキテクチャーの簡素化と一元的な監視が重要な状況に最適です。集中管理は、1つの機関が厳密な管理を必要とする小規模なコンピューター・ネットワーク、内部ビジネス・システム、ファイル・サーバー、クライアント・サーバー・アプリケーションによく使用されます。
分散システムでは、完全に制御できる単一のマシンは存在しません。複数のノードが連携し、各ノードがワークロードの一部を処理したり、データの一部を保存したりできます。この構造は本質的により柔軟ですが、ノード間の調整が必要です。
分散システムは、1つのノードに障害が発生しても他のノードが動作し続けることができるため、耐障害性が高くなります。分散システムでも障害が発生する可能性はありますが、集中型システムよりも正常に劣化する傾向があります。
分散システムは水平スケーリングに依存しており、システムは参考情報の増加に対応するためにマシンを追加します。
そのため、多数のユーザー、大規模なデータ・セット、または地理的な分散が1つの中央マシンを非現実的なものにする状況では、分散環境が好まれることが多いです。分散システムは、高い可用性と拡張性を必要とするWebサービス、クラウド・プラットフォーム、ブロックチェーン・ネットワーク、大規模サービスでは一般的です。
分散システムは、マシンの編成方法と通信方法に基づいて、いくつかの共通タイプにグループ化できます。
クライアント・サーバー・システムでは、1台の中央サーバー(または小規模なサーバー・グループ)がサービスを提供する一方で、他のマシン(「クライアント」)は中央サーバーの作業に依存しています。
中央サーバーは、多くの場合、ハードウェアの点でより強力なマシンであり、共有参考情報(ファイル、データベース、プリンター、ユーザー・アカウント)の管理を担当します。クライアントは通常、ユーザーとの対話やリクエストと応答の処理に重点を置いたエンド・ユーザー・マシン(ノートPC、モバイル、ブラウザー)です。
クライアントと中央サーバーは別々のマシン上で実行され、ネットワークを介して通信するため、クライアント・サーバー・システムは分散システムとみなされます。ただし、クライアント・サーバー・アーキテクチャー内のノード間の通信は集中化されます。
すべてのクライアントは共有リソースにアクセスするために中央サーバーに依存しており、クライアント同士がそれらのリソースについて直接話し合うことはありません。代わりに、クライアントとサーバー間の通信は通常、リクエスト/レスポンスのパターンに従います。
ユーザーがアクション(ボタンをクリックするなど)を実行すると、クライアントはそのアクションを要求メッセージに変換し、ネットワークを介してサーバーに送信します。サーバーはリクエストを受信し、処理して、応答を送り返します。次に、クライアントは応答を解釈し、結果を人間が読める方法でユーザーに示します。
例えば、Webアプリケーションでは、WebサーバーにHTTPリクエストを送信し、データベースに読み書きを行ってHTMLまたはJSON応答を返すブラウザー(クライアント)を使用する場合があります。
集中通信により、クライアント・サーバー・システムの更新、セキュリティー・ポリシーの適用、データ管理が容易になります。ただし、トレードオフは、一元化によってボトルネックや単一障害点が発生する可能性があることです。
ピアツーピア・システムでは、「ピア」と呼ばれるすべてのノードがほぼ同じ役割を持ちます。各ピアは独自の参考情報の一部を提供し、他のピアから提供された参考情報を消費します。すべてのピアは、参考情報を要求することも、他のノードに提供することもできます。
したがって、P2Pシステムの「クライアント」と「サーバー」は、ノードが一時的に果たす役割であり、固定IDではありません。
純粋なP2Pシステムでは、ピアは互いに発見し、オーバーレイ・ネットワーク(物理的なインターネット接続の上に構築された論理ネットワーク)を介して通信します。オーバーレイ・ネットワークは、誰が誰と通信するか、またピア間でデータをルーティングする方法を決定します。
ピアが何か(ファイルのチャンクなど)を必要とする場合、それを持っている可能性のある他のピアにリクエストを直接送信します。また、別のピアがリクエストを受信すると、応答して要求されたデータを送り返し、その瞬間に効果的にサーバーとして機能します。その後で、役割が交換され、同じ2つのノードによって、データを提供している人と要求している人が逆転する場合があります。
すべてのピアは与えたり与えたりすることができるため、データ処理のワークロードはネットワーク全体でより均等に分散される傾向があります。また、同業他社が増えるにつれて、より多くの容量が得られるため、システムをより簡単に拡張できるようになります。
従来のファイル共有ネットワークは、P2Pシステムの良い例です。各ユーザーのコンピューターはファイルの一部を保管し、それらを他のノードにアップロードすると同時に、不足しているファイルもダウンロードします。
P2Pシステムは、クライアント・サーバー・システムよりも単一障害点に対して堅牢です。1つのピアがオフラインになっても、他のピアがデータのコピーを保持しているか、障害が発生したノードを避けてデータをルーティングできるため、通常はシステム全体が稼働し続けます。
多層システムは、基本的なクライアント・サーバー・モデルを拡張し、それを複数の明確に分離されたレイヤーに編成し、それぞれに独自のジョブを持たせます。最も一般的な形式は、2層、3層、n層です。
2層システムは、別の名前でクライアント・サーバー・アーキテクチャーです。クライアントにはアプリケーション・ロジックのほとんどが含まれており、サーバーのデータベースと直接通信して照会と更新を実行します。このプロセスは単純ですが、ユーザー・インターフェースとデータとを密接に結合させます。データ構造の変更は、他の多くのクライアントにも変更を強制する可能性があります。
3層アーキテクチャーは3つの層を使用します。プレゼンテーション層は、ユーザー・インターフェース(Webページ、モバイルUI、デスクトップUI) を処理します。アプリケーション層、または「ビジネス・ロジック」層は、ルールやワークフロー(検証、計算、意思決定)を実装します。データ層は、分散データベースや他のストレージ・システムからデータを保管および取得します。
N層システムは、より特殊な層を追加することで3層の概念を拡張します。例えば、ITチームは、RESTやGraphQLのエンドポイントを公開する別のアプリケーション・プログラミング・インターフェース(API)またはサービス層を作成することを選択するかもしれません。また、ユーザーのログインやトークンを処理するために、認証や暗号化レイヤーを分離することもあります。
追加層は、最初の3層と同じ原則に従います。各層には1つの主な責任があり、層は明確に定義されたインターフェースを介して通信します。このモジュール性により、チームはさまざまな層を個別に作業、アップグレード、交換でき、場合によってはそれぞれに異なるテクノロジーを使用することもできます。
多層システムは、電子商取引Webサイトや銀行アプリケーションを実行するために一般的に使用されます。
クラスターとは、近くに配置されたコンピューターのグループで、あたかも単一のより強力なマシンであるかのように動作します。クラスター内のノードは密結合であるため、通常は次のようになります。
クラスターはノードが類似しており、適切に接続されているため、大きなタスクを小さな断片に分割して、異なるノードで並列処理し、その成果を結合できます。
クラスターは、クラスター・ミドルウェア、スケジューラー、Resource Managerなどの特別なソフトウェアによって管理されます。このソフトウェアは、どのノードがどのジョブを実行するかを決定し、ノードのヘルスを監視し、データ・ルーティングを管理し、ノード間のワークロードのバランスをとります。この管理層は、「ネットワーク上のコンピューターの集合」をクラスターに変えるものです。これにより、ユーザーは各マシンに手動でロギングする代わりに、クラスター全体にジョブを送信できます。
クラスター・システムは、ビッグデータ分析、AIモデル学習、科学シミュレーションなど、高性能計算を必要とする状況で有用です。
グリッド・コンピューティングとは、多くの場合、さまざまな都市や国に分散している多数の独立したコンピューターをプールし、単一の大規模な計算タスクで連携させることです。
グリッド内の各参加マシンは、異なる組織または個人に属している場合があります。それらはすべて、CPU、メモリーサイズ、オペレーティング・システム、およびローカルポリシーが異なる場合があります。ただし、一般的な問題に対しては空き参考情報の一部を共有することに同意しています。
グリッドは複数の管理ドメインにまたがるため、すべてのマシンを所有または完全に制御する組織は存在しません。これはグリッドとクラスターの根本的な違いであり、1つの機関が1つのデータセンターにあるサーバーを所有および管理します。
グリッド・システムでは、各ノードは自律的なままです。グリッドに参加したり離脱したりすることができ、独自のResource Managerを持ち、異なるセキュリティー・ルールや優先順位を持っている場合があります。グリッド・ミドルウェアは、ジョブの送信、利用可能な参考情報の発見、作業のスケジュール設定、データの移動、成果の収集を行うための共通層を提供します。このミドルウェアにより、グリッド全体がエンド・ユーザーにとって仮想スーパーコンピューターのように機能するようになります。
ユーザーが大規模なジョブ(タンパク質分割シミュレーションや財務リスク計算など)を送信すると、ミドルウェアは自動的にジョブを多くの小さなタスクに分割します。次に、グリッド内の任意の場所で、アイドル状態または使用率の低いマシンを検索して、それらにジョブの一部を割り当てます。各マシンはそれぞれの部分で処理を行い、最終的な回答にまとめて結果を返します。
重要なのは、グリッド・ノードはグリッド専用ではないということです。これらは、本業のローカル作業で忙しくないときに、予備のCPUサイクルを提供する通常のデスクトップまたはサーバーかもしれません。
クラウドベースの分散システムは、クラウド・プロバイダーが運営するビッグデータセンターの上に構築される。
組織は物理サーバーを所有するのではなく、インターネット経由で分散コンピューティング・リソースをレンタルします。これらのリソースは、仮想マシン(VM)、コンテナ、データベース、キュー、その他のマネージド・サービスとして公開される。
クラウド・システムは、何よりも弾力性があります。企業は、ワークロードが増加するとより多くのコンピューティング、ストレージ、またはネットワーク容量を要求し、負荷が軽減されたときに参考情報を解放することができます。また、企業はハードウェアを前払いで購入する代わりに、使用したリソースに対してのみ料金を支払うことができます。
クラウド・システムを使用することで、ITチームは動的な水平スケーリング・プロセスを実装できます。Auto-Scalingグループ(同一のサーバー・インスタンスの論理グループ)は、ワークロードのメトリクスの変動を監視します。負荷が設定された閾値を超えると、自動化ツールはより多くのサービスインスタンスを起動します。負荷が低下すると、余分なインスタンスを自動的にシャットダウンしてコストを節約します。
マイクロサービス・アーキテクチャーは、異なるマシン上で動作する複数の独立したコンポーネントを使用してソフトウェア・アプリケーションを構築する、アプリケーションレベルの分散システムです。
モノリシック・アプリケーションとは異なり、マイクロサービス・アーキテクチャー内の単一のマイクロサービスにはアプリ全体が含まれることはありません。代わりに、各マイクロサービスは特定の機能を担当し、他のコンテナから独立して実行される独自の小さなサービス(独自のコード、通常は独自のデータ・ストアを備えています)です。
マイクロサービスは独立しているため、独自に開発、デプロイ、拡張できますが、システムの利点はマイクロサービス間のコラボレーションによってもたらされます。
ユーザーがリクエストを送信すると、クライアントはメッセージを作成し、エッジ・デバイス(ロードバランサーやAPI Gatewayなど)に送信します。エッジ・デバイスはリクエストを適切なマイクロサービスに送信します。受信者マイクロサービスはメッセージを読み取り、独自のビジネス・ロジックを実行してからエッジ・デバイスに応答を送り返し、エッジ・デバイスからユーザーに応答を中継します。
分散システムは現実世界に蔓延しています。人々がエンターテイメント、ビジネス、財務管理に使用するツールやサービスの多くは、分散システム上に構築されています。
セルラー・ネットワークは、複数の地域に分散する多数の基地局(セル・タワーまたは小型アンテナ)で構成され、すべてがプロバイダーのコア・ネットワークとインターネットに接続されています。ユーザーが携帯電話を持って移動すると、電話信号はユーザーが気付かないうちにタワーからタワーへと移動します。
大規模なストリーミング・プラットフォームは、分散システムに大きく依存しています。複数のデータセンターのクラスター化されたサーバーを使用して、動画コンテンツを保存します。また、CDNを使用してコンテンツをチャンク化、複製、キャッシュし、世界中の何百万ものユーザーにコンテンツ・ストリームをオンデマンドで提供できるようにしています。
ブロックチェーン・ネットワーク(暗号通貨など)は、多くのノードが台帳のコピーを維持し、コンセンサス・アルゴリズムを通じて新しいトランザクションに合意する、分散型ピアツーピア・ネットワークです。各ノードは完全(または部分)のチェーンを保存し、新しいブロックを検証し、他のノードと共有するため、データと計算は真に分散されます。
AIとオートメーションの力を活用することで、問題がアプリケーションスタック全体でプロアクティブに解決します。
AIを活用したオブザーバビリティー(可観測性)機能により、運用の回復力を最大化し、クラウドネイティブなアプリケーションの正常性を確保します。
生成AIでITのオートメーションとオペレーションを強化して、ビジネスの優先事項に沿ったITインフラストラクチャーを実現します。