本文へジャンプします。

TOP

ニフクラSEハンドブック

クラウド トップ>SEハンドブック>ニフクラ個別設計・移行設計指針

ニフクラ個別設計・移行設計指針

目次

ドキュメント情報

区分

設計

リリース日

2023年02月27日

留意事項

2023年01月 時点の機能をもとに作成しております。
機能は順次エンハンスされますので、検討時にはニフクラホームページにて最新情報を確認ください。

■ニフクラホームページ

https://pfs.nifcloud.com/

はじめに

  • 本ドキュメントの目的

    • 本ドキュメントは、ニフクラでの商談対応やシステム設計を担当される方々が、ニフクラ上でのシステム設計に必要な知識を習得し、商談対応やシステム設計を円滑に行えるようになることを目的とします。

  • 本ドキュメントの対象読者

    • ニフクラを利用して商談対応、要件定義、システム設計をする方

    • オンプレミスまたはクラウド(IaaS)での商談対応、要件定義、システム設計の経験者

  • 前提知識

    • システム設計/システム運用に関する基本的な知識

      • OSに関する基本的な知識

      • インターネット、イントラネットに関する基本的な知識

      • セキュリティに関する基本的な知識

      • バックアップ、監視、冗長化などシステム設計/システム運用に関する基本的な知識
        ※システム設計の経験が必要

  • 仮想化技術に関する以下の基本的な知識

    • ハイパーバイザー、仮想サーバー、仮想ストレージ、仮想ネットワークに関する基本的な知識

    • VMwareに関する基本的な知識

  • ニフクラサービスの変更は最新のドキュメントを参照してください。

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

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

    • 本ドキュメントではニフクラを通じて、商談対応や要件定義、システム設計をされる皆様に提供してきた、利用者がニフクラで設計をする際のナレッジ(実商談で培われたナレッジ)を、システムを設計する際のポイントとしてカテゴリに分類して提供します。
      ※利用者がニフクラ上でシステム設計/構築する際のナレッジを記載しています。サービスを提供するニフクラ側が作業する内容は含みません。

    • 本ドキュメントで、記載しているサービスに関して利用できるゾーン、リージョンが限定されている場合があります。各サービスでの提供ゾーン/リージョンは 最新のニフクラ仕様ページを確認してください。

  • 記載内容の粒度

    • ナレッジとして記載した情報の粒度は、実際の商談対応や要件定義、システム設計の問い合わせに対する回答の粒度です。具体的には、以下のような問い合わせに対する回答を集約して、ナレッジとして記載しています。

      • [Q]ニフクラでOracleは利用できるか。

      • [A]ニフクラOVMを利用して、Oracle Databaseライセンスを持ち込むことができる仮想サーバーを所定の方法で作成し、そのサーバーにOracle Databaseをインストールして利用できます。

本ドキュメントの構成

  • 本ドキュメントは、以下の章立てで記載します。 設計のポイント: 各章で検討や留意すべき特徴的な内容をポイントとして記載します。

    設計ポイントの適用事例

    設計のポイントで記載した内容を適用した事例を記載します。各章の記載内容をかいつまんで把握したい場合は、適用事例まで参照してください。

    カテゴリと留意事項

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

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

    各カテゴリの作業レベルで参考となる詳細ドキュメントの概要や参照先を記載します。

  • オンプレミスと同様に検討できる項目について

    • オンプレミスと同様となる設計については、本ドキュメントでは割愛します。既存のオンプレミスの設計を参考にしてください。

      例：仮想マシンの中でのデータのバックアップ設計

      → アプリケーション設計の範囲で、既存の設計と変わりません

      例：サーバーのバックアップ設計

      → 物理サーバーのフルバックアップが仮想マシンのフルバックアップに変わるだけで、使うツールなどの方式設計は変わりますがそのバックアップの取得サイクルなどの設計は変わりません

      例：仮想マシンの冗長構成

      → OS及びアプリケーションレイヤより上の冗長化は物理サーバーやオンプレミスの仮想マシンと変わりませんが、仮想マシン自体の冗長構成例えばHigh Availability (HA)は構成する際の考慮点があります。

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

  • 知識の習得

    • 利用者がニフクラでシステムを構成する際に必要な知識を習得できます

  • ニフクラが提供するサービス/機能を早い段階で適用判断が可能

    • 本ドキュメントで提供するナレッジを活用すると以下の効果が期待できます

      • システムに対する要求事項のうち、システム構成の課題を解決するための構成サンプルを提示可能

      • ニフクラが提供するサービスや機能を利用するか、あるいは利用者側でミドルウェアなどを手配して導入するかの判断を、商談や要件定義などの早い段階で実施可能

  • システム構成の手戻りを抑制可能

    • ニフクラのシステム構成に関するナレッジを習得することで、システム設計の後工程になって問題が発生するような事態を抑制できます

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

  • ニフクラでは、ニフクラが提供している製品を除き、利用者が独自に導入する製品やOSSの動作保証は行いません。利用者責任で動作確認を行ったうえで導入してください。

  • SQL Serverについては、ニフクラがSPLAライセンスで提供する「SQL Server」（2016 SE SP2、2017 SE、2019 SE）を利用する方法と、利用者自身がSA(ソフトウェアアシュアランス)つきのボリュームライセンスで保有するライセンスをLicense Mobilityで ニフクラ 環境に持ち込み、SQL Serverを構築する方法があります。SQL Serverを冗長化するAlwaysOn機能とその前提のWSFC機能も、利用者側で動作確認のうえ、利用してください。

  • Oracle Databaseに関しては、ニフクラOVMを利用してOracle Databaseライセンスを持ち込むことができる仮想サーバーを所定の方法で作成し、そのサーバーにOracle Databaseをインストールして利用できます。BYOLするOracle Databaseライセンスに関しては、利用者の責任で予めその許諾内容をご確認のうえ、適切に使用ください。

