Compute Nodeに直結されたInterconnected Storageは、エフェメラルディスクのような高反応速度を持ちつつも、データが永続化されるストレージです。このストレージはデータベースなどのレイテンシーに影響を受けやすいワークロードのパフォーマンス向上に最適でありつつ、リクエスト数の事前想像が難しいインターネットエッジサーバに向いており、複数のCompute Nodeに分散したインスタンスに配置することで、スムーズにワークロードを分散することが可能という特徴を持ちます。
共有Block Storageへのアクセス集中が、プライベートクラウドの連鎖障害を生む
3-tier型のオンプレミス仮想化基盤を使ったり、プライベートクラウドを一度でも使ったことがある人は、共有Storage(Block Storage、File Storage共々)のアクセス集中による「ストレージ障害」という言葉を1度は見たことがあるでしょう。この障害は、単なるパフォーマンス劣化に留まるだけでなく、ほぼ全てのインスタンスが一斉にダウンするシビアな障害です。
一般に、多くのプライベートクラウドは次の様な三層構造を持っています。またパブリッククラウドでも共有Block Storageの上にボリュームを置くことで近い構造になります。
- インスタンス層
- Compute Node層
- ストレージ層
プライベートクラウドに収容される全ての仮想マシンインスタンスの仮想ディスクは、ストレージ層のBlock StorageやFile Storageに集約されます。ストレージの品質は様々ですが、集約する以上、ストレージに全てのIOが集まります。ストレージ側でも、ディスクキャッシュなど様々な仕組みを利用し、ある程度、緩和策を取っていますが、高価なストレージでも安価なストレージでも、IOの最大値は容量と同じように概ね決まっています。容量が100TBのストレージでは、結局100TB以上は使えないように、概ね、IO性能10,000IOPSのストレージは合計10,000IOPS以上、受けることはできませんし、1,000,000IOPSのストレージは1,000,000IOPSで律速します。そのIOスピードは概ねコストに跳ね返り、一般的にはそこにマジックはありません。
ここで難しいのは律速点にさしかかると、概ね「仮想マシンインスタンスがハングアップする」事です。
IOが集中して限界速度までつかうと、電源ブレーカーが落ちるような動きをし、インスタンスを順次再起動することを余儀なくされてしまいます。
このことがわかっているのに、なぜ共有Storageに集約するのでしょうか？それは、次の様なメリットがあるからです。
- 一貫性を重視＝仮想マシンインスタンスから書き込んだデータは必ず担保され、バックアップはStorageのみ考えれば良い。
- Compute Nodeが落ちたとき、他のCompute Nodeに移設することができる。いわゆるHA＝High Availability機能。
オンプレミス仮想化基盤や一般的なプライベートクラウドでは、1がもっとも重要となります。これを満たすストレージを作りこむことのは、とにかくとても大変なので、一箇所で集約して徹底的に守るという戦略になります。そのため、可用性(動いてる時間をなるべく長くする)を捨ててでも、一貫性(書いたデータがなるべく失われないようにする)を守っているのだという事になります。
2は、1が満たされているから実現できる技術です。実際問題、可動部品が少ないCompute Nodeが壊れることはそれほど多くはなく、この機能はメンテナンス、主にアップデートなどで使われています。HAは危険性やデメリットもありますが、仮想マシンインスタンスが数百もあるプライベートクラウドにおいて、ハイパバイザのメンテナンス時に、手動でマイグレーションを行うのは大きな手間になるため、HAは大きなメリットとなります。
※可用性と一貫性はどちらも満たしたい要件ですが、分散システムにおいてはどちらか片方しか満たすことができないという取捨選択の要件です。これをCAP定理と呼びます。詳しいドキュメントは、下記を参照。
インターネットに露出している情報サイト、ポータルサイト、ゲームサービスなどでは最大のアクセス量を読むことは中々難しく、ピークと平常では、10倍どころか、100倍、1000倍のアクセス量の違いがあります。
ピークアクセスが発生すると、ロードバランサ→インスタンス→Compute Nodeを経て、ストレージにIOインパクトが派生します。仮に耐障害性を求めて上位層でロードバランサーを設置したとしても、全てのアクセスは最終的にストレージに集められてしまうため、律速がストレージIOにあった場合は、最悪、全インスタンスがハングアップするという障害に繋がるのです。
この問題を簡単に回避したいのであれば、Block Storageの切り出し元を割るしかありません。
結局、可用性を得ようとしてロードバランサーを設置したのに、一貫性重視したアーキテクチャのシステム(ストレージ)が下位層にあることで、結果、どちらも得られなくなってしまいます。
全てのCompute Nodeを独立させること
上記の通り、負荷がフレキシブルに変わっていくサイトにとって、ストレージ集約される3-tier構造のプライベートクラウドは不向きです。
では、プライベートクラウドで、アクセスインパクトに応じてフレキシブルに稼働して欲しいポータルサイトや、情報サイト、ゲームサービスは、どのような構造をとればよいのでしょうか？答えはStorage層にあります。IOを集約するStorage層を無くし、Compute Nodeに直接、低レイテンシでアクセス出来る専有Storageを持てば良いのです。
それが、Interconnected Storageです。
シブリング単位のレプリケーションでデータを守る
Interconnected Storageは、NANDフラッシュの層で冗長化されており、RAIDのようにRAIN(Redundant Array of Independent NAND)構造を持つ永続化ストレージです。しかしその永続化レベルはEnterprise StorageやBackup Storageにくらべて劣る面があります。
そこで、ペアで動作させる仮想マシンインスタンス(シブリングと呼びます)を作り、どちらか1つのインスタンスがダウンしてもサービスが継続できるように設計を行います。
たとえばRDBであればHAレプリケーションを取ることでシブリングを作る事ができ、Application Server(Servlet)やWebServeも、ADCやProxyなどの機能で、冗長化できます。
こうしたシブリング・インスタンスを、同じCompute Nodeにおかないようにホームサーバ設定を行い、両方が同時にダウンしないようにコントロールすることができます。これは、アンチ・アフィニティやホームサーバコントロールなどと呼ばれ、これを行う事でIOが集約されず、可用性を上げたりデータロスを防ぐことが可能となります。
CAP定理において分散システムでは、可用性と一貫性はどちらか一つになりますが、これを時間軸と空間軸の両方でなるべく極小化していくことにより、サービスに足るレベルで両方を満たすことが可能です。
可用性だけでなく、一貫性も持ちたい場合はどうすれば良いのでしょうか？
その場合は、シブリング・インスタンスの中のミドルウェアの層で一貫性を保てば良いのです。同期型のレプリケーションを行えば、データは常に一貫性を保つことが可能です。ミドルウェアの中だけで同期される場合、本当に必要なデータだけに絞られるため、全てを同期するシステムと異なり、一貫性に関わるコストは下がり、応答速度劣化が小さくなります。
InfiniCloudのインスタンス間の接続は最大2x10G/25Gですから、インスタンス間のインターコネクトは十分な速度だと言えます。このようにInterconnected Storageの性能をうまく引き出すことで、エンドユーザのレスポンス速度にフォーカスしたサービスを作りやすいようにデザインされているのです。
バックアップまで含めた一貫性と可用性を考える
実のところ、Enterprise StorageもBackup Storageも、Interconnected Storageより永続化レベルが高いとはいえ、データが必ず失われないわけではありません。一貫性や可用性は、バックアップまで含めて考える必要があります。
「バックアップが可能なシステム」とは、「数時間前の状態にデータが戻ることが許容されているシステム」と同義と捉えることができます。バックアップからのリストア時には必ずバックアップ時点の状態に戻りますから、バックアップされたシステムは一貫性を失っていることになります。この巻戻る時点をRPO(Recovery Point Objective)と言います。
ここで、データの更新頻度が月に一度しかないようなシステムを想像してみましょう。
「毎月の締日のみデータの更新が発生する」というシステムであれば、その締日の処理さえ一貫性が確保できれば、データ更新後すぐにバックアップをすることで、バックアップから翌月の締日処理の開始までの一貫性を保つことができます。バックアップ間隔は月に1度でよいことになります。これは単位が毎月でなく、毎日でも、話は同じことです。
一方、可用性もバックアップからのリストア時に停止する場合には失われますが、サービスによってはロードバランサー等で複数台サーバーを用意することでカバーできることもあります。
このように、「バックアップ間隔 ≦ データ更新間隔」が成り立つ場合、一貫性についてはデータ更新の瞬間のみ意識すればよいという結論が導かれます。
