投稿者「climb」のアーカイブ

クラウドデータマネジメントとは?

クラウドデータ管理とは、データを自社のサーバーではなく、クラウド上に置くことです。クラウドデータは、オンプレミスのデータストレージを補完することができますが、すべてのデータをクラウドに置くことを選択する企業も増えています。クラウドデータマネジメントの利点は、ユーザがどこからでもデータにアクセスできることです。また、データ管理にクラウドを利用することで、バックアップ、災害復旧、アーカイブがよりシンプルになり、必要に応じてストレージを追加購入できるため、費用対効果も高くなります。ただし、クラウドによるデータ管理は、セキュリティやデータ損失などの問題が発生する可能性があるのが難点です。

 

なぜクラウドデータマネジメントを選ぶのか?
従来のデータストレージには、いくつかの欠点があります。

・老朽化したハードウェアのアップグレードや交換に費用がかかる
・データセンターの賃貸料の高騰
・スケーリング(拡張)に伴う追加コスト
・コンプライアンスに対応するための専門的な社内ノウハウ
・オンプレミスでのデータ保持のリスク増大

 

クラウドでのデータ管理は、柔軟性、内蔵のセキュリティ、手頃な価格で、これらの問題を解決します。しかし、クラウドへのデータ移行は複雑で時間がかかり、データを危険にさらすだけでなく、社内のリソースを消費してしまう可能性があります。

SaaSとは?

SaaSは、ベンダーが提供する完全なソフトウェアソリューションを、通常は消費ベースで提供します。一般的な例としては、電子メール、カレンダー、オフィスツール(Microsoft Office 365など)などがあります。基本的に、お客様は組織のためにアプリケーションをレンタルし、ユーザはインターネットを介してそのアプリケーションに接続します。

 

インフラからアプリのデータまで、基盤となる部分はすべてサービス・プロバイダーのデータセンターに収容されます。ベンダーは、アプリケーションのアップタイムには責任を負いますが、アプリケーションでホストされているデータには責任を負いません。データに対する責任は、ユーザが負うことになります。

 

なぜSaaSを選ぶのか?

SaaSは、ソフトウェアとハードウェアのための最小限の初期費用で、高度なアプリケーションにアクセスする柔軟性を組織に提供します。SaaSでは、ハードウェア、ミドルウェア、ソフトウェアの購入、インストール、更新、保守の必要がないため、ERPやCRMなどの高度なエンタープライズ・アプリケーションも、あらゆる規模の組織で手頃な価格で利用することができます。通常は使用した分だけを支払います。SaaSサービスは、自動的にスケールアップとスケールダウンを行います。また、インターネットに接続できる環境であれば、どのコンピューターやモバイル機器からでもSaaSアプリケーションやデータにアクセスすることができます。

 

SaaSの保護

しかし、ほとんどのSaaSソリューションが責任共有モデルを採用しているため、SaaSデータの保護は組織に委ねられています。ソフトウェア・ベンダーによる基本的な保護はあるものの、SaaSのデータはベンダーの責任ではなく、ユーザの責任となります。つまり、障害、不慮の削除、ランサムウェアの攻撃は、復元不可能なデータと生産性の損失につながる可能性があるということです。

クラウドの種類は?

パブリッククラウドは、組織がオンデマンドのコンピューティングサービスとインフラストラクチャを管理するためにプロバイダーを雇うコンピューティングモデルである。このプロバイダーは、月額または使用量に応じた料金の購入でコンピューティングリソースを提供し、複数の組織がリソースを共有するのが一般的です。

 

プライベートクラウドは、コンピューティングリソースが専用で専有されており、基盤となるハードウェア層が他のすべてから分離されていることを意味します。企業は、自社のデータセンター、コロケーション施設、またはプライベートクラウドプロバイダーを利用することができます。

 

