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

ディザスターリカバリテストが重要な理由

分散型システムにおけるリカバリーの課題

よく設計された分散システムでは、あるコンポーネントの故障がシステム全体の故障を意味することはないはずです。むしろ、故障はそのコンポーネント自体に分離されるべきです。このような種類の障害を適切に検出し、対応するようにシステムを設計することは可能である。いずれにせよ、災害復旧テスト計画は、現実的な条件が訓練されるように、これらのニュアンスを考慮する必要があります。ここでは、復旧可能な分散型システムを設計する際に対処しなければならない課題をいくつか紹介します:

ネットワーク障害とデータレプリケーション
ネットワークトポロジーは、通常の運用中に変化することがあります。ネットワーク・パーティション、ネットワークの混雑、ポリシー、ルール、セキュリティ・グループ、その他多くの要因によって、システム内のコンポーネント間で断続的または恒久的な切断が発生することがあります。

フェイルオーバー時のプライマリーネットワークとリカバリーネットワークをどのように設計し、運用しているか?また、本番システムと並行してどのようにテストを行うかを理解することも重要です。リカバリーシステムは、オンデマンドでリカバリーできることが分かっていればそれでいいのです。

分散トランザクション管理
分散システムで実行されるトランザクションは、複数のシステムにまたがる可能性があり、それらのシステム間で調整する必要があることを意味します。この調整は、複数のマシンプロセスにまたがるトランザクションを調整することになるため、些細なことではありません。

さらに、トランザクションは、それらの他のマシン上の他のトランザクションや、データベースやファイルシステムなどの外部リソースと調整する必要がある場合があります。

サービス依存性の解決
サービス間でビジネスロジックの実行やサービスコールを連携させるためには、サービス同士を見つけることができる必要があります。ほとんどのマイクロサービス実装では、サービスディスカバリーが必要ですが、モノリシックなアーキテクチャでも応用が可能です。

データの一貫性と回復
多くの場合、ディザスタリカバリは、データの損失や破損を最小限に抑えながら、できるだけ早くサービスを回復することを目的としています。したがって、アプリケーションは、状態を失ったりデータを破損したりすることなく、障害から回復できるように設計されていなければなりません。

バックアップとディザスタリカバリの計画
バックアップは復旧計画に欠かせないもので、データのバックアップコピーがない場合は、ゼロから作り直すことも可能です。

災害復旧テスト + 復旧メカニズムの検証
リカバリープランは複雑なメカニズムに依存しており、本番環境に導入する前にテストが必要です。

ソフトウェアの新バージョンが常にリリースされ、リカバリに影響を与える可能性のある新機能が追加されるため、テストは定期的に行う必要があります。

N2WS vs. AWS Backup

復旧シナリオ : AWS環境でのデータ保護の構成管理ツール「 N2WS 」では、災害やAWSの停止が発生したときに実行できるシナリオを作成することができます。これにより、最も重要なリソースを重要度の高い順に復旧させ、RTO/RPOを最小化することができます。この機能のドライラン機能により、テストを実施し、これらの復旧を実行するための準備がすべて整っていることを確認することができます。

 

クロスリージョン/アカウントディザスターリカバリー :N2WSは、最も包括的なクロスアカウント/リージョンを提供し、ボタンをクリックするだけで全環境をリカバリーすることができます。AWS Backupのバージョンは非常に基本的で、実行が複雑です。

 

スケジュール :AWS Backupでは、バックアップのスケジュールを1/12/24時間ごとに設定するよう制限されています。N2WSではそのような制限はなく、バックアップは1分ごとにスケジュールすることができます。

 

ファイルレベルリカバリー  : AWS Backupは、Amazon EFSのファイルレベルリカバリーのみをサポートしています。N2WSは、EFS、EC2、S3に対してファイルレベルのリカバリを実行できます(暗号化されたボリュームに対しても)。

 

Start/Stop Servers (Resource Source Control) : N2WSのこの機能は、EC2インスタンスのアクティブ化と非アクティブ化のスケジュールを設定することが可能である。例えば、非生産用のインスタンスを月曜日から金曜日の午前9時に開始し、午後5時に停止するようにスケジュールすることができる。これにより、お客様はAWSのコストを数千ドル削減することができます。N2WSのお客様であるGett様は、この機能により年間60,000ドルのコスト削減を実現しています。

 

