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

Microsoft Office 365にバックアップが重要な7つの理由

1. 誤って削除してしまうこと: 1つ目の理由は、実はMicrosoft 365のデータ損失で最も多い懸念事項です。ユーザーを削除すると、その意図があったにせよなかったにせよ、その削除はネットワーク上に複製されます。バックアップを取れば、オンプレミスのExchangeでもOffice 365でも、そのユーザーを復元することができます。

 

2. 保持ポリシーのギャップと混乱:Microsoft 365 の保持ポリシーは、コンテンツの保持や削除を求める規制、法律、社内ポリシーに組織が準拠できるように設計されており、それらはバックアップではありません。しかし、バックアップの代わりに保持ポリシーに頼ったとしても、管理はおろか、維持することも困難です。バックアップは、より長く、よりアクセスしやすいリテンションを提供し、すべてを保護し、一箇所に保存して、簡単にリカバリできるようにします。

 

3. 内部セキュリティーの脅威:ビジネスに対する脅威を考えるとき、私たちは通常、外部の脅威から保護することを考えます。しかし、多くの企業は内部からの脅威を経験しており、それはあなたが考えている以上に頻繁に起こっています。ハイグレードなリカバリーソリューションがあれば、重要なデータが失われたり破壊されたりするリスクを軽減することができます。

 

4. 外部からのセキュリティ脅威: ランサムウェアはますます巧妙になり、犯罪者はユーザーの手を煩わせ、リンクをクリックさせ、身代金を要求するために組織全体のデータを暗号化する方法をより多く見つけてきています。バックアップを取れば、攻撃される前のインスタンスにデータを簡単に復元することができます。

 

5. 法的コンプライアンス要件:Microsoft 365 には eDiscovery 機能が組み込まれていますが、サードパーティのバックアップソリューションは、バックアップ内を簡単に検索し、あらゆる法規制のコンプライアンスニーズに対応したデータを迅速に復元できるように設計されています。

 

6. ハイブリッドメールの導入とMicrosoft 365への移行の管理:Microsoft 365 に移行する場合でも、オンプレミスの Exchange と Microsoft 365 のユーザーを混在させる場合でも、交換データは同じ方法で管理および保護する必要があり、移行元のロケーションは関係ありません。

 

7. Teams のデータ構造:Teams のバックエンドは、多くの人が思っているよりもはるかに複雑です。Teamsは自己完結型のアプリケーションではないため、Teamsで生成されたデータはExchange Online、SharePoint Online、OneDriveなど、他のアプリケーションに存在することになります。このように複雑なレイヤーが追加されているため、データを適切に保護することが最も重要です。

 

Veeam Backup for Microsoft Office 365 がそれらにお答えします。

クラウドストレージ管理のヒントとベストプラクティス

効率的で費用対効果の高いクラウドストレージの管理手法を確立するために、守るべき最高のヒントとコツを紹介します。

 

▸ ニーズを定義する。 プロバイダーやソリューションを選択する前に、正確なニーズを定義する必要があります。そうしないと、ベンダーをウィンドウショッピングするために多くの時間とお金を費やすことになります。

 

データを分類する。データをタイプ別に分類し、組織にとって重要なデータセットを定義することが推奨されます。

 

▸ プロバイダーを綿密周到に選択する。クラウド ストレージ市場は、現代のクラウドの世界で最も競争の激しい市場の一つです。つまり、少なくとも10社の素晴らしい有名ベンダーがあり、あなたに合うかもしれないということです。したがって、コスト削減のためだけに無名業者を選択する必要はありません。大手ベンダーよりも価格が高くなる可能性もあるし、サポートが悪かったり、スタートアップ企業にありがちなトラブルに見舞われる可能性もあります。

 

▸ クラウド上で安全性を確保する。多くのクラウドストレージベンダーが提供するIDアクセス管理ソリューションは、一見難しそうですが、洗練された便利なものです。データの漏洩や損失を避けるためには、時間をかけて堅牢なデータアクセスポリシーを作成することが最も重要です。主なアクセスパターンとして、最小権限ルールを採用してみてください。

 

