awsサービスのdynamodbの監視とは

dynamodbは、awsのサービスの1つで完全マネージド型のNoSQLデータベースサービスのことです。完全マネージド型なのでデータベース管理作業について心配はありません。またシステム規模に関わらず、自動的にスケールアップ・ダウンを調整し、高速で一貫したパフォーマンスを提供してくれます。

無料利用枠もあるのでawsアカウントを作成すれば、すぐにdynamodbのサービスを利用できます。

dynamodbの特徴

dynamodbの特徴であるNoSQLデータベースは高いスケーラビリティを実現できる設計になっています。ただし、リレーショナルデータベースに匹敵するほど複雑なクエリ機能はありません。dynamodbのNoSQLデータベースのタイプはキーバリューストアとドキュメント型データベースのデータ構造を持ちます。

キーバリューストアとはキーとバリュー(値)のデータを管理するデータストアのことです。ゲームや広告、モバイルといった信頼性と低い遅延(レイテンシー)で安定したスループット(秒当あたりの読み書き)が求められるアプリケーションに主に使われます。

コストについては、プロビジョニングされたスループットの容量と使用されたストレージ分のみに支払うだけです。自動的に3か所の施設にバックアップがとられているので、災害や復旧作業に強いのが魅力です。自動的にスケールアップ・スケールダウンを調節して、高速で一貫したパフォーマンスを提供してくれます。

またdynamodbのテーブル構成は、アイテムとアトリビュートで構成されています。アイテムは一意のプライマリキーと任意の数のアトリビュートを持っています。テーブル内の各テーブルには一意の値を持つプライマリキーがあり、プライマリキーでアイテムのクエリが出来上がります。

dynamodbの特徴を生かすためには、コスト面で運用監視を常にする必要があります。

dynamodbのコスト面の監視の必要性

クラウドサービスのdynamodbはパフォーマンスで適切な運用と監視を行う必要があります。コスト面で料金が膨れ上がることがあるからです。オンプレミスのデータベースサーバは設計・構築・運用するのに計画通りのコストがかかります。

他方、dynamodbは利用した分だけかかります。この2つの違いの理由は監視計画が異なっているからです。オンプレミス環境ではサーバーを自社で運用するので、コスト面でサーバーを長く持たせようとします。クラウドでは仮想サーバーを作るだけなので、サーバ一の監視よりも使用量の監視が大切になってきます。

dynamodbは、セットアップは不要で、サインインすればすぐに最新のデータベース環境が整います。dynamodbが常に適正か、継続的に改善しながら適正コストを見つけ出す必要があります。ちなみにテーブルの削除は簡単にできます。

不要なテーブルで課金されないように、使用しなくなったテーブルは削除しておきましょう。

dynamodbの料金プラン

dynamodbの料金プランは2つあります。料金プランごとにデータの読み書きの請求オプションがあります。1つ目はオンデマンドキャパシティプランで、システムがdynamodbに対してデータの読み書きをした回数に対して料金が発生するプランです。

2つ目はプロビジョニング済みキャパシティープランで、システムがdynamodbに対して、1秒当たりのデータの読み書き回数を指定し、指定した回数をベースに料金が決定されるプランです。データの読み書きが予測できるのならプロビジョニング済みキャパシティプランが適切とされ、逆に予測できないのなら、オンデマンドキャパシティーが適切です。

契約者によっては、月日によってデータの読み書き回数が大きく違うので、常に監視・分析して適切なプランを検討しなければなりません。

cloudwatchでログ監視をすべき理由は?効率的な方法も紹介!

dynamodbの監視計画の作成

dynamodbの信頼性、可用性、パフォーマンスを維持する上では、監視は欠かせません。適切な監視が行えるように、監視計画を立てましょう。監視する前に、監視の目的、使用する監視ツール、監視の頻度とリソースを明らかにします。

その後に監視担当者を決めて問題が発生した場合には、誰が通知を受け取るのかを決めます。次に、様々なタイミングと負荷条件でパフォーマンスを測定し、通常時のdynamodbのパフォーマンスのベースラインを確定します。

ベースラインの確定には、次の3つの項目を監視する必要があります。1つ目は指定された期間に消費された読み込み、または書き込み容量ユニットの数です。2つ目はテーブルにプロビジョニングされた書き込み、または読み込み容量を指定期間中に超えたリクエストです。

3つ目はリクエストエラーです。出来上がった監視のデータを、通常時のデータとしてベースラインを保存します。これで監視計画の作成が完了です。

dynamodbの監視による異常データの活用

最新のdynamodbのパフォーマンスデータとベースラインの保存データを比較すれば、異常時のデータが検出できます。検出されるもので注目するのは3つです。1つ目は、プロビジョニングされたスループットの使用量の増加による読み書きの遅れです。

読み書きのキャパシティユニットを監視すれば、読み書きの動作の上昇や低下を発見できます。1つの読み込みキャパシティユニットは、1秒で4KBを超えると読み書きに遅れが生じます。2つ目は、テーブルにプロビジョニングされたスループットクォータを、どのリクエストが超過したのかです。

リクエストが設定した制限を超過した場合にリクエストが制限されます。このリクエストの制限プロセスは、リーキーバケットアルゴリズムの概念と呼ばれています。ネットワークに注入されるデータの転送レートの制御に使われ、データ転送レートの「バースト性」を平常化します。

最後にリクエストのエラーです。リクエストが失敗した場合、dynamodbは以下の3つのエラーを返してくます。HTTPステータスコード(例:400など)とエラーメッセージ、例外名です。HTTPステータスコードとは、ユーザーがブラウザから送ってくるリクエストに対して、レスポンスの結果を示す3桁のコードのことです。

400番台はクライアントエラーで、リクエストが処理できない趣旨のエラーメッセージがでます。具体的には、認証の失敗や必須パラメータの欠落です。またはテーブルにプロビジョニングされているスループットの超過などの問題が示されます。

監視担当者はコードが400(不正なリクエスト)になったリクエストの数を監視します。このコードは少ない方が望ましく、400が出た場合クライアントがdynamodbとの通信に、なんらかの問題があることを示しています。

500番台はサーバーエラーを示します。サーバーの異常が発生し、ページが表示できない状況の趣旨のエラーメッセージがでます。少ないほうが望ましく、担当者はサーバーエラーの原因を調査します。以上のように、監視により獲得した異常データを活用すれば、常にdynamodbの適切なパフォーマンスがわかります。

さらにcloudwatch(awsの監視サービス)にdynamodbのデータを送れば可視化できるので、ログ管理を含めた総合的な監視も行えます。

サーバーの監視を自動化する「aws glue」!導入するメリットと注意点を解説

dynamodbのメリットを生かすには常に監視が必要

dynamodbのメリットを最大限に生かすには、常にパフォーマンスを監視する必要があります。その監視結果を分析して、ユーザーが自分に合った適正料金プランを選びます。無駄のない容量を使い続けることがポイントになります。

クラウドサービスであるdynamodbは、オンプレミスでは行うサーバー管理をしなくてよいのがメリットです。一方でdynamodbというサービスの監視は継続的に実行する必要があります。