本文へジャンプします。

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

2024年4月1日をもって、「ニフクラ」は、「FJcloud-V」に統合し、名称を変更しました。
「ニフクラ」「NIFCLOUD」「nifcloud」は、「FJcloud-V」に読み替えていただきますようお願いいたします。

ニフクラ ユーザーガイド

クラウド トップ>ユーザーガイド>ニフクラ設計ガイド(運用・保守設計編)

はじめに

  • 本ドキュメントの目的

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

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

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

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

  • 前提知識

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

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

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

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

      • バックアップ、監視、冗長化などシステム設計/システム運用に関する基本的な知識
        ※システム設計経験を有することが望ましい

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

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

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

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

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

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

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

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

本ドキュメントの構成

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

    設計のポイント

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

    設計ポイントの適用事例

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

    カテゴリと留意事項

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

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

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

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

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

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

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

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

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

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

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

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

  • 知識の習得

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

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

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

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

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

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

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

運用・保守

運用・保守設計のポイント

ニフクラにて運用・保守観点で設計をする際には、以下の項目を検討してください。

項目

検討内容

ニフクラ基盤の運用保守と、ニフクラ上で構築するシステムの運用保守体制
運用保守の実施

  • ニフクラが提供するサービス(ニフクラ内の物理ネットワーク、ハードウェア、仮想化基盤、PaaS基盤等)の運用保守はニフクラ基盤側で実施します。

  • 仮想サーバーのOS層以上の運用保守(OSに対するパッチ適用、アプリケーション保守、各種パラメーターの変更等)は、ニフクラの利用者側で、運用体制や運用フローを検討のうえ、実施してください。

[障害などの通知と対応]

  • ニフクラの障害時やメンテナンス時の運用体制と運用フローをあらかじめ検討してください。
    ニフクラのサービス障害の通知やメンテナンス情報(緊急メンテナンス含む)は、メール及びコントロールパネルにて通知します。利用者側では、通知内容から業務影響を判断し、運用フローにしたがって障害などの対応をしてください。

  • お知らせ通知についてニフクラから通知する際、内容ごとにメールの件名を取り決めています。詳細は以下を参照してください。

  • ニフクラからのお知らせ通知にて、期日までに利用者に回答を求めることがあります。お知らせ通知を受信したら、内容の確認、対応をしてください。

    • 例) 指定期日までに、リソースのアップグレードを依頼

    • 例) ニフクラ側で利用者リソースに対しての作業を実施してよいか確認を求める

運用作業におけるニフクラのサービス／機能の利用
[ニフクラの機能の把握と運用保守作業への適用検討]

  • ニフクラが提供する機能を、運用保守作業に組み込むか検討してください。例えば仮想サーバーの停止/起動を、ニフクラのコントロールパネルやAPIを使ってするか、コンソール機能を使うか、OSコマンドで行うか等を検討してください。

  • ニフクラの機能の特徴や制限事項が、運用保守上で問題にならないか検討してください。

[ニフクラの監視サービスの適用検討]

  • 運用作業におけるニフクラのサービスの適用検討として、特にニフクラの監視サービスを適用するかの検討は必ず行ってください。

  • ニフクラでは、基本監視サービスの利用により、CPU使用率などのリソース監視が可能です。ただし、ニフクラの基本監視サービスはハイパーバイザー層からできる監視までのため、仮想サーバー内部のOS層以上の状態を把握できません。そのため、仮想サーバー内部でログ監視やプロセス監視をする場合には、利用者の要求レベルに合わせてZabbix 等の監視ソフトを導入した監視を検討してください。
    大規模環境におけるシステム監視方式例は、本ドキュメント内「複数ゾーン、複数リージョンでのシステム相互監視例」を確認してください。

災害発生時の対策検討とSLA
[複数ゾーン構成、複数リージョン構成の検討]

  • 単一ゾーンの障害に備えて、複数ゾーンでのシステム運用を検討してください。

  • 広域災害を想定する場合は、複数リージョンを用いたシステムを検討してください。詳細は信頼性の章を確認してください。

