アーキテクチャに関する基本的な考慮事項

マルチサイト EKS/AKS の Automation Suite のインフラストラクチャ、レイテンシ、データソース、管理、RTO、RPO に関する考慮事項。

マルチサイト デプロイと同様に、Automation Suite にも、インフラストラクチャ、レイテンシ、データ ソース、管理、回復時間の目標、回復ポイントの目標などのアーキテクチャ上重要な考慮事項があります。

インフラストラクチャ

両方のクラスターに同じハードウェアを使用することをお勧めします。ただし、Automation Suite クラスターは、違いがほとんどない類似のハードウェア構成でもおそらく動作します。異種のハードウェアでは、複雑さが増し、トラブルシューティングに時間がかかる場合があります。

管理

2 つの Automation Suite クラスターは独立しており、構成を共有しません。したがって、管理やメンテナンスのアクティビティは、各クラスターで個別に実行する必要があります。たとえば、両方のクラスターの SQL 接続文字列を更新し、証明書を個別に設定するなどの必要があります。さらに、2 つのクラスターを個別に監視し、個別にアップグレードするなどの必要があります。

データ ソース

ObjectStore を SQL データベースと組み合わせることにより、Automation Suite にインストールされた製品の状態を形成します。

SQL Server 構成

SQL Server の構成は、マルチサイト デプロイで重要な役割を果たします。SQL Server は Automation Suite の外部コンポーネントですが、Automation Suite と連動させる際に真の高可用性を実現するために、追加で必要な手順がいくつかあります。

SQL Server は、Always On 可用性グループまたはフェイルオーバー グループに構成する必要があります。両方のサイトに分散させて、一方のサイトがダウンしたときに高可用性を厳密に確保する必要があります。両方のクラスターが接続文字列で同じ SQL リスナー エンドポイントを使用する必要があります。さらに、SQL Server/データベースが複数のサブネットにまたがって分散されている場合は、接続文字列で MultiSubnetFailover=True プロパティを設定することをお勧めします。

詳細については、「 Amazon RDS での Microsoft SQL Server のリードレプリカの使用」、「 Always On 可用性グループ」および 「Always On 可用性グループの前提条件、制限、推奨事項」をご覧ください。

PostgreSQL サーバーの構成

SQL Server と同様に、PostgreSQL は Automation Suite の外部にありますが、マルチサイト デプロイで真の HA を実現するには、追加の手順がいくつか必要です。PostgreSQL は、Process Mining、Autopilot for Developers、および Temporal as a Service で使用されます。障害復旧の場合は、Autopilot for Developers をセカンダリ サイトにレプリケートする必要があります。Process Mining データベースでは、クロスサイト レプリケーションは必要ありません。TaaS はセカンダリ クラスターではサポートされていません。これは、A/P展開のプライマリ・サイトでのみサポートされます。

サイト 1 のプライマリ PostgreSQL サーバーをサイト 2 の少なくとも 1 つの読み取り専用スタンバイに物理レプリケーションして構成し、両方のクラスターを 1 つのエンドポイント経由で現在のプライマリにポイントします。障害が発生した場合は、サイト 2 スタンバイをプライマリに昇格し、サイト 2 を指すようにエンドポイントを更新します。

• マネージドサービス: フェイルオーバー中に、 Amazon RDS for PostgreSQL、 Amazon Aurora PostgreSQL Global Database、 Azure Database for PostgreSQL など、プロバイダーのクロスリージョンレプリケーションとそのエンドポイントの更新を使用します。
• 自己管理型: プライマリの前面に DNS レコード (Amazon Route 53 など) を設定し、両方のクラスターで同じアドレスが使用されるようにします。フェールオーバー時にセカンダリを指すように DNS レコードを更新します。

外部 ObjectStore の構成

外部 ObjectStore は、ノードの障害による破損の影響を受けるおそれがありません。Automation Suite から独立して、データのレプリケーションや障害復旧を実行できます。SQL Server と同様に、外部 ObjectStore も高可用性障害復旧の設定で構成する必要があります。

プライマリ ObjectStore インスタンスをプライマリ データ センターに物理的に配置し、データ同期が有効化されたセカンダリ データ センターに少なくとも 1 つのセカンダリ インスタンスを配置します。ObjectStore にロード バランサーを構成すると、両方の Automation Suite クラスターが同じエンドポイントを参照するようになります。これにより、ObjectStore の内部構成に依存しないデプロイが可能になります。

重要:

AWS S3 の場合、 マルチリージョン アクセス ポイント は Automation Suite で実行されるすべての製品に必要な S3 API をすべてサポートしているわけではありません。サポートされている API のリストの詳細については、「 サポートされている API オペレーションでのマルチリージョンアクセスポイントの使用」を参照してください。

両方のリージョンで製品/スイートごとに 2 つのバケットを作成し、同期を有効化できます。同じリージョンで実行される Automation Suite クラスターは、同じリージョン内のバケットを参照します。

回復時間の目標

RTO に関する組織のポリシーは、マルチサイト Automation Suite クラスターを設計する上で非常に重要です。目的の RTO を達成するには、以下の要素を考慮してください。

• Traffic Manager の設計。
• セカンダリ/パッシブ クラスター内のノードの可用性。
• セカンダリ クラスターでの動的なワークロード (ML スキルなど) の可用性。
• 構成管理。

Traffic Manager

両方のクラスターの能力を最大限に引き出すには、Traffic Manager を適切に構成することがきわめて重要です。この設定では理論上、トラフィックを両方のクラスターに容易に分散できます。この戦略により、負荷がバランス良く分散されるだけでなく、ビジネスの継続性も保護され、どちらかのサイトが完全にシャットダウンした場合に事業が中断される可能性も低減されます。

ノードの可用性

障害が発生して一方のサイトが完全に動作しなくなった場合にビジネス オートメーションが影響を受けないよう、もう一方のサイトには十分なキャパシティが必要です。機能しているサイトのキャパシティが不十分な場合、事業の運営に悪影響が及び、事業にとって重大な問題につながる可能性があります。

動的なワークロードの可用性

AI Center などの一部の製品では、ML スキルを実行時に動的にデプロイします。別のクラスターへのスキルのデプロイは常に非同期です。そのため、スキルの可用性を保証できません。適切な時間内にオートメーション ソリューションがオンラインに戻るようにするには、別のクラスターでスキルを定期的に同期します。

構成の管理

Automation Suite のマルチサイト デプロイは 2 つの異なるクラスターで構成されるため、一方のクラスターで実行される操作を他方のクラスターで遅延なく実行してずれを減らす必要があります。これにより、両方のクラスターの構成がほぼ同じになり、回復に費やす労力を抑えることができます。

回復ポイントの目標

回復ポイントの目標 (RPO) に関する組織のポリシーは、マルチサイト Automation Suite クラスターを設計する上で非常に重要です。目的の RPO を達成するには、以下の要素を考慮する必要があります。

• データ同期
• スケジュールされたバックアップ

データの同期

プライマリ データ ソースにデータを書き込む際には、データをセカンダリ クラスターにも同期する必要があります。しかし、データセンターがダウンしてデータが同期されない場合は、データ損失のリスクがあります。模範的なネットワーク構成 (2 つのデータセンター間の帯域幅が広く、レイテンシが低い場合など) では、同期速度が向上します。

スケジュールされたバックアップ

すべての障害復旧でデータの損失が完全に解消するわけではありません。しかし、一定間隔の定期的なバックアップ戦略をデプロイすれば、障害がデータ復旧に与える影響を最小限に抑えることができます。詳細については、「 クラスターをバックアップおよび復元する」をご覧ください。