分散システムに関する20,000語の詳細な入門書

WeTest の紹介 QQ、WeChat、Taobao など、特定のインターネット アプリケーションのサーバー側システムがいかに優れているかについてはよく耳にします。では、インターネット アプリケーションのサーバー側システムの何が優れているのでしょうか?膨大な数のユーザーアクセスによってサーバー側のシステムが複雑になるのはなぜですか?この記事では、最も基本的なところから始めて、サーバー側システム テクノロジの基本的な概念を探ります。

[[331504]]

容量は分散システムが存在する理由である

インターネットビジネスが人気になると、最も顕著に発生する技術的な問題は、サーバーが非常に混雑することです。毎日 1,000 万人のユーザーが Web サイトにアクセスする場合、どのようなサーバー ハードウェアを使用していても、1 台のマシンだけでサポートすることは不可能です。したがって、インターネット プログラマーがサーバー側の問題を解決するときは、複数のサーバーを使用して同じインターネット アプリケーションにサービスを提供する方法を考慮する必要があります。これがいわゆる「分散システム」の起源です。

しかし、多数のユーザーが同じインターネット サービスにアクセスすることによって発生する問題は単純ではありません。表面的には、インターネットからの多くのユーザー要求を満たすために、最も基本的な要件は、いわゆるパフォーマンス要件です。ユーザーからは、Web ページの開きが非常に遅い、オンライン ゲームの動作が非常に遅い、などの報告があります。 「サービス速度」の要件には、実際には、高スループット、高同時実行性、低レイテンシ、負荷分散が含まれます。

スループットが高いということは、システムが同時に多数のユーザーをサポートできることを意味します。ここでの焦点は、システム全体が同時に対応できるユーザー数です。このスループットを単一のサーバーで達成することは絶対に不可能であるため、必要なスループットを達成するには複数のサーバーが連携する必要があります。複数のサーバが連携する中で、サーバの一部がボトルネックとなってシステム全体の処理能力に影響を与えないように、いかにサーバを有効活用するかは、アーキテクチャ面での慎重な検討が求められる分散システムです。

高い同時実行性は、高いスループットの要件の拡張です。多数のユーザーを抱える場合、不要な消費や待機なしに各サーバーが最大限の能力を発揮できることを私たちは心から願っています。ただし、ソフトウェア システムは、複数のタスクを同時に処理し、「可能な限り多くの」タスクを処理するように単純に設計されているわけではありません。多くの場合、どのタスクを処理するかを選択するために、プログラムで追加のオーバーヘッドが発生します。これは分散システムが解決する問題でもあります。

少人数のサービスでは低遅延は問題になりません。しかし、多数のユーザーがアクセスしたときに計算結果を素早く返す必要がある場合は、さらに困難になります。サイトにアクセスするユーザー数が多いためにリクエストがキューに入れられることに加え、キューの長さが長すぎるためにメモリ不足や帯域幅使用率などの空間的な問題が発生する可能性もあります。キューイングの失敗により再試行戦略が採用された場合、全体的な遅延は大きくなります。したがって、分散システムでは、より多くのサーバーがユーザー要求をできるだけ早く処理できるように、さまざまな要求の並べ替えと配布の方法を採用します。ただし、分散システムの数が多いため、ユーザー要求を複数回分散する必要があります。これらの配布および転送操作により、全体的な遅延が大きくなる可能性があります。したがって、分散システムでは、リクエストを分散するだけでなく、分散レベルの数を減らしてリクエストをできるだけ速く処理できるようにする必要があります。

インターネット ユーザーは世界中からアクセスするため、物理的な空間における遅延が異なるネットワークや回線からアクセスしている場合や、異なるタイム ゾーンからアクセスしている場合もあります。したがって、ユーザーソースの複雑さに効果的に対処するには、異なるスペースに複数のサーバーを配置してサービスを提供する必要があります。同時に、複数の異なるサーバーによって同時リクエストが効率的に実行されるようにする必要もあります。いわゆる負荷分散は、分散システムが本来備えているタスクです。

分散システムは、インターネットビジネスの収容力の問題を解決するためのほぼ最も基本的な方法であるため、サーバー側プログラマーにとって分散システム技術を習得することは非常に重要です。しかし、分散システムの問題は、いくつかのフレームワークやライブラリの使い方を習得するだけでは簡単に解決できません。なぜなら、1 台のコンピュータでプログラムを実行すると、無数のコンピュータで同時に実行されるプログラムとなり、開発や運用・保守に大きな違いをもたらすからです。

分散システムの収容能力を向上させる基本的な手段: 階層化モデル (ルーティング、プロキシ)

ポリモーフィック サーバーを使用してコンピューティング タスクを共同で完了する最も単純なアイデアは、各サーバーがすべての要求を完了できるようにし、その後、要求を任意のサーバーにランダムに送信して処理することです。最も初期のインターネット アプリケーションでは、DNS ポーリングは次のように実行されていました。ユーザーが Web サイトにアクセスするためにドメイン名を入力すると、ドメイン名は複数の IP アドレスの 1 つとして解釈され、Web サイトへのアクセス要求が対応する IP のサーバーに送信され、複数のサーバー (複数の IP アドレス) が連携して大量のユーザー要求を処理できるようになりました。

ただし、リクエストをランダムに転送するだけでは、すべての問題を解決できるわけではありません。たとえば、インターネット ビジネスの多くは、ユーザーのログインを必要とします。サーバーにログインした後、ユーザーは複数のリクエストを開始します。これらのリクエストをランダムに別のサーバーに転送すると、ユーザーのログイン ステータスが失われ、リクエスト処理の失敗が発生します。単にサービス転送のレイヤーに頼るだけでは不十分なので、ユーザーの Cookie またはログイン資格情報に基づいて、特定のビジネスを処理する後続のサーバーに情報を転送する一連のサーバーを追加します。

ログイン要件に加えて、大量のデータを処理するためにデータベースが必要であり、多くの場合、データは 1 つのデータベースにのみ集中できることがわかりました。そうしないと、他のサーバーに保存されているデータ結果がクエリ中に失われます。そのため、データベースを専用サーバーのグループに分割することがよくあります。

この時点で、アクセス、ロジック、ストレージという典型的な 3 層構造が出現していることがわかります。しかし、この 3 段階の結果ですべての病気が治るわけではありません。たとえば、ユーザーがオンラインでやり取りできるようにする必要がある場合 (オンライン ゲームが典型的な例です)、異なる論理サーバーに分割されたオンライン ステータス データは互いを認識することができません。このように、インタラクティブサーバーに似た特別なシステムを作成する必要があります。ユーザーがログインすると、特定のユーザーが特定のサーバーにログインしていることを示すデータのコピーもそこに記録されます。メッセージが対象ユーザーのサーバーに正しく転送されるには、まずすべての対話型操作がこの対話型サーバーを通過する必要があります。