[SLA]

  • ニフクラでは仮想サーバー、ネットワークサービス等にSLAを設定しています。
    ニフクラの仮想サーバーのSLAは、仮想サーバー一台から適用されます。複数ゾーンの利用が必須といった条件はありません。そのためHAを許容できれば複数ゾーンで構成する必要はありません。詳細は品質保証制度（SLA）を確認してください。
複数ゾーン、複数リージョンでのシステム相互監視例

image

構成図補足
【Webサービス監視】

Zabbixなどで監視を想定
西日本リージョン内の監視サーバーから東日本リージョン内のロードバランサー（L4）のURLを監視します。
複数ゾーンに監視サーバーを配備して相互監視することで、ゾーン障害も迅速に検知可能
別リージョンからWebサービス監視することで、ユーザー視点でのサービス監視が可能

【サーバー監視：相互監視方式】

Zabbix 等の監視ツールで可能

設定内容

  • 東日本内のゾーンAに監視サーバー1、ゾーンBに監視サーバー2を配備します。両方の監視サーバーとも、監視をする設定とします。

  • 各ゾーンに配備する仮想サーバーには、監視エージェントをインストールし、 両方の監視サーバーにデータを送信する設定をします。
    記載のDBサーバーがニフクラRDBだった場合(ニフクラRDBは複数ゾーン構成が実装できません。)、監視エージェントをインストールできないため、監視サーバーからニフクラRDBへの接続監視を行います。

留意事項

  • 両方の監視サーバーで異常を検知しますので、何らかの考慮をしていない場合は、異常を検知した際のアクションが２つとなります。
    片方の監視サーバーに対して、異常を検知した際にメール通知やコマンド実行等のアクションを実行しないでください。

  • 監視サーバー同士の設定について、同期をとる運用を検討してください。

運用・保守のカテゴリと作業概要

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

カテゴリ項目

作業

ニフクラでの作業概要

備考

運用・保守

運用・保守体制の設計

構築期間・実運用における役割分担や連絡網等の運用・保守体制を設計してください。

定常時運用の方式設計

システムの定常時運用におけるシステム起動・停止、バッチ業務、ログ管理及びユーザー管理等の方式を設計してください。 [1]

1. 定常時運用の方式設計では一般的な設計項目の中で、ニフクラ利用時に検討するポイントのある設計項目について、記載していきます。

障害時運用の方式設計

システム運用時の障害発生に備え、信頼性対策を考慮した障害時運用の方式を設計してください。

保守時運用の方式設計

OS・ミドルウェア・業務アプリケーション・ネットワーク等のシステム保守作業時の運用方式を設計してください。

運用・保守規約の設計

運用・保守におけるコード、ログ、ドキュメントに関する規約を設計してください。

オンプレミスと同様に設計してください。(記載は省略します。)

運用補完アプリケーションの具体化

運用方式実現のために必要となる運用補完アプリケーションに関する要件をまとめてください。また、既存の運用補完アプリケーションの流用可否を検討してください。

運用管理システム構成設計

運用管理システムの構成を設計してください。また、具体化した定常時・障害時・保守時の運用要件に基づいて、運用管理システムでサポートする機能配置を設計してください。
運用・保守体制の設計
作業概要

  • 構築期間・実運用における役割分担や連絡網等の運用・保守体制を設計してください。

留意事項

留意事項

内容

運用保守の責任分解点

  • ニフクラが提供するサービス(ニフクラ内の物理ネットワーク、ハードウェア、仮想化基盤、PaaS基盤等)の運用保守はニフクラ基盤側で実施します。

  • 仮想サーバーのOS層以上の運用保守(OSに対するパッチ適用、アプリケーション保守、各種パラメーターの変更等)は、ニフクラの利用者側で、運用体制や運用フローを検討のうえ、実施してください。

ニフクラ基盤自体の障害とメンテナンス通知

  • ニフクラの障害時やメンテナンス時の運用体制と運用フローをあらかじめ検討してください。
    ニフクラのサービス障害の通知やメンテナンス情報(緊急メンテナンス含む)は、メール及びコントロールパネルにて通知します。緊急時には、予告なく、緊急メンテナンスを実施します。利用者側では、通知内容から業務影響を判断し、運用フローにしたがって障害等の対応をしてください。 こちらの内容については以下を参照してください。