アイコンの説明

  • 本ドキュメント構成図に使用されているアイコンは下記の通りとなります。

  • リージョン及びゾーンについて特に記載がなければ、単一リージョン、単一ゾーン構成を示します。

  • 構成図内の名称は略称で記載されている場合があります。（下記()内が略称の例）

image

image

ガイダンス

カテゴリー「設計」は必要な観点によって5つのドキュメントに分類しています。確認して必要なドキュメント/章を参照してください。

設計時に必要な観点
個別に設計する際に必要な観点

  • 本ドキュメントの下記章を参照

    • 1. データベース

    • 2. 外部接続

    • 3. 移行

移行について
運用・保守について
構成サンプル

１．データベース

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

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

検討項目

検討内容

選択値・条件

独自データベースの配備
オンプレミス環境に配備

オンプレミス環境とニフクラの環境をプライベート接続サービスなどで接続し、オンプレミス環境のOracleなどのデータベースを利用可能

ニフクラの仮想環境に配備

要件に応じて配備場所を決定。なお、利用者が独自に導入するデータベースの製品やOSSは、利用者側で動作確認のうえ配備する

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

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

ニフクラRDB利用

  • オンプレミス環境で実施しているような複雑なデータベースの構成設計不要

  • パラメーターを設定するだけでデータベースの冗長化が可能なサービス

  • 自動でデータをバックアップするような便利な機能（自動バックアップ機能）も利用可能

  • ニフクラRDBの制約条件や留意事項を参照のうえ利用者自身でデータベースを設計/構築する分のコストを勘案し、ニフクラRDBの利用可否判断をする

提供中DBは以下。

  • MySQL

  • PostgreSQL

  • MariaDB[1]

1. 現在提供中のMariaDBは、2023年03月29日に新規申込受け付けを終了します。詳しくはサービスアクティビティのお知らせ（inf-000811 2023/01/13）を確認してください。

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

  • オンプレミス環境でのデータベース設計/構築や運用/保守との違いを、本ドキュメント内「カテゴリ項目ごとの作業と留意事項」に記載している留意事項を確認する

  • ニフクラRDBを使う場合は以下が利用者でデータベースを自作する場合と、大きく異なります。留意してください。

    • ニフクラ上で取りうるデータベースの構成 (ニフクラRDBではシングル構成、または運用/待機構成が可能)

    • データベースのセキュリティ (アクセス制御、ユーザー管理、暗号化)

    • データベースの監視

    • トラブル時のリストア
ニフクラ RDB 利用例

image

冗長化構成

可用性が求められるシステムの場合、上図のようなアクティブ/スタンバイ構成で構築可能です。
冗長化と障害時のフェイルオーバーをサポートします。冗長化のタイプは、データ優先/性能優先の2つから選択可能です。性能優先はMySQLのみ利用可能です。
※現在提供中の冗長構成（性能優先）は、2023年03月29日に新規申込受け付けを終了します。詳しくはサービスアクティビティのお知らせ（inf-000811 2023/01/13）を確認してください。

自動バックアップ

自動バックアップ設定により、指定した時間帯に、1日1回全データのバックアップが取得されます。最大10日間保存可能です。全データバックアップ後、トランザクションログを継続的にバックアップします。

  • 冗長構成の種別によりバックアップ取得元が異なります。

    • 性能優先：主系からバックアップ

    • データ優先：待機系からバックアップ

  • 下記の場合は自動バックアップが行われません。

    • DBエンジンがPostgreSQLかつ、DBサーバーのステータスが不正なDBパラメーターの場合。

    • 24時間以内に作成された自動バックアップが存在する場合。

