テクニカル・ノート - JUSTPLAYER インターネットサービス

Top / サービス一覧 / Xenプライベートクラウドサービス / テクニカル・ノート

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

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

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

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

なぜでしょうか?

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

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

そこには、データの保持特性に対する再定義が存在するのです。


データの一貫性を過度に重視することが可用性を低下させてしまう

データストアをどのように設計するか?

分散システムを構築するにあたり、「データストアをどのように設計するか」は重要なテーマのひとつです。

残念ながら機械である以上サーバーはいつかは必ず壊れます。複数台のサーバーで構成されているシステム内で1台故障するだけでサービス停止が発生したり(可用性の低下)、データが壊れること(一貫性の低下)によりサービスが終了するわけにはいきません。そこで、データは複数箇所に保存するべきだと考えられます。

しかし、複数のサーバーで共通のデータを持たねばならない場合、次の3つの望まれる性質のうち、2つしか同時に満たすことができません。これを『CAP定理』といいます。

 

CAP
C:Consistency(一貫性)
すべてのサーバーで統一された最新データを持っていること。
A:Availability(可用性)
そのデータの更新に対する高可用性。つまり、常に動いているということ。
P:Partition-tolerance(分断の許容)
サーバー同士が分断する状態がありえる、または分断が起きてしまった状態

簡単に説明するため、2つのサーバーに同じデータを保存したい場合を考えます。CAP定理では、『P-A』『P-C』『A-C』の3つのパターンのみが達成可能です。

P-A
サーバーに分断が発生したとき(P=分断が起きてしまった)、可用性(A)を考えて片方のサーバーにだけ書き込みをしてしまうと、2つのサーバーでは同じデータを持つことができません。そこで一貫性(C)が失われます。
P-C
同様にサーバーに分断が発生したとき(P=分断が起きてしまった)、一貫性(C)を考えて2つのサーバーで同じデータにするには、システムを一時停止するしかありません。つまり可用性(A)が失われます。
A-C
分断されていない状態(Pが起きていない)ときのみ、一貫性(C)も可用性(A)も得ることができます。
 

二つのサーバーでCAP定理を考える

例えば、遠隔の拠点(例としてデータセンター)にそれぞれサーバーが設置されている分散システムの場合、短時間といえどこれらのサーバー間の通信が分断されることを避けることはできません。したがって、システムの全体設計として、分断(Partition)が起きることを許容(Tolerance)しなければならず、『P』は必須となります。CAP定理に従うと、結果として残りは『A』または『C』のどちらかを選ぶしかありません。

視点を変えて、近距離に設置したの二つのサーバーではどうでしょうか?

『P』を選ぶ必要がない、すなわち分断は必ず起きないと保証されるとき、『A』と『C』は同時に成立するように見えます。データの一貫性が保たれ動作が継続する。これは理想的なシステムと考えられそうです。

そこで、ミラー化されたストレージサーバー・システムを想像してみましょう。ミラー化されたストレージサーバーでは、一方のストレージサーバーがダウンしてももう一方のストレージサーバーのみで動作を継続するため、一見するとデータ一貫性も可用性も保たれているように見えます。

 

xentec1-2.jpg

具体的に想像するため、ストレージサーバー『1号機』と『2号機』があり、同じデータを書き込むリクエストがあったと仮定します。

システムは『1号機』と『2号機』の両方に書き込み要求をし、その書き込みが完了したという「完了報告」(一般にAcknowledge/アクノリッジといいます)をもらってから、ようやく次のデータの読み書きに移ることができます。

こうしなければ一貫性(C)を保つことができません。

 
xen

ここでもし、『1号機』はすぐに書き込みを完了したが、『2号機』の書き込みが遅れた場合はどうなるでしょうか? 

この場合、『1号機』だけが最新の状態になり、『2号機』はどうなっているのかわかりません。つまりこの瞬間においては分断が発生(P)しているのです。

 

『A』『C』のどちらかを選ばなければならない

あなたがプログラマーだったとしたら、一方のストレージ応答が遅れた場合の処理をどう書きますか? どう考えたとしても、できるのは次のどちらかか、両方の組み合わせのプログラムです。

  • 『応答を待ち続ける』
    • この場合は、データの一貫性(C)を保つことを重視していることになります。ただし、『2号機』の書き込み完了を待つ間(Δt)、そのシステムは停止することになるため可用性(A)を失います。
  • 『応答を待たずに進む』
    • この場合は、『1号機』だけで動作を継続することから可用性(A)を重視していることになります。ただし、『1号機』と『2号機』のデータ整合性が崩れるため、一貫性(C)を失います。