たとえば、オンライン フォーラム (BBS) システムを使用している場合、投稿する記事を 1 つのデータベースだけに書き込むことは不可能です。これは、閲覧要求が多すぎるとデータベースの速度が低下するためです。フォーラムのセクションに応じて異なるデータベースに書き込んだり、複数のデータベースに同時に書き込んだりすることがよくあります。これにより、記事データを異なるサーバーに保存し、多数の操作要求に対応することができます。ただし、ユーザーが記事を読むときには、特定の記事がどのサーバーにあるかを調べるための特別なプログラムが必要です。この時点で、特別なプロキシ レイヤーを設定し、すべての記事リクエストをそのレイヤーに転送する必要があります。次に、事前に設定されたストレージ プランに従って、対応するデータベースを検索し、データを取得します。

上記の例によれば、分散システムは典型的な 3 層構造を持ちますが、実際には 3 層以上になることが多く、ビジネス ニーズに応じて複数のレベルに設計されます。リクエストを適切なプロセスに転送して処理するために、リクエスト転送専用のプロセスとサーバーを多数設計しました。これらのプロセスは、多くの場合、プロキシまたはルーターと呼ばれます。多層構造では、さまざまなプロキシ プロセスが存在することがよくあります。これらのプロキシ プロセスは、多くの場合、TCP を介してフロント エンドとバック エンドを接続します。しかし、TCP はシンプルである一方で、障害発生後の回復が難しいという問題があります。また、TCP ネットワーク プログラミングも少し複雑です。 ——そこで、より優れたプロセス間通信メカニズムであるメッセージ キューが設計されました。

さまざまなプロキシまたはルーター プロセスを通じて強力な分散システムを構築できますが、その管理の複雑さも非常に高くなります。そのため、階層化モデルに基づいて、階層化モデル プログラムをよりシンプルかつ効率的にするための方法がさらに考案されました。

並行性モデル（マルチスレッド、非同期）

サーバー側のプログラムを作成する場合、ほとんどのプログラムが同時に到着する複数のリクエストを処理することは明らかです。したがって、HelloWorld のように単純な入力から出力を計算することはできません。同時に多くの入力を取得するため、多くの出力を返す必要があります。これらの処理プロセス中に、プログラムがデータベース処理の結果を待ったり、別のプロセスへの要求の結果を待ったりするなど、「待機」または「ブロック」する必要がある状況に頻繁に遭遇します。要求を 1 つずつ処理すると、これらのアイドル待機時間が無駄になり、ユーザーの応答遅延が増加し、システム全体のスループットが大幅に低下します。

したがって、複数のリクエストを同時に処理する方法に関しては、業界には 2 つの一般的なソリューションがあります。 1 つはマルチスレッドで、もう 1 つは非同期です。初期のシステムでは、マルチスレッドまたはマルチプロセッシングが最も一般的に使用されていたテクノロジでした。この手法のコードは、各スレッドのコードが確実に順番に実行されるため、記述が比較的簡単です。ただし、複数のスレッドが同時に実行されるため、複数のスレッド間のコードの順序を保証することはできません。これは、同じデータを処理する必要があるロジックにとっては非常に深刻な問題です。最も簡単な例は、ニュースが読まれた回数を表示することです。 2 つの ++ 演算が同時に実行されると、結果に 2 ではなく 1 のみが追加される可能性があります。そのため、マルチスレッド環境では、多くのデータ ロックを追加する必要があり、スレッドのデッドロックが発生する可能性があります。

そのため、非同期コールバック モデルがマルチスレッドよりも人気になりました。マルチスレッドのデッドロック問題に加えて、非同期は、マルチスレッドでのスレッド切り替えの繰り返しによって発生する不要なオーバーヘッドの問題も解決できます。各スレッドには独立したスタック領域が必要です。複数のスレッドが並行して実行される場合、これらのスタックのデータをコピーする必要がある場合があり、これにより追加の CPU が消費されます。同時に、各スレッドはスタック領域を占有する必要があるため、スレッドの数が多い場合はメモリの消費量も膨大になります。非同期コールバック モデルはこれらの問題を非常にうまく解決できますが、非同期コールバックは並列処理の「手動バージョン」のようなもので、開発者が「並列」問題を自分で実装する必要があります。

非同期コールバックは非ブロッキング I/O 操作 (ネットワークとファイル) に基づいているため、読み取り関数と書き込み関数を呼び出すときに関数呼び出しで「スタック」する必要はなく、「データがあるかどうか」の結果をすぐに返します。 Linux の epoll テクノロジーは、基礎となるカーネル メカニズムを使用して、読み取りおよび書き込みの対象となるデータを持つ接続\ファイルをすばやく「見つける」ことを可能にします。各操作は非ブロッキングであるため、プログラムは 1 つのプロセスだけで多数の同時リクエストを処理できます。プロセスは 1 つしかないため、すべてのデータ処理の順序は固定されています。 2 つの関数のステートメントを複数のスレッドで交互に実行することは不可能であるため、さまざまな「ロック」は必要ありません。この観点から見ると、非同期ノンブロッキング技術は開発プロセスを大幅に簡素化します。スレッドは 1 つだけであり、スレッド切り替えなどのオーバーヘッドが必要ないため、スループットと同時実行性に対する要件が高い多くのシステムでは、非同期非ブロッキングが第一の選択肢となっています。

int epoll_create(int サイズ); //epoll ハンドルを作成します。サイズは、リスナーの数をカーネルに伝えるために使用されます。

int epoll_ctl(int epfd、int op、int fd、struct epoll_event *event);

int epoll_wait(int epfd、struct epoll_event * events、int maxevents、int timeout);

バッファリング技術

インターネット サービスでは、ほとんどのユーザー操作で即時に結果が返される必要があるため、レイテンシに関して一定の要件があります。オンラインゲームのようなサービスでは、遅延を数十ミリ秒以内に短縮する必要があります。したがって、遅延を減らすために、バッファリングはインターネット サービスで最も一般的なテクノロジの 1 つです。

初期の WEB システムでは、各 HTTP リクエストがデータベース (MySQL) への読み取りと書き込みによって処理されると、接続数がいっぱいになるため、データベースはすぐに応答を停止します。一般的なデータベースは数百の接続しかサポートしませんが、WEB アプリケーションの同時リクエストは簡単に数千に達する可能性があります。これは、設計が不十分な Web サイトの多くが、アクセス数が多すぎると停止してしまう最も直接的な理由でもあります。データベースへの接続とアクセスの数を最小限に抑えるために、多くのバッファリング システムが設計されてきました。これは、データベースからのクエリの結果を高速な機能に保存し、関連する変更がない場合にはそこから直接読み取るというものです。