お知らせ通知による作業依頼や確認依頼

  • ニフクラのリソースは、定期的にアップグレードを必要とするサービスがあります。期日までに利用者の都合の良いタイミングで実施してください。期日を超過してもアップグレードがされない場合はニフクラにて任意のタイミングで実施します。

  • 利用者のリソースに対して作業を依頼したり、ニフクラ側での作業を実施してよいか事前に確認します。
ニフクラのサポート

以下サービスページを確認してください。

運用の方式設計（定常時）
作業概要

  • システムの定常時運用におけるシステム起動・停止、バッチ業務、ログ管理及びユーザー管理の方式を設計してください。
    「運用の方式設計（定常時）」では一般的な設計項目の中で、ニフクラ利用時に検討するポイントがある設計項目について記載していきます。

一般的な設計項目

方式設計の概要

1

設計前事前確認

オンプレミスと同様に設計してください。(記載は省略します。)

2

システム起動・停止

システム全体の起動・停止をする場合の手順を設計してください。

3

時刻補正

システム内の各リソースで時刻が同じになるよう、システム要件に合わせて時刻補正方式を設計してください。

4

システム監視

業務サービス運用中、システムの各種資源が正しく稼働しているか、定期的またはリアルタイムにチェック/検知する方式を設計してください。

5

バッチ業務制御

バッチ業務処理に関する運用保守の手順を設計してください。

6

バックアップ・リカバリ

誤操作や障害の発生に備えたバックアップデータの取得と、バックアップデータからのデータリストアについての運用を設計してください。

7

ログ管理

パフォーマンス分析、障害調査、監査対応等、それぞれの目的に応じたログ収集、管理、集計に関する運用を設計してください。

8

リモート操作

ニフクラの環境にリモートからアクセスする方式を設計してください。合わせて、リモートログイン時のセキュリティを設計してください。

9

ユーザー管理

ニフクラ利用者の立場や状況に応じて、適切な権限を設定してください。

10

データベース管理

データベースに関する運用方式を設計してください。

11

構成管理

オンプレミスと同様に設計してください。(記載は省略します。)

12

変更管理

13

リリース

14

キャパシティ管理

15

帳票管理

16

外字管理

17

消耗品管理
システム起動・停止（定常時）
作業概要

  • システム全体の起動・停止をする場合の手順を設計してください。

留意事項

留意事項

内容

仮想サーバーのステータス
[仮想サーバーの状態]

ニフクラの仮想サーバーは、起動、停止、異常の状態があります。

[仮想サーバー停止状態]

停止状態は、OSがシャットダウンされた状態です。

コントロールパネル操作/API実行による仮想サーバーの停止

コントロールパネル操作またはAPI操作による仮想サーバーの停止は、強制オプションを指定すると強制電源断の扱いになります。
仮想サーバーにログインしてOSからのシャットダウン処理も可能です。

仮想サーバーの自動起動

仮想サーバーを自動起動したい場合は、ニフクラタイマーを利用するか、APIを使用したスクリプトをスケジュール実行する等の作り込みを行ってください。

仮想サーバー、仮想サーバー内のサービスの起動/停止順序

仮想サーバーや仮想サーバー内のサービスについて、システム間で起動や停止の順序に依存関係がある場合には、利用者側でシステムの起動/停止順序を検討してください。
時刻補正（定常時）
作業概要

  • システム内の各リソースで時刻が同じになるように、システム要件に合わせて時刻補正方式を設計してください。

留意事項

留意事項

内容

選択値・条件

NTPサービス

ニフクラの仮想サーバーの時刻管理については、サーバーの時刻管理を参照してください。特に以下の内容を確認してください。

別途仮想サーバーをNTPサーバーとして構築し、他仮想サーバーの時刻を構築したNTPサーバーと同期させることも可能です。要件に応じて対応してください。
また、外部公開NTPサーバーと同期をする際にはインターネットへのアクセスが必要になります。インターネットへアクセス可能な構成にしてください。

