一般的なベストプラクティス

Identify KPI を特定する。求めるビジネス成果を基に、主要業績評価指標 (KPI) を特定し、KPI を評価して、ワークロードの成果を判断します。例えば、コアビジネスが e コマースの場合、求めるビジネス成果の 1 つとして、顧客が e ショップを 24 時間 365 日利用できることが考えられるでしょう。このビジネス成果を得るには、e-shop アプリケーションで使用されるバックエンド Amazon RDS データベースの可用性 KPI を定義して、ベースライン KPI を週あたり 99.99% に設定します。ベースライン値と照らし合わせて実際の可用性 KPI を評価すると、目標のデータベース可用性 99.99% を満たしているかどうかを判定して、24 時間 365 日サービスを提供するというビジネス成果を得られるでしょう。

ワークロードメトリクスを定義する。ワークロードメトリクスを定義して、Amazon RDS ワークロードの量と品質を測定します。メトリクスを評価して、ワークロードによって求める成果を得られているかどうかを判断し、ワークロードのヘルスを把握します。例えば、Amazon RDS DB インスタンスの可用性 KPI を評価するには、DB インスタンスのアップタイムやダウンタイムといったメトリクスを測定しなければなりません。その後、こうしたメトリクスを使用して、次のように可用性 KPI を計算できます。

availability = uptime / (uptime + downtime)

メトリクスとは、時系列のデータポイントセットであり、これには、分類と分析に役立つディメンションを含めることもできます。

ワークロードメトリクスを収集して分析する。Amazon RDS では、設定に応じて、さまざまなメトリクスとログが生成されます。これらの中には、DB インスタンスイベント、カウンター、統計情報などを表すものもあります (例: db.Cache.innoDB_buffer_pool_hits)。その他のメトリクスは、オペレーティングシステムから取得します。memory.Total がその例であり、これによって、ホスト Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのメモリ総量を測定できます。ここでは、モニタリングツールを使い、収集済みメトリクスを定期的かつプロアクティブに分析して傾向を特定し、適切な対応が必要かどうかを判断しなければなりません。

ワークロードメトリクスのベースラインを確立する。メトリクスのベースラインを確立して、期待値を定義するとともに、正常か異常かを判断するしきい値を特定します。例えば、通常のデータベースオペレーションの場合、ReadIOPS のベースラインは、最大 1,000 と定義できるでしょう。これにより、定義したベースラインを比較対象にし、過剰使用率を特定できます。新規メトリクスによって、読み取り IOPS が一貫して 2,000～3,000 の範囲にあることがわかれば、調査、介入、改善のための対応をトリガーしてもよい偏差を特定したことになります。

ワークロードの成果を得られない可能性がある場合にアラートを発行する。ビジネス成果実現が危ういと判断された場合に、アラートを発行します。これによって、顧客に影響が及ぶ前にプロアクティブに問題に対処したり、インシデントの影響をタイムリーに軽減したりできます。

ワークロードアクティビティの想定パターンを特定する。メトリクスベースライン基づいて、ワークロードアクティビティのパターンを確立することで、予期しない動作を特定し、必要に応じて適切なアクションを実行します。AWS のモニタリングツールを使用すると、統計アルゴリズムと機械学習アルゴリズムを適用してメトリクスを分析し、異常を検出できます。

ワークロードの異常が検出された場合にアラートを発行する。Amazon RDS ワークロードのオペレーションで異常が検出された場合にアラートを発行し、必要に応じて、適切なアクションを実行できるようにします。

KPI とメトリクスを確認し修正する。Amazon RDS データベースが定義済みの要件を満たしていることを確認するとともに、ビジネス目標の達成に寄与し得る改善点を特定します。また、測定したメトリクスと評価 KPI の有効性を検証し、必要に応じて修正します。例えば、最適な同時データベース接続数に KPI を設定した後に、接続の試行と失敗に関するメトリクスと、作成され実行中のユーザースレッドをモニタリングするとしましょう。場合によっては、KPI ベースラインで定義した数よりも多くのデータベース接続があるでしょう。そうした最終結果は、現在のメトリクス分析によって検出できますが、根本原因は特定できない可能性があります。その場合は、メトリクスを修正して、その他のモニタリング指標 (テーブルロックのカウンターなど) を追加しなければなりません。こうした新規メトリクスを使用すると、データベースの接続数増加の原因が予期しないテーブルロックにあるかどうかを判断しやすくなります。