AWSサービスの機能を調べる（Databases）
皆さんは、AWSクラウドが持つ機能を調べるとき、どうしていますか？
また、使おうと考えているサービスの仕様をどのように調べていますか？
私はこのところ、AWSサービスの機能のホントのところを確認するために、AWS公式ホームページの「AWSサービス別資料」で確認を取っています。
（資料には、SlideShare 、PDF 、Youtube があります）
ちまたのインターネットでの技術ネタを調べることも過去多かったのですが、情報の鮮度もありますし、やっぱり本家の情報がしっくりと安心できます！！
今回は、この画面の左にあるカテゴリー分けから「Compute」を選んだときに、各資料にはどのような情報が含まれているかを箇条書きにします。（99-99 形式の数字はページを表します）
Databasesカテゴリ
●●●資料【01_DocumentDB(MongoDB).pdf】
45Page 何故シャーディングが必要ない？
54Page MongoDBとの互換性
55-58 セキュリティ：データベース認証、暗号化（VPC：パブリックエンドポイントは現状作れない）、
監査ログ、モニタリング
61-62 使い分け(RDS、DynamoDB）
63-67 移行方法：ダンプツール、Database Migration Serviceとダンプのハイブリッド、DMSのみ
69-71 料金体系
●●●資料【02_DynamoDB.pdf】
結果整合性モデル採用による可用性向上：
DynamoDBは2箇所を書き込んだ時点で「書き込みOK」という返答をします。
残り1箇所は「そのうち時間が経てば(DynamoDBの場合は1秒以内)結果的に書き込まれる」
という考え方です。 これを「結果整合性」と言います。
読み取り時には3箇所に書き込まれているデータのどこから読み取るかはわからないので、
書き込まれていないデータからは読み取れないことになりますし、更新前のデータからは
古いデータが読み取れてしまいます。
ConsistentReadオプション(読み取り一貫性)とはこのような読み取りによる差がないことを
保証するもので、スキャン時にこのオプションをつけることでスキャン前に登録、変更
された値は確実に読み取る事ができます。
具体的には書き込まれている3箇所より2箇所の値を読み取り、一致すればその値を、一致
しなければもう1箇所の値を読んで、2箇所に書き込まれている値を返すという仕組み
になります。Capacity Unitを２倍消費する。
52Page
Filter式による結果の絞込 – 2個目 Query、Scanの１MBの制限？ (→17、52Page)
56Page
隠れている文字：1ユーザでN個のゲームをプレイしている場合
66Page
Indexにコピーする属性を定義？
72Page
TTL→自動的に削除できるタイミングを定義
・追加料金なしで提供
・既存・新規のテーブルに設定可能
・ DynamoDB Streamsとの併用可能
・TTLを有効化する前に項目を確認できる。
・最大48時間削除まで掛かる。期限切れを読み取らないようにするには、
Queryを利用するか、アプリ側フィルタ処理が必要。
78Page
・リクエストが減った時に自動的に容量を縮小してコストを削減（下から２番目）
→CapacityUnit値わかるか？
→43Page Capacity変更時の注意事項：「キャパシティエラーを起こしやすい状態」
81Page
Auto Scalling：上げる回数の上限は無いが下げる回数は現在最大一日9回
83Page
DynamoDB Accelerator (DAX)
リージョン内でマルチAZ構成かつキャッシュ情報のレプリケーション、
障害時のフェイルオーバーなどをフルマネージドで実現
111Page
DynamoDB Streams
・DynamoDBに行われた追加、更新、削除の変更履歴を保持しとりだし可能
・過去 24 時間以内にそのテーブルのデータに対して行われた変更のストリーム
すべてにアクセス可能。
・24時間経過したストリームデータは、その後、消去される
・DynamoDB Streams の容量は自動的に管理
114Page
・クロスリージョンレプリケーション(→124Page)
・ゲームやソーシャルサイト等のユーザの集計、分析、解析のための非同期集計
・ユーザーが新しい写真をアップロードするとすぐにサークル内友人のモバイルデバイスに
自動通知するモバイルアプリケーションの構築等
120Page
DynamoDB Triggers
・AWS Lambda：
S3、Kinesis、SNS等でのイベント発生を元にユーザが用意したコード（Node.js、Java）を実行
ユーザアプリからの同期/非同期呼び出し
・DynamoDBへの書き込みに応じて値チェックをしつつ別テーブルの更新やプッシュ通知を実行
・DynamoDBの更新状況の監査ログをS3に保存
・ゲームデータなどのランキング集計を非同期に実施
124Page
DynamoDBクロスリージョンレプリケーション(オープンソース、独自組み込み可)
・DRとして利用：複数リージョンへ複製で、データセンター障害時、他リージョンへ切替可能
・速いリード：複数リージョンで運営時、最も近いリージョンからテーブルを読み取り可能
・RR：テーブル全体の読取作業負荷を分散するレプリカでマスター表リードキャパシティを節約
・リージョンマイグレーション：新リージョンにリードレプリカを作成し、マスターデータを
レプリケーションし、システム移行できる
140Page
DynamoDBデータのバックアップ、レプリカ
１．DynamoDB Streamsを用いたクロスリージョンレプリケーション：
一時的にレプリケーションをStopさせて、PITRバックアップを実現
２．AWS Data Pipelineを使ったデータバックアップ
→ 別リージョン、同一リージョンのテーブルにコピー、選択Attributeのみコピー
& Incrementalコピーのジョブ実行可能
３．Amazon Elastic MapReduceを使ったコピー：
S3や別のDynamoDBに、Amazon Elastic MapReduceのhiveを使ってデータをコピー
143Page
DynamoDB Local： 開発/テスト用のツール
・JARファイルで提供され、ローカルにインストールして動かすことができる(要Java7以上)
・DynamoDB Streamsも利用可能
・ウェブベース(DynamoDB JavaScript Shell)のUIも利用可能
・あくまでAPIの機能的を再現しているテストツールなので本番では利用しない
●●●資料【03_DynamoDB Advanced Design Pattern.pdf】
20Page からチェック！！
●●●資料【04_ElastiCache】
14Page Amazon ElastiCache for memcached
15Page Memcached アクセス用のClient Libraryの提供
（通常アクセス用Client Library Auto Discovery用Client Library）
16Page Auto Discovery for memcached
17Page ElastiCache for Redis
18-19 Amazon による Redis 拡張
20Page Redis アクセス用のClient Library
21-22 リードレプリカ (Replication)
23Page フェイルオーバ
24Page バックアップ／リストア
26Page CloudWatchによるElastiCacheの監視
●アップデート
27-38 Redis Cluster
39Page バックアップからのRedis Cluster リサイズ
40Page Redis Cluster オンラインリサイズ
41Page Redis Cluster オンラインリサイズ: スケールアウト
42Page Redis Cluster オンラインリサイズ: スケールイン
43Page Redis Cluster オンラインリサイズ: CWのアラームトリガー
44-45 セキュリティ強化
●ユースケースパターン
49Page 様々なキャッシング
50-51 NoSQL データベースのキャッシング
52Page ストリームデータ処理
53Page Redisを使ったビッグデータアーキテクチャ
54Page IoT ソリューション
55Page モバイルアプリケーション
56Page アドテクノロジーアプリケーション
57Page チャットアプリケーション
58Page リアルタイムリーダーボード
59Page Rate Limit
61Page Amazon ElastiCache の料金
62Page TCO比較(同スペックでのEC2とElastiCacheでのTCOの比較)
●●●資料【05_Neptune.pdf】
7-12 グラフとは
13-27 グラフDBとは
Amazon Neptune
30-34 グラフ処理の分類、クエリ性能、リードレプリカ、
クラウドネイティブストレージエンジンの概要、Point-in-Time リストア、セキュリティ
36Page サポートされるインターフェイス：Tinkerpop/ Gremlin RDF/SPARQL
37Page ElasticSearch Service連携、LIKE検索やfuzzy検索
41Page 事例: Zeta Global 顧客識別グラフ
43Page データの投入：
①S3上のCSVファイル → Neptune Loaderでロード
②AWS Database Migration Service → 他DBから移行
47Page CLI (Gremlin Console)
48-51 Neptune Workbench：Jupyter Notebookからクエリ実行
52-54 可視化：①OSSツールによる可視化 ②商用ツールによる可視化
55Page Tom Sawyer: ユースケース
56Page 運用ツール：GraphML 2 Neptune CSV
57Page 運用ツール：Neptune Export
●●●資料【06_RDS.pdf】
13Page
RDSの制限事項（Oracle Databaseの例）
| RDS for Oracleの制限事項 | 具体的な例 |
| ①バージョンが限定される ②キャパシティに上限がある | 11g (11.2.0.4), 12c (12.1.0.2) をサポート m4.16xl (64vCPU/256GB) or r4.16xl (64vCPU/488GB) 最大 16TBストレージ、40,000 IOPS |
| ③OSログインやファイルシステムへのアクセスができない | AWS CLIやプロシージャで代替 （例：DBMS_FILE_TRANSFER など） |
| ④ALTER SYSTEMやALTER DATABASEが使えない | ALTER SESSIONや独自プロシージャで代替 （例：rdsadmin.rdsadmin_util.disconnect など） |
| ⑤IPアドレスの固定はできない ⑥一部の機能が使えない ⑦個別パッチは適用できない | DNS名でエンドポイントに接続 RAC, ASM, DataGuard, RMANなどは使えない 四半期ごとのPSU(Patch Set Updates)として適用 |
※ トレードオフが許容できない場合は、On EC2かオンプレミスで構築
16Page
シンプルな手順で高度なアーキテクチャを実現
●マルチAZデプロイメント
同期レプリケーション・自動フェイルオーバー
● 非同期レプリケーション・リードレプリカ
スケールアップ・スケールダウン ※ストレージサイズは、拡張はできるが縮小はできない
● バックアップ（スナップショット）
25Page DBインスタンスタイプの選択
26Page DBインスタンスタイプとスペック
27Page RDSで使用できるストレージタイプ
30Page バックアップ
31Page スナップショットとリストア
32-33 スナップショットのユースケース（１）(２）
34Page スナップショットについての参考情報
※ 自動スナップショットは、DBインスタンス削除と同時に削除。
手動スナップショットは削除されない
35-37 リネーム
38Page 設定変更（パラメータグループ、オプショングループ）
39Page ソフトウェアメンテナンス
40-45 モニタリング
46Page 各種制限と緩和申請
50-51 セキュリティ
53-55 DBエンジン(MySQL)、キャッシュウォーミング
56-57 DBエンジン(Oracle)、Statspack
58Page DBエンジン(SQL Server)
59-60 DBエンジン(PostgreSQL)、拡張モジュールの例
61Page Amazon Aurora
62Page DBエンジン(MariaDB)
63Page RDS DBエンジン毎の主要機能のまとめ
65-67 料金体系
68Page Simple Monthly Calculator
69Page AWS無料利用枠
71-83 新機能
●●●資料【07_Aurora MySQL Compatible Edition ユースケース毎のスケーリング手法.pdf】
9Page Aurora を構成するコンポーネント
15Page Aurora内から、Amazon SageMaker とAmazon Comprehend を呼び出せる
16Page Database Activity Stream (DAS)：コンプライアンス/規制要件のモニタリング
17-18 Amazon RDS Proxy：
アプリケーションのスケーラビリティ、データベース障害の回復力と安全性向上
スケール
24Page サービス初期はシンプルな構成から始める
27Page スケールアップ・スケールアウトの前に考えること
28Page [参考] Performance Insights によるボトルネックの特定
32-36 リードレプリカ
37Page [参考]キャッシュレイヤの導入
40-43 データベース分割（垂直分割と水平分割、マッピングテーブル、ハッシュ＋レンジ分割）
44Page ①AWS DMS (Database Migration Service)によるデータベース分割・集約
②Aurora・Cloning機能
45-47 [参考] 用途に合わせた適切なデータベースの利用
48Page [参考] Aurora Multi-Master：もう片方のWriter接続で、書き込み可用性を継続
51-54 Aurora グローバルデータベース
57-62 Aurora Serverless
●●●資料【08_Aurora MySQL.pdf】
Page14 ディスク障害検知と修復
Page20 コストを抑えるための⼯夫
Page21 レプリケーション(Shared Multi-AZ Storage)
Page22 アダプティブスレッドプール
Page24 高速でより予測可能なフェイルオーバー時間
新機能
29-30 CloudWatchで、継続バックアップとスナップショットで使用している容量を確認可能
32Page Custom Endpoints
※ 説明ではリードレプリカを使ってしますとデータが分散されるので注意！
カスタムエンドポイントに関しては課金していない！
33Page Global Database（REPLICATION FLEET）
34-41 Aurora Serverless
42-44 Parallel Query、データベースクラスタのstop/startサポート、
Deletion Protection はYoutubeに説明ない
46-48 Performance Insights ※ 本番系ではオーバーヘッドに注意！！
49-51 Backtrack：DBごと巻き戻し
52Page OOM Avoidance (1.19以降) はYoutubeに説明ない
53Page Database cloning
54-55 Advanced Auditing はYoutubeに説明ない
56Page Amazon Aurora AuditログをAmazon CloudWatchLogsで管理
57-61 Load Data From S3、Export Data into S3、拡張モニタリング、
重要なシステム／OSメトリクスに対応
拡張モニタリングはYoutubeに説明ない
62-63 Lab mode ：今後提供予定の機能を試すことが出来る
●●●資料【09_Aurora PostgreSQL.pdf】
9Page Aurora を構成するコンポーネント はYoutubeに説明ない
11Page Aurora PostgreSQL のバージョン はYoutubeに説明ない
16-17 Amazon Aurora Continuous Backup、高速なデータ修復 はMySQL説明にない
20Page log-structured 分散ストレージシステム はMySQL説明にない
21Page Aurora リードレプリカ
23Page IO traffic in Amazon RDS for PostgreSQL はMySQL説明にない
24Page IO traffic in Aurora (データベース) はMySQL説明にない
25Page IO traffic in Aurora (ストレージノード) はMySQL説明にない
運用管理
27Page Amazon Aurora クラスター全体のライフサイクル
28Page クラスター内のインスタンスライフサイクル
29Page Auto Scaling によるレプリカの自動増減
30Page Aurora のバックアップ機能
31Page パラメーターグループによる設定
32Page DB クラスターパラメータとDB パラメータ
33-36 Performance Insights によるワークロード監視
37Page マネジメントコンソールでのメンテナンス確認と適用
38Page AWS CLI でのメンテナンス確認と適用
新機能
42Page Aurora PostgreSQL と外部のPostgreSQL でのレプリケーションが可能
43-45 Cluster Cache Management
46-47 Query Plan Management
53Page Amazon Aurora / RDS for PostgreSQL:IAM認証のサポート
54Page 厳密なパスワード管理
55Page Database Activity Stream によるリアルタイム監視（Kinesis Data Stream へプッシュ）
57Page Amazon Aurora: クラスターの停止および起動をサポート
58-59 CloudWatch Logs
●●●資料【10_Timestream.pdf】
12Page 時系列データの活用場所：①現状の傾向を知る ②これから先に起こることを予測する
16-24 Amazon Timestream 特徴
18Page コスト最適化
20Page スケーラブル
22Page 時系列専用のデータモデルと関数
アーキテクチャ概念と仕組み
28Page コンセプトと用語: テーブル (Tables)
29Page ストレージ階層の種類（インメモリ階層／マグネティック階層）
30Page ストレージ階層間のデータライフサイクル：メモリ階層
→マグネティック階層（データ移動、データ削除）
32Page コンセプトと用語: タイムシリーズ(Time-Series)：属性値毎、時系列レコードのまとまり
42Page コンセプトと用語: ディメンション (Dimensions)：識別するための属性情報セット
46Page コンセプトと用語: メジャー (Measures)：
測定値∈名前(measure_name)と値(measure_value) の単一測定値
55Page レコードの重複判定：先勝ち ↓要望により、Version番号を追加
56Page レコードの更新 ※ 後勝ち に対応できる
データベースへのアクセス方法
66-70 データ挿入
71Page データ挿入注意点①：インメモリ階層の保持期間外のデータを挿入することが出来ない。
72Page データ挿入注意点②：
保持期間変更は、以降にTimestreamへ送信されたデータのみ新保持期間が有効。
1度マグネティック階層へ挿入されたデータがインメモリ階層へ戻らない
74-83 出力クエリプロセッシング
①フラットモデルと時系列モデルの2つのデータモデルをサポート
②データはフラットモデルを使用して保存され、時系列分析には時系列モデルを使用
84-87 時系列機能 – 補間関数
88Page Adaptive Query Engineによる最適化
89Page 出力：クエリ発行 →AWS SDK / Timestream API JDBC Driver
90Page Query Editor機能
91-97 出力：分析・可視化ツール
→ ①QuickSight ②Grafana (Open Source Edition) ③Amazon SageMaker Notebook
時系列データの主なユースケース
99Page IoTデバイスから収集したデータをAWS IoT Coreルールアクション
→ Amazon Timestreamにルーティング
100Page ApacheFlink：Kinesis、AmazonMSK、ApacheKafka等streaming処理
→ Amazon Timestreamへデータ直接転送
101Page Telegraf(OSS)エージェントを監視対象リソースへインストール
→ Amazon Timestreamへデータ直接転送
運用
103Page ロギングとモニタリング：①CloudWatch ②CloudTrail
104Page 可用性・耐障害性：リージョン内複数AZ構成でデータレプリケーションや
障害時フェイルオーバー、クォーラムベース
105Page バックアップ・リストア：
自動復旧リストアで手動バックアップやリストア機能は提供されていない
106Page パフォーマンスとチューニング
108Page Timestream の価格設定
109Page 料金計算ツール
123Page データベース・テーブル設計時の考慮ポイント