リードレプリカ

非同期レプリケーションでリードレプリカを構成できます。1台のニフクラRDBに対して最大5台のリードレプリカを作成可能です。

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

image

PostgreSQLの冗長化

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

同期／非同期

パターン

同期

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

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

非同期

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

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

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

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

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

カテゴリ項目

作業

ニフクラでの作業概要

データベース

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

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

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

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

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

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

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

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

DBMS動作規定の設定

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

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

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

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

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

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

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

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

システム全体の運用・保守設計に基づき、データベースにおける障害時運用設計をする
データベースを構築する際の全般的な設計・留意事項
作業概要

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

検討項目

検討内容

全体構成

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

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

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

  • サーバー障害、データセンターのファシリティ障害に対して業務の継続性の確保

  • パッチの適用による業務停止時間を最小化（ローリングアップデート）

  • バックアップ処理の負荷による業務への影響の低減化（データ退避などを頻繁に実施する場合、I/O性能の低下の考慮が必要）

  • ニフクラ上での冗長化構成に関する注意

    • ニフクラ上では、プライベートLAN内であれば自由にIPアドレスを設定可能。[2]そのため、冗長化構成でIPアドレスを共有する構成が可能

    • ニフクラは共有型のディスクがないため、冗長構成を実現するためには非共有ディスク構成(データミラー型)で実装する必要あり

    • SQL Serverを冗長化するAlwaysOn機能および、その前提となるWSFC機能については、利用者側で動作確認のうえ利用する

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

  • データベースサーバーの障害、ファシリティ障害時の長時間停止

  • DBのストレージ障害（データのバックアップからの復旧が必要）による長時間停止

  • パッチ適用時のデータベースサーバーの停止と起動

  • 仮想サーバーが配備された物理サーバー異常時に仮想サーバーが自動フェイルオーバーして起動するまでの時間停止

2. ネットワークインターフェースあたり100個以上のIPアドレスを割り当てることは禁止事項となります。

データベース構成

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

  • データベース/インスタンス構成

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

  • ログファイル構成
ニフクラRDB利用時の設計・留意事項
作業概要

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

    留意事項

    内容

    選択値・条件

    データベースサーバー

    • ①DBエンジンを選択可能

    • ②ログイン可否

      • ニフクラRDBを構成するサーバーのOSに対してのログイン許可されていないため、OSコマンドの操作は不可

    • ③IPアドレスの確保

      • 構成により複数IPアドレスの確保が必要

    提供DB

    • MySQL

    • PostgreSQL

    • MariaDB[3]

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

    3. 現在提供中のMariaDBは、2023年03月29日に新規申込受け付けを終了します。詳しくはサービスアクティビティのお知らせ（inf-000811 2023/01/13）を確認してください。

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

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

    • ①シングル構成

    • ②主系‐待機系構成（データ優先タイプ）

      • ディスクレベルで同期（完全同期）の冗長構成

    • ③主系‐待機系構成（性能優先タイプ）[4]

      • DBエンジンがMySQLの場合のみ利用が可能

      • DBサーバーレベルで同期（非同期）での冗長構成。待機系側DBはリードレプリカとして利用することが可能
        冗長構成とは別にリードレプリカの作成も可能

    4. 現在提供中の冗長構成（性能優先）は、2023年03月29日に新規申込受け付けを終了します。詳しくはサービスアクティビティのお知らせ（inf-000811 2023/01/13）を確認してください。

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

    データベース構成

    • ①データベース/インスタンス

      • 業務システムごとにデータベースを構築することが可能

    • ②データベースファイル構成

      • ニフクラRDB側で設計されており、設計担当者などで変更不能

    • ③ログファイル構成

      • ②と同様
バックアップ／リストアに関する留意事項
作業概要

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

留意事項

内容

選択値・条件

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

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

  • ① DBスナップショット

    自動バックアップ

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

    手動スナップショット

    任意の時間にデータベースサーバーのスナップショットを取得

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

自動バックアップ最大世代数：10世代
データベース利用時のセキュリティ設計・留意事項
作業概要

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

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

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

検討項目

検討内容

初期設定

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

認証

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

アクセスコントロール

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

暗号化

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

監査

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

脆弱性監査

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

バックアップ

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

リソース制限

サービス妨害を防ぐため、CPUリソースの制限、メモリリソースの制限、ディスクリソースの制限についての設計が必要
ニフクラRDB利用時のセキュリティ設計・留意事項
作業概要

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