RDS MySQL & PostgresSQL (S3) : N2WSは、これらのRDSカテゴリをS3に保存することができ、より安価でコールド・ストレージを使用することにより、ストレージコストを大幅に節約することができます。AWS Backupにはこの機能はありません。

 

自動化 :  N2WSによる自動化のおかげで、お客様は他の重要なトピックにエネルギーを集中させることができ、N2WSにバックアップの世話をさせることができるようになります。つまり、一度必要なポリシーとスケジュールを作成すれば、あとはツールがバックグラウンドでバックアップを行い、何か問題が発生したり、注意が必要な場合はアラートが表示されるのです。N2WSは、保存ポリシーに応じて、S3、Deep Archive、Glacierなどのコールドストレージへの保存を自動化することも可能です。これにより、AWSのコストを大幅に削減することができます。

 

カスタマーサポート : N2WSは、24時間365日のプレミアムサポートを提供し、必要なときにはサポートします。AWSのサポートは別途費用がかかります。

 

レポートログとモニタリング : AWSでは、レポートログとモニタリングは別料金で、設定が必要です。N2WSでは、バックアップ、リストア、管理、監査の全活動を監視し、追加コストなしですぐに使えるレポートを提供します。

バックアップ対象(VM01, VM02)からVM02を除外した場合、VM02のリストアポイントは指定した世代数を保持しますか?

いいえ、保持しません。
例えば、リストアポイントを4世代とした場合、バックアップを取得するたびに世代数が減っていきます。
11/1, 11/2, 11/3, 11/4とバックアップを取得し、11/5にVM02が除外されたバックアップを取得した場合、VM02のリストアポイントは11/2, 11/3, 11/4となり、11/1のリストアポイントは消されます。
最終的には11/4のリストアポイントがフルバックアップファイル内に残り続けます。
これを消すにはフルバックアップの再作成や再構成(Compact full)が必要です。

物理サーバのバックアップも行えますか。

はい、Veeam Backup & Replication Universalライセンスをご利用いただくことで、
仮想サーバに限らず、物理サーバも併せてバックアップ可能です。
Universalライセンスにつきましては、こちらをご参照ください。

Excelスプレッドシートから直接データの抽出できますか?

はい、Espressシリーズはデータ・レジストリー内でExcelデータソース機能を使用してExcelスプレッドシートから直接データの抽出が可能です。

 

 

詳しくはこちらのブログを参照ください。

Android端末に対応していますか?

はい、モバイル端末としてAndroid, iPad, iPhoneに対応しております。

Microsoft AzureやAWSなど自社利用のクラウド環境で稼働させることは出来ますか?

はい、可能です。

評価版から製品版データ移行することが出来ますか

はい、可能です。評価版システムに製品キー・ファイルを製品にディプロイすることで可能になります。

他システムとの連携は可能ですか?

外部システムとの連携用の備え付けのAPIを利用して外部システムとの連携が可能です。詳細はお問い合わせください。

操作講習会などはありますか?

定期的な講習はありませんが、導入検討中のお客様および購入済みのお客様向け無償オンライン講習会の準備は可能です。詳細はお問い合わせください。

導入前に評価することは可能ですか?

はい45日間無料で全機能ご利用可能です。評価は、クラウドでもオンプレミスでも選択いただけます。

詳細はお問合せページ

また無料でサポートを行っています。

システムの提供形態は何がありますか?

クラウド、オンプレミスのどちらでもご利用形態に合わせて提供が可能です。。詳細はお問い合わせください。

7. Database Performance Analyzer (DPA)でデータベースのチューニングはどのように行われるのですか?

Database Performance Analyzer (DPA)は、ユーザーがデータベースパフォーマンスの問題を監視、発見、解決できるように構築された、俊敏でスケーラブルなデータベースチューニングツールです。

 

DPAは、データベースアクティビティ、待機時間、SQLステートメント、アプリケーションリクエスト、およびその他のディメンションを相関させ、データベース速度低下の原因を正確に突き止めることができるように設計されています。 DPAでは、IBM DB2、SQL Server、SAP Adaptive Server Enterprise(SAP ASE)などの主要な商用データベースについて、SQLステートメントの迅速な分析、パフォーマンス問題の根本原因の特定、専門家のチューニングアドバイスを受けることも可能です。

