これは、AWS での「コストの最適化」の基本について、ずっと共有したかった短いシリーズです。 この旅を から始めましょう! DocumentDB この投稿が気に入ったら、お気軽に👏 ;) 正直なところ、このタイトルは *.* クリックベイトです のようなものを書くことは間違いありませんが、キャッチーではありません。 「ドキュメントで提供されているいくつかの共通ガイドラインを尊重して、AWS インフラストラクチャでコストを最適化した方法」 おそらく、これらのトリックや優れたプラクティスを既に知っている人もいるでしょう。 私が提案するチェックリストを直接探している場合は、ここまでスクロールしてください。 DocumentDB サービスの非常にトリッキーな I/O コストを理解する 価格ページを見ると、4 つのコスト ディメンションで分割されています。ここで再開します。 : このコストはすぐに理解できます。インスタンスに対して支払います。価格はそのリソース (CPU、RAM など) によって異なります。 インスタンスの価格 : 上記と同じで、かなり理解しやすく、それらのコストを追跡して簡単に見積もることができます。AWS は保存された GB ごとに請求します。合法。 ストレージとバックアップ ストレージのコスト です。AWS は 100 万 I/O あたり から (インスタンスのリージョンによって異なります) を請求します 非常にトリッキーな部分はデータベース 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 つの方法は、 をアクティブにすることです。その名前が示すように、いくつかの操作をプロファイリングしていることを示しています (詳細情報を取得するためのリンクは次のとおりです)。 以上かかる操作。たとえば、COLLSCAN を実行しているクエリの数を追跡するのに非常に便利です。これらのオプションは非常に価値があるため、両方を有効にしてください。 🧐 インサイトと を パフォーマンス プロファイリング操作 プロファイリング操作 n ミリ秒 💾 : インデックスを作成する最適な高カーディナリティ フィールドを特定する必要があります。インデックス カーディナリティの概念に慣れていない場合は、AWS DocumentDB のドキュメントで十分に説明されています :) 常に最初にデータを見てください 🫠 : 3 つのフィールドを持つコレクションを作成し、そのうちの 1 つに一意のキーを持たせ、多くの更新/挿入を実行する予定の場合は、コレクションのモデル化を検討してください。 I/O 操作が地獄のようにヒットし、I/O の使用量が増えるためです。 小さくトリッキーなコレクションを避ける ⏱️ : (ほとんどの場合) Time-to-leave インデックスを設定しなくても処理できるため、インスタンスまたはクラスターで TTL パラメーターが有効になっていないことを確認してください。 TTL、別名 Time-to-leave インデックスを避ける 💡 新しいクエリを作成するとき (または作成しないとき) にクエリ プランナーのインデックスの選択性を確認する非常に簡単な方法は、 パラメーターを使用して 操作を実行することです。インデックスにヒットすると思っていたいくつかのクエリが、どのインデックスにもヒットしなかったことに驚かれることでしょう… 解説！ executionStats Explain ☯️ 。ただしないでください。カーディナリティを覚えておいてください。 boolean フィールドのインデックスを作成しないでください ⚖️ コマンドを使用して、所有する各コレクション ます。あなたのインスタンスでは十分ではありません。オブジェクトを注意深く監視し、不要なフィールドを保存しないでください。多くのフィールドを保存する必要がある場合は、すべてのフィールドを選択しないことでクエリを最適化することを検討してください。 db.<mycollection>.stats(1024) のオブジェクトの平均サイズを監視し ⚠️ 主に MongoDB と互換性がありますが、MongoDB ではありません。たとえば、 演算子を使用してクエリを実行する場合は、必須であるため、インデックスを付ける `hint()` が必要です。除外演算子はインデックスを使用しないため、インデックスを作成または最適化するときは、これらの動作を考慮してください! DocumentDB は MongoDB ではないことに注意してください。 $regex 👉 ほのめかさ でください。上記の非常に具体的な使用例を除いて、 の使用を避ける必要があります。クエリ プランナーがインデックスを選択しない場合、それには正当な理由があることに注意してください。ほとんどの場合、コレクションからすべてのドキュメントをスキャンするのではなく、インデックスをスキャンするのに時間がかかるか、同等であるためです。 ない hint 私の会社で AWS コストの最適化に取り組んでいる間に私が学んだこれらの秘訣を理解していただけることを願っています。 別の投稿をお楽しみに！ この投稿が気に入ったら、お気軽に👏 ;) PS: 何か間違っている、または誤解していると思われる場合は、遠慮なく私に DM を送ってください。 にも掲載 こちら

Amazon

Read My Stories

Buy Me a Coffee

Software Engineer/AWS Architect

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Let Your Engineers & PMs focus on Product. Apply for $50K Credits!

HackerNoon Mobile

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

長すぎる; 読むには

Company Mentioned

@paulelie

関連ストーリー