サーバのスケールアウト・スケールアップって愛憎相半ばする関係(love-hate relationship)?

Subscribe with livedoor Reader

つい最近、世界最大のBitcoin取引所のMt.GoxがハッキングだというのですがBitcoinという470億円分の暗号化通貨(crypto-currency)のデータが消失し負債総額65億円で倒産しましたね。まあ、本当にハッキングされたのかトンズラしたのかも微妙ですが、データが兎に角消えるとこうなることがあるって例ですね。



Google


翻ってみて、世の中クラウド時代になり身近なんですが、こちら「クラウドって便利ですが、今後は淘汰の時代!? ある日大事な写真やデータが....」でもご紹介しましたとおり、データが兎に角消えるとどうなるか考えさせられます。データの性格をキチンと考えないとクラウド導入で情報データ消失し、倒産なんてことに.....なるかならないかはさておき。お金でなくても、写真でも下手すると大事な思い出が全部消えてしまいますよね。契約ではよくてクラウドの使用料金位しか損害賠償して貰えないんですから、ちょっと考えたいですね。

クラウドって便利ですが、今後は淘汰の時代!? ある日大事な写真やデータが....

そんなクラウドのイメージも徐々に変わりつつあり、過去の苦い経験から信頼性もかなり上がってきていますね。そして、そろそろスケールアウトの時代ではなく、ご存知のようにデータセンターなど一箇所の集めるためにスケールアップもしておいて、CODに応じ機を見て仮想化で一気にスケールアウトする、スケールアップもスケールアウトも当たり前な時代だと思います。

ここまでは分かっているのですが、データの性格について深い意識が及ばないまま、簡単に仮想化でスケールアップとスケールアウト両立できますよって言っちゃうから、こちら「クラウドって便利ですが、今後は淘汰の時代!? ある日大事な写真やデータが....」でご紹介したようなクラウドでのデータ消失が2011~2012年にあちらこちらで起こり、NTT PCコミュニケーションズのような事業廃業が起こったんでしょうかね。

NTT PCコミュニケーションズ WebARENA CLOUD9障害について

実際その当時のNTT PCコミュニケーションズの状況としては、仮想サーバが起動不可->データの不整合が発生?->すべての仮想サーバに対して接続不可->ファイルシステムの不具合の復旧作業が不可->事実上のデータ大量消失だったようですね。

米AWSも仮想ネットワークの構成を間違えた->EBSでデータの複製(再ミラーリング)が多発->記憶容量が一杯になったEBS(管理ノード)がダウン->仮想マシーンへの接続不可->リレーショナル・データベース・サービス(RDS)が動かない->ストレージサービスやデータベースサービスの障害へと波及->大規模な障害を起こしたばかりの頃でしたのでなおさらでした。

しかし、それが反面教師か反省かどうかは分かりませんが、2013年からは日本ではデータの性格を意識してセキュリティの第3者による格付けを取得するなど、ハードなり、システムなりにも意識が及んでもしもの時のデータの多重化が徹底されてきたように感じますね。

じゃあどうするか?なんですが、既に今日現在ではかなりクラウドベンダーは対策済みだと思うんですが、バックアップ先も含め多くのデータセンターを色んな場所、しかも理想は多国に展開している大規模なクラウドベンダが生き残るでしょうから、そういうところは第3者による格付けも取ってるでしょうから最初から頼むという手、そこは割り切って諦めて困らないところしか頼まないかでしょうね。

スケールアップとスケールアウトで取り扱うデータの性格だったり、処理継続の容易さだったり、ハードやシステムとは関係ない(お客さまから頂く)大切な(あるいはそんなに大切ではない?)データの性格やサービスレベル(SLA、契約など)に応じたサービスを正しく説明し、提供して頂いくことで、我々もクラウドは「障害が起こる」前提でサービスを選択していくしかないでしょうね。

サーバのスケールアウト/スケールアップ
処理能力アップの考え方とその方法 適用しやすい前提 メリット 適用しやすい
サーバの種類
スケール
アップ
ハードウェアを
高性能化する
分散したサーバでの処理継続が容易でない場合 サーバの台数が減るため管理の手間が少なく、ソフトウェアのライセンス料金が抑えられる DBサーバ
スケール
アウト
サーバの台数を
増やす
分散したサーバでの処理継続が容易な場合
(複製や同期が容易で、複製で問題の起きにくいデータを扱う場合)
メンテナンスや障害発生時にもサービスを完全に停止させる必要がない Webサーバ
仮想化 高性能化したサーバ上で
仮想サーバの台数を増やす
分散したサーバでの処理継続が容易かにはよらない スケールアウト・スケールアップが両立できる 全てのサーバ


ヤフーの子会社のファーストサーバがやった、脆弱性対策のための更新プログラム自体に大きなバグ(「ファイル削除コマンド」を停止させる記述漏れと、メンテナンスの対象となるサーバー群を指定する記述漏れ)があることに起因したデータ消失はさておき、兎に角仮想化という物理的なリソースに紐付けされていない目に見えない世界を充分理解し、クラウドは「障害が起こる」前提でどう復旧するかのスキームを作っておくことが必要になってきます。

例えば、よくあると思うのですがサービスレベルに応じた(コストに応じた)可用性への対策と、やはり可用性のレベルに応じた(コストも含めた)正しい説明をしていく必要がありますね。つまり、この一連のデータ消失は、I/Oの仮想化、ストレージの仮想化がまだ成熟していないところに適用したのが原因、その1点だったようにはたから見ると感じますね。

サービスレベルに応じた(コストに応じた)可用性への対策
  • サービスレベルが高くない場合
    物理環境の可用性を向上する(サーバの可用性に効くスイッチなど、兎に角物理ハードウェアの冗長性を上げておく)

  • サービスレベルが中程度の場合
    仮想環境の可用性を向上する(仮想化ソフトVMware, Hyper-V, KVMなどにある可用性向上機能を活用してみる)

  • -------------------ここまではだいたい対策済み?-------------------

  • サービスレベルが高い場合(基幹系システム)
    HAクラスタリング(運用系と待機系の2系統のシステム)や、物理的な場所も含めバックアップシステムを導入する

vSphere High Availability (HA) Clusters


あるいは、従来のように単に物理サーバやネットワークなど個別に監視するのではなく、パフォーマンスを監視しながらパフォーマンスの低下の原因をデータセンターの内外も含めて把握・分析・解決するAPM(Application Performance Management)のツールを導入することもプロアクティブな対策になるとは思います。

SmartCloud Application Performance Management - IBM Cloud TechTalk (2013/6)


ちょっと矛盾するのですが、クラウドは「障害が起こる」前提ですが、どんな障害が起こるか分からないのが常でもありますのでこのような対策が今後大事(あるいはビジネス上の売り)になってくるかもしれません。さらには、バックアップという点でもVMwareのvCloud構想、MicrosoftのWindows Azure連合など国を超えたワールド互換をベースに世界規模のクラウドシステムを構築というのが今後大事(あるいはビジネス上の売り)になってくるかもしれません。

Introducing Windows Azure


Windows Azure - Microsoft Cloud


VMware vCloud Director Tutorial for Service Providers


VMware vCloud Suite 5.1 - Complete and Integrated Cloud Infrastructure


COMMENT 0