ハイブリッドクラウドモデルは、プライベートクラウドとパブリッククラウドを組み合わせて使用し、クラウドコンピューティングの柔軟な組み合わせを作成します。ハイブリッドクラウドコンピューティングは、インフラと運用を拡張し、組織のニーズに一貫して対応します。

 

さまざまなクラウドの選択肢は何を提供するのか?

 

パブリッククラウドサービスプロバイダーは、アクセスのしやすさ、コスト効率、オプションサービスなどを提供します。企業は、データの保存や機密性の低いアプリケーションのために、パブリッククラウドサービスを利用することがよくあります。

 

プライベートクラウドは、コントロールしやすく、セキュリティも高いが、メンテナンス、アップグレード、ソフトウェアの管理は、通常エンドユーザーが行います。

 

プライベートクラウドとパブリッククラウドのリソースを組み合わせてハイブリッドクラウドを構築する場合、企業はニーズに合わせてサービスの組み合わせを選択し、運用やコストの変化に応じてアプリケーションやデータを異なるクラウド間で柔軟に移行することが可能になります。

IaaSとは?

IaaSは、インターネット上で必要なコンピューティングインフラを提供し、多くの種類のワークロードのための標準的なモデルとして急速に普及しました。IaaSには物理リソースと仮想リソースの両方が含まれ、クラウド上でアプリケーションやワークロードを実行するために必要なものが提供されます。

 

IaaSプロバイダーは、通常世界中にある大規模なデータセンターを管理しており、その中には、その上にあるさまざまな層の仮想化コンピューティングリソースを動かすのに必要な物理マシンが入っています。これらのサービスには、通常、自動スケーリングやロードバランシングなどのサポートサービスが付属しています。IaaSには、ネットワーキングとストレージのサービスも含まれます。

 

IaaSを選択する理由
IaaSの人気は、その柔軟性と費用対効果に大きく起因しています。IaaSは、組織のニーズや要件に応じて、コンピューティング・インフラストラクチャを簡単にスケールアップまたはスケールダウンできるため、柔軟性があります。また、サードパーティ製のディザスターリカバリーソリューションを柔軟に選択することができます。IaaSの費用対効果は、従量課金制であることと、物理的なコンポーネントやその他のプライベートインフラへの支出を削減できることの両方から生まれます。

PostgreSQL パフォーマンス・チューニング

PostgreSQLは、新世代のエンタープライズアプリケーションのためのデータベースです。あなたのデータベースのパフォーマンス監視とチューニングのツールもエンタープライズクラスですか?

 

クライムとSolarWindsは、Confioからの10年以上に渡ってOracleとSQL Serverのユーザにソリューションを提供してきたため、データベースのパフォーマンス管理について多くのノウハウを持っています。ユーザの声に耳を傾けてユーザから学んでいます。そのため、現在ではオープンソースのデータベースを数多くサポートし、その数は増え続けています。

 

私たちは、性能監視、PostgreSQLクエリチューニング、I/Oチューニングなどに対応する2つのソリューションで、私たちの専門知識をPostgreSQLに提供します。

 

どちらもユーザをエンタープライズクラスとして大きく手助けします。

 

Database Performance Analyzer (DPA)は、Oracle、SQL Server、MySQL、その他を含む広範なデータベースプラットフォームをサポートします。PostgreSQLの深いクエリチューニングと分析に機械学習を組み合わせてエンドツーエンドのITパフォーマンス管理を実現します。

 

Database Performance Monitor (DPM)はPostgreSQL監視ソリューションで、開発者、SRE、DBAのいずれにも有用なSaaSベースのインターフェイスを提供します。DPMは、MySQL、MongoDB、Redisなどの主要なオープンソースデータベースのシステムおよびデータベースの監視と分析の両方を提供します。

データベーススキーマは何に使うのですか?