最も一般的な WEB アプリケーション キャッシュ システムは Memcache です。 PHP 自体のスレッド構造により、ステートレスになります。初期の頃は、PHP 自体に「ヒープ」メモリを操作する方法さえなかったため、それらの永続的な状態は別のプロセスに保存する必要がありました。 Memcache は、一時的な状態を保存するためのシンプルで信頼性の高いオープン ソース ソフトウェアです。多くの PHP アプリケーションの現在の処理ロジックは、まずデータベースからデータを読み取り、次にそれを Memcache に書き込むというものです。次のリクエストが来たら、まず Memcache からデータを読み取ろうとします。これにより、データベースへのアクセスが大幅に削減される可能性があります。

ただし、Memcache 自体は独立したサーバー プロセスであり、特別なクラスタリング機能はありません。つまり、これらの Memcache プロセスを統合されたクラスターに直接編成することはできません。 1 つの Memcache では不十分な場合は、どのデータをどの Memcache プロセスに割り当てるかを手動でコードを使用して割り当てる必要があります。 ——本当に大規模な分散型 Web サイトの場合、このようなバッファ システムの管理は非常に面倒な作業です。

そのため、より効率的なキャッシュ システムの設計が検討され始めました。パフォーマンスの観点から、Memcache のすべてのリクエストは、メモリ内のデータを取得する前にネットワークを介して送信される必要があります。要求者自身のメモリにもデータが保存される可能性があるため、これは間違いなく少し無駄です。 ——これが、リクエスタのメモリを活用する多くのバッファリング アルゴリズムとテクニックを生み出したのです。最も単純な方法は、LRU アルゴリズムを使用して、ハッシュ テーブル構造のヒープ メモリにデータを配置することです。

Memcache にクラスタリング機能がないことも、ユーザーにとっての悩みの種です。そこで、多くの人が、データ キャッシュが異なるマシンに分散されるのを防ぐ方法を設計し始めました。最も単純なアイデアは、いわゆる読み取りと書き込みの分離です。つまり、キャッシュへの各書き込みは複数のバッファ プロセスに記録されますが、読み取りはどのプロセスからでもランダムに読み取ることができます。ビジネス データに明らかな読み取りと書き込みの不均衡がある場合、効果は非常に良好です。

ただし、コミュニティやゲームなどの一部のオンラインインタラクティブインターネットビジネスなど、すべてのビジネスが読み取りと書き込みの分離を単純に使用して問題を解決できるわけではありません。これらのビジネスのデータの読み取りと書き込みの頻度はそれほど違いがなく、非常に高いレイテンシも必要です。そのため、ローカル メモリとリモート プロセスのメモリ キャッシュを組み合わせて、2 段階のキャッシュを持つデータを提供する方法が模索されています。同時に、データはすべてのキャッシュ プロセスに同時にコピーされるのではなく、一定のルールに従って複数のプロセスに分散されます。 ——この分散パターンに使用される最も一般的なアルゴリズムは、いわゆる「コンシステント ハッシュ」です。このアルゴリズムの利点は、プロセスが失敗した場合に、クラスター全体ですべてのキャッシュされたデータを再配置する必要がないことです。データ キャッシュの分散が、データ ID を持つプロセスの数を単純に法とした場合、プロセス数が変わると、各データが格納されるプロセスの場所が変わる可能性があり、サーバーのフォールト トレランスに役立たないことが想像できます。

Oracle には、キャッシュ システム向けに設計された Coherence という製品があります。本製品は、ローカルメモリキャッシュとリモートプロセスキャッシュの連携利用をサポートする商用製品です。クラスター プロセスは完全に自己管理されており、データ キャッシュが配置されているプロセスでのユーザー定義の計算 (プロセッサ関数) もサポートします。これは単なるキャッシュではなく、分散コンピューティング システムでもあります。

ストレージ技術 (NoSQL)

CAP理論については皆さんもよくご存知だと思います。しかし、インターネットの初期の頃、まだ誰もが MySQL を使用していた頃は、データベースにさらに多くのデータを保存し、より多くの接続を実現する方法について多くのチームが頭を悩ませていました。データの保存方法がファイル中心で、データベースは補助的な手段となっている企業も数多くあります。

しかし、NoSQL が登場すると、多くのインターネット ビジネスのデータ形式が非常に単純で、リレーショナル データベースの複雑なテーブルは必要ないということが突然明らかになりました。インデックスの要件は、多くの場合、メイン インデックスに基づいて検索することだけです。データベース自体は、より複雑な全文検索を実行することはできません。そのため、現在では多くの高同時実行インターネット ビジネスがストレージ設備として NoSQL を好んでいます。最も古い NoSQL データベースには MangoDB などがあり、現在最も人気のあるのは Redis のようです。一部のチームでは、Redis をバッファ システムの一部と見なしており、実際に Redis のパフォーマンス上の利点を認識しています。

NoSQL のより重要な特徴は、より高速で大容量であることに加えて、このデータ保存方法では 1 つのインデックスに従ってのみ取得および書き込みが可能であることです。このような需要制約は、流通の面で利益をもたらします。このプライマリインデックスに基づいて、データが格納されるプロセス (サーバー) を定義できます。このようなデータベースのデータは、さまざまなサーバーに簡単に保存できます。分散システムの必然的なトレンドにより、データ ストレージ層はついに分散化の方法を見つけました。

分散システムの管理性によって生じる問題 分散システムでは、ニーズを満たすために多数のサーバーを単純に一緒に実行することはできません。単一のマシンや少数のサーバーのクラスターと比較すると、解決すべき特別な問題がいくつかあります。

ハードウェア故障率

いわゆる分散システムには、必ずしも 1 つのサーバーだけがあるわけではありません。サーバーの平均障害時間が 1% であると仮定すると、サーバーが 100 台ある場合、ほぼ常に 1 台のサーバーがダウンしていることになります。この例えはあまり正確ではないかもしれませんが、システムに含まれるハードウェアが増えると、ハードウェア障害は偶発的な出来事から避けられない出来事へと変わります。一般的に、関数型コードを書くときは、ハードウェアに障害が発生した場合にどうするかは考慮しません。分散システムを作成する場合は、必ずこの問題に直面することになります。そうしないと、1 台のサーバーのみが故障し、数百台のサーバーからなるクラスター全体が正常に動作しなくなる可能性が高くなります。

