レスポンス速度にフォーカスしたクラウドでエンドユーザーに高度なエクスペリエンスを与える - JUSTPLAYER インターネットサービス

Top / テクニカルノート / レスポンス速度にフォーカスしたクラウドでエンドユーザーに高度なエクスペリエンスを与える

ハイレスポンスプライベートクラウド

印刷

レスポンス速度にフォーカスしたクラウドで、
エンドユーザーに高度なエクスペリエンスを与える

情報サービス、ゲームサービス、ポータルサイト。

これらコンシューマー・サービスは、ユーザー体験を重視するサービスであり、そのレスポンス速度は最重要課題のひとつです。遅延や応答性の低下により、サービスのブランドイメージが損なわれ、ユーザーが離れてしまうことが考えられるからです。

このようなユーザー体験を重視するサービスのクラウドインフラとしては、ひとつのリソースに多数の利用者が収容されるパブリッククラウドよりも、他の利用者の影響を受けにくいプライベートクラウドが望ましいでしょう。しかし、残念ながら一般的なプライベートクラウドは、コンシューマー向けの速度を重視したサービスには向かないといわれています。

なぜでしょうか?

対して、ジャストプレイヤーの『ハイレスポンスプライベートクラウド』は、レスポンス速度にフォーカスし、ゲームサーバーや、ポータルサイトのような、速度を要求されるコンシューマー・サービスを作りやすいようにデザインされています。

一般的なプライベートクラウドとは何が異なるのでしょうか?

3-tier 構造のプライベートクラウドが連鎖障害を生む

プライベートクラウドを一度でも使ったことがある人、あるいは興味があって情報を集めている人ならば、「ストレージ障害」という言葉を1度は見たことがあるでしょう。ストレージ障害は、およそ全てのインスタンスが一斉にダウンする事の多い障害です。

 

三層構造

一般に、多くのプライベートクラウドはパブリッククラウドとは異なり、次の様な三層構造を持っています。

  1. 仮想マシン層(インスタンス)
  2. ハイパバイザ層
  3. ストレージ層
 

 

プライベートクラウドに収容される全ての仮想マシンの仮想ディスクは、ストレージ層のSANストレージに集約されます。ストレージの品質は様々ですが、集約する以上、ストレージに全てのIOが集まってきます。ストレージ側でも、ディスクキャッシュなど様々な仕組みを利用し、ある程度、緩和策を取っていますが、高価なストレージでも安価なストレージでも、IOの最大値は容量と同じように概ね決まっています。100TBのストレージでは結局100TB以上使えないように、概ね、IO性能1,000IO/secのストレージは合計1,000IO/secで律速するし、1,000,000IO/secのストレージは1,000,000IO/secで律速します。その差は概ねコストに跳ね返り、そこにマジックはありません。

 

全てのマシンからアクセスがある

ここで難しいのは律速点にさしかかると、概ね「落ちる」事です。

落ちる=全ての仮想サーバインスタンスのダウンです。IOが集中して限界速度までつかうと、電源ブレーカーが落ちるような動きをします。

 

 


このことがわかっているのに、なぜ3-tier構造を取るかと言えば、次の様なメリットがあるからです。

  1. 一貫性を重視=仮想マシンインスタンスから書き込んだデータは必ず担保されている。
  2. コンピュートノードが落ちたとき、他のコンピュートノードに移設することができる。

1がもっとも重要で、これを満たすストレージをつくるのはとにかくとても大変なので、一箇所で集約して徹底的に守るという戦略になります。鍵を一箇所で集めて徹底的にまもるのか、鍵を分散して個別に守るのか、どちらにも是非がありますが、それと似ています。

インフラを提供しているクラウド事業社としては、お客様が書いたデータが無くなってしまうということは、是が非でも避けたいインシデントです。そのため、可用性(動いてる時間をなるべく長くする)を捨ててでも一貫性(書いたデータがなるべく失われないようにする)を守っているのだという事になります。

2は、1が満たされているから、簡単に可能になる技術です。実際問題、可動部品が少ないコンピュートノードが壊れることは、それほど多くはなく、この機能はハイパバイザのメンテナンス、主にアップデートなどで使われています。


※可用性と一貫性はどちらも満たしたい要件ですが、分散システムにおいてはどちらか片方しか満たすことができないという取捨選択の要件です。これをCAP定理と呼びます。詳しいドキュメントは、下記を参照。

 » 時空(時間軸と空間)に拡張されるCAP定理