データベーススキーマは、情報を体系的に整理するために設計された認知的な枠組みや概念です。スキーマがあれば、膨大な量の情報を素早く解釈することができる。未整理のデータベースは混乱しやすく、維持・管理も困難です。きれいで、効率的で、一貫性のあるデータベーススキーマの設計により、組織のデータを最大限に活用することができます。リレーショナルデータベースは、データの冗長性を排除し、データの不整合を防ぎ、データの検索と分析を容易にし、データの整合性を確保し、不正なアクセスからデータを保護するために、データベーススキーマ設計に大きく依存します。強力なテスト環境でデータをテーブルとカラムに整理することが極めて重要です。データの整合性を管理し、データベースとソースコードを更新する計画が必要です。

データベースのスキーマには、大きく分けてどのような種類があるのでしょうか。

物理データベーススキーマ: 物理データベーススキーマは、データの物理的な配置と、ファイル、インデックス、キーと値のペアなどのストレージのブロックへの格納方法を表します。

 

論理データベーススキーマ:論理データベーススキーマはデータの論理的な表現を記述し、論理的な制約を伝達する。データはある種のデータレコードとして記述することができ、異なるデータ構造として格納される。ただし、データの実装などの内部的な詳細はこのレベルでは隠されている。

データベーススキーマ設計のベストプラクティス

データベーススキーマを最大限に活用するためのベストプラクティスを以下に紹介します。

 

セキュリティ: 効果的なデータベーススキーマの設計は、データセキュリティに重点を置く必要があります。また、ログイン情報、個人を特定できる情報(PII)、パスワードなどの機密データを保護するために、高度な暗号化を使用します。
名前の規則: スキーマ設計をより効果的にするために、データベースで適切な命名規則を定義することができます。テーブル、カラム、フィールド名には、複雑な名前、特殊文字、予約語を使用しないようにします。
正規化: 正規化とは、独立したエンティティやリレーションシップが、同じテーブルやカラムにまとめられないようにすることで、冗長性を排除するものです。これにより、データの整合性が向上し、開発者が情報を取得しやすくなります。また、正規化により、データベースのパフォーマンスを最適化することもできます。
ドキュメンテーション: データベーススキーマは、開発者とドキュメンテーションの作成にとって非常に重要です。データベーススキーマの設計は、説明書、コメント、スクリプトなどとともに文書化する必要があります。

データベーススキーマの設計方法

データベーススキーマの設計は、データの書式が一貫していること、すべての項目が主キーを持つこと、重要なデータが除外されていないことを保証します。データベーススキーマは、視覚的なものと論理的なものがあり、データベースを管理するための公式のセットを含んでいます。開発者は、これらの公式とデータ定義を使用して、データベーススキーマを作成します。

 

最も一般的なデータベーススキーマの種類を以下に概説します。

 

階層的モデル: 階層型:ルートノードに子ノードが付随するツリー状の構造を持つデータベーススキーマを階層型という。このデータベーススキーマモデルは、家系図などのネストされたデータを格納することができる。

 

フラットモデル:フラットモデル: データを単次元または二次元の配列に整理したもので、行と列を持つスプレッドシートのようなモデル。このモデルは、複雑な関係を持たない単純なデータを表形式で整理するのに適している。

 

リレーショナルモデル:リレーショナルモデルは、データが表、行、列に整理されるフラットモデルに似ている。ただし、このモデルでは、異なるエンティティ間の関係を定義することができる。

 

スタースキーマ: スターデータベーススキーマは、データを「ディメンション」と「ファクト」に整理します。ディメンジョンには説明的なデータが含まれ、ファクトには数値が含まれる。

 

スノーフレークスキーマ: スノーフレーク(雪片)型データベーススキーマは、データベース内のデータを論理的に表現したものである。このタイプのスキーマの表現はスノーフレークに似ており、複数のディメンジョンが1つの集中ファクトテーブルにくっ付いている。

 

ネットワークモデル: ネットワークデータベーススキーマは、データを接続された複数のノードとして含みます。このモデルは、多対多の関係などの複雑な接続を可能にするため、特定のタスクを達成するために使用されます。

