すべてのお客様に共通の設計を採用。クラウド固有の差異（接続製品、主要サービス、データベースエンジンなど）は、再設計ではなく構成上の選択肢に過ぎません。そのため、わずか5営業日でコードから環境を構築することが可能になります。
上から絵を読む
- ユーザーとシステム連携は、erp.<顧客ドメイン>という単一の名前でアクセスし、HTTPS、TLS 1.2以上でWAFを備えたロードバランサーに到達します。これが唯一の公開アクセス経路です。
- 少なくとも3つのワーカーノード（可用性ゾーンごとに1つ）が、WebおよびAPI、投稿エンジン、ASKオペレーター、ワーカー、ジョブを実行します。ノードまたはゾーン全体がダウンすると、ユーザーへのサービス提供能力が失われます。
- 管理対象データベース（エンジンとサイズは顧客が選択可能）は、別のゾーンに同期スタンバイ構成を備えています。ゾーン障害が発生してもデータ損失は発生しません。RPO（目標復旧時点）はほぼ0です。
- 文書と添付ファイルは、データベースではなく、バージョン管理されたオブジェクトストレージに保存されます。
- 送信トラフィックはNATを経由して、許可リストに登録された宛先（銀行、税務・電子請求書、給与計算、メール、AIエンジン）にのみ送信されます。それ以外のトラフィックは送信されません。
- バックアップデータは、別のアカウントにあるエアギャップされた保管庫へ一方向に送信されます。
プライベートエンドポイントと内部ロードバランサーは、プライベートアクセスが使用されている場合にのみ存在するため、破線で表示されています。HTTPSのみのアクセスでは、これらは構築されません。
つまみは5つだけで、他には何もありません。
ノードサイズ、ノード数（最低3つ）、データベースエンジンとサイズ、Live DRリージョン、環境数。その他はすべてリファレンスアーキテクチャです。
設定、統合、そして最後にコーディングを行う。
標準を超える要件は、プラットフォームのアップグレードで対応可能な場合は構成変更によって満たされます。対応できない場合は、クラスタ外で実行されるTRANXACT APIを介した統合によって対応します。セキュリティおよびエンジニアリングレビューの後、クラスタ内のコードまたはエージェントが検討されます。承認された場合は、許容され、顧客サポートの対象となります。却下された場合は、クラスタ外で実行されます。
顧客によるデータベースへの直接アクセスは提供されていません（DB_3.1.09）。レポート作成と統合はTRANXACTのAPIと抽出を介して行われるため、BIツールもデータベースへのログインではなく、APIまたはスケジュールされた抽出によって接続されます。
カルダーウッド社のBIチームは、データウェアハウス用の読み取り専用データベースユーザーを要求しました。その解決策は、プライベートリンクを介したスケジュール抽出です。インターフェースリストのBI行は「保持、スケジュール抽出、プライベートリンク」となっています。
試してみて カルダーウッド社の月末処理中に、ゾーン2のワーカーノードが故障しました。ユーザーにはどのような影響があり、SLA（サービスレベル契約）の対象外となりますか？
そのポッドは、負荷を処理できるように設計されたゾーン1とゾーン3のノードに再スケジュールされます。ゾーン2がプライマリを保持していない限り、データベースは影響を受けません。プライマリを保持している場合は、RPO ≈ 0で同期スタンバイにフェイルオーバーします。SLAにカウントされるのは、その月の可用性がティアの目標を下回った場合のみです。