留意事項

内容

選択値・条件

初期設定

  • ①データベースバージョン

    • 提供されている最新バージョンを選択

  • ②セキュリティパッチの適用

    • セキュリティパッチを運用担当者が適用することは不可

    • 稼働中のニフクラRDBに対しては、基本的にパッチは適用しない方針が前提

    • 脆弱性対応などで、既存運用環境に対してのメンテンスは、ニフクラ側で適宜実施

  • ③ポート番号は変更可能

  • ④インストール環境

    • ニフクラRDB側の設計のため、変更不可

  • ⑤インターネット接続

    • ニフクラRDBでは、インターネット接続も可能(グローバルIPアドレスを利用可能)。グローバルネットワーク側からのアクセスが不要な場合は、DBファイアウォールでアクセス制御を実施するか、グローバルIPアドレスを利用しないオプションを使用すること
ポート番号デフォルト

  • 3306(MySQL,MariaDB[5])

  • 5432(PostgreSQL)（変更可：1150～65535）

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

5. 現在提供中のMariaDBは、2023年03月29日に新規申込受け付けを終了します。詳しくはサービスアクティビティのお知らせ（inf-000811 2023/01/13）を確認してください。

認証

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

アクセスコントロール

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

暗号化

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

監査

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

脆弱性監査

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

バックアップ

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

リソース制限

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

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

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

    検討項目

    検討内容

    文字コード決定

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

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

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

    格納先

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

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

    留意事項

    内容

    文字コード決定

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

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

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

    格納先

    データベースのインストール先及びデータファイルの格納先は、利用者が任意に設定できない
データベース運用設計（定常時）
作業概要

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

設計項目

方式設計の概要

1

データ連携運用設計

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

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

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

2

セキュリティ運用設計

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

  • 初期設定

  • 認証

  • アクセスコントロール

  • 監査

  • バックアップ

3

監視運用設計

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

4

性能運用設計

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

5

統計運用設計

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

6

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

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

7

保守運用設計

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

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

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

    検討項目

    検討内容

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

    • ①レブリケーションによるデータ連携

      • レプリケーション機能でデータ連携する場合は、バックアップ時にデータ不整合を発生させない運用検討が必要

      • また、テーブル、インデックスの再編成について検討が必要

    • ②スナップショット機能を用いたデータ連携

    • ③データベース間接続でのデータ連携

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

    • ①エクスポート/インポートによるデータ連携運用

    • ②ローダーを用いたデータ連携

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

    留意事項

    内容

    選択値・条件

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

    • 分散データベース構成でのデータ連携は、アクティブ/スタンバイの冗長化構成を設定するだけで利用可能

    • 外部レプリケーション機能を利用することにより、ゾーンやリージョンをまたいだレプリケーションや、ニフクラ外のDBとのレプリケーションを実現可能

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

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

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

    6. ニフクラRDB構成サーバーにOSログインできないため
セキュリティ運用（定常時）
作業概要

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

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

    検討項目

    検討内容

    初期設定

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

    認証

    • ①利用者管理：正当なアクセスのみを許可し、不正アクセスを防ぐための利用者管理方針/手順を設計する

    • ②パスワードの管理：パスワードの不正利用によるなりすましを防ぐため、パスワード管理方針/手順を設計する

    アクセスコントロール

    • ①アクセス権限の設定：不正アクセスを防ぐため、必要最低限のアクセス権限を設定するように設計する

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

    監査

    • ①ログの取得：定期的に適切な監査ログを取得し、監査ログの取得対象は適宜見直しする運用を含めて設計する

    • ②ログ保全：監査ログを利用するにあたり、監査ログの正当性を確保できるよう、監査ログの保全方式を設計する

    • ③監査ログ分析：不正行為の発見、追跡をするため、監査ログの分析するよう方針/手順を設計する

    • ④不正アクセスの検知：不正アクセスを監視・監査するため、アクセスログ取得と分析方針/手順を設計する

    バックアップ

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

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

    留意事項

    内容

    初期設定

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

    認証

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

    アクセスコントロール

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

    監査

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

    バックアップ

    パックアップデータの保全：自動バックアップ、手動スナップショットと合わせ、バックアップ方式を設計する
