ニフクラユーザーガイド（ニフクラ設計ガイド(個別機能設計編)）

【重要なお知らせ】サービス統合に基づくサービス名称の読み替えのお願い（2024年4月1日）

2024年4月1日をもって、「ニフクラ」は、「FJcloud-V」に統合し、名称を変更しました。
当サイトのアドレス（ドメイン名）に含まれる「nifcloud.com」は現時点では変更はございませんが、
各ページに記載の「ニフクラ」「NIFCLOUD」「nifcloud」は、「FJcloud-V」に読み替えていただきますようお願いいたします。

ニフクラユーザーガイド

クラウドトップ>ユーザーガイド>ニフクラ設計ガイド(個別機能設計編)

はじめに
１．データベース
２．外部接続

はじめに

本ドキュメントの目的
- 本ドキュメントは、ニフクラでの商談対応やシステム設計を担当される方々が、ニフクラ上でのシステム設計に必要な知識を習得し、商談対応やシステム設計を円滑に行えるようになることを目的とします。
本ドキュメントの対象読者
- ニフクラを利用して商談対応、要件定義、システム設計をする方
- オンプレミスまたはクラウド(IaaS)での商談対応、要件定義、システム設計の経験者
前提知識
- システム設計/システム運用に関する基本的な知識
  - OSに関する基本的な知識
  - インターネット、イントラネットに関する基本的な知識
  - セキュリティに関する基本的な知識
  - バックアップ、監視、冗長化などシステム設計/システム運用に関する基本的な知識
    ※システム設計の経験が必要
仮想化技術に関する以下の基本的な知識
- ハイパーバイザー、仮想サーバー、仮想ストレージ、仮想ネットワークに関する基本的な知識
- VMwareに関する基本的な知識
ニフクラサービスの変更は最新のドキュメントを参照してください。

本ドキュメントで提供する内容

本ドキュメントで提供する内容
- 本ドキュメントではニフクラを通じて、商談対応や要件定義、システム設計をされる皆様に提供してきた、利用者がニフクラで設計をする際のナレッジ(実商談で培われたナレッジ)を、システムを設計する際のポイントとしてカテゴリに分類して提供します。
  ※利用者がニフクラ上でシステム設計/構築する際のナレッジを記載しています。サービスを提供するニフクラ側が作業する内容は含みません。
- 本ドキュメントで、記載しているサービスに関して利用できるゾーン、リージョンが限定されている場合があります。各サービスでの提供ゾーン/リージョンはクラウド技術仕様/制限値(共通:ゾーン別機能対応表)を確認してください。

本ドキュメントの構成

本ドキュメントは、以下の章立てで記載します。

設計のポイント

各章で検討や留意すべき特徴的な内容をポイントとして記載します。

設計ポイントの適用指針

設計のポイントで記載した内容を適用する指針を記載します。

カテゴリと留意事項

各カテゴリの作業レベルで、検討事項、留意事項を記載します。なお、オンプレミスと同様に検討できる項目については記載を省略しています。

方式設計と参考ドキュメント

各カテゴリの作業レベルで参考となる詳細ドキュメントの概要や参照先を記載します。
オンプレミスと同様に検討できる項目について
- オンプレミスと同様となる設計については、本ドキュメントでは割愛します。既存のオンプレミスの設計を参考にしてください。
  
  例：仮想マシンの中でのデータのバックアップ設計
  
  → アプリケーション設計の範囲で、既存の設計と変わりません
  
  例：サーバーのバックアップ設計
  
  → 物理サーバーのフルバックアップが仮想マシンのフルバックアップに変わるだけで、使うツールなどの方式設計は変わりますがそのバックアップの取得サイクルなどの設計は変わりません
  
  例：仮想マシンの冗長構成
  
  → OS及びアプリケーションレイヤより上の冗長化は物理サーバーやオンプレミスの仮想マシンと変わりませんが、仮想マシン自体の冗長構成例えばHigh Availability (HA)は構成する際の考慮点があります。

本ドキュメント活用のメリット

知識の習得
- 利用者がニフクラでシステムを構成する際に必要な知識を習得できます
ニフクラが提供するサービス/機能を早い段階で適用判断が可能
- 本ドキュメントで提供するナレッジを活用すると以下の効果が期待できます
  - システムに対する要求事項のうち、システム構成の課題を解決するための構成サンプルを提示可能
  - ニフクラが提供するサービスや機能を利用するか、あるいは利用者側でミドルウェアなどを手配して導入するかの判断を、商談や要件定義などの早い段階で実施可能
システム構成の手戻りを抑制可能
- ニフクラのシステム構成に関するナレッジを習得することで、システム設計の後工程になって問題が発生するような事態を抑制できます

ソフトウェアの動作確認及びライセンスの扱いについて

ニフクラでは、ニフクラが提供している製品を除き、利用者が独自に導入する製品やOSSの動作保証は行いません。利用者責任で動作確認を行ったうえで導入してください。
SQL Serverについては、ニフクラがSPLAライセンスで提供する「SQL Server」を利用する方法と、利用者自身がSA(ソフトウェアアシュアランス)つきのボリュームライセンスで保有するライセンスをLicense Mobilityでニフクラ環境に持ち込み、SQL Serverを構築する方法があります。SQL Serverを冗長化するAlwaysOn機能とその前提のWSFC機能も、利用者側で動作確認のうえ、利用してください。
※ニフクラがSPLAライセンスで提供するSQL Serverのバージョンは、ニフクラサーバータイプ・仕様「OS（選択可能）」項目の最新情報を確認してください。
Oracle Databaseに関しては、ニフクラOVMを利用してOracle Databaseライセンスを持ち込むことができる仮想サーバーを所定の方法で作成し、そのサーバーにOracle Databaseをインストールして利用できます。BYOLするOracle Databaseライセンスに関しては、利用者の責任で予めその許諾内容をご確認のうえ、適切に使用ください。

１．データベース

ニフクラ RDB 設計のポイント

データベース観点で設計する際には、以下の項目を検討してください。

検討項目	検討内容	選択値・条件
独自データベースの配備	オンプレミス環境に配備オンプレミス環境とニフクラの環境をプライベート接続サービスなどで接続し、オンプレミス環境のOracleなどのデータベースを利用可能ニフクラの仮想環境に配備要件に応じて配備場所を決定。なお、利用者が独自に導入するデータベースの製品やOSSは、利用者側で動作確認のうえ配備するソフトウェアの動作確認及びライセンスの扱いについては「ソフトウェアの動作確認及びライセンスの扱いについて」の章を参照のこと。	SAP HANAはニフクラ環境では利用不可。SAP HANA はオンプレミス環境に配備し、ニフクラ環境と連携する構成の検討が必要
ニフクラRDB利用	オンプレミス環境で実施しているような複雑なデータベースの構成設計不要パラメーターを設定するだけでデータベースの冗長化が可能なサービス自動でデータをバックアップするような便利な機能（自動バックアップ機能）も利用可能ニフクラRDBの制約条件や留意事項を参照のうえ利用者自身でデータベースを設計/構築する分のコストを勘案し、ニフクラRDBの利用可否判断をする	提供中DBは以下。 MySQL PostgreSQL
オンプレミスとの差異確認	オンプレミス環境でのデータベース設計/構築や運用/保守との違いを、本ドキュメント内「カテゴリ項目ごとの作業と留意事項」に記載している留意事項を確認するニフクラRDBを使う場合は以下が利用者でデータベースを自作する場合と、大きく異なります。留意してください。ニフクラ上で取りうるデータベースの構成 (ニフクラRDBではシングル構成、または運用/待機構成が可能) データベースのセキュリティ (アクセス制御、ユーザー管理、暗号化) データベースの監視トラブル時のリストア

検討項目

検討内容

選択値・条件

独自データベースの配備

オンプレミス環境に配備: オンプレミス環境とニフクラの環境をプライベート接続サービスなどで接続し、オンプレミス環境のOracleなどのデータベースを利用可能
ニフクラの仮想環境に配備: 要件に応じて配備場所を決定。なお、利用者が独自に導入するデータベースの製品やOSSは、利用者側で動作確認のうえ配備する

ソフトウェアの動作確認及びライセンスの扱いについては「ソフトウェアの動作確認及びライセンスの扱いについて」の章を参照のこと。

SAP HANAはニフクラ環境では利用不可。SAP HANA はオンプレミス環境に配備し、ニフクラ環境と連携する構成の検討が必要

ニフクラRDB利用

オンプレミス環境で実施しているような複雑なデータベースの構成設計不要
パラメーターを設定するだけでデータベースの冗長化が可能なサービス
自動でデータをバックアップするような便利な機能（自動バックアップ機能）も利用可能
ニフクラRDBの制約条件や留意事項を参照のうえ利用者自身でデータベースを設計/構築する分のコストを勘案し、ニフクラRDBの利用可否判断をする

提供中DBは以下。

MySQL
PostgreSQL

オンプレミスとの差異確認

オンプレミス環境でのデータベース設計/構築や運用/保守との違いを、本ドキュメント内「カテゴリ項目ごとの作業と留意事項」に記載している留意事項を確認する
ニフクラRDBを使う場合は以下が利用者でデータベースを自作する場合と、大きく異なります。留意してください。
- ニフクラ上で取りうるデータベースの構成 (ニフクラRDBではシングル構成、または運用/待機構成が可能)
- データベースのセキュリティ (アクセス制御、ユーザー管理、暗号化)
- データベースの監視
- トラブル時のリストア

ニフクラ RDB 利用例

冗長化構成

可用性が求められるシステムの場合、上図のようなアクティブ/スタンバイ構成が可能となっており、冗長化と障害時のフェイルオーバーをサポートします。

自動バックアップ

自動バックアップ設定により、指定した時間帯にバックアップが取得されます。

バックアップ取得元は以下の通りです。
- データ優先：待機系からバックアップ
自動バックアップが行えない条件があります。詳細な仕様はクラウド技術仕様/制限値(RDB:自動バックアップ)をご確認ください。

リードレプリカ

非同期レプリケーションでリードレプリカを構成できます。

独自データベース利用例（PostgreSQL）