▸ コストをコントロールする。 ベンダーを選択したら、そのソリューション・エンジニアリング・チームと連絡を取り、シナリオに応じた最適なアプローチを検討します。これにより、初期コストを削減し、継続的なコストを監視および管理するためのドキュメントを作成することができます。さらに、ベンダーによっては、すぐに必要でないデータを、より安価なデータストレージの階層に保存することを認めてくれるところもあります。

 

▸ 構造を作成する。 クラウドへのデータのアップロードや、完全なデジタル文書のワークフローの作成を始める前に、図面を引いて構成図を作りましょう。その構成により、クラウドデータストレージが1年後にゴミサイトとならないようにすることができます。

DPAリソースメトリクスのベースラインについて

DPA の [Resources] タブでリソース メトリクスを表示しているとき、ベースラインを表示して、特定の期間の値を過去の基準値と比較することができます。ベースラインは、現在の値に対するコンテキストを提供します。ベースラインを大幅に上回ったり下回ったりするメトリック値は、チューニングや再設定が必要な領域を示している可能性があります。

 

ベースラインを計算する前に、少なくとも1日間モニタリングが有効でなければなりません。ベースラインは、モニタリングの日数が増えるほど、より代表的なものになります。

 

(注)ベースラインは、VMオプションで収集されたメトリクスでは利用できません。

 

ベースラインの表示/非表示

 

ベースラインは、選択した期間が1週間以下の場合に利用できます。デフォルトでは、ベースラインは表示されません。[Resource]タブの右上にある[Baselines]トグルスイッチをクリックすると、ベースラインの表示/非表示が切り替わります。

ベースラインを表示する場合(かつ期間が1週間以内の場合)、10%から90%の間の履歴値を網掛けで表示します。

 


ベースラインはどのように計算されるのですか?

ベースラインは、1時間ごとに計算されます。デフォルトでは、ベースラインは平日(月~金)のデータのみを使用して計算されます。各ベースラインは、平日すべての対応する時間のデータを使用して計算されるため、特定の時間の値はすべての日にわたって同じになります。(例えば、午後1時から2時までは月曜日から金曜日まで同じ値です)。

ベースラインは、チャートに表示されている最も古い時間以前の履歴データを使用して計算されます。例えば、5月10日から始まる1週間のチャートの場合、すべてのベースラインは5月9日以前のデータを使って計算されます。このため、1週間チャートは日毎にパターンが繰り返されます。

 

ベースライン計算に含まれる日数を変更する

ベースライン計算に含まれる日数を変更するには、詳細オプションの 「METRICS_BASELINE_TYPICAL_HOUR_CALCULATION」 を編集します。このオプションは、グローバルまたは特定の監視対象データベースインスタンスに対して設定することができます。

 

以下の値のいずれかを選択してください。

Weekday Only (M-F):平日(月~金)の対応する時間のデータを用いて、1時間ごとにベースラインを計算します。これはデフォルトです。
All Days of the Week:ベースラインは、すべての日の対応する時間のデータを使用して、各1時間の期間について計算されます。
Same Day of Week:各1時間の期間について、該当する日の該当する時間のデータを使用して計算されます。(例えば、月曜日の午後1-2時の値は、月曜日の対応する時間のデータを使用しており、したがって金曜日の午後1-2時の値とは異なります)。このオプションを選択すると、メトリックごとのベースラインの数が24から168に増えることに注意してください。

DPAは2種類のアドバイザーを提供

●Query advisors [クエリアドバイザ]は、待ち時間の原因となっている待ちの種類、ステートメントが他のセッションによってブロックされていないか、実行プランにフルテーブルスキャンなどのコストのかかるステップが含まれていないかなど、特定のクエリのパフォーマンスを改善するのに役立つ情報を提供します。

 

●Table tuning advisors [テーブルチューニングアドバイザー]は、あるテーブルに対して非効率的なクエリが大量に実行された場合に生成されます。これらのアドバイザーは、テーブル、実行された非効率的なクエリ、および既存のインデックスに関する集約された情報を提供します。

 

DPA ホームページの [チューニング] 列には、データベース インスタンスで警告またはクリティカル ステータスのアドバイザが利用可能な場合、警告またはクリティカル アイコンが表示されます。この列の緑のチェックマークは、アドバイザーが存在しないか、すべてのアドバイザーが情報提供であることを示します。

 