データベース監視運用（定常時）
作業概要

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

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

    検討項目

    検討内容

    プロセス監視

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

    状態監視

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

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

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

    性能閾値監視

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

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

    留意事項

    内容

    選択値・条件

    プロセス監視

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

    • DBMSのプロセス監視不可（ニフクラRDB構成サーバーにOSログインできないため）

      イベントカテゴリ

      • availability

      • backup

      • configuration change

      • creation

      • deletion

      • failover

      • failure

      • low storage

      • maintenance

      • notification

      • recovery

      • restoration

    状態監視

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

    • バイナリログサイズ

    • スワップ領域の使用量

    • ディスクI/Oのキュー数

    • CPU使用率（非アイドル）

    • 平均ディスクI/O数

    • リードレプリカの主系との遅延(MySQL エンジンのみ)

    • DBコネクション数

    • 読込時間/書込時間

    • スループット（読込時/書込時）

    • 空きディスク容量

    • 空きメモリ容量

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

    データベースエンジンのログ監視を検討推奨
    コントロールパネルまたはAPIを使用し、データベースエンジンのログを閲覧することが可能
    APIによるログのダウンロードは10MBまでが推奨
    MySQL、MariaDBエンジン[7]

    • エラーログ

    • スロークエリ―ログ

    • 一般クエリーログの閲覧可能(トランザクションログの閲覧・監視・ダウンロード機能は提供無)

    PostgreSQLエンジン

    • 起動ログ

    • PostgreSQLログの閲覧可能

    7. 現在提供中のMariaDBは、2023年03月29日に新規申込受け付けを終了します。詳しくはサービスアクティビティのお知らせ（inf-000811 2023/01/13）を確認してください。

    性能閾値監視

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

    モニタリング自体にメール通知機能なし
