Azure PostgreSQL – Flexible Server: デフォルト設定が静かに数千ドルを無駄にする仕組みと、その対処法
By Mirko Peters · · Updated
Azure PostgreSQL のデフォルト設定はクラウドの請求額を押し上げることがあります。隠れたコストの見つけ方、設定の最適化、Flexible Server でのコスト削減のポイントを解説します。
Automatically translated with AI from the original post. Read the English original
Azure PostgreSQL の請求額は必要なリソースに見合っていると思われているかもしれません。しかし、デフォルト設定によってコストが上がることがあります。マネージドサービスはデータベースのパッチ適用を担いますが、コストを下げてくれるわけではありません。設定を確認しなければ、使っていないものに対して料金を払うことになります。コストを削減するには、測定し、変更し、不要なものを整理する必要があります。無駄なコストが発生する前に、今すぐ環境を確認しましょう。
重要なポイント
Azure PostgreSQL のデフォルト設定は、支出を増やす原因になることがあります。利用状況に合っているか、定期的に設定を確認しましょう。
サーバーが大きすぎたり、不要な高可用性を有効にしていたりすると、コストが上がります。実際の使用状況を確認し、リソースに適したサイズを選びましょう。
自動拡張の設定により、ストレージは増え続けることがあります。毎月ストレージを確認し、自動拡張の上限を設定して、使っていない領域に料金を払わないようにしましょう。
レプリカには明確な役割が必要です。業務に役立っていないレプリカは削除し、余分な料金を避けましょう。
定期的なチェックと自動化を活用して、コストの問題を早期に見つけましょう。使用量が多い場合にアラートを設定し、毎月の確認を計画して、コストを管理下に置きましょう。
Azure PostgreSQL の請求額がワークロードではなくデフォルト設定を反映している理由
マネージド = パッチ適用済み、ではあるが最適化済みではない
マネージドデータベースサービスがすべてを自動で処理してくれると思われているかもしれません。Azure PostgreSQL は更新プログラムとセキュリティパッチを担当します。バグの修正やシステムの保護を気にする必要はありません。しかし、支払う金額の管理はあなた自身が行う必要があります。サービスが利用状況を監視したり、必要に合わせてリソースを調整したりすることはありません。コストを削減したい場合は、設定を確認し、必要な変更を加えてください。
ヒント: マネージドとは、自動更新とサポートを受けられることを意味しますが、コストは自分で管理する必要があります。
多くのユーザーは、マネージドであれば最適化もされていると考えがちです。しかし、これは正しくありません。Azure PostgreSQL はデータベースの稼働を維持しますが、サーバーやストレージのサイズを適切に調整してはくれません。選択したリソースに対して、使い切らなくても料金が発生します。大きなサーバーや追加のストレージを選んだ場合、その分の料金が毎時間発生します。
「設定して放置」の罠
Azure PostgreSQL をセットアップする際には、多くのオプションが表示されます。安全そうに見えるため、デフォルトを選んでしまうかもしれません。問題を避けたいあまり、必要以上のリソースを選ぶこともあるでしょう。セットアップ後はこれらの選択を忘れがちです。データベースは動き続けますが、請求額は増えていきます。
陥りやすい罠は次のとおりです。
ワークロードに必要な規模より大きなサーバーを選んでいる。
自動拡張ストレージをオンにしたまま、一度も縮小していない。
重要ではないデータベースにも、すべて高可用性を有効にしている。
テスト用にレプリカを追加したが、削除していない。
罠 | 結果 |
|---|---|
過剰なコンピューティング | 毎月の高額な費用 |
余分なストレージ | 未使用の容量に対する料金 |
不要な高可用性 | 料金が二重に発生 |
未使用のレプリカ | 請求額の増加 |
Azure PostgreSQL はこれらの設定を自動的に変更してはくれません。選択内容を見直し、実際のワークロードに合わせて調整する必要があります。見直さなければ、使っていないリソースに対して料金を払い続けることになります。
Azure PostgreSQL の主要なコスト漏れ 5 つ
毎月の請求額が高いと感じることがあるかもしれません。その原因は、多くの場合、主要な 5 つのコスト漏れに潜んでいます。どこを確認すべきかが分かれば、修正してコストを削減できます。
コンピューティングの基準と、バースト可能な SKU の罠
コンピューティングには毎時間料金が発生します。Azure PostgreSQL は専用サーバー上で動作します。大きなサーバーを選ぶと、データベースがアイドル状態でも料金を支払うことになります。安価に見えるため、バースト可能な SKU を選ぶユーザーも多くいます。ただし、これらのサーバーは CPU クレジットを使用します。ワークロードが一日中稼働している場合、クレジットはすぐに消費されてしまいます。クレジットがなくなると、データベースの速度が低下します。サーバーの料金は引き続き発生しますが、本来の性能は得られません。
注: CPU 使用率がほとんどの時間低い場合は、サーバーのサイズを縮小できます。データベースが営業時間内にしか使われていない場合は、停止時間をスケジュールして料金を節約できます。
罠 | 起きること |
|---|---|
サーバーが大きすぎる | 使っていない性能分の料金を支払う |
バースト可能な SKU | スロットリングされるうえに、料金は発生する |
ストレージの肥大化とプレミアム SSD の過剰購入
ストレージは時間とともに増えていきます。Azure PostgreSQL ではディスクに自動拡張を使用します。データが増えるとディスクサイズも大きくなります。問題は、データを削除してもディスクが縮小しないことです。ディスクが一度でも到達した最大サイズに対して料金が発生します。プレミアム SSD v2 は高速性をうたっているため、選ぶユーザーも多くいます。この階層では容量、IOPS、スループットに対して課金されます。これらの機能をすべて使わなければ、お金を無駄にすることになります。
ヒント: ストレージの使用状況を毎月確認してください。自動拡張には上限を設定しましょう。Premium SSD v2 は、高い IOPS やスループットが本当に必要な場合にのみ使用してください。
使っていないディスク容量に対しても料金を支払うことになります。
使っていない高性能ストレージに対しても料金を支払うことになります。
既定の保険としての高可用性
高可用性 (HA) は安全に思えます。ダウンタイムを避けたいので、すべてのデータベースで有効にしがちです。しかし HA を有効にするとコンピューティングとストレージのコストが 2 倍になります。トラフィックを処理しないスタンバイサーバーに対しても料金を支払うことになります。データベースにゼロダウンタイムが必要ない場合、HA は無駄なコストになります。
注意: HA は基幹システムにのみ使用してください。社内用や検証用のデータベースでは、代わりにバックアップとレプリカを活用しましょう。
HA を有効にする対象 | 結果 |
|---|---|
すべてのデータベース | 請求額が 2 倍に |
重要度の低いデータベース | 不要な保険 |
元が取れないレプリカ
レプリカはレポートや災害復旧に役立ちます。ただし、各レプリカは独立したフルサーバーであり、それぞれに料金が発生します。テストや「念のため」という理由でレプリカを追加すると、余計な費用がかかります。アプリがレプリカを読み取りに使っていなければ、そのコストは無駄になります。レプリカを何段にも連鎖させると、コストは倍々に膨らみます。
ヒント: 各レプリカが確実に目的を果たしていることを確認してください。BI ツールやアプリの読み取りトラフィックがレプリカを使うように設定しましょう。
レプリカは、プライマリサーバーの負荷を肩代わりするものであるべきです。
実際のワークロードに役立っていないレプリカは削除してください。
バックアップとメンテナンス時間帯
バックアップはデータを守ります。Azure PostgreSQL では、スナップショットとログを数日間にわたり保持します。保持期間を既定のままにしておくと、ストレージコストは増え続けます。メンテナンス時間帯は、更新がいつ行われるかを制御します。カスタムの時間帯を設定しないと、業務時間中に更新が行われる可能性があります。その結果、ダウンタイムや予期しないコストが発生することがあります。
注意: バックアップの保持期間は必要に応じて設定してください。復元テストは定期的に実施しましょう。メンテナンス時間帯は、利用が混み合う時間を避けて設定してください。
既定の設定 | 起こりうる問題 |
|---|---|
バックアップの保持期間が長い | ストレージコストの増加 |
既定のメンテナンス | 業務時間中のダウンタイム |
これら 5 つの領域を確認すれば、気づかないうちに発生しているコストの漏れを防げます。Azure PostgreSQL では制御手段が用意されていますが、実際に使いこなす必要があります。設定を監査し、リソースのサイズを適正化し、不要なものは整理しましょう。
Azure PostgreSQL のリソース適正化プレイブック
実際のワークロードメトリックの確認
まずは計測から始める必要があります。実際のワークロードメトリックを見れば、データベースが実際にどのように動作しているかが分かります。要求レート、応答時間、依存関係の呼び出しといった数値を確認すると、サーバーがどの程度混み合っているか、いつ遅くなるかが分かります。これらの数値は、必要なリソースを判断する材料になります。
メトリック | 説明 |
|---|---|
サーバーの要求レート | サーバーが処理した要求の数を測定します。 |
サーバーの応答時間 | 要求に応答するまでにかかった時間を示します。 |
依存関係の呼び出し | 依存先に対して行われた呼び出しの数を数えます。 |
これらのメトリックは毎週確認してください。要求レートが低く応答時間が速い場合、サーバーが大きすぎる可能性があります。逆に数値が高い場合は、リソースの追加が必要かもしれません。
コンピューティングとストレージの調整
計測を行ったら、コンピューティングとストレージを調整できます。CPU 使用率が大半の時間 25% を下回っている場合は、より小さいサーバーを選びましょう。一日中稼働させる必要がないデータベースには、停止と開始のスケジュールを使うこともできます。ストレージについては、使用量を確認してください。ディスクがデータ量に比べてはるかに大きい場合は、縮小する必要があります。ディスクが大きくなりすぎないよう、自動拡張には上限を設定すべきです。Premium SSD v2 は、高速性や大量の入出力が必要な場合にのみ選択してください。
ヒント: コンピューティングとストレージを毎月監査してください。未使用のリソースを削除して、コストを抑えましょう。
HA、レプリカ、バックアップの最適化
高可用性は、常にオンラインであり続ける必要があるデータベースにのみ使用すべきです。それ以外のデータベースでは、バックアップと読み取りレプリカの方が適しています。各レプリカがレポートや災害復旧など、実際の業務に役立っていることを確認してください。目的を果たしていないレプリカは削除しましょう。バックアップの保持期間は既定値ではなく、必要に応じて設定してください。復元テストは数か月ごとに実施しましょう。利用が混み合う時間を避けてメンテナンス時間帯を設定してください。
高可用性は基幹システムにのみ使用してください。
BI ツールは読み取りレプリカに接続してください。
古いバックアップと未使用のレプリカを整理してください。
注意: 定期的な整理とスケジュールの工夫によって、コストを低く抑え、データベースを健全に保てます。
継続的なコスト管理のベストプラクティス
定期的な監査と自動化
Azure PostgreSQL は頻繁に確認してください。監査によって無駄を早期に発見できます。Azure のツールを使って、サーバーのサイズやストレージを確認しましょう。バックアップ設定も確認してください。毎月確認する計画を立てましょう。使っていないものが見つかったら、すぐに削除してください。
自動化は、この作業を楽にするのに役立ちます。スクリプトを使って、一時的なサーバーにタグを付けることができます。長く残っている場合はアラートを設定します。ストレージとバックアップのルールは Azure Policy で設定できます。毎日稼働させる必要のないサーバーは、停止と起動の時間を自動化します。これによりコストを削減でき、手間もほとんどかかりません。
ヒント: 自動化は問題を早期に見つけるのに役立ちます。CPU 使用率の上昇やストレージ容量の増加に対してアラートを設定しましょう。コストが膨らむ前に対処できます。
月次監査用のシンプルなチェックリストは次のとおりです。
サーバーの CPU とメモリの使用状況を確認します。
ストレージのサイズと増加量を確認します。
バックアップの保持期間が要件に合っているか確認します。
使用していないレプリカを削除し、リストアをテストします。
一時リソースにタグを付け、不要なものを削除します。
監査タスク | 実施する対応 |
|---|---|
CPU/メモリの確認 | 使用率が低い場合はサイズを縮小する |
ストレージの監査 | ディスクを縮小するか、上限を設定する |
バックアップの確認 | 保持期間を調整する |
レプリカの確認 | 未使用のレプリカを削除する |
一時リソース | 削除するか、TTL 用のタグを付ける |
コスト意識をチームに定着させるためのトレーニング
チームにコスト管理の方法を教えましょう。コスト意識は、何をすべきかを知ることから始まります。既定の設定がどのように無駄なコストを生むかをチームに示してください。自社の環境から実例を挙げてください。適切なサイズ設定(リサイジング)が重要な理由も説明しましょう。
新しいサーバーやレプリカを作成する前に、よく検討するようチームに求めてください。コスト管理を新メンバーのトレーニングに組み込みましょう。会議でヒントを共有します。「CPU 使用率が低いままならサイズを縮小する」や「30 日経過した未使用のレプリカは削除する」といったわかりやすいルールを活用してください。
注意: コスト管理は全員で取り組むべきものです。チームが影響を理解すると、より賢い判断ができるようになります。
短いトレーニングを実施したり、ガイドを共有したりできます。監査で得た数値を活用しましょう。無駄を見つけて取り除いた人がいれば、それを称えてください。こうした取り組みにより、チーム全体でコストを低く抑える協力体制が生まれます。
既定の設定をそのまま使うのではなく、見直せば Azure PostgreSQL のコストを下げられます。データベースの負荷状況を確認し、適切なリソースを選び、構成を定期的に見直すことで、コストを節約できます。プレイブックとコストの無駄を見つける手順に従って、ご自身の監査を行ってください。
今すぐ行動しましょう: 現在の環境を確認し、設定を変更して、無駄が大きくなる前に止めてください。次の請求書は、既定値ではなく、実際に使っている量を示してくれるはずです。
よくある質問
Azure PostgreSQL Flexible Server で最も大きなコストの無駄は何ですか?
多くの場合、コンピュート(計算リソース)に過剰な費用がかかっています。必要以上に大きなサーバーを選ぶと、お金が無駄になります。バースト可能な SKU も、想像以上にコストがかかることがあります。CPU の使用状況を頻繁に確認してください。必要な性能が出ていない場合は、サーバーを小さくしましょう。
高可用性(High Availability)が必要かどうかは、どうやって判断すればよいですか?
高可用性が必要なのは重要なデータベースだけです。ビジネスとして一定のダウンタイムを許容できるなら、無効にしても構いません。データベースを常に稼働させておく必要がない場合は、代わりにバックアップを活用してください。
データを削除した後、ストレージを縮小できますか?
Azure PostgreSQL は、ディスクを自動的に縮小することはありません。ストレージのサイズは自分で変更する必要があります。使っていない容量分の料金を払わないように、毎月ディスクのサイズを確認してください。
PostgreSQL の環境はどのくらいの頻度で監査すべきですか?
構成は毎月確認することをお勧めします。そうすることで、無駄が大きくなる前に見つけられます。Azure のツールを使って、サーバー、ストレージ、バックアップ、レプリカを確認してください。