本文へジャンプします。

TOP

ニフクラSEハンドブック

クラウド トップ>SEハンドブック>ニフクラ運用・保守設計指針

ニフクラ運用・保守設計指針

ドキュメント情報

区分

設計

リリース日

2022年7月1日

留意事項

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

■ニフクラホームページ

https://pfs.nifcloud.com/

はじめに

  • 本ドキュメントの目的

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

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

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

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

  • 前提知識

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

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

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

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

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

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

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

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

  • 本ドキュメントの注意事項

    • 本ドキュメントは、2022年3月時点の機能をもとに作成しています。ニフクラは継続的にエンハンスが行われるクラウドサービスです。

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

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

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

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

  • 記載内容の粒度

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

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

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

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

    設計のポイント

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

    設計ポイントの適用事例

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

    カテゴリと留意事項

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

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

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

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

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

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

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

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

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

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

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

本ドキュメント活用のメリット
  • 知識の習得

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

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

    • 本ドキュメントで提供するナレッジを活用すると、システムに対する要求事項のうちシステム構成の課題を解決するために構成サンプルを提示し、ニフクラが提供するサービスや機能を利用するか、あるいは利用者側でミドルウエアなどを手配してニフクラの仮想サーバーに導入するかの判断を、商談や要件定義などの早い段階で行えます。

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

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

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

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

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

image

image

ガイダンス

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

設計時に必要な観点
個別に設計する際に必要な観点
移行について
運用・保守について
  • 本ドキュメントの下記章を参照

    • 1. 運用・保守

構成サンプル

運用・保守

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

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

項目

検討内容

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

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

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

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

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

    • 障害・お知らせ通知について - お知らせ通知
      https://pfs.nifcloud.com/service/notice.htm

    • 作業依頼の通知の場合メール件名は「[重要][ニフクラ]お客様利用環境に関するお知らせ」で通知されます。

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

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

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

運用作業におけるニフクラのサービス/機能の利用

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

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

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

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

災害発生時の対策検討とSLA

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

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

[SLA]
  • ニフクラでは仮想サーバー、ネットワークサービス等にSLAを設定しています。ニフクラの仮想サーバーのSLAは、仮想サーバー一台から適用されます。複数ゾーンの利用が必須といった条件はありません。そのためHAを許容できれば複数ゾーンで構成する必要はありません。

  • SLAは、稼働保証ではありません。SLAを遵守できなかった場合は減額対応します。

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

image

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

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

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

Zabbix 等の監視ツールで可能

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

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

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

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

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

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

カテゴリ項目

作業

ニフクラでの作業概要

備考

運用・保守

運用・保守体制の設計

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

定常時運用の方式設計

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


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

障害時運用の方式設計

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

保守時運用の方式設計

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

運用・保守規約の設計

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

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

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

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

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

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

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

留意事項

留意事項

内容

運用保守の責任分解点

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

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

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

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

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

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

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

ニフクラのサポート

種別

対応時間

問題解決支援

内容

導入相談窓口

平日9:00~17:45

メール/電話

ニフクラの仕様・機能や料金、導入相談などの問い合わせや見積もりなどに対応します。

トラブル窓口

24時間365日 [2]


2. 法定点検時等を除く

メール/電話

ニフクラを利用中のトラブルについての問い合わせに対して対応します。無償のベーシックサポートと有償のエンタープライズサポートを選択できます。

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

一般的な設計項目

方式設計の概要

1

設計前事前確認

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

2

システム起動・停止

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

3

時刻補正

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

4

システム監視

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

5

バッチ業務制御

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

6

バックアップ・リカバリ

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

7

ログ管理

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

8

リモート操作

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

9

ユーザー管理

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

10

データベース管理

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

11

構成管理

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

12

変更管理

13

リリース

14

キャパシティ管理

15

帳票管理

16

外字管理

17

消耗品管理

システム起動・停止(定常時)
作業概要
  • システム全体の起動・停止を行う場合の手順を設計してください。

