Amazonサーバーとクラウドのパフォーマンス比較

今日、開発者はデータベースのない負荷の高いシステムを想像することはできません。 情報を保存するこの方法はカルトになります。 私たちは毎日データベースを操作することに慣れていますが、まだ暗い点があります。 それらの1つはパフォーマンスです。 データベースのチューニング、最適化などについて多くの記事が書かれています。 データベース（DB）が既にあり、そのパフォーマンスが十分でない場合に役立ちます。 ただし、AWS、Azure、Rackspaceなどのクラウドサービスでデータベースを実行する必要がある場合、これらの記事は役に立ちません。



これらの質問のいくつかは、これについて多くのことを私に尋ねたので、一部の人には馴染みがあると確信しています。

• AWSまたは通常のIronサーバーを使用する必要がありますか？
• Amazonで選択するサーバーのタイプは何ですか？
• Amazon RDSまたはEC2データベースに使用しますか？
• Amazon専用またはオンデマンドから選択しますか？
• 各タイプのサーバーが処理できるトランザクションの数はいくつですか？

この記事の目的は、これらの問題を解決することです。 もちろん、それらへの直接の答えはありません;それは「依存する...」という言葉で始まります。 しかし、私の分析があなたが正しい決断を下すのにまだ役立つことを願っています。

テスト環境

リングの左隅には、以下の仕様の驚くべき専用HP DL380 G9アイロンサーバーがあります。