つまり、近距離の二つのサーバーであったとしても、プログラマーは分断が発生する前提で『A』『C』のどちらかを選ばなくてはなりません。

※この文書でのΔtは、ある時間t1から、ある時間t2までの間の、一定の時間Δt=t2-t1を意味しています。ここでは、とある一定の時間だと考えれば良いでしょう。

一貫性を保つことで可用性の低下(レスポンス性の低下)が発生する

実際のストレージシステムにおいては、この遅延時間『Δt』はしばしば発生しています。たとえ同じハードウェア・同じソフトウェアのストレージシステムを用いたとしても必ず発生しています。上の例では、『2号機』の書き込み遅延が終了するまでの時間(Δt)が分断が発生(P)している時間になります。

これはCAP定理自体を、マクロな設計視点から、一定の短い時間(Δt)を考慮したミクロな設計視点へ概念を拡張しなくてはならないことを意味しています。ほぼすべての分散システムにおいて、Δtのようなごく短時間の間に、分断『P』が発生したり消滅したりしているのです。したがって、分散システム上で処理を記述するプログラマーは、必ずどこかで『A』と『C』のどちらかを選ぶ必要があります。

現実的なミラーストレージをミクロ的な視点から見ると、書き込み遅延により分断が発生(P)した場合、基本的にはタイムアウトが発生するまでは書き込み完了を待ち続けます。すなわち待つ(停止する)ことで可用性(A)を捨て、一貫性(C)を保つのです。この「Δtの間待つ」という行為が多数発生しているシステムは、マクロ的な視点からは「全体的に遅いシステム」に見えることになります。

なお、タイムアウトが発生してしまった場合は、そのタイムアウトが発生した片系のシステムを切り離します。それにより一貫性(C)が捨てられ、可用性(A)が選択されて動作を継続します。

さて、一般的なクラウドシステムでは、ハイパーバイザー層で共有ストレージ(SANストレージ)を利用し、この層で一貫性(C)を担保しようとします。ストレージは、複数のハイパーバイザーから届く様々なリクエストを、一貫性を保ちつつ処理するため、大小様々な遅延を発生させています。

これにより一貫性は保たれますが、マクロの視点からは上述のとおり「全体的に遅いシステム」に見えます。一貫性を重視しすぎることで、可用性の低下(レスポンス性の低下)が発生してしまうのです。

ミラーストレージのような分散システムにおいて、片系のストレージでタイムアウトが発生することにより、その片系の切り離しが発生します。このとき、一貫性(C)が失われ、代わりに可用性(A)を得ることになります。タイムアウトにより『P-C』のシステムが『P-A』のシステムへと入れ替わるのです。

これをマクロの視点から見た場合、仮にタイムアウトまでの時間を無視できるのであれば、ミラー化された冗長ストレージシステムは一貫性(C)ではなく、可用性(A)を重視したシステムといえます。

実際には、片系が切り離されデグレードとなった状態で、一端、分散システムから単一系になります。再度、リカバリー(リビルド、リシルバーなど)処理が完了すると、元の冗長された分散システムへと戻ります。

このようにCAP定理は、Δtの長さによって、短い時間の単位で考えるミクロな視点と、全体を見たマクロな視点のどちらでも考えなくてはなりません。


遅延が少なく高レスポンスなシステムにするために

ここまで述べたことから、高速なレスポンスが必要ならば「一貫性(C)を捨て可用性(A)を重視する」か、「そもそもデータを複数に分散しない」の二択であると考えられます。

そこで、まずは「そのサービスにデータ一貫性(C)が必要か?」を考える必要があります。

もちろん一貫性(C)を失う、つまりデータをロストすることに問題があるケースの方が多いでしょう。しかし、サービスを役割ごとに分割することで、「あるサーバーにはデータ一貫性が必要」「あるサーバーは数時間に一度の更新しか発生しない」など、様々な種類に分けることができます。

例えば、データ更新がない・または少ないウェブサーバーやアプリケーションサーバーであれば、あらかじめ同じデータを持つサーバーを複数用意することで、1台のサーバーがダウンしてもサービスを継続することができます。

 

xentec3.jpg

