HHU クラウド コンピューティング最終レビュー (パート 1) Google、Amazon AWS、Azure

河海大学ビジネススクールのクラウドコンピューティングコースの復習ノートの前半は
試験会場のみを対象としているため、包括的ではなく、将来必要になる学生のために予約されています
。 Google Cloud Computing、Amazon AWS、Microsoft Azure について、システムの重要な知識ポイント

第1章;序章

クラウド コンピューティングは、サーバー、ストレージ、データベース、ネットワーク、ソフトウェア、分析、その他のサービスを含むコンピューティング サービスを、インターネット (「クラウド」) を通じて世界中のユーザーに提供するモードです。サービスの種類に応じて、クラウド コンピューティングは一般に、サービスとしてのインフラストラクチャ (IaaS)、サービスとしてのプラットフォーム (PaaS)、およびサービスとしてのソフトウェア (SaaS) の 3 つのカテゴリに分類できます。

以下に、これら 3 つのサービス タイプの詳細な紹介と代表的な例を示します。

1. Infrastructure as a Service (略称 IaaS) : サーバー、ストレージ、ネットワーク ハードウェアなどのインフラストラクチャ サービスを含むコンピューティング リソースを提供します。ユーザーは、ビジネスの変化に対応するために、ニーズに応じていつでもリソースを購入または解放できます。このサービスにより、ユーザーはインフラストラクチャの詳細をすべて制御できるようになりますが、同時にシステムの運用、保守、管理についてはユーザーが責任を負う必要があります。代表的な IaaS サービス プロバイダーには、Alibaba Cloud や Tencent Cloud などがあります。
2. Platform as a Service (略して PaaS) : 完全な開発および展開環境を提供し、開発者は基盤となるインフラストラクチャを管理せずにコードの作成に集中できます。通常、PaaS にはオペレーティング システム、データベース、ミドルウェアなどのサービスが含まれており、ユーザーはアプリケーションの開発のみに集中すればよく、基盤となるインフラストラクチャを管理する必要はありません。Huawei Cloud はさまざまな PaaS サービスを提供しており、Alibaba Cloud と Tencent Cloud も同様のサービスを提供しています。
3. Software as a Service (略称 SaaS) : ネットワーク経由でソフトウェア アプリケーションを提供します。ユーザーはソフトウェアを購入してインストールする必要はなく、ネットワークを使用するだけで済みます。SaaSは通常サブスクリプション制を採用しており、ユーザーはソフトウェアやハードウェアの購入や保守を行わず、ソフトウェアの使用料のみを支払うだけで済みます。SaaSサービスの代表例としては、アリババのDingTalkやテンセントのWeChat Workなどが挙げられる。

クラウドコンピューティングの主なサービスは上記の3つです。これら 3 つのサービス タイプは相互に排他的ではなく、多くのクラウド サービス プロバイダーがこれら 3 つのサービスを同時に提供することに注意してください。

第 2 章 Google クラウド コンピューティング

2.1 Google ファイル システム (GFS)

GFS はもともと、Google のビッグデータのストレージと処理のニーズを満たすように設計されました。このシステムは、マスター サーバー (Master Server)、複数のチャンク サーバー (Chunk Server)、および一連のクライアント ライブラリ (Client) で構成されます。

• クライアントは、GFS によってアプリケーションに提供されるアクセス インターフェイスです。
• メインサーバー Master は、名前空間、アクセス制御情報、ファイル ブロック情報などのメタデータ (メタデータ) の管理を担当します。メインサーバーはファイルの読み書きに直接関与しないため、ボトルネックになることが回避されます。
• チャンク サーバーはファイルを固定サイズのチャンク (デフォルトでは 64MB) として保存し、マスターの指示でそれらを複製してフォールト トレランスを提供します。

GFS ファイルの書き込みプロセスは大まかに次のとおりです。

• クライアントはマスターサーバーに、どのチャンクサーバーがファイルを保持しているかを尋ねます。
• マスターサーバーがチャンクサーバー情報を返した後、クライアントはチャンクサーバーに書き込みリクエストを送信します。
• チャンク サーバーは書き込みデータを受け入れ、成功するとメタデータを更新するようにマスター サーバーに通知します。

升级原理？

2.2 MapReduce と Hadoop

分散データ処理

MapReduce は Google によって設計されたビッグ データ処理プログラミング モデルであり、Apache Hadoop はこのモデルのよく知られたオープンソース実装です。

MapReduce には主に、Map ステージ、Shuffle ステージ、Reduce ステージの 3 つのステージがあります。マップ フェーズでは、入力データが複数のブロックに分割され、クラスターの各ノードで並列処理されて、一連のキーと値のペアが生成されます。次の Shuffle ステージでは、これらのキーと値のペアをキーに従って並べ替えてグループ化し、同じキーを持つ値を 1 つに集めることができます。次に、Reduce フェーズで、キーと値のペアのキーに従って、対応する値が集約されます。

このプロセスの例を次に示します。

大きなテキスト ファイルを処理する必要があり、その目標が各単語の出現数をカウントすることであるとします。MapReduce を使用してこのタスクを実行できます。