NTPサーバーのサービス提供はなし

ネットワーク構成

下図中央のように、グローバルネットワークに接続されていないプライベートネットワークからは、外部NTPサーバーにはアクセスできません。この場合は、下右図のように、グローバルネットワークにも接続された独自のNTPサーバーを構築し、プライベートネットワーク経由での時刻同期を検討してください。

ニフクラRDB

ニフクラRDBの時刻同期についてはこちらを確認してください。

image

システム監視（定常時）
作業概要

  • 業務サービス運用中、システムの各種資源が正しく稼働しているか、定期的またはリアルタイムチェックしたり検知したりする監視方式を設計してください。

留意事項

留意事項

内容

選択値・条件

リソース監視

ニフクラの基本監視サービスでは、仮想サーバーの CPU使用率など、リソースを監視できます。
パフォーマンスチャートを利用して、基本監視項目とほぼ同様[2]のリソース状況を確認できます。ほかにも有人監視の利用が可能です。

2. パフォーマンスチャートでは基本監視の項目にはない、サーバーのネットワーク流量の確認が可能です。

基本監視でリソース監視可能な項目は基本監視の技術仕様/制限値を確認してください。

システム監視

以下の要件でシステムを統合的に監視したい場合は、ニフクラの基本監視サービスではなく、別途Zabbix等の監視用のソフトウェアを導入してください。

  • 仮想サーバー内部でログ監視やプロセス監視をしたい場合

  • 異常を検知した際に、仮想サーバー内部でリカバリ用のコマンドを発行したい場合

  • システム内部の監視だけではなく、WebサービスのURL監視等も含めて、統合的/一元的に監視をしたいような場合 [3]

3. 大規模環境におけるシステム監視方式例は、本ドキュメント内「複数ゾーン複数リージョンでのシステム相互監視例」を確認してください。
バッチ業務制御（定常時）
作業概要

  • バッチ業務処理に関する運用保守の手順を設計してください。

留意事項

留意事項

内容

バッチのジョブ管理

バッチジョブの管理やスケジュール実行が必要な場合は、実現方法を検討してください。例としては以下の実現方法があります。

  • OS標準のタスクスケジューラ利用

  • SystemWalker Operation Manager [4]

  • その他オープンソースなどのジョブ管理ソフト

4. 2023年1月11日をもってソリューションサービスとしての新規申し込み受け付けを終了しました。以降の導入に関しては 富士通株式会社 より購入してください。

バッチスケジューリングの再検討

オンプレミスからシステムを移行する場合、以下の状況により、バッチ実行時間に大きな影響を受けることがあります。

  • ニフクラ仮想サーバーのCPUクロック数がオンプレミスと異なっている

  • 各種リソース(ストレージ、ネットワーク等)がベストエフォートとなっている

そのため、バッチ処理の移行の際には、必ずバッチ処理をニフクラで実機検証し、必要に応じてバッチの多重化を検討する等して、余裕を持った運用ができるようバッチスケジューリングを検討してください。

ネットワーク経由でのバッチ実行

ネットワーク経由でオンプレミスや他のクラウドシステムに対してデータ転送を伴うバッチ処理をする場合には、以下に留意してください。

  • 処理時間の遅延

  • データ転送により発生する費用
バックアップ・リカバリ（定常時）
作業概要

  • 誤操作や障害の発生に備えたバックアップデータの取得と、バックアップデータからのデータリストアについての運用を設計してください。

留意事項

留意事項

内容

バックアップ・リカバリにおけるニフクラのサービス／機能の利用

ニフクラが提供するカスタマイズイメージなどの機能について、その機能の特徴や制限事項が運用保守上で問題にならないか検討してください。そのうえで、ニフクラが提供するカスタマイズイメージなどの機能を利用者側システムの運用作業に組み込むか検討してください。ニフクラでバックアップとして利用できる機能は以下があります。

5. サードパーティ製のソリューションサービスです。

バックアップの世代管理

