y2blog » さくらVPSとConoHa VPS

10

21

2017

さくらVPSとConoHa VPS

ConoHaとさくらのVPS性能を簡単に比較してみた


このサイトのホスティングサーバ をこれまで使っていたさくらインターネットのVPSからConoHa VPSに変更した事については先の記事で簡単に紹介したが、両者の性能やネットワークレスポンスなどを簡単に紹介しておく.但し、両者の比較条件は必ずしも同じ条件ではないので、あくまでも傾向を知る程度の比較結果であることを留意しておいて欲しい.

このサイトは現在ConoHa VPSで運用されているが、さくらVPSの契約が今月末までは残っているので、ほぼ完全なミラーサイトをさくらVPS上に作成した.両者の環境はほぼ同じ(2 vCPU Core, 1GB Mem, SSD 30/50GB)で値段も月額1,000円程度ということなので、同じクラスのVPSサービスと言って良いだろう.


・テスト環境


OS: CentOS7.4
HTTPサーバ: Apache 2.4
PHP: 5.6 (+OPCache+APCu)
DB: Maria DB (InnoDB Engine)

HTTPレスポンス比較 [ Apache Bench (localhost) ]


HTTPレスポンスはネットワーク環境に大きく依存するので、VPSの性能を比較するという意味でlocalhost上でApache Benchを使ってHTTPサーバの性能を比較してみた.


両者のOS環境やアプリケーション環境を100%厳密に合わせることはできないが、HTTPアプリケーション実行環境ほぼ同じと言って良いだろう.今回のテスト環境は @IT の”とにかく速いWordPress” の記事を参考に多少のチューニングが施されているので、アプリケーションをインストールしただけの素の環境では無いことに留意して欲しい.


ConoHa VPS [ Tokyo リージョン ]

さくら VPS [ Tokyo リージョン ]

このベンチマークの数値だけ見る限り、さくらVPSの方がHTTPアプリケーションの実行速度が速いが、ConoHa VPSは実運用環境でさくらVPSはテスト環境なので、実際に外部からのアクセス来るConoHa VPSは多少条件が悪い.さくらのVPSは2年前に契約した仮想環境なので仮想環境自体は古いかもしれない.仮想基盤が途中で更新されていたり、同一ホストでの他ユーザのVPSの運用の影響も受けるので、単純なVPS性能の比較結果ではない.


HTTPレスポンス比較 [ インターネット接続環境 ]


