EKS/AKS の Automation Suite のインストールガイド

最終更新日時 2025年6月10日

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

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

インフラストラクチャ

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

管理

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

データソース

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

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 可用性グループの前提条件、制限、推奨事項」を参照してください。

外部 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 つのデータセンター間の帯域幅が広く、レイテンシが低い場合など) では、同期速度が向上します。