データベース性能運用（定常時）
作業概要

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

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

    検討項目

    検討内容

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

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

    例

    • バッファキャッシュのヒット率

    • データベースのディスク領域（フラグメント、使用量）の状況

    • 1日当たりジャーナル量及びジャーナルアーカイブ量

    • クリティカルなSQLの処理時間(CPU時間、I/O時間）

    • ロック状況（デッドロックの発生状況を含む）

    • バックアップ時間

    • 業務ピーク時のトランザクション量

    • オプティマイザ統計情報の有無と取得された時期

    • DBMSの動作を規定するパラメーターなど

    実現方式

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

    例

    • OSのコマンド機能を使用

    • 運用管理ソフトウェアの機能を使用

    • DBMSの機能を使用

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

    留意事項

    内容

    選択値・条件

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

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

    実現方式

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

    例

    • モニタリングにAPIを利用

    • DBMSの機能を使用

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

    ニフクラRDB構成サーバーのOSに対してログイン不可（OSコマンド操作も不可）
統計情報運用（定常時）
作業概要

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

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

    検討項目

    検討内容

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

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

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

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

    留意事項

    内容

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

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

    オプティマイザ統計情報の運用
バックアップリストア運用（定常時）
作業概要

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

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

    検討項目

    検討内容

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

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

    • ①障害から復旧までの最大許容時間

    • ②データ復旧ポイントの明確化

    • ③バックアップ取得タイミング

    • ④バックアップ取得方法

    • ⑤保管方法と世代管理

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

    留意事項

    内容

    選択値・条件

    バックアップ

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

    • ①自動バックアップ

      • バックアップ保存期間オプション、バックアップ時刻オプションを設定することで毎日、定刻にバックアップを実施

    • ②手動スナップショット

      • 任意の時刻にデータベースサーバーのスナップショットを取得。バックアップとして保存することも可能

    • 自動バックアップ最大10日間

      • バックアップ時刻はUTC設定

    • 手動スナップショットのバックアップ保存は上限10個(申請により緩和可(緩和上限は要相談))

    リストア

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

    • ①ポイントインタイムリカバリー

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

    ①、②のいずれのリストア方法もリストア後のニフクラRDBは新規作成となりIPアドレスの変更が実施される。必要に応じて変更する手順を設計する。
データベース利用時の保守運用での留意事項（定常時）
作業概要

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

検討項目

検討内容

テーブルの再編成

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

インデックスの再編成

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

データベース起動/停止

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

各種ログファイルの管理

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

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

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

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

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

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

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

オブジェクトの変更運用

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

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

留意事項

内容

選択値・条件

テーブルの再編成

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

インデックスの再編成

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

データベース起動/停止

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

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

各種ログファイルの管理

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

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

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

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

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

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

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

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

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

オブジェクトの変更運用

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

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

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

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

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

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

フェイルオーバーやフェイルバックにかかる時間については、データベースの状態により変動
データベース利用時の運用設計（障害時）
作業概要

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

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

    検討項目

    検討内容

    システム障害

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

    データベース性能障害

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

    トランザクション障害

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

    ヒューマンエラー障害

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

    自然災害など

    自然災害などが発生した場合の障害対応方式について設計する
ニフクラ RDB 利用時の運用設計（障害時）
作業概要

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

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

    留意事項

    内容

    選択値・条件

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

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

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

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

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

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

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

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

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

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

    自然災害など

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

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

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

    12. 通常稼働状態の場合でもアーカイブログなどから任意の時刻のデータ状態に戻すことはできない仕様
方式詳細と参考ドキュメント
掲載ドキュメント

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

設計項目

ドキュメント掲載先

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

内容

(1)ニフクラRDB

本ドキュメント内

ニフクラ RDB 利用例

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

CDP

RDBパターン

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

CDP

RDB冗長化パターン

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

CDP

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

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

本ドキュメント内

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

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

本ドキュメント内

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

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

  • 主系データベース障害時の挙動
    冗長構成のニフクラRDBで主系DBに障害が発生した際の挙動を図に示します。

    • 正常時

      • 主系/待機系のDBが同期しています。
        image

    • 主系ニフクラRDB障害発生

      • フェイルオーバーし、待機系DBが主系DBとなります。
        image

    • 復旧状態

      • 復旧状態とする場合、再度利用者で、冗長化を行う必要があります。記載構成は再冗長化実施後の構成となります。
        ※冗長化のタイプが性能優先の場合でリードレプリカが複数ある場合は、リードレプリカが1台少なくなり(主系となり)他リードレプリカが待機系DBとなり冗長構成は継続されます。
        image

        注意事項

        冗長構成のタイプ（性能優先/データ優先）によってフェイルオーバーに要する時間が異なります。

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

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

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

シングル

ニフクラRDB冗長構成

備考

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

リストア作業要

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

  • シングル構成では、スナップショットを利用してニフクラRDBを新規作成するリストア方式

  • 冗長化構成では、フェイルオーバーで待機系が主系に切り替わるため、リストアは不要

  • フェイルオーバー後、ある時点まで更新状況を戻したい場合、スナップショットは利用不可

  • スナップショットを利用したリストアでは、別のニフクラRDBが生成される

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

  • シングル構成では、ポイントインタイムリカバリーを利用してニフクラRDBを新規作成するリストア方式

  • エラーが発生したニフクラRDBを削除すると、自動バックアップのデータも削除されるため、リストアをしてからエラーとなったニフクラRDBを削除するような設計が必要

  • 冗長化構成では、フェイルオーバーで待機系が主系に切り替わるため、リストアは不要

  • ただし、フェイルオーバー後、自動バックアップのデータを使用してデータベースをフェイルオーバー以前のある時点までの更新状況に戻すことはできないため、どのように復元するかの運用設計をする

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

  • シングル構成では、ニフクラRDBの新規作成後にツールでリストアを実行

  • 冗長化構成では、フェイルオーバーで待機系が主系に切り替わりますので、リストアは不要

  • フェイルオーバー後、ツールで採取したバックアップデータを流し込むことは可能
ニフクラRDBのフェイルオーバー後のバックアップに関して

  • 主系が障害時、フェイルオーバーで待機系が主系に切り替わります。

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

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

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

２．外部接続

外部接続設計のポイント

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

検討項目

検討内容

接続形態

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

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

  • インターネット接続

    • http/httpsで提供されているサービス(APIなど含む)、DNS、NTP等、外部サービスとの接続 [13]

  • IPsecVPNによる、利用者の拠点のシステムとニフクラ内のシステムとの接続 等々

  • プライベート接続サービスを利用した閉域接続

    • データセンターや拠点のシステムとニフクラ内のシステムとの接続（「ニフクラ導入・移行設計指針（共通編）拠点環境とのダイレクトポート接続事例」参照）

    • ニフクラの各リージョンに存在するシステムのリージョン間の閉域網接続（「ニフクラ導入・移行設計指針（共通編）DRサイト構築事例概要」参照）等

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

外部システムの仕様

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

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

  • 接続先のIPアドレスの変更がありえる。 [14]

  • 接続先のシステムのアクセス制御が厳しく、不特定のIPアドレスからの接続を受け付けない場合がある。 [15]

  • 接続先がインターネットで提供されているサービスで、接続元のシステムがインターネットにアクセスできる必要がある。 [16]

  • 接続先のシステムやサービスが、応答を返すことを保障しない。] [17]

  • httpsでの接続をする際に、指定のバージョンの暗号が使えないと接続できない。 [18] [19]