さて、インターネットに露出している情報サイト、ポータルサイト、ゲームサービスなどでは最大のアクセス量を読むことは中々難しく、ピークと平常では、10倍どころか、100倍、1000倍のアクセス量の違いがあります。

 

ロードバランサーからストレージにインパクトが伝搬
ピークアクセスが発生すると、仮想サーバ、ハイパバイザを経て、ストレージにインパクトが派生します。仮にネットワーク上位層でロードバランサーが設置されていたとしても、全てのアクセスは最終的にストレージに集められてしまうため、律速がストレージIOにあった場合は、最悪、全仮想マシンインスタンスがダウンするという障害に繋がるわけです。
 

 

結局、可用性を得ようとしてロードバランサーを設置したのに、一貫性重視したアーキテクチャのシステム(SANストレージ)が下位層にあることで、結果、どちらも得られないという自体になってしまうのです。


全てのコンピュートノードが独立であること

上記の通り、負荷がフレキシブルに変わっていくサイトにとって、3-tier構造のプライベートクラウドは不向きです。

しかし、アクセスインパクトに応じてフレキシブルに稼働して欲しいポータルサイトや、情報サイト、ゲームサービスは、プライベートクラウドに収容できないのでしょうか?答えは先のStorage層にあります。IOを集約するStorage層を無くし、Hypervisorが個々に専有Storageを持てば良いのです。

 

Hypervisorに直結したStorageが個々にある
この構造であれば、L/Bで分散したトラフィックは、互いのコンピュートノードにアクセスインパクトが分散されます。またストレージがハイパバイザから専有であれば、より高速なインターコネクトを利用することもでき、広帯域でハイレスポンスが必要なサービス作成にはちょうど良い動作になります。
 

 

あとは平行動作させる仮想マシンインスタンス(シブリングと呼ぶ)を、同じコンピュートノードにおかないようにコントロールします。これは、アンチ・アフィニティやホームサーバコントロールなどと呼び、これをきちんと行う事で、IOは集約されず、仮に1つのコンピュートノードがダウンした場合でも、他のサーバで動作させることが可能になります。

バッキングストレージであるデータベースや分散KVSなども、同じようにそれぞれのコンピュートノードに分散し、どれか1つが落ちた場合でもサービスダウンしない実装にすれば、期待通りの動作となるでしょう。

 » レスポンスの速いサーバ(可用性の高いサーバ)はどう作るのか?

この構造でも、仮想マシンのライブマイグレーション(仮想マシンを動作させたままのコンピュートノード移設)は可能です。ストレージデータを伴って移設をすることができるためです。しかしながら、移設には時間と、その間の多少のIO負荷はかかります。ライブマイグレーションを行う事ができれば、コンピュートノードのメンテナンスやアップデートも可能です。

問題は、この構造では、1つのコンピュートノードが不慮のダウンをした場合、その下位層に繋がっている専有ストレージへのアクセス経路を失ってしまうことです。


バックアップまで含めた一貫性と可用性を考える

「バックアップが可能なシステム」とは、「数時間前の状態にデータが戻ることが許容されているシステム」と同義と捉えることができます。バックアップからのリストア時には必ずバックアップ時点の状態に戻りますから、バックアップされたシステムは一貫性を失っていることになります。(とはいえ、データを完全にロストするわけにはいきませんから、次善の策としてバックアップをするわけです)ここで、データの更新頻度が月に一度しかないようなシステムを想像してみましょう。

「毎月の締日のみデータの更新が発生する」というシステムであれば、その締日の処理さえ一貫性が確保できれば、データ更新後すぐにバックアップをすることで、バックアップから翌月の締日処理の開始までの一貫性を保つことができます。バックアップ間隔は月に1度でよいことになります。これは単位が毎月でなく、毎日でも、話は同じことです。

一方、可用性もバックアップからのリストア時に停止する場合には失われますが、サービスによってはロードバランサー等で複数台サーバーを用意することでカバーできることもあります。

このように、「バックアップ間隔 ≦ データ更新間隔」が成り立つ場合、一貫性についてはデータ更新の瞬間のみ意識すればよいという結論が導かれます。


xen