1. Map ステージ: 各 Map タスクはファイルの一部を処理し、テキストを読み取り、各単語をキーと値のペアとして出力します (キーは単語自体、値は単語の数 (最初は 1))。たとえば、入力が「アップル バナナ アップル」の場合、Map ステージの出力は [("apple", 1), ("banana", 1), ("apple", 1)] となります。
2. シャッフル ステージ: このステージでは、システムはすべてのキーと値のペアをキーに従って自動的に並べ替えてグループ化し、すべての同じキーが 1 つに集められます。私たちの場合、シャッフル ステージはすべての ("apple", 1) と ("banana", 1) を一緒に収集します。
3. Reduce フェーズ: このフェーズでは、各 Reduce タスクは Shuffle フェーズの結果を受け取り、同じキーのすべての値を集計します。たとえば、「apple」の場合、Reduce フェーズの入力は [("apple", 1), ("apple", 1)] であり、これらのカウントが合計され、出力結果は [("apple" 、２）】。

このように、MapReduce を使用することで、大規模クラスター上の大量のデータを効率的に処理できます。

• 具体的な実行プロセス:
  • MapReduce の一般的な実行プロセスを次の図に示します。

図の 6 つのステップは以下に対応しています。

1. 入力ファイルはまず M 個のデータ セグメントに分割され、各データ セグメントのサイズは通常 16MB ～ 64MB になります。その後、ユーザー プログラムはクラスター全体にプログラムのコピーを多数作成します。
2. 1 つのマスターを除いて、レプリカ プログラムはすべてワーカー プログラムであり、マスターは M 個のマップ タスクと R 個のリデュース タスクを割り当てます。マスターは、アイドル状態のワーカーにマップ タスクまたはリデュース タスクを割り当てます。
3. マップ タスクを割り当てられたワーカー プログラムは、対応する入力データ フラグメントを読み取り、キーと値のペアを解析して処理し、キーと値のペアの中間結果を生成して出力し、それをメモリ バッファーにキャッシュします。
4. バッファ内の中間結果は、ユーザー指定のパーティション関数 (例: hash(key) mod R) によって定期的に R 部分に分割され、ローカル ディスクに保存されます。タスクが完了すると、ローカル ディスクにキャッシュされたストレージの場所がマスターに返され、マスターはこれらのストレージの場所を Reduce ワーカーに転送する責任を負います。
5. リデュース ワーカー プログラムは、マスター プログラムから送信されたデータの保存場所情報を受信すると、RPC を使用して、マップ ワーカーが存在するホストのディスクからキャッシュされたデータを読み取り、同じキー値でデータをソートして集計します。キー。中間データが大きすぎてメモリ内でソートできない場合は、外部でソートする必要があります。
6. Reduce ワーカー プログラムは、ソートされた中間データを走査します。一意の中間キー値ごとに、Reduce ワーカーはキー値とそれに関連する値の値セットを処理のためにユーザー定義の Reduce 関数に渡し、処理出力は対応するパーティションの出力ファイル。ソートされた中間データは順次処理されるため、各出力ファイルのフラグメントは内部的に順序付けされます。

2.3 分散ロックサービス Chubby

Chubby は Google の分散ロック サービスです。粗粒度のロックと少量のデータを保存する機能を提供することで、他の Google システムに共同サービスを提供します。

• Chubby通信プロトコル（教科書P30を読む）

• マスターサーバーエラー

  • Chubby 通信中、クライアントは RPC リクエストを送信することで Chubby サーバーと対話します。メイン サーバーに障害が発生すると、フェイルオーバーが実行され、バックアップ サーバーがその役割を引き継いでシステムの可用性を確保します。

• リースメカニズム

  • リース メカニズムは、Chubby がサービスの可用性を確保するための重要な手段です。クライアントがロックを取得すると、通常は数十秒間有効なリースも取得します。クライアントのリースが期限切れになっていない限り、クライアントはそのロックを保持していると考えることができます。クライアントがリース期間中に Chubby サーバーとのリースを更新した場合、リースは引き続き有効です。サーバーがリース更新リクエストを受信しない場合、サーバーはクライアントがクラッシュしたとみなしてロックを解放し、他のクライアントがロックを取得できるようにします。

たとえば、あなたが Google ドキュメントで文書を作成しており、同僚が同時にその文書を編集したいと考えているとします。太いロックにより、このプロセス中にドキュメントの同じ部分を同時に変更できなくなり、競合が発生する可能性があります。段落を編集すると、クライアントは Chubby ロックを取得して、編集中に他の人がその段落を変更できないようにします。リースの有効期限が切れて更新されない場合、Chubby は編集を停止したものとみなし、ロックを解除し、他の人がその段落を編集できるようにします。

2.4 分散構造化データテーブル Bigtable

ビデオ: https://www.bilibili.com/video/BV1bj41137BY/

Bigtable は Google の分散ストレージ システムであり、主に構造化データの保存に使用されます。Bigtable は主に、クライアント ライブラリ (Client Library)、メイン サーバー (マスター サーバー)、および複数のサブテーブル サーバー (タブレット サーバー) の 3 つの部分で構成されます。

Bigtable のデータは行と列で編成されており、各行は行キーによって一意に識別されます。

保管形態

• <行キー、列キー、タイムスタンプ> -> 内容

• 行ラベルの格納方法

  • Bigtable に行キーが格納される方法は辞書順 (アルファベット順という意味です) にソートされているため、隣接する行キーの読み取り操作が非常に効率的になります。**この機能により、Bigtable は特定の範囲に従って読み取る必要がある操作に非常に適しています。

• 行ラベルを反転する利点

  • 同じアドレス ドメイン内の Web ページはテーブル内の連続した位置に保存されるため、ユーザーが検索および分析するのに便利です。

  • 反転はデータ圧縮に便利で、圧縮率を大幅に向上させることができます。

  • 説明する：

    • ドメイン名:

      • 「www.example.com/news」では、「example.com」はメイン ドメイン名、「www」はこのメイン ドメイン名の下にあるサブドメイン名、「/news」はこのサブドメイン名の下にあるパスまたはページです。
      • 「news.example.com」では、「example.com」がメインドメイン名のままですが、今回の「news」はこのメインドメイン名の下にあるサブドメインになります。

      サブドメインはメイン ドメイン名の枝であり、通常はメイン ドメイン名の下にあるさまざまな機能やサービスを示すために使用されます。たとえば、多くの Web サイトには、ブログをホストする「blog.example.com」や、オンライン ストアをホストする「shop.example.com」があります。

    • Bigtable の設計者は、特に URL に多くのレベルのサブドメイン名がある場合に、主に「ドメイン名」のクエリ効率を最適化するために、URL を逆の順序で使用することを選択しました。

      1. news.example.com
      2. スポーツ.example.com
      3. Finance.example2.com

      URL が正の順序でソートされている場合、上記の 3 つの URL 内の同じメイン ドメイン名 (example.com または example2.com) のページは必ずしもまとめられるとは限りませんが、逆の順序でソートすると次のことが可能です。

      1. com.example.news
      2. com.example.スポーツ
      3. com.example2.finance

メインサーバー

• メインサーバーの主な役割

  • 

子表

• タブレット

  • Bigtable のテーブルは、Bigtable で「タブレット」と呼ばれる多数の小さな部分で構成されています。各タブレットは行キーの範囲の一部を表すため、テーブル全体を、並列処理される多数の小さな部分、いわゆる「サブテーブル」に分割できます。タブレットは、テーブルの分散ストレージと並列処理を容易にします。
  • 概念的には、サブテーブルは行のコレクションです

• タブレット サーバーは、1 つ以上のタブレット テーブルの処理を担当する Bigtable 内のサーバーです。サブテーブルの読み取りおよび書き込みリクエストを処理し、必要に応じてサブテーブルをより小さな単位に分割します。

• SSTテーブル

  • SSTableフォーマットの基本図
    • SSTable は、Bigtable 用に設計された Google の内部データ ストレージ形式です。すべての SSTable ファイルは GFS に保存され、ユーザーはキーによって対応する値をクエリできます。
    • 各 SSTable には、データの効率的な検索と読み取りに使用される一連のブロック (ブロック) とブロック インデックス (ブロック インデックス) が含まれています。
    • 

• 子テーブルの実際の構成

  • サブテーブルは複数の SSTable とログ ファイルで構成されます
  • 異なるサブテーブルのSSTableを共有可能
  • 各子テーブル サーバーにはログ ファイルが 1 つだけ保存されます。
  • Bigtable では、ログの内容がキー値でソートされることが規定されています
  • 各サブテーブル サーバーに保存されるサブテーブルの数は数十から数千の範囲であり、通常は約 100 です。
  • 

• サブテーブルのアドレス構成

  • サブテーブル (タブレット) のデータは 1 つ以上の SSTable に格納されます。各 SSTable には、ソートされたキーと値のペアが格納され、このソート機能により、範囲クエリやシーケンシャル読み取りなどの操作が非常に効率的に行われます。
  • サブテーブルと SSTable の間には重要なマッピングがあります。各サブテーブルは、そのデータがどの SSTable に格納されているかを認識します。サブテーブル サーバーは、サブテーブルのデータの読み取りまたは書き込みが必要な場合、このマッピング関係を使用して対応する SSTable を見つけ、SSTable 内で操作します。
  • 

• 3 つの形式のデータ圧縮

  • 微圧縮、複合圧縮、一次圧縮
  • 

サブテーブルのデータは最終的に GFS に書き込まれ、GFS 内のサブテーブルの物理形式は複数の SSTable ファイルになります。

クラスタにはメイン サーバーとサブサーバーが含まれており、メイン サーバーはサブサーバーへのスライスの割り当てを担当し、サブサーバーは特定のデータ サービスを完全に担当します。

ただし、サブサーバーが実際にデータを保存している (メモリ内の memtable データを除く) と誤解しないでください。データの実際の場所は GFS のみが知っており、メインサーバーはサブテーブルをサブサーバーに割り当てる必要があります。これは、サブサーバーがサブテーブルのすべての SSTable ファイル名を取得したことを意味します。サブサーバーは、インデックス作成メカニズムを通じて、必要なデータがどの SSTable ファイルに含まれているかを知ることができ、GFS から SSTable ファイルのデータを読み取ることができます。複数のチャンクサーバーに分散されます。

Bigtable 関連の最適化手法

Bigtable は、BWT (Burrows-Wheeler Transform) とブルーム フィルターなどのパフォーマンス最適化手法を使用します。

1. BWT (Burrows-Wheeler Transform): データ圧縮のアルゴリズムであり、主に文字列データの変換に使用されます。BWT では、文字列の文字が特定の順序で配置され、新しい文字列が選択されます。この新しい文字列内の文字の順序によって、その後の圧縮アルゴリズム (前へ移動変換、実行など) が改善されます。長さエンコーディング）の効率。つまり、BWT は、文字列内の文字の順序を変更し、元々ランダムに分散されていた文字をより集中させることにより、圧縮の効率を高めます。この変換は可逆的であることは注目に値します。つまり、BWT によって変換および圧縮されたデータは完全に復元できます。???

2. ブルーム フィルター: ブルーム フィルターは、要素がセットのメンバーであるかどうかを検出するために使用される、スペース効率の高い確率的データ構造です。その主な特徴は、一定の誤検知率はありますが、それを見逃すことは決してないことです。偽陽性率は、コレクションに存在しない要素をクエリすることを指し、ブルーム フィルターはその要素がコレクション内にあると誤って認識する可能性があります。偽陰性は、コレクションに存在する要素をクエリすることを指し、ブルーム フィルターは間違いではありませんが、セットには含まれていないと考えてください。Bigtable では、不要なディスク読み取り操作を減らすためにブルーム フィルターが使用されます。要素をクエリするとき、最初にブルーム フィルターを使用してそれを判断します。判断結果が「存在しない」場合は、ディスクの読み取りを回避できます。結果が「in」の場合は、さらにディスクからデータを読み取って判断する必要があります。

   • 電話帳があり、電話番号が電話帳にあるかどうかを判断する必要があるとします。電話帳に直接クエリを実行すると、電話帳全体を調べる必要があり、時間がかかります。一方、ブルーム フィルターを使用すると、非常に短時間で答えを得ることができます。まず、電話帳内のすべての電話番号をブルーム フィルターに追加し、ビット配列を生成します。次に、電話番号が電話帳にあるかどうかを確認する必要がある場合、このビット配列を確認するだけで済みます。ブルームフィルターで「載っていない」と判定されれば、その電話番号は間違いなく電話帳に載っていないことがわかり、不要な問い合わせを避けることができます。ブルーム フィルタの結果が「in」の場合は、電話帳をさらに確認して判断する必要があります。このようにして、ほとんどの場合、非常に短時間で答えを得ることができ、クエリの効率が大幅に向上します。

一般に、BWT はデータ圧縮効率を向上させるために使用されるアルゴリズムであり、ブルーム フィルターは不要なディスク読み取りを削減してクエリ効率を向上させるために使用されるデータ構造です。どちらも Bigtable で重要な役割を果たします。

2.5 分散ストレージシステム Megastore

https://www.jianshu.com/p/7c4d0ab911f6

メガストア

Megastore は Google の分散ストレージ システムであり、Bigtable に基づいて構築されており、ACID トランザクションを含むいくつかのリレーショナル データベース機能をユーザーに提供します。

Megastore の基本アーキテクチャには次の部分が含まれます。

• エンティティ グループ: Megastore はデータをエンティティ グループ (エンティティ グループ) に編成します。各エンティティ グループは Bigtable の方法で内部的に保存され、各エンティティ グループは ACID セマンティクス (小さなデータベースのような) を持つトランザクションを提供できます。ACID トランザクションはエンティティ グループ間で提供できません。

• レプリカ: データの可用性と耐障害性を向上させるために、Megastore は各エンティティ グループのデータを複数の物理的な場所に複製します。

• Paxos: Megastore は Paxos アルゴリズムを使用して、各エンティティ グループの複数のレプリカ間の一貫性を保証します。Megastore のすべての書き込み操作は、大多数の Paxos によって送信される必要があります。

• キャッチアップ: 異なるリージョン間のデータの一貫性を確保するために、Megastore はキャッチアップ メカニズムを提供します。つまり、コピーが他のコピーより遅れている場合、キャッチアップ プロセスを通じて失われた更新を取得できます。

• 製品: Megastore は多くの Google 製品で広く使用されており、たとえば、Google App Engine のデータ ストレージは Megastore に基づいて実装されています。

ACID セマンティクス

ACID は、データベース トランザクションを正しく実行するための 4 つの基本特性、つまり原子性 (Atomicity)、一貫性 (Consistency)、分離 (Isolation)、永続性 (Durability) を指します。

1. A (原子性) 原子性: これは、トランザクション全体が分割不可能な単位であることを意味します。トランザクション内のすべての操作は、すべて正常に送信されるか、すべて失敗してロールバックされます。トランザクションの操作について、システムはすべての操作が次のいずれかであることを保証します。完了または完全に完了、これを行わないと、中央のリンクに留まることはできません。トランザクションのアトミック性は、「元に戻す」と「やり直し」によって実現されます。

2. C (一貫性) 一貫性: トランザクションは、データベースをある一貫性のある状態から別の状態に変換する必要があります。一貫性はビジネスに関連します。たとえば、アカウント A がアカウント B に送金する場合、送金が成功したかどうかに関係なく、アカウント A の出金金額はアカウント B の入金金額と一致している必要があります。これがビジネスの一貫性です。

3. I (lsolation) - 分離: 複数のユーザーが同時にデータベースにアクセスする場合、各ユーザーに対してデータベースによって開かれたトランザクションは他のトランザクションの操作によって干渉されることができず、複数の同時トランザクションは互いに分離されなければなりません。つまり、次のような効果を実現します。トランザクション T1 の観点から見ると、任意の 2 つの同時トランザクション T1 と T2 について、T2 は T1 が開始される前に終了するか、T1 が終了した後に開始されます。これにより、各トランザクションは、システム内の他のトランザクションが実行されていないように感じられます。並行して。

4. D (耐久性) 永続性: トランザクションがコミットされると、その変更はデータベースに永続的に保存されます。トランザクションコミット後にシステムがクラッシュした場合でも、再起動後はトランザクションの永続性が保証されます。

基本構造

• フルコピー:完全なログとデータは Bigtable に保存されます。

• 証人コピー: Paxos アルゴリズムの実行中に解決策を生成できない場合に投票に参加します。したがって、このコピーの場合、Bigtable はログのみを保存し、特定のデータは保存しません。

• 読み取り専用コピー:投票には参加できません。最近のある時点までの一貫したデータを読み取る機能のみです。読み取り操作がこれらの古いデータを許容できる場合、読み取りレプリカは書き込み遅延を悪化させることなく、広い地理的空間にデータを送信できます。

• Megastore の展開には、クライアント関数ライブラリと複数のサーバーが必要です。アプリケーションは、Paxos アルゴリズムを実行するこのクライアント関数ライブラリに接続します。また、コーディネーター (高速読み取り) と呼ばれるサービスもあります。このサービスの役割を理解するには、まず高速読み取りメカニズムと高速書き込みメカニズムを理解する必要があります。

• Megastore は、世界中に多数の支店、つまりサーバーを持つ超大規模な図書館と考えることができます。これらの分館の中には、全冊の図書と詳細な貸出記録を保管している図書館（全冊）もあります。本を所蔵していない図書館（証書）もありますが、すべての貸し出しを記録しています。また、図書の閲覧のみを許可し、貸出情報を記録しない図書館（閲覧専用）もあります。読者が本を借りたいときは、クライアント関数ライブラリ (つまり、貸出デスク) に接続する必要があり、貸出デスクは一連のプロセス (Paxos アルゴリズムと同様) を実行して、本の貸出プロセスが確実に行われるようにします。正しい。コーディネーターサービスは、探している本がどこにあるかをすぐに教えてくれるクイッククエリサービスのようなもので、これが速読の仕組みです。

コアテクノロジー - コピー

• 読み取られたデータ:

• 現在の読み取りの前に、少なくとも 1 つのコピー上のデータが最新であることを確認する必要があります。つまり、以前にログに送信されたすべての更新がコピーに送信され、そのコピーに確実に反映される必要があります。コピー。** このプロセスはキャッチアップと呼ばれます

• 

スーパーに買い物に行くようなプロセスだと考えてください。あなたは買い物リストを手に持っていますが、スーパーマーケットに入る前にこのリストを最新の状態に保つ必要があります。つまり、家で行うすべての変更 (特定の製品の追加または削除など) がこのリストに更新されることになります。リスト、このプロセスはキャッチアップです。そしてそのリストに従ってスーパーで買い物をする、これがデータ読み取りのプロセスです。買い物の過程で突然リストに商品がないことに気づいた場合は、家に帰ってリストを再度更新する必要があります。これにより、リスト (コピー) が最新であることを確認できます。

第 3 章 アマゾン AWS

3.1 ダイナモ

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

• ダイナモ

  • 基盤となるストレージ アーキテクチャは、単純なキーと値のペアのストレージのみをサポートします
  • センタレスモデル
  • 中心的なアイデア: Dynamo は、データセンター内の分散ストレージを通じて高可用性とスケーラビリティを実現します。
  • アーキテクチャ形式: Dynamo は、データ分散に一貫したハッシュ アルゴリズムを使用するため、ノードが動的に変更された場合でもシステムが負荷を分散し、データ移行を最小限に抑えることができます。

• Windows Azure は、コンピューティング サービス、ストレージ サービス、およびアプリケーションと通信するためのさまざまなサービスを提供するクラウド ベースのアプリケーション実行環境です。Azure では、ストレージ層はマルチコピー レプリケーション メカニズムを使用し、データをさまざまな物理ノードにレプリケートすることでデータの永続性と信頼性を実現します。

  2 つの主な違いは、設計目標と実装方法にあります。Dynamo は高可用性とスケーラビリティに重点を置き、非構造化データに適しており、最終整合性モデルを使用します。一方、Azure はコンピューティング、ストレージ、通信サービスを提供するより一般的なプラットフォームで、構造化データの保存に適しており、強力な整合性モデルを使用しています。 。

一貫したハッシュアルゴリズム

• 一貫性のあるハッシュ アルゴリズム: Haogang: 一貫性のあるハッシュ アルゴリズムを詳細に説明する 7 分間のビデオ
  • コンシステント ハッシュ アルゴリズムでは、仮想ノードと物理ノードの関係は、各物理ノードが複数の仮想ノードに対応し、各仮想ノードが物理ノードのデータの一部を格納すると単純に理解できます。仮想ノードを追加することで、物理ノードの数が変化したときに負荷を均等に分散し、移行する必要があるデータの量を最小限に抑えることができます。
  • より多くの仮想ノードを使用すると、次のような利点があります。
    • 1) データをより均等に分散し、データの偏りの問題を軽減できます。これは、実際には各物理ノードのパフォーマンスが必ずしも同じであるとは限らず、仮想ノードの導入により、異なるパフォーマンスのノードが異なる負荷を負担する可能性があるためです。
    • 2) 物理ノードを追加または削除する場合、少量のデータのみを移行する必要があるため、データ移行のオーバーヘッドが軽減されます。
    • 3) システムの拡張性と安定性を向上させます。
  • 一貫性のあるハッシュ アルゴリズムでは、特定のキー (キー) を見つける複雑さは通常$O\left(log\right(n))$、ここで$n$はハッシュ リング内のノード (サーバー) の数です。
  • コンシステント ハッシュ アルゴリズムは、たとえば、レプリケーションおよびデータ断片化メカニズムを導入することによってさらに改善でき、システムの可用性とデータ セキュリティをさらに向上させることができます。