PostgreSQLの冗長化: PostgreSQLのストリーミングレプリケーション機能を利用すると、4つの冗長化構成パターンでデータベースを構築できます。

同期／非同期	パターン
同期	①アクティブ・スタンバイ完全同期パターン
②スタンバイメモリ同期後応答パターン
非同期	③アクティブ処理後応答パターン
④アクティブメモリ処理後応答パターン

同期／非同期

パターン

同期

①アクティブ・スタンバイ完全同期パターン

②スタンバイメモリ同期後応答パターン

非同期

③アクティブ処理後応答パターン

④アクティブメモリ処理後応答パターン

いずれも、アクティブのDBサーバー異常時には、スタンバイのDBサーバーをアクティブのDBサーバーに昇格させるなどの設定をしてください。

カテゴリ項目ごとの作業と留意事項

カテゴリ項目ごとの作業概要です。

カテゴリ項目	作業	ニフクラでの作業概要
データベース	データベースサーバー構成の方式設計	データベースのサーバー構成について、信頼性などの要件を考慮して設計する。要件に応じてニフクラRDBを利用するか、データベースを個別に仮想サーバー上に構築するかを検討する。
データベース接続の方式設計	オンプレミスと同様に、業務要件やプロジェクト規模、データベースへの同時接続数、などを考慮してデータベースの接続方式について設計する
データベースデータ連携の方式設計	オンプレミスと同様に、データ連携方式について設計する
データベースセキュリティの方式設計	データベースセキュリティポリシーに準じて検討し、実装方式を設計する。データベースのセキュリティが破られ、情報が漏洩した際の対処方針についても考慮が必要。
DBMS動作規定の設定	オンプレミスと同様に、データベースを使用するアプリケーションなどで設定すべきDBMS動作規定について設計する
データベース規約の方式設計	各種データベースオブジェクトの設計や、SQLコーディングにおける規約について設計する
データベース格納の方式設計	業務グループから業務データの処理方式、使用するデータベース機能等をヒアリングし、データベースへのデータ格納方式の設計が必要。ヒアリング結果に基づいて、データベースの文字コード、パーティショニング、格納先等を決定。
データベース運用設計(定常時)	システム全体の運用・保守設計に基づき、データベースにおける正常時運用設計をする
データベース運用設計(障害時)	システム全体の運用・保守設計に基づき、データベースにおける障害時運用設計をする

カテゴリ項目

作業

ニフクラでの作業概要

データベース

データベースサーバー構成の方式設計

データベースのサーバー構成について、信頼性などの要件を考慮して設計する。
要件に応じてニフクラRDBを利用するか、データベースを個別に仮想サーバー上に構築するかを検討する。

データベース接続の方式設計

オンプレミスと同様に、業務要件やプロジェクト規模、データベースへの同時接続数、などを考慮してデータベースの接続方式について設計する

データベースデータ連携の方式設計

オンプレミスと同様に、データ連携方式について設計する

データベースセキュリティの方式設計

データベースセキュリティポリシーに準じて検討し、実装方式を設計する。
データベースのセキュリティが破られ、情報が漏洩した際の対処方針についても考慮が必要。

DBMS動作規定の設定

オンプレミスと同様に、データベースを使用するアプリケーションなどで設定すべきDBMS動作規定について設計する

データベース規約の方式設計

各種データベースオブジェクトの設計や、SQLコーディングにおける規約について設計する

データベース格納の方式設計

業務グループから業務データの処理方式、使用するデータベース機能等をヒアリングし、データベースへのデータ格納方式の設計が必要。
ヒアリング結果に基づいて、データベースの文字コード、パーティショニング、格納先等を決定。

データベース運用設計(定常時)

システム全体の運用・保守設計に基づき、データベースにおける正常時運用設計をする

データベース運用設計(障害時)

システム全体の運用・保守設計に基づき、データベースにおける障害時運用設計をする

データベースを構築する際の全般的な設計・留意事項

作業概要

データベースサーバーの構成は堅牢性、信頼性、可用性等のシステム要件をもとに設計してください。また、要件に応じてニフクラRDBを利用するか、仮想サーバー上にデータベースを構築するかを検討してください。
※以下の項目等、オンプレミスと同様に検討してください

検討項目	検討内容
全体構成	システム全体でデータベースにアクセスする要素を抽出
データベースサーバー構成	冗長化構成とスタンドアロン構成について、データ保護/退避・可用性とコストとを考慮して構成を設計する主な検討項目は以下の通りサーバー障害、データセンターのファシリティ障害に対して業務の継続性の確保パッチの適用による業務停止時間を最小化（ローリングアップデート）バックアップ処理の負荷による業務への影響の低減化（データ退避などを頻繁に実施する場合、I/O性能の低下の考慮が必要）ニフクラ上での冗長化構成に関する注意ニフクラ上では、プライベートLAN内であれば自由にIPアドレスを設定可能。^[1]そのため、冗長化構成でIPアドレスを共有する構成が可能ニフクラは共有型のディスクがないため、冗長構成を実現するためには非共有ディスク構成(データミラー型)で実装する必要あり SQL Serverを冗長化するAlwaysOn機能及び、その前提となるWSFC機能については、利用者側で動作確認のうえ利用する以下の運用やリスクが許容できる場合はスタンドアロン構成を選択可能データベースサーバーの障害、ファシリティ障害時の長時間停止 DBのストレージ障害（データのバックアップからの復旧が必要）による長時間停止パッチ適用時のデータベースサーバーの停止と起動仮想サーバーが配備された物理サーバー異常時に仮想サーバーが自動フェイルオーバーして起動するまでの時間停止 1. IPアドレスの割り当てについて禁止事項となる操作があります。詳細はニフクラ禁止事項をご確認ください。
データベース構成	以下の構成について設計が必要データベース/インスタンス構成データベースファイル構成（データベースファイル、ジャーナル、アーカイブログ等）ログファイル構成

検討項目

検討内容

全体構成

システム全体でデータベースにアクセスする要素を抽出

データベースサーバー構成

冗長化構成とスタンドアロン構成について、データ保護/退避・可用性とコストとを考慮して構成を設計する
主な検討項目は以下の通り

サーバー障害、データセンターのファシリティ障害に対して業務の継続性の確保
パッチの適用による業務停止時間を最小化（ローリングアップデート）
バックアップ処理の負荷による業務への影響の低減化（データ退避などを頻繁に実施する場合、I/O性能の低下の考慮が必要）
ニフクラ上での冗長化構成に関する注意
- ニフクラ上では、プライベートLAN内であれば自由にIPアドレスを設定可能。^[1]そのため、冗長化構成でIPアドレスを共有する構成が可能
- ニフクラは共有型のディスクがないため、冗長構成を実現するためには非共有ディスク構成(データミラー型)で実装する必要あり
- SQL Serverを冗長化するAlwaysOn機能及び、その前提となるWSFC機能については、利用者側で動作確認のうえ利用する

以下の運用やリスクが許容できる場合はスタンドアロン構成を選択可能

データベースサーバーの障害、ファシリティ障害時の長時間停止
DBのストレージ障害（データのバックアップからの復旧が必要）による長時間停止
パッチ適用時のデータベースサーバーの停止と起動
仮想サーバーが配備された物理サーバー異常時に仮想サーバーが自動フェイルオーバーして起動するまでの時間停止

1. IPアドレスの割り当てについて禁止事項となる操作があります。詳細はニフクラ禁止事項をご確認ください。

データベース構成

以下の構成について設計が必要

データベース/インスタンス構成
データベースファイル構成（データベースファイル、ジャーナル、アーカイブログ等）
ログファイル構成

ニフクラRDB利用時の設計・留意事項

作業概要

データベースサーバーの構成は堅牢性、信頼性、可用性等のシステム要件をもとに設計してください。また、要件に応じてニフクラRDBを利用するか、仮想サーバー上にデータベースを構築するかを検討してください。
※全般的な検討項目と合わせて検討してください。

留意事項	内容	選択値・条件
データベースサーバー	①DBエンジンを選択可能 ②ログイン可否ニフクラRDBを構成するサーバーのOSに対してのログイン許可されていないため、OSコマンドの操作は不可 ③IPアドレスの確保構成により複数IPアドレスの確保が必要	提供DB MySQL PostgreSQL 冗長構成、且つプライベートLAN利用時はVIP、アクティブDB用IP、スタンバイDB用IPの設定が必須
データベースサーバー構成	ニフクラRDBで構築できる構成は以下の通り ①シングル構成 ②主系‐待機系構成（データ優先タイプ）ディスクレベルで同期（完全同期）の冗長構成	フェイルオーバーやフェイルバックにかかる時間については、データベースの状態により変動冗長構成とは別にリードレプリカの作成も可能
データベース構成	①データベース/インスタンス業務システムごとにデータベースを構築することが可能 ②データベースファイル構成ニフクラRDB側で設計されており、設計担当者などで変更不能 ③ログファイル構成 ②と同様

留意事項

内容

選択値・条件

データベースサーバー

①DBエンジンを選択可能
②ログイン可否
- ニフクラRDBを構成するサーバーのOSに対してのログイン許可されていないため、OSコマンドの操作は不可
③IPアドレスの確保
- 構成により複数IPアドレスの確保が必要

提供DB

MySQL
PostgreSQL

冗長構成、且つプライベートLAN利用時はVIP、アクティブDB用IP、スタンバイDB用IPの設定が必須

データベースサーバー構成

ニフクラRDBで構築できる構成は以下の通り

①シングル構成
②主系‐待機系構成（データ優先タイプ）
- ディスクレベルで同期（完全同期）の冗長構成

フェイルオーバーやフェイルバックにかかる時間については、データベースの状態により変動
冗長構成とは別にリードレプリカの作成も可能

データベース構成

①データベース/インスタンス
- 業務システムごとにデータベースを構築することが可能
②データベースファイル構成
- ニフクラRDB側で設計されており、設計担当者などで変更不能
③ログファイル構成
- ②と同様

バックアップ／リストアに関する留意事項

作業概要

