[小ネタ] DynamoDBのキャパシティユニットをCloudWatchで見るときのコツ | DevelopersIO
ども、大瀧です。 クラウドネイティブなEC/CRM SaaSであるPrismatixでは、AWSマネージドサービスをこれでもかと駆使ししており、日々の運用ではそれらのメトリクス監視が肝要です。マネージドNoSQLサービスであるDynamoDBの運用としては、パフォーマンス設定であるキャパシティユニットの監視が鉄板と言えるでしょう。 DynamoDBのキャパシティユニットは、テーブルないしグローバルセカンダリインデックスにおける単位時間あたりの性能キャパシティを確保するものです。運用としては消費量が確保したキャパシティを超えないよう、CloudWatchアラームを設定して監視したり、スパイクでなければAuto Scalingを設定してキャパシティを増やしたりできます。 CloudWatchでキャパシティユニットの使用状況を見たい！ キャパシティユニットの直近の状況をAWS Managemen
![[小ネタ] DynamoDBのキャパシティユニットをCloudWatchで見るときのコツ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/4b2f07b09ab4c1be36356e4aa6b29a3c80c4aa9a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FDynamoDB.png)
AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
3. サーバーレスアーキテクチャ #とは • 視点1：3種類の「サーバ」を捨てていく 1. 自分で管理する物理的・仮想的な「サーバ」を捨てて、 上の「機能」だけを利用する 2. プロビジョニング単位としての「サーバ」を捨てて、 確保サーバ数から消費したリソース量への転換 3. 処理全体に責任を持つ「指揮者としてのサーバ」を捨てて、 リアクティブな非同期メッセージングでシステムを構成 • 視点2：クラウドが提供する「ありもの」を最大限に活用する 4. 続きは書籍で！ • SoftwareDesign 2016/04号 • 電子版が技評で買えます https://gihyo.jp/dp/ebook/2017/978-4-7741-8409-8 • サーバーレスの薄い本 • 電子書籍版 https://gumroad.com/l/memotr201608 • ダイジェスト https://www
DynamoDBのインフラコスト構造と削減策 - ゆううきブログ
Amazon DynamoDBは、RDSのようなインスタンスサイズによる課金モデルではなく、ストレージのデータ使用量とスループットを基にした課金モデルになっている。 インスタンスサイズによる課金モデルでないデータストア系サービスとして、他にはS3、Kinesisなどがある。 これらは、AWSの中でも、フルマネージドサービスと呼ばれる位置づけとなるサービスだ。 フルマネージドサービスは、ElastiCacheのようなそうでないものと比較し、AWSに最適化されていて、サービスとしてよくできていると感じている。 Mackerelの時系列データベースのスタックの一つとして、DynamoDBを採用している。 時系列データベースの開発は、コストとの戦いだったために、それなりにコスト知見が蓄積してきた。(時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ) (※ 以下は、2018
DynamoDB ベストプラクティス - Qiita
今年は始めて、re:Inventに参加してきたので、その際に見た「Amazon DynamoDB: Data Modeling and Scaling Best Practices」というセッションの内容を共有したいと思います。 内容をだいぶ端折ってるので、間違っている場合には、びしばしツッコミいただければと思います。 では、まいります。 1. CacheはCashなり なんでDynamoDBを使うかといえば、やっぱり、ポチポチっと設定するだけで簡単に読み込み、書き込み性能を上げたり、下げたりできるっていうのが大きなポイントかと思います。 ただ、設定した性能も、データのアクセスパターンによっては思い通りの性能が出ないことがあります。 例えば、ReadCapacityを 100から5,000 に上げたとします。そうると、DynamoDBは、「オレ１人では捌き切れない」と思って、パーティション
コンセプトから学ぶAmazon DynamoDB【GSI篇】 | DevelopersIO
よく訓練されたアップル信者、都元です。今回はグローバル・セカンダリ・インデックス（GSI）にフォーカスします。LSIを忘れないうちにGSIいきますよっ。 ローカル・セカンダリ・インデックス（LSI）というのは、ハッシュキーattributeが共通で別のレンジキーattributeを持つ、複合キーテーブルに対するインデックスでした。 グローバル・セカンダリ・インデックス（GSI）とは 例えば、Amazon DynamoDB Developer Guide - サンプルテーブルとデータにあるProductCatalogテーブルは、Idがハッシュキーとなったハッシュキーテーブルです。つまりこのテーブルは、Idを条件としたquery（問い合わせ）しかできません。ハッシュキーテーブルであるが故に、LSIも定義できません。 アプリケーション要件「ProductCategoryで絞り込んだ後、Title
コンセプトから学ぶAmazon DynamoDB【LSI篇】 | DevelopersIO
よく訓練されたアップル信者、都元です。今回はローカル・セカンダリ・インデックス（LSI）について深堀りしてみましょう。 ここまでの復習 その前に、色々復習しておきましょう。 DynamoDBのインデックス3種類 まず、DynamoDBが持てるインデックス3種類をあらためてまとめておきます。 暗黙的な、キー（ハッシュキーのみ、または、ハッシュキー＋レンジキー）による検索のためのインデックス 明示的に定義した、ローカル・セカンダリ・インデックス（LSI） 明示的に定義した、グローバル・セカンダリ・インデックス（GSI） このうち、暗黙的なインデックスは1テーブルにつき1つだけ、LSI及びGSIは1テーブルにつき各5個まで定義できます。つまり、1つのテーブルには最小で1個、最大で11個のインデックスがあります。検索を行う場合は、まず「どのインデックスを使って検索をするか」を指定し、その上で検索条
DynamoDBのキー・インデックスに関するまとめ 〜ハッシュキー(パーティションキー)、レンジキー(ソートキー)、プライマリキー、ローカルセカンダリインデックス、グローバルセカンダリインデックスの説明、違い、使い方、使用方法、例題、サンプル〜 | Magtranetwork マグトラネットワーク
AWS Lambda、Amazon API Gatewayに続きAWS IOTが発表され時代はモバイルとクラウドが融合したIOTへとトレンドが向かっていることが明確になって来ました。 このような状況下で今までよりもまして重要になってくるのがモバイル端末から送られてくる大量のデータを高速に保存し分析するKVS(キーバリューストア)型NoSQLです。 AWSにおいてはすでにチャットシステムやソーシャルゲームなどで幅広く活用されているDynamoDBがあります。 DynamoDBは高いパフォーマンスとスケーラビリティを兼ね備えているため昨今のITトレンドに対応しやすいですが、検索に使用するキーについては独特の考え方・設計がされているため使用するにあたっては一癖あります。 今回はAWSのKVS型NoSQLとして広く活用されているDynamoDBのキー・インデックスについて備忘録として記載しておきた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