データベース・スキーマ設計とは?

データベーススキーマ設計は、データベースのアーキテクチャを開発するための設計図を提供することで、膨大な情報を体系的に格納することができる。また、データベースの構築に関わる戦略やベストプラクティスを指します。データベーススキーマ設計は、データを個別のエンティティに整理し、整理されたエンティティ間の関係を決定することによって、データの消費、解釈、取得をはるかに容易にします。

データベースのスキーマはどのように設計されているのですか?

データベース設計者は、プログラマーが効率的にデータベースを操作できるように、データベーススキーマを作成します。データベースを作成するプロセスは、データモデリングとして知られています。データベーススキーマを設計するためには、情報を収集し、それらをテーブル、行、列に並べる必要があります。情報を整理することで、理解しやすく、関連付けやすく、使いやすくする必要があります。

データベーススキーマの定義

データベーススキーマとは、リレーショナルデータベース全体の論理的、視覚的な構成のことである。データベースのオブジェクトは、テーブル、関数、リレーションとしてグループ化され表示されることが多い。スキーマは、データベース内のデータの構成と格納を記述し、さまざまなテーブル間の関係を定義します。データベーススキーマは、スキーマ図を通して描くことができるデータベースの記述的な詳細を含んでいます。

Database Performance Analyzer vs. Database Performance Monitor

Database Performance Analyzer

 

 

DBAは、複数のデータベースプラットフォームでより多くのデータベースインスタンスを管理する必要に迫られています。Database Performance Analyzer(DPA)を使用すれば、機械学習による異常検知や履歴およびリアルタイム分析などの機能により、数分でパフォーマンス問題をピンポイントで特定できる、データベースパフォーマンス管理への一貫したアプローチを手に入れることができます。

 

DPAの主な機能は以下のとおりです。

 

●専門家によるクエリーのアドバイス、ブロッキング、リソース利用による多次元クエリー分析
●カスタムアラート、メトリクス、レポーティング
●VMwareの監視と分析を統合
●シンプルでエージェントレスなインストールにより、オーバーヘッドを1%未満に抑えることが可能
●オンプレミス、Azure、Amazon(RDSおよびAurora)インスタンスを含む幅広いデータベースプラットフォームが対象

 

Database Performance Monitor

 

 

アプリケーションを所有する開発者、データベースのリアルタイムおよび過去の統計情報を必要とするSREやDBAは、すべて Database Performance Monitor(DPM)の恩恵を受けることができます。直感的なインターフェイスは、コードの展開とデータベースのパフォーマンス監視を行う部門横断的なチームの作業をサポートします。

 

DPMの主な機能は次のとおりです。

 

●パフォーマンスの前後を測定するための時間比較
●カスタムアラートとダッシュボード
●システムとデータベースの両方のメトリックスにより、全体的な健全性を洞察
●部門横断的なチーム向けに拡張性のあるSaaSプラットフォーム
●MySQL、MongoDB、Redis、Auroraなど、幅広いオープンソースデータベースプラットフォームをカバー

仮想化されたPostgreSQLの統合監視

DBAは、PostgreSQLのパフォーマンスチューニングと分析に関して、しばしば指南役となります。誰かがアプリケーションのパフォーマンス低下について不満を漏らすと、データベースのバックエンドが最初に非難されることがよくあります。

 

しかし、PostgreSQLインスタンスがVMware仮想マシンで動作している場合はどうでしょうか。多くの場合、DBAはPostgreSQLインスタンスをサポートする仮想インフ ラの影響(もしあれば)を全く見ることができません。DPA VMオプションによる統合仮想化監視は、VMがPostgresの性能問題を引き起こしているかどうかを判断するために必要なデータをDBAに提供します。VMのメトリクスとデータベースのメトリクスを重ねた独自の「タイムスライス」ビューから、詳細なESXiホストのメトリクスまで、DBAはPostgreSQLインスタンスへの影響を判断するのに必要なデータを手に入れることができます。