留意事項	内容	選択値・条件
バックアップからリストアした際のIPアドレスに関して	以下に留意して、データベースのバックアップ方式とリストア方式を設計が必要 ① DBスナップショット自動バックアップ自動バックアップオプションを有効にすることで、毎日、定刻にバックアップ実施手動スナップショット任意の時間にデータベースサーバーのスナップショットを取得 ②リストア上記の２つのバックアップから、データベースサーバー障害時などにリストア可能。自動バックアップからはポイントインタイムリカバリーを利用し、ある時点の情報を元にリストアが可能。ただし、リストアは新規にニフクラRDBを作成する方式のみ。グローバルIPアドレス、共通プライベートネットワークでのプライベートIPアドレスは同じにならないため、リストア後に業務システムのデータベース接続部分に変更が必要	自動バックアップの最大世代数など仕様の詳細はクラウド技術仕様/制限値(RDB:自動バックアップ)をご確認ください。

留意事項

内容

選択値・条件

バックアップからリストアした際のIPアドレスに関して

以下に留意して、データベースのバックアップ方式とリストア方式を設計が必要

① DBスナップショット

自動バックアップ

自動バックアップオプションを有効にすることで、毎日、定刻にバックアップ実施

手動スナップショット

任意の時間にデータベースサーバーのスナップショットを取得
②リストア
上記の２つのバックアップから、データベースサーバー障害時などにリストア可能。
自動バックアップからはポイントインタイムリカバリーを利用し、ある時点の情報を元にリストアが可能。ただし、リストアは新規にニフクラRDBを作成する方式のみ。グローバルIPアドレス、共通プライベートネットワークでのプライベートIPアドレスは同じにならないため、リストア後に業務システムのデータベース接続部分に変更が必要

自動バックアップの最大世代数など仕様の詳細はクラウド技術仕様/制限値(RDB:自動バックアップ)をご確認ください。

データベース利用時のセキュリティ設計・留意事項

作業概要

データベースセキュリティポリシーに準じて検討し、実装方式を設計してください。また、データベースのセキュリティが破られ、情報が漏洩した際の対処方法についても考慮してください。

ニフクラ上でデータベースを構築する際の全般的な検討項目

※全般的な検討項目と合わせて検討してください。

検討項目	検討内容
初期設定	最新のDBMSバージョンの導入、最新のセキュリティパッチの適用、通信ポートの変更、デフォルトインストール環境の変更等の考慮が必要
認証	認証方式、利用者管理、パスワード管理等の設計が必要
アクセスコントロール	アクセス権限の設定、アクセス経路の制限について設計が必要
暗号化	通信の暗号化、データの暗号化、プロシージャの暗号化について設計が必要
監査	ログの取得、ログ保全、監査ログ分析、不正アクセス検知について設計が必要
脆弱性監査	セキュリティ対策状況について稼働前の診断、定期的に診断が実施できる体制、手法等の設計が必要
バックアップ	バックアップの盗難や破壊を防ぐための対策についての設計が必要
リソース制限	サービス妨害を防ぐため、CPUリソースの制限、メモリリソースの制限、ディスクリソースの制限についての設計が必要

検討項目

検討内容

初期設定

最新のDBMSバージョンの導入、最新のセキュリティパッチの適用、通信ポートの変更、デフォルトインストール環境の変更等の考慮が必要

認証

認証方式、利用者管理、パスワード管理等の設計が必要

アクセスコントロール

アクセス権限の設定、アクセス経路の制限について設計が必要

暗号化

通信の暗号化、データの暗号化、プロシージャの暗号化について設計が必要

監査

ログの取得、ログ保全、監査ログ分析、不正アクセス検知について設計が必要

脆弱性監査

セキュリティ対策状況について稼働前の診断、定期的に診断が実施できる体制、手法等の設計が必要

バックアップ

バックアップの盗難や破壊を防ぐための対策についての設計が必要

リソース制限

サービス妨害を防ぐため、CPUリソースの制限、メモリリソースの制限、ディスクリソースの制限についての設計が必要

ニフクラRDB利用時のセキュリティ設計・留意事項

作業概要: データベースセキュリティポリシーに準じて検討し、実装方式を設計してください。また、データベースのセキュリティが破られ、情報が漏洩した際の対処方法についても考慮してください。
※ 全般的な検討項目と合わせて検討してください。

留意事項	内容	選択値・条件
初期設定	①データベースバージョン提供されている最新バージョンを選択 ②セキュリティパッチの適用セキュリティパッチを運用担当者が適用することは不可稼働中のニフクラRDBに対しては、基本的にパッチは適用しない方針が前提脆弱性対応などで、既存運用環境に対してのメンテンスは、ニフクラ側で適宜実施 ③ポート番号は変更可能 ④インストール環境ニフクラRDB側の設計のため、変更不可 ⑤インターネット接続ニフクラRDBでは、インターネット接続も可能(グローバルIPアドレスを利用可能)。グローバルネットワーク側からのアクセスが不要な場合は、DBファイアウォールでアクセス制御を実施するか、グローバルIPアドレスを利用しないオプションを使用すること	グローバルIPアドレスを利用しないオプションの付与はニフクラRDB新規作成時のみとなり、作成後の変更不可
認証	認証方式はデータベース機能として提供。利用者管理、パスワード管理についてはオンプレミスと同様の設計が必要
アクセスコントロール	アクセス経路の制限についてはDBファイアウォールで制限可能。その他の項目についてはオンプレミスと同様の設計が必要
暗号化	ニフクラで提供されているデータベースには、暗号化機能は含まず
監査	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要
脆弱性監査	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要
バックアップ	自動バックアップ、手動スナップショットと合わせて、バックアップ方式を設計が必要
リソース制限	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要

留意事項

内容

選択値・条件

初期設定

①データベースバージョン
- 提供されている最新バージョンを選択
②セキュリティパッチの適用
- セキュリティパッチを運用担当者が適用することは不可
- 稼働中のニフクラRDBに対しては、基本的にパッチは適用しない方針が前提
- 脆弱性対応などで、既存運用環境に対してのメンテンスは、ニフクラ側で適宜実施
③ポート番号は変更可能
④インストール環境
- ニフクラRDB側の設計のため、変更不可
⑤インターネット接続
- ニフクラRDBでは、インターネット接続も可能(グローバルIPアドレスを利用可能)。
  グローバルネットワーク側からのアクセスが不要な場合は、DBファイアウォールでアクセス制御を実施するか、グローバルIPアドレスを利用しないオプションを使用すること

グローバルIPアドレスを利用しないオプションの付与はニフクラRDB新規作成時のみとなり、作成後の変更不可

認証

認証方式はデータベース機能として提供。利用者管理、パスワード管理についてはオンプレミスと同様の設計が必要

アクセスコントロール

アクセス経路の制限についてはDBファイアウォールで制限可能。その他の項目についてはオンプレミスと同様の設計が必要

暗号化

ニフクラで提供されているデータベースには、暗号化機能は含まず

監査

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要

脆弱性監査

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要

バックアップ

自動バックアップ、手動スナップショットと合わせて、バックアップ方式を設計が必要

リソース制限

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要

データベース格納の方式設計

作業概要

業務グループから業務データの処理方式、使用するデータベース機能等をヒアリングし、データベースへのデータ格納方式を設計してください。
ヒアリング結果に基づいて、データベースの文字コード、パーティショニング、格納先等を決定してください。

ニフクラ上でデータベースを構築する際の全般的な検討項目
※ 全般的な検討項目と合わせて検討してください。

検討項目	検討内容
文字コード決定	データベースの文字コードを決定する
パーティショニングの検討	大規模表、履歴データを持つ表などが想定される場合には設計が必要
格納先	データベースのインストール先、データファイルの格納先を決定が必要

検討項目

検討内容

文字コード決定

データベースの文字コードを決定する

パーティショニングの検討

大規模表、履歴データを持つ表などが想定される場合には設計が必要

格納先

データベースのインストール先、データファイルの格納先を決定が必要

ニフクラRDB利用時の留意事項
※ 全般的な検討項目と合わせて検討してください

留意事項	内容
文字コード決定	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要
パーティショニングの検討	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要
格納先	データベースのインストール先及びデータファイルの格納先は、利用者が任意に設定できない

留意事項

内容

文字コード決定

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要

パーティショニングの検討

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計が必要

格納先

データベースのインストール先及びデータファイルの格納先は、利用者が任意に設定できない

データベース運用設計（定常時）

作業概要

システムの定常時運用におけるシステム起動・停止、バッチ業務、ログ管理及びユーザー管理などの方式を設計します。

	設計項目	方式設計の概要
1	データ連携運用設計	以下のデータ連携運用に関して、データの同期などを考慮して運用設計が必要分散データベース構成を用いたデータ連携（レブリケーション機能、スナップショット機能、データベース間接続）データベースユーティリティを用いたデータ連携
2	セキュリティ運用設計	データベース運用上、必要となるセキュリティ事項の運用設計が必要となるセキュリティ事項初期設定認証アクセスコントロール監査バックアップ
3	監視運用設計	データベースにおいて何らかの異常（破損、誤操作等）が発生した際に、即座に運用管理者が異常箇所の特定とその原因究明を行うことができ、それに派生する影響箇所を洗い出せるように、データベース監視設計をすること
4	性能運用設計	データベースの正常な性能を維持するための設計をすること
5	統計運用設計	データベースへの問い合わせ処理に対する応答速度を向上させるためにデータベースの統計情報の運用について、オンプレミスと同様に設計する
6	バックアップ・リストア運用設計	バックアップ・リストアにおいては、単純にデータベースのバックアップを取得し破損したデータを復元するのみでなく、必要なデータを決められた時間内に復旧できるように計画・実行し、その結果、データの整合性が保たれ、保護できる設計が必要（重要）
7	保守運用設計	テーブル再編成、インデックス再編成、データベース起動/停止、各種ログファイル管理、ジャーナルファイルとアーカイブログファイル等の運用管理、パーティションローテーション運用に伴う追加・削除運用などの運用設計をする

設計項目

方式設計の概要

データ連携運用設計

以下のデータ連携運用に関して、データの同期などを考慮して運用設計が必要

分散データベース構成を用いたデータ連携（レブリケーション機能、スナップショット機能、データベース間接続）
データベースユーティリティを用いたデータ連携

セキュリティ運用設計

