事前作業

• To ensure cloud-native alignment, complete your data modeling and architectural reviews. データ・モデリングとアーキテクチャーについては、IBMガレージにお問い合わせください。
• Terraform、API、CLI、UIメソッド など、初期設定に最適な方法を決定する。
• ホスティングモデル を決定し、データベースのシングルまたはマルチテナントを決定します。
• [ ]データベースのデータアットレストの暗号化キーを管理するには、データベースを作成するときに 独自の暗号化キー（BYOK）を持参する 必要があります。 この設定はインスタンスのプロビジョニング後に変更することはできません。
• IAMアクセスポリシーとリソースグループ が、ビジネスプロトコルに正しく設定されていることを確認してください。
• Ensure that your account is VRF対応.
• [ ]データベースの高可用性モデルを理解してください。 これについては、各データベースの資料の「高可用性」セクションで説明されています。
• To ensure you receive messages, enroll in IBM Cloud notifications, specifically the "Resource Activity" notification. データベースのバージョンが寿命に近づくと、直接お知らせします。 さらに、データベース・バージョン・ライフサイクル・ポリシー をブックマークすることもできます。

「実動の開始」のチェックリスト例

• [ ]必要なホスティング・モデル、ディスク、RAM、仮想CPUでデータベースを作成する。 これらのスケーリング・パラメーターは最初のプロビジョニング後に変更できるが、ディスクはスケールダウンできない。

• If you would like hypervisor level isolation, or if you want to guarantee a number of vCPUs, ensure that you 分離されたコンピュート・インスタンスの提供.

• ユーザーを追加します。 Cloud Databasesインスタンスの関連ドキュメントを参照してください。

• Admin パスワードを変更する。

• Set up auto scaling policies, if appropriate. デフォルトの自動スケーリングロジックが推奨されるベースラインである。 予算とユース・ケースに合わせてこれらのパラメーターを調整してください。 推奨されるディスク・スペースは必要最小量を反映していますが、ディスク容量はバックアップとリストアをせずにスケールダウンできないことにご注意ください。 RAM と仮想 CPU (vCPU) はスケールアップおよびスケールダウンできます。 メモリーの自動スケーリングは、ディスクI/Oの使用量に基づいて動作し、ページキャッシュのパフォーマンスを最適化する。 データベースは、使用中メモリーが 100% に近づいても自動スケーリングを行いません。これは通常望ましい状態です。

  詳細については、Cloud Databasesインスタンスを参照してください。

• IBM Cloud® Monitoring IBM Cloud® Activity Tracker Event Routing IBM® Cloud Logsで監視を設定する。 少なくともアラートは有効にします。

  • IBM Cloud Monitoring- ディスク使用量がプロビジョニングされた容量の80%を超えた場合（ディスク容量にはオートスケーリングを使用することをお勧めします）。 また、ディスク入出力使用状況または CPU 使用状況などの提供されたすべてのメトリックについて、使用、把握、アラートすることをお勧めします。
  • IBM Cloud Activity Tracker Event Routing バックアップの失敗、IP許可リストの更新、自動スケーリングなどの制御プレーンアクションの監査イベント。
  • IBM Cloud Logs- 遅いクエリログなど、通知したいデータベース固有のログ。
  • 該当する場合、詳細なデータベース内監査を有効にします (Databases for PostgreSQL および Databases for MongoDB Enterprise Edition でのみ使用可能)。

• [ ]コンテキストベースの制限を設定し、アカウント所有者と管理者に、アクセス要求のコンテキストに基づいてIBM Cloud®リソースへのアクセス制限を定義し、実施する能力を与える。 詳細は コンテキストベースの制限によるCloud Databasesリソースの保護 を参照。

• プライベート・エンドポイント を設定する。 また、パブリックエンドポイントを無効にすることもできる（IBM Cloud®外部からの接続が期待されない場合は、強く推奨する）。

• データベースへの接続にアプリケーションが TLS を使用することを確認します。 Cloud Databases への安全でない接続は許可されません。

• 十分にロード・テストを繰り返します。

• アプリケーションの再接続ロジックを検証します。 一部のアプリケーションでは、再試行では不十分なので再接続する必要があります。 IBM Cloud® Databases for Redis への実装例については、記事 「Unresponsive Redis Service」を参照してください。

• 開発環境とテスト環境を別個のインスタンスとしてセットアップしてから、このチェックリストを再度確認します。 要件によっては、これらのテスト環境にIsolated Computeを使用したくないかもしれません。 Isolated Computeを使わないことで、コストを抑えることができる。

• [ ]完全な 災害復旧 テスト。 他の IBM Cloud 地域へのアプリケーション復元をテストします。 新しい接続詳細を使用して、「リストアされた」データベースに接続できることを確認してください。

  • 復旧ポイント目標（RPO）と復旧時間目標（RTO）の要件を理解し、データベースの構成でそれを満たすことができることを確認する。

データベースの UUID を解決するには、コマンドibmcloud resource search <UUID>を使用します。 他にも、ibmcloud cdb about および ibmcloud cdb cxn といった有用な CLI コマンドがあります。 詳しくは、CLI プラグイン・リファレンス資料を参照してください。