サーバー自身のメモリやハードディスクなどの障害に加え、サーバー間のネットワーク回線の障害も一般的です。さらに、この種の障害は散発的に発生する場合もあれば、自動的に回復する場合もあります。この問題に直面した場合、「故障した」マシンを単に取り外すだけでは十分ではありません。しばらくするとネットワークは回復する可能性がありますが、この一時的な障害により、クラスターの処理能力の半分以上が失われる可能性があります。

いつ発生するかわからないさまざまな障害に対して、分散システムがどのように自動的に保守・維持され、外部のサービスも可能な限り維持されるかは、プログラムを書く上で考慮しなければならない課題となっています。このような障害を考慮する必要があるため、アーキテクチャを設計する際には、冗長機能や自己メンテナンス機能を意識的に設定しておく必要があります。これらは製品に対するビジネス要件ではなく、純粋に技術的な機能要件です。この点に関して適切な要件を提示し、それを正しく実装できることは、サーバー側プログラマーの最も重要な責任の 1 つです。

リソース利用の最適化

多数のサーバーを含む分散システム クラスターでは、クラスターのハードウェア容量が限界に達した場合、最も自然なアイデアはハードウェアを追加することです。しかし、ハードウェアを「追加」することでソフトウェアシステムの持ち運び性能を向上させるのは、それほど簡単ではありません。ソフトウェアは複数のサーバーで動作するため、複雑で詳細な調整が必要です。クラスターの容量を拡張する場合、多くの場合、クラスター全体のサービスを停止し、さまざまな構成を変更し、最後に新しいサーバーを追加してクラスターを再起動する必要があります。

各サーバーのメモリ内にはユーザーデータが存在する可能性があるため、運用中にクラスター内で提供されるサービスの構成を軽率に変更しようとすると、メモリデータの損失やエラーが発生する可能性があります。したがって、Web サーバーを追加するなど、実行時にステートレス サービスの容量を拡張することは比較的簡単です。しかし、オンライン ゲームなどのステートフル サービスの場合、単純なランタイム拡張を実行することはほぼ不可能です。

分散クラスターでは、容量の拡張に加えて、容量の削減も必要です。ユーザー数が減少し、サーバーのハードウェア リソースがアイドル状態になると、これらのアイドル リソースを活用して、他の新しいサービス クラスターに配置する必要が生じることがよくあります。スケールダウンは、クラスターの障害による災害復旧に似ています。違いは、縮小のタイミングと対象が予測可能であることです。

分散クラスターの拡張と縮小、および可能な限りオンラインで運用したいという要望により、クラスター内の相互に関連する構成を正しく効率的に変更する方法、ステートフル プロセスを操作する方法、拡張と縮小中にクラスター内のノード間の正常な通信を確保する方法など、非常に複雑な技術的問題に対処する必要があります。サーバーサイドプログラマーとして、複数のプロセスのクラスター状態の変化によって発生する一連の問題に特化した開発を行うには、多くの経験を積む必要があります。

ソフトウェアサービスコンテンツの更新

アジャイル開発モデルでは、サービスが新しい要件を満たし、バグを修正するためにプログラムを継続的に更新することを示すために、「反復」を使用することが一般的になっています。管理するサーバーが 1 台だけであれば、このサーバー上のプログラムの更新は非常に簡単です。ソフトウェア パッケージをコピーして、構成を変更するだけです。しかし、数百、数千のサーバーで同じ操作を実行したい場合、各サーバーにログインして処理することは不可能です。

サーバー側のバッチインストールおよびデプロイメント ツールは、すべての分散システム開発者に必要です。ただし、インストール作業には、バイナリと構成ファイルのコピー以外にも多くの操作が含まれます。たとえば、ファイアウォールを開く、共有メモリ ファイルを作成する、データベース テーブル構造を変更する、一部のデータ ファイルを書き換えるなどです。サーバーに新しいソフトウェアをインストールする必要がある場合もあります。

サーバー側プログラムの開発時にソフトウェアの更新やバージョン アップグレードを考慮する場合は、構成ファイル、コマンド ライン パラメーター、システム変数の使用について事前に計画を立てておく必要があります。これにより、インストールおよび展開されたツールの実行速度と信頼性が向上します。

インストールと展開のプロセスに加えて、異なるバージョン間のデータの問題という別の重要な問題があります。バージョンをアップグレードすると、古いバージョンのプログラムによって生成された一部の永続データは、通常、古いデータ形式になります。また、アップグレードされたバージョンでデータ テーブルの結果などのデータ形式が変更される場合は、これらの古い形式のデータを変換して、新しいバージョンのデータ形式に書き換える必要があります。つまり、データ構造を設計する際には、これらのテーブルの構造を明確に考慮し、将来の変更を容易にするために最も単純で直接的な表現を使用する必要があります。または、変更の範囲を早めに予測し、一部のフィールドを特別に事前設定したり、他のフォームを使用してデータを保存したりします。

永続的なデータに加えて、クライアント プログラム (ヒット APP など) がある場合、これらのクライアント プログラムのアップグレードはサーバーと同期されないことがよくあります。アップグレード内容に通信プロトコルの変更が含まれている場合、バージョンごとに異なるサーバー側システムを導入する必要が生じます。複数のサーバーを同時に保守することを避けるために、ソフトウェアを開発する際には、いわゆる「バージョン互換」のプロトコル定義方法を好む傾向があります。互換性を保つためにプロトコルをどのように設計するかも、サーバー側プログラムが慎重に検討する必要がある問題です。

統計と意思決定

一般的に、分散システムのログデータはまとめて収集され、均一にカウントされます。ただし、クラスターのサイズが一定のレベルに達すると、これらのログ内のデータ量は恐ろしいほどになります。多くの場合、1 日のログの量をカウントするには、コンピューターを 1 日以上実行する必要があります。そのため、ログ統計の作業も非常に専門的な活動となっています。

古典的な分散統計モデルには、Google の Map Reduce モデルが含まれます。このモデルは、柔軟性と、統計作業に多数のサーバーを活用する機能の両方を提供します。ただし、欠点は、これらのデータの統計が一般的な SQL データ テーブルの統計と大きく異なるため、使いやすさが十分でないことが多く、より詳細な統計を行うためにデータを MySQL に投入することになることが多いことです。

分散システム ログの数が膨大になり、ログの複雑さが増しているため。分散システムでデータ統計を真に実行するには、Map Reduce などのテクノロジーを習得する必要があります。また、統計作業の効率を向上させる方法も見つける必要があります。

ディレクトリサービス（ZooKeeper）は、分散システムの管理性を解決するための基本的な手段です。