6. データベースチューニングツールはどのように機能するのですか?

データベースチューニングツールは、通常データベースチューニングに時間がかかる手動プロセスの多くを自動化することによって、チューニングプロセスを容易にするように設計されています。

 

また、データベース・チューニング・ソフトウェアは、問題のある箇所を正確に把握できるため、クエリーやアプリケーションの中を探し回る必要がなく、効果的なトラブルシューティングの手段にもなります。見えない問題を解決することはできません。これらのツールは、データベースがどのように動作しているかを概観することができます

5. なぜデータベースのチューニングが重要なのか?

 

データベースクエリーの数ミリ秒の遅れは、あっという間に大きなボトルネックとなり、修正するのに長い時間がかかることがあります。データベースのチューニングが重要なのは、クエリの応答時間を数秒単位で短縮できるため、必要な情報を必要な場所にすばやく届けることができるからです。定期的なチューニングは、データベースパフォーマンスのベストプラクティスの重要な部分であり、アプリケーションのパフォーマンスを加速させる手っ取り早い方法となります。

4. データベースのチューニングはどのように行われるのでしょうか。

データベースのパフォーマンスチューニングのベストプラクティスに関して、ここでは簡単なチュートリアルを紹介します。

 

1)過去のデータを使って「正常」であることを確認し、データベースのベースラインに関する情報を収集します。ベースラインの指標を収集することで、データベースに何か異常があるかどうかを簡単に(そしてはるかに速く)確認することができます。

 

2)実行プランに目を通す。MySQL では、データベース管理者がクエリおよびデータベースのパフォーマンスを調査するためのさまざまな方法を提供しています。実行プランに目を通し、可能な限り効率的であることを確認します。

 

3)すべてのテーブル、インデックス、クエリに非効率性がないかを確認します。待ち時間の増加やインデックスのカラムアライメントを確認します。

 

4)ボトルネックを特定し、解消する。問題のあるSQLクエリとその原因を特定し、ボトルネックを解決する。

 

5)効果的な監視を実施する。非効率的なクエリは、データベースのパフォーマンス問題の主な原因であるため、データベースのチューニングの大部分はクエリパフォーマンスの監視に費やされます。たとえば、SolarWinds Database Performance Analyzerは待機ベースの分析機能を備えています。これは、時間関連の問題がデータベースパフォーマンスチューニングの最も顕著な問題点の1つであるためです。この方法は、データベースパフォーマンスチューニングの問題をより正確に切り分け、特定し、調査するのに役立ちます。

3. データベースのパフォーマンスを向上させるにはどうすればよいですか?

ここでは、データベース全体のパフォーマンスを向上させるために役立つヒントをいくつか紹介します。

 

●インデックスが論理的なデータ構造を実装していることを確認し、データ検索プロセスをより効率的にする。
●コンピューティングシステムのメモリーの予備を再割り当てする。十分なメモリがない場合、データベースはしばしば最も大きな打撃を受けます。
●MySQLやOracleの最新版を使用していますか? データベースを最新に保つだけで、データベースのパフォーマンスが向上することがあります。
●ループのコーディングや相関性のあるSQLサブクエリのような一般的なSQLインデックスの落とし穴を避ける。
●データをデフラグすることで、データベースのスピードアップにつながるかもしれません。十分なディスク容量があることを確認する。
●効果的なデータベースチューニングとパフォーマンス監視は、洞察とピンポイントでのパフォーマンス最適化の推奨事項を提供するのに役立ちます。

2.SQLパフォーマンスチューニングとは何ですか?

SQLパフォーマンス・チューニングは、データベース・パフォーマンス・チューニングと似ていますが、より狭い範囲に限定されます。SQLパフォーマンス・チューニングは、リレーショナル・データベースが可能な限り効率的に動作するように設計されたベストプラクティスや手順のことを指します。これには主に、SQLクエリーとインデックスのチューニング、管理、および最適化が含まれます。

 

定期的な SQL パフォーマンス・チューニングは、SQL パフォーマンス問題の一般的な原因である非効率的なインデックスと SQL クエリに取り組む費用対効果の高い方法であり、リソースを再割り当てしてシステムを自助努力で使用することによって実現できます

1.データベース・パフォーマンスチューニングとは?

