出発点は、ワークフロープロセス、コンポーネントディレクトリ、そして複製されないデータベースの全ての要素を、高可用性インフラ上でホスティングすることだ。そのため、こうした要素は結局、社内で保守することが多くなる。「複製できないものは、頑丈にすべし」というのが、ここでの合言葉だ。それには、冗長電源やネットワーク接続の信頼性を慎重に分析することなども含まれる。

　アプリケーション機能をコンポーネント化して可用性を最大限に高める場合、留意すべき点がある。「別々にホスティングされるコンポーネントの数が増えれば、通常、可用性は低下する」ということだ。従って、実行時のコンポーザビリティ（コンポーネントの結合性）を犠牲にしてでも、コンポーネント化には制限を設けるのが賢明かもしれない。アプリケーションはモジュール式のソフトウェア標準に合わせて開発できる。だが、展開されたアプリケーションの要素には複数のコンポーネントが含まれている可能性がある。そのため、ホスティングポイントを少なくして、より高い信頼性を確保することが求められる。

　コンポーネントの数を減らしても、コンポーネントのホスティングリソースに障害が発生すれば、オペレーションは維持できない。そこで登場するのが、選択的冗長性の概念だ。選択的冗長性とは、「一部のコンポーネントを、異なるホストプラットフォーム（別々のクラウド、あるいはクラウドとデータセンターの組み合わせも可）に複製しておくことで、どんなときにも少なくとも1つのコピーは確実に利用できるようにしておく」という考え方だ。ここで「選択的」というのは、データベースの更新時にステート（状態）の損失や衝突を起こすことなく複数の処理経路を正しく調整できるのがワークフロー内の特定の箇所に限られるからだ。こうした箇所を見つけ、冗長性を持たせれば、可用性を高められる。ただし、クラウドサービスは地理的な多様性を生かして構成する必要があることや、クラウドデータセンターと主要データセンターが同じ大都市圏にある場合は完全に冗長とはいえない点などに留意が必要だ。

　選択的冗長性を確保するために検討しているアプリケーションコンポーネント間のインタフェースが、REST（Representational State Transfer）型でステートレス（Stateless）であれば、複数のコンポーネントを並列につなぐ方法が比較的簡単で手っ取り早い。フェイルオーバーが行われる場合、ステートを維持するためにクライアント／ユーザー要素に頼れるからだ。ただし、ステートフル（Stateful）なサービス指向アーキテクチャやSOAP（Simple Object Access Protocol）が使われている場合は、単にコンポーネントを複製しただけでは解決策にならない可能性がある。障害は少なくともその時点のセッションやトランザクションをほぼ確実に中断させるからだ。この点が問題となるなら、後述する高信頼性処理を検討するといい。

　選択的冗長性を確保できるか否かの判断には、クラウドバースティングを考えるのが有効だ。クラウドバースティングとは、負荷がピークに達したときにクラウドを使って作業負荷をオフロードすることである。クラウドバースティングを機能させるための仕組みと、可用性向上のために選択的冗長性を確保するのに必要となる仕組みは同じであり、それには負荷分散の他、集約とシリアル化のフェーズが含まれる（データベースの更新はここで管理される）。単一障害点を作ることなく分散型負荷分散を導入する方法は、ドメインネームシステム（DNS）も含め、幾つかある。だが、クラウドバースティングや冗長性によって、全体的な可用性を低下させるのではなく確実に向上させるためには、多くの場合、アプリケーションの負荷分散とシリアル化の両要素を高可用性として構成する必要があるはずだ。

　アプリケーション設計者の大半は、フェイルオーバー時のトランザクションのステート管理が極めて複雑になり得ることを知っている。高信頼性トランザクション処理や高信頼性セッション処理などと呼ばれる機能を搭載するには、特別なワークフローの設計が必要となるであろうこともだ。一連の協調的な処理が必要となるアプリケーションにおいては、フェイルオーバー時にプロセスのコンテキストが維持される必要がある。さもなければ、アクティビティがコンテキストを失い、データベース（およびユーザー）は不安定な状態で放置されることになりかねないからだ。

　従来の一般的なオンライントランザクション処理（OLTP）では、並列データベースを管理して高可用性を確保するのに、同時更新やマルチフェーズでのコミットなどの方法が用いられる。だがときには、単一の高可用性コンポーネントでは希望するレベルの可用性を実現できないことや、コンポーネントの複数のコピー間でステートレスな負荷分散を行えないこともある。こうした場合には、マルチフェーズコミットなど、アプリケーションレベルのステート同期化を用いれば、トランザクションやデータベースの整合性を失うことなくクラウド障害から復旧できる。ただし、この方法はアプリケーションのコストや複雑度まで増大させる可能性がある。

　動画や音声通話も含め、セッションアクティビティの信頼性は、プロセスのステートを記録するデータベースロギングを提供することによって高められる場合もある。プロセスのステートを記録することによって、障害で引き起こされた新しいコンポーネントがステートを復元し、ユーザーへの影響を減らせるようにするのだ。こうした機能強化は、コラボレーティブアプリケーションやユニファイドコミュニケーションにとっては極めて重要なものとなりそうだ。実際、WebRTC（Web Real-Time Communications）などの技術を用いて通信セッションとWebアプリケーションを統合する傾向が強まる中で、こうした機能の採用も進んでいる。

　多くのユーザーは、クラウドによって多様性とシステム障害対策が自動的に提供されると考えている。だが実際には、クラウド各社が用意している可用性管理のための特別な設備でさえ、クラウド障害からユーザーを守れるとは限らないのが現実だ。アプリケーションの設計段階で事前に対策を講じることは、ITシステムで管理するのと同じくらい効果的に可用性を管理できるクラウドアプリケーションを開発する上で大いに役立つはずだ。それに、企業が受け入れられるアプローチは結局、それしかない。