留意事項

留意事項

内容

仮想サーバーのステータス

[仮想サーバーの状態]

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

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

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

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

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


3. 仮想サーバーにログインする方法については、ssh(Linux系)やRDP(Windows系)での一般的なリモートログインに加えて、ニフクラが提供するコンソール機能の利用もあわせて検討してください。

仮想サーバーの自動起動

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

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

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

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

留意事項

留意事項

内容

選択値・条件

NTPサービス

ニフクラの仮想サーバーでは、スタンダードイメージを使用して配備した場合、VMware Toolsによる物理サーバーとの時刻同期は無効になっており、ゲストOSの時刻同期ソフトウエアが有効になっています。別途仮想サーバーをNTPサーバーとして構築し、他仮想サーバーの時刻を構築したNTPサーバーと同期させることも可能です。要件に応じて対応してください。
また、外部公開NTPサーバーと同期を行う際にはインターネットへのアクセスが必要になります。インターネットへアクセス可能な構成にしてください。

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

ネットワーク構成

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

ニフクラRDB

ニフクラRDBでは、サービス内で時刻同期を行っております。

image

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

留意事項

留意事項

内容

選択値・条件

リソース監視

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


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

基本監視でリソース監視可能な項目

  • 仮想サーバー:CPU使用率/メモリ使用率/ディスク使用率

  • ロードバランサー/マルチロードバランサー:ネットワーク流量

  • ディスク(ローカルディスク、増設ディスク):ディスクのパーティション使用率

  • パフォーマンスチャートで最大過去6ヶ月間までのリソース情報を確認可能

  • 基本監視では検知後のアラート通知は最短10分

  • リアルタイムチェック不可

リソース監視とアラーム機能

基本監視サービスでは、閾値を設定し、その閾値を超えた際にメールを送信するアラートメールを利用可能です。 この閾値を利用してオートスケールを実行することも可能です。アラームの閾値で設定できるのは数値のみで文字列を設定できないため、ログ監視用途にも不向きです。リソースの閾値を監視するレベルではなく、システムを統合的に監視したい場合は、下記項目を検討してください。

OS内部でのコマンド実行不可

システム監視

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

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

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

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


5. 大規模環境におけるシステム監視方式例は、本ドキュメント内「複数ゾーン複数リージョンでのシステム相互監視例」 を確認してください。
バッチ業務制御(定常時)
作業概要
  • バッチ業務処理に関する運用保守の手順を設計してください。

留意事項

留意事項

内容

バッチのジョブ管理

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

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

  • SystemWalker Operation Manager(ニフクラでは サードパーティ製のソリューションサービスとして利用可能です。)

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

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

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

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

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

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

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

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

  • 処理時間の遅延

  • データ転送により発生する費用

バックアップ・リカバリ(定常時)
作業概要
  • 誤操作や障害の発生に備えたバックアップデータの取得と、バックアップデータからのデータリストアについての運用を設計してください。バックアップ・リカバリの方式設計に関しては、「ニフクラSEハンドブック_ニフクラ導入・移行設計指針(共通編)データ保全対策の方式設計」及び「ニフクラSEハンドブック_バックアップ」の章もあわせて確認してください。

留意事項

留意事項

内容

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

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

  • ①カスタマイズイメージ (バックアップ) /イメージ配布

  • ②ワンデイスナップショット

  • ③バックアップ

  • ④バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud) [6]

  • ニフクラが提供するバックアップ関連サービスの比較表については、以下を確認してください。 https://pfs.nifcloud.com/pdf/backup_spec.pdf


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

バックアップの世代管理

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

  • ニフクラでは、上記①ではバックアップに関する世代管理は利用者側が行う必要があります。

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

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

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

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

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

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

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

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

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

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

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

リストア時の状態

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

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

  • ④ バックアップを取得した元サーバーでも別サーバーに対してもリストアが可能です。

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

留意事項

留意事項

内容

選択値・条件

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

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

