sql >> データベース >  >> RDS >> MariaDB

Galera Cluster Cloudオファリングの比較:パート2 Google Cloud Platform(GCP)

    前回のブログでは、MySQL GaleraClusterを実行しているときにアマゾンウェブサービス(AWS)内で利用できるサービスについて説明しました。このブログでは、同じクラスタリングテクノロジーを実行するためのサービスについてさらに詳しく見ていきますが、今回はGoogle Cloud Platform(GCP)で説明します。

    AWSの代替としてのGCPは、さまざまなフルスタックテクノロジー、コンテナ化されたアプリケーション、大規模な本番データベースシステムのサポートを提供することで、DevOpsに適したアプリケーションを継続的に引き付けてきました。 Google Cloudは、YouTubeやGmailなどの製品向けにGoogleの独自のハードウェアインフラストラクチャを強化する、本格的な戦闘テスト済みの環境です。

    GCPは、機能のリストが増え続けていることが主な理由で注目を集めています。 Visual Studio、Android Studio、Eclipse、Powershellなどのプラットフォームをサポートします。 GCPは、最大かつ最先端のコンピュータネットワークの1つであり、アプリケーションの構築に集中するのに役立つ多数のツールへのアクセスを提供します。

    Google Cloudを移行、インポート、または使用するように顧客を引き付けるもう1つの点は、コンテナ化に対する強力なサポートとソリューションです。 Kubernetes(GKE:Google Kubernetes Engine)はプラットフォーム上に構築されています。

    GCPは最近、Anthosと呼ばれる新しいソリューションもリリースしました。この製品は、組織がGoogle Cloud Platform(GCP)またはオンプレミスでGKE On-Premを使用して、さらにはアマゾンウェブサービス(AWS)やAzureなどのライバルクラウドでも同じインターフェースを使用してワークロードを管理できるように設計されています。

    これらのテクノロジーに加えて、GCPは、最新世代のIntelスケーラブルプロセッサ(Cascade Lake)上に構築されたGCEのC2ファミリのような、洗練された強力なコンピューティング最適化マシンタイプを提供します。

    GCPは引き続きオープンソースをサポートしています。これは、適切にサポートされたわかりやすいフレームワークを提供することでユーザーにメリットをもたらし、最終製品をタイムリーに簡単に提供できるようにします。このオープンソーステクノロジーのサポートにもかかわらず、GCPはMySQLGaleraClusterのデプロイまたは構成をネイティブでサポートしていません。このブログでは、このテクノロジーを使用する場合に利用できる唯一のオプションである、自分で管理する必要のあるコンピューティングインスタンスを介した展開について説明します。

    Google Compute Engine(GCE)

    GCEには、消費に利用できる洗練された強力な計算ノードのセットがあります。 AWSとは異なり、GCEには市場で入手可能な最も強力なコンピューティングノードがあります(160vCPUと3.75TBのメモリを備えたn1-ultramem-160)。 GCEは最近、C2マシンタイプと呼ばれる新しいタイプのコンピューティングインスタンスファミリも導入しました。最新世代のIntelスケーラブルプロセッサ(Cascade Lake)上に構築されたC2マシンタイプは、最大3.8 GHzの持続的なオールコアターボを提供し、基盤となるサーバープラットフォームのアーキテクチャに完全な透過性を提供します。パフォーマンスを微調整できます。 C2マシンタイプは、はるかに多くのコンピューティング能力を提供し、新しいプラットフォームで実行され、一般に、N1ハイCPUマシンタイプよりも計算集約型のワークロードに対してより堅牢です。 C2ファミリーの提供は(執筆時点で)制限されており、すべての地域とゾーンで利用できるわけではありません。 C2は、地域の永続ディスクもサポートしていませんが、冗長性と高可用性を必要とするステートフルデータベースサービスの優れたアドオンになります。 C2インスタンスのリソースはGaleraノードには多すぎるため、代わりに計算ノードに焦点を当てます。これは理想的です。

    GCEも仮想化テクノロジーソフトウェアとしてKVMを使用していますが、AmazonはXenを使用しています。 GCEで利用可能なコンピューティングノードを見てみましょう。これらは、AWSEC2での同等性と一緒にGaleraを実行するのに適しています。料金は地域によって異なりますが、このグラフでは、AWSのオンデマンド料金タイプを使用した東部地域を使用しています。

    マシン/インスタンスタイプ

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

    AWS EC2

    共有

    f1-micro

    G1-小さい

    料金は1時間あたり$0.006-$0.019から

    t2.nano – t3.2xlarge'

    価格は1時間あたり$0.0058〜$0.3328から

    標準

    n1-standard-1 – n1-standard-96

    料金は0.034ドルから​​-1時間あたり3.193ドル

    m4.large – m4.16xlarge

    m5.large – m5d.metal

    料金は1時間あたり$0.1〜$5.424から

    高メモリ/メモリ最適化

    n1-highmem-2 – n1-highmem-96

    n1-megamem-96

    n1-ultramem-40 – n1-ultramem-160

    料金は0.083ドルから-1時間あたり17.651ドル

    r4.large – r4.16xlarge

    x1.16xlarge – x1.32xlarge

    x1e.xlarge – x1e.32xlarge

    料金は1時間あたり$0.133〜$26.688から

    高CPU/ストレージ最適化

    n1-highcpu-2 – n1-highcpu-32

    価格は1時間あたり$0.05〜$2.383から

    h1.2xlarge – h1.16xlarge

    i3.large – i3.metal

    I3en.large --i3en.metal

    d2.xlarge – d2.8xlarge

    料金は1時間あたり$0.156〜$10.848から

    GCEには、AWSとは異なり、選択できる事前定義されたタイプのコンピューティングノードの数が少なくなっています。ただし、ノードのタイプに関しては、より細分性があります。これにより、使用するインスタンスの種類を簡単に設定および選択できます。たとえば、ディスクを追加してその物理ブロックサイズ(デフォルトは4)を16に設定したり、モードを読み取り/書き込みまたは読み取り専用に設定したりできます。これにより、Galeraノードを管理する準備ができた適切なタイプのマシンまたはコンピューティングインスタンスを提供できます。また、Cloud SDKを使用して、またはCloud APIを使用してコンピューティングノードをインスタンス化し、継続的インテグレーション、デリバリー、またはデプロイメント(CI / CD)に自動化または統合することもできます。

    料金(コンピューティングインスタンス、ディスク、vCPU、メモリ、ネットワーク)

    価格は、その場所の地域、OSまたはライセンスの種類(RHELとSuse Linux Enterprise)、および使用しているディスクストレージの種類によっても異なります。

    GCPは、リソース消費を節約できる割引も提供しています。 Compute Engineの場合、さまざまな割引が利用できます。

    継続使用割引は、次のリソースに適用されます。

    • 汎用のカスタムおよび事前定義されたマシンタイプ用のvCPUとメモリ

    • メモリ最適化マシンタイプのvCPUとメモリ

    • コンピューティングに最適化されたマシンタイプのvCPUとメモリ

    • ソールテナントノードのvCPUとメモリ

    • 単一テナントノードの10%のプレミアムコスト(これらのノードのvCPUとメモリがコミットされた使用割引でカバーされている場合でも)

    • GPUデバイス1

    AppEngineフレキシブル環境とCloudDataflowを使用して作成されたVMには、継続使用割引は適用されないことに注意してください。

    契約に拘束されているVMSを購入するときに、確約使用割引を使用することもできます。このタイプの選択は、予測可能なワークロードとリソースのニーズに最適です。確約使用契約を購入すると、1年または3年間のリソースの支払いを確約する見返りとして、一定量のvCPU、メモリ、GPU、およびローカルSSDを割引価格で購入します。マシンタイプやGPUなどのほとんどのリソースの割引は最大57%です。メモリが最適化されたマシンタイプの場合、割引は最大70%です。購入すると、選択した期間中(サービスを使用するかどうかに関係なく)購入したリソースに対して毎月請求されます。

    プリエンプティブVMは、通常のインスタンスよりもはるかに低価格で作成および実行できるインスタンスです。ただし、Compute Engineは、他のタスクのためにこれらのリソースへのアクセスが必要な場合、これらのインスタンスを終了(プリエンプト)することがあります。プリエンプティブインスタンスは過剰なComputeEngine容量を使用するため、その可用性は使用状況によって異なります。

    アプリケーションがフォールトトレラントであり、インスタンスのプリエンプションの可能性に耐えられる場合、プリエンプティブインスタンスはコンピューティングエンジンのコストを大幅に削減できます。たとえば、バッチ処理ジョブはプリエンプティブインスタンスで実行できます。これらのインスタンスの一部が処理中に終了した場合、ジョブは遅くなりますが、完全には停止しません。プリエンプティブインスタンスは、既存のインスタンスに追加のワークロードをかけることなく、また追加の通常のインスタンスに全額を支払う必要なしに、バッチ処理タスクを完了します。

    Compute Engineの場合、ディスクサイズ、マシンタイプのメモリ、およびネットワーク使用量はギガバイト(GB)で計算されます。ここで、1GBは230バイトです。この測定単位は、ギビバイト(GiB)とも呼ばれます。つまり、GCPでは、割り当てたリソース消費量に基づいてのみ料金を支払うことができます。

    これで、高品質の本番データベースアプリケーションを使用している場合は、別の永続ディスクを接続または追加することをお勧めします(理想的です)。次に、そのディスクをデータベースボリュームとして使用します。これは、GCEで信頼性が高く一貫したディスクパフォ​​ーマンスを提供するためです。設定するサイズが大きいほど、提供されるIOPSは高くなります。永続ディスクの価格のリストをチェックして、取得する価格を決定してください。これに加えて、GCEには、データベースクラスター内でより堅牢で持続可能な高可用性が必要な場合に適したリージョナル永続ディスクがあります。リージョナル永続ディスクは、インスタンスが終了、クラッシュ、または破損した場合に備えて、冗長性を追加します。これは、VMインスタンスで透過的に行われる1つのリージョン内の2つのゾーン間のデータの同期レプリケーションを提供します。万が一ゾーンに障害が発生した場合、ワークロードは同じゾーンまたはセカンダリゾーンにある別のVMインスタンスにフェイルオーバーできます。次に、リージョナル永続ディスクをそのインスタンスに強制的に接続できます。強制取り付け時間は1分未満で見積もられます。

    ディザスタリカバリソリューションの一部としてバックアップを保存し、クラスタ全体のボリュームが必要な場合、GCPはCloud Filestore、NetApp Cloud Volumes、およびその他の代替ファイル共有ソリューションを提供します。これらは、標準サービスとプレミアムサービスを提供するフルマネージドサービスです。 NetAppの価格設定ページはこちらで、Filestoreの価格設定はこちらで確認できます。

    GCPでのGalera暗号化

    GCPには、Galeraで利用可能な暗号化の種類に対する特定のサポートは含まれていません。ただし、GCPはデフォルトで保存されている顧客データを暗号化し、追加の操作は必要ありません。 GCPには、Cloud KMSおよび顧客提供の暗号化キー(CSEK)で顧客管理の暗号化キー(CMEK)を使用してデータを暗号化する別のオプションも用意されています。 GCPは、サイトとクラウドプロバイダー間、または2つのサービス間でデータが移動するときに傍受されるすべての通信にSSL/TLS暗号化も使用します。この保護は、送信前にデータを暗号化することによって実現されます。エンドポイントの認証。到着時にデータを復号化して検証します。

    Galeraは内部でMySQLを使用しているため(Percona、MariaDB、またはCodershipビルド)、MariaDBまたはMySQLKeyringプラグインを使用してファイルキー管理暗号化プラグインを利用できます。これは、これを実装する方法に関する優れたリソースであるPerconaによる外部ブログです。

    GCPを使用したGaleraClusterMulti-AZ / Multi-Region / Multi-Cloud Deployments

    AWSと同様に、GCPはGaleraクラスターをMulti-AZ / -Region/-Cloudにデプロイするための直接サポートを提供していません。

    GCPでのGaleraClusterの高可用性、スケーラビリティ、冗長性

    Galeraノードクラスターを使用する主な理由の1つは、高可用性、冗長性、および拡張性です。グローバルにトラフィックを処理している場合は、データベースノードの地理分布を含むアーキテクチャ設計を使用して、地域ごとにトラフィックを処理するのが最適です。これを実現するには、マルチAZおよびマルチリージョンまたはマルチクラウド/マルチデータセンターの導入が推奨され、実現可能です。これにより、クォーラムの不足によるクラスターのダウンやクラスターの誤動作を防ぐことができます。

    スケーラビリティの設計をさらに支援するために、GCPには自動スケーリンググループで設定できる自動スケーラもあります。これは、クラスターをマネージドインスタンスグループとして作成した場合に機能します。たとえば、CPU使用率を監視したり、自動スケーリングポリシーで定義されたStackdriverのメトリックに依存したりできます。これにより、特定のしきい値に達したときにインスタンスをプロビジョニングして自動化したり、通常の状態に戻ったときにインスタンスを終了したりできます。

    マルチリージョンまたはマルチクラウド展開の場合、Galeraにはgmcast.segmentと呼ばれる独自のパラメーターがあり、サーバーの起動時にこれを設定できます。このパラメータは、Galeraノード間の通信を最適化し、ネットワークセグメント間で送信されるトラフィックの量を最小限に抑えるように設計されています。これには、ライトセットリレーとISTおよびSSTドナーの選択が含まれます。このタイプのセットアップでは、異なるリージョンに複数のノードをデプロイできます。それとは別に、GaleraノードをGCP、AWS、Microsoft Azureからルーティングする別のクラウドベンダーにデプロイすることも、オンプレミス内にデプロイすることもできます。

    これらのタイプの実装方法の詳細については、ブログ「MySQLまたはMariaDB用のGaleraクラスターを使用した複数のデータセンターのセットアップ」および「リレーノードを使用したMySQLガレラクラスターによるダウンタイムゼロのネットワーク移行」を確認することをお勧めします。展開。

    GCPでのGaleraClusterデータベースのパフォーマンス

    GCPではGaleraのサポートが利用できないため、アプリケーションのトラフィックとリソースの需要の要件と設計に応じて選択できます。メモリ消費量が多いクエリの場合は、n1-highmem-2インスタンスから始めることができます。高CPUインスタンス(n1-highcpu *ファミリ)は、これが高トランザクションデータベースである場合、またはゲームアプリケーションに適している場合に適しています。

    データベースボリュームに適切なストレージと必要なIOPSを選択する必要があります。通常、ここではSSDベースの永続ディスクを選択します。必要なトラフィックの量によって異なりますが、アプリケーションに適したサイズを決定できるように、GCPストレージオプションをチェックアウトする必要がある場合があります。

    また、Galera Clusterの最適化の詳細については、ブログ「MySQLまたはMariaDBのGaleraClusterのパフォーマンスを向上させる方法」を確認して読むことをお勧めします。

    GCPでのGaleraデータのバックアップ

    MySQL Galeraデータをバックアップする必要があるだけでなく、データベースアプリケーションを構成する層全体もバックアップする必要があります。これには、ログファイル(論理またはバイナリ)、外部ファイル、一時ファイル、ダンプファイルなどが含まれます。GCEインスタンスで使用されている永続ディスクボリュームのスナップショットを常に作成することをお勧めします。スナップショットを簡単に作成してスケジュールできます。 GCPスナップショットはCloudStorageに保存され、バックアップを配置する場所または地域を選択できます。スナップショットのスケジュールを設定したり、スナップショットの保持ポリシーを設定したりすることもできます。

    ClusterControlなどの外部サービスを使用することもできます。これは、監視ソリューションとバックアップソリューションの両方を提供します。詳細を知りたい場合は、こちらをご覧ください。

    GCPでのGaleraClusterデータベースの監視

    GCEを使用する場合、GCPはデータベースモニタリングを提供しません。インスタンスの状態の監視は、Stackdriverを介して実行できます。ただし、データベースの場合は、高度で高度なデータベースメトリックを備えた外部監視ツールを入手する必要があります。 PerconaによるPMM、DataDog、Idera、VividCortex、または独自のClusterControl(ClusterControl Communityではモニタリングは無料です)など、選択できる選択肢はたくさんあります。

    GCPでのGaleraClusterデータベースのセキュリティ

    以前のブログで説明したように、パブリッククラウドでデータベースを保護するために同じアプローチを取ることができます。 GCPでは、プライベートサブネット、ファイアウォールルールを設定して、Galeraの実行に必要なポート(特にポート3306、4444、4567、4568)のみを許可できます。 NATゲートウェイを使用するか、要塞ホストを設定してプライベートデータベースノードにアクセスできます。これらのノードがカプセル化されている場合、GCP構内の外部からアクセスすることはできません。これを設定する方法については、以前のブログ「AWSおよびVPNを使用したGCPでのセキュアマルチクラウドMySQLレプリケーションのデプロイ」をご覧ください。

    これに加えて、TLS / SSL接続を使用するか、データが保存されているときにデータを暗号化することで、転送中のデータを保護できます。 ClusterControlを使用している場合、転送中の安全なデータのデプロイはシンプルで簡単です。試してみたい場合は、ブログSSL Key Management and Encryption of MySQL DatainTransitをチェックしてください。保存データについては、このブログの暗号化セクションで前述した説明に従うことができます。

    ガレラクラスターのトラブルシューティング

    GCPは、可観測性、監視、通知の要件を支援するために活用できるStackdriverLoggingを提供します。 Stackdriver Loggingの優れている点は、AWSとの統合を提供することです。これを使用すると、イベントを選択的にキャッチし、そのイベントに基づいてアラートを発行できます。これにより、発生する可能性のある特定の問題を常に把握し、トラブルシューティングに役立てることができます。 GCPにはCloudAuditLogsもあり、管理者アクティビティ、データアクセス、システムイベントなど、GCP環境内からより追跡可能な情報を提供します。

    ClusterControlを使用している場合は、[ログ]-> [システムログ]に移動すると、MySQLGaleraノード自体から取得したキャプチャされたエラーログを参照できます。これとは別に、ClusterControlは、緊急時やMySQLGaleraノードが故障した場合にアラームと通知システムを増幅するリアルタイムの監視を提供します。

    結論

    Google Cloud Platformは、活用できるさまざまな効率的で強力なサービスを提供します。パブリッククラウドプラットフォームにはそれぞれ長所と短所がありますが、GCPはAWSがクラウドをロックしていないことを証明しています。

    Vimeoなどの大企業がオンプレミスからGCPに移行し、テクノロジースタックでいくつかの興味深い結果を経験したことは興味深いことです。 BloombergもGCPに満足しており、Percona XtraDB Cluster(Galeraバリアント)を使用しています。以下のコメントで、MySQLGaleraのセットアップにGCPを使用することについてのご意見をお聞かせください。


    1. 1つのテーブルから選択し、別のテーブルに挿入しますoraclesqlクエリ

    2. SQL Server DATEPART()とDATENAME()–違いは何ですか?

    3. PostgreSQL-GROUPBY句または集計関数で使用

    4. SQLiteは14のエラーコードを返しました