データベース運用上、必要となるセキュリティ事項の運用設計が必要となるセキュリティ事項

初期設定
認証
アクセスコントロール
監査
バックアップ

監視運用設計

データベースにおいて何らかの異常（破損、誤操作等）が発生した際に、即座に運用管理者が異常箇所の特定とその原因究明を行うことができ、それに派生する影響箇所を洗い出せるように、データベース監視設計をすること

性能運用設計

データベースの正常な性能を維持するための設計をすること

統計運用設計

データベースへの問い合わせ処理に対する応答速度を向上させるためにデータベースの統計情報の運用について、オンプレミスと同様に設計する

バックアップ・リストア運用設計

バックアップ・リストアにおいては、単純にデータベースのバックアップを取得し破損したデータを復元するのみでなく、必要なデータを決められた時間内に復旧できるように計画・実行し、その結果、データの整合性が保たれ、保護できる設計が必要（重要）

保守運用設計

テーブル再編成、インデックス再編成、データベース起動/停止、各種ログファイル管理、ジャーナルファイルとアーカイブログファイル等の運用管理、パーティションローテーション運用に伴う追加・削除運用などの運用設計をする

データ連携運用（定常時）

作業概要

システムの定常時運用におけるデータ連携運用の方式を設計します。

ニフクラ上でデータベースを構築する際の全般的な検討項目
※以下の項目等、オンプレミスと同様に検討してください

検討項目	検討内容
分散データベース構成でのデータ連携	①レブリケーションによるデータ連携レプリケーション機能でデータ連携する場合は、バックアップ時にデータ不整合を発生させない運用検討が必要また、テーブル、インデックスの再編成について検討が必要 ②スナップショット機能を用いたデータ連携 ③データベース間接続でのデータ連携
データベースユーティリティを用いたデータ連携	①エクスポート/インポートによるデータ連携運用 ②ローダーを用いたデータ連携

検討項目

検討内容

分散データベース構成でのデータ連携

①レブリケーションによるデータ連携
- レプリケーション機能でデータ連携する場合は、バックアップ時にデータ不整合を発生させない運用検討が必要
- また、テーブル、インデックスの再編成について検討が必要
②スナップショット機能を用いたデータ連携
③データベース間接続でのデータ連携

データベースユーティリティを用いたデータ連携

①エクスポート/インポートによるデータ連携運用
②ローダーを用いたデータ連携

ニフクラRDB利用時の留意事項
※全般的な検討項目と合わせて検討してください

留意事項	内容	選択値・条件
分散データベース構成でのデータ連携	分散データベース構成でのデータ連携は、アクティブ/スタンバイの冗長化構成を設定するだけで利用可能外部レプリケーション機能を利用することにより、ゾーンやリージョンをまたいだレプリケーションや、ニフクラ外のDBとのレプリケーションを実現可能
データベースユーティリティを用いたデータ連携	エクスポート/インポートによるデータ連携ニフクラRDBにアクセスできるクライアントから、エクスポート/インポートを実行することが可能	OS上でのエクスポート/インポート不可 ^[2] 2. ニフクラRDB構成サーバーにOSログインできないため

留意事項

内容

選択値・条件

分散データベース構成でのデータ連携

分散データベース構成でのデータ連携は、アクティブ/スタンバイの冗長化構成を設定するだけで利用可能
外部レプリケーション機能を利用することにより、ゾーンやリージョンをまたいだレプリケーションや、ニフクラ外のDBとのレプリケーションを実現可能

データベースユーティリティを用いたデータ連携

エクスポート/インポートによるデータ連携
ニフクラRDBにアクセスできるクライアントから、エクスポート/インポートを実行することが可能

OS上でのエクスポート/インポート不可 ^[2]

2. ニフクラRDB構成サーバーにOSログインできないため

セキュリティ運用（定常時）

作業概要

システムの定常時運用におけるセキュリティ運用の方式を設計します。

ニフクラ上でデータベースを構築する際の全般的な検討項目
※以下の項目等、オンプレミスと同様に検討してください

検討項目	検討内容
初期設定	システム全体のセキュリティパッチ適用方針をもとに、最新のセキュリティパッチの状況を調査し、DBMSのセキュリティパッチ適用有無の判断、適用タイミングについて、セキュリティパッチ適用方針/手順を設計する
認証	①利用者管理：正当なアクセスのみを許可し、不正アクセスを防ぐための利用者管理方針/手順を設計する ②パスワードの管理：パスワードの不正利用によるなりすましを防ぐため、パスワード管理方針/手順を設計する
アクセスコントロール	①アクセス権限の設定：不正アクセスを防ぐため、必要最低限のアクセス権限を設定するように設計する ②アクセス経路の制限：データベース構成ファイルに対する不正行為を防ぐため、アクセス経路を制限するように設計する
監査	①ログの取得：定期的に適切な監査ログを取得し、監査ログの取得対象は適宜見直しする運用を含めて設計する ②ログ保全：監査ログを利用するにあたり、監査ログの正当性を確保できるよう、監査ログの保全方式を設計する ③監査ログ分析：不正行為の発見、追跡をするため、監査ログの分析するよう方針/手順を設計する ④不正アクセスの検知：不正アクセスを監視・監査するため、アクセスログ取得と分析方針/手順を設計する
バックアップ	パックアップデータの保全：バックアップデータの盗難や破壊を防ぐため、バックアップデータの保全方式を設計する

検討項目

検討内容

初期設定

システム全体のセキュリティパッチ適用方針をもとに、最新のセキュリティパッチの状況を調査し、DBMSのセキュリティパッチ適用有無の判断、適用タイミングについて、セキュリティパッチ適用方針/手順を設計する

認証

①利用者管理：正当なアクセスのみを許可し、不正アクセスを防ぐための利用者管理方針/手順を設計する
②パスワードの管理：パスワードの不正利用によるなりすましを防ぐため、パスワード管理方針/手順を設計する

アクセスコントロール

①アクセス権限の設定：不正アクセスを防ぐため、必要最低限のアクセス権限を設定するように設計する
②アクセス経路の制限：データベース構成ファイルに対する不正行為を防ぐため、アクセス経路を制限するように設計する

監査

①ログの取得：定期的に適切な監査ログを取得し、監査ログの取得対象は適宜見直しする運用を含めて設計する
②ログ保全：監査ログを利用するにあたり、監査ログの正当性を確保できるよう、監査ログの保全方式を設計する
③監査ログ分析：不正行為の発見、追跡をするため、監査ログの分析するよう方針/手順を設計する
④不正アクセスの検知：不正アクセスを監視・監査するため、アクセスログ取得と分析方針/手順を設計する

バックアップ

パックアップデータの保全：バックアップデータの盗難や破壊を防ぐため、バックアップデータの保全方式を設計する

ニフクラRDB利用時の留意事項
※全般的な検討項目と合わせて検討してください

留意事項	内容
初期設定	ニフクラRDBの利用者が個別にデータベースに対するセキュリティパッチ適用は不能
認証	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする
アクセスコントロール	DBファイアウォールを利用して、アクセス経路を制限をするニフクラRDBを構成するサーバーのOSに対してログインできないため、データベースが配備されたサーバーに対してのssh等のログイン制限設定は不要
監査	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする
バックアップ	パックアップデータの保全：自動バックアップ、手動スナップショットと合わせ、バックアップ方式を設計する

留意事項

内容

初期設定

ニフクラRDBの利用者が個別にデータベースに対するセキュリティパッチ適用は不能

認証

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする

アクセスコントロール

DBファイアウォールを利用して、アクセス経路を制限をする
ニフクラRDBを構成するサーバーのOSに対してログインできないため、データベースが配備されたサーバーに対してのssh等のログイン制限設定は不要

監査

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする

バックアップ

パックアップデータの保全：自動バックアップ、手動スナップショットと合わせ、バックアップ方式を設計する

データベース監視運用（定常時）

作業概要

システムの定常時運用におけるデータベース監視運用の方式を設計します。

ニフクラ上でデータベースを構築する際の全般的な検討項目
※以下の項目等、オンプレミスと同様に検討してください

検討項目	検討内容
プロセス監視	DBMSが稼働するために必要なDBMSプロセス状態について監視するよう設計が必要
状態監視	データベースファイル、データベースオブジェクト、セッション等のデータベースの状態について監視するよう設計が必要
メッセージ監視 (ログ監視)	DBMSが管理するログファイルに出力される異常メッセージについて監視するよう設計が必要
性能閾値監視	キャッシュヒット率、データベースファイルのフラグメント、アーカイブログファイルのサイズ等、性能に影響を与える項目を監視するよう設計が必要

検討項目

検討内容

プロセス監視

DBMSが稼働するために必要なDBMSプロセス状態について監視するよう設計が必要

状態監視

データベースファイル、データベースオブジェクト、セッション等のデータベースの状態について監視するよう設計が必要

メッセージ監視 (ログ監視)

DBMSが管理するログファイルに出力される異常メッセージについて監視するよう設計が必要

性能閾値監視

キャッシュヒット率、データベースファイルのフラグメント、アーカイブログファイルのサイズ等、性能に影響を与える項目を監視するよう設計が必要

ニフクラRDB利用時の留意事項
※全般的な検討項目と合わせて検討してください

留意事項	内容	選択値・条件
プロセス監視	ニフクラRDBのイベント/イベント通知機能により、異常検知等が可能	DBMSのプロセス監視不可（ニフクラRDB構成サーバーにOSログインできないため）イベント内容の詳細はクラウド技術仕様/制限値(RDB:イベント)をご確認ください。
状態監視	モニタリング機能により可能	モニタリング項目の詳細はクラウド技術仕様/制限値(RDB:モニタリング)をご確認ください。
メッセージ監視 (ログ監視)	データベースエンジンのログ監視を検討推奨コントロールパネルまたはAPIを使用し、データベースエンジンのログを閲覧することが可能	エンジンごとに確認可能なログの種別が異なります。ダウンロードできるログのサイズに制限があります。詳細はクラウド技術仕様/制限値(RDB:DBログ)をご確認ください。
性能閾値監視	モニタリング情報をAPIで取得することが可能	モニタリング自体にメール通知機能なし