データベース・パフォーマンスチューニングは、データベース管理者がデータベースを可能な限り効率的に実行する方法を指す広義用語です。DBMSチューニングは、通常、MySQLやOracleなどの一般的なデータベース管理システムのクエリをチューニングすることを指します。

 

データベースのチューニングは、全体的なパフォーマンスを向上させるために、データベースシステムを上から下まで、ソフトウェアからハードウェアまで、再最適化することを支援します。このチューニングには、最適な使用方法に応じたオペレーティングシステムの再構成、クラスタの展開、システム機能とエンドユーザー体験をサポートする最適なデータベース性能への取り組みが含まれます。

[初めに]このカテゴリーについて[Database Performance Analyzer (旧Ignite) について]

データベースのパフォーマンスモニター・分析ツール「Database Performance Analyzer(DPA)」についてよくある質問の一覧です。

 

本サイトはこちらです。

複数のデータベースタイプに対応した堅牢な異常検知ツールを利用する


環境の大規模化・複雑化に伴い、データベース管理者は、様々な種類のデータベースを監視できる異常検知ツールを必要としています。Database Performance Analyzer(DPA)は、WindowsおよびLinuxサーバー上の仮想化、物理、クラウドベースのデータベースインスタンス、Azure、またはAWSサブスクリプションとして、1回のインストールで使用できる異常ベースのデータベース監視ツールを提供します。DPAの異常検知ツールは、Oracle、MySQL、Azure SQL Database、Microsoft SQL Serverなどをサポートするよう構築されています。また、DPAはVMオプションでVMware ESXiの可視化機能を統合しています。

SQLデータベースの異常検知に利用可能な最新データを活用する


データベースの異常検知ツールは、そこに入力されるデータによってのみ、その性能が発揮されます。Database Performance Analyzer(DPA)は、24時間365日、異常ベースの監視を行い、機械学習アルゴリズムにより最新の洞察を提供します。30日以上監視が停止した場合、DPAのアルゴリズムは古いデータに基づいて予測を行うことはありません。代わりに、DPAは新しいデータから学習を開始し、3日後に最新のデータに基づいて再び予測を開始します。この機能により、異常検知の取り組みが最新の関連データのみによって裏付けられていることを確認することができます。

重大な動作の変化を警告するように設計された異常検出ツールを使用して、効果的なトラブルシューティングを行うことができます。

データベースの異常を検出することも重要ですが、24時間365日ダッシュボードを見続ける人はいないため、Database Performance Analyzer(DPA)は動作の変化を検出した際にアラートを送信することが可能です。感度を快適なレベルにカスタマイズしてノイズを減らし、DPAに監視を任せてください。

 

 

DPAはデータベースを常時監視し、動作の変化が検出されるとアラートを送信します。この異常検知ツールは、ワークロードのシフト、メンテナンスジョブの営業時間内実行、その他調査したい予期せぬ変化が発生したときに知らせることができます。

スパイクを超えた、異常ベースのデータベース監視の深化化

データベース管理者は、データベースのパフォーマンスにおけるスパイクに注目しがちです。これは問題のある動作を特定する良い方法ですが、動作のスパイクを分析することだけがパフォーマンスの変化を示す指標ではありません。実際、ほとんどの実稼働データベースでは、パフォーマンスの変動は正常であり、予期されるべきものです。データベース管理者は、予想される変動を考慮し、予期しないものを呼び出す方法を必要としています。

Database Performance Analyzer(DPA)のスマートなSQLデータベース異常検知は、スパイクを越えて、予想される変動を考慮し、何か予期せぬことが起きたときに指摘することができます。この異常検知ツールは、そのような事象をハイライト表示し、標準から逸脱した事態を知るための複数の方法を提供します。

異常検知ツールでデータベースの待ち時間動作パターンを自動学習

狭い知識に頼っていると、新しい人がそれを習得するのは難しいです。また、大規模な環境では、深く広く理解することができない場合もあります。狭い知識の必要性を排除し、Database Performance Analyzer(DPA)の機械学習アルゴリズムに正常な動作パターンの「理解」の自動化を任せましょう。重要なリソースが異動したときに知識が流出しないように、知識を自動化して保持し、チーム全員の利益につなげます。

DPAの機械学習アルゴリズムは、時間の経過とともに賢くなるように設計されており、より多くのデータを収集することで予測精度を向上させます。