分散システムは、多数のプロセスから構成される全体です。この全体の各メンバーには、独自の担当モジュール、独自の負荷状況、特定のデータの制御などのステータスがあります。他のプロセスに関連するこれらのデータは、障害回復や容量の拡張と削減の際に非常に重要になります。

シンプルな分散システムでは、静的構成ファイルを使用して、プロセス間の接続対応、IP アドレスやポートなどのデータを記録できます。ただし、高度な自動化を備えた分散システムでは、これらのステータス データを動的に保存する必要があります。これは、プログラムが独自に災害復旧と負荷分散作業を実行できるようにする唯一の方法です。

一部のプログラマーは、クラスター内のプロセスの実行ステータスを記録するために DIR サービス (ディレクトリ サービス) を作成します。クラスター内のプロセスは自動的にこの DIR サービスに関連付けられるため、災害復旧、容量拡張、負荷分散を実行するときに、これらの DIR サービスのデータに基づいて要求の宛先を自動的に調整し、障害のあるマシンをバイパスしたり、新しいサーバーに接続したりすることができます。

ただし、この作業を実行するために 1 つのプロセスだけを使用する場合は、次に、このプロセスはクラスターの「単一ポイント」になります。つまり、このプロセスが失敗すると、クラスター全体が実行できなくなる可能性があります。そのため、クラスターの状態を保存するディレクトリ サービスも分散する必要があります。幸いなことに、分散ディレクトリ サービスである優れたオープン ソース ソフトウェア ZooKeeper があります。

ZooKeeper は、奇数個のプロセスを開始するだけで、小さなディレクトリ サービス クラスターを形成できます。このクラスターは、他のすべてのプロセスに、その巨大な「構成ツリー」を読み書きする機能を提供します。これらのデータは 1 つの ZooKeeper プロセスに保存されるだけでなく、非常に安全なアルゴリズムに基づいて複数のプロセスによって運ばれます。これにより、ZooKeeper は優れた分散データ ストレージ システムになります。

ZooKeeper のデータ ストレージ構造はファイル ディレクトリに似たツリー状のシステムであるため、各プロセスを「ブランチ」の 1 つにバインドし、これらの「ブランチ」をチェックしてサーバー要求を転送する機能を使用することがよくあります。これにより、要求ルーティング (誰が行うか) の問題を簡単に解決できます。さらに、これらの「ブランチ」にプロセスの負荷ステータスをマークすることもできるため、負荷分散も簡単に実行できます。

ディレクトリ サービスは、分散システムで最も重要なコンポーネントの 1 つです。 ZooKeeper は、このタスクを実行するために設計された優れたオープン ソース ソフトウェアです。

メッセージ キュー サービス (ActiveMQ、ZeroMQ、Jgroups)

2 つのプロセスがマシン間で通信する必要がある場合、ほとんどの場合、TCP/UDP などのプロトコルが使用されます。しかし、ネットワーク API を直接使用してプロセス間通信を記述するのは非常に面倒です。低レベルのソケット コードを大量に記述することに加えて、データを交換するプロセスをどのように見つけるか、データ パケットが失われないように整合性を確保する方法、通信の他のプロセスがハングアップした場合やプロセスを再起動する必要がある場合にどうするかなど、一連の問題にも対処する必要があります。これらの問題には、災害復旧、容量拡張、負荷分散などの一連の要件が含まれます。

分散システムにおけるプロセス間通信の問題を解決するために、「メッセージ キュー」モデルという効果的なモデルがまとめられました。メッセージ キュー モデルは、プロセス間の相互作用を個々のメッセージの処理に抽象化します。これらのメッセージについては、メッセージを一時的に保存するための「キュー」、つまりパイプがいくつかあります。各プロセスは 1 つ以上のキューにアクセスし、そこからメッセージを読み取ったり (消費)、メッセージを書き込んだり (生成) できます。キャッシュされたパイプラインがあるため、プロセスの状態を安全に変更できます。プロセスが開始されると、メッセージが自動的に消費されます。メッセージ自体のルーティングは、保存されているキューによっても決定され、複雑なルーティングの問題を静的キューの管理方法の問題に変えます。

一般的なメッセージキューサービスは、「配信」と「受信機」の2つの簡単なインターフェイスを提供します。ただし、メッセージキュー自体の管理はより複雑です。一般的に言えば、2つのタイプがあります。一部のメッセージキューサービスは、ポイントツーポイントキュー管理を提唱しています。通信ノードの各ペアの間に個別のメッセージキューがあります。このアプローチの利点は、異なるソースからのメッセージが互いに影響を与えないことであり、キュー内のメッセージが多すぎるため、他のキューのメッセージキャッシュスペースは絞り出されないことです。さらに、メッセージを処理するプログラムは、処理の優先順位を単独で定義することもできます。最初に特定のキューを収集および処理し、他のキューをより少なく処理することもできます。

ただし、このポイントツーポイントメッセージキューは、クラスターが増加するにつれて多数のキューを追加します。これは、メモリの使用と操作とメンテナンス管理のための複雑な問題です。したがって、より高度なメッセージキューサービスがさまざまなキューにメモリスペースを共有できるようになり、アドレス情報、作成、およびメッセージキューの削除がすべて自動化されました。 - これらの自動化は、多くの場合、上記の「ディレクトリサービス」に依存して、キューIDに対応する物理IPやポートなどの情報を登録する必要があります。たとえば、多くの開発者はZookeeperを使用して、メッセージキューサービスの中央ノードとして機能します。 JGROPUSのようなソフトウェアは、各ノードの現在および過去の情報を保存するためのクラスター状態を維持しています。

別のメッセージキューは、パブリックメールボックスのようなものです。メッセージキューサービスはプロセスであり、ユーザーはこのプロセスでメッセージを配信または受信できます。これにより、メッセージキューの使用が容易になり、操作およびメンテナンス管理に便利になります。ただし、この使用では、すべてのメッセージは、処理されるまでに送信されるまでに少なくとも2つのプロセス間通信を通過し、遅延は比較的高くなります。また、配信と収集の制約が予定されていないため、バグが発生しやすくなります。

使用されるメッセージキューサービスに関係なく、分散サーバー側システムでは、プロセス間通信が解決する必要がある問題です。したがって、サーバー側のプログラマーとして、分散システムコードを書き込むとき、最も一般的に使用されるコードはメッセージキュー駆動型コードであり、EJB3.0が「メッセージ駆動型の豆」を仕様に直接追加しました。

トランザクションシステム

分散システムでは、トランザクションは解決するのが最も難しい技術的問題の1つです。プロセスはさまざまな処理プロセスに分散される可能性があるため、プロセスは失敗する可能性があり、この障害がロールバックが必要になる場合があります。これらのロールバックのほとんどには、他の複数のプロセスが含まれます。これは、拡散マルチプロセス通信の問題です。分散システムのトランザクションの問題を解決するには、2つのコアツールが必要です。1つは安定した状態ストレージシステムです。もう1つは、便利で信頼できるブロードキャストシステムです。

トランザクションのステップのステータスは、クラスター全体で表示され、災害復旧機能を備えている必要があります。この要件は通常、クラスターの「ディレクトリサービス」によって満たされます。ディレクトリサービスが十分に堅牢である場合、各トランザクションの処理ステータスをディレクトリサービスに同期させることができます。 Zookeeperは再びここで重要な役割を果たします。

トランザクションが中断され、ロールバックする必要がある場合、プロセスには既に実行されている複数のステップが含まれます。おそらく、このロールバックは入り口でロールバックするだけで（ロールバックに必要なデータがそこに保存されていると仮定して）、各処理ノードでロールバックする必要がある場合があります。後者の場合、クラスター内で異常が発生するノードは、「ロールバック！トランザクションIDはxxxx」などのメッセージを他のすべての関連ノードにブロードキャストする必要があります。このブロードキャストの基礎となるレイヤーは通常、メッセージキューサービスによって運ばれ、JGroupsのようなソフトウェアはブロードキャストサービスを直接提供します。

現在、トランザクションシステムについて議論していますが、実際には、分散システムに必要な「分散ロック」機能も同時にこのシステムで完了することもできます。いわゆる「分散ロック」は、各ノードが最初にチェックしてから実行できるようにする制限条件です。単一操作のための効率的なディレクトリサービスがある場合、このロック状態は実際には「シングルステップトランザクション」の状態記録であり、ロールバック操作はデフォルトで「一時停止操作」になります。この「ロック」メソッドはトランザクション処理よりも単純なため、より信頼性が高くなります。したがって、ますます多くの開発者が、「トランザクションシステム」を実装する代わりに、この「ロック」サービスを喜んで使用します。

自動展開ツール（Docker）

分散システムの最大の要件は、実行時にサービス容量を変更することです（サービスを中断する必要があるかもしれません）：拡張または削減。分散システム内の一部のノードが故障した場合、作業を復元するには新しいノードも必要です。これらがまだ昔ながらのサーバー管理方法のようなものである場合、フォームに記入し、宣言の提出、コンピュータールームへの入場、サーバーのインストール、ソフトウェアの展開...、効率は間違いなく機能しません。

分散システムの環境では、一般に「プール」メソッドを使用してサービスを管理します。事前にマシンのバッチを申請し、一部のマシンでサービスソフトウェアを実行し、その他はバックアップとして実行します。明らかに、当社のサーバーのバッチは、1つのビジネスだけにサービスを提供することはできませんが、複数の異なるビジネスキャリアを提供します。これらのバックアップサーバーは、複数のサービスの一般的なバックアップ「プール」になります。ビジネスのニーズが変化するにつれて、一部のサーバーはサービスAと「参加」サービスBを「終了」する場合があります。

この頻繁なサービスの変更は、高度に自動化されたソフトウェア展開ツールに依存しています。当社の運用およびメンテナンス担当者は、そのような運用およびメンテナンス操作を実行するために、厚いマニュアルではなく、開発者が提供する展開ツールを習得する必要があります。より経験豊富な開発チームの中には、ほとんどの展開および構成ツールが一般的なシステムで管理できることを期待して、より経験豊富な開発チームの一部が統一されます。オープンソース業界では同様の試みがあります。最もよく知られているのは、RPMインストールパッケージ形式です。ただし、RPMのパッケージング方法は依然として複雑すぎて、サーバー側のプログラムの展開ニーズを満たしていません。そのため、シェフが代表するプログラム可能な一般的な展開システムが登場しました。

しかし、NOSQLが出現したとき、人々は実際に多くのインターネットビジネスのデータ形式が非常に単純であるため、ルーツが多くの場合リレーショナルデータベースのような複雑なテーブルを必要としないことに突然気づきました。インデックスの要件は、多くの場合、メインインデックスに基づいてのみ検索されます。また、より複雑なフルテキスト検索は、データベース自体では実行できません。したがって、かなりの数の非常に同時のインターネットサービスの場合、NOSQLが保管施設の最初の選択肢です。初期のNOSQLデータベースにはMangoDBなどが含まれており、最も人気のあるデータベースはRedisのようです。一部のチームは、Redisをバッファシステムの一部と見なしています。これは、Redisのパフォーマンスの利点を実際に認識しています。

NoSQLには、より速く、より大きな負荷であることに加えて、このデータストレージメソッドは1つのインデックスに従って取得および記述できるというより重要な機能があります。このような需要の制約は、分布の利点をもたらし、このメインインデックスに従ってデータストレージのプロセス（サーバー）を定義できます。この種のデータベースデータは、さまざまなサーバーに簡単に保存できます。分散システムの避けられない傾向の下で、データストレージレイヤーが最終的に分布方法を見つけました。

多数の分散サーバー側のプロセスを管理するには、展開管理を最適化するために多くの努力を費やす必要があります。統一されたサーバー側のプロセス操作仕様は、自動展開管理を実現するための基本的な条件です。 「オペレーティングシステム」に基づいてDockerテクノロジーを仕様として使用できます。また、「Webアプリケーション」に基づいて特定のPAASプラットフォームテクノロジーを仕様として使用することもできます。または、より具体的な仕様を定義し、自分で完全に分散したコンピューティングプラットフォームを開発することもできます。

ログサービス（log4j）

サーバー側のロギングは常に重要であり、見過ごされがちな問題です。多くのチームが最初に開始されたとき、彼らはログを開発、デバッグ、トラブルシューティングのバグの補助ツールとみなしました。しかし、サービスが動作した後、ログは実行時にプログラムの状況を理解するための唯一の効果的な手段であることがすぐに発見されます。

さまざまなプロファイルツールがありますが、これらのツールのほとんどは、正式に操作されたサービスの開設には適していません。これは、運用パフォーマンスを大幅に減らすためです。したがって、ログに基づいてより頻繁に分析する必要があります。ログは本質的にテキスト情報ラインごとに行われますが、それらは非常に柔軟であり、開発と運用および保守担当者によって非常に評価されています。

ログ自体は概念的には非常に曖昧なものです。ファイルを開いて情報を書くことができます。ただし、最新のサーバーシステムは一般に、ログの標準化された要件を作成します。ログはラインごとに行う必要があります。これは、将来の統計分析により便利です。ログテキストの各行には、日付と時刻が基本的な要件であるなど、いくつかの統一ヘッダーが必要です。たとえば、ログの出力は等級付けする必要があります。

致命的/エラー/警告/情報/デバッグ/トレースなど。プログラムは、実行時に出力レベルを調整して、ログ印刷の消費を節約できるようにすることができます。ログのヘッダーには、一般に、ユーザーIDやIPアドレスなどのヘッダー情報が必要です。これは、ログレコードの特定のバッチを迅速に見つけて見つけてフィルタリングするために使用されるか、染色機能と呼ばれるログ表示範囲をフィルタリングおよび削減するために使用される他のフィールドがあります。また、ログファイルには「ロールバック」機能が必要です。つまり、固定サイズの複数のファイルを保持して、長期操作後にハードディスクが埋められないようにします。

上記のさまざまなニーズにより、オープンソース業界は、多くのメンバーがいる有名なLOG4JやLog4Xファミリーライブラリなど、ゲームに多くのログコンポーネントライブラリを提供しています。これらは、幅広いアプリケーションと好評のアプリケーションを備えたツールです。

ただし、ログ印刷関数と比較して、ログ収集と統計機能は、見過ごされがちです。分散システムのプログラマーとして、彼は間違いなく、集中ノードからクラスターログの状況全体に統計を収集することを望んでいます。クラスター全体の健康を監視するために、非常に短時間で繰り返し得られることを望んでいるログ統計がいくつかあります。これを行うには、ログの継続的な到着を保存するための分散ファイルシステムが必要です（これらのログは、しばしばUDPプロトコルを介して送信されます）。このファイルシステムには、マップを減少させるアーキテクチャに似た統計システムがあり、大量のログ情報を迅速にカウントしてアラームします。一部の開発者はHadoopシステムを直接使用し、他の開発者はLog StorageシステムとしてKafkaを使用してから独自の統計プログラムを構築します。

ログサービスは、分散型の操作とメンテナンスのための機器パネルとペリスコープです。信頼できるロギングサービスがなければ、システム全体の健康が制御不能になる可能性があります。したがって、分散システムのノードがいくつあるか、少数であっても、ログの統計分析を自動化するシステムを確立するために、重要なエネルギーと特別な開発時間を費やす必要があります。

開発効率における分散システムによって引き起こされる問題とソリューション上記によれば、ビジネス要件における分散システムの機能は、多くの追加の非機能的ニーズを必要とすると考えられています。これらの非機能要件は、多くの場合、マルチプロセスシステムの安定した信頼性の高い動作のために設計および実装されています。これらの「余分な」作業は一般にコードをより複雑にし、良いツールがない場合、開発効率が大幅に低下します。

マイクロサービスフレームワーク：EJB、WebService

サーバー側のソフトウェアの配布について議論するとき、サービスプロセス間の通信は避けられません。ただし、メッセージを送信および受信するだけでは、サービスプロセス間の通信を実現することはできません。これには、メッセージのルーティング、エンコード、デコード、サービスステータスの読み取り、および書き込みなども含まれます。プロセス全体が自分で開発された場合、疲れすぎます。

したがって、業界は非常に早く、さまざまな分散サーバー側の開発フレームワークを開始しました。その中で最も有名なのは「EJB」 - エンタープライズJavabeanです。多くの場合、「エンタープライズ」と呼ばれるテクノロジーは、分布の下で必要な部分であり、EJBテクノロジーは分散オブジェクト呼び出しのテクノロジーでもあります。複数のプロセスを協力してタスクを完了させる必要がある場合、タスクを複数の「クラス」に分割する必要があり、これらの「クラス」のオブジェクトは各プロセスコンテナで生き残り、それによってサービスの提供について協力します。このプロセスは非常に「オブジェクト指向」です。各オブジェクトは、特定の分散関数を提供できる「マイクロサービス」です。

他のシステムは、インターネットの基本モデル、HTTPの学習に向かっています。したがって、オープンソースから商用ソフトウェアまで、さまざまなWebサービスフレームワークがあり、それぞれに独自のWebサービスの実装があります。このモデルは、複雑なルーティング、エンコード操作を一般的なHTTP操作に簡素化します。これは非常に効果的な抽象化です。開発者は、複数のウェブサービスをWebサーバーに開発および展開し、分散システムの構築を完了します。

EJBであろうとWebサービスであろうと、実際に分散コールの複雑さを簡素化する必要があります。分散コールの複雑さは、災害復旧、容量拡張、クロスプロセスコールへの負荷分散などの機能を統合する必要があることです。したがって、コードの共通セットを使用して、災害復旧、容量拡大、負荷分散、過負荷保護、状態キャッシュヒットなどの非機能的要件をすべてのクロスプロセス通信（コール）に達成します。これにより、分散システム全体の複雑さを大幅に簡素化できます。

一般に、当社のマイクロサービスフレームワークでは、ルーティング段階でクラスター全体のすべてのノードのステータスを観察します。これには、どのアドレスがどのサービスプロセスを実行しているか、これらのサービスプロセスの負荷ステータス、それが利用可能かどうかなどです。次に、ステートフルサービスの場合、一貫性のハッシュと同様のアルゴリズムを使用して、キャッシュヒット率を可能な限り改善しようとします。クラスター内のノードの状態が変更されると、マイクロサービスフレームワークの下のすべてのノードは、できるだけ早くこの変更を取得し、現在の状態に基づいて将来のサービスルーティングの方向を再計画し、それにより、自動化されたルーティングと過剰な負荷または障害でノードを回避することができます。

IDLを「スケルトン」および「ステーク」コードに変換するのと同様のツールを提供するマイクロサービスフレームワークがいくつかあります。このようにして、リモートコールプログラムを作成するとき、複雑なネットワーク関連コードをまったく記述する必要はありません。すべての輸送層とエンコード層コードが自動的に記述されます。この点で、EJB、FacebookのThrift、およびGoogle GRPCにはこの能力があります。コード生成機能のフレームワークを使用すると、ローカル関数を書くのと同じように、分散形式で利用可能な機能モジュール（機能またはクラス）を書きます。これは間違いなく分散システムの下で非常に重要な効率改善です。

非同期プログラミングツール：Coroutines、Futrue、Lamda

分散システムでプログラミングすると、必然的に多数の「コールバック」APIに遭遇します。分散システムには多くのネットワーク通信が含まれるためです。任意のビジネスコマンドは、複数のプロセスに分解され、複数のネットワーク通信を介して組み合わせることができます。非同期の非ブロッキングプログラミングモデルは人気があるため、私たちのコードはしばしば「コールバック関数」にいつでも遭遇します。ただし、コールバックの非同期プログラミングモデルは、コードの読み取りに非常に不利なプログラミング方法です。ビジネスタスクが徐々に完了する方法を理解するために、最初から最後までコードを読むことができないためです。ビジネスタスクに属するコードは、複数の非ブロッキングコールバックのために多くのコールバック関数に分割され、コードのさまざまな部分で接続されています。

さらに、「オブザーバーモード」を使用することを選択し、多数の「イベント応答関数」を1か所に登録し、コールバックが必要なイベントを発行することがあります。 - この種類のコードは、単にコールバック関数を登録するよりも理解するのが難しいです。イベントに対応する応答関数は通常、問題の時点​​では見られないためです。これらの機能は常に他のファイルに配置され、時にはこれらの関数が実行時に変更される場合があります。あなたのプログラムに何百ものイベントが必要な場合、理解しやすい名前を与えることはほとんど不可能であるため、イベント名自体は信じられないほど困難です。

コードの読みやすさに対するコールバック関数の破壊効果を解決するために、多くの異なる改善方法が発明されています。これらの中で最も有名なのは「コルーチン」です。以前はマルチスレッドを使用して問題を解決していたため、同期的な方法でコードを書くことに精通しています。 Coroutinesはこの習慣を継続しますが、マルチスレッドとは異なり、Coroutinesは「同時に」実行されません。彼らは、evel（）を使用して、ブロックする必要がある他のコルーチンを実行するためにスイッチアウトします。その後、ブロッキングが終了したら、Resume（）を使用して、実行したばかりの位置に戻り、実行を続行します。これは、Callback関数のコンテンツがevel（）コールに接続されていることに相当します。コードを書き込むこの方法は、同期の書き込みに非常に似ているため、コードを読みやすくします。しかし、唯一の欠点は、いわゆる「メインスレッド」でresume（）のコードを実行する必要があることです。ユーザーがブロッキングから回復する必要がある場合、resume（）を呼び出します。コルーチンのもう1つの欠点は、スタックを保存する必要があることです。他のコルーチンに切り替えた後、スタック上の一時変数も余分なスペースを占有する必要があります。これにより、Coroutineコードの書き込み方法が制限され、開発者があまりにも大きな一時変数を使用しないようにします。

コールバック関数の書き込みを改善する別の方法は、しばしばFuture/Promiseモデルと呼ばれます。この執筆方法の基本的なアイデアは、「一度にすべてのコールバックを一緒に書く」ことです。これは非常に実用的なプログラミングモデルです。コールバックを完全に排除することはできませんが、あちこちからコールバックを分散させて1か所に集中させることができます。同じコードでは、各非同期ステップが直列または並行してどのように実行されるかをはっきりと確認できます。

最後に、JS言語の幅広いアプリケーションで人気のあるLamdaモデルについて話しましょう。他の言語では、コールバック関数を設定することは非常に厄介です。Java言語はインターフェイスを設計してから実装する必要があります。これは、5つ星の問題です。 C/C ++は機能ポインターをサポートしていますが、これは比較的簡単ですが、コードを理解できないようにすることも簡単です。スクリプト言語は比較的優れており、機能を定義する必要があります。開発するのが最も便利で、コールバックを呼び出すときに読む方が便利です。さらに重要なことに、ラムダは一般に閉鎖を意味します。つまり、このコールバック関数のコールスタックは個別に保存されます。それらの多くは、非同期操作で「セッションプール」と同様の状態保存変数を確立する必要があります。ここでは必要ありませんが、自然に実施することができます。これはコルーチンに似ています。

どの非同期プログラミング方法が使用されていても、エンコードの複雑さは、同期と呼ばれるコードの複雑さよりも間違いなく高くなっています。したがって、分散サーバーコードを記述するときは、機能コードを自由に追加しないようにコード構造を慎重に計画し、コードの読みやすさを破壊する必要があります。読み取れないコードは維持不可能なコードであり、多数の非同期コールバックを備えたサーバー側のコードが発生する可能性が高くなります。

クラウドサービスモデル：IAAS/PAAS/SAAS

複雑な分散システム開発と使用のプロセスでは、多数のサーバーとプロセスを操作および維持する方法は、常に問題となっています。マイクロサービスフレームワーク、統一展開ツール、ログ監視サービスを使用している場合でも、多数のサーバーが中央に管理されているため、非常に困難です。この背後にある理由は、主に大量のハードウェアとネットワークが論理コンピューティングの力を多くの小さな部分に削減するためです。

コンピューターコンピューティング機能の改善により、仮想化テクノロジーの出現は、分割されたコンピューティングユニットをよりインテリジェントに統合することができます。最も一般的なものはIAASテクノロジーです。1つのサーバーハードウェアを使用して複数の仮想サーバーオペレーティングシステムを実行できる場合、維持する必要があるハードウェアの量は指数関数的に減少します。 PAASテクノロジーの人気により、特定のプログラミングモデルのシステム操作環境を均一に展開および維持することができます。オペレーティングシステムをインストールしたり、実行中のコンテナを構成したり、実行中のコードとデータを次々とアップロードする必要はありません。統一されたPAASがある前に、多数のMySQLデータベースをインストールすることは、かつて時間がかかり、労働集約的な作業でした。

私たちのビジネスモデルがいくつかの固定ソフトウェアに抽象化するのに十分な成熟している場合、分散システムは使いやすくなります。私たちのコンピューティングパワーは、もはやコードやライブラリではなく、ネットワークを通じてサービスを提供するクラウドサーズです。このようにして、ユーザーはタスクを維持および展開する必要はありません。インターフェイスを適用して、予想される容量クォータを入力して、直接使用できます。これにより、対応する機能の開発において多くのイベントを節約するだけでなく、SAASメンテナーに多くの運用とメンテナンス作業を引き渡すことも意味します。

操作モデルとメンテナンスモデルの進化では、IAASからPAAS、SaaSまでのアプリケーションの範囲は狭くなり、狭くなっている可能性がありますが、使用の利便性は大幅に改善されています。これはまた、ソフトウェア労働の仕事が、分業を通じてより専門的で細分の方向の効率を改善できることを証明しています。

分散システムの問題へのソリューションパスを要約します

サーバーの収容能力の問題に対応して、Tencent Wetestは、10年以上の内部実践的な経験を使用して、実際のビジネスシナリオとユーザー行動に基づいて経験とストレステストを要約して、ゲーム開発者がサーバー側でパフォーマンスボトルネックを発見し、サーバーの調達とメンテナンスコストを削減し、ユーザーの定着と変換率を改善します。