冗長バックアップ

• パラメータを調整できる弱いクォーラム メカニズム
  • $R+W>N\; は$、障害のあるノードの数が 1 つを超えない場合、ユーザーが最新データの少なくとも 1 つのコピーを取得できることを保証できます。どこに$W\; は、$書き込み操作を成功させるために少なくとも書き込む必要があるコピーの数を表します ($R\; は、$読み取り操作が成功するためにサーバーからユーザーに返される必要があるコピーの最小数を示します$N\; は、$各データストアのレプリカの数を表します。
• 冗長バックアップがデータ セキュリティを向上させる理由
  • 冗長バックアップは、データのセキュリティと可用性を保護するための一般的な手段です。冗長バックアップの原則は、データのコピーを複数の場所に保存することです。1 つの保管場所に障害が発生し、データが失われたり破損したりしても、そのデータのコピーを別の場所から取得できます。たとえば、DynamoDB は、データのコピーを複数の可用性ゾーンに保存することで、高可用性とデータ耐久性を提供します。
  • 実際、冗長バックアップはデータのセキュリティを向上させるだけでなく、データの可用性も高めます。ストレージ ノードに障害が発生した場合、システムは他のストレージ ノードからデータを迅速に取得できるため、単一障害点によるシステムの利用不能を回避できます。

メンバーシップとエラー検出

P96

• Dynamo は非中央アーキテクチャであり、各メンバー ノードは他のノードのルーティング情報を保存する必要があります。

• 分散システムでは、メンバーシップとエラー検出が非常に重要な問題になります。メンバーシップとは、システム内のどのノードが操作に参加しているかを決定することを指します。エラー検出とは、システム内のどのノードに障害が発生した可能性があるかを判断することを指します。

• メンバーシップ (メンバーシップ) とは、分散システム内でどのノードがアクティブであるか、つまり現在操作に参加しているノードを決定することを指します。分散システムでは障害やその他の理由でノードがオフラインになる可能性があるため、どのノードがオンラインであるかを追跡して識別するメカニズムが必要です。

  • マルチプレイヤー オンライン ゲームに参加していて、このゲームのサーバーが分散されているとします。各プレイヤーはサーバー ノードに接続します。このとき、メンバーシップとは、現在オンラインでゲームに参加しているプレイヤー (ノード) を識別することです。

• 障害検出: 分散システム内でどのノードに障害が発生したかを特定することを指します。大規模な分散システムでは障害はつきものだからです。一部のノードは、ハードウェア障害やネットワークの問題などのさまざまな理由により動作しない場合があります。

  • 例として上記のゲームを続けます。チーム内のプレイヤーが突然オフラインになったとします (おそらくネットワーク障害やコンピューターのクラッシュなどが原因です)。エラー検出のタスクは、プレーヤーがオフラインであることをできるだけ早く見つけて、ゲームが適切な措置を講じられるようにすることです (AI に引き継がせる、または参加する新しいプレーヤーを見つけるなど)。

メンバーシップとエラー検出は通常、 「 Gossip 」と呼ばれるプロトコルを通じて実装されます。このメカニズムでは、各ノードは、自分が「生きている」というメッセージを他のノードに定期的に送信します。ノードが別のノードからの応答を一定期間受信しない場合、そのノードはオフラインであるか、障害が発生していると見なされます。

• 新しいノードが合計ノード数 N のシステムに参加し、最適な方法で拡散する場合 (つまり、各通信の 2 つのノードが初めてノード情報を交換する場合)、新しいノードの拡散に必要な時間はシステム全体の複雑さは$O\left(ログオン\right)\_\_\_$

3.2 エラスティック コンピューティング クラウド EC2

• 地理とアベイラビリティーゾーン

• EC2 は Amazon の Elastic Compute Cloud の略称で、スケーラブルなコンピューティング機能を提供します。ユーザーは、Amazon のコンピューティング環境の仮想マシン上でアプリケーションを起動できます。GPUの提供など各種サービス

• AWS グローバル インフラストラクチャは、世界中に分散されたクラウド インフラストラクチャです。これらのインフラストラクチャには、地理的リージョンと可用性ゾーンが含まれます。

  • 地理的リージョンは、世界中の AWS クラウドの物理的な場所であり、各リージョンには少なくとも 2 つのアベイラビリティ ゾーンが含まれます。
  • アベイラビリティーゾーンは、地理的には離れていますが、同じ地理的エリア内にあり、ネットワーク遅延が低いデータセンターを表します。通常、独立した電源システムと冷却システムがあるかどうかによって分類されます。
  • EC2 は複数の地理的リージョンで構成され、各地理的リージョンには複数のアベイラビリティ ゾーンが含まれます。

• このアイデアをアプリケーション アーキテクチャに組み込むと、アプリケーションの可用性と災害復旧機能が向上します。たとえば、アプリケーションを複数のアベイラビリティーゾーンにデプロイすると、1 つのアベイラビリティーゾーンで問題が発生した場合でも、他のアベイラビリティーゾーンでアプリケーションを正常に実行できます。

3.3 シンプルストレージサービスS3

S3 (Simple Storage Service) は、Amazon が提供するオブジェクト ストレージ サービスで、オブジェクトを単位として使用し、インターネット上で任意の量のデータを保存および取得する機能を提供します。

• バケット: バケットは Amazon S3 のフォルダーまたはディレクトリのようなもので、オブジェクト (データ) を保存するために使用されます。各バケットには S3 内でグローバルに一意の名前が付けられており、S3 に保存されているすべてのオブジェクトは何らかのバケットに含まれている必要があります。ユーザーはバケットのアクセス権限を設定して、バケット内のオブジェクトにアクセスできるユーザーを制御できます。バケットは、特定の地理的領域にデータを保存するように構成することもできます。
• オブジェクト: オブジェクトは主にデータとメタデータで構成され、ファイルと同様にバケット内の基本要素です。各オブジェクトには、ファイル自体に関するデータといくつかのメタデータ (ファイルの種類、作成日など) が含まれています。S3 では、ファイル システム内でファイルがそのパスとファイル名によって一意に識別されるのと同様に、オブジェクトはバケット内のキーによって一意に識別されます。

バケットとオブジェクトの関係は、現実の大きな倉庫 (バケット) とその倉庫内のさまざまな商品 (オブジェクト) にたとえることができます。倉庫とはさまざまな商品を保管する場所であり、商品は倉庫の基本単位です。各製品には、オブジェクトのメタデータのような独自のタグ (製品名、製造日など) があります。倉庫では、各アイテムには固定の場所があり、これは S3 バケット内のオブジェクトのキーのようなものです。

この例では、特定のアイテムを検索したい場合、まずそれがどの倉庫 (バケット) にあるかを知る必要があります。次に、タグ (メタデータ) または場所 (キー) に基づいてアイテム (オブジェクト) を見つけることができます。アイテム。

3.4 非リレーショナルデータベース

リレーショナルデータベースとの違い

教科書 P108

• リレーショナル データベース: MySQL、PostgreSQL などは、データがテーブルの形式で格納される、リレーショナル モデルに基づくデータベースです。リレーショナル データベースはデータの一貫性とトランザクション性を重視し、ACID の原則(原子性、一貫性、分離性、耐久性) に従います。このタイプのデータベースは、結合、グループ化、集計などの複雑なクエリ要件を持つアプリケーションに適しています。
• 非リレーショナル データベース (SimpleDB、DynamoDB など) : NoSQL データベースとも呼ばれる非リレーショナル データベースは、主に大規模なデータを処理するように設計されており、高スループット、低遅延のデータ アクセスとストレージを提供できます。このようなデータベースは通常、トランザクション機能をサポートしないか、制限された機能のみを提供し、ACID 原則には従わない場合がありますが、BASE 原則 (基本可用性、ソフト状態、結果整合性) に従う場合があります。たとえば、DynamoDB は、柔軟なスケーラビリティと予測可能なパフォーマンスで知られるキーバリュー ストア システムです。

3.5 リレーショナルデータベースサービスRDS

AWS は、Amazon RDS と呼ばれる MySQL 用のマネージド サービスを提供しています。バックアップ、パッチ適用、フェイルオーバーなど、データベースの日常的な管理タスクの多くを処理します。ユーザーは、単一の可用性ゾーンで RDS インスタンスを実行することを選択することも、可用性と耐障害性を高めるために複数の可用性ゾーン間でレプリケートすることもできます。

RDS (Relational Database Service) は、アマゾン ウェブ サービス (AWS) が提供するリレーショナル データベース サービスです。MySQL は、オープンソースのリレーショナル データベース管理システム (RDBMS) です。したがって、MySQL は「製品」、RDS は「サービス」と考えることができます。

RDS サービスでは、MySQL、PostgreSQL、MariaDB、Oracle、SQL Server など、さまざまなタイプのデータベース エンジンを選択できます。したがって、MySQL は RDS でサポートされるデータベースの 1 つです。AWS の RDS サービスを使用すると、ユーザーはデータベースを簡単に展開、拡張、管理できます。RDS は、バックアップ、ソフトウェア パッチの更新、フェイルオーバーなど、ユーザー向けの多くのデータベース運用およびメンテナンス タスクを処理します。

簡単に言えば、MySQL を自分のサーバーにダウンロードしてインストールするだけで済みますが、その場合、すべてのメンテナンスと管理を自分で行う必要があります。また、AWS の RDS サービスを使用し、データベース エンジンとして MySQL を選択した場合、AWS が多くの運用とメンテナンスのタスクを処理してくれるため、データベースの使用だけに集中する必要があります。

3.6 コンテンツプッシュサービス CloudFront

CDN (コンテンツ配信ネットワーク) は、ユーザーがより速くアクセスできるように、地理的に異なる場所にあるサーバー上にコンテンツを複製するサービスです。CDN を使用すると、コンテンツをユーザーに近づけることができるため、ユーザーはより早くコンテンツを入手できるようになります。

違い：

Amazon CloudFront や Azure CDN はそのようなサービスの例です。どちらもコンテンツ (Web サイトの静的および動的コンテンツ、ビデオ ストリーミング、API 呼び出しなど) を世界中のエッジ ロケーションにキャッシュできるため、コンテンツをより迅速にユーザーに提供できます。

? ? ? 2 つの違いは何ですか。Azure にはキャッシュが必要です。

例として、米国東部に Web サイトがあり、ユーザーが世界中に広がっているとします。CDN がない場合、オーストラリアのユーザーは米国東部のサーバーにリクエストを送信し、結果を返す必要があります。これにより、遅延が増加します。ただし、CDN を使用すると、Web サイトのコンテンツはオーストラリアを含む世界中のサーバーにレプリケートされます。その結果、オーストラリアのユーザーは近くのサーバーからコンテンツを取得できるようになり、待ち時間が大幅に短縮されました。

第4章 マイクロソフトのクラウドコンピューティングサービス「Azure」

4.1 5 つの部分

• たとえ話から始めましょう

1. コンピューティング サービス: Azure のコンピューティング サービスは、リースされたコンピューターと考えることができます。インターネット カフェでコンピューターをレンタルするのと同じように、Web の閲覧、コードの作成、さらにはサーバーの実行など、やりたいことはすべてそのコンピューターで実行できます。Azure が提供するコンピューティング サービスは、クラウド上のコンピューターをレンタルし、その上でアプリケーションを実行できるようにするものです。
2. ストレージ サービス: Azure のストレージ サービスは、保管しておきたいものはすべて保管できる、レンタル倉庫のようなものです。Azure は、 Blob (大きな箱に似ており、何でも置くことができます)、テーブルストレージ (巨大な Excel テーブルのような、構造化データの保存に使用されます)、キューストレージ (キュー システムのような、保留中のメッセージの保存に使用されます)、およびディスク ストレージを提供します。 (コンピューターのハード ドライブと同様、さまざまなファイルやデータの保存に使用されます)。
3. ファブリック コントローラー:ファブリック コントローラーは、インテリジェントなビル管理者またはビル管理者のようなものです。サーバー、ネットワーク、ストレージなどのクラウド サービス内のリソースの調整と管理を担当します。ビル管理者がどの会社がどのオフィスを借りるか、電力をどのように分配するか、ネットワーク接続をどのように構成するかを決定するのと同じように、ファブリック コントローラーは、Azure サービス インスタンスのプロビジョニングとライフサイクルの管理、ネットワークとストレージのリソースの割り当てと管理を担当します。
4. コンテンツ配信ネットワーク (CDN) : Azure の CDN は、世界中のコンビニエンス ストアのチェーンのようなものです。あなたがニューヨークにパン屋を持っていて、あなたのパンがとても人気で、世界中の人々がそれを食べたがっているとします。しかし、オーストラリアにいる人がパンを買いにニューヨークに来るというのは現実的ではありません。そこで、誰もが近くの店で焼きたてのパンを購入できるように、世界中に店舗をオープンすることにしました。これが Azure CDN の機能です。コンテンツ (Web サイト、ビデオ、ソフトウェアなど) を世界中のノードにキャッシュします。ユーザーがこれらのコンテンツを要求すると、アクセス速度を向上させるために最も近いノードからコンテンツを取得できます。
5. Windows Azure Connect : Azure Connect は、ローカル ネットワークと Azure の仮想ネットワークを接続するブリッジのようなものです。2 つのアイランドがあり、1 つはオンプレミス (ローカル ネットワーク)、もう 1 つはクラウド (Azure の仮想ネットワーク) にあるとします。2 つの島を簡単に移動するには、2 つの島を結ぶ橋が必要です。Azure Connect はブリッジとして、オンプレミスとクラウド ネットワーク間でデータを安全かつ簡単に転送できるようにします。

• 具体的な定義

1. コンピューティング サービス (Compute) : アプリケーションを実行するための仮想マシン (VM) を提供し、さまざまなオペレーティング システムと複数のプログラミング言語をサポートし、オンデマンドで拡張できます。
2. ストレージ サービス (ストレージ) : BLOB (オブジェクト) ストレージ、ファイル ストレージ、キュー ストレージ、テーブル ストレージ、ディスク ストレージなど、大規模で可用性の高い永続的なクラウド ストレージを提供します。
3. ファブリック コントローラー: 主にアプリケーションの展開、管理、監視に使用されます。
4. CDN (Content Delivery Network) : グローバルなコンテンツ配信ネットワーク サービスを提供し、世界中のエッジ ノードにコンテンツをキャッシュすることでユーザーがデータを取得する速度を最適化します。
5. ネットワーキング: 仮想ネットワーク、負荷分散、VPN、トラフィック管理、その他のネットワーク機能を提供して、クラウドとローカル環境の間に安全なプライベート接続を確立します。

4.2 3 つの例

Azure サービス プラットフォームでは、アプリケーションがコードを実行するために、Web ロール、ワーカー ロール、VM ロールという 3 種類のロール (ロール) が提供されます。これらのロールは、Azure サービス プラットフォーム上で実行されるアプリケーション インスタンスの動作環境を定義します。

1. Web ロール: 自動的に管理され、ホストされる IIS 環境を提供します。開発者は、ASP.NET、WCF サービス、またはその他の IIS 互換アプリケーションを Web ロールに公開して、ユーザーの HTTP/HTTPS リクエストを処理できます。
2. ワーカー ロール: 開発者があらゆる種類のプログラムを実行できる共通の Windows 環境を提供します。ワーカー ロールは、Web ロールからのデータの処理、スクリプトの実行、その他の長時間実行タスクなどのバックグラウンド処理タスクとしてよく使用されます。
3. VM ロール: より自由度の高い仮想マシン環境を提供し、ユーザーは必要に応じて VM ロールの Windows 環境をカスタマイズし、特定のタスクやサービスを実行するために必要なアプリケーションをインストールできます。

1. Web ロール: Web ロールは、ケータリングを提供するレストランのようなものです。お腹を空かせた人々に食事を提供するレストランと同様に、クライアント (ユーザー) のリクエストを受け入れて処理できます。Azure では、Web ロールは Microsoft のパブリック クラウド環境で実行されるサービスで、レストランで注文を処理するのと同じように、外部 HTTP または HTTPS リクエストを処理します。
2. ワーカー ロール: ワーカー ロールは、レストランの裏キッチンで料理を調理する責任のあるシェフのようなものです。Azure では、ワーカー ロールは、Web ロールからのデータの処理、スクリプトの実行、その他の長時間実行タスクなど、バックグラウンドで実行されるタスクを実行します。彼らはシェフのようなもので、素材（データ）をグルメ（有益な情報）に変えます。
3. VM ロール: VM ロールは賃貸アパートのようなもので、ニーズに応じて家具を装飾したり配置したりできます。Azure では、VM ロールによって仮想マシン環境が提供され、ユーザーは必要に応じてこの環境を構成し、必要なソフトウェアをインストールできます。この役割により、賃貸アパートに自由に配置できるのと同じように、ユーザーはクラウド サービス環境をより自由に定義できるようになります。

4.3 データ構造

1. Blob : 画像、オーディオ、ビデオ、ログ ファイルなどの大量の非構造化データを保存するために使用されます。
2. 表: 大量の非リレーショナル データの保存に適した、スケーラブルな非リレーショナル構造化データ ストレージを提供します。
3. Queue : アプリケーション間でメッセージを非同期に受け渡すための拡張可能なメッセージ キュー サービスを提供します。

4.4 スポークバックアップのアイデア

異なる SQL Azure データベース間の同期は、「ハブアンドスポーク」モデルを使用して行われます。

このモデルでは、セントラル ノード (ハブ) がデータの受信と配布を担当し、エッジ ノード (スポーク) がデータの保存を担当します。

ここで、ハブは SQL Azure データベースであり、他のハブは SQL Azure データベースまたは SQL Server データベースです。

このモデルを航空会社の路線ネットワークと比較できます。この例では、航空会社の大規模なハブ空港 (アトランタやアムステルダムなど) が中央ノードとして機能し、他の小規模な空港がエッジ ノードとして機能します。すべてのフライト (データ) はハブ空港 (ハブ) を通過し、さまざまな目的地 (スポーク) に配信されます。

Azure のデータセンター ネットワークでは、同様のモデルが使用されています。メイン データ センター (ハブ) は、すべてのユーザー データを受信し、そのデータを各エッジ データ センター (スポーク) に同期する責任があります。この方法では、ユーザーがどこからデータにアクセスしても、常に最も近いデータセンターからデータを取得するため、最速の応答時間が得られます。

さらに、エッジ データ センターに障害が発生した場合でも、メイン データ センターまたは他のエッジ データ センターからユーザー データを取得できるため、データの可用性と一貫性が確保されます。