Azure Table Storage

解決する課題

スキーマ設計やインデックス管理に手間をかけずに、大量の半構造化データをとにかく安く保存したい、というニーズに応えます。リレーショナルな結合や複雑なクエリは不要で、「キーを指定して引く」アクセスが中心のワークロードに向きます。

• ログ、IoT のテレメトリ、ユーザープロファイルなど、項目数が膨大になるデータを置きたい
• スキーマが頻繁に変わる、または項目ごとに列が違う半構造化データを扱いたい
• RDB ほどの機能は要らず、できるだけ低コストでストレージを確保したい
• キーで素早く引ければよく、複雑な検索や結合は不要

AWS で言えば DynamoDB の最小機能セットに近く、ストレージ課金が中心の簡易版という位置づけです。

主要概念と用語

• ストレージアカウント: テーブルを束ねる入れ物。Blob やキューと同じアカウント上に同居する
• テーブル: 項目（エンティティ）の集合。スキーマ定義は不要で、行ごとに異なるプロパティを持てる
• エンティティ（Entity）: 1件のレコードに相当。最大プロパティ数や1件あたりサイズに上限がある
• パーティションキー（PartitionKey）: データの物理分散を決めるキー。同じ値の項目は同一パーティションにまとまる（DynamoDB のパーティションキーに相当）
• 行キー（RowKey）: パーティション内で項目を一意に識別するキー（DynamoDB のソートキーに近い役割）
• 主キー: パーティションキーと行キーの組み合わせ。この2つで1件を一意に特定する
• タイムスタンプ（Timestamp）: 各エンティティに自動付与される更新時刻。サーバー側で管理される
• プロパティ: 列に相当。文字列、数値、真偽値、日時、バイナリなどの型を持てる

仕様・制限・クォータ

• スキーマレス: 同じテーブル内でもエンティティごとにプロパティ構成を変えられる
• インデックスはキーのみ: パーティションキーと行キーにのみインデックスがあり、それ以外のプロパティでの検索はテーブルスキャンになる
• 1エンティティあたりのプロパティ数とサイズに上限があり、1件は数百キロバイト程度までに収まる（大きな本文は Blob に逃がす）
• クエリ言語は SQL ではなく、プロパティに対するフィルター式で行う。結合や集計、グループ化はサポートしない
• トランザクションはエンティティグループトランザクションに限定され、同一パーティションキー内の複数操作をまとめて1回で実行できる（パーティションをまたぐ原子的更新はできない）
• 厳密な数値は変動しうるため公式ドキュメントで確認すること

内部の仕組み

Table Storage はパーティションキーを使ってデータを内部のパーティションに振り分け、負荷に応じて自動でスケールします。同じパーティションキーを持つ項目は同じパーティションに集まり、その範囲内では行キー順に並びます。したがってパーティションキーの設計が性能を左右します。

• パーティションキーと行キーの両方を指定する「ポイントクエリ」が最も高速で安価
• パーティションキーを固定して行キーの範囲を絞る「レンジクエリ」も効率がよい
• キーを指定しない検索は全パーティションを走査するテーブルスキャンとなり、遅く高コストになる
• 1つのパーティションへアクセスが集中するとホットパーティションとなり、スループットの上限に当たりやすい

設計パターン / ベストプラクティス

• アクセスパターンを列挙し、読み取りがキーで完結するようパーティションキーと行キーを決める
• 1つのキーに偏らないよう、カーディナリティが高く負荷が分散するパーティションキーを選ぶ
• 時系列ログでは、行キーに逆順のタイムスタンプを入れて新しい順に取りやすくするなどの工夫をする
• 同じデータを別のキー設計で**重複保存（デノーマライズ）**し、複数のアクセスパターンに備える
• 大きなバイナリや本文は Table に入れず Blob Storage に置き、Table にはキーやメタデータだけを持たせる
• 同一パーティション内のまとめ更新にはエンティティグループトランザクションを使う

運用・監視

• Azure Monitor / ストレージメトリクスでトランザクション数、レイテンシ、エラー率を監視する
• スロットリングを示すステータス（要求が多すぎる旨のレスポンス）が出たら、ホットパーティションやアクセス集中を疑う
• 診断ログを Log Analytics に送り、遅いクエリや高頻度のスキャンを特定する
• バックアップ用途では、データのコピーやエクスポートの仕組みを別途用意する（テーブルのポイントインタイム復元のような高度な機能は前提にしない）

コスト

Table Storage の最大の魅力は安さです。課金は基本的に保存データ量とトランザクション数で決まり、スループットを事前に確保して支払う方式ではありません。同じキーバリュー用途でも、機能が豊富な Cosmos DB に比べて単純なストレージ課金で済むため、低トラフィックや大量保存のケースでコストを抑えられます。

セキュリティ

• 保存時暗号化はデフォルトで有効（ストレージサービスの暗号化）。通信は TLS で暗号化される
• アクセス制御はアカウントキー、SAS（Shared Access Signature）、Microsoft Entra ID（RBAC） から選べる。キーのハードコードを避け、可能なら Entra ID とマネージド ID を使う
• SAS を使えば、有効期限や権限を絞った一時的なアクセスを発行できる
• プライベートエンドポイント（Private Link） で VNet 内からの到達に限定し、パブリックアクセスを最小化する

Well-Architected の観点

• コスト最適化: スループットを確保して払う方式ではなく保存量とトランザクション課金が中心のため、大量データの保管や低トラフィック用途で費用を大きく抑えられる
• パフォーマンス効率: ポイントクエリとレンジクエリに最適化されており、キー設計が適切なら大規模でも安定して高速に引ける。一方でキー以外の検索や集計は不得意なので、要件が合うかを見極める

試験で問われるポイント

関連サービス・比較

同じキーバリューの世界でも、シンプルで安い Table Storage と、高機能でグローバル分散できる Cosmos DB のどちらを選ぶかが論点になります。AWS の対応サービスとあわせて整理します。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# ストレージアカウントを作成（Table はこのアカウント上に作る）
az storage account create \
  --name demotablestg0614 \
  --resource-group demo-rg \
  --location japaneast \
  --sku Standard_LRS

# アカウントキーを取得して環境変数に入れる
az storage account keys list \
  --account-name demotablestg0614 \
  --resource-group demo-rg \
  --query "[0].value" -o tsv

# テーブルを作成
az storage table create \
  --name Orders \
  --account-name demotablestg0614

# エンティティを1件挿入（PartitionKey と RowKey が主キー）
az storage entity insert \
  --account-name demotablestg0614 \
  --table-name Orders \
  --entity PartitionKey=user001 RowKey=order100 Amount=1500 Status=paid

# パーティションキーと行キーを指定してポイントクエリで取得
az storage entity show \
  --account-name demotablestg0614 \
  --table-name Orders \
  --partition-key user001 \
  --row-key order100