一般的なウェブサービスでは、コンテンツの更新頻度と参照頻度を比べた場合、参照頻度がずっと高いはずです。データ更新用サーバーと参照用サーバーを分け、更新用サーバーで更新されたコンテンツを参照用サーバーにコピーするような仕組みを用意することができるのであれば、更新用サーバーは一貫性を重視し、参照用サーバーは可用性を重視することで一貫性と可用性のベストバランスを実現できるでしょう。

※その場合、更新用サーバーから参照用サーバーへとコピーする時間を考慮する必要があります。コピーする時間(Δt)は、更新用サーバーと参照用サーバーのコンテンツに差異がある状態のため、一貫性が失われることを許容しなければなりません。

このように、サービスを構成するサーバーを「一貫性が必要なもの」と「可用性を重視・高レスポンス性が必要なもの」にそれぞれ分離することで、エンドユーザーが感じる快適さを大きく向上することができます。言い方を換えると、エンドユーザーからのアクセスが、一貫性が必要なサーバーにアクセスしなければ、サーバーのレスポンスは向上し、快適なサービスができあがるのです。

 

 

つまり、一貫性が不要なサーバー(高レスポンス性が必要なサーバー)は、高速なハイパーバイザー上に設置されるのが望ましいことになります。高速なハイパーバイザーはハイパーバイザー層でデータを分散せず、レスポンス性を確保します。ハイパーバイザー層で一貫性を重視したクラウドシステムはどうしても遅くなるからです。

ジャストプレイヤーのXenプライベートクラウドサービスは、ハイパーバイザー間の共有リソースをほとんど持ちません。(バックアップ時を除き)それぞれのハイパーバイザーが独立して動作するため、他のハイパーバイザーとの一貫性の調整が必要がありません。そのため、単一ハイパーバイザー内での高速レスポンスが可能な設計になっています。また特定のハイパーバイザーにシビアな負荷が発生しても、他のハイパーバイザーへの影響はほぼ発生しません。


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

今度は、時系列をもっとマクロな視点に移して考えます。「ある一定の期間」であるΔtをもっともっと長く、バックアップの時間まで拡げていくとシステムの一貫性と可用性は異なる見え方に変化します。

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

ここで、データの更新頻度が月に一度しかないようなシステムを想像してみましょう。

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

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

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


xen

ジャストプレイヤーのXenプライベートクラウド

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

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

 
xentec5.jpg

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

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

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

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

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

これが許容できるか、あるいは許容するためにシステム全体をどう設計するかが重要な点となるのです。


データストアサーバーをどうするべきか?

実際にシステムが破損することは頻繁に発生するわけではありませんが、発生することを前提としなければなりません。

しかしこれまでの話で、可用性より一貫性が必要なサーバーは、実際は全体の中のほんの一部であるし、一貫性が必要な尺度もΔtによって異なることがわかりました。

にもかかわらず、システム全てに影響するハイパーバイザ層、ストレージ層で一貫性を担保するということは、全体の速度に大きく影響を及ぼしますし、コストもかかります。

許容範囲を決め、そこに収まる一貫性を得るためにはどうすればよいのでしょうか?

これには2つの方法があります。

  1. 一貫性が必要なサーバーだけ、一貫性のあるクラウドサービスに収容する
  2. アプリケーション層で冗長度を担保する

1.の一貫性を重視したクラウドサービスは、当社においては次のものがあります。

  • VMwareプライベートクラウド
    • 共有ストレージを用い、データ一貫性をある程度、重視した設計。
    • IOレスポンス速度は下がるため、パブリックサービスでユーザーリクエスト毎にデータアクセスするようなシステムには向きません。
  • Solaris SPARC/Xeonプライベートクラウド
    • ミッションクリティカルなシステム向けにデータ一貫性に主眼をおいた設計。
    • 常に複数のストレージシステムにダブル・ライトされるため、データ書き込みの応答速度は下がりますが一貫性を保ちます。

これらを採用することで解決なのでしょうか? 残念ながらすべてが解決するわけではありません。

ハイパーバイザー層やストレージ層での一貫性の維持には、あらゆる意味のコストがかかります。それは金銭的コストだけではなく、処理に必要な時間的コストも必要です。実際には、一貫性の維持のために、どうしても時間的コストが必要です。