PostgreSQL Azure、AWS、Googleの徹底チューニング

クラウドコンピューティングプラットフォーム上でPostgreSQLを実行する場合、パフォーマンスの最適化とチューニングが重要です。なぜなら、計算リソースの対価として、非効率的で不適切なクエリは、フロントエンドアプリケーションのパフォーマンスへの影響は言うまでもなく、コストにつながる可能性があるからです。

 

DPAは、PostgreSQLのパフォーマンス管理に対して、以下のような全体的なアプローチを提供します。

 

●リアルタイムおよびヒストリカルビュー
●24時間365日、秒単位のデータ収集が可能
●シンプルでエージェントレスな実装により、オーバーヘッドを1%未満に抑えることができます。
●ポストグレスに特化したレポート(アドホックまたはスケジュール型)
●機械学習による異常検知
●多角的なクエリ待ち時間分析
●問題箇所をピンポイントで特定するクエリアドバイザ
●システムおよびPostgreSQLの両方のメトリクス
●SQLテキストへのドリルダウンとライブプランの実行
●ドラッグ&ドロップでカスタマイズできるメールアラートテンプレート
●自動化統合のためのRESTful API
●DPAは、物理サーバーやVM、Azure、AWSのサービスとして実装することが可能

機械学習+クエリアドバイザ=PostgreSQLの最適化

DPAの異常検知は、時間の経過とともに賢くなる機械学習をベースに、季節性を利用して何が正常で何が正常でないかを判断しています。この強力な機能により、DBAは意識していなかったものも含め、パフォーマンスの問題を通常数秒で発見することができます。

 

機械学習と高度な待ち時間解析の組み合わせにより、クエリが影響を受けている理由と場所を示し、従来の監視ソリューションでは実現できなかったPostgreSQLの最適化の可視性を提供します。

 

DPAは、パフォーマンス低下の原因を指摘するクエリアドバイザによる専門的なアドバイスによって、PostgreSQLのチューニングをさらに一歩推し進めます。

PostgreSQLの重要なメトリクスを可視化する

DPAは、24時間365日、秒単位のデータ収集により、ディスク、メモリ、ネットワークなどの主要なシステムメトリクスを含むPostgreSQL環境の広範なメトリクスを測定します。さらに、PostgreSQL固有の主要なメトリクスを簡単に利用できます。

 

キャッシュエビション
チェックポイント
レプリケーション
バキューム
行の操作
ライセンスコンプライアンス

 

これらの指標と、リアルタイムおよび履歴ビューを組み合わせることで、DBAはPostgreSQLのチューニング指標に簡単にアクセスすることができます。

クラウドからオンプレミスへのPostgreSQLの適用範囲

PostgreSQLデータベースインスタンスは、Linux、Windows Server、VMware仮想マシン、クラウドプラットフォームのどこで実行しても、Database Performance Analyzer(DPA)でカバーすることができます。

PostgreSQLプラットフォームの広範なサポートは以下のとおりです。

 

  • PostgreSQL
  • EDB Postgres
  • Azure Database for PostgreSQL
  • Amazon RDS for PostgreSQL
  • Amazon Aurora for PostgreSQL
  • Google Cloud SQL for PostgreSQL

 

DPAのPostgreSQLデータベース管理へのハイブリッドアプローチは、エージェントレスアーキテクチャと1%未満のオーバーヘッドで、データベースパフォーマンスのチューニングと最適化への一面的なビューを提供します。

 

DPAの異常検知

DPAでは、異常検知アルゴリズムを用いて、予期せぬ待ち時間の増加を検知しています。ある期間では、待ち時間が多くても正常である場合があります。DPAは、過去のデータを使って正常な状態を「学習」し、そのデータに基づいて予測を行います。ある時間帯の待ち時間が予想より大幅に長い場合、DPAは異常を報告します。

DPAのテーブル・チューニング・アドバイザー

