機械翻訳について

環境の計画

このトピックでは、インスタンスを作成する前に考慮すべき事項を示します。

リソースを編成するためのコンパートメント階層や、リソースにアクセスする必要があるユーザー・グループの定義など、環境を計画します。 「テナンシ設定のベスト・プラクティスの学習」を参照してください。

考慮事項 説明
追加のアイデンティティ・ドメインが必要ですか。

すべてのテナンシには、デフォルトのアイデンティティ・ドメインが付属しています。 アイデンティティ・ドメインは、ユーザー、グループおよびその他のアクセス関連情報のコンテナです。 デフォルトのアイデンティティ・ドメインでのみ作業するか、必要に応じてIAMで追加のアイデンティティ・ドメインを作成して、様々なユーザー集団を保持できます。

通常、ユーザー、ポリシーおよびロール間の分離を維持する場合は、コンプライアンス上の理由から追加のアイデンティティ・ドメインを作成します。 たとえば、複数のアイデンティティ・ドメインを作成して、次のタイプの分離を維持できます:
  • 地理間(インドのユーザーのドメインと米国のユーザーのドメインなど)。
  • サービス間(Oracle Integrationのドメインと別のサービスのドメインなど)。
  • サービスのインスタンス間(Oracle Integrationインスタンスごとに1つのドメインなど)。

IAMアイデンティティ・ドメインの詳細は、Oracle Cloud Infrastructureドキュメントの「アイデンティティ・ドメインの管理」を参照してください。

単一のドメインからの複数のインスタンスの管理

Oracle Integrationインスタンスを作成すると、アイデンティティ・ドメインに関連付けられます。 デフォルトでは、作成中にサインインしているドメインに関連付けられており、インスタンスを管理するにはそのドメインにサインインする必要があります。 異なるアイデンティティ・ドメインに複数のインスタンスが関連付けられている場合は、インスタンスを個別に各ドメインにサインインして管理する必要があります。 管理を簡素化するには、インスタンスを作成および管理するドメインを1つ選択します。 次に、インスタンスの作成時に、各インスタンスを、ユーザー移入に使用されるセカンダリ・ドメインに関連付けます。

アイデンティティ・ドメインごとに個別のコンパートメントを作成します

デフォルトのアイデンティティ・ドメインは、テナンシのルート(デフォルト)コンパートメントにあります。 そのコンパートメントまたは別のコンパートメントに追加のドメインを作成できますが、各アイデンティティ・ドメインを個別のコンパートメントに作成できます。 たとえば:
  • ルート(デフォルト)コンパートメントでは、管理者のみのデフォルト・ドメインを使用します。
  • 別のコンパートメント(たとえば、「開発」)で、開発環境でユーザーおよびグループのドメインを作成します。
  • 別のコンパートメント(たとえば、「製品」という名前)で、本番環境のユーザーおよびグループのドメインを作成します。

コンパートメントの詳細は、次の行を参照してください。
追加のコンパートメントが必要ですか。

テナンシがプロビジョニングされると、ルート・コンパートメントが作成されます。 ルート・コンパートメントには、すべてのクラウド・リソースが保持されます。 そのルート・コンパートメントの下に、リソースを編成および分離するための追加のコンパートメントを作成して、リソースへのアクセスの管理および保護を容易にします。

ポリシーを使用してリソースを保護し、ポリシーによってコンパートメントが指定されるため、コンパートメント階層を開発する際にセキュリティ要件を考慮する必要があります。 たとえば、前の行で説明したように、アイデンティティ・ドメインごとにコンパートメントを作成できます。

Oracle Cloud Infrastructureドキュメントのコンパートメントの理解およびコンパートメントを設定するためのサンプル・アプローチを参照してください。

また、コンパートメントに作成できるインスタンスの数に割当て制限を設定することもできます。 コンパートメントへのインスタンス割当ての設定を参照してください。

どのグループを設定する必要があるか。

テナンシにはAdministratorsというグループが付属しており、デフォルト管理者は自動的にこのグループに属します。 このグループは削除できません。また、常に少なくとも1人のユーザーが存在する必要があります。

Oracle Integrationへのアクセスの割当てと管理を容易にするために、IAMでグループを作成します。 個々のユーザーではなく、グループ全体にロールおよびポリシーを割り当てることができます。 つまり、Oracle IntegrationへのOracle Cloudコンソール・アクセスを制御し、Oracle Integration自体にアクセスするためのグループを作成する必要があります。 「ユーザーにアクセスする必要があるもの」を参照してください。

作成するグループのカテゴリに関するいくつかのアイデアを次に示します。
  • 組織ロール
  • 部門
  • セキュリティ・レベル
ユーザーの管理にはどのアイデンティティ・システムを使用しますか。
Oracle Integrationをどのように実装し、どのような機能が必要ですか。

Oracle Integrationの動作方法と使用可能な機能には、いくつかの要因があります。