基本監視サービスによるログの保持期間は最長6ヶ月間

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

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

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

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

主に利用されるニフクラ機能のうち、ログが取得できないものがあります。
内容に関しては各機能の詳細を確認してください。

以下は取得不可

  • ロードバランサー(L4)のアクセス制御ログ

  • コントロールパネル操作以外の仮想サーバー内のログ

  • オブジェクトストレージのログ

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

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

留意事項

留意事項

内容

リモートログイン手段

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

セキュリティ

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

  • アクセス元を限定する

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

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

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

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

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

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

踏み台サーバー

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

ユーザー管理(定常時)
作業概要
  • ニフクラ利用者の立場や状況に応じて、適切な権限を設定してください。

  • ユーザー管理については「ニフクラSEハンドブック_ニフクラ導入・移行設計指針(共通編)認証管理に関する留意事項」も合わせて確認してください。

留意事項

留意事項

内容

選択値・条件

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

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


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

管理者権限、運用者権限、閲覧権限のアカウント作成可能

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

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

データベース管理(定常時)
作業概要
  • データベースに関する運用方式を設計してください。

  • データベースの方式設計に関しては、「ニフクラ個別設計・移行設計指針 ニフクラRDB設計のポイント」もあわせて確認してください。

留意事項

留意事項

内容

選択値・条件

ニフクラRDBの監視

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

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

ニフクラRDBにおいて、ニフクラRDBの再起動を行う場合は、冗長化設定を確認してください。
冗長化設定が「有効」で、「フェイルオーバーを通して再起動する」を選択して再起動した場合、フェイルオーバーが発生します。フェイルオーバーを発生させる必要がない場合は「通常通り再起動する」を選択して再起動してください。

ニフクラRDBのバックアップ、リストア

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

ニフクラRDBのデータリストアの方法としては、ポイントインタイムリカバリーと手動スナップショットからのリストアがあります。

[ポイントインタイムリカバリー]

ポイントインタイムリカバリーでは、バックアップ保持期間~最新のトランザクションログ保持時点の間で復旧日時を指定して、復旧を行うことが可能です。

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

手動スナップショットからのリストアでは、事前に取得していたスナップショットデータをもとに新規に仮想データベースの作成を行います。

[リストアの有効範囲]

ニフクラRDBのリストアは、同一ゾーンにニフクラRDBを新規に作成して行います。他ゾーン/リージョンに対してデータをリストアすることはできません。

最新のトランザクションログ保持時点 (最長5分前)

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

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

留意事項

留意事項

内容

選択値・条件

運用保守の責任分界点

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

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

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

約14日前を目安にメンテナンス通知

定期メンテナンスに関しては告知は行われません。定期メンテナンス中は、コントロールパネルとAPIを利用できないため留意してください。

毎月第3木曜日 午前8時~10時に定期メンテナンス実施

ニフクラのSLA

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

仮想サーバーのSLA:99.99%
(それぞれのサービスで設定している稼働率は異なります。)

ニフクラのMTTR/RTO等

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

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

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

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

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

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

留意事項

留意事項

内容

選択値・条件

運用保守の責任分界点

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


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

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

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

約14日前を目安にメンテナンス通知

定期メンテナンスに関しては告知は行われません。定期メンテナンス中は、コントロールパネルとAPIを利用できないため留意してください。

毎月第3木曜日 午前8時~10時に定期メンテナンス実施

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

作業依頼の通知の場合メール件名は「[重要][ニフクラ]お客様利用環境に関するお知らせ」で通知

仮想サーバーの保守順序

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

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

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

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

  • 複数ゾーン構成や複数リージョン構成のシステムの場合、どのサーバーから保守を実施するか等々

運用・保守方式詳細と参考ドキュメント

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

設計項目

ドキュメント掲載先

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

内容

監視関連

本ドキュメント内

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

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

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

CDP

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

CDP

プライベートブリッジによって、監視サーバーや踏み台サーバー等を共通化するパターンです。

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

0120-22-1200

0120-22-1200

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