留意事項

内容

選択値・条件

プロセス監視

ニフクラRDBのイベント/イベント通知機能により、異常検知等が可能

DBMSのプロセス監視不可（ニフクラRDB構成サーバーにOSログインできないため）
イベント内容の詳細はクラウド技術仕様/制限値(RDB:イベント)をご確認ください。

状態監視

モニタリング機能により可能

モニタリング項目の詳細はクラウド技術仕様/制限値(RDB:モニタリング)をご確認ください。

メッセージ監視 (ログ監視)

データベースエンジンのログ監視を検討推奨
コントロールパネルまたはAPIを使用し、データベースエンジンのログを閲覧することが可能

エンジンごとに確認可能なログの種別が異なります。
ダウンロードできるログのサイズに制限があります。
詳細はクラウド技術仕様/制限値(RDB:DBログ)をご確認ください。

性能閾値監視

モニタリング情報をAPIで取得することが可能

モニタリング自体にメール通知機能なし

データベース性能運用（定常時）

作業概要

システムの定常時運用におけるデータベース性能運用の方式を設計します。

ニフクラ上でデータベースを構築する際の全般的な検討項目
※以下の項目等、オンプレミスと同様に検討してください

検討項目	検討内容
データベース性能情報の収集	データベース性能情報収集項目について設計する例バッファキャッシュのヒット率データベースのディスク領域（フラグメント、使用量）の状況 1日当たりジャーナル量及びジャーナルアーカイブ量クリティカルなSQLの処理時間(CPU時間、I/O時間）ロック状況（デッドロックの発生状況を含む）バックアップ時間業務ピーク時のトランザクション量オプティマイザ統計情報の有無と取得された時期 DBMSの動作を規定するパラメーターなど
実現方式	収集すべき性能情報を検討後、その性能情報を収集するための実現方式（ツール、採取時間）を設計する例 OSのコマンド機能を使用運用管理ソフトウェアの機能を使用 DBMSの機能を使用

検討項目

検討内容

データベース性能情報の収集

データベース性能情報収集項目について設計する

例

バッファキャッシュのヒット率
データベースのディスク領域（フラグメント、使用量）の状況
1日当たりジャーナル量及びジャーナルアーカイブ量
クリティカルなSQLの処理時間(CPU時間、I/O時間）
ロック状況（デッドロックの発生状況を含む）
バックアップ時間
業務ピーク時のトランザクション量
オプティマイザ統計情報の有無と取得された時期
DBMSの動作を規定するパラメーターなど

実現方式

収集すべき性能情報を検討後、その性能情報を収集するための実現方式（ツール、採取時間）を設計する

例

OSのコマンド機能を使用
運用管理ソフトウェアの機能を使用
DBMSの機能を使用

ニフクラRDB利用時の留意事項
※全般的な検討項目と合わせて検討してください

留意事項	内容	選択値・条件
データベース性能情報の収集	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする
実現方式	収集すべき性能情報を検討後、その性能情報を収集するための実現方式（ツール、採取時間）を設計する例モニタリングにAPIを利用 DBMSの機能を使用本ドキュメント内「データベース監視運用（定常時）」で要件を満たせる場合は、そちらの利用も検討してください。	ニフクラRDB構成サーバーのOSに対してログイン不可（OSコマンド操作も不可）

留意事項

内容

選択値・条件

データベース性能情報の収集

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする

実現方式

収集すべき性能情報を検討後、その性能情報を収集するための実現方式（ツール、採取時間）を設計する

例

モニタリングにAPIを利用
DBMSの機能を使用

本ドキュメント内「データベース監視運用（定常時）」で要件を満たせる場合は、そちらの利用も検討してください。

ニフクラRDB構成サーバーのOSに対してログイン不可（OSコマンド操作も不可）

統計情報運用（定常時）

作業概要

システムの定常時運用における統計運用の方式を設計します。

ニフクラ上でデータベースを構築する際の全般的な検討項目
※以下の項目等、オンプレミスと同様に検討してください

検討項目

検討内容

オプティマイザとオプティマイザ統計情報

オンプレミスと同様の設計をする

オプティマイザ統計情報の運用
ニフクラRDB利用時の留意事項
※全般的な検討項目と合わせて検討してください

留意事項

内容

オプティマイザとオプティマイザ統計情報

オンプレミスと同様の設計をする

オプティマイザ統計情報の運用

検討項目	検討内容
オプティマイザとオプティマイザ統計情報	オンプレミスと同様の設計をする
オプティマイザ統計情報の運用

留意事項	内容
オプティマイザとオプティマイザ統計情報	オンプレミスと同様の設計をする
オプティマイザ統計情報の運用

バックアップリストア運用（定常時）

作業概要

システムの定常時運用におけるバックアップリストア運用の方式を設計します。

ニフクラ上でデータベースを構築する際の全般的な検討項目
※以下の項目等、オンプレミスと同様に検討してください

検討項目	検討内容
バックアップとリストア方式	要件定義におけるデータベースのバックアップリストアの定義内容を確認し、障害から復旧をする際に求められる条件を明確化したうえ、以下の項目についてバックアップ・リストア方式の設計をする ①障害から復旧までの最大許容時間 ②データ復旧ポイントの明確化 ③バックアップ取得タイミング ④バックアップ取得方法 ⑤保管方法と世代管理

検討項目

検討内容

バックアップとリストア方式

要件定義におけるデータベースのバックアップリストアの定義内容を確認し、障害から復旧をする際に求められる条件を明確化したうえ、以下の項目についてバックアップ・リストア方式の設計をする

①障害から復旧までの最大許容時間
②データ復旧ポイントの明確化
③バックアップ取得タイミング
④バックアップ取得方法
⑤保管方法と世代管理

ニフクラRDB利用時の留意事項
※全般的な検討項目と合わせて検討してください

留意事項	内容	選択値・条件
バックアップ	あらかじめ用意されている機能の利用を検討する。 ①自動バックアップバックアップ保存期間オプション、バックアップ時刻オプションを設定することで毎日、定刻にバックアップを実施 ②手動スナップショット任意の時刻にデータベースサーバーのスナップショットを取得。バックアップとして保存することも可能	バックアップ保存期間や手動スナップショット保存数の上限値等の詳細はクラウド技術仕様/制限値(RDB:DBスナップショット)をご確認ください。
リストア	あらかじめ用意されている機能の利用を検討する。 ①ポイントインタイムリカバリー ②手動スナップショットからのリストア ①、②のいずれのリストア方法もリストア後のニフクラRDBは新規作成となりIPアドレスの変更が実施される。必要に応じて変更する手順を設計する。

留意事項

内容

選択値・条件

バックアップ

あらかじめ用意されている機能の利用を検討する。

①自動バックアップ
- バックアップ保存期間オプション、バックアップ時刻オプションを設定することで毎日、定刻にバックアップを実施
②手動スナップショット
- 任意の時刻にデータベースサーバーのスナップショットを取得。バックアップとして保存することも可能

バックアップ保存期間や手動スナップショット保存数の上限値等の詳細はクラウド技術仕様/制限値(RDB:DBスナップショット)をご確認ください。

リストア

あらかじめ用意されている機能の利用を検討する。

①ポイントインタイムリカバリー
②手動スナップショットからのリストア

①、②のいずれのリストア方法もリストア後のニフクラRDBは新規作成となりIPアドレスの変更が実施される。必要に応じて変更する手順を設計する。

データベース利用時の保守運用での留意事項（定常時）

作業概要

システムの定常時運用におけるデータベース保守運用の方式を設計します。
※以下の項目等、オンプレミスと同様に検討してください

検討項目	検討内容
テーブルの再編成	一般にデータベースの利用にあたっては、データの追加/削除/更新が頻繁に行われることによって行移行や行連鎖などによりテーブルの断片化が発生、それに伴い実際に利用可能な空きブロックがばらばらに多数存在するような状態になってしまい検索時のレスポンス悪化につながるため、定期的にテーブルの再編成する運用方式を設計する
インデックスの再編成	データの削除やインデックスを構成するカラムの更新が頻繁に行われると、不要となったインデックス領域（リーフブロック）が増加するため、空きになったインデックス領域の再利用しないとインデックス領域の利用効率が悪化することにより検索性能劣化が発生するため、インデックス領域の定期的な再編成する運用方式を設計する
データベース起動/停止	データベースを起動/停止する場合、一般に他の業務や機器、他製品との依存関係があるため、依存関係を考慮したシステム全体としての起動/停止順序を検討して運用方式を設計する
各種ログファイルの管理	日々作成される各種ログファイルは一般に自動で削除されることはないため、放置すると蓄積されたログファイルによりディスク容量を圧迫、結果として業務運用に支障をきたすことも想定されるので、不要なログに対するログの切替や削除といった管理運用方式を設計する
アーカイブログファイルの運用管理	データの追加/削除/更新処理では、処理履歴をアーカイブログファイルとして履歴管理し、データベース障害が発生した際に、アーカイブログを適用し障害発生ポイントまでリストアする必要があるため、アーカイブログファイルの適切な運用管理方式を設計する
パーティションローテーションに伴う追加削除運用	パーティションを用いたローテーション運用を行う場合、パーティション追加、スプリット（分割）、削除、バックアップ等を考慮した運用方式を設計する
ユーザーアカウント・権限の変更運用	データベースを利用していたユーザーアカウントの変更に対する運用方式を設計する（例：データベース管理者の異動に伴い、データベースアカウントを作成（権限付与）、削除する場合など）
オブジェクトの変更運用	テーブル、ビュー、関数などのオブジェクトの追加、削除に伴い、領域の追加、変更、削除や、権限、統計情報の保守などが発生するため、それぞれのオブジェクトに対する変更をどのようにするかの設計をする（例：既存のデータベースに新規のテーブルが追加した場合にその表に対するアクセス権の付与等）

検討項目

検討内容

テーブルの再編成

一般にデータベースの利用にあたっては、データの追加/削除/更新が頻繁に行われることによって行移行や行連鎖などによりテーブルの断片化が発生、それに伴い実際に利用可能な空きブロックがばらばらに多数存在するような状態になってしまい検索時のレスポンス悪化につながるため、定期的にテーブルの再編成する運用方式を設計する

インデックスの再編成

データの削除やインデックスを構成するカラムの更新が頻繁に行われると、不要となったインデックス領域（リーフブロック）が増加するため、空きになったインデックス領域の再利用しないとインデックス領域の利用効率が悪化することにより検索性能劣化が発生するため、インデックス領域の定期的な再編成する運用方式を設計する

データベース起動/停止

データベースを起動/停止する場合、一般に他の業務や機器、他製品との依存関係があるため、依存関係を考慮したシステム全体としての起動/停止順序を検討して運用方式を設計する

各種ログファイルの管理

日々作成される各種ログファイルは一般に自動で削除されることはないため、放置すると蓄積されたログファイルによりディスク容量を圧迫、結果として業務運用に支障をきたすことも想定されるので、不要なログに対するログの切替や削除といった管理運用方式を設計する

アーカイブログファイルの運用管理

データの追加/削除/更新処理では、処理履歴をアーカイブログファイルとして履歴管理し、データベース障害が発生した際に、アーカイブログを適用し障害発生ポイントまでリストアする必要があるため、アーカイブログファイルの適切な運用管理方式を設計する

パーティションローテーションに伴う追加削除運用

パーティションを用いたローテーション運用を行う場合、パーティション追加、スプリット（分割）、削除、バックアップ等を考慮した運用方式を設計する

ユーザーアカウント・権限の変更運用

データベースを利用していたユーザーアカウントの変更に対する運用方式を設計する（例：データベース管理者の異動に伴い、データベースアカウントを作成（権限付与）、削除する場合など）

オブジェクトの変更運用

テーブル、ビュー、関数などのオブジェクトの追加、削除に伴い、領域の追加、変更、削除や、権限、統計情報の保守などが発生するため、それぞれのオブジェクトに対する変更をどのようにするかの設計をする（例：既存のデータベースに新規のテーブルが追加した場合にその表に対するアクセス権の付与等）

ニフクラRDB利用時の保守運用での留意事項

作業概要

システムの定常時運用におけるデータベース保守運用の方式を設計します。
※全般的な検討項目と合わせて検討してください

留意事項	内容	選択値・条件
テーブルの再編成	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする
インデックスの再編成	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする
データベース起動/停止	ニフクラRDBユーザーによる停止はできない（再起動は可能）ため、冗長構成でデータ優先を利用している場合で、ニフクラRDBでデータベースを再起動する際、通常はフェイルオーバーオプションをfalseで再起動するように設計する ^[3] 3. フェイルオーバーオプションが true の場合、再起動時に主系サーバーと待機系サーバーが入れ替わり起動されてしまうため
各種ログファイルの管理	ニフクラRDBでは運用担当者がログファイルを削除できない ^[4] 4. データベースのデータ領域の使用率が80%を超える前に領域の拡張するなどの運用設計をする
ジャーナルファイルとアーカイブログファイルの運用管理	自動バックアップオプションを有効にすることで、ジャーナルファイル、アーカイブファイルの管理を意識することなくオンラインバックアップが可能	自動バックアップオプションの条件に基づいたポイントでリストアが可能
パーティションローテーションに伴う追加削除運用	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする
ユーザーアカウント・権限の変更運用	ニフクラRDBで作成されるユーザーアカウントは、ニフクラRDB専用のユーザーアカウントのため、その他で使用するユーザーアカウントについては、ニフクラ上でデータベースを構築する際の全般的な検討項目などと併せ、オンプレミスと同様の設計をする
オブジェクトの変更運用	ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする
データベースのログを使用して任意の状態に復元	冗長化したデータベースでフェイルオーバーが発生した場合、そのデータベースを任意の時刻のデータ状態に戻すことは不可能なため、復元結果はどのようにするかの設計をする ^[5] 5. 通常稼働状態の場合でもアーカイブログなどから任意の時刻のデータ状態に戻すことはできない仕様
フェイルオーバー時の業務システムの処理に関して	異常発生後、待機系がフェイルオーバーして主系となって片系運用が開始されるまでのダウンタイムがあるため、業務システムの要件に応じてデータベース接続に対するリトライ処理されるよう、また中断した処理は再実行されるように設計をする	フェイルオーバーやフェイルバックにかかる時間については、データベースの状態により変動

留意事項

内容

選択値・条件

テーブルの再編成

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする

インデックスの再編成

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする

データベース起動/停止

ニフクラRDBユーザーによる停止はできない（再起動は可能）ため、冗長構成でデータ優先を利用している場合で、ニフクラRDBでデータベースを再起動する際、通常はフェイルオーバーオプションをfalseで再起動するように設計する ^[3]

3. フェイルオーバーオプションが true の場合、再起動時に主系サーバーと待機系サーバーが入れ替わり起動されてしまうため

各種ログファイルの管理

ニフクラRDBでは運用担当者がログファイルを削除できない ^[4]

4. データベースのデータ領域の使用率が80%を超える前に領域の拡張するなどの運用設計をする

ジャーナルファイルとアーカイブログファイルの運用管理

自動バックアップオプションを有効にすることで、ジャーナルファイル、アーカイブファイルの管理を意識することなくオンラインバックアップが可能

自動バックアップオプションの条件に基づいたポイントでリストアが可能

パーティションローテーションに伴う追加削除運用

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする

ユーザーアカウント・権限の変更運用

ニフクラRDBで作成されるユーザーアカウントは、ニフクラRDB専用のユーザーアカウントのため、その他で使用するユーザーアカウントについては、ニフクラ上でデータベースを構築する際の全般的な検討項目などと併せ、オンプレミスと同様の設計をする

オブジェクトの変更運用

ニフクラ上でデータベースを構築する際の全般的な検討項目など、オンプレミスと同様の設計をする

データベースのログを使用して任意の状態に復元

冗長化したデータベースでフェイルオーバーが発生した場合、そのデータベースを任意の時刻のデータ状態に戻すことは不可能なため、復元結果はどのようにするかの設計をする ^[5]

5. 通常稼働状態の場合でもアーカイブログなどから任意の時刻のデータ状態に戻すことはできない仕様

フェイルオーバー時の業務システムの処理に関して

異常発生後、待機系がフェイルオーバーして主系となって片系運用が開始されるまでのダウンタイムがあるため、業務システムの要件に応じてデータベース接続に対するリトライ処理されるよう、また中断した処理は再実行されるように設計をする

フェイルオーバーやフェイルバックにかかる時間については、データベースの状態により変動

データベース利用時の運用設計（障害時）

作業概要

システム全体の運用・保守設計に基づいて、データベースにおける障害時運用設計を実施します。

ニフクラ上でデータベースを構築する際の全般的な検討項目
※以下の項目等、オンプレミスと同様に検討してください

検討項目	検討内容
システム障害	DBサーバー障害、データベースファイル障害、データベースプロセス障害、データベースメモリ不足発生時の対処、対応方法について設計する
データベース性能障害	データベース性能障害が発生した際の対応方式について設計する
トランザクション障害	トランザクション障害が発生した際の障害対応方式について設計する
ヒューマンエラー障害	ヒューマンエラー障害が発生した際の障害対応方式について設計する
自然災害など	自然災害などが発生した場合の障害対応方式について設計する

検討項目

検討内容

システム障害

DBサーバー障害、データベースファイル障害、データベースプロセス障害、データベースメモリ不足発生時の対処、対応方法について設計する

データベース性能障害

データベース性能障害が発生した際の対応方式について設計する

トランザクション障害

トランザクション障害が発生した際の障害対応方式について設計する

ヒューマンエラー障害

ヒューマンエラー障害が発生した際の障害対応方式について設計する

自然災害など

自然災害などが発生した場合の障害対応方式について設計する

ニフクラ RDB 利用時の運用設計（障害時）

作業概要

システム全体の運用・保守設計に基づいて、データベースにおける障害時運用設計を実施します。

ニフクラRDB利用時の留意事項
※全般的な検討項目と合わせて検討してください

留意事項	内容	選択値・条件
システム障害に対して信頼性を向上する冗長化構成	冗長化構成を使用することで、データベースの冗長化が可能主系サーバーの利用不可を検知した場合、フェイルオーバーを行い待機系DBサーバーに切り替わる
システム障害などからのリストアに利用できるリストア機能① ポイントインタイムリカバリー	自動バックアップオプションが有効な場合、ポイントインタイムリカバリー機能を使用しデータベースのリストアが可能。自動バックアップでは、指定したバックアップ時間帯に1日1回データ全体のバックアップを行い、その後トランザクションログのバックアップを継続的に実施するため直近の状態まで戻すことが可能。リストアでは、新規のサーバーとして復元されるため、IPアドレスは元のサーバーと異なるものが設定される。 ^[6] 6. リストア前に障害となったサーバーを削除すると、バックアップファイルも削除されるため、運用設計時に注意が必要	自動バックアップオプションの条件に基づいたポイントでリストアが可能
システム障害などからのリストアに利用できるリストア機能② 手動スナップショットからのリストア	任意の時点で採取したスナップショットを利用して、その時点のデータと同じ状態のデータベースを作成可能リストアでは、ニフクラRDBは新規のサーバーとして復元されるため、IPアドレスは元のサーバーと異なるものが設定される
システム障害などからのリストアに利用できるリストア機能③ クライアントツールの利用	各DBエンジンのクライアントツールなどを利用してデータのバックアップを採取可能各DBエンジンのコマンドでバックアップしたデータをリストアすることも可能 (dumpデータのエクスポート/インポートなど)
自然災害など	ニフクラは、同一国内で複数の地域にリージョン（地域ごとのセンター）があり、自然災害などの障害対応方式の1つの例として、クライアントツールを利用してdumpデータをエクスポートし、別リージョンへ定期的に退避する設計を行うことが可能（自動バックアップのデータは利用者で別リージョンへの転送を行うことはできない）
データベースのログを使用して任意の状態に復元	冗長化したデータベースでフェイルオーバーが発生した場合、そのデータベースを任意の時刻のデータ状態に戻すことは不可能なため、復元結果はどのようにするかの設計をする ^[7] 7. 通常稼働状態の場合でもアーカイブログなどから任意の時刻のデータ状態に戻すことはできない仕様

留意事項

内容

選択値・条件

システム障害に対して信頼性を向上する冗長化構成

冗長化構成を使用することで、データベースの冗長化が可能
主系サーバーの利用不可を検知した場合、フェイルオーバーを行い待機系DBサーバーに切り替わる

システム障害などからのリストアに利用できるリストア機能①
ポイントインタイムリカバリー

自動バックアップオプションが有効な場合、ポイントインタイムリカバリー機能を使用しデータベースのリストアが可能。
自動バックアップでは、指定したバックアップ時間帯に1日1回データ全体のバックアップを行い、その後トランザクションログのバックアップを継続的に実施するため直近の状態まで戻すことが可能。
リストアでは、新規のサーバーとして復元されるため、IPアドレスは元のサーバーと異なるものが設定される。 ^[6]

6. リストア前に障害となったサーバーを削除すると、バックアップファイルも削除されるため、運用設計時に注意が必要

自動バックアップオプションの条件に基づいたポイントでリストアが可能

システム障害などからのリストアに利用できるリストア機能②
手動スナップショットからのリストア

任意の時点で採取したスナップショットを利用して、その時点のデータと同じ状態のデータベースを作成可能
リストアでは、ニフクラRDBは新規のサーバーとして復元されるため、IPアドレスは元のサーバーと異なるものが設定される

システム障害などからのリストアに利用できるリストア機能③
クライアントツールの利用

各DBエンジンのクライアントツールなどを利用してデータのバックアップを採取可能
各DBエンジンのコマンドでバックアップしたデータをリストアすることも可能
(dumpデータのエクスポート/インポートなど)

自然災害など

ニフクラは、同一国内で複数の地域にリージョン（地域ごとのセンター）があり、自然災害などの障害対応方式の1つの例として、クライアントツールを利用してdumpデータをエクスポートし、別リージョンへ定期的に退避する設計を行うことが可能（自動バックアップのデータは利用者で別リージョンへの転送を行うことはできない）

データベースのログを使用して任意の状態に復元

冗長化したデータベースでフェイルオーバーが発生した場合、そのデータベースを任意の時刻のデータ状態に戻すことは不可能なため、復元結果はどのようにするかの設計をする ^[7]

7. 通常稼働状態の場合でもアーカイブログなどから任意の時刻のデータ状態に戻すことはできない仕様

方式詳細と参考ドキュメント

掲載ドキュメント: 詳細な方式例としてCDP（クラウドデザインパターン）や、システム構成の参考事例を記載します。

設計項目	ドキュメント掲載先	ドキュメント名または本ドキュメント内のタイトル	内容
(1)ニフクラRDB	本ドキュメント内	ニフクラ RDB 利用例	可用性の観点を考慮した冗長化構成の事例を記載
CDP	RDBパターン	ニフクラRDBでデータベースを構築した事例を記載
CDP	RDB冗長化パターン	ニフクラRDBで冗長化機能を利用し、データベースサーバーの可用性を向上させる事例を記載
CDP	RDBリードレプリカパターン	ニフクラRDBでリードレプリカ機能を利用し、データベースサーバーのパフォーマンスを向上させる事例を記載
本ドキュメント内	ニフクラRDB冗長化構成障害時の動作	ニフクラRDBを利用して構築したDBサーバーに障害が発生した場合の動作について記載
本ドキュメント内	ニフクラRDBの障害時のリストアに関して	ニフクラRDBを利用して構築したDBサーバーに障害が発生し、サーバーの状態がエラーとなった際のリストアに関して記載

設計項目

ドキュメント掲載先

ドキュメント名または本ドキュメント内のタイトル

内容

(1)ニフクラRDB

本ドキュメント内

ニフクラ RDB 利用例

可用性の観点を考慮した冗長化構成の事例を記載

CDP

RDBパターン

ニフクラRDBでデータベースを構築した事例を記載

CDP

RDB冗長化パターン

ニフクラRDBで冗長化機能を利用し、データベースサーバーの可用性を向上させる事例を記載

CDP

RDBリードレプリカパターン

ニフクラRDBでリードレプリカ機能を利用し、データベースサーバーのパフォーマンスを向上させる事例を記載

本ドキュメント内

ニフクラRDB冗長化構成障害時の動作

ニフクラRDBを利用して構築したDBサーバーに障害が発生した場合の動作について記載

本ドキュメント内

ニフクラRDBの障害時のリストアに関して

ニフクラRDBを利用して構築したDBサーバーに障害が発生し、サーバーの状態がエラーとなった際のリストアに関して記載

ニフクラRDBにて冗長化構成を利用中の障害時動作

クラウド技術仕様/制限値(RDB:冗長化・フェイルオーバー)をご確認ください。

ニフクラRDBの障害時のリストア

ニフクラRDBの障害時のリストアについて

ニフクラRDBで、主系のDBに障害が発生し、サーバーの状態がエラーとなった際にとりうるリストア方式を以下に記載します。

冗長化状態／リストア方式	シングル	ニフクラRDB冗長構成	備考
手動スナップショットからリストア	リストア作業要	リストア作業不要（自動で切替）	シングル構成では、スナップショットを利用してニフクラRDBを新規作成するリストア方式冗長化構成では、フェイルオーバーで待機系が主系に切り替わるため、リストアは不要フェイルオーバー後、ある時点まで更新状況を戻したい場合、スナップショットは利用不可スナップショットを利用したリストアでは、別のニフクラRDBが生成される
自動バックアップからのリストア	シングル構成では、ポイントインタイムリカバリーを利用してニフクラRDBを新規作成するリストア方式エラーが発生したニフクラRDBを削除すると、自動バックアップのデータも削除されるため、リストアをしてからエラーとなったニフクラRDBを削除するような設計が必要冗長化構成では、フェイルオーバーで待機系が主系に切り替わるため、リストアは不要ただし、フェイルオーバー後、自動バックアップのデータを使用してデータベースをフェイルオーバー以前のある時点までの更新状況に戻すことはできないため、どのように復元するかの運用設計をする
pg_dumpなどのツールで採取したバックアップからのリストア	シングル構成では、ニフクラRDBの新規作成後にツールでリストアを実行冗長化構成では、フェイルオーバーで待機系が主系に切り替わりますので、リストアは不要フェイルオーバー後、ツールで採取したバックアップデータを流し込むことは可能

冗長化状態／リストア方式

シングル

ニフクラRDB冗長構成

備考

手動スナップショットからリストア

リストア作業要

リストア作業不要（自動で切替）

シングル構成では、スナップショットを利用してニフクラRDBを新規作成するリストア方式
冗長化構成では、フェイルオーバーで待機系が主系に切り替わるため、リストアは不要
フェイルオーバー後、ある時点まで更新状況を戻したい場合、スナップショットは利用不可
スナップショットを利用したリストアでは、別のニフクラRDBが生成される

自動バックアップからのリストア

シングル構成では、ポイントインタイムリカバリーを利用してニフクラRDBを新規作成するリストア方式
エラーが発生したニフクラRDBを削除すると、自動バックアップのデータも削除されるため、リストアをしてからエラーとなったニフクラRDBを削除するような設計が必要
冗長化構成では、フェイルオーバーで待機系が主系に切り替わるため、リストアは不要
ただし、フェイルオーバー後、自動バックアップのデータを使用してデータベースをフェイルオーバー以前のある時点までの更新状況に戻すことはできないため、どのように復元するかの運用設計をする

pg_dumpなどのツールで採取したバックアップからのリストア

シングル構成では、ニフクラRDBの新規作成後にツールでリストアを実行
冗長化構成では、フェイルオーバーで待機系が主系に切り替わりますので、リストアは不要
フェイルオーバー後、ツールで採取したバックアップデータを流し込むことは可能

ニフクラRDBのフェイルオーバー後のバックアップに関して

主系が障害時、フェイルオーバーで待機系が主系に切り替わります。
切り替わった主系が稼働開始したら、その時点のスナップショットやツールによるバックアップが可能です。

シングル構成のバックアップリストアについて

スナップショットや、DBエンジンのクライアントツールによるバックアップを行っていない場合、シングル構成では、データベースを新規作成した後、csvなどの元データをデータベースに投入していくことになります。

２．外部接続

外部接続設計のポイント

外部に存在するシステムとの接続の観点で設計する際には、以下の項目を検討してください。

検討項目	検討内容
接続形態	接続する外部システムとの間の接続形態を確認、その接続形態を実現するための手続きにかかる期間を考慮した設計をする。接続形態により、手配や工事等の作業で接続に数ヶ月を要する場合がある。外部システム/サービスとの接続形態の例インターネット接続 http/httpsで提供されているサービス(APIなど含む)、DNS、NTP等、外部サービスとの接続 ^[8] IPsecVPNによる、利用者の拠点のシステムとニフクラ内のシステムとの接続等々プライベート接続サービスを利用した閉域接続 8. セキュリティの章で記載する Trend Micro Cloud One - Workload Security なども外部サービスと接続する例となります（「ニフクラ導入・移行設計指針（共通編）Webサービス提供」参照）
外部システムの仕様	接続する外部システムの接続仕様を確認のうえ接続設計をする。外部のシステムやサービスの詳細レベルの仕様により、接続できないことが後になって判明する場合がありますので留意が必要。外部システム/サービスの接続仕様例接続先のIPアドレスの変更がありえる。 ^[9] 接続先のシステムのアクセス制御が厳しく、不特定のIPアドレスからの接続を受け付けない場合がある。 ^[10] 接続先がインターネットで提供されているサービスで、接続元のシステムがインターネットにアクセスできる必要がある。 ^[11] 接続先のシステムやサービスが、応答を返すことを保障しない。 ^[12] httpsでの接続をする際に、指定のバージョンの暗号が使えないと接続できない。 ^[13] ^[14] 9. Workload Securityのマネージャサーバーなど、外部接続先のシステムでIPアドレスの変更がありえる場合は、FQDNによるアクセスが必須。 10. 接続元のIPアドレスが属するドメインを、DNSの逆引きで確認できることが必須のケースがある。 11. ニフクラが提供するESSなどの利用では、インターネットアクセスできる環境が必要。 12. 接続元のシステムで、接続先のシステムやサービスでエラーが発生した際や無応答時の際の作り込みが必要となる。 13. セキュリティ上問題がある暗号化方式（TLSv1.1より古い暗号化方式）を使ったhttpsでは接続できない。 14. 反対に、外部接続のシステムが変更できないため、古い暗号化方式のhttpsでしか接続できない。

検討項目

検討内容

接続形態

接続する外部システムとの間の接続形態を確認、その接続形態を実現するための手続きにかかる期間を考慮した設計をする。
接続形態により、手配や工事等の作業で接続に数ヶ月を要する場合がある。

外部システム/サービスとの接続形態の例

インターネット接続
- http/httpsで提供されているサービス(APIなど含む)、DNS、NTP等、外部サービスとの接続 ^[8]
IPsecVPNによる、利用者の拠点のシステムとニフクラ内のシステムとの接続等々
プライベート接続サービスを利用した閉域接続

8. セキュリティの章で記載する Trend Micro Cloud One - Workload Security なども外部サービスと接続する例となります（「ニフクラ導入・移行設計指針（共通編）Webサービス提供」参照）

外部システムの仕様

接続する外部システムの接続仕様を確認のうえ接続設計をする。
外部のシステムやサービスの詳細レベルの仕様により、接続できないことが後になって判明する場合がありますので留意が必要。

外部システム/サービスの接続仕様例

接続先のIPアドレスの変更がありえる。 ^[9]
接続先のシステムのアクセス制御が厳しく、不特定のIPアドレスからの接続を受け付けない場合がある。 ^[10]
接続先がインターネットで提供されているサービスで、接続元のシステムがインターネットにアクセスできる必要がある。 ^[11]
接続先のシステムやサービスが、応答を返すことを保障しない。 ^[12]
httpsでの接続をする際に、指定のバージョンの暗号が使えないと接続できない。 ^[13] ^[14]

9. Workload Securityのマネージャサーバーなど、外部接続先のシステムでIPアドレスの変更がありえる場合は、FQDNによるアクセスが必須。

10. 接続元のIPアドレスが属するドメインを、DNSの逆引きで確認できることが必須のケースがある。

11. ニフクラが提供するESSなどの利用では、インターネットアクセスできる環境が必要。

12. 接続元のシステムで、接続先のシステムやサービスでエラーが発生した際や無応答時の際の作り込みが必要となる。

13. セキュリティ上問題がある暗号化方式（TLSv1.1より古い暗号化方式）を使ったhttpsでは接続できない。

14. 反対に、外部接続のシステムが変更できないため、古い暗号化方式のhttpsでしか接続できない。

外部接続設計ポイントの適用事例

ニフクラ内のシステムからインターネット上の外部システムやサービスに接続する構成例を記載します。

ニフクラ内のシステムから、外部の公開NTPサーバーに接続する構成例
- 外部NTPサーバーに接続するには、以下の図①③の通り、接続元がインターネットにアクセスできる環境が必要です。
- ニフクラで提供するサービスのうち、ESSなどは、インターネット上で提供されます。そのためESSなどを利用の際のネットワーク構成も同様に検討してください。

構成図補足

① グローバルIPを利用している仮想サーバーから外部公開のNTPへのアクセスは可能
② グローバルIPを利用していない仮想サーバーから外部公開のNTPへのアクセスは不可能
③ グローバルIPを利用していない仮想サーバーの時刻同期を行いたい場合、グローバルIPを利用している仮想サーバーを内部参照用NTPサーバーとして構築することで時刻同期可能

カテゴリ項目ごとの作業概要

カテゴリ項目ごとの作業概要です。

カテゴリ項目	作業	ニフクラでの作業概要	備考
外部接続	外部接続の方式設計	外部システムや外部サービスとの接続要件に基づいて、外部接続方式、インターフェース、通信シーケンスなどをオンプレミスと同様の設計する。本ドキュメント内「DNSサービス設計に関する留意事項」他DNS関連の説明ページではニフクラ内の利用者環境から、ニフクラがインターネット上で提供するサービスに接続する際の留意事項について記載。	本ドキュメント内の DNS関連記載箇所を参照
外部接続データ量見積	外部接続を行うにあたって必要な概算データ量を見積もり、システム全体としてのディスク容量見積もり設計に反映する。また、必要に応じ、回線速度の見積もり設計に反映する。	オンプレミスと同様の設計をする
外部接続のための各種手続き	外部接続を行うにあたり、外部システムや外部サービス等の接続先や、接続先との間のネットワークなどで必要な手続きを実施する。
外部接続システム構成設計	外部接続を行うにあたり、必要なハードウェア・ソフトウェア構成を検討し、システム全体としてのシステム構成設計に反映する。
外部接続運用設計(定常時)	システム全体の運用・保守設計に基づいて、外部接続の定常時の管理、運用方法を設計する。
外部接続運用設計(障害時)	システム全体の運用・保守設計に基づいて、外部接続の障害時の管理、運用方法を設計する。

カテゴリ項目

作業

ニフクラでの作業概要

備考

外部接続

外部接続の方式設計

外部システムや外部サービスとの接続要件に基づいて、外部接続方式、インターフェース、通信シーケンスなどをオンプレミスと同様の設計する。
本ドキュメント内「DNSサービス設計に関する留意事項」他DNS関連の説明ページではニフクラ内の利用者環境から、ニフクラがインターネット上で提供するサービスに接続する際の留意事項について記載。

本ドキュメント内の DNS関連記載箇所を参照

外部接続データ量見積

外部接続を行うにあたって必要な概算データ量を見積もり、システム全体としてのディスク容量見積もり設計に反映する。また、必要に応じ、回線速度の見積もり設計に反映する。

オンプレミスと同様の設計をする

外部接続のための各種手続き

外部接続を行うにあたり、外部システムや外部サービス等の接続先や、接続先との間のネットワークなどで必要な手続きを実施する。

外部接続システム構成設計

外部接続を行うにあたり、必要なハードウェア・ソフトウェア構成を検討し、システム全体としてのシステム構成設計に反映する。

外部接続運用設計(定常時)

システム全体の運用・保守設計に基づいて、外部接続の定常時の管理、運用方法を設計する。

外部接続運用設計(障害時)

システム全体の運用・保守設計に基づいて、外部接続の障害時の管理、運用方法を設計する。

ESS、コンテンツ配信サービス、その他に関する留意事項

作業概要: 外部システムや外部サービスとの接続要件に基づいて、外部接続方式、インターフェース、通信シーケンスなどを設計してください。

ニフクラのサービス／機能	留意事項	内容
ESS（メール配信）	ESSへのアクセス	ニフクラのESSはインターネット上で提供されるサービスのため、仮想サーバーなどのリソースからインターネット上のESSへアクセス可能なネットワーク構成が必要
コンテンツ配信サービス(CDN) Fastly J-stream CDNext	配信可能なコンテンツ	サードパーティ製のソリューションサービス何れもインターネット上で提供しており、オリジンサーバーに関してインターネット上のCDNからアクセス可能なネットワーク構成が必要。
HULFT	ファイル転送ミドルウェア（HULFT）	HULFT自体は通信経路をセキュアに保つ機能がないのでIPsec-VPN/SSL-VPNでのネットワーク構成が必要
その他	NTPサーバーの設定	ニフクラのスタンダードイメージを使用した場合、VMware Toolsによる物理サーバーとの時刻同期が無効になっているため、別途NTPサーバーを用意し作成したサーバーの時刻を同期させることが必要。^[15] 外部公開NTPサーバーと同期を行う際には、インターネットへアクセスできるネットワーク構成が必要。 15. VMware Toolsの時刻同期の有効・無効にかかわらず、一部のVMware仮想化基盤及びゲストOSにおける操作により時刻同期が行われます。詳細は VMware Toolsの時刻同期についてを確認してください。
サードパーティ製ソリューションサービス	サードパーティ製ソリューションサービスでは、製品仕様上インターネットアクセスが必要となる製品が存在するため、それらを利用する場合にはインターネットへアクセス可能なネットワーク構成が必要。「バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）」、「Trend Micro Cloud One - Workload Security」等
OSパッチなど	ニフクラ環境では各OSのパッチ適用に利用できるサービスの提供はない。インターネット上からパッチ適用する場合はインターネットへアクセス可能なネットワーク構成が必要。

ニフクラのサービス／機能

留意事項

内容

ESS（メール配信）

ESSへのアクセス

ニフクラのESSはインターネット上で提供されるサービスのため、仮想サーバーなどのリソースからインターネット上のESSへアクセス可能なネットワーク構成が必要

コンテンツ配信サービス(CDN)

Fastly
J-stream CDNext

配信可能なコンテンツ

サードパーティ製のソリューションサービス
何れもインターネット上で提供しており、オリジンサーバーに関してインターネット上のCDNからアクセス可能なネットワーク構成が必要。

HULFT

ファイル転送ミドルウェア（HULFT）

HULFT自体は通信経路をセキュアに保つ機能がないのでIPsec-VPN/SSL-VPNでのネットワーク構成が必要

その他

NTPサーバーの設定

ニフクラのスタンダードイメージを使用した場合、VMware Toolsによる物理サーバーとの時刻同期が無効になっているため、別途NTPサーバーを用意し作成したサーバーの時刻を同期させることが必要。^[15]
外部公開NTPサーバーと同期を行う際には、インターネットへアクセスできるネットワーク構成が必要。

15. VMware Toolsの時刻同期の有効・無効にかかわらず、一部のVMware仮想化基盤及びゲストOSにおける操作により時刻同期が行われます。詳細は VMware Toolsの時刻同期についてを確認してください。

サードパーティ製ソリューションサービス

サードパーティ製ソリューションサービスでは、製品仕様上インターネットアクセスが必要となる製品が存在するため、それらを利用する場合にはインターネットへアクセス可能なネットワーク構成が必要。
「バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）」、「Trend Micro Cloud One - Workload Security」等

OSパッチなど

ニフクラ環境では各OSのパッチ適用に利用できるサービスの提供はない。
インターネット上からパッチ適用する場合はインターネットへアクセス可能なネットワーク構成が必要。