当社のこれらのクラウドサービスではすべてEnterprise SSDを採用していますので、一般的なプライベートクラウドサービスに比べれば「速い」方といっても差し支えありません。しかしながら、当社の『Xenプライベートクラウド』のように、一貫性を考慮しないサービスに比べると、どうしても応答速度は下がります。

それだけではありません。前述したとおり、一貫性を担保できるのは限定的な範囲に留まります。例えば、一貫性のために二系統のストレージに書き込みを行うとき、片方のストレージがタイムアウトまで応答しなかった場合、その間は一貫性を維持するために可用性を捨て停止します。この停止時間のため、仮想マシンは再起動が必要になってしまう場合もあります。

結局のところ、これは「どこにΔtがあるのか?」という問題なのです。先ほどの「もしあなたがプログラマーだったなら…」という命題のとおり、サービスの分割が発生したら、一貫性を複数のサーバーで維持しようとしても、どこかでタイムアウト待ちとなる「Δt」の処理があるのです。

例えば、あなたのシステムにファイルベースのデータストアが必要な場合、適当な分散技術は残念ながら余りないでしょう。この場合、ハイパーバイザー層での一貫性にある程度は頼る必要があります。またシングル構成のデータベースであったり、それらがよくわからないシステムである場合は、やはりハイパーバイザー層に頼るしかありません。

一方、アプリケーション層で冗長度を担保する方法は、ある程度の理解度が必要になりますが、一貫性の問題をより小さな範囲で閉じ込めることが可能です。

例としてデータベースであれば、レプリケーションやクラスター機能があることが一般的で、複数のハイパーバイザーにデータベースを分散することで、そのデータベースソフトウェアが担保できる範囲で一貫性や可用性を得ることができます。仮にひとつのハイパーバイザーが破損しても、可用性を維持したり一貫性を維持する方法があるでしょう。

また、分散ストレージ・分散KVS等のシステムを利用し、複数のハイパーバイザーの上に適度にデータストアを分散・保存する方法もあります。これら分散型のものは、一貫性を逆に持たず、可用性だけを求めるケースもありますから、その場合は一貫性をアルゴリズムの面で管理したり別の物で保つ必要があります。

参考として、分散技術には次の様なものがあります。

  • MySQL
    • グループレプリケーション
  • PostgreSQL
    • レプリケーション
  • Hadoop
  • redis
  • DNS
  • LDAP

これらの分散技術は、それぞれ異なる思想を持って作られたものです。例えばデータベースのレプリケーションであっても、Δtを十分小さくしていくと、一貫性が保てるわけではないこともあります。

それぞれの特性を良く理解し、どの仕組みがどのレベル、どの単位での一貫性を持つのかを押さえておく必要があります。

パソコンと違って、サーバーのパフォーマンス問題は致命的です。

一般的にパソコンは一人のユーザーがそのマシンを占有するため、遅いときはその人だけが待てばよいことになります。しかし、サーバーの場合、同時に複数人が使用します。同時に受け付けることができる数は、だいたいメモリやCPUパワーによって決まります。

例えば、1秒で終わる処理を100人同時に受け付けることができるシステムが、速度劣化によりその処理に10秒必要となったらどうなるのでしょうか? 1秒あたりの処理可能人数は10人と、ぐっと下がってしまいます。この状態でいつもと同じ人数がアクセスすると、待ち時間が劇的に増えてしまいます。それは実質サーバーがダウンしたのと同じ状態です。

このように、サーバーにとっての速度劣化は、インシデントに直結するのです。


サーバーはいつか必ずダウンする

残念ながら、サーバーはいつかダウンします。そしてダウンしないシステムを構築する銀の弾もありません。

起こりうる範囲のインシデントを最初から押さえ、上手く設計することで、より良く安定したサービスを実現することが可能となります。

『Xenプライベートクラウド』は、パブリッククラウドサービスではなく専用のインフラを提供するサービスです。そのため、パブリッククラウドサービスでありがちな「理由は良くわからないが遅くなる」ということも、何かの理由で知らない間に再起動されることも(インシデントを除き)ありません。

適切に使うことで、安価で可用性の高いサービスの実現が可能になるでしょう。

サービスをご利用いただくユーザーにとって、何が重要であり、どう組み合わせれば最高のエクスペリエンスを与えられるかが重要なのです。

※当社のエンジニアリングサービスでは、監視データの取得をしながら、これらのコンサルティングが可能です。是非ご活用ください。

 

 

Oracle GOLD Partner

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