TOP ＞ Cloud ＞ クラウドからの即時撤収に備える15の方法（下）
関連カテゴリー： Software
クラウドからの即時撤収に備える15の方法（下）
2021/04/02
米国の往年のテレビドラマで、「M*A*S*H」というシチュエーションコメディがあった。若い世代には信じがたいかもしれないが、朝鮮戦争時に米軍の移動野戦病院（MASH）に配属された医師らを描いたコメディで、11年続いた。話の中で、戦況が変わって危険が迫り、野戦病院を急いで撤収する時には、MASHのMはMobile（移動）のMだ、と誰かが話していた。
（前回から続く）
予行演習を実施しておく
模擬的な移行を演習として実施しておくとよい。構成要素一式のコピーを、別のクラウドや社内のサーバーで稼働し、所要時間を計る。構成ファイルやソフトウエアパッケージの工夫で、スピードアップを図ることはできないだろうか。データベースの自動レプリケーションは使えないだろうか。コンテナはすべて予定どおり起動できただろうか。
実験的なプロジェクトで試す
研究開発のプロジェクトは、まずは同じクラウドと同じハードウエア構成で取りかかるのが典型的だが、新しいサービスやデータベースを使って実験するのなら、別のクラウドでも同時に試してみるとよい。
データセットに自己修復能力を取り入れておく
一連のイベントをデータベースのテーブルに一元的に記録し、信頼できる唯一の情報源として利用するアプリケーションは多い。つまりは、データベースのUPSERTSの連続だ。このイベントストリームが止まったらどうなるだろうか。一部のイベントが反復した場合はどうなるだろうか。障害に対応できるようにアーキテクチャーをデザインし、データフローが中断した場合でも、一元的な情報源としてのデータベースの一貫性を維持する必要がある。
集中を避ける
あらゆる処理に同じクラウドを利用すれば、対応がシンプルになって魅力的だが、そのクラウドが巨大な単一障害点となる。例えば、MicrosoftがGitHubを買収したことは、Azureユーザーにとっては、コードを別のリポジトリに保存した方がよいかもしれないと考え始める契機になる。少なくとも、定期的なバックアップは欠かせない。他のクラウドに関しても同じだ。
