DynamoDBも当初はマネージドとしてシンプルでしたが要求が増えるにつえ複雑になってきました。 ＊ソフトウェアでは良くあることで、そして新しくシンプルなものが生まれ新しいサイクルが始まる モデリングなどはドキュメントを見ていただきつつ、この記事では間違えやすい抑えていただきたいポイントを解説します on-demandモードを使う 初期設定はprovisionedモードになりがちですが固定料金を取られます。また、トラフィックが読めないとき、増減激しいときもあるでしょう on-demandモードが無難です(2024/11/1から半額になりなおさら) CDKの場合、dynamodb tableV2を使うと初期設定でon-demandです provisionedになっているテーブルを探すならAWS Configを使えばアカウント横断で検索できます provisionedは上級者向け。地味に難しい
はじめに AWS Lambdaは、イベント駆動型のサーバーレスコンピューティングサービスであり、API GatewayやEventBridgeなど様々なサービスから起動されます。 この記事ではAWS Lambdaでのインメモリキャッシュのポイントと、その実装方法について解説します。 キャッシュとは コンピューティングにおいて、キャッシュは、データのサブセットが保存される高速のデータストレージレイヤーで、通常は一時的な性質のものです。これにより、それ以降に同じデータのリクエストが発生した場合、データのプライマリストレージロケーションにアクセスするよりも高速にデータが供給されます。キャッシュにより、以前に取得または計算されたデータを効率的に再利用できるようになります。 AWSでキャッシュを活用することのメリット AWSでキャッシュを活用することで以下のようなメリットがあります。 パフォーマンス
概要 サーバレスアプリケーションで利用されることの多いAmazon DynamoDBについてまとめてみました。DynamoDBの利用を検討されている方やDynamoDBのテーブル・インデックス設計を考えられている方の参考になると幸いです。 Amazon DynamoDB DynamoDBの特徴 フルマネージド型の NoSQL データベースサービス データは3つの Availability Zone に同期的にレプリケートされるため可用性とデータ耐久性が高い 性能要件に応じて、テーブルごとに読み込み・書き込みキャパシティを設定可能。キャパシティの Auto Scalingやオンデマンドキャパシティにも対応 ストレージの容量制限がない。使った分だけの従量課金制 基礎知識 テーブルは各Itemを一意に識別できるPrimary Keyを持ちます。Primary Keyは、Partition Key
Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R
Serverless Framework(https://www.serverless.com/)を使ったアプリケーション構築のハンズオン本です。 アプリケーションの雛形を構築するとともに、サーバーレスでのサービス構築に関連する設定やTipsについてステップバイステップで理解できるようになることを目指します。
Amazon DynamoDB スケーリングのベストプラクティス | Amazon Web Services
Amazon Web Services ブログ Amazon DynamoDB スケーリングのベストプラクティス はじめに 長年にわたって、Amazon DynamoDB はものすごいスピードで進化を遂げています。グローバルセカンダリインデックス(GSI)、クエリ式のサポート、Auto Scaling 機能、そして、ポイントインタイムリカバリ (PITR) 、オンデマンドモードを断間なくリリースされました。お客様はモバイルバックエンドをはじめ、ゲームや IoT (Internet of Things) の実装まで、さまざまなユースケースで DynamoDB を使用してきました。 本記事は、DynamoDB を利用する中で、スケーリングの部分に焦点に当たって、スケーリングを考えるときのポイントを説明します。その後、代表的なワークロード、例えば、新しいサービスローンチや、ゲームにおいては新しい
本記事はハンズラボ Advent Calendar 2020の17日目です。 はじめに！ こんにちは。AWS絶賛勉強中の@bassaaaaaです。 業務でDynamoDBテーブルを全件取得し、ゴニョゴニョする必要がありました。 RDBなら普通にExportできますが、DynamoDBは最近までできなかったみたいです。 というわけで、最近出たDynamoDB Export1をaws-cliからやってみたいと思います。 前置きはいいから！という人はaws-cliでDynamoDB Exportをやってみるへ 昔は大変だった！ DynamoDB Exportは2020/11/9から使えるようになりました。 それまでは以下のような方法でExportを行う必要がありました。2 AWS Data Pipelineを使う Amazon EMRを使う AWS Glueを使う 全件取得クエリ 1~3はなんと
計測対象が増えた場合にカラムやアトリビュートが横に増えていくのか、レコードが縦に増えていくのかという違いがあります。 ストレージ Timestreamはメモリストアとマグネティックストアという2種類のストレージを持ちます。それぞれ以下のような役割を持ちます。 メモリストア 新しいデータを保存するためのストレージ ある時点のデータを高速に抽出するようなクエリに最適化されている マグネティックストア データを長期間保存するためのストレージ 分析クエリをサポートするように最適化されている 各ストレージにはデータの保持期間が設定でき、設定したデータ保持期間とレコードのタイムスタンプに応じてレコードの保存先がメモリストア → マグネティックストアと遷移し、マグネティックストアのデータ保持期間を超過したレコードは削除されます。 現在はメモリストアとマグネティックストアの2種類でストレージが構成されてい
何を書いた記事か 過去にDynamoDB Streams + Kinesis Data Firehose + Lambdaを用いたリアルタイムETLを検証した際のメモをこちらに転載します。 特にKinesis Data Firehoseの裏で動かすLambdaの実装に癖があったので、誰かの参考になれば幸いです。 前提 Webサービスなど展開していて、Database層にDynamoDBを採択している場合、そのデータを分析するための分析基盤構築手法として、Glueを用いたETLが一般的な選択肢になりうるのかなと思います。 最近DynamoDBのTableをS3にExportできる機能もGAになったので、フルダンプ＋日時バッチのデータ分析としてはそのような手法も使えるかもしれません。 しかし、DynamoDB上にあるデータをなるべくリアルタイムに分析基盤に連携したい、最低限のETL処理も挟みた
【2019/09/12 追記】 この資料は旧版であり、最新版が存在します。 2019/09/12 にアップロードしたものをご参照ください 最新版 → https://www.slideshare.net/AmazonWebServicesJapan/db-20190905 --------（元の文）------------------- 2019/05/09 に #AWSLoft Tokyo で開催されたイベント、「イチから理解するサーバーレスアプリ開発」における講演資料の一つです。 ・サーバーレスアプリケーションにおいて Amazon DynamoDB が利用しやすい理由 ・RDB と DynamoDB の設計プロセス・考え方の対比・明文化 ・実例に沿った DynamoDB の設計プロセス解説とサンプル例題 などを含みます。 イベント: https://understandingbasi
Amazon DynamoDB のベストプラクティスに従うという 2019 年の計を立てる | Amazon Web Services
Amazon Web Services ブログ Amazon DynamoDB のベストプラクティスに従うという 2019 年の計を立てる AWS ではこの 2019 年、DynamoDB での作業時にミッションクリティカルなワークロードのパフォーマンスを最大化して、コストを最適化するために役立つ Amazon DynamoDB のベストプラクティスに従うことをお勧めします。この記事は、このような抱負の維持を助ける DynamoDB のコンテンツに焦点を当てて行きます。 パーティションキーを効率的に設計して使用する DynamoDB テーブルにある各アイテムを固有に識別するプライマリーキーは、シンプルなキー (パーティションキーのみ) または複合キー (ソートキーと組み合わされたパーティションキー) にすることができます。アプリケーションは、テーブルとそのセカンダリインデックスの論理パーテ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DynamoDBを使うサーバーレス設計を使ったときに失敗したことがあったので書きます。 なお、この体験はハッカソン等での個人の体験であり、 実サービスとは関係ありません。 また、関わったエンジニアの方々を馬鹿にしたいわけでなく、同じ失敗を繰り返さないために自分用のメモとしても載せております。 わかること DynamoDBを使うサーバーレス設計を利用するときの失敗例から導入すべきかどうか 料金や工数は本当に下がるのか 要件 投稿があったらその投稿にメールを返信したい SNSログインもある 件数は無限に多いと予想 Railsのomniaut
はじめに Amazon DynamoDBは低レイテンシで安定したスループットもつNoSQLサービスです。コストが低く使いやすいので弊社でも様々な案件で利用しています。 DynamoDBではあらかじめテーブルごとに読み込み/書き込みのスループットを指定することができます。 例えば、参照が多いサービスで利用する場合は読み込み：1000回/秒、書き込み：100回/秒のプロビジョンドスループットを設定するという具合です。 プロビジョンドスループットを超えた操作が発生した場合、バーストキャパシティ(バースト用に貯められている予備キャパシティ)が残っていればそれが利用されますが、バーストキャパシティを使い切っている場合、操作に失敗します。 なので、ある程度余裕を持ったプロビジョンドスループットの設定が必要です。 とはいってもスループットを事前に予測するのは難しいため、予測を超えたスループットが発生した
あいさつ Serverless(2) Advent Calendar 2016 15日目の記事です。 こんにちは。GS2 CEO の丹羽(@kazutomo)です。 サーバレスアーキテクチャでゲームサーバを開発し、AWSのサービスのように1時間あたり数円〜利用できる Game Server Services を提供しています。 このシステムのバックエンドDBの多くには DynamoDB を利用しており、サーバレスアーキテクチャと DynamoDB は切っても切り離せない関係にあると感じています。 これからサーバレスアーキテクチャを勉強しようと思っている皆さんの中には 「まだDynamoDBとかよくわかってないんだよなあ」 という人も多くいらっしゃるとおもいます。 この記事ではプログラムのコードを示して使い方を説明するというよりは、 DynamoDB とはどういうものか？どういうことに気をつ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【JAWS-UG朝会】今更ながら Amazon DynamoDB の論文を真面目に読んでみた
