CHAPTER6 Architecting to Scale

AWS SAP対策

CloudFront-"Behavior"

CloudFrontでマルチオリジンとCache Behavior設定してみた | DevelopersIO

AWSの試験の中に、CloudFrontの機能としてBehaviorと呼ばれる機能が出てくる(日本語で何と訳されるかは謎)。

これはURLのパスごとにオリジンとするインスタンスやキャッシュの長さを変更できるシステムである。 パスごとにオリジンを変更することぐらいはELBでも出来る(パスベースルーティング)。キャッシュの長さを変更できるところがこの機能の利点となる。

これを使うとCloudFrontがオリジンに(キャッシュ対象コンテンツを)問い合わせる回数を最適化でき、オリジンとなるホスト(EC2やオンプレサーバ)に対する負荷を必要最小限とすることが出来る。

Kinesis

Amazon Kinesis Client Library(KCL)

Kinesisのデータストリームからデータをサブスクライブしてリアルタイムで処理するようなアプリケーションを自分で実装する場合、ストリームからやってくるデータの読み取りに必要なライブラリである。

Kinesis クライアントライブラリの使用 - Amazon Kinesis Data Streams

KCL は Java ライブラリです。Java以外の言語のSupport は、MultiLangDaemonと呼ばれる多言語インタフェースを使用して提供されます。このデーモンは Java ベースで、Java 以外の KCL 言語を使用している場合、バックグラウンドで実行されます。たとえば、KCL for Python をインストールして、コンシューマーアプリケーションをすべて Python で書く場合でも、MultiLangDaemon を使用するために、Java をシステムにインストールする必要があります。

ちなみにKinesisにデータを流し込む方にはAPI GatewayとKinesisDataStreamAPIなどを組み合わせて使うらしいがKCLさえ覚えておけば、テストでは問題なさそう。

SQS vs Kinesis vs S3

各アプリケーションが1ユニット毎に格納できるファイルの大きさは下記の通りになっている。 監視カメラとKinesisを連携するような場合、1MB(/s)だと小さすぎるように感じるが実際には性能上の問題なくビデオをストリーミング出来るらしい。

料金 - Amazon Kinesis Video Streams | AWS

Service Size
SQS 256KB
SNS 140Byte
Kinesis 1MB(/Second)
S3 5GB

DynamoDBのPrimaryKeys

主なキーの概要

DynamoDBのキー・インデックスについてまとめてみた - Qiita

DinamoDBのKeyにはまず代表的なものが3つ存在する。

  1. Partition Key
  2. Sort Key
  3. Primary Key

Partition Keyは、RDBのパーティションのようなものでDynamoDBのうちどのテーブルに所属するかを決定し、レコード間で一意である必要はない。DynamoDBでは原則テーブルは単一とすることを推奨している。しかし非常に高いパフォーマンスが求められる環境では各テーブル毎に均等にレコードが配置されるような設計にしないと、IOが一つのテーブルに集中し性能劣化をもたらす。

従って、各レコードでパーティションキーは均等に分散されることが望ましい。

Sort Keyの設定は任意である。自分で決定しなくてもDynamoDB側で勝手に設定してくれるらしい。SortKeyの値順にテーブルにレコードが並べられるので、一緒に取得したいレコード同士が近くなるようにSortKeyを設計しておくと性能を向上できる可能性がある。

Primary Keyはレコードを(テーブル間)グローバルに一意とするKeyである。Partition KeyとSort Keyによる複合主キーなので、ユーザーが自分で設定するものではない。

時系列データの格納

時系列データの格納では、特別なBestPracticeをAWS側が提供している。

本来高いパフォーマンスを要求される環境では、レコードが分散するようにテーブルを分割するのが望ましいとしていた。 しかし時系列データベースを扱うときに限っては、時間をPartition Keyとしてレコードを分散する設計としている。

Best Practices for Handling Time Series Data in DynamoDB - Amazon DynamoDB

Amazon DynamoDB recommend that you keep the number of tables you use to a minimum. For most applications, a single table is all you need. However, for time series data, you can often best handle it by using one table per application per period.

これでは常に一つのテーブルに対する書込(と、直近のデータが頻繁に参照されるような環境では読取)が一つのテーブルに集中することになり性能劣化が心配される(実際そのような高パフォーマンスが要求されると、この設計は使えない)。

しかしテーブルごとにRCU/WCUを変更して直近のデータを格納するテーブルの性能を大幅に向上させ、古いデータが格納されたテーブルへのIO性能を最小限にすることでコスト削減につなげている。

The idea is to allocate the required resources for the current period that will experience the highest volume of traffic and scale down provisioning for older tables that are not used actively, therefore saving costs.