追加機能を有効にすることもできます。
  • お知らせ- システムのお知らせは、Oracle Integrationユーザーにタイムリで重要な情報を提供します。
  • コンパートメントに作成できるOracle Integration 3インスタンスの数に対するコンパートメント割当て制限の設定。
  • データのバックアップ- Oracle Integrationインスタンス・データをエクスポートし、バックアップのために格納します。
  • 決定- 決定を使用して、非構造化ポリシー コンテンツをルール ベースの決定に変換します。.
  • 障害回復- 次の行を参照してください。
  • 拡張データ保持- エンタープライズ・エディション・インスタンスがある場合、デフォルトの32日より長いデータを保持できます。
  • ファイル・サーバー - 処理するファイルの受信ボックスおよび送信ボックスとして機能する組込みSFTPファイル・サーバーにアクセスします。
  • ヒューマン・イン・ザ・ループ- ヒューマン・イン・ループを使用して、監督、承認または例外処理のために個人を関与させます。
  • インスタンス・イベント通知- インスタンスの作成、更新または削除時やコンパートメントの変更時などのイベントについて通知されます。
  • プロセス自動化 - ビジネス・プロセスを迅速に設計、自動化および管理します。
  • Visual Builder - コーディングなしでWebアプリケーションを作成します。
ディザスタ・リカバリをどのように処理しますか。 ディザスタ・リカバリ・ソリューションを確立することで、自然災害や人的災害などの予期しない混乱が発生した場合のビジネスの継続性が保証されます。 ディザスタ・リカバリを実装するには、いくつかの方法があります。
  • 顧客管理のディザスタ・リカバリ
  • Oracle管理障害リカバリ
  • フル・スタック・ディザスタ・リカバリ

ディザスタ・リカバリ・オプションの詳細は、ディザスタ・リカバリの有効化を参照してください。

メッセージ・パックはいくつ必要ですか。

ピーク・ロードに基づいてインスタンスを正しくサイズ設定することで、リアルタイム・トランザクションとスケジュールされたバッチ処理の両方で、スムーズでスケーラブル、かつ回復力のある日々の業務を実現できます。

従量制テナンシのメッセージ・パック使用の見積りを参照してください。

Oracle Integrationインスタンスおよびファイル・サーバーにアクセスする必要があるネットワークは何ですか。

許可リストを使用して、Oracle Integrationおよびファイル・サーバーへのインバウンド・アクセスを制限できます。

「許可リストを使用したインスタンスへのアクセスの制限」を参照してください。

Oracle Integrationインスタンスのカスタム・エンドポイントは必要ですか。

Oracle Cloudコンソールで生成された元のインスタンスURLではなく、自分のホスト名(mycustom.example.orgなど)でOracle Integrationインスタンスにアクセスする必要がある場合は、カスタム・エンドポイントを設定します。

「インスタンスのカスタム・エンドポイントの構成」を参照してください。

APIゲートウェイを使用してOracle Integrationエンドポイントを管理しますか。

APIゲートウェイ・サービスを使用すると、API (統合など)を、ネットワーク内からアクセス可能なプライベート・エンドポイントとともに公開でき、インターネット・トラフィックを受け入れる場合はパブリックIPアドレスで公開できます。 エンドポイントは、API検証、リクエストとレスポンスの変換、CORS、認証と認可、およびリクエスト制限をサポートしています。

Oracle Integrationインスタンスのフロント・エンドとして単一のAPIゲートウェイを使用すると、実際には複数の統合で構成されていても、APIコンシューマおよびAPIクライアントに単一の統合APIを表示できます。 単一のAPIゲートウェイを使用して、複数のバックエンド・サービス(ロード・バランサ、コンピュート・インスタンス、OCI Functionsなど)を単一の統合APIエンドポイントにリンクできます。

APIゲートウェイを使用した統合エンドポイントの管理を参照してください。

仮想クラウド・ネットワーク(VCN)内のプライベート・リソースに接続する必要はありますか。

アウトバウンド・トラフィック(エグレス・トラフィックとも呼ばれる)は、Oracle Integrationインスタンスで発生し、組織のネットワークまたはプライベート・クラウドに移動します。 すべてのアウトバウンド・トラフィックはアダプタを介してルーティングされます。 プライベート・エンドポイントを使用している場合、アウトバウンド・トラフィックは、Oracle Cloud Infrastructure内に設定されているプライベート・チャネルにルーティングされます。 トラフィックは決してパブリック・インターネットを経由しません。

インスタンスのプライベート・エンドポイントの構成を参照してください。

Oracle Integrationは、証明書を必要とする外部サービスまたはエンドポイントに接続する必要がありますか。

ルート証明書がOracle Integrationに存在しないSSL接続を作成すると、例外エラーがスローされます。 その場合、適切な証明書をアップロードする必要があります。 証明書により、Oracle Integrationは外部サービスと接続できます。 外部エンドポイントが特定の証明書を必要とする場合は、証明書をリクエストしてOracle Integrationにアップロードします。

「外部サービスに接続するための証明書のアップロード」を参照してください。