Más contenido relacionado La actualidad más candente (20) Aurora2. はじめに
o Amazon Auroraは、2014年11月の Amazon
re:Inventで発表された、注目すべき新しいタイ
プのクラウド・データベースである。
o 小論では、第一部でAuroraの概要を述べ、第二
部でその技術的中核であるLog Structured
File Systemについて見ていく。
o Appendixに、AmazonのWebサイトで提供され
ているAurora情報をまとめておいた。小論とあ
わせて、この新しい技術の理解が深まることを期
待している。
3. Agenda Part I
Amazon Aurora
o Replay
“Re-imagining Relational Database”
o Amazon Aurora
n Non-Monolithic
n Scalability
n Availability
o Question?
4. Agenda Part II
Log-Structured File System
o Log-Structured File System
o log-structured Database
o Cache, Log and File System
o SSD File System
16. Amazon Aurora
-- 新しいRDBMSをあらためて想像しよう --
l サービス指向のアプローチを使って、再発明された
リレーショナル・データベース
l データベースのレイヤーを、scale outさせ、マルチ・
テナントにしよう -- まず、ストレージから始める
l MySQL 5.6 との、そのままのコンパティビリティを
維持する -- 既存のアプリがそのまま動くように
17. Amazon Aurora
l データベースに適用されたサービス
指向アーキテクチャー
l ログとストレージのレイヤーを、マルチ
テナントで、scale outする、データ
ベースに最適化されたストレージ・サー
ビスに移動する
l Amazon EC2, Amazon VPC,
Amazon DynamoDB, Amazon SWF,
Amazon Route 53 といった他のAWS
のサービスと統合する
l 連続的なバックアップのために、Amazon
S3 と統合する
18. Amazon Auroraは高い可用性を持つ
l デフォールトで高可用性
l 3つのAZをまたいだ6通り
のレプリカ
l 4/6の書き込みQuorum
l 1つのAZが使えなく
なれば自動的に3/4に
l 3/6の読み込みQuorum
l SSD, Scale out,
Multi-tenantストレージ
l シームレスなストレージ
のScalability
l 64T byte までのデータ
ベース・サイズ
l 利用したものにだけ課金
l Log-Structured Storage
l 多くの小さなセグメントが、自身のredoログを持つ
l ログページがデータページを生成するのに利用される
l データベースとストレージのがたつきをなくす
21. Amazon Auroraのレプリカは、
ただちに、増設できる
MySQL Read Scaling
l レプリカはログを再生しなければならない
l それはマスターに負荷をかける
l レプリカ作成の遅延は、非確定的に増大
する
l フェール・オーバーは、データの消失を引
き起こす
シングル・スレ
ッドでbinlogを
適用
ページキャッ
シュの無効化
Amazon Aurora Read Scaling
l レプリカはログを再生しない
l マスターにほとんど負荷をかけないで、15
台までのレプリカを増設できる
l レプリカの遅延は、10ms 程度
l レプリカとマスターは、同じストレージを共
有しているので、フェール・オーバーは、
データの消失を引き起こさない
41. Amazon RDS
o Amazon RDSは、これまで次の4つのデータ
ベースに対してサービスが提供されている。
n Amazon RDS for MySQL
n Amazon RDS for Oracle
n Amazon RDS for SQL Server
n Amazon RDS for PostgreSQL
o Amazon RDS for Auroraは、Amazon RDS
の5番目の利用例となる。
o 利用できるサービスの詳細は、各データベース・
エンジンごとに異なるのだが、多くの場合、次のよ
うなサービスを提供している。
42. Amazon RDS
o パラメータの事前設定
o メトリックスの提供とモニタリング
o ソフトウェアの自動パッチ適用
o 自動バックアップ DB
o スナップショット
o 複数アベイラビリティゾーン(マルチ AZ)配置
o 汎用/プロビジョンド IOPS(SSD)ストレージの
提供
43. 「オーロラは雲の上」
Amazon RDS for Aurora
o Auroraのクラウド・サービスの利用は、もっと踏
み込んだものだ。
o データベースの諸機能のうち、CacheとLogging
の機能を切り出し、Loggingとクラウドのストレー
ジ機能と一体なものにして、新しいクラウド・デー
タベースのサービスを作った。それが、Amazon
RDS for Auroraである。文字通り、「Auroraは
雲の上」なのである。
44. Auroraを構成する基本的サービス群
o Amazon Relational Database Service
(RDS)
o SQL + Transaction Engine
o Cache Service
DBプロセスとは独立のキャッシュ・サービス
o Log-Structured Storage Service
ログとストレージのレイヤーを、マルチテナントで、
Scale outする、データベースに最適化されたス
トレージ・サービスに移動したもの
o Amazon S3
47. Amazon RDS for MySQL
のキャッシュ
o “14.13.1.5 Preloading the InnoDB Buffer
Pool for Faster Restart”
http://bit.ly/19tkg6y
o To avoid a lengthy warmup period after
restarting the server, particularly for
instances with large InnoDB buffer pools,
you can save the InnoDB buffer pool
state at server shutdown and restore
the buffer pool to the same state at
server startup.
Warmupには、Shutdown時にBuffer Poolを取得しておく必要が有る
48. Amazon Aurora DB クラスター
Aurora DB Clusterは、データベースのクラスター
構成で一般的な Shared Nothing のクラスターで
はない。データの読み書きが非対称であることが特徴
のシンプルな構成。鍵は、Log-Structured File
Systemを採用した、Cluster Volumeにある。
データベース・アクセスの現状とCPUが高速になり巨
大なメモリーが使える技術のもとでは、コスト・パ
フォーマンスに優れた、現実的な選択だと思う。
50. Amazon Aurora DB クラスター
o DB クラスターは、1 つ以上のインスタンスと、こ
れらのインスタンスのデータを管理する 1 つの
Cluster Volumeで構成される。
(Cache層は?)
o Aurora Cluster Volumeは、複数のアベイラ
ビリティーゾーン(AZ)にまたがる仮想データベー
スストレージボリュームである。各AZにはクラス
ターデータのコピーが格納される。
51. DBクラスターを構成する
二つのインスタンス
o プライマリインスタンス – 読み取り/書き込みワー
クロードをサポートし、クラスターボリュームに対
するすべてのデータ変更を実行する。
o Aurora レプリカ – 読み取りオペレーションのみ
をサポート。各 DB クラスターは、最大 15 個の
Aurora レプリカを持つことができる。複数の
Aurora レプリカは読み取りワークロードを分散し、
別のアベイラビリティーゾーンの Aurora レプリ
カを検索することでデータベースの可用性を高め
ることもできる。(別のAZも読みに行ける)
52. クラスターエンドポイント
o 各 Aurora DB クラスターには、ユーザーが接続
できるクラスターエンドポイントがある。クラスター
エンドポイントは DB クラスターのプライマリイン
スタンスに接続する。プライマリインスタンスには、
一意のエンドポイントもある。
o プライマリインスタンスが失敗すると、クラスター
エンドポイントは、新しいプライマリインスタンスを
ポイントする。
53. Replicaの一意のエンドポイント
o Aurora DB クラスター内の各 Aurora レプリカ
には、一意のエンドポイントがある。
o クライアントが Aurora DB クラスター内の複数
の Aurora レプリカに接続するように構成して、
アプリケーションの読み取りワークロードを分散で
きる。
o 可用性の高いシナリオでは、Aurora レプリカを
複数のアベイラビリティーゾーンに配置することで、
アプリケーションは、1 つのアベイラビリティー
ゾーンで障害が発生した場合でも Aurora DB
クラスターからデータを読み取ることができる。
54. Cluster Volume
単一の論理ボリューム
o Cluster Volumeは、DB クラスターのデータ
の複数のコピーで構成されるが、Cluster
Volume内のデータは、DB クラスター内のプラ
イマリと Aurora レプリカに対する単一の論理ボ
リュームとして表される。
o この結果、すべての Aurora レプリカは、最小限
のレプリカ・ラグでクエリの結果として同じデータを
返す。レプリカ・ラグは、通常はプライマリインスタ
ンスが更新を書き込んだ後、100 ミリ秒未満。
(レプリカ・ラグは、データベースの変更レートに
よって異なる。)・
55. Cluster VolumeとReplica
o Cluster Volumeは DB クラスター内のすべ
てのインスタンスで共有されるため、Aurora レプ
リカごとにデータのコピーをレプリケートする追加
作業は必要ない。
o 対照的に、MySQL のリードレプリカは、単一ス
レッド上で、マスター DB インスタンスからローカ
ルデータストアに対するすべての書き込みオペ
レーションを再生する必要があるため、大量の読
み取りトラフィックをサポートする MySQL リード
レプリカの能力に影響を与える可能性がある。
57. AuroraのScalability
o Push-button Compute Scaling:
コンソール画面で数クリックするだけで、CPU数・
メモリーサイズをスケール・アップ/スケール・ダ
ウン出来る。所要時間は、数分。
o Storage Auto-scaling:
Auroraでは、ストレージ容量を指定する必要は
ない。最初10Gのストレージが割り当てられ、以
降、必要に応じて、自動的に10G単位で容量は
増えていく。ユーザーは、ストレージの容量を意
識する必要はない。最終的には、64Tまで拡張可
能である。
61. Replicaによる
読み取りのスケーリング
o Aurora DB クラスターの読み取りのスケーリン
グは、最大 15 個の Aurora レプリカを DB クラ
スター内に作成することで実現する。
o 各 Aurora レプリカは、最小限のレプリカ・ラグで
クラスターボリュームから同じデータを返す。通常、
このラグはプライマリインスタンスが更新を書き込
んだ後、100 ミリ秒を大幅に下まわる。
o 読み取りトラフィックが増えたら、追加の Aurora
レプリカを作成し、それらに直接接続することで
DB クラスターの読み取りワークロードを分散す
る。
62. Amazon RDS for MySQLでの
リードレプリカ
o ソース DB インスタンスに加えられた更新は、
リードレプリカに非同期的にコピーされる。
o 読み込みクエリをアプリケーションからリードレプ
リカにルーティングすることにより、ソース DB イ
ンスタンスへの負荷を減らすことができる。リード
レプリカを使うと、読み込み負荷の高いデータ
ベースワークロードに単一 DB インスタンスの能
力が対応しきれない場合に、弾力的にスケール
アウトできる。
63. Amazon RDS for MySQLでの
リードレプリカ
o リードレプリカを作成したら、最初に既存の DB
インスタンスをソースとして指定する。Amazon
RDS がソースインスタンスのスナップショットを取
得し、スナップショットから読み取り専用インスタン
スを作成する。
o 次に、Amazon RDS は、ソース DB インスタン
スの変更がある場合は必ず、DB エンジンの非
同期レプリケーションを使用してリードレプリカを
更新する。Amazon RDS は、ソース DB インス
タンスのすべてのデータベースをレプリケートする。
67. Amazon Auroraは高い可用性を持つ
l デフォールトで高可用性
l 3つのAZをまたいだ6通り
のレプリカ
l 4/6の書き込みQuorum
l 1つのAZが使えなく
なれば自動的に3/4に
l 3/6の読み込みQuorum
l SSD, Scale out,
Multi-tenantストレージ
l シームレスなストレージ
のScalability
l 64T byte までのデータ
ベース・サイズ
l 利用したものにだけ課金
l Log-Structured Storage
l 多くの小さなセグメントが、自身のredoログを持つ
l ログページがデータページを生成するのに利用される
l データベースとストレージのがたつきをなくす
68. Aurora DB クラスターの耐障害性
o Cluster Volumeは 1つのリージョン内の複数
のアベイラビリティーゾーンにまたがり、各アベイ
ラビリティーゾーンにはCluster Volumeデータ
のコピーが含まれる。
o DB クラスターは、データ損失なしでアベイラビリ
ティーゾーンの障害に耐えることができ、発生す
るのはサービスの短時間の中断のみである。
http://amzn.to/1C6vzw4
70. プライマリインスタンスの
フェールオーバー
o DB クラスターに Aurora レプリカが含まれてい
ない場合は、プライマリインスタンスが再作成され
る。その間例外によって読み取りと書き込みオペ
レーションが失敗する。新しいプライマリインスタ
ンスが再作成されまでの時間は、通常は 10 分
未満。
o Aurora クラスターボリュームは複数のアベイラ
ビリティーゾーンにわたっているため、この場合で
も、データは保持される。
71. プライマリインスタンスの
フェールオーバー
o DB クラスターに 1 つ以上の Aurora レプリカ
がある場合は、障害発生中に 1 つの Aurora レ
プリカがプライマリインスタンスに昇格される。
o 短時間の中断が発生するが、レプリカのプライマ
リインスタンスへの昇格は、新しいプライマリイン
スタンスの作成よりもはるかに短時間で実行され、
一般的なサービスの復元時間は 120 秒未満、
多くの場合 60 秒未満で復元される。
o DB クラスターの可用性を高めるために、複数の
アベイラビリティーゾーン内の 1 つ以上の
Aurora レプリカを作成することが勧められる。
72. Amazon RDS for MySQLでの
リードレプリカのインスタンスへの昇格
o リードレプリカソース DB インスタンスへのトランザ
クションの書き込みを停止し、すべての更新がリー
ドレプリカに加えられるまで待つ。
o データベース更新は、ソース DB インスタンスで行
われた後にリードレプリカで行われるため、このレ
プリケーションは大幅に遅延する場合がある。
o Amazon RDS コンソールの [Promote Read
Replica] オプション、CLI コマンドrds-promote-
read-replica、または
PromoteReadReplica API 操作を使用して、
リードレプリカを昇格させる。
75. バックアップ
o Aurora は、Cluster Volumeを自動的にバック
アップし、バックアップ保持期間分の復元データを
保持できる。
o Aurora のバックアップは継続的かつ増分的であ
るため、バックアップ保持期間の任意の時点にす
ばやく復元できる。
o バックアップデータが書き込まれるときに、データ
ベースサービスのパフォーマンスに影響が出たり、
中断が発生したりすることはない。DB クラスター
を作成または変更するときに、バックアップ保持
期間(1~35 日)を指定できる。
77. データの復元
o Aurora が保持するバックアップデータから新し
い Aurora DB クラスターを作成することで、
データを回復できる。DB クラスターの新しいコ
ピーは、バックアップ保持期間の任意の時点にす
ばやく復元できる。
o 保存した DB クラスターのスナップショットから復
元することもできる。バックアップ保持期間中の
Aurora バックアップが継続的かつ増分的である
ことは、復元時間を短縮するためにデータのス
ナップショットを頻繁に作成する必要がないことを
意味する。
79. Latest Restorable Time と
Earliest Restorable Time
o DB インスタンスの最新または最も早い復元可能
時間を判断するには、RDS コンソールでLatest
Restorable Time 値または Earliest
Restorable Time 値を探す。
o DB クラスターの最新の復元可能時間は、DB ク
ラスターを復元できる最も直近の時点であり、通
常は現在時間の 5 分以内である。
o 最も早い復元時間は、クラスターボリュームを
バックアップ保持期間内でどこまで遡って復元で
きるかを示す。
84. Amazon Aurora DB クラスター
Cluster Volume
Data Copy Data Copy Data Copy
AZ内で、Data Copy
AZを超えて、MasterがReplicaに書き込む?
85. Amazon Auroraは高い可用性を持つ
l デフォールトで高可用性
l 3つのAZをまたいだ6通り
のレプリカ
l 4/6の書き込みQuorum
l 1つのAZが使えなく
なれば自動的に3/4に
l 3/6の読み込みQuorum
l SSD, Scale out,
Multi-tenantストレージ
l シームレスなストレージ
のScalability
l 64T byte までのデータ
ベース・サイズ
l 利用したものにだけ課金
l Log-Structured Strage
l 多くの小さなセグメントが、自身のredoログを持つ
l ログページがデータページを生成するのに利用される
l データベースとストレージのがたつきをなくす
4/6の書き込みQuorum ?
3/6の読み込みQuorum ?
Disk内のSegmentが、異なって
いるので、この図は、Replicaの図
ではない。
89. Availability
o ストレージは自動的に3つのAWS アベイラビリ
ティゾーン (AZs)内に複製され、さらに各AZ内で
2つのコピーを作成する。
o 6つのディスクの内少なくとも4つのディスクに書き
込みが完了するとすぐに次の処理を実行する。
「Amazon Web Services ブログ」
http://bit.ly/1BF8Kux
o 2つのディスク障害までは書き込みは継続し、3つ
のディスクが障害を起こしても読み込み処理を続
ける。
90. 「データベースに障害が発生した場合 ….」
o 「Amazon Aurora は自動的に 3 つのアベイラ
ビリティーゾーンにかけて 6 個のデータコピーを保
持するため、正常なアベイラビリティーゾーンで
データ損失のないデータベースを自動的にレプリ
ケーションします。」
「Amazon RDS for Aurora についてよくある質問」
http://amzn.to/1CBNFbr
92. Data Copy2 Data Copy2 Data Copy2
Data Copy1
Data Copy1
Cluster Volume
Replicaの作成は、Primary Instance
の仕事ではなく、Cacheとの間でCluster
Volume自身が行うのだろう。
Data Copyは、Disk単位ではなく
Segment 単位に行えばいい。
94. Amazon Auroraは高い可用性を持つ
l デフォールトで高可用性
l 3つのAZをまたいだ6通り
のレプリカ
l 4/6の書き込みQuorum
l 1つのAZが使えなく
なれば自動的に3/4に
l 3/6の読み込みQuorum
l SSD, Scale out,
Multi-tenantストレージ
l シームレスなストレージ
のScalability
l 64T byte までのデータ
ベース・サイズ
l 利用したものにだけ課金
l Log-Structured Strage
l 多くの小さなセグメントが、自身のredoログを持つ
l ログページがデータページを生成するのに利用される
l データベースとストレージのがたつきをなくす
l多くの小さなセグメントが、
自身のredoログを持つ?
lログページがデータページを
生成するのに利用される?
96. Q: Amazon Aurora はディスク障害に対するデー
タベースの耐障害性をどのように向上しますか?
o Amazon Aurora はデータベースボリュームを自動で
10 GB のセグメントに分割し、多数のディスクに分散しま
す。各 10 GB 単位のデータベースボリュームが、3 つの
アベイラビリティーゾーンにかけて 6 個レプリケーションさ
れます。Amazon Aurora は最大 2 つまでのデータの
コピー損失をデータベースの書き込み能力に影響せずに
透過的に処理し、最大 3 つまでのコピー損失を読み込み
能力に影響せずに処理します。
「Amazon RDS for Aurora についてよくある質問」
http://amzn.to/1CBNFbr
次のPart II で、そのメカニズムは詳しく見ることにしよう。
97. Amazon Aurora
l データベースに適用されたサービス
指向アーキテクチャー
l ログとストレージのレイヤーを、マルチ
テナントで、scale outする、データ
ベースに最適化されたストレージ・サー
ビスに移動する
l Amazon EC2, Amazon VPC,
Amazon DynamoDB, Amazon SWF,
Amazon Route 53 といった他のAWS
のサービスと統合する
l 連続的なバックアップのために、Amazon
S3 と統合する
S3への「連続的なバックアップ」?
102. Log-structured File System
とは何か?
o Logでは、ファイルへの書き出しは、常に、ファイ
ル末尾への追加である。Log-structured File
Systemは、これと同じように、ファイル・システム
への書き出しが、常に、ストレージの「末尾」への
追加であるように、ファイル・システムを構築しよ
うとする。
o このアイデアは、新しいものではない。25年近く
昔の論文に、こうしたアイデア(1988年)と実装
例(1991年)がある。
103. Log-structured File Systemの
アイデアの背景
o 「ほとんどのファイル・システムは、最近アクセスさ
れたブロックを保持する、大きなメモリー・キャッ
シュを持っている。だから、ほとんどのRead は、
キャッシュで解決できる。ディスクから見ると、ディ
スクのトラフィックの大部分はWriteトラフィックで
ある。ディスクI/Oを高速化するために は、
Writeの高速化が重要である。」
104. Log-structured File Systemの
アイデアの背景
o 「しかしディスクのパフォーマンスは、最終的には、
ディスク・ヘッドの移動によって制限される。現在
のファイル・システムでは、ブロックの追加に は、
ファイルとメタデータへの書き出しを含めて、数回
のWriteが必要である。そのためには、ヘッドの
移動を伴う数回のシークが必要になるのだが、こ
れには、非常に時間がかかる。」
105. Log-structured File Systemの
アイデアの背景
o 「いい代案がある。それは、ディスクをログとして
使うことだ。ログは、先頭(末尾でもいいのだが)
だけに、書き込みが行われるデータ構造だ。もし
も、ディスクがログとして管理できるなら、ヘッドの
シークがなくなるので、極めて効率的になる。
「ファイル」は常に、シーケンシャルに追加される。
キャッ シュ上で、新しいデータは、inodeや
directory等のメタデータと、一緒にまとめて、大
きなブロックに書き出せばいい。これで、ディスク
のスループットは、大幅に向上するはず。」
110. A A’ A’’MA MA’ MA’’
Checkpoint region
inode mapへのindex
logとは、別の固定領域に置かれる
Checkpoint Region
Checkpoint Regionで、inode map MA’’’を選べば、Foo’と
Barの値が得られるが、inode map MA’を選べば、Barとともに
古いFooの値が復元できる。
113. THE DESIGN AND IMPLEMENTATION
OF A LOG-STRUCTURED
FILE SYSTEM
M. Rosenblum and J. K. Ousterhout
University of California, Berkeley
ACM SIGOPS Operating Systems Review
1991年 http://bit.ly/1LmyTJx
121. Problems with Existing File
Systems
o For example, the Berkeley Unix fast file system
…. takes at least five separate disk 1/0s, each
preceded by a seek, to create a new file in Unix
FFS: two different accesses to the file’s
attributes plus one access each for the file’s
data, the directory’s data, and the directory’s
attributes. When writing small files in such a
system, less than 5% of the disk’s potential
bandwidth is used for new data; the rest of the
time is spent seeking.
Unixのファイルシステムでは、最低5回のdisk i/Oがあり、それに先立って
seekが行われる。結局、ディスクの帯域の5%しか新しいデータのために使
われていない。残りは、seekingに費やされる
122. Problems with Existing File
Systems
o The second problem with current file systems
is that they tend to write synchronously: the
application must wait for the write to complete,
rather than continuing while the write is
handled in the background. For example even
though Unix FFS writes file data blocks
asynchronously, file system metadata
structures such as directories and inodes are
written synchronously.
現在のファイル・システムでは、書き込みが同期的に行われている。Unix
FSSでは、データブロックの書き込みは、非同期的に行われるが、ディレク
トリーやi-nodeの書き込みは同期的に行われている。
128. Index の構造
o Inode map は、それぞれの i-node の位
置情報を保持する
n ブロックはディスク上の様々な位置にある
n アクティブなブロックは、メイン・メモリーにキャッシュ
される
o それぞれのディスクの固定のcheckpoint
region は、全ての inode map のブロック
のアドレスを含んでいる
131. 空きスペースを固定長のセグメントへ
の分割で管理するためのデータ構造
o Segment summary: segmentの中身
(ファイルの数、それぞれのブロックのoffset等)
を同定する Logの中に置かれる
o Segment usage table: segmentに残さ
れている利用可能なバイト数を数え、segment
中のデータの最終書き込み時刻を格納する
Logの中に置かれる
o Superblock: segmentの数やsegmentの
サイズのような、静的な構成情報を保持する 固
定領域に置かれる
http://stanford.io/1aRpQA8
148. Crash recovery (I)
o checkpoints を利用する
n 全てのファイルシステムの構造が、整合的で完全
であるログの中の場所
o Sprite LFS は、定期的な間隔で、あるいは、
ファイルシステムがアンマウントかシャットダウ
ンした時に、checkpoint を実行する
o Checkpoint region が、特別の固定した
位置に書き出される。それは、i-node map
中の全てのブロックのアドレスと segment
usage tableを含んでいる
149. Crash recovery (II)
o 一番最後の checkpoint を復元すると、最近
書き込まれた多くのデータブロックに失う
o Sprite LFS には、roll-forwardがある
n システムがクラッシュの後、再起動された時、最後
のcheckpoint の後に書き込まれたログ・セグメ
ントをスキャンする
n summary blockが、新しい i-node があること
を示していれば、Sprite LFS はその i-node
mapを更新する
151. directory operation log
o To restore consistency between directories and
inodes, Sprite LFS outputs a special record in the
log for each directory change. The record
includes an operation code (create, link, rename
or unlink), the location of the directory entry (i-
number for the directory and the position within
the directory), the contents of the directory
entry (name and i-number), and the new
reference count for the inode named in the entry.
These records are collectively called the directory
operation log; Sprite LFS guarantees that each
directory operation log entry appears in the log
before the corresponding directory block or
inode.
154. Abstract
o Research results show that while LogStructured
File Systems (LFS) offer the potential for
dramatically improved file system performance,
the cleaner can seriously degrade performance,
by as much as 40% in transaction processing
workloads [9]. Our goal is to examine trace
data from live file systems and use those to
derive simple heuristics that will permit the
cleaner to run without interfering with normal
file access. Our results show that trivial
heuristics perform very well, allowing 97% of
all cleaning on the most heavily loaded system
we studied to be done in the background.
155. The two traces depict
FFS and LFS processing
cycles. Both systems
are writing the same
amount of data, but
FFS must issue its
writes synchronously,
resulting in a much
longer total execution
time. LFS issues its
write asynchronously
and cleans during
processing periods,
thus achieving much
shorter total execution
time.
LFSでは、writeが非同期に実行され、かつ、処理期間中にクリーニング
が実行されるので、トータルの実行時間は短くなる。
159. Garbage Collection
の対象は、柔軟に選べる
o Log-structure FSのアプローチは、他のファイルシステ
ムに対して、幾つか有利な点がある。まず、一番古い
segmentを最初に消去するよう制限されているわけでは
ないということだ。例えば、もし、中間のsegmentがほと
んど空だったら、代わりに、そのsegmentをGCすること
を選ぶことができる。このことは、長い期間同じままにとど
まるようなデータや繰り返し上書きされるようなデータを持
つデータベースには特に役に立つ。我々は、同一の修正
されていないデータを書き換えるのに、多くの時間をかけ
るのは望んでいない。我々は、GCがいつ起きるのかを
もっと柔軟に決められる。通常は、GCが起きる前に、
segmentが大部分古いものになるまで待つことができる。
さらに、行わなければいけない仕事の量を最小にできる。
164. ロックのない読み出しが可能
o 我々は、この問題を、Multiversion Concurrency
Control, MVCCで克服できる。ノードがデータベースか
ら読み込みをしたい時、現在のルートのIndexノードを調
べて、 それをこのトランザクションのアラームとして使う。
o 既存のデータは、log-basedなストレージでは修正される
ことはないので、そのプロセスは、それが処理の権限を得
た時点でのデータベースのスナップショットを得ることにな
る。並行して走るトランザクションは、そのデータベースの
viewに、全く影響を与えることはない。こうして、ロックの
ない読み出しが可能になる!
Snapshot Isolation !
168. Cache, Log and File System
2006年 Google: BigTable
http://bit.ly/1BgmxYs
2011年 Google: LevelDB
http://bit.ly/1943U47
170. Tabletの表現 / SSTable
Write Buffer in Memory
Random-Access
Append–Only Log
on GFS
SSTable
on GFS
SSTable
on GFS
SSTable
on GFS
mmap
…
Tablet
172. Tablet Serving
write operation
o 書き込みの操作がtabletサーバに届くと、
サーバは、そのリクエストの形式と権限を
チェックする。
o 権限チェックは、Chubbyファイルの権限を持
つ書き手のリストを読むことで行われる。
o 正当な書き込みは、コミットlogに書き込まれ
る。
o 書き込みがコミットされてから、その中身が
memtableに挿入される。
173. Tablet Serving
Read Operation
o 読み出しの要求がtabletサーバに届くと、同
様に、形式と権限がチェックされる。
o チェックされた正当な読み出しは、SSTable
の並びとmemtableのマージしたviewの中
で実行される。
o SSTableもmemtableも、辞書式順にソート
されたデータ構造であるので、マージは効率
的に行われる。
177. LevelDB: SSTables and Log
Structured Merge Trees
o On-disk SSTable indexes are always
loaded into memory
o All writes go directly to
the MemTable index
o Reads check the MemTable first and
then the SSTable indexes
o Periodically, the MemTable is flushed to
disk as an SSTable
o Periodically, on-disk SSTables are
"collapsed together”
http://bit.ly/18tMGf9
182. Write Ahead Log
o Facebookのシステムで、スケータビリティと信頼
性に取って、本質的に重要な特徴は、WAL
write ahead logである。 おこると想定される操
作のログ。
o キーに基づいて、データは、リージョン・サーバに
分割される。
o データは、まず最初に、WAL に書き出される。
183. Write Ahead Log
o データはメモリーにおかれ、ある時点で、あるい
は、十分なデータが集積したら、ディスクにフラッ
シュされる。
o もしも、マシンが倒れたら、WALからデータを再
生できる。
o ログとメモリー内ストレージを組み合わせて利用
することで、極めて高レートのIOを、確実にハン
ドルできる。
187. NAND型Flash Memoryと
Block Copy
o 「NANDメモリは、書き込み/読み出しを「ページ」と呼ば
れる単位で行なうが、消去は、複数のページをまとめた
「ブロック」という単位で行なう。また、データの上書きが行
なえないため、ページ内のデータを変更するときは、その
ページを含むブロック全体のデータを空きのあるブロック
に待避させ、消去を行なった後に、変更したデータととも
にブロック全体を書き戻すという「ブロックコピー」と呼ばれ
る処理を行なう必要がある。つまり、NANDメモリでは、わ
ずかなデータの変更のために、より多くのデータを書き込
まなければならないというムダが発生するのだ。」
「SSD完全攻略マニュアル」
http://www.dosv.jp/other/0910/02.htm
188. NAND型Flash Memoryと
Block Copy
o 「ウェアレベリングは、このようにムダな書き込みが発生す
るNANDメモリにおいて、記録エリアごとの書き換え回数
を常に監視し、その情報を管理することで同じエリアばか
りにデータの記録が集中しないように平準化する機能だ。
また、不良ブロックの管理は、エラーが発生し、リード/ラ
イトが行なえなくなった記録領域を管理リストに登録し、二
度と使用しないようにする機能で、エラー訂正機能は、
NANDメモリに記録したデータの信頼性を確保するため
のものである。SSDの基本性能は、これらの処理を行なう
NANDコントローラで決まると言ってもよい。」
「SSD完全攻略マニュアル」
http://www.dosv.jp/other/0910/02.htm
191. Flash file system
o A flash file system is a file system designed
for storing files on flash memory–based
storage devices. While the flash file systems
are closely related to file systems in general,
they are optimized for the nature and
characteristics of flash memory (such as to
avoid write amplification), and for use in
particular operating systems.
192. While a block device layer can emulate a disk
drive so that a general-purpose file system can be
used on a flash-based storage device, this is
suboptimal for several reasons:
o Erasing blocks: flash memory blocks have to
be explicitly erased before they can be written
to. The time taken to erase blocks can be
significant, thus it is beneficial to erase unused
blocks while the device is idle.
o Random access: general-purpose file systems
are optimized to avoid disk seeks whenever
possible, due to the high cost of seeking. Flash
memory devices impose no seek latency.
o Wear leveling: flash memory devices tend to
wear out when a single block is repeatedly
overwritten; flash file systems are designed to
spread out writes evenly.
193. Flash file system と LFS
o Log-structured file systems have all
the desirable properties for a flash file
system. Such file systems
include JFFS2 and YAFFS.
194. Log-structured file systems:
There's one in every SSD
o When you say "log-structured file system,"
most storage developers will immediately think
of Ousterhout and Rosenblum's classic paper
o Linux developers might think of JFFS2, NILFS,
or LogFS, three of several modern log-
structured file systems specialized for use with
solid state devices (SSDs).
o Few people, however, will think of SSD
firmware. The flash translation layer in a
modern, full-featured SSD resembles a log-
structured file system in several important
ways.
http://lwn.net/Articles/353411/
196. Amazon RDS for Aurora
o Amazon Aurora は、MySQL と互換性のあるリレー
ショナルデータベース管理システム(RDBMS)で、高性能
の商業用データベースのスピードと可用性、そしてオープ
ンソースデータベースの簡易性とコスト効率性を併せ持っ
ています。Amazon Aurora は、MySQL の 5 倍の性
能を持ち、同様の機能や可用性を提供している商用
RDBMS の 10 分の 1 の価格です。Amazon Aurora
は、MySQL、Oracle、Microsoft SQL Server、
PostgreSQL に続く第 5 のリレーショナルデータベース
エンジンとして Amazon RDS を通してご利用いただけ
ます。Amazon RDS はプロビジョニング、パッチの適用、
バックアップ、リカバリ、障害検知、リペアなど、データベー
スのルーティンタスクを処理します。
http://amzn.to/1B72mMv
198. o Amazon Aurora はリレーショナルデータベースエンジ
ンで、高性能の商業用データベースの可用性およびス
ピードと、オープンソースデータベースのコスト効率性およ
び簡素性を併せ持っています。Amazon Aurora は同じ
ハードウェアで実行する標準の MySQL と比較して最大
5 倍のスループットを提供します。Amazon Aurora は
MySQL 5.6 と互換性を持つように設計されているため、
既存の MySQL アプリケーションおよびツールを修正す
ることなく実行できます。MySQL、Oracle、Microsoft
SQL Server、PostgreSQL に次いで、Amazon
Aurora は Amazon RDS のお客様が利用できる 5 番
目のデータベースです。
199. o Amazon RDS はプロビジョニング、パッチの適用、バッ
クアップ、リカバリ、障害検知、リペアなど、時間のかかる
タスクを処理します。使用する各 Amazon Aurora デー
タベースインスタンスに対して単純な月額方式の料金が
発生します。最低利用料金や長期契約はありません。
o Amazon Aurora は、データベースワークロード用の
SSD ベースの仮想化ストレージレイヤーとデータベース
エンジンを完全に統合することで、MySQL のパフォーマ
ンスおよび可用性を向上します。Amazon Aurora のス
トレージは耐障害性と自己修復機能を備えています。ディ
スクの障害はバックグラウンドでリペアされ、データベース
の可用性が損なわれることはありません。
200. o Amazon Aurora は自動的にデータベースのクラッシュ
を検出するように設計されており、60 秒以内に再起動し
ます。クラッシュのリカバリやデータベースキャッシュの再
構築は不要です。インスタンス全体に障害が発生した場
合、Amazon Aurora は最大 15 個のリードレプリカの
1 つに自動的にフェイルオーバーします。この処理は通
常数分で完了します。
o Amazon RDS はデータベースの運用に関する一般的な
管理タスクのほとんどを自動化し、Amazon Aurora
データベースの管理を容易にします。AWS マネジメントコ
ンソールで数回クリックするだけで、Amazon Aurora
データベースインスタンスをすばやく起動できます。
201. o Amazon Aurora はストレージを自動でスケールし、スト
レージの拡張および I/O の再分散を実行して一貫性の
あるパフォーマンスを提供します。オーバープロビジョニン
グは必要ありません。たとえば、10 GB のデータベース
を起動し、データのリサイズまたはリストライプによって可
用性を損なうことなく 64 TB まで自動的に拡張できます。
204. o セキュリティ
n 保存中と移動中の暗号化
n ネットワークの隔離
n リソースレベルのアクセス許可
o 管理性
n 使用が簡単
n 移行が簡単
n モニタリングおよびメトリクス
n ソフトウェアの自動パッチ適用
n DB イベントの通知
o 低コスト
n 実際に使用した分のみ料金が発生
205. 低ジッターで高スループット
o Amazon Aurora は、データベースエンジンが利用可能
なコンピューティング、メモリ、ネットワーキングを最大限に
活用できるようにさまざまなソフトウェアおよびハードウェ
ア技術を使用しています。I/O 操作にはクォーラムのよう
な分散型システム技術を使用し、パフォーマンスの一環性
を向上します。SysBench のような標準のベンチマーク
でテストした結果、同様のハードウェアで実行する標準の
MySQL 5.6 と比べて最大 5 倍のパフォーマンスを記録
しました。
206. ボタンを押すだけのコンピューティング
スケーリング
o Amazon RDS API を使用して、または AWS マネジメ
ントコンソールで数回クリックするだけでコンピューティン
グおよびメモリリソースをスケールし、デプロイの処理能
力を向上または低減できます。処理能力の最大は 32
vCPU および 244 GiB メモリです。コンピューティングの
スケーリングは通常、数分以内に完了します。
207. ストレージの自動スケーリング
o Amazon Aurora は、データベースのニーズが増大する
と自動的にデータベースのサイズを拡張します。ボリュー
ムは 10 GB ごとに最大 64 TB まで、またはお客様が
指定したサイズまで拡張されます。将来の拡張に備えて
データベースに余分なストレージをプロビジョニングする
必要はありません。
208. Amazon Aurora レプリカ
o Amazon Aurora レプリカを作成して、複数のインスタン
スから大容量のアプリケーション読み込みトラフィックを提
供することで、全体的な読み込みスループットを向上でき
ます。Amazon Aurora レプリカはソースインスタンスと
基盤となるストレージを共有しているため、コストを削減で
き、レプリカノードへの書き込みの実行が必要ありません。
これにより読み込みリクエストに対応するための処理能力
が向上し、レプリカのタイムラグを通常数ミリ秒に短縮しま
す。Amazon Aurora データベース 1 つにつき最大 15
個のレプリカを作成できます。
209. インスタンスのモニタリングと修復
o Amazon RDS は Amazon Aurora データベースおよ
び基盤となる EC2 インスタンスを継続的にモニタリングし
ます。データベースに障害が発生した場合、Amazon
RDS はデータベースおよび関連する処理を再起動します。
Amazon Aurora はデータベースの再実行ログのクラッ
シュリカバリリプレイを必要としないため、再起動時間を大
幅に短縮できます。
o
http://amzn.to/197jUBx
210. o また Amazon Aurora はデータベースのバッファキャッ
シュをデータベース処理から隔離するため、データベース
の再起動時にキャッシュが削除されません。インスタンス
に障害が発生した場合、Amazon RDS は RDS Multi-
AZ テクノロジーを使用して、3 つのアベイラビリティー
ゾーンに作成した最大 15 個の Amazon Aurora レプ
リカのうちの 1 つに自動でフェイルオーバーします。
Amazon Aurora レプリカが 1 つもプロビジョニングさ
れていない場合、Amazon RDS は障害が発生するとお
客様に代わって新しい Amazon Aurora DB インスタン
スの作成を自動で試行します。
211. 耐障害性と自己修復機能を備えたスト
レージ
o 各 10 GB 単位のデータベースボリュームが、3 つのア
ベイラビリティーゾーンにかけて 6 個レプリケーションされ
ます。Amazon Aurora ストレージは耐障害性を備え、
最大 2 つまでのデータのコピー損失をデータベースの書
き込み能力に影響せずに透過的に処理し、最大 3 つま
でのコピー損失を読み込み能力に影響せずに処理します。
また、Amazon Aurora ストレージは自己修復機能を備
えています。データブロックおよびディスクはエラー検出の
ために継続的にスキャンされ、自動的に置き換えられます。
212. 自動的かつ継続的な増分バックアップ
と特定時点の復元
o Amazon Aurora のバックアップ機能は、インスタンスの
特定時点の復元を可能にします。これによって、直近で 5
分前まで、保持期間内の任意の時点にデータベースを復
元させることができます。自動バックアップの保持期間は、
最大 35 日間まで設定できます。自動バックアップは
99.999999999% の耐久性を設計されたAmazon
S3 に保存されます。Amazon Aurora のバックアップは
自動的かつ継続的な増分バックアップで、データベースの
パフォーマンスに影響を与えません。
215. IAM ユーザーを作成する
o AWS のサービス(Amazon RDS など)の場合
は、サービスにアクセスする際に認証情報を指定
する必要がある。これにより、サービスのリソース
へアクセスするための権限を持っているかどうか
がサービスによって判定される。
o コンソールを使用するにはパスワードが必要であ
る。AWS アカウントのアクセスキーを作成して、
コマンドラインインターフェイスまたは API にアク
セスすることができる。
216. o ただし、AWS アカウントの認証情報を使って
AWS にアクセスすることは、推奨されない。代わ
りに AWS Identity and Access
Management(IAM)を使用するが推奨される。
o IAM ユーザーを作成して、管理権限を使ってこ
のユーザーを IAM グループに追加するか、管理
権限を付与する。これで、特殊な URL と IAM
ユーザーの認証情報を使って、AWS にアクセス
することができる。
230. 要件の特定
o Amazon RDS の基本的な構成要素は DB イン
スタンス。DB インスタンスは、データベースが作
成される場所である。DB インスタンスによって、
エンドポイントと呼ばれるネットワークアドレスが
提供される。
o DB インスタンスによって公開されたエンドポイン
トに接続する。DB インスタンスの作成時に指定
する情報によって、それぞれの構成要素(スト
レージ、メモリ、データベースエンジンとバージョン、
ネットワーク設定、セキュリティ、メンテナンス期間
など)が制御される。
231. デフォルトの VPC
o AWS アカウントがリージョン内にデフォルトの
VPC を所有している場合、その VPC は DB イ
ンスタンスをサポートするように設定される。
o DB インスタンスをホストするには、VPC は特定
の要件(2 つ以上のサブネットを保持しており、各
サブネットは個別のゾーン内にあることなど)を満
たす必要がある。
o DB インスタンスで使用できる VPC 内のサブ
ネットを定義する デフォールトのDB サブネットグ
ループを指定する必要がある。
232. フェイルオーバーサポート
o Amazon RDS では、フェイルオーバーが発生し
た場合に使用できる DB インスタンスのスタンバ
イレプリカは、マルチ AZ 配置と呼ばれる。
o 本稼働でワークロードが発生する場合は、マルチ
AZ 配置を使用する必要がある。テスト目的の場
合、マルチ AZ 配置ではなく、通常は 1 つのイン
スタンスで対応できる。
233. AWS アカウントのポリシー
o AWS アカウントが、Amazon RDS オペレーショ
ンの実行に必要な権限を付与するポリシーを持っ
ているかどうか。IAM 認証情報を使用して AWS
に接続する場合、IAM; アカウントには、
Amazon RDS オペレーションの実行に必要な
権限を付与する IAM ポリシーが必要となる。
234. Listen Port
o データベースがリッスンするのは、どの TCP/IP
ポートであるか。一部の企業のファイアウォール
では、データベースエンジン用のデフォルトの
ポートへの接続がブロックされる場合がある。
o 会社のファイアウォールがデフォルトのポートをブ
ロックする場合は、新しい DB インスタンス用に
他のポートを指定する。指定したポートをリッスン
する DB インスタンスを作成すると、DB インスタ
ンス用のポートは変更できない。
236. ストレージの要件
o Amazon RDS には、標準とプロビジョンド IOPS
(input/output operations per second)の 2
種類のストレージがある。
o 標準ストレージは、コスト効果に優れたストレージで
あり、アプリケーションの I/O 要件が少ないかまた
はバースト性である場合に適している。
o プロビジョンド IOPS ボリュームは、ランダムアクセ
ス I/O スループットにおけるストレージパフォーマ
ンスと整合性が重要となる、I/O 集約型ワークロー
ド(特にデータベースワークロード)の要件を満たす
ように設計されている。
238. o セキュリティグループは、関連付けられた DB イ
ンスタンスのファイアウォールとして動作し、イン
バウンドトラフィックとアウトバウンドトラフィックの
両方をインスタンスレベルで制御する。
o DB インスタンスが作成されると、アクセスを禁止
するファイアウォールがデフォルトで設定されます。
このため、DB インスタンスへの接続を可能にす
るルールをセキュリティグループに追加する必要
がある。前の手順で決定したネットワークと設定
に関する情報を使用して、DB インスタンスへの
アクセスを許可するルールを作成する。
239. o 作成する必要があるセキュリティグループは、VPC
セキュリティグループまたは DB セキュリティグ
ループのいずれかである。これは、DB インスタン
スが VPC 内にあるかどうかによって決まる。
o 2013 年 3 月以降に作成された AWS アカウント
の場合、デフォルトの VPC を所有しており、その
VPC 内に DB インスタンスが作成される可能性
がある。VPC 内の DB インスタンスでは、インスタ
ンスへのアクセスを許可するルールを VPC セ
キュリティグループに追加する必要がある。