タグ: Cloud向け開発の覚書き

クラウド向けにシステムを構築した場合、必ず自社内に開発できる体制を保持しておく。IaaSはともかく、PaaSやSaaSは仕様変更やサービス終了と無縁では居られない。仕様変更やサービス終了が告知された場合は、システムを維持するために速やかに改修する必要がある。この時に開発体制を外部に依存しているとシステムの維持に大きなリスクを負うことになる。

クラウドの外にデータをバックアップする方法を検討しておく。クラウド上のデータをローカルにダウンロードしてバックアップする場合、インターネット帯域の制約を受ける。オンプレミスなら数Gbpsの帯域を使えていた物が、インターネット経由で行う場合には数十Mbps程度になってしまう。例えローカルの環境が1Gpbsでインターネットに接続していたとしても、仮想マシン側のインターネット通信帯域は数十～数百Mbps程度でしかないため、何も考えずにフルバックアップ等していては時間がかかってしかたがない。またデータ転送量も従量課金の対象となるので無駄に代金を払うことになる。
・・・ではバックアップ無しで良いかというと、そうはいかない。パブリッククラウドを使用している場合、ベンダー側の都合でサービスの使用が変更になったり、終了したり、あるいはベンダーが事業から撤退したりと言うことが常に起こる。既にHP Helion Public Cloudも撤退しているし、VMware vCloud Airは日本市場から撤退を決めている。IaaSでサービスを終了した事業者はまだそれほど多くないが、SaaSやPaaSも含めると市場から消えたサービスはさらに増える。サービスが終了したとき、他のサービスへの移行手段としてバックアップが必ず必要になる。

最低でも三重にレプリケーションされており物理障害でデータが失われる可能性は非常に少ない。とはいえ、必ずクラウドの機能を使って仮想マシンのバックアップを取得するようにしておく。
クラウドではオペレーションミスによってデータを失う可能性はむしろ高いので注意が必要になる。管理コンソールの操作ミスによって仮想マシンやストレージを削除してしまうのは勿論、仮想OSの操作ミスでSSH接続などリモートセッションの設定を破壊してしまった場合、バックアップした仮想OSを戻す事が出来なければデータ復旧は絶望的になる。
例えば私はLinuxでapt-get upgradeを実施したときに、仮想マシンのエージェントの更新がかかり、操作ミスで設定ファイルを上書きしてしまったことがある。もちろんSSHによる接続は出来ない。クラウドの管理コンソールから新しいSSHキーを設定するも動かず、バックアップされていた仮想マシンをロールバックすることで対応した。

クラウドでもオンプレミスでも、仮想OSは物理PCに比較してディスクIOのパフォーマンスが低く、この部分がボトルネックとなりやすいです。そのために頻繁なディスクIOが発生する用途ではパフォーマンスが得られにくいという欠点があります。 クラウド上の仮想マシンでのパフォーマンス改善には、仮想ディスクへのIO負荷を如何に減らすかが、最初に検討すべき重要な要素になります。
仮想PCマシン割り当てられる揮発性ストレージ（EC2では インスタンスストア）を活用できないか検討することをお勧めします。揮発性のため仮想PCが停止した場合はデータが失われますが、専用に割り当てられており、物理PCと遜色ない速度でアクセスすることが出来ます。起動後に必要なフォルダやファイルを作成したり、シャットダウン前や低周期でファイルを退避したり、一手間必要になりますが効果も大きいです。

オンプレミスでは当たり前に使っていたこともあり、 ついリレーショナルデータベースを使いたくなります。リレーショナルデータベースは一貫性を保つために、更新処理を排他的に実行します。頻繁なファイル更新を伴い、広大なメモリ領域を必要とするために、もともと仮想マシンとは相性が悪いのです。
Amazon RDSやAzure SQLでは仮想サーバーと相性の悪いRDBをクラウド上で利用しやすいように最適化しています。ですがスケールアウトにはすぐに限界が来ます。テーブル単位でしか分散できなかったり、無制限にスケールできるというものではないという認識が必要です。
将来的にスケールアウトを考えているなら、最初からスケールアウトに適したテクノロジを採用できないか検討する必要があります。