14. Workload Securityのマネージャサーバーなど、外部接続先のシステムでIPアドレスの変更がありえる場合は、FQDNによるアクセスが必須。
15. 接続元のIPアドレスが属するドメインを、DNSの逆引きで確認できることが必須のケースがある。
16. ニフクラが提供するESSなどの利用では、インターネットアクセスできる環境が必要。
17. 接続元のシステムで、接続先のシステムやサービスでエラーが発生した際や無応答時の際の作り込みが必要となる。
18. セキュリティ上問題がある暗号化方式（TLSv1.1より古い暗号化方式）を使ったhttpsでは接続できない。
19. 反対に、外部接続のシステムが変更できないため、古い暗号化方式のhttpsでしか接続できない。
外部接続設計ポイントの適用事例
ニフクラ内のシステムからインターネット上の外部システムやサービスに接続する構成例を記載します。

  • ニフクラ内のシステムから、外部の公開NTPサーバーに接続する構成例

    • 外部NTPサーバーに接続するには、以下の図①③の通り、接続元がインターネットにアクセスできる環境が必要です。

    • ニフクラで提供するサービスのうち、ESSなどは、インターネット上で提供されます。そのためESSなどを利用の際のネットワーク構成も同様に検討してください。

image

構成図補足

  • ① グローバルIPを利用している仮想サーバーから外部公開のNTPへのアクセスは可能

  • ② グローバルIPを利用していない仮想サーバーから外部公開のNTPへのアクセスは不可能

  • ③ グローバルIPを利用していない仮想サーバーの時刻同期を行いたい場合、グローバルIPを利用している仮想サーバーを内部参照用NTPサーバーとして構築することで時刻同期可能

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

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

カテゴリ項目

作業

ニフクラでの作業概要

備考

外部接続

外部接続の方式設計

外部システムや外部サービスとの接続要件に基づいて、外部接続方式、インターフェース、通信シーケンスなどをオンプレミスと同様の設計する。
本ドキュメント内「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サーバーを用意し作成したサーバーの時刻を同期させることが必要。[20]
外部公開NTPサーバーと同期を行う際には、インターネットへアクセスできるネットワーク構成が必要。

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

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

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

OSパッチなど

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

３．移行

移行設計のポイント

ニフクラへの移行観点で設計する際には、以下の項目を検討してください。

検討項目

検討内容

選択値・条件

移行元システムと移行先システムの互換性

OSやソフトウェア、データベース、データベースに格納するデータの互換性などを確認する。

OS

ニフクラが提供するOSとバージョンが適合するかを確認する

ソフトウェア

ニフクラが提供するソフトウェアを利用する場合は、提供バージョンが使えるかどうかを事前に確認する

ニフクラRDB

提供されているデータベースエンジンの互換性情報や設定できる機能や移行元との互換性があるか確認する。データベースに格納する対象データの統廃合やコード変換の発生についても留意する

移行元システムのライセンスの確認

移行元システムで使用しているライセンスを確認する。

Oracle社の製品

仮想環境へOracleをインポート (ないし新規構築) することはライセンス上厳しく制限

Microsoft社の製品

SPLAや仮想環境での利用の条項などに基づいてニフクラが提供する製品を利用するか、利用者がSA付のライセンスモビリティでニフクラ上に利用者のライセンスを持ち込むかのいずれかを選択

移行機能の検討

ニフクラが移行のために提供する機能について、各機能のカバー範囲の確認が必要。

  • 単純なリホストの場合は、ニフクラ IaaS サービスの VMインポート機能/ディスク受取サービス(VMインポート) を利用する

  • ニフクラで提供しているAcronisバックアップや別途バックアップミドルウェアが提供する、別ハードへのリストア機能を利用する

データ転送方式とデータ転送にかかる所要時間

利用者環境からニフクラ環境にデータ転送する方式を設計する。

  • ①インターネットを利用したデータ転送

    • インターネットで直接アクセスしたり、IPsec-VPN/SSL-VPN、オブジェクトストレージを利用したりする方式

  • ②物理ポート（構内接続プラン）接続でデータ転送

    • ホスティング環境から物理ポート（構内接続プラン）接続経由で、ニフクラの仮想環境にデータを転送する方式

  • ③ダイレクトポート/物理ポート（コロケーションプラン）接続でデータ転送

    • データセンターまたは利用者環境から、ダイレクトポートまたは物理ポート（コロケーションプラン）接続で、ニフクラの仮想環境にデータを転送する方式

  • ④ディスク受取サービスでデータ転送

    • ニフクラ側からHDDを利用者指定の場所に送付

    • 利用者にて移行データをHDDに格納、返送

    • ニフクラ側で利用者指定の増設ディスクにデータを転送

    • アクセス権限については引き継がれない可能性があるので移行前・移行後に確認し差分があれば再設定をする

移行ツール