古い世代のバックアップのデータを定期的に削除する運用を検討してください。

  • 上記①のサービス利用時は、バックアップ世代の管理は利用者責任となります。

  • ②は世代管理には不向きです。

  • ③は世代管理が可能です。

  • ④は世代管理がAcronisのコンソールより可能です。

バックアップデータ保存に必要なストレージ容量

  • ①②③ ニフクラの基盤側でバックアップデータを保存する容量は確保しています。

  • ④ バックアップデータ保存に必要なストレージ容量の確保がプランによって必要です。

バックアップ取得の自動化

  • ①ニフクラタイマーや、APIを実行するスクリプトを作成し、ジョブをスケジュール実行するなどで自動化が可能です。

  • ②世代管理には不向きなため、自動化するメリットはありません。ニフクラタイマーやAPIには対応しています。

  • ③自動化(スケジューリング)が可能です。

  • ④Acronisコンソールより自動化(スケジューリング)が可能です。

リストア時の状態

  • ①③ 取得したイメージから新規にサーバーを作成します。グローバルIPアドレス情報が変更になります。変更したくない場合は別途、付替IPアドレスの利用を検討してください。

  • ② スナップショットを取得したサーバーでスナップショット取得時の状態に戻すことが可能です。

  • ④ バックアップを取得した元サーバーでも別サーバーに対してもリストアが可能です。
ログ管理（定常時）
作業概要

  • パフォーマンス監視、障害調査、監査証跡等、それぞれの目的に応じたログ収集、管理、集計に関する運用を設計してください。

留意事項

留意事項

内容

選択値・条件

パフォーマンス監視用途のログについて

ニフクラの基本監視サービスでは、仮想サーバーのCPU使用率など、リソースを監視できます。
ニフクラの監視サービスで要件を満たさない場合には、利用者にてパフォーマンス監視の仕組みを構築してください。

基本監視サービスによるログはコントロールパネに表示されます。詳細はアクティビティログを確認してください。

障害調査用途のログについて

仮想サーバーにおけるOS層以上の運用保守は、利用者責任となります。
そのため、仮想サーバーで生成されるOSのシステムログや業務アプリケーションのログ等は必要に応じて収集・保存・管理をしてください。

ニフクラのファイアウォールの拒否ログはコントロールパネル/APIから取得可能

監査証跡用途のログについて

主に利用されるニフクラ機能のうち、ログを取得できないものがあります。
内容に関しては各機能の詳細を確認してください。
リモート操作（定常時）
作業概要

  • ニフクラの環境にリモートからアクセスする方式を設計してください。合わせて、リモートログイン時のセキュリティを設計してください。

  • アクセス制御、ユーザー管理、ログイン時の認証、不正ログインの確認手段の検討等を行ってください。

留意事項

留意事項

内容

リモートログイン手段

仮想サーバーにリモートログインするには、仮想サーバーにグローバルIPアドレスを付与してインターネットから直接接続する方法と、仮想サーバーにグローバルIPアドレスを振らずにリモートログインする方法があります。
仮想サーバーにグローバルIPアドレスを振らずにリモートログインするための手段としては、コンソール機能やアクセス経路をVPN経由、プライベート接続サービス経由があります。

セキュリティ

リモートログインする経路のセキュリティを検討してください。

  • アクセス元を限定する

  • アクセスできるユーザーを限定する

  • リモートログイン時のユーザー認証を強化する

  • リモートログイン先を特定の踏み台サーバーに限定する

  • ニフクラのリモートアクセスVPNゲートウェイを利用する

  • 不正なアクセスがないか確認する

  • アクセスできるユーザーを適宜棚卸しする等

踏み台サーバー

インターネットからニフクラ上のシステムにログインする場合、踏み台サーバーを配備してアクセス経路を一元的に管理する方式を検討してください。
ユーザー管理（定常時）
作業概要

  • ニフクラ利用者の立場や状況に応じて、適切な権限を設定してください。

留意事項

留意事項

内容

選択値・条件

ニフクラのマルチアカウントによる権限の設定

ニフクラでは、コントロールパネル/API利用者管理機能としてマルチアカウントを提供しています。 [6] [7]

