web-dev-qa-db-ja.com

AmazonAWSのI / O集約型MySqlサーバー

最近、従来のデータセンターからAWSのクラウドコンピューティングに移行しました。他社との提携で製品を開発しており、発売する製品のデータベースサーバーを作成する必要があります。

アマゾンウェブサービスを過去3年間使用していますが、この非常に特殊なハードウェア構成で仕様を受け取ったのはこれが初めてです。

トレードオフがあり、実際のハードウェアは常に仮想マシンよりも高速になることを私は知っています。その事実を事前に知っているので、何をお勧めしますか？

1）Amazon EC2？ 2）Amazon RDS？ 3）他に何かありますか？ 4）赤ちゃんを忘れて、実際のハードウェアに固執する

ハードウェア要件は次のとおりです

このサーバーは、画像ホスティングの統計、メモリサイズ、ディスク容量のI/OとMySQLに重点を置いています。

サーバー1

I/Oこのサーバーの非常に主要な部分はI/O処理であり、FusionIOカードは非常に効率的であることが証明されています。これは現在可能な限り最高です。このドメインにあります。 o Fusion ioDrive2 MLC 365GB（ http://www.fusionio.com/load/-media-/1m66wu/docsLibrary/FIO_ioDrive2_Datasheet.pdf ）

[〜＃〜] cpu [〜＃〜]MySQLはApacheよりも少ないCPUコアを使用しますが、非常にハードに使用します。E7ファミリーには30Mがあります。キャッシュL3wichiはブーストパフォーマンスを提供します：o 1x IntelE7-2870は問題ありません。

ストレージSASは、特に必要なスペースを考慮すると、パフォーマンスの点で十分です。oRAID 10 of 4 x SAS 10kまたは15k、合計使用可能容量512GB。

メモリo統計データベースのサイズを考慮すると、このサーバーでは64GB以上が必要です。警告：統計データベースは急速に大きくなります。可能であれば、128GBから直接開始することを検討してください。このサーバーは、画像ホスティングの統計、メモリサイズ、ディスク容量のI/OとMySQLに重点を置いています。

サーバー2

I/Oこのサーバーの非常に主要な部分はI/O処理であり、FusionIOカードは非常に効率的であることが証明されています。これは現在可能な限り最高です。このドメインにあります。 o Fusion ioDrive2 MLC 365GB（ http://www.fusionio.com/load/-media-/1m66wu/docsLibrary/FIO_ioDrive2_Datasheet.pdf ）

[〜＃〜] cpu [〜＃〜]MySQLはApacheよりも少ないCPUコアを使用しますが、非常にハードに使用します。E7ファミリーには30Mがあります。キャッシュL3wichiはブーストパフォーマンスを提供します：o 1x IntelE7-2870は問題ありません。

ストレージSASは、特に必要なスペースを考慮すると、パフォーマンスの点で十分です。oRAID 10 of 4 x SAS 10kまたは15k、合計使用可能容量512GB。

メモリo統計データベースのサイズを考慮すると、このサーバーでは64GB以上が必要です。警告：統計データベースは急速に大きくなります。可能であれば、128GBから直接開始することを検討してください。

前もって感謝します。

ベスト、

mysqlamazon-ec2amazon-web-servicesioamazon-rds
3
rhossi

問題：

  • 上にリストした2つのサーバーは完全に同一です。
  • FusionIOについて話しますが、MySQLとApacheを同じボックスで実行することについても話します。
  • ApacheファイルまたはMySQLデータベース（または_ib_logfile_などのその一部）がFusionIOドライブにあるかどうかについては言及していません。

誤解：

「実際のハードウェアは常に仮想マシンよりも高速である」というのは必ずしも真実ではありません。確かに同じハードウェアで同じアプリケーションが仮想マシンにない方がパフォーマンスが向上しますが、Amazonのハードウェアにアクセスできないため、その比較は重要ではありません。

クラウドのポイントは水平方向に拡張できるため、1台のサーバーで100人の同時訪問者にサービスを提供できれば、10台のサーバーで1000人の同時訪問者にサービスを提供でき、各訪問者は、いくつ持っていても同じ応答速度を受け取ります。 。

クラウド：