HTTPサーバ自体の性能比較に続いて、実際に外部からWEBブラウザ経由でアクセスしたときのネットワーク環境も含めたレスポンスについても比較してみた.Apache Benchはサーバに負荷が掛かり過ぎて使う訳には行かないので、smokeping を使って我が家のネットワーク環境からConoHaとさくらの両環境にHTTPアクセスを行い、HTTPレスポンスを計測してみた.尚、今回は WordPressのトップディレクトリ ( http://y2web.net/blog/)ではなく、HTTPサーバのトップディレクトリ(http://y2web.net/)で計測している.



ConoHa VPS
Conoha VPS HTTP Latency
ConoHa VPSのHTTPレスポンス


さくら VPS
Sakura VPS HTTP Latency
さくらVPSのHTTPレスポンス

Smokepingによるインターネット接続環境下でのHTTPレスポンスの実測結果では、さくらのVPSの方が安定したHTTPレスポンスを返しているようだ.Conohaの方は午前4時くらいから日中帯のレスポンスが悪化する傾向が見られる.単純に比較する事はできないが、さくらのVPSの方がインターネット接続環境が安定しているようだ.


どっちが良い?


現時点で、ConoHa VPSとさくらVPSの優劣を判定するような事はできないが、運用を含めた安定性を求めるならさくらVPSの方が良い意味で枯れて安定していると言えそうだ.両者共に極端な性能差は無さそうなので、後はサービスの利便性と安定性などを考慮して決める事になるではないかと思う.


安定性を求めるならさくらVPS、クラウドライクな機能性を求めるならConoHa VPSということだろうか.



【追記: 10/31 2017 】ConoHa VPSサーバのお引越し計画


このブログのサーバを稼働させているConoHaのVPS環境は今のところ大きな支障は出ていないが、どうもハズレVPSだったようで、同一仮想基盤に同居している他テナントの影響をもろに受けてしまっていると思われる.このような場合は、現行サーバを一旦停止させイメージバックアップを取り、そのイメージバックアップから新たなVPSサーバを興して、そちらに切り替えれば良さそうな気がするがどうだろう?



Another VPS's HTTP Latency
別なConoHa VPSのHTTPレスポンス(ConoHa IDも別アカウント)


仮想基盤側のホストサーバが期待通り別な物理サーバ環境に切り替われば良いが、前と同じホストサーバだったらわざわざVPSを作り直した意味がなくなる.バックアップの取得という点ではある程度意味はあるのだが...

と言う訳で、11/1(未明)にこのサイト “y2web.net” の鞍替え(馬替え?)を行ってみることにしよう.


仮想サーバイメージのバックアップ/リストアによるサーバ再構築作業


仮想サーバをスケールアップ(ダウン)させるには、一般的なVPS環境だと別な仮想サーバを新規に作成した上でサーバの環境を移行しなければならない.これは非常に手間と時間の掛かる作業で、誰もやりたくない作業だろう.幸いなことに、ConoHaのVPSサービスには、これらの作業をとても簡単に行う事が可能な、仮想サーバイメージのバックアップ・リストア機能が備わっている.AWSなどのパブリッククラウドサービスやVMWare ESXなどの仮想環境を使っている人には当たり前の機能なのだが、VPSサービスレベルでこの機能が備わっているサービスは殆ど見かけない.


今回、仮想サーバイメージのバックアップ・リストア機能を使って、この “y2web.net” サーバの仮想サーバ基盤(ホスト)乗り換えを行ってみた.



Image Backuping
サーバをシャットダウンした状態で仮想サーバのイメージを取得する

Deploying VPS Server
新しいVPSサーバをバックアップしたイメージファイルから復元する

Dual VPS Operation
DNSの切り換えが完了するまでの間は新旧両サーバを平行稼働させておく


今回のホストサーバ換装に要した時間は、20~30分程度で済んだ.DNS切り替えの事前準備(TTL短縮)や仮想基盤側Firewallの設定変更、DNSレコードの設定変更などそれなりにやらなければならない事はあるのだが、基本的にはクローンサーバなので、サーバ側で変更する箇所は “/etc/hostname” などの極一部で済む.


今回は前のサーバのIPも引き継がず別なIPのまま新旧サーバを平行稼働させる方法を採用したので、サービス停止時間も短時間で済んだ.心配していた仮想サーバ基盤(ホスト)も別なサーバが割り当てられていたので、ハズレサーバを引いてしまった場合は、今回のイメージバックアップ・リストア機能を使ってホスト基盤替えに挑戦してみては如何だろう.


今回は導入してはいないが、ロードバランササービスもあるので、片系統のサーバでサービスを継続させながらもう片方のサーバを更新するといった使い方も可能だ.


ConoHa VPSのイメージバックアップ・リストア機能はとても便利で有り難いサービスだ. VPSサービスと名乗ってはいるが、実体は完全なパブリッククラウドサービスだ.AWSの様にサーバの停止中は課金されないというような料金体系では無いが、時間単位の課金体系や月額ポッキリ料金などとても魅力的なVPSサービスだ.



【追記: 11/2 2017】


【追記】ホストサーバを乗り換えて1日ほど様子を見てみたが、HTTP Latency は以前と同じ状況だ.どうやらホストサーバの問題というより、その上位のシステム側の問題のようだ.只、同じ東京リージョンにある別なテナントのVPSサーバではこのような傾向は見られないので、テナント固有の問題だろう.


癪なので、このテナントを畳んで別テナントに移行することにしよう.オブジェクトストレージを使えば別テナントへ仮想サーバ毎引越しができそうだが、APIを駆使して相当頑張らないと難しそうだ.


別テントへの移行作業についてはまた別な機会に報告しようと思う.


New VPS HTTP Latency
ホストサーバを替えても結果は前と同じだった

Local Search

Calendar

November 2017
S M T W T F S
« Oct    
 1234
567891011
12131415161718
19202122232425
2627282930  
  • Blogroll

  • Meta