CPU: 16 cores (Dual Socket Octo Core Intel Xeon E5–2630v3 2.4GHz, #Processors: 2, #Cores per Proc: 8) RAM: 128 GB DISKS: 500 GB RAID 5 SSD
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リングの右隅には、EC2とRDSの2つのAmazonサービスがあります。 Ironサーバーと同じ特性を実現するために、DB1（メモリ最適化）とDB2（計算最適化）の2つのデータベースインスタンスを使用します。 仕様は次のとおりです。



DB1：

 r3.4xlarge (memory optimized) 16 cores 122 GB RAM 320 GB SSD Instance Storage
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DB2：

 c3.8xlarge 32 cores 60 GB RAM 750 GB io1 EBS 7500 IOPS
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、さまざまなタイプのリースを使用してインスタンスをテストします。専用およびオンデマンドに加えて、デフォルトで含まれていないインスタンス（r3.4xlargeなど）のEBS最適化を行います。



注意してください：

• RDSまたはEC2サービスを調整しませんでした。標準構成のみを使用しました
• 結果は、アベイラビリティーゾーン（AWS）および地域によって異なる場合があります。
• Ironサーバーとは異なり、AmazonにはHVM仮想化のオーバーヘッドがあります

試験条件

• EC2およびIronサーバーのオペレーティングシステム：Ubuntu 14.04 LTS x64
• EC2インスタンスタイプ：r3.4xlargeおよびc3.8xlarge
• RDSインスタンスのタイプ：db.r3.4xlargeおよびdb.m4.10xlarge（db.c3.8xlargeはRDSでは使用できないため、より高いレベルのインスタンスに置き換えました）
• ボリューム：DB1の場合は320 GB SSD、DB2の場合は750 GB IO1 7500 IOPS
• MariaDBエンジン：10.0.17
• SysBenchバージョン：0.4.2
• SysBenchテスト：OLTP複合テスト
• SysBenchを起動するコマンド：
  
  

   sysbench --db-driver=mysql --num-threads=$THREADS --max-requests=0 --test=oltp --mysql-table-engine=innodb --oltp-table-size=2000000 --max-time=60 --mysql-engine-trx=yes --mysql-user=$USER --mysql-password=$PASSWORD --mysql-host=$HOST run
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• 接続の最大数（my.cnf構成ファイル）：300
• スレッド：1〜256
• sysbenchを実行するためのホスト：EC2のlocalhost、RDSの-同じ可用性ゾーン内
• 結果：SysBenchテストの結果に応じた1秒あたりのトランザクション数
• SysBenchテストは、他のテストから分離して実施されます。

AWSベストプラクティス

テストに進む前に、Amazonの推奨事項を紹介します。 2015年、同社はEC2およびRDSでのリレーショナルデータベースの立ち上げに関する詳細なホワイトペーパーをリリースしました。 完全なドキュメントはこちらにあります 。



ドキュメントからの簡単な抜粋を次に示します。



最初にAmazon RDSを検討することをお勧めします。 次の場合、これが最良の選択です。

• パフォーマンスの調整、回路の最適化など、高レベルのタスクに集中します。 Amazonは、データベースの提供、バックアップとリカバリの管理、セキュリティパッチ、SQL Server（RDBMS）バージョンのアップグレード、ストレージの管理を期待しています。
  
  
  
  
• 可用性の高いデータベースソリューションを探しており、ボタンをクリックするだけで、データベースミラーリング、フェールオーバークラスタリング、またはAlwaysOn可用性グループを手動で構成および保守する必要なく、マルチAZ同期レプリケーションを使用したい。
  
  
  
  
• バックアップを管理したくない、そして最も重要なことには、データベースを特定の時点に復元したくない-AWSがこのプロセスを自動化することを好む。

次の場合は、 EC2で SQL Serverを実行することをお勧めします。

• オペレーティングシステムやソフトウェアスタックへのアクセスなど、データベースインスタンスを完全に制御する必要があります。
• 独自の管理者に、バックアップ、レプリケーション、クラスタリングなどのデータベースを管理してもらいたい。
• データベースのサイズとパフォーマンスは、現在のAmazon RDSの最大値またはその他の制限を超えています。
• Amazon RDSがサポートしていないSQL Server機能またはオプションを使用します。
• AWSでSQL Serverをソースとして使用する場合、災害復旧ソリューションを構成します。
• Amazon RDSでサポートされていないバージョンのSQL Serverを使用する必要があります（たとえば、執筆時点ではサポートされていない2014のバージョン）。

結果

先ほど言ったように、リングには2人の戦闘機がいるので、結果としてAWSに対して鉄のサーバーを取得します。 いくつかのAmazonサービスを使用するため、いくつかのテストがあります。

• EC2およびDB1ベースのRDSとIron Server
• DB2ベースのEC2およびRDSとIron Server

結果は非常に興味深いので、分析してみましょう。

• 両方のEC2サーバーの値は非常に似ており、16スレッドまで直線的に増加します。その後、スレッド数を増やしても停止し、ほぼ同じレベルに留まります。
  
  EBS最適化により、スレッドが増えると1秒あたりのトランザクション数がわずかに増加します。
  
  
  
  
• 専用インスタンスは、パフォーマンスにはほとんど影響しません。 選択されたインスタンスとオンデマンドインスタンスの結果は非常に似ており、違いは文字通り2〜3％です。 つまり、専用インスタンスはデータベースを高速化しませんが、データセキュリティを提供します。 ホストハードウェアレベルで他のユーザーのインスタンスから分離されているため。
  
  
  
  
• コンピューティング最適化インスタンスは、EC2とRDSの両方のテストで、メモリ最適化インスタンスよりもわずかに低いパフォーマンスを示します。
  
  
  
  
• スレッド数の少ないRDSは、EC2や鉄サーバーよりも若干悪い動作をします。このギャップは最大16スレッドまで続きます。 16スレッドから開始して、RDSのパフォーマンスはEC2から大幅に向上して急速に成長しています。 256スレッドでは、RDSの値は3倍になります。
  
  
  
  
• Ironサーバーは、少ないストリームで良好な結果を示し、128ストリームから始まるRDSを再生します。
  
  
  
  
• Ironサーバーは、32スレッドで最高の結果を示しますが、レートが高くなると、値は減少します。

おわりに

上記のグラフからわかるように、EC2インスタンスは、膨大な数の接続がある負荷の高いシステムではうまく機能しません。 したがって、「データベースにAmazon RDSまたはEC2を使用しますか？」という質問には、「…に依存する」と答える必要があります。 膨大な数の接続を持つ負荷の高いデータベースを使用している場合は、間違いなくRDSを選択する必要があります。 鉄のサーバーと比較すると、スレッド数が少ないにもかかわらず、良い結果を示しています。 ただし、1対のスレーブノードでクラスターシステムを使用し、スレッド数が16未満の場合は、EC2を選択します。このサービスは、スレッド数が少ない方が少しうまく機能します。

「AWSを使用するか、データベースにアイロンサーバーを使用するか」という質問に対して、「...に依存します」と答えます。

	アイロンサーバー 物理専用サーバー	IaaSクラウド パブリッククラウドの仮想マシン
P l y と s	激しいワークロードに適しています サーバーへのフルアクセス、「騒々しい隣人」なし 安定した性能 コンテナは仮想化を必要としません	さまざまな負荷に適しています 仮想マシンの高速回転 バックアップ、テスト用の優れた管理ツール 安く さまざまなVMサイズにより、特定のジョブに適切なサイズを選択できます
M そして n で と s	より高価 それほど柔軟ではなく、向きを変えるのに時間がかかる それほどクールな管理ツールではありません（バックアップ用のマシン全体のイメージはありません） ほとんどのワークロードにはリソースが多すぎる	不安定なパフォーマンス、「ノイズの多い隣人」の問題は可能です リソース共有のセキュリティ問題

Amazonによると、専用インスタンスは主にデータセキュリティを提供します。 さまざまな地域のテスト結果は変動しています-文字通り2〜3％異なります。 これは主に地域の負荷に依存し、その結果、スケジュールの相違に依存します。 データベースの速度を上げる方法として、専用インスタンスを検討しません。



はい、「Amazonでどの種類のサーバーを選択すればよいですか？」という質問に答えることは依然として困難です。 ただし、RDSで高負荷システムのデータベースを実行することをお勧めします。 それでもEC2を使用する場合は、EBS最適化を備えたメモリ最適化インスタンスが最適です。