前述の通り、ハイレスポンスプライベートクラウドは、ストレージ層で可用性を高めているクラウドシステムとは違い、ひとつのハイパーバイザーがダウンしてしまった場合、そのハイパーバイザーに収容されていた仮想マシンはアクセスができなくなります。

※ストレージ層で可用性を高めているクラウドシステムとしては、当社の場合『VMwareプライベートクラウド』『Solaris SPARC/Xeonプライベートクラウド』が相当します。

 
xentec5.jpg

もちろんハイパーバイザーのダウンが一時的な問題であり、再起動するだけで復旧できるのであれば、そのシステム全体も短時間で復旧できることになります。しかし、ハイパーバイザーが起動できないレベルの問題(ハードウェア故障など、特に専有ストレージ破損)があった場合、そのハイパーバイザーに収容されていた仮想マシンのデータは完全に失われてしまいます。

そこで、当社の『ハイレスポンスプライベートクラウド』では、バックアップ用に共有NFSをマウントし、そのバックアップストレージに対して1時間に1度の頻度(RPO = 2時間)で、差分レプリケーション(仮想マシンのクローン)が実行されています。

 
xen
ハイパーバイザーの復旧に時間がかかってしまう場合、このバックアップストレージ上の仮想マシンデータを別のハイパーバイザーに再収容(クローンコピー)することで、最大2時間前(RPO = 2時間)のデータを元に復元することができます。
 

実際にこのような事態が発生してしまったときは、以下の事象が発生することになります。

  • 一貫性(C)の損失、RPO = 2時間分
  • 可用性(A)の損失、ダウンタイムはバックアップからクローンコピーをして復元する時間(RTOは仮想マシンのストレージの実サイズにより変わります)

バックアップストレージであれば、ピークのアクセスインパクトがストレージ層まで伝播することはありません。伝搬しないということは、それぞれのコンピュートノードには「独立性」があるということになります。

しかしながら、このようなインシデントの時にはデータの巻戻りが発生するため、これが許容できるかどうかで、システム全体の設計を変える必要があります。


可用性も一貫性も捨てたくないとき

ハイレスポンスクラウドは、一貫性にある程度、目をつぶる代わりに、結果的に可用性を引き上げるアーキテクチャとなっています。そのため、一度書いたデータでも、バックアップシーケンスが動かない限り、専有のインターコネクトストレージにだけデータがある状態が生まれます。

実際のシステムにおいて、1時間に1度のバックアップによるデータ保護では足りない時があります。

可用性だけでなく、一貫性も持ちたい場合はどうすれば良いのでしょうか?

CAP定理的に、分散システムにおいて、可用性と一貫性はどちらか一つになりますが、これを時間軸と空間軸の両方でなるべく極小化していくことにより、サービスに足るレベルで両方を満たすことが可能です。

 » 時間と空間の両方で狭域化する!

 

仮想マシンの上のデータベースがお互いにレプリケーション

仮想マシンの中のミドルウェアの層で一貫性を保てば良いのです。

異なるコンピュートノードに動く、異なる仮想マシンインスタンス内のミドルウェアで、同期型のレプリケーションを行えば、データは常に一貫性を保つことができます。

そのミドルウェアの中だけで同期されるため、本当に必要なデータだけに絞られて同期が行われるため、全てを同期するシステムと異なり、負荷は小さめになります。

2つの仮想マシン間接続が十分に速ければ、これらは高速に機能するでしょう。

 

 

ハイレスポンスクラウドの仮想マシン間のインターコネクトは標準で10Gbpsです。このようにハイレスポンスクラウドは、サービスのレスポンス速度にフォーカスし、ゲームサーバーや、ポータルサイトのような、速度を要求されるコンシューマー・サービスを作りやすいようにデザインされているのです。

 

本記事の関連サービス

 

クラウド型リモートVPNサービス xen-orchestra.html 採用情報 TeraCLOUD 清水エスパルス
Oracle GOLD Partner

ジャストプレイヤーはオラクル認定ゴールドパートナーです。
SPARCをはじめ、オラクル社の製品を用いたクラウド環境の構築、運用をサポートします。


JUSTPLAYER.NE.JP

https://justplayer.ne.jp/

info@justplayer.com

ジャストプレイヤー株式会社
JUSTPLAYER Co.,Ltd.
静岡県静岡市葵区上石町2-4 河村上石町ビル 1F
tel/050-3801-5987 fax/054-251-1757