2,769 測定値

AWS Lose Money を作成しました - 方法は次のとおりです。

に Paul-Élie5m2022/07/29

長すぎる; 読むには

これは、AWS での「コストの最適化」の基本について、ずっと共有したかった短い連載です。 DocumentDB サービスの I/O コストは、100 万回の I/O あたり 0.20 ～ 0.30 ドルです。インスタンスの価格はすぐに理解できます。インスタンスの料金を支払います。価格はそのリソース (CPU、RAM など) によって異なります。ストレージとバックアップストレージのコスト**: 上記と同じです。保存された GB あたりのコストを簡単に見積もることができます。

Company Mentioned

featured image - AWS Lose Money を作成しました - 方法は次のとおりです。

これは、AWS での「コストの最適化」の基本について、ずっと共有したかった短いシリーズです。

この旅をDocumentDBから始めましょう!

この投稿が気に入ったら、お気軽に👏 ;)

正直なところ、このタイトルはクリックベイトです*.*

「ドキュメントで提供されているいくつかの共通ガイドラインを尊重して、AWS インフラストラクチャでコストを最適化した方法」のようなものを書くことは間違いありませんが、キャッチーではありません。

おそらく、これらのトリックや優れたプラクティスを既に知っている人もいるでしょう。

私が提案するチェックリストを直接探している場合は、ここまでスクロールしてください。

DocumentDB サービスの非常にトリッキーな I/O コストを理解する

価格ページを見ると、4 つのコストディメンションで分割されています。ここで再開します。

インスタンスの価格: このコストはすぐに理解できます。インスタンスに対して支払います。価格はそのリソース (CPU、RAM など) によって異なります。
ストレージとバックアップストレージのコスト: 上記と同じで、かなり理解しやすく、それらのコストを追跡して簡単に見積もることができます。AWS は保存された GB ごとに請求します。合法。
非常にトリッキーな部分はデータベース I/Oです。AWS は 100 万 I/O あたり0.20 ドルから0.30 ドル(インスタンスのリージョンによって異なります) を請求します!!

では、I/O の背後にあるものは何でしょう?

AWS は、DocumentDB サービスを使用すると、事前に I/O リソースをプロビジョニングする必要がないことを説明しています。これは興味深いことです。ストレージの制限がなく、I/O 操作の選択を簡単に処理できるからです。使用料を請求しているので、公平に思えます。

AWS はドキュメントで、I/O 操作をカバーするものについて説明しています。主に、検索、挿入、更新、削除などのすべての操作、またはストリームの変更や TTL (Time to Live) インデックスなどの一部の機能です。

まあ、ストレージボリュームにヒットするものはすべてあなたに請求されます.

待って、何、100 万 I/O あたり 0.20 ドル？

今すぐ AWS に損失を出させましょう!

AWS DocumentDB のドキュメントには、あなたの目 (そして財布 💸) を引き付けるフレーズがあります。

一度、データがストレージボリュームから読み取られ、メモリ内に存在し続けると、同じデータの後続の読み取りで追加の I/O が発生することはありません。

このフレーズは、I/O の背後にあるものを理解するための鍵です。

I/O の使用量が少ない操作はどれですか?

インデックスを使用するクエリは、コレクションのすべてのストレージをスキャンしていないため、使用する I/O が少なくなる可能性があります。確かに I/O を消費しますが、コレクション全体をスキャンするよりもずっと少なくなります。

さらに、インスタンスの RAM はインデックスサイズをカバーする必要があり、追加の I/O が発生しないようにすることができます。

インデックスの使用に関するいくつかの原則を尊重する必要があることに注意してください。

チェックリスト ✅

I/O の使用を最適化し、コストを削減してパフォーマンスを向上させたい場合のアドバイス/チェックリストを次に示します。

DocumentDB に厳密には適用されないいくつかの一般的なベストプラクティスを使用して、AWS DocumentDB ドキュメントページから情報を集めただけなので、私が天才ではないことがわかります。

原則で心をリフレッシュすることは常に良いことです。

