[信頼性]
医療機関のために臨床システムを実行することを考えてみてください。 医師や介護人が許容できるダウンタイムはほとんどありません。 常に最高品質の治療を提供していることを保証するには、医療用 IT システムに 24 時間アクセスできる必要があります。
医師の 24 時間の要求を満たすには、アプリケーションでは、ユーザーへの影響を最小限にしながら、エラーを処理できる必要があります。 局所的なインシデントと大規模災害のどちらが発生した場合でも、アプリケーションの継続稼働を保証する方法はあるのでしょうか。
このユニットでは、アーキテクチャの設計に、信頼性の柱の要素を追加する方法について説明します。
信頼性とは
複雑なアプリケーションでは、いくつもの箇所でさまざまな規模の問題が発生する可能性があります。 個々のサーバーやハード ドライブが故障する可能性があります。 デプロイの問題により、データベースのすべてのテーブルが意図せず削除されてしまう可能性があります。 データセンター全体がアクセス不能になる可能性があります。 ランサムウェアのインシデントでは、すべてのデータが悪意を持って暗号化されてしまう可能性があります。 アプリケーションが信頼性を維持し、局所的なインシデントと広範に影響が及ぶインシデントの両方を処理できることが非常に重要です。
信頼性のための設計には、小規模なインシデントや部分的なネットワーク停止のような一時的な条件にもかかわらずアップタイムを維持することが含まれます。 各コンポーネントに高可用性を統合することで、局所的な障害をアプリケーションで確実に処理できるようになります。 このアプリケーション設計により、単一障害点が排除されます。 このような設計により、インフラストラクチャのメンテナンスの影響も最小限になります。 通常、可用性の高い設計では、インシデントの影響を迅速かつ自動的に取り除き、影響がほとんどあるいはまったくない状態でシステムが要求を処理し続けられるようにすることを目指します。
信頼性のための設計では、データ損失や大規模災害からの復旧にも重点が置かれます。 自動回復の手順によって復旧に必要な時間を短縮できますが、多くの場合、このような種類のインシデントからの復旧にはアクティブな操作が含まれます。 これらの種類のインシデントによって、結果的に多少のダウンタイムが発生したり、データが永久に失われたりする可能性があります。 ディザスター リカバリーには、実行と同じくらい入念な計画が必要です。
アーキテクチャの設計に高可用性と回復性を含めることで、ダウンタイムやデータ損失の結果として生じる金銭的損失から企業を守ることができます。 また、顧客の信頼の喪失によってビジネスの評判が失われないようにします。
信頼性のための設計により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 エンド ユーザーがシステムを "使用でき"、システムがいかなる障害からも "復旧できる" ようにすることが必要です。
高可用性アーキテクチャの構築
可用性については、コミットしているサービス レベル アグリーメント (SLA) を識別します。 アプリケーションの潜在的な高可用性機能を SLA を基準にして確認し、適切なカバレッジがある箇所と改善が必要な箇所を特定します。 目的は、停止が発生する可能性が低下するように、アーキテクチャのコンポーネントに冗長性を追加することです。
高可用性設計コンポーネントの例には、クラスタリングや負荷分散があります。
クラスタリングでは、単一の VM が協調して動作する VM のセットに置き換えられます。 1 つの VM で障害が発生するか VM がアクセス不能になったら、要求を処理できる別の VM にサービスをフェールオーバーできます。
負荷分散は、サービスの多数のインスタンスに要求を分散すると同時に、障害が発生したインスタンスを検出し、それらのインスタンスに要求がルーティングされないようにします。
障害からの復旧が可能なアーキテクチャを構築する
回復性については、想定されるデータ損失や大規模なダウンタイムのシナリオを調査する分析を実行する必要があります。 分析には、復旧戦略と、その方法ごとの、費用とメリットのトレードオフの検討結果を含める必要があります。 この演習では、組織の優先事項に関する重要な分析情報が得られます。また、アプリケーションの役割を明確にする助けとなります。 分析の結果には、アプリケーションに関する次の期間の値が含まれている必要があります。
目標復旧時点 (RPO): データ損失が許容される最大継続時間。 RPO の測定単位は量ではなく時間です。 たとえば、"30 分のデータ"、"4 時間のデータ" などです。 RPO はデータの "損失" の上限や復旧に使われ、データの "盗難" には関連しません。
目標復旧時間 (RTO): ダウンタイムが許容される最大継続時間。"ダウンタイム" は仕様によって定義されます。 たとえば、障害が発生したときに許容されるダウンタイムの継続時間が 8 時間の場合、RTO は 8 時間です。
RPO と RTO が定義されたら、バックアップ、復元、レプリケーション、回復機能を、これらの目標を達成するために自分のアーキテクチャに取り入れるように設計できます。
すべてのクラウド プロバイダーは、アプリケーションの可用性と回復性を向上させるために使用できるサービスおよび機能一式を提供します。 可能であれば、既存のサービスやベスト プラクティスを利用し、独自に作成することはできるだけ避けてください。
ハード ドライブの故障、データセンターのアクセス不能、ハッカーの攻撃はどれも可能性があります。 可用性と回復性を備えることで、顧客からの高い評判を維持することが重要です。 可用性ではネットワーク停止などの条件下で稼働状態を維持することに重点が置かれており、回復性では障害発生後のデータ取得に重点が置かれます。