非効率なクエリ、つまり、多くの行を読み取るが、返す行数は比較的少ないクエリのパフォーマンスを改善する方法を決定する際には、多くの要因を考慮する必要があります。DPAのテーブルチューニングアドバイザーは、十分な情報に基づいた意思決定を支援します。DPAは毎日、非効率的なクエリが実行されたテーブルを特定します。各テーブルについて、テーブル チューニング アドバイザー ページには、非効率的なクエリ、テーブル構造、および既存のインデックスに関する集約された情報が表示されます。こ の情報は、 次の よ う な質問に答 え る のに役立ち ます。

 

●クエリの計画をレビューする際に、どのステップに焦点を当てるべきか?
●このテーブルには現在いくつのインデックスが存在し、それらはどのようなものか?
●パフォーマンスを向上させるためにインデックスを追加することは可能か?
●統計は古くないか?
●テーブルのチャーン(挿入、更新、削除)はどの程度行われているか?

DPAのクエリー・パフォーマンス解析

クエリのパフォーマンス問題の根本原因を調査するために、DPAはクエリに関する最も関連性の高いデータをインテリジェントに収集し、「クエリの詳細」ページに表示します。この情報を使用して、次のことを行います。

 

●パフォーマンスに影響を及ぼしている待機の種類を確認し、各待機の種類に関する詳細情報および推奨事項を表示します。
●クエリおよびテーブルのチューニングアドバイザーを確認する
●統計およびメトリックスチャートで、クエリ待ち時間と他のイベントとの関連性を調べることができます。

 

DPAは、主な待ちの種類やその他の情報をもとに、最も関連性の高い統計、ブロッキング、プラン、メトリクスチャートを自動的に選択します。これらのチャートを表示するためにスクロールダウンしても、「トップウェイト」チャートは表示されたままなので、同じ時間帯の他のイベントとクエリ待ち時間を関連付けることができます。この情報は、複雑なパフォーマンス問題の根本原因を特定するために必要なコンテキストを提供します。

DPAの待ち時間(Wait-based)を利用した分析

従来のデータベース監視ツールは、データベースの健全性指標に着目して、パフォーマンス問題のトラブルシューティングを行います。DBA(DB管理者) は、これらの指標を改善するために何時間もかけてデータベースをチューニングしますが、その変更がパフォーマンスにほとんど影響を与えないことに気付くことがあります。

 

DPA(Database Performance Analyzer)は、データベースの健全性指標の代わりに、アプリケーションとエンドユーザーの待ち時間に注目します。DPAは、待ち時間が最も長い場所をグラフィカルに表示し、待ち時間が予想より長い時間帯(異常)も特定します。パフォーマンス問題の根本原因を掘り下げることができ、その修正方法に関するアドバイスを得ることができます。DPAを使用して、長い待ち時間の直接の原因となっている問題を発見し修正すれば、注目されるパフォーマンス改善を実現することができます。

 

DPAのホームページを使用して、待ち時間の長いデータベースインスタンスや異常なインスタンスを素早く特定し、ドリルダウンして詳細を確認することができます。

 

スナップショットとは?

従来のバックアップ方法では、仮想マシン(VM)を保護するためにスナップショットを使用していました。バックアップの際、目的のデータのスナップショットが取られ、専用のバックアップ・ストレージに移動されます。大規模な組織では、このストレージは、拡張性とサービスレベル契約要件を満たすために強力なリソースを必要とします。スナップショットでは、システムリソースが枯渇するため、システム管理者は深夜などの使用頻度の低い時間帯にスナップショットのスケジュールを組む必要があり、データギャップは必要不可欠なものです。

スナップショットの仕組み
スナップショットは、特定の時点から仮想マシン(VM)を複製し、災害からの復旧のために複数の復旧ポイントを維持するためによく使用されます。スナップショットは、VMレベルまたはストレージ・エリア・ネットワーク(SAN)レベルで実行できます。