6. 一部マルチアカウントには対応していないサービスもあるため留意してください。
7. 運用者権限・閲覧権限のユーザーには、許可する操作を定義したポリシーを追加できます。

管理者権限、運用者権限、閲覧権限のアカウント作成可能。マルチアカウント、マルチアカウント権限比較表を参考に担当者ごとの役割分担や権限分割を検討してください。

ニフクラ上のシステムを利用するエンドユーザーの認証

ニフクラ上のシステムを利用するエンドユーザーを管理・認証する基盤は、ニフクラとしては提供されていません。エンドユーザーを管理・認証する仕組みは、別途構築してください。
データベース管理（定常時）
作業概要

  • データベースに関する運用方式を設計してください。

  • データベースの方式設計に関しては、クラウド技術仕様/制限値(RDB)を確認してください。

留意事項

留意事項

内容

ニフクラRDBの監視

ニフクラRDBのイベント通知機能、モニタリング機能等を利用して監視が可能です。
なお、ニフクラRDBの容量監視は必ず実施してください。詳細はデータベースの章を確認してください。

ニフクラRDBの再起動について

ニフクラRDBにおいて、ニフクラRDBの再起動をする場合は、冗長化設定を確認してください。再起動時の選択により動作が異なります。

ニフクラRDBのバックアップ、リストア
[ニフクラRDBのバックアップ・リストア方法]

バックアップ・リストアについては、以下の技術仕様/制限値を確認して利用を検討してください。
運用の方式設計（障害時）
作業概要

  • システム運用時の障害発生に備え、信頼性対策を考慮した障害時の運用方式を設計してください。

  • 「ニフクラ導入・移行設計指針（共通編）適用の指針」も合わせて確認してください。

留意事項

留意事項

内容

選択値・条件

運用保守の責任分界点

ニフクラが提供するサービス基盤(ニフクラ内の物理ネットワーク、ハードウェア、仮想化基盤、PaaS基盤など)の運用保守はニフクラ側で実施します。
仮想サーバーのOS層以上の運用保守(OSに対するパッチ適用、アプリケーション保守、各種パラメーターの変更等)は、ニフクラの利用者側で、運用体制や運用フローを検討のうえ、実施してください。

ニフクラの障害・メンテナンス通知

ニフクラの障害時やメンテナンス時の運用体制と運用フローをあらかじめ検討してください。
ニフクラのサービス障害の通知やメンテナンス情報(緊急メンテナンス含む)は、メール及びコントロールパネルにて通知します。緊急時には、予告なく、緊急メンテナンスを実施します。利用者側では、通知内容から業務影響を判断し、運用フローにしたがって障害などの対応を行ってください。

詳細は障害・お知らせ通知を確認してください。

ニフクラのSLA

ニフクラでは仮想サーバー、ネットワークサービス等にSLAを設定しています。
ニフクラの仮想サーバーのSLAは、仮想サーバー一台から適用されます。複数ゾーンの利用が必須といった条件はありません。そのためHAを許容できれば複数ゾーンで構成する必要はありません。SLAは、稼働保証ではありません。SLAを遵守できなかった場合は減額対応します。サードパーティ製のソリューションサービス等、SLAが設定されていないサービスもあるため注意してください。

仮想サーバーのSLAは品質保証制度（SLA）を参照してください。

ニフクラのMTTR/RTO等

ニフクラ障害発生時のMTTR (平均復旧時間)やRTO(目標復旧時間)は、定められていません。

ニフクラの複数ゾーンを用いた災害対策

業務継続について、リージョン内の単一ゾーンの全損を想定する場合、リージョン内の複数のゾーンでシステムを稼働させる方式を検討してください。
ゾーン障害について、データの復旧やロードバランサー（L4）の処理振り分けといったシステムの切り替え・切り戻し手順を作り込むとともに、ゾーン障害時の切り替え作業の習熟訓練を運用の定期イベントとして組み込むなど、ゾーン障害の発生を見据えた障害時運用を検討してください。

ニフクラの複数リージョンを用いた災害対策