データベースインスタンスのすべてのアドバイザーを表示する

データベースインスタンスのすべてのアドバイザーを表示するには、次のいずれかの操作を行い、[Tuning Advisors] ページを開きます。

●DPA ホームページから、[Tuning] 列のアイコンをクリックします。
●データベース インスタンスの情報を表示するためにドリルインした場合は、インスタンスの詳細ページの右上隅にある[Tuning]タブをクリックします。

 

Tuningタブの赤または黄色のバーは、CriticalまたはWarningアドバイザーが利用可能であることを示します。

 

Tuning Advisors ページには、最新のクエリおよびテーブル・チューニング・アドバイザーが表示されます。ページの上部にあるドロップダウン・メニューを使用して、以前の日付に生成されたアドバイザーを表示します。

Kubernetesのデータ保護とDR

Kubernetes (KOO-bur-NEH-teez) または K8S は、コンテナ化されたワークロードとアプリケーションの管理を支援する強力なオープンソースプラットフォームで、コンテナオーケストレーションの標準となっています。また、コンテナで実行されるマイクロサービス・アーキテクチャの人気と普及に伴い、その使用範囲は拡大する一方です。

 

Kubernetesの仕組み
Kubernetesは、コンテナ化されたアプリケーションのライフサイクルを管理するための完全なフレームワークを提供します。DevOpsチームは、コンテナ展開の自動化、フェイルオーバー計画の準備、すべてのアプリケーションとグループが正しく動作していることの確認などを、規模に関係なく環境全体を完全に制御するために設定されたスケーラブルなアプローチで行うことができます。コンテナがオンプレミス、クラウド、またはハイブリッドデータセンターのいずれに保存されていても、Kubernetesによってデータとリソースを完全に管理することができます。

 

コンテナで異なる保護方法が必要
他のデータと同様に、コンテナもバックアップし、保護し、あらゆる災害に備えなければなりませんが、基礎となるさまざまな側面がこれらのプロセスを複雑にしています。まず、コンテナとパイプラインの問題があります。コンテナ・イメージをキャプチャするだけでなく、パイプライン、つまりイメージを生成するためのファクトリーを保護することがより理にかなっています。これには、設定スクリプトやドキュメントも含まれます。また、永続的なアプリケーションデータやボリュームを保護することも重要です。

 

データ保護とDRのためのKubernetesのオプションは限られています。環境がより複雑になり、より多くのコンテナが組み込まれるようになると、企業はコンテナ化されたアプリケーションと、さまざまなクラウドサービスにある残りのデータとの間でディザスタリカバリのアプローチを調整できるソリューションが必要になります。

 

クライムはKubernetesに対する次のデータ保護とDRソリューションを提供します。

 

 

Kasten K10 Platform

 

Zerto for Kubernetes

リスクマネジメントとは?

リスクとは、ポジティブであれネガティブであれ、組織の目標や目的に影響を与える可能性のあるあらゆる事象を指します。リスクマネジメントでは、リスクとは、これらの目標にマイナスの影響を与える可能性のある事象のことである。サイバーセキュリティの観点では、リスクとは、データ資産や業務の損傷や暴露につながる可能性があるあらゆる事象を指します。このようなリスクをうまく管理するためには、効果的なプロセスや戦略を開発する必要があります。

 

なぜリスクマネジメントに投資するのか?
サイバーセキュリティの例で説明すると、サイバーセキュリティのリスクはかつてないほど高まっています。例えば、ランサムウェアの攻撃はここ数年エスカレートしており、人質を取って悪質なコードを公開し、企業に破壊的な打撃を与えるケースが増えています。ランサムウェアの攻撃を受けると、企業の重要なデータは暗号化され、身代金を支払うまでアクセスできなくなります。

 

この攻撃から回復するためには、多額の評判と収益の損失が発生する可能性があります。リスクマネジメントは、サイバーセキュリティの脅威を認識し、事前に計画を立てます。サイバーセキュリティの脅威に対応するための十分な情報と効果的な戦略を準備しておくことで、組織の回復力が大幅に向上します。

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

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

 

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

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

 

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

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は異常を報告します。