VMレベルのスナップショットはハイパーバイザーで作成され、パフォーマンスに最も大きな影響を及ぼします。VMレベルのスナップショットベースのレプリケーション・システムは通常、パフォーマンスへの影響を軽減するために、毎日または毎週、業務時間外にレプリケーションを行うように構成されています。

ストレージレベルのスナップショットは、VMレベルのスナップショットに比べてパフォーマンスへの影響は少ないものの、ストレージコントローラの処理能力を必要とし、規模が大きくなるとパフォーマンスを低下させる可能性があります。そのため、ストレージレベルのスナップショットを作成する頻度は、パフォーマンスに影響を与える可能性があるため、非常に限られています。

 

スナップショットのデメリット
上述したように、バックアップと保護に関して、スナップショットには主に2つの欠点があります。それは、パフォーマンスへの影響と、スナップショットが提供するリカバリポイントの粒度です。

 

●パフォーマンスへの影響: スナップショットの作成と使用は、本番環境のパフォーマンスに悪影響を与えるため、データを保護するためには慎重な計画とスケジューリングが必要です。この悪影響を避けるため、スナップショットは通常、数時間に1回、場合によっては24時間に1回だけ取得されます。数時間おきに取得したリストアポイントは、ダウンタイムが発生した場合、最大で24時間分のデータ損失が発生するなど、大きな影響を及ぼします。

●非粒度(細かさ): スナップショットはVM単位の一貫性のみをサポートします。つまり、アプリケーションが複数のVMで構成されている場合、スナップショットはすべてのVMで一貫性を維持することができません。このため、ダウンタイムが発生した場合、すべてのVMが異なる一貫性のない時点にリカバリされる可能性があります。

ビジネスインパクト分析(BIA)とは?

BIAは、組織の重要で時間的制約のある業務に着目し、自然災害を含むあらゆる中断、機能停止、または災害が発生した場合に何が起こるかを判断するものです。 BIAは、事業継続の要件とリソース依存に重点を置き、ダウンタイムが組織にどのような影響を与えるかを示すことで、特定のビジネス要件を正当化します。

 

リスクアセスメントとビジネスインパクト分析
事業継続計画の関連ステップであるリスクアセスメントでは、サイバー攻撃、ネットワーク障害、自然災害、サプライヤー障害、ユーティリティ停止など、具体的に起こりうる災害や障害を特定する。リスクアセスメントでは、これらの脆弱性を軽減することに焦点を当てます。

BIAは、リスクアセスメントの段階で明らかになったリスクが、万一発生した場合にビジネスにどのような影響を及ぼすかを予測しようとします。これにより、ビジネスへの影響を軽減し、ビジネスの継続性を確保するために、それぞれのリスクに対してどのような回復策が必要かを判断します。 BIAの結論は、ビジネスをサポートするすべてのタイプのアプリケーションとプロセスに関連するRTOとRPOの要件を推進することになります。

BIAを実施するには?
ビジネスインパクト分析の方法は業界によって異なるため、一概には言えませんが、以下のリストはBIAで評価すべき多くの分野です。

●計画外の混乱時に起こりうる変化
●計画外の混乱がもたらす法的または規制上の影響
●事業継続に必要な全事業部門のインベントリ
●主要な人材とサポートスタッフ
●障害発生後の依存関係
●テスト計画の妥当性確認
●優先順位と作業順序の決定

 

BIAは、これらの領域に加え、組織内の複数の部門やビジネスユニットを巻き込んで分析を行い、ユーザのニーズに合った復旧戦略の立案を支援します。

バックアップ計画の設定が2種類ありますがどのような違いがありますか

v7.0から追加された新しいバックアップ形式と従来のバックアップ形式(Legacy)です。
新しいバックアップ形式では従来よりもバックアップやリストアが高速化し多くの新機能がございます。

詳細は下記をご参照ください。

CloudBerry(MSP360) Backup 7.0リリース