Amazon Web Services ブログ
持続可能な AWS インフラストラクチャの最適化、第四部:データベース編
このブログは Otis Antoniou, Ibtehaj Ahmed, Darren Ko, Ceren Tahtasiz によって執筆された内容を翻訳したものです。原文はこちらを参照して下さい。
このシリーズの第一部:コンピュート編、第二部:ストレージ編、第三部:ネットワーキング編では、持続可能性のために AWS アーキテクチャのコンピュート、ストレージ、ネットワーキングレイヤーを最適化するための戦略を紹介しました。
この投稿、第四部では、データベースレイヤーに焦点を当て、データベースの使用率、パフォーマンス、およびクエリを最適化するための推奨事項を提案します。これらの推奨事項は、AWS Well-Architected Framework のサステナビリティ(持続可能性)の柱の設計原則に基づいています。
AWS インフラストラクチャのデータベースレイヤーの最適化
アプリケーションがより多くのお客様にサービスを提供するにつれて、データベース内に格納されるデータの量は増加します。次のセクションの推奨事項を実装すると、データベースリソースをより効率的に使用し、コストを節約できます。
マネージドデータベースを使用する
通常、お客様はピーク時のトラフィックを吸収するために必要なキャパシティを過大評価し、未使用のインフラストラクチャにリソースとお金を浪費します。AWS フルマネージド型データベースサービスは継続的なモニタリングを提供し、必要に応じてデータベースキャパシティを増減できます。さらに、ほとんどの AWS マネージドデータベースは、使用されるインスタンスサイズとストレージに基づく従量課金制モデルを使用します。
マネージドサービスは、デプロイされたハードウェアの高い平均使用率と持続可能性の最適化を維持するために、責任を AWS に移します。Amazon Relational Database Service (Amazon RDS) は、Amazon Elastic Compute Cloud (Amazon EC2) で独自のデータベースを維持する場合と比較して、個人の負担を減らします。マネージドデータベースでは、AWS はクラスターを継続的にモニタリングし、自己修復ストレージと自動スケーリングを使用してワークロードを実行し続けます。
AWS は 15 以上の目的別エンジンを提供し、多様なデータモデルをサポートしています。たとえば、モノのインターネット (IoT) アプリケーションが大量の時系列データを処理する必要がある場合、Amazon Timestream はこの正確なユースケースに合わせて設計および最適化されます。
適切なサイズ、無駄の削減、適切なハードウェアの選択
使用率の低いインスタンスと適切なサイズ設定の機会を特定するために実行できるメトリクス、しきい値、アクションを確認するには、「Optimizing costs in Amazon RDS」を参照してください。次の表に、未使用のリソースを見つけるための追加のツールとメトリックを示します。
サービス | メトリック | 参照 |
---|---|---|
Amazon RDS | DatabaseConnections | Amazon CloudWatch |
Amazon RDS | Idle DB Instances | AWS Trusted Advisor |
Amazon DynamoDB | AccountProvisionedReadCapacityUtilization, AccountProvisionedWriteCapacityUtilization, ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits | CloudWatch |
Amazon Redshift | Underutilized Amazon Redshift Clusters | AWS Trusted Advisor |
Amazon DocumentDB | DatabaseConnections, CPUUtilization, FreeableMemory | CloudWatch |
Amazon Neptune | CPUUtilization, VolumeWriteIOPs, MainRequestQueuePendingRequests | CloudWatch |
Amazon Keyspaces | ProvisionedReadCapacityUnits, ProvisionedWriteCapacityUnits, ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits | CloudWatch |
これらのツールは、適切なサイズ設定の機会を特定するのに役立ちます。ただし、データベースの適切なサイズ設定はクエリ時間の SLA に影響を与える可能性があるため、変更する前にこの点を考慮してください。
また、以下の点の考慮もお勧めします:
- 既存の SLA がビジネスニーズを満たしているかどうか、または持続可能性のために環境を最適化するための許容可能なトレードオフとして緩和できるかどうかを評価します。
- 営業時間内にのみ実行する必要がある RDS インスタンスがある場合は、手動または Instance Scheduler を使用して営業時間外にシャットダウンすることを検討してください。
- データベースに AWS Graviton ベースのインスタンスなどの、より電力効率の高いプロセッサを使用することを検討してください。Graviton2 は、AWS の他のどのプロセッサよりもワットあたり 2〜3.5 倍優れた CPU パフォーマンスを提供します。
ワークロードのタイプに適した RDS インスタンスタイプを選択してください。たとえば、バーストパフォーマンスインスタンスは、キャパシティを過剰にプロビジョニングすることなく、ベースラインを超えるスパイクに対処できます。ストレージに関しては、Amazon RDS にはパフォーマンス特性と価格が異なる 3 つのストレージタイプが用意されているため、必要に応じてデータベースのストレージレイヤーを調整できます。
サーバーレスデータベースを使用する
トラフィックが断続的、予測不能、または急増する商用データベースは、十分に活用されていない可能性があります。効率を向上させ、余分なキャパシティを排除するには、負荷に応じてインフラストラクチャをスケーリングします。
AWS は、使用していないときにシャットダウンし、迅速に再起動し、アプリケーションのニーズに基づいてデータベースキャパシティを自動的にスケーリングするリレーショナルおよび非リレーショナルサーバーレスデータベースを提供します。これにより、キャパシティ管理が自動的に最適化されるため、環境への影響が軽減されます。ワークロードに最適な目的別データベースを選択することで、次の表に示すように、サーバーレスデータベースサービスのスケーラビリティとフルマネージドエクスペリエンスのメリットを享受できます。
サーバーレスリレーショナルデータベース | サーバーレス非リレーショナルデータベース |
---|---|
Amazon Aurora Serverless はオンデマンドの自動スケーリング構成を実現します | Amazon DynamoDB(オンデマンドモード)はフルマネージドで、サーバーレスなキーバリュー NoSQL データベースです |
Amazon Redshift Serverless は、データウェアハウスを稼働させ、キャパシティをスケーリングします;データウェアハウスインフラストラクチャのセットアップと管理は必要ありません | Amazon Timestream は IoT および運用アプリケーション向けの時系列データベースサービスです |
Amazon Keyspaces はスケーラブルで可用性が高く、マネージドの Apache Cassandra 互換データベースサービスです | |
Amazon Quantum Ledger Database は、透過的かつイミュータブルで、暗号的に検証可能な一元化されたトランザクションログを備えているフルマネージド型の台帳データベースです |
データベースの自動バックアップを使用し、冗長なデータを削除する
Amazon RDS の手動バックアップは、自動バックアップとは異なり、データベースの手動スナップショットを作成し、デフォルトでは保持期間が設定されていません。つまり、手動スナップショットを削除しない限り、自動的には削除されません。不要な手動スナップショットを削除すると、使用するリソースが少なくなり、コストが削減されます。RDS の手動スナップショットが必要な場合は、AWS Backup で「有効期限」を設定できます。MariaDB、MySQL、および PostgreSQL データの長期的なスナップショットを保持するには、スナップショットデータを Amazon Simple Storage Service (Amazon S3) にエクスポートすることをお勧めします。特定のテーブルまたはデータベースをエクスポートすることもできます。これにより、データをデータベース内に保持するのではなく、“より冷たい”長期アーカイブストレージに移動できます。
実行時間の長いクエリを最適化する
アプリケーションの全体的なパフォーマンスに影響を与える可能性があるため、リソースを大量に消費するクエリを特定して最適化します。Performance Insights ダッシュボードでは、特にトップ SQL、待機、ホストを表示する上位ディメンションテーブルを使用すると、SQL クエリを表示およびダウンロードして、さらに診断および調査できます。
「Performance Insights で Amazon RDS for MySQL をチューニングする」と、このナレッジセンターの記事は、Amazon RDS for MySQL のクエリの最適化とチューニングに役立ちます。ブログ記事「ネイティブツールと外部ツールに基づいた Amazon RDS PostgreSQL のクエリの最適化とチューニング」および「Improve query performance with parallel queries in Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL-Compatible Edition」では、ネイティブツールと外部ツールを使用して Amazon RDS PostgreSQL クエリを最適化とチューニングする方法、および並列クエリ機能を使用してクエリパフォーマンスを向上させる方法について概説しています。
データベースのパフォーマンスを向上させる
異常なパフォーマンスの問題を監視、特定、修復することで、データベースのパフォーマンスを向上させることができます。AWS は、データベース管理者 (DBA) に依存する代わりに、次の表に示すように、データベーステレメトリを継続的にモニタリングおよび分析するためのネイティブツールを提供します。
サービス | CloudWatch メトリクス | 参照 |
---|---|---|
Amazon RDS | CPUUtilization, FreeStorageSpace | CloudWatch |
Amazon Redshift | CPUUtilization, PercentageDiskSpaceUsed | CloudWatch |
Amazon Aurora | CPUUtilization, FreeLocalStorage | CloudWatch |
Amazon DynamoDB | AccountProvisionedReadCapacityUtilization, AccountProvisionedWriteCapacityUtilization | CloudWatch |
Amazon ElastiCache | CPUUtilization | CloudWatch |
CloudWatch は、Amazon RDS のインスタンスレベルおよびアカウントレベルの使用状況メトリクスを表示します。CloudWatch アラームを作成して、指定したメトリクス値のしきい値に基づいて、またはメトリクスの異常な動作が検出されたときにアクティブ化して通知します。 DB インスタンスが実行されているオペレーティングシステムの拡張モニタリングのリアルタイムのメトリクスを有効にします。
Amazon RDS Performance Insights は、各 RDS DB インスタンスからデータベース負荷などのパフォーマンスメトリクスを収集します。このデータにより、データベースのアクティビティを秒単位で詳細に把握できます。ダウンタイム、再起動、またはフェールオーバーを発生させることなく、パフォーマンスインサイトを有効にできます。
Amazon DevOps Guru for RDS は、Performance Insights、拡張モニタリング、CloudWatch のデータを使用して、運用上の問題を特定します。機械学習を使用して、リソースの過剰使用や特定の SQL クエリの誤動作など、データベース関連の問題を検出して通知します。
まとめ
この記事では、テクノロジの選択、設計原則、およびデータベースの最適化と効率向上のための推奨アクションについて説明しました。データが増大するにつれて、ユーザー負荷に合わせてデータベースキャパシティを拡張し、冗長データを削除し、データベースクエリを最適化し、データベースパフォーマンスを最適化することが重要です。図 2 は、データベースの最適化に使用できるツールの概要を示しています。
翻訳はネットアップ合同会社の藤原 善基氏、監修はソリューションアーキテクトの豊原 任が担当しました。