コロケーションと比較して、クラウドプロバイダーにはいくつかの重要な違いがあります。あなたがそれらを利用することができれば、それらはクラウドでのホスティングを明らかに勝者にするでしょう。

  1. インスタンスを非常にすばやくスピンアップおよびスピンダウンできます。トラフィックが非常にバーストしている場合（たとえば、チケット販売ウェブサイトを運営する）すると、ジャスティンビーバーのチケットが発売される1時間前に、ウェブ層、データベース層、ストレージ層を数百台の仮想マシンに簡単に複製し、1時間後にすべてシャットダウンして節約できます。お金。ハードウェアベースのソリューションは、通常、容量を増やすのに数週間かかり、十分に活用されていない場合でもコストがかかり続けます。
  2. 初期費用ははるかに低くなる可能性があります。あなたが言及するハードウェアは、他のホスティング費用に加えて、おそらく数万ドルの費用がかかります。私のAmazonサーバーのコストは月額約15ドルですが、それでも、はるかに強力な仮想マシンに簡単にスケールアップして、数時間の通知で負荷分散された数十のインスタンスにスケールアウトできました。
  3. 彼らはあなたのために多くの仕事をします。Amazonには、あなたが与えたワークロードまたはストレージ要件に自動的にスケールアウトまたはインするDynamoDBなどの他のサービスがあります。これらは速度を上げるためにSSDで実行され、複数の場所に複製されて冗長性と可用性を提供します。

とはいえ、アプリケーションは水平方向にスケーリングできる必要があります。単にクラウドに投入して、永遠に拡張できると期待することはできません。たとえば、デフォルトのPHPセッションには2つの問題があります。

  1. これらはローカルディスクに保存されるため、スティッキーセッションまたは共有ディスクを使用する必要があります。これがボトルネックになります。
  2. それらは、排他的なブロッキングファイルロックであるflock()で開かれます。一度に1つのPHPプロセスのみがセッションファイルを使用できます。これは、大量のAJAX呼び出しを開始するときに、深刻な問題になる可能性があります。

これは1つの例にすぎませんが、水平スケーリングを念頭に置いて作成されていないアプリケーションは、通常、そのような排他的なリソースでいっぱいです。

分散データベース（Amazonのデータベースサービス）を実行している場合、アプリは[〜＃〜]に固有のトレードオフにも対処できる必要があります。 cap [〜＃〜]定理。これは、一貫性、可用性、パーティション許容度の3つの側面のうちの2つを取得できることを示しています。あなたはあなたが持っていない3つのうちのどれを知っている必要があり、あなたのアプリにそれを補償させる必要があります。

アプリケーションがハードウェアに適している場合は、ハードウェアを選択してください。クラウドに適している場合は、クラウドを選択してください。

注：ここでは例としてAmazonを使用しましたが、インスタンスを非常にすばやくスピンアップおよびスピンダウンし、実際に使用したものに対してのみ課金する同様の機能を備えた他のクラウドホスティングプロバイダーがあります。

2
Ladadadada

クラウドソリューションから最大のパフォーマンスを得るには、クラウド向けに設計する必要があります。完全にスケーラブル（アップとダウンの両方）に設計されたサービスから取得できるIOPSの数が心配な場合は、クラウドコンピューティングではなく仮想マシンについて考えています。利用可能なIOPSの量に関しては、 EBSに関するこの記事 考慮すべき問題について説明していると思います

3
Jim B

言及されていないもう1つのポイントは、将来的にデータベースの容量を拡張できることです。ハードウェア要件は静的ではなく、アプリケーションの成長に伴って時間とともに変化します。 @rhossi、ハードウェアオプションごとに、将来のスケーラビリティパスを検討する必要があります。簡単に説明すると、（1）Amazon EC2の場合、スケールアップするには、より大きなインスタンスにアップグレードできます[簡単]。スケールアウトするには、追加のインスタンスにMySQLをインストールし、それらの間のクラスタリングを定義する必要があります[ハード、最適ではないネットワークパフォーマンス特別なクラスターインスタンスをリクエストしない限り]。 （2）Amazon RDSの場合、スケールアップするには、同じ[簡単]、スケールアウトするには、RDSインスタンスを追加し、クラスタリングを定義します[ハード]。 （3）他の何か-Xeroundの クラウドデータベース 自動スケーリングがあり、クラスタリングを必要としないEC2のソリューションを調べるかもしれませんが、ストレージ容量に制限があるため、適切ではない可能性があります。自動スケーリングを提供する追加のオプションがあるかもしれません、そして私は調査するのが良いと思います。 （4）実際のハードウェア-スケールアップにはハードウェアを手動でアップグレードする必要があり[小さな手間+初期費用]、スケールアウトにはより多くのマシンと手動でクラスタリングを定義する必要があります[中程度のハード]が、IPはクラウド上よりも簡単に実現できます。静的で、ネットワークパフォーマンスが向上します。 HTH

0
Lena Weber