🧠まず、次のことを覚えておいてください。I/O が少ない = 安価 = パフォーマンスが向上します。ここでは、コストやパフォーマンスがすべてではありませんが、2 つのことは関連しています。
❌未使用のインデックスを削除する: ビジーなコレクションの未使用のインデックスがどれほどコストがかかるかわかりません。未使用のインデックスを削除することで、会社は月額 2,000 ドル節約できました🤌 。また、次のクエリを使用すると、未使用のインデックスを簡単に追跡できます。

インデックス統計クエリ

クエリは、インデックスがヒットした回数に対応するフィールドopsを出力します。アプリケーションの負荷に応じて、未使用のインデックスを削除することを検討してください。

🧐パフォーマンスインサイトとプロファイリング操作を有効にする: RDS を使用している場合は、パフォーマンスインサイトを認識している可能性があります。これにより、DocumentDB のパフォーマンスに影響を与えているクエリに関する非常に役立つメトリックと情報が得られ、I を消費するクエリをすばやく確認できます。 /Os 操作 (およびそれらの量) が含まれているため、ボトルネックを簡単に追跡するのに非常に役立ちます。スロークエリまたは collscan クエリを監視するもう 1 つの方法は、プロファイリング操作をアクティブにすることです。その名前が示すように、いくつかの操作をプロファイリングしていることを示しています (詳細情報を取得するためのリンクは次のとおりです)。 n ミリ秒以上かかる操作。たとえば、COLLSCAN を実行しているクエリの数を追跡するのに非常に便利です。これらのオプションは非常に価値があるため、両方を有効にしてください。
💾常に最初にデータを見てください: インデックスを作成する最適な高カーディナリティフィールドを特定する必要があります。インデックスカーディナリティの概念に慣れていない場合は、AWS DocumentDB のドキュメントで十分に説明されています :)
🫠小さくトリッキーなコレクションを避ける: 3 つのフィールドを持つコレクションを作成し、そのうちの 1 つに一意のキーを持たせ、多くの更新/挿入を実行する予定の場合は、コレクションのモデル化を検討してください。 I/O 操作が地獄のようにヒットし、I/O の使用量が増えるためです。
⏱️ TTL、別名 Time-to-leave インデックスを避ける: (ほとんどの場合) Time-to-leave インデックスを設定しなくても処理できるため、インスタンスまたはクラスターで TTL パラメーターが有効になっていないことを確認してください。
💡解説！新しいクエリを作成するとき (または作成しないとき) にクエリプランナーのインデックスの選択性を確認する非常に簡単な方法は、 executionStatsパラメーターを使用してExplain操作を実行することです。インデックスにヒットすると思っていたいくつかのクエリが、どのインデックスにもヒットしなかったことに驚かれることでしょう…
☯️ boolean フィールドのインデックスを作成しないでください。ただしないでください。カーディナリティを覚えておいてください。
⚖️ db.<mycollection>.stats(1024)コマンドを使用して、所有する各コレクションのオブジェクトの平均サイズを監視します。あなたのインスタンスでは十分ではありません。オブジェクトを注意深く監視し、不要なフィールドを保存しないでください。多くのフィールドを保存する必要がある場合は、すべてのフィールドを選択しないことでクエリを最適化することを検討してください。
⚠️ DocumentDB は MongoDB ではないことに注意してください。主に MongoDB と互換性がありますが、MongoDB ではありません。たとえば、 $regex演算子を使用してクエリを実行する場合は、必須であるため、インデックスを付ける `hint()` が必要です。除外演算子はインデックスを使用しないため、インデックスを作成または最適化するときは、これらの動作を考慮してください!
👉 ほのめかさないでください。上記の非常に具体的な使用例を除いて、 hintの使用を避ける必要があります。クエリプランナーがインデックスを選択しない場合、それには正当な理由があることに注意してください。ほとんどの場合、コレクションからすべてのドキュメントをスキャンするのではなく、インデックスをスキャンするのに時間がかかるか、同等であるためです。