データ移行のツールとして、Windowsではrobocopy (Microsoft社ツール) 、Linuxではrsyncがよく利用される。
移行ツールを使用する際にはファイルの読み取り／書き込み権限がどのようになっているかの確認と、必要に応じた変更などの考慮が必要。

  • 例：オンプレミスでファイルサーバーとして構築されているWindowsサーバーでは、給与データや経理データ等が記載されたファイルに対してWindowsサーバーの管理者権限を持っていても読めなくするようアクセス制限をかけている場合も存在。

参考の「移行ガイド」では、VMインポートを利用した移行事例を記載。
移行適用の指針

設計のポイントで例示した検討項目について、検討対象への適用の指針を記載します。

移行対象・データ転送式／移行機能・手法

移行対象

データ転送方式

ローカルディスク

ローカルディスク+データディスク(2つ目以降のディスク)

データディスク(2つ目以降のディスク)

データ(ファイル単位)

インターネット利用

ダイレクトポート／プライベートアクセス接続利用

HDD利用

インターネット

IPsecVPN

SSL-VPN

オブジェクト ストレージ

データ移行

－

－

－

○

○

○

○

○ ※2

○

ー ※3

別途バックアップミドルウェアなど利用 ※1

○

○

○

○

○

○

○

○ ※2

○

ー ※3

バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）

○

○

○

○

○

○

－

－

○

ー ※3

VMインポート

○

－

－

－

○ ※4

－

－

－

－

ー ※3

ディスク受取サービス

－

－

－

○

－

－

－

－

－

○ ※5

ディスク受取サービス（VMインポート）

○

○

－

－

－

－

－

－

－

○ ※5

  • ※1 別途バックアップミドルウェアなどを利用する場合には、動作要件などを事前に確認してください。

  • ※2 オブジェクトストレージへのアクセスはhttp(s)でのAPI経由となります。事前にアクセス方式に関して検討してください。

  • ※3 物理HDDを直接ニフクラ環境に持ち込むことはできません。

  • ※4 VMインポートではコントロールパネル経由で操作を実施します。

  • ※5 利用するHDDはニフクラより送付します。

その他ライセンスや互換性など、「移行設計のポイント」の項目も留意してください。各移行機能/手法の留意事項等も別途確認してください。

移行適用事例

image

以下にシステム構成に対して、ローカルディスクなどの検討対象ごとに、移行に関する検討項目の適用事例を記載していきます。

  • 利用者側オンプレミス環境とニフクラ環境の接続構成例

    • IPsec VPN

    • 専用線/閉域網接続 ＋ ニフクラダイレクトポート接続

    • ディスク受取サービスの利用

移行作業のカテゴリと作業概要

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

カテゴリ項目

作業

ニフクラでの作業概要

備考

移行

移行対象 ハードウェアの抽出

オンプレミスシステム同士の場合と同様、移行対象となる ハードウェアを抽出し一覧を作成する

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

移行対象ソフトウェアの抽出

移行対象となるソフトウェアを抽出し、一覧を作成する移行元システムでのパッチ適用状況を確認し、一覧を作成する。 [21]

21. ソフトウェアによってはクラウド環境に移行する際、ライセンスの取り扱いに変更が入る場合あり

移行対象ネットワークの抽出

移行対象となるネットワークを抽出し、一覧を作成する。
HUBなどクラウド環境に移行することにより不要になる、移設対象外となる機器を洗い出す。

移行対象システム資産の抽出

移行対象となる ハードウェア、ソフトウェア、ネットワーク以外の資産（スクリプト、定義体、ツール、フォント、外字など）を抽出し、一覧を作成する。

移行対象システム構成図の見直し

洗い出した移行対象の整理を行い、移行対象システム構成図について見直しを行う。

移行対象データの抽出

移行対象となるアプリケーションで使用する業務データ（DBデータ、一般ファイルデータ）を抽出し、一覧を作成する。

移行対象データ項目の確認

抽出した移行対象データの項目（カラム、フィールド単位レベル）を確認し、一覧を作成する。

新旧データ項目の非互換調査

移行対象データにおいて、移行時の非互換要素（文字コード、暗号化等）の有無やデータ統廃合の有無などを調査し、一覧を作成する。
データベースの移行先としてニフクラRDBを使用する場合、対象データの統廃合やコード変換の発生があるかも確認する。

移行ツールの概要検討

システム・データ移行に必要となる移行ツールや移行機能を検討する。
ニフクラ への移行を支援する機能として、VMインポートサービスなどの利用も検討。

移行ツールの手配

選定した移行ツールを手配する。

導入のご相談はお電話でも受け付けております。

0120-22-1200

0120-22-1200

受付時間：9:00～17:45（土日祝・当社指定の休業日を除く）
※携帯電話・PHSからもご利用可能

お問い合わせ

お申し込み

資料ダウンロード

見積もりシミュレーター

お申し込み