業務継続について、ニフクラのリージョン全損を想定する場合、別リージョンにあらかじめ災害対策用の待機系システムを用意し、災害時に稼働させる災害対策方式があります。データの復旧やDNSによるアクセス先の振り分けなど、システムの切り替え手順・切り戻し手順を作り込むとともに、待機系システムへの切り替え作業の習熟訓練を運用の定期イベントとして組み込むことなど、有事の復旧を見据えた運用を検討してください。
保守時運用の方式設計
作業概要

  • OS・ミドルウェア・業務アプリケーション・ネットワーク等のシステム保守作業時の運用方式を設計してください。

留意事項

留意事項

内容

選択値・条件

運用保守の責任分界点

ニフクラが提供するサービス基盤(ニフクラ内の物理ネットワーク、ハードウェア、仮想化基盤、PaaS基盤、スタンダードイメージ[8]など)の運用保守はニフクラ側で実施します。
仮想サーバーのOS層以上の層の運用保守(OSに対するパッチ適用、アプリケーション保守、各種パラメーターの変更等)は、ニフクラの利用者側で、運用体制や運用フローを検討のうえ、実施してください。

8. 利用者がイメージから作成したサーバー、パブリックイメージは対象外です。

ニフクラの障害・お知らせ通知

ニフクラの障害時やメンテナンス時の運用体制と運用フローをあらかじめ検討してください。
ニフクラのサービス障害の通知やメンテナンス情報(緊急メンテナンス含む)は、メール及びコントロールパネルにて通知します。
緊急時には、予告なく、緊急メンテナンスを実施します。基本的には利用者の利用リソースに影響がでないよう活性メンテンスで実施します。通知内容から業務影響を判断し、運用フローにしたがって障害等の対応をしてください。

詳細は障害・お知らせ通知を確認してください。

ニフクラからお知らせ通知を受け取れる運用体制と運用フローをあらかじめ検討してください。
ニフクラのリソースは、定期的にアップグレードを必要とするサービスがあります。期日までにアップグレードを依頼するお知らせ通知を受信したら、利用者の都合の良いタイミングで実施してください。
期日を超過してもアップグレードがされない場合はニフクラが任意のタイミングで実施します。 また、利用者リソースへの作業を依頼する可能性があります。事前にお知らせ通知にて作業の実施確認をします。

ニフクラからお伝えしたい情報は、内容ごとに特定のメール件名で送付します。詳細はお知らせ通知を確認してください。

仮想サーバーの保守順序

仮想サーバーの保守(OSパッチ適用、アプリケーション保守、各種パラメーターの変更等)は、保守を実施する仮想サーバーの順序に留意してください。

  • WebサーバーやAPサーバーが複数台稼働している場合は、どのサーバーから保守を実施するか

  • 冗長化構成のデータベースを独自に導入している場合、運用系と待機系をどのように切り替えつつ保守を実施するか

  • オートスケールのシステムの場合、テンプレートで使用しているカスタマイズイメージに対してどのように保守を実施するか

  • 複数ゾーン構成や複数リージョン構成のシステムの場合、どのサーバーから保守を実施するか等々
運用・保守方式詳細と参考ドキュメント

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

設計項目

ドキュメント掲載先

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

内容

監視関連

本ドキュメント内

複数ゾーン、複数リージョンでのシステム相互監視例

信頼性の観点を考慮した、複数ゾーン、複数リージョン構成の事例を記載しています。

アクセス経路のセキュリティ関連

CDP

セキュアメンテナンスパターン：踏み台サーバー利用
セキュアメンテナンスパターン：リモートアクセスVPNゲートウェイ利用

メンテナンス用に、ファイアウォールや踏み台サーバー、リモートアクセスVPNゲートウェイを設定するパターンです。

CDP

リージョン間接続パターン：プライベートブリッジ

プライベートブリッジによって、監視サーバーや踏み台サーバー等を共通化するパターンです。
  • ※本ページ記載の金額は、すべて税抜表示です。
  • ※本ページ記載の他社製品名および会社名などは、各社の商標または登録商標です。
  • ※本ページの内容は、2024年5月08日時点の情報です。

推奨画面サイズ　1024×768 以上

ページの先頭へ