1. マルチクラウドキャッシュの背景1. マルチクラウドアーキテクチャZhihu は現在、主に次の 3 つの考慮事項に基づいて、マルチクラウド アーキテクチャを採用しています。
Zhihu には現在 5 ~ 6 のデータセンターと 2 つのコア コンピューター ルームがあります。 1 つはオンライン コンピューター ルームで、コメント、回答、推奨事項などのサービスを Zhihu メイン サイトのユーザーに直接展開します。もう 1 つはオフライン コンピュータ ルームです。ここでは主に、共通データ プラットフォーム、オフライン ストレージ、OLAP エンジンなどのオフライン コンピューティング関連サービスを展開します。 2 つのコンピューター ルームは専用回線を介して通信するため、専用回線は非常に重要です。 コンピュータ室の専用回線が安定しているかどうかを測る重要な指標の一つは、コンピュータ室のトラフィックです。一般的に、サービス間の通話はデータセンターのトラフィックをほとんど使用しないため、データセンター内の専用回線トラフィックには影響しません。ただし、私たちのアルゴリズムのシナリオでは、コンピューター ルームの専用回線全体を直接占有するという非常に特殊な状況があります。これは次に紹介する推奨/検索モデルのオンラインシナリオです。 2. 推奨/検索モデルのオンラインシナリオ私たちのモデルの出力は、大規模な分散コンピューティングのためのオフライン コンピュータ ルームの機械学習プラットフォームと Spark クラスターに依存しており、モデルは最終的にオフライン HDFS に書き込まれます。モデルがオンラインになると、推論サービス コンテナーには数百または数千のコンテナーが含まれる場合があります。同時に HDFS からモデルをプルすると、専用回線間のトラフィックが大量に発生し、次の 2 つの問題が発生します。
3. 複数の HDFS クラスタ ソリューション当初、このモデルを立ち上げる際の問題に対する私たちの解決策は非常にシンプルで、マルチ HDFS クラスター ソリューションでした。これまでのオフライン HDFS から直接プルするのと比較して、モデルが生成された時点でオフライン コピー タスクを使用してモデルをオンライン HDFS にコピーし、プル時にオンライン HDFS から直接モデルを読み取ります。これには 2 つの利点があります。
ただし、このアプローチにはいくつかの欠点もあります。
2. 自社開発部品段階次に、3 番目の反復バージョンである、独自に開発したコンポーネント UnionStore を紹介します。 1. 自社開発コンポーネント - UnionStore当社が独自に開発したマルチクラウド キャッシュ コンポーネントは、UnionStore と呼ばれます。名前が示すように、これは HDFS とオブジェクト ストレージを組み合わせてオブジェクト ストレージへのアクセス インターフェイスを提供する共同ストレージを意味します。ワークフローは次のとおりです。モデルは機械学習プラットフォームと Spark を介して出力され、最終的に HDFS に書き込まれます。読み取り時には、オブジェクト ストレージ プロトコルを通じて UnionStore にリクエストが送信されます。ファイルの読み取り要求を受信すると、UnionStore はオブジェクト ストレージにファイルが存在するかどうかを確認します。そうであれば、ファイルを直接ユーザーに返します。そうでない場合は、オフライン HDFS からファイルを読み取り、オブジェクト ストレージにアップロードし、最終的にオブジェクト ストレージからユーザーに返します。 2. UnionStoreの利点UnionStore の利点は次のとおりです。
これはUnionStoreの最初の使用シナリオです。 UnionStore はオブジェクト ストレージ アクセス メソッドを提供します。また、1 つのことも可能です。ユーザーは s3fs-fuse を使用して UnionStore を POSIX ローカル ディレクトリにマウントし、ローカル ディレクトリから直接トレーニング データを読み取ることができるため、機械学習プラットフォームのサポートが向上します。 このソリューションは、発売されるとすぐにユーザーから好評を博しました。当時、HDFS をマウントする方法は 2 つありました。 1 つ目は Hadoop コミュニティが提供する HDFS マウント ローカル ディレクトリ方式で、もう 1 つは Go 言語で記述された HDFS マウント方式です。しかし、どちらの解決策も再試行しても十分ではありません。 s3fs-fuse の再試行の方が優れているため、s3fs-fuse を選択しました。 3. UnionStoreのデメリットUnionStoreは2年間、芝湖で営業しています。初期段階では問題はありませんでした。しかし、モデルの規模が拡大し続けるにつれて、次のような問題が徐々に発生しました。
上記の欠点により、2 つの選択肢が残ります。最初の選択肢は、UnionStore を継続的に反復して、社内のニーズを満たすようにすることです。 2 番目のオプションは、UnionStore の使用シナリオを置き換える適切なオープン ソース ソリューションを見つけることです。人的資源の貴重さを考慮して、私たちは 2 番目の選択肢を選択し、適切なオープン ソース ソリューションを探しました。 オープンソース ソリューションでは、2 つの使用シナリオを解決する必要があります。 1 つ目は、モデル読み取り高速化シナリオであり、オブジェクト ストレージ プロトコルの提供が必要です。 2 つ目は、モデル トレーニングの高速化シナリオであり、ローカル ディレクトリにアクセスする方法を提供する必要があります。 アルクシオフェーズ私たちは多くのオープンソース ソリューションを調査し、多くの内部キャッシュ コンポーネントも検討しましたが、Alluxio だけが私たちのニーズを満たすことができることがわかりました。 Alluxio には次の利点があります。
これら 3 つのポイントは私たちのニーズを満たすのに十分ですが、さらに次の 3 つの機能も提供します。
調査を通じて機能がニーズを満たしていることを確認した後、それを使用してモデルを立ち上げました。 1. モデル読み取り加速シナリオ最初のシナリオは、モデル読み取り加速シナリオです。次に、クライアントの選択、パフォーマンス テスト、展開とチューニング、オンライン効果の 4 つの側面を紹介します。 (1)クライアントの選択 - S3プロキシ次の理由から、モデルの読み取りシナリオを高速化するために Alluxio S3 Proxy を選択しました。
(2)Alluxio S3 ProxyパフォーマンステストAlluxio S3 Proxy で、HDFS、UnionStore、Alluxio を比較する一連のパフォーマンス テストを実施しました。ファイルのホット リード時に、Alluxio のパフォーマンスが他の 2 つのコンポーネントのパフォーマンスをはるかに上回っていることがわかりました。 100GB のファイルをホット リードするのに必要な時間は、UnionStore の 1/7 に過ぎませんでした。この加速効果は非常に明白です。 (3)展開方法以下の理由により、K8S デプロイメントではなくベアメタル デプロイメントを選択しました。
ここでの展開方法は S3 プロキシであり、最終的にドメイン名はユーザー アクセス用の DNS プロキシを通じて提供されます。 (4)展開とチューニングモデル読み取りシナリオの最適化は、モデル読み取りシナリオの特性と組み合わせて実行する必要があります。モデル読み取りシナリオには、次の 3 つの特徴があります。
私たちは、次の 3 つの特性に基づいてターゲットを絞った最適化を実行しました。
次に、それぞれのチューニング戦略について詳しく説明します。
左の図は短絡読み取りがない場合の状況を示しています。ユーザーが S3 プロキシにファイルの読み取りを要求すると、2 層のネットワークを通過します。ネットワークの最初の層はユーザーから S3 プロキシまでであり、ネットワークの 2 番目の層は S3 プロキシからワーカーまでです。最後に、Worker はディスク上のファイルを読み取ります。この場合、ネットワーク カードの消費量は非常に大きくなります。 右の図はショート回路の読み取り状況を示しています。ユーザーが S3 プロキシを要求すると、S3 プロキシはワーカーを経由せずにディスク上のデータを直接読み取ります。これは、S3 プロキシとワーカー間のトラフィックを節約することと同じです。当社のオンラインテストによれば、トラフィックを約 30% ~ 50% 節約できます。
簡単に言えば、リアルタイムのファイル事前加熱戦略は、分散負荷機能を S3 プロキシに統合することです。 S3 プロキシはダウンロード要求を受け入れると、ファイルをブロックに分割し、各ファイル ブロックを異なるワーカーに送信して同時キャッシュを行います。これを行う利点は、ファイルをダウンロードするときに、先頭部分がキャッシュされずダウンロードが非常に遅くなる可能性があるが、後続のファイルを読み取るときに、他のワーカーがすでにファイルをキャッシュしている可能性があるため、速度はキャッシュをヒットするのとほぼ同じになる可能性があることです。ファイルが大きくなるほど、この高速化戦略の効果は顕著になります。 10GB のファイルなど、大きなファイルを読み取る場合、読み取り速度はコールド リードよりも 2 ~ 5 倍速くなります。 100GBであれば基本的にはホットリードと同じです。 2 番目の利点は、後の順序のファイル ブロックが事前にキャッシュされているため、UFS トラフィックを節約できることです。オンラインデータ検証によると、UFSトラフィックを2〜3倍節約できます。 リアルタイム予熱戦略の効果を見てみましょう。次の図は、そのラインの実際のスクリーンショットです。その中の各線分は、モデルの読み取り要求を表します。線分が長くなるほど、モデルの読み取りにかかる時間が長くなり、読み取り速度が遅くなります。 フェーズ 1 では UnionStore を使用した読み取り効果を示し、フェーズ 2 では S3 Proxy を直接使用した読み取り効果を示します。全体的な読み取り時間が約半分に短縮されたことがわかりますが、いくつかのスパイクがあり、一部のリクエストの読み取りが非常に遅い可能性があることを示しています。これは、Alluxio のパフォーマンスがファイルのコールド リード時に大幅に低下するためです。 フェーズ 3 では、リアルタイム予熱戦略が開始された後の読み取り効果を示します。基本的にすべてのスパイクが消え、全体的なファイルの読み取り速度も向上していることがわかります。予熱効果はとても良いです。
3 番目の最適化戦略は、特定のメタデータ キャッシュを実行することです。これは 3 つの段階に分かれています。上の写真も、実際にオンライン上のスクリーンショットです。フェーズ 1 では、UnionStore を使用してデータを読み取りますが、これは非常に低速です。フェーズ 2 では、S3 プロキシを使用してデータを読み取るため、時間が短縮され、速度がほぼ 2 倍になります。フェーズ 3 では、メタデータ キャッシュを 1 分間使用するため、初期の UnionStore と比較して速度が数十倍向上します。 メタデータ キャッシュを有効にした後は、ファイルの不整合が発生する可能性があるため、メタデータの同期に特別な注意を払う必要があります。そのため、ファイルの使用仕様もいくつか策定しました。たとえば、新しいファイルを追加するときは、できるだけ新しいディレクトリに書き込み、バージョン番号の形式で管理し、古いファイルを追加したり上書きしたりしないようにユーザーに依頼します。業務履歴から残っているタスクの古いファイルを変更する必要がある場合には、特別な方法も提供しています。 S3 プロキシのコードの一部を変更し、ユーザーがメタデータを更新するための特別なコマンドを追加しました。
S3 プロキシの速度制限の目的は、ワーカーとビジネス コンテナを保護し、ネットワーク カードが完全に使用されるのを防ぐことです。 S3 Proxy は最大速度が 1.6 GB と非常に高速であるため、ネットワーク カードを大量に消費します。そのため、Worker とビジネス コンテナのネットワーク カードを保護する必要があります。ここでは2つの速度制限を設定しました。 1 つ目は、S3 プロキシ プロセスにグローバルな速度制限を設定し、ワーカー ネットワーク カードを保護できるようにすることです。 2 つ目は、ビジネス コンテナが配置されている K8S ノードを保護し、このノードのネットワーク カード全体が十分に使用されないようにするために、単一の接続の速度を制限することです。この機能はコミュニティに貢献され、バージョン 2.9.0 以降がリリースされました。 下の図は、モデル読み取りの高速化による全体的な効果を示しています。速度が数十倍ほど向上していることがわかります。もちろん、ここでの数十回は、Alluxio クラスターが非常にアイドル状態であるためです。実際のオンライン結果は、UnionStore と Alluxio の速度は同じですが、Alluxio は UnionStore のリソースの半分しか使用しないため、コストを 50% 節約することになります。 2. モデルトレーニングの加速シナリオ2 番目のシナリオはモデル トレーニングの高速化シナリオであり、これもクライアントの選択、パフォーマンス テスト、展開とチューニング、オンライン効果という 4 つの側面から紹介されています。 (1)クライアントの選択 - Alluxio fuseクライアントが Alluxio Fuse を選択した理由は次の通りです。
(2)アルクシオヒューズ性能試験クライアントを選択した後、パフォーマンステストを実行します。テストでは公式のデフォルト構成を使用します。公式のデフォルト設定との違いは 2 つあります。 1 つは、特定のカーネル メタデータ キャッシュが有効になっていること、もう 1 つは、カーネル メタデータ キャッシュを使用するため、コンテナーの合計メモリが非常に大きいことです。 テストベンチマークとしてローカルディスクを使用し、テスト結果は次のとおりです。ローカル ディスクのシーケンシャル読み取り速度は 1800 MB/S、ランダム読み取り速度は 1000 MB/S です。 fuse が 1G の実際のファイルを連続的に読み取ると、速度は 1700 MB/S に達し、これは基本的にローカル ディスクのパフォーマンスの 90% に達します。これは非常に高いパフォーマンスです。 fuse が 100 GB のファイルを連続して読み取ると、パフォーマンスが急激に低下します。これは、以前のコンテナのメモリが 40 GB であり、100 GB のファイルをキャッシュするのに十分なページ キャッシュがないためです。ただし、1GB および 10GB のファイルの場合はキャッシュ ヒットが十分にあるため、パフォーマンスは半分に低下します。 fuse のランダム読み取りパフォーマンスは 450 MB/S と比較的低いですが、モデル トレーニングのニーズを満たすことができ、全体的には期待どおりです。 (3)展開とチューニングモデルトレーニングシナリオのチューニングは、その特性と組み合わせて実行する必要があります。モデルトレーニングシナリオには、次の 3 つの特徴もあります。
fuse プロセスをデプロイするには DeamonSet を使用します。ホスト パスを使用して、キャッシュ データ ディレクトリをレイヤーごとにマウントし、モデル トレーニング コンテナーに提供して使用します。
次に、fuse と組み合わせて Alluxio クラスター全体をデプロイする方法を見てみましょう。私たちは小規模なクラスターと大量のクライアントのアプローチを採用しています。名前が示すように、Alluxio クラスターは実際には非常に小さいです。 Raft プロトコルをサポートするマスター ノードは 3 つとワーカー ノードは 3 つしかありませんが、数 PB の NVME ストレージを含む、数百台の GPU マシン (ここでは約 100 ~ 300 台の GPU マシン) をサポートしています。 GPU マシンには数百の fuse プロセスが展開されています。各ヒューズ プロセスには、ローカル キャッシュ用に 10 TB の NVME があります。つまり、Alluxio クラスターは実際にはデータ分散という 1 つのことだけを実行します。パフォーマンス保証などのその他のことは、ヒューズプロセスに完全に引き継がれ、ローカルで完了します。 最後に、Alluxio を調整しましょう。チューニング項目は非常にシンプルです。いくつかの変更を加えただけで、残りは公式の設定です。
(3)モデルトレーニングの加速効果実際の加速効果から判断すると、モデルトレーニングの全体的な速度が 60% 向上しました。当初はトレーニングに 10 日間必要だったモデルが、わずか 6 日間で完了できるようになりました。さらに、モデルをトレーニングする際のデータの読み取り速度も2.5倍に向上しました。 3. 補足シーン私たちの内部には、さらに興味深いシナリオもあります。それは、ビッグデータの運用と保守のシナリオであり、これも私たちの補足シナリオです。 (1)ビッグデータコンポーネントのリリースと起動(最適化前)まず、ビッグデータ コンポーネントのリリースと起動のプロセスを紹介します。たとえば、ビッグデータ コンポーネントを起動する場合、ユーザー開発者はまず自分のタスクを GitLab に送信します。マージコードリクエストを受信すると、GitLab は CI Web Hook を呼び出してユーザーを自動的にビルドおよびパッケージ化し、バイナリパッケージを Kosmos にアップロードします。ここでの Kosmos は、当社の内部パッケージ管理サービスです。バイナリ パッケージを受け取った後、Kosmos はそれをオブジェクト ストレージに転送します。これが公開プロセスです。 オンラインプロセスを見てみましょう。開発者はビッグデータ運用保守プラットフォームをクリックして新しいバージョンを起動し、ビッグデータ運用保守プラットフォームはデプロイメントロジックを本番環境サーバーに配布します。実稼働環境サーバーはデプロイメント ロジックを実行します。途中でパッケージをダウンロードする必要がある場合は、Kosmos にダウンロードを要求します。ダウンロード要求を受信すると、Kosmos は要求をオブジェクト ストレージにリダイレクトします。このとき、本番環境サーバーはオブジェクト ストレージからバイナリ パッケージを直接取得します。プロセス全体が完璧です。唯一の欠陥は、オブジェクト ストレージがバイナリ パッケージをダウンロードするときに、次の 2 つの問題が発生することです。
(2)ビッグデータコンポーネントのリリースと立ち上げ(最適化後)このプロセスを最適化するために Alluxio を使用しましたが、プロセスは非常に簡単でした。 Alluxio は HDFS のマウントだけでなく、オブジェクト ストレージのマウントもサポートしているため、Kosmos で使用されるオブジェクト ストレージを Alluxio に直接マウントします。パッケージをダウンロードする場合、本番環境サーバーは S3 プロキシからバイナリ パッケージを直接要求します。 Alluxio からダウンロードされるため、下図に示すように、速度が非常に速くなります。最終打ち上げ後の効果を比較したグラフです。 図中の赤い円はオブジェクトストレージからのダウンロード速度を示しており、約 10 MB/S です。 Alluxio からのダウンロード速度は約 600 MB/S です。ここでの 600 MB/S は抑制中の状況です。前述の最適化ソリューション、つまり S3 プロキシが速度を制限することを考慮すると、速度は 600 MB/S に制限されますが、実際には最大 1600 MB/S に達する可能性があります。 IV.結論最後に技術的な概要を示します。当社のマルチクラウド キャッシュの開発履歴を振り返ると、当初の総当たりによる読み取りから、その後の複数の HDFS クラスター、そして自社開発のコンポーネント UnionStore まで、どれも当社のニーズを満たすことができませんでした。最終的に、私たちはニーズを満たすために Alluxio を立ち上げました。 Alluxio はどのような改善をもたらしましたか?まず、パフォーマンスの面では、全体的に 2 ~ 5 倍のパフォーマンス向上が見られます。安定性の面では、HDFS への強い依存が排除されます。最後に、コストの面では、コストが約半分に削減されました。 将来的には、データ オーケストレーションや OLAP アクセラレーションのシナリオで Alluxio を使用する予定です。当社の人工知能シナリオの一部では小さなファイルの使用が必要なため、新世代アーキテクチャである Dora アーキテクチャに期待しています。 5. 議論と交流1. Hive は Alluxio を使用して、ユーザーが作成した過去の Hive テーブルへの変更を最小限に抑えるにはどうすればよいでしょうか?A: これは、Hive テーブルの場所を HDFS の先頭から Alluxio の先頭に変更したくないためだと思います。 OLAP エンジンはまだ高速化されていませんが、現在は代替ソリューションがあります。 Hive の MetaStore にいくつかの変更を加える可能性があります。コンピューティング エンジンが HDFS 上のパーティションを読み取るときに、それが Alluxio にキャッシュされている場合は、Hive MetaStore で直接変更し、HDFS プレフィックスを Alluxio プレフィックスに直接変更します。この方法では、Hive の場所を変更する必要はありません。 2. 先ほど述べたページ サイズが 1MB から 16MB に調整されました。これはどのように調整されましたか?なぜ32MBではないのですか?回答: ビジネスでデータを読み取る場合、大きなファイルだけでなく小さなファイルも含まれます。この値が大きすぎると、小さなファイルが適切にサポートされなくなります。小さすぎると、大きなファイルをうまくサポートできません。そこで、実験経験に基づいて、比較的妥協した値を選択しました。 3. Alluxio のパフォーマンスはコールド リード中に大幅に低下しますが、この問題は予熱によって解決されます。どうやって予熱するんですか?A: たとえば、S3 プロキシから 512 MB のファイルを要求するユーザーがいるとします。次に、S3 プロキシはマスターからファイルのメタデータを取得し、各ブロックのサイズが 128 MB の 4 つのブロックがあることを示します。これら 4 つのブロックについては、ハッシュなどの特別なアルゴリズムを使用し、それらを異なるワーカーに送信してキャッシュします。読み取り時に、S3 プロキシは最初にダウンロードする場合があります。たとえば、ブロック 1 をダウンロードしますが、ブロック 1 はまだキャッシュされていない可能性があるため、UFS から直接読み取られてからユーザーに返されます。これにより、速度が遅くなる可能性があります。ブロック 2 を読み取るときに、キャッシュされている可能性があり、その場合、読み取りは非常に高速になります。その後、ブロック 3 と 4 を読み取るときに、それらがキャッシュされ、非常に速く読み取られる可能性があります。これが私たちのやり方です。ここでは、ファイルのブロック数が 1 より大きい必要があります。それ以外の場合は、ファイル自体が比較的小さいため、パフォーマンスが低くてもすぐに読み取ることができるため、高速化する必要はありません。 4. 先ほど、メタデータのキャッシュに Alluxio を使用することを説明しました。メタデータには具体的に何が含まれていますか?回答: Alluxio のメタデータ キャッシュは 3 つの部分に分かれています。最初の部分は、マスターにキャッシュされるオブジェクト ストレージ メタデータなどの UFS メタデータです。 2 番目の部分は fuse で、これはクライアントのローカル メタデータ キャッシュです。これはかなりよくあることです。 Fuse はメモリを使用してマスターのメタデータを 1 回キャッシュします。 3 番目の部分はカーネル メタデータであり、これも fuse で共通です。これは、オペレーティング システムのローカル ディレクトリの状態をキャッシュするオペレーティング システム レベルのキャッシュです。 メタデータのキャッシュはパフォーマンスに大きな影響を与えます。メタデータのキャッシュが有効になっていない場合、たとえば、UFSメタデータをキャッシュしない場合、クライアントからのすべての要求がUFSに侵入し、パフォーマンスは非常に低くなります。特に、オブジェクトストレージを使用する場合、たとえば、ディレクトリをリストしたい場合、オブジェクトストレージリスティングディレクトリのパフォーマンスは非常に貧弱で、時には数秒かかる場合があります。 ここで1分のキャッシュタイムアウトを設定します。 1分間のメタデータキャッシュは実際には妥協点です。これは、ユーザーがファイルの変更をできるだけ早く感じると同時に、ある程度のキャッシュを実行できるようにするためです。メタデータの一貫性要件がそれほど厳格でない場合、実際に1時間、数時間、または数日に調整するか、手動で更新できます。これは、シーンに従ってのみ調整できます。 5。オブジェクトストレージは、モデルの起動とモデルトレーニングシナリオの両方で使用されます。クラウドまたはローカルオブジェクトストレージ上のオブジェクトストレージですか?すべての接続インターフェイスは、標準のS3プロトコルを使用して接続されていますか?回答:クラウドベンダーからオブジェクトストレージサービスを直接購入します。独自のオブジェクトストレージをセットアップするのは高すぎるためです。 ここには2つのS3プロトコルが関係しています。一方では、UnionStore自体がS3プロトコルを外の世界に提供しています。このコンポーネントは私たちによって開発されています。一方、UnionStoreはS3プロトコルを使用して、クラウドベンダーから購入するオブジェクトストレージと対話します。 6.モデルトレーニングシナリオでは、GPUクラスターは最初は数百のノードで構成されていますが、Alluxioは3人のマスターと3人の労働者の小さなクラスター展開を使用しています。この小さなクラスターアーキテクチャは、ホットデータを引き出す容量と同時アクセス要件全体を満たすことができますか?A:これは、Alluxioが現在持っている問題に関連して解決する必要があります。現在、クラスターからデータを読むと、ヒューズは非常に遅いです。これはAlluxioの欠陥です。約200MB/sの最高速度にしか到達できないため、ワーカーのネットワークカードから十分なデータを読み取ることができません。これについては、Alluxioコミュニティと何度も話し合いました。 Alluxioの次のバージョンはこの問題を解決し、楽しみにしています。また、当時のバージョンのアップグレードとアーキテクチャのアップグレードを行うこともできます。たとえば、労働者の拡大やビジネス部門と直接統合するなどです。 |
<<: 光ファイバー相互接続: クラウド コンピューティング ネットワークを改善する方法
2020年9月9日、「信頼できるクラウド、未来を創る」をテーマにした中国電子クラウド戦略会議が武漢で...
GA を使用して Web サイトを分析することは、金鉱を掘るようなものです。 GA の操作に慣れてい...
百度の最近の大幅な調整以前は、多くのタオバオユーザーは非常に良い収入を得ており、中には月に1万元以上...
インターネットの発展は、当初の一方的な情報伝達から、徐々に情報共有と情報生産へと移行し、誰もが情報生...
ブラウジングしていると、ultravps が特別価格の VPS 4 つ、クラウド サーバー 2 つ、...
A5ウェブマスターの記事をよくプレビューすると、毎日、古いウェブマスターがソフト記事の書き方に関する...
2020年6月10日、Nanhua FuturesはQingCloudが構築した「Nanhua Cl...
アマゾン ウェブ サービスは2022年11月9日、第5回中国国際輸入博覧会(CIIE)の期間中、アマ...
vaicdnは主に高速、高防御のCDNサービスを提供しており、ハイエンドの専用線アクセス(CN2など...
市場調査会社フォーチュン・ビジネス・インサイトが発表したレポートによると、IoT市場規模は2019年...
小説では、頂点から一歩手前の修行段階を「頂点まで半歩」と呼ぶことが多い。 1946年、アメリカで世界...
先日、「良い x: 修正済み - 年間支払い $12/KVM/1000M ポート/無制限トラフィック...
ZENON NSP は 1996 年に設立されたロシアのホスティング会社です。非常に古いブランドです...
ウェブマスターなら誰でも、ウェブマスターコミュニティで広く流布している「コンテンツは王、外部リンクは...
ソフト記事を初めて書く著者にとって、優れたソフト記事の書き方は確かに疑問です。高品質のソフト記事は、...