Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to Aurora
Similar to Aurora (20)
More from maruyama097
More from maruyama097 (20)
Aurora
- 2. はじめに 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
- 6. Re-imagining Relational Database まず、Auroraの全体像をつかむために、 Re:Invent でのAnurag Guptaのプレゼン を、そのまま、振り返ることから始めよう。
- 11. 現在のDBのアーキテクチャーはモノリシックである たとえ、それをScale out させたとしても、引き続き 全く同じスタックを複製する ことになる キャッシュ層・ストレージ層で結合されている
- 13. リレーショナル・データベースの事を、あらためて 想像してみよう l 我々が、今、データベースを発明しているとすれば、 どうなるだろう？ l 我々が、1970年代にしたようには、少なくとも、 全面的に同じようには、設計しないだろう l Scale outし、自己修復し、既存のAWSのサービス を活用する、何かを構築するだろう
- 14. 自分の好きなお菓子を、食べることもできる l エンタープライズ版の商用データベースのパフォーマ ンスと可用性 l オープンソースのデータベースの価格と単純さ l 既存のアプリケーションとのコンパティビリティ
- 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 データベースとストレージのがたつきをなくす
- 19. Amazon Auroraは、 ただちにクラッシュから回復できる 伝統的なデータベース l 最後のチェックポイントからログを 再生しなければならない l MySQLではシングルスレッドで、非 常に多くのディスクアクセスが必要 になる Amazon Aurora l 配下のストレージは、ディスク・リード の一部として、オンデマンドでredoを 再生する l 並列、分散、非同期 T0でのクラッシュは、最後の チェックポイント以降のredo ログで、SQLアプリを再利用 することを要求する T0でのクラッシュは、redoログが それぞれのセグメントで、オンデ マンドでパラレルで非同期的に、 適用されることに帰着する
- 20. Amazon Auroraのキャッシュは、 DBが再起動されても生き残る l キャッシュは、データベースの プロセスから切り離されている l キャッシュは、データベースの 再起動の際にも「温かい」まま である l 復旧の全面的なロードの操作 は、早くできる キャシングのプロセスは、データベースの プロセスの外部にあり、データベースの再 起動をまたいで、温かいままでいる
- 21. Amazon Auroraのレプリカは、 ただちに、増設できる MySQL Read Scaling l レプリカはログを再生しなければならない l それはマスターに負荷をかける l レプリカ作成の遅延は、非確定的に増大 する l フェール・オーバーは、データの消失を引 き起こす シングル・スレ ッドでbinlogを 適用 ページキャッ シュの無効化 Amazon Aurora Read Scaling l レプリカはログを再生しない l マスターにほとんど負荷をかけないで、15 台までのレプリカを増設できる l レプリカの遅延は、10ms 程度 l レプリカとマスターは、同じストレージを共 有しているので、フェール・オーバーは、 データの消失を引き起こさない
- 32. Amazon Auroraは、データベースを 走らせるのを簡単にする l データベースを数分で作る l ボリューム上に、すぐにスナップショットが取れる l ボリューム外のAmazon S3に、連続的でインクリメンタルな、スナップ ショットが取れる l 64TBまでの自動的なストレージのスケールアップ – パフォーマンスや可 用性にインパクトを与えない l 自動的な再ストライピング、ミラーの修復、ホットスポット管理、暗号化
- 34. Amazon Auroraの価格 l ライセンスなし l ロックインなし l 使った分だけ支払う
- 36. Amazon Aurora 先のプレゼンの繰り返しになるのだが、次の 諸点を中心に、Auroraの特徴を見ていこう。 p Non-Monolithic, SOA p Amazon Aurora DB Cluster p Scalability p Availability
- 38. “Monolithic”なアプリとしての データベース o これまで、データベースは、特定のOS・特定の ハードウェア・特定のファイルシステムの上で動く ようにセットアップされたアプリケーションだった。 o それゆえ、データベースに必要な諸機能、SQL・ Transaction・Caching・Loggingといった機能 は、一体のものとして構築されている。それは、 “Monolithic（一枚岩）”のシステムといっていい。 o 逆にいえば、従来の環境では、“Monolithic”じゃ なければ、完結したアプリとしては動かないのだ から、そうした構成は、当然でもある。
- 40. Amazon RDS o Aurora以前にも、AWSではデータベース用のク ラウド・サービスは存在していた。Amason RDS がそれである。 o Amazon RDSは、クラウド利用を想定していな い “Monolithic” なデータベースに、その外側か ら、Availabilityの高いクラウド・ストレージの利 用と管理機能の提供を中心に、便利なクラウド・ サービスを提供しようというものだ。
- 41. Amazon RDS o Amazon RDSは、これまで次の４つのデータ ベースに対してサービスが提供されている。 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 の５番目の利用例となる。 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が高速になり巨 大なメモリーが使える技術のもとでは、コスト・パ フォーマンスに優れた、現実的な選択だと思う。
- 49. Amazon Aurora DB クラスター Cluster Volume Data Copy Data Copy Data Copy
- 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 リード レプリカの能力に影響を与える可能性がある。
- 56. Amazon AuroraのScalability Auroraでは、インスタンス、ストレージ、レプリカの Scalingが容易である。ストレージのScalingについ てはCluster Volumeの構成が、レプリカのScaling については非対称の構成が、大きく寄与している。 RDS for MySQLとの比較は興味ふかい。
- 57. AuroraのScalability o Push-button Compute Scaling： コンソール画面で数クリックするだけで、CPU数・ メモリーサイズをスケール・アップ／スケール・ダ ウン出来る。所要時間は、数分。 o Storage Auto-scaling： Auroraでは、ストレージ容量を指定する必要は ない。最初10Gのストレージが割り当てられ、以 降、必要に応じて、自動的に10G単位で容量は 増えていく。ユーザーは、ストレージの容量を意 識する必要はない。最終的には、64Tまで拡張可 能である。
- 58. AuroraのScalability o Amazon Aurora Replicas： Auroraでは、同じデータベース・ストレージを共 有する読み出し専用のRead Replicaを15台ま で、数クリックで、瞬時に増設できる。
- 59. インスタンスのスケーリング o クラスター内の各 DB インスタンスの DB インス タンスクラスを変更することで、必要に応じて DB クラスターをスケーリングできる。
- 60. ストレージのスケーリング o Aurora ストレージは、クラスターボリューム内の データに合わせて自動的にスケーリングする。 o データが増加すると、クラスターボリュームスト レージは、10 ギガバイト（GB）単位で最大 64 TBまで増加。データのサイズが減少すると、クラ スターボリュームストレージのサイズを、同様に 10 GB 単位で自動的に減少させる。 o DB クラスターの [Maximum Volume Size] 設定を使用して、Aurora DB クラスターが自動 的に拡張されるサイズを制限できる。。
- 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 インス タンスのすべてのデータベースをレプリケートする。
- 66. Amazon AuroraのAvailability Auroraは、高い可用性・耐障害性を持つ。バックアッ プ・スナップショットの作成、障害からの復旧にも、従 来のデータベースにはなかった優れた特徴を持つ。そ の多くは、Log-Structured File Systemの採用に よるものである。ここでも、RDS for MySQLとの比較 は、印象的である。
- 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
- 69. プライマリインスタンスの フェールオーバー o プライマリインスタンスの障害が発生した場合、新 しいプライマリインスタンスに自動的にフェイル オーバーする。 o DB クラスターに 1 つ以上の Aurora レプリカ がある場合は、1 つの Aurora レプリカがプライ マリインスタンスに昇格する。この場合、一般的な サービスの復元時間は 120 秒未満、多くの場合 60 秒未満で復元される。
- 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 操作を使用して、 リードレプリカを昇格させる。
- 73. Amazon Auroraは、 ただちにクラッシュから回復できる 伝統的なデータベース l 最後のチェックポイントからログを 再生しなければならない l MySQLではシングルスレッドで、非 常に多くのディスクアクセスが必要 になる Amazon Aurora l 配下のストレージは、ディスクリード の一部として、オンデマンドでredo を再生する l 並列、分散、非同期 T0でのクラッシュは、最後の チェックポイント以降のredo ログで、SQLアプリを再利用 することを要求する T0でのクラッシュは、redoログが それぞれのセグメントで、オンデ マンドでパラレルで非同期的に、 適用されることに帰着する
- 74. Amazon Auroraのキャッシュは、 DBが再起動されても生き残る l キャッシュは、データベースの プロセスから切り離されている l キャッシュは、データベースの 再起動の際にも「温かい」まま である l 復旧の全面的なロードの操作 は、早くできる キャシングのプロセスは、データベースの プロセスの外部にあり、データベースの再 起動をまたいで、温かいままでいる
- 75. バックアップ o Aurora は、Cluster Volumeを自動的にバック アップし、バックアップ保持期間分の復元データを 保持できる。 o Aurora のバックアップは継続的かつ増分的であ るため、バックアップ保持期間の任意の時点にす ばやく復元できる。 o バックアップデータが書き込まれるときに、データ ベースサービスのパフォーマンスに影響が出たり、 中断が発生したりすることはない。DB クラスター を作成または変更するときに、バックアップ保持 期間（1～35 日）を指定できる。
- 76. スナップショット o バックアップ保持期間を超えたバックアップを保持 する場合は、クラスターボリュームの中にデータ のスナップショットを作成できる。 o Aurora では、バックアップ保持期間全体の差分 復元データを保持するため、必要なのは、バック アップ保持期間を超えて保持するデータのスナッ プショットを作成することだけである。 o スナップショットから新しい DB クラスターを作成 できる。
- 77. データの復元 o Aurora が保持するバックアップデータから新し い Aurora DB クラスターを作成することで、 データを回復できる。DB クラスターの新しいコ ピーは、バックアップ保持期間の任意の時点にす ばやく復元できる。 o 保存した DB クラスターのスナップショットから復 元することもできる。バックアップ保持期間中の Aurora バックアップが継続的かつ増分的である ことは、復元時間を短縮するためにデータのス ナップショットを頻繁に作成する必要がないことを 意味する。
- 78. o DB クラスターの復元を要求したときは、読み取り オペレーションと書き込みオペレーションの両方 で、新しいクラスターボリュームがただちに使用で きる。ただし、コピーの作成中は、読み取りオペ レーションでレイテンシーが発生する場合がある。 o このレイテンシーは、クエリで要求されたデータが まだクラスターボリュームに復元されていない場 合にのみ発生する。この場合、データは、クラス ターボリュームにただちに復元される。要求され たデータが復元されると、そのデータがクエリ要 求に戻される。
- 79. Latest Restorable Time と Earliest Restorable Time o DB インスタンスの最新または最も早い復元可能 時間を判断するには、RDS コンソールでLatest Restorable Time 値または Earliest Restorable Time 値を探す。 o DB クラスターの最新の復元可能時間は、DB ク ラスターを復元できる最も直近の時点であり、通 常は現在時間の 5 分以内である。 o 最も早い復元時間は、クラスターボリュームを バックアップ保持期間内でどこまで遡って復元で きるかを示す。
- 80. MySQLのbinlog o バイナリログ作成を有効にすると、データロードに よりパフォーマンスが低下し、バイナリログ作成を 無効にして同じデータをロードした場合より多くの 空きディスク容量 (最大 4 倍) が必要になる。 o パフォーマンス低下の重大度と必要な空きディス ク容量は、データのロードに使用されるトランザク ションのサイズに正比例する。 http://amzn.to/1GK0wpj
- 81. MySQLのbinlogと トランザクションのサイズ o トランザクションが小さい場合、バイナリログ作成 により、データのロードに必要なディスク書き込み 数が 2 倍になる。 o アップロード速度、ロード中に実行される他の データベースアクティビティ、Amazon RDS DB インスタンスの容量によっては、他のデータベー スセッションのパフォーマンスが大幅に低下し、 データのロードに必要な時間が長くなることがあ る。
- 82. MySQLのbinlogと トランザクションのサイズ o トランザクションが大きい場合、バイナリログ作成 を有効にすると、バイナリログ作成を無効にした 場合のロードと比較して、データのロードに使用 できる容量の 3 倍の空きディスク容量が必要と なる。 o たとえば、1 つのトランザクションとしてロードされ る 10GB のデータは、ロード中に少なくとも 30GB ディスク容量を消費する。 (テーブルに 10GB + バイナリログキャッシュに 10GB + バ イナリログ自体に 10GB)。
- 83. Question ? Re:Inventのプレゼンでは、簡単に触れられている のだが、 Amazon Auroraのドキュメントには、 Cluster Volumeが、Log-Structured File Systemに基づいていることは、ほとんど触れられて いない。その分、かえって分かりにくい。 ここでは、筆者がプレゼンとドキュメントを読んで感じ た「素朴な疑問」をまとめてみた。第二部で、納得出来 る答えが得られればと思う。
- 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の図 ではない。
- 88. Google MegaStore
- 89. Availability o ストレージは自動的に3つのAWS アベイラビリ ティゾーン (AZs)内に複製され、さらに各AZ内で ２つのコピーを作成する。 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ログページがデータページを 生成するのに利用される?
- 95. Amazon Auroraは、 ただちにクラッシュから回復できる 伝統的なデータベース l 最後のチェックポイントからログを 再生しなければならない l MySQLではシングルスレッドで、非 常に多くのディスクアクセスが必要 になる Amazon Aurora l 配下のストレージは、ディスクリード の一部として、オンデマンドでredo を再生する l 並列、分散、非同期 T0でのクラッシュは、最後の チェックポイント以降のredo ログで、SQLアプリを再利用 することを要求する T0でのクラッシュは、redoログが それぞれのセグメントで、オンデ マンドでパラレルで非同期的に、 適用されることに帰着する sharding?
- 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 と統合する S３への「連続的なバックアップ」？
- 98. バックアップ o Aurora は、クラスターボリュームを自動的にバッ クアップし、バックアップ保持期間分の復元データ を保持できる。 o Aurora のバックアップは継続的かつ増分的であ るため、バックアップ保持期間の任意の時点にす ばやく復元できる。 o バックアップデータが書き込まれるときに、データ ベースサービスのパフォーマンスに影響が出たり、 中断が発生したりすることはない。DB クラスター を作成または変更するときに、バックアップ保持 期間（1～35 日）を指定できる。
- 100. log-structured File System データベース技術としてのAuroraが、極めてイノベー ティブなのは、大量のキャッシュとSSDストレージが利 用可能な時代に、最適なデータベースのストレージの 構造を提案していることである。 AuroraのRelational Database Serviceの技術 的な心臓部分は、このLog-structured Storageで ある。この試みは、画期的であるといっていい。
- 101. Aurora理解の要 o AuroraのCluster Volumeは、Replicaの数 だけのLog-structured Storageからなる。この ことを踏まえなければ、Auroraの障害からの “Quick Recovery”のメカニズムも、S3への Back-upが、何故に“Continuous”に可能なの かも理解できない。 o また、Auroraで は、ストレージはSSDのみで、 磁気ディスクのサポートがないのだが、これも単 なる高速化のためではない。Log-structured Storageは、ストレージがSSDの時に、最大の効 果を発揮するからだ。
- 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等のメタデータと、一緒にまとめて、大 きなブロックに書き出せばいい。これで、ディスク のスループットは、大幅に向上するはず。」
- 107. 一個だけのデータ Foo Aは、inodeで、データFoo をポイントしている。 二個目のデータ Barを追加 A’は、新しいinodeで、 データ Bar とデータ Fooを ポイントしている。 http://bit.ly/19EWBQN LFSの基本構造 inodeとデータ A A A’
- 108. Fooの値を、新しいFoo’で置き換える A’’は、新しい inodeで、新しい データFoo’ と データ Bar をポイントしている。 上のデータを整理する Cleaning A’’’は、新しい inode。データ Barがコピーされ、 コピーされたBarとデータFoo’ をポイントしている。 先頭のsegmentは、現在のinodeからはポイントされない。 GC可能 http://bit.ly/19EWBQN A A’ A’’ A A’ A’’ A’’’
- 109. 一個だけのデータ Foo Aは、inodeで、データFoo をポイントしている。 MAは、inode Mapでinode A をポイントしている。 二個目のデータ Barを追加 A’は、新しいinodeで、データ Bar とデータ Fooをポイントしている。 MA’’は、inode Mapでinode A、A’ をポイントしている。 inode Map - inodeのindex A MA MA MA’A A’
- 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の値が復元できる。
- 111. Roll-Forward - Crashからの回復 最終 Checkpoint 最後に書き込ま れた inode Checkpoint Region Checkpoint Region Crashからの回復は、最後に行われたCheckpointから始めて 最後に書き込まれた inodeを見つけることに帰着する。あとは、 適宜、失われたリンクを貼り直せばいい。 Scan
- 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
- 115. THE PAPER o この論文は、ほとんどシーケンシャルな書き込み を可能とする新しいファイルシステムの提案であ る。 o ほとんどのデータがRAMキャッシュにあると仮定 してみよう。 n 非常に複雑で、遅いディスクのreadの問題を解決 o ディスク・スペースを取り戻すメカニズムについて 述べる。 n この論文の本質的な部分
- 116. OVERVIEW o Introduction o Key ideas o Data structures o Simulation results o Sprite implementation o Conclusion
- 117. INTRODUCTION o プロセッサーのスピードは、指数関数的に増大し ている。 o メイン・メモリーのサイズも、指数関数的に増大し ている。 o ディスクの容量も急速に大きくなっている。 o ディスクのアクセス時間は、もっとゆっくりにしか 進化していない。
- 118. 結論 o 大きなメモリーサイズは、大きなキャッシュを意味 する n キャッシュは、ほとんどのreadアクセスを捉えるだ ろう n ディスクのトラフィックはwriteで占められる n キャッシュは、たくさんの小さなwriteを、少数の大 きなwriteに置き換える writeバッファーとしても 行動できる。 o 本質的な問題は、seekをなくすことで、ディスク writeのパフォーマンスを上げること
- 119. 負荷の考察 o ディスク・システムのパフォーマンスは、負荷に よって、強い影響を受ける o オフィスやエンジニアリングの負荷は、小さなファ イルへのアクセスで占められている n 多くのランダムなディスク・アクセス n ファイルの作成と削除の時間は、ディレクトリーと i-node の更新で占められている n ファイルシステムで、一番難しい問題
- 120. 既存のファイルシステムの制限 o それは、ディスク上に情報を広げている n I-nodes は、データブロックとは別に格納されて いる n ディスクの帯域の5%以下が、新しいデータにアク セスするために利用されている o ディレクトリーと i-node を更新するために、同期 的書き込みを利用する n 整合性が要求される n 非同期の書き込みより効率は悪い
- 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の書き込みは同期的に行われている。
- 123. キーとなるアイデア o ディスクに対する全ての変更を、ログのような 構造で、シーケンシャルに書き込む n たくさんの小さなランダムな書き込みを、大きな シーケンシャルな移動に変換する n ファイル・キャッシュを、Writeバッファーとして利 用する
- 124. LOG-STRUCTURED FILE SYSTEMS o Log-structured ファイルシステムの基本的なア イデアは、一連のファイルシステムの変更をファイ ル・キャッシュにバッファリングして、ついで、一回 のwrite操作で、全ての変更をシーケンシャルに ディスクに書き出すことで、writeのパフォーマン スを改善することである。
- 125. 主な利点 o 多くの小さなランダムな書き出しを、少数のシーケ ンシャルな書き出しで置き換える o クラッシュの後の迅速な復旧 n 最近書かれた全てのブロックは、ログの末尾に書かれ る n 整合性のために、全てのファイルシステムをチェックす る必要がない o UNIX や Windows 95/98 がしているように
- 126. ログ o ディスク上の唯一の構造 o i-nodesとデータブロックを含む o ファイルをログから比較的効率的に読み戻す ことができるように、インデックスの情報を含む o ほとんどのreadは、すでにキャッシュにある データにアクセスする
- 127. LFSとUNIXのディスク・レイアウト Disk Disk Log Inode Directory Data Inode map LFS Unix FSS dir1 dir2 file1 file2 dir1 dir2 file1 file2
- 128. Index の構造 o Inode map は、それぞれの i-node の位 置情報を保持する n ブロックはディスク上の様々な位置にある n アクティブなブロックは、メイン・メモリーにキャッシュ される o それぞれのディスクの固定のcheckpoint region は、全ての inode map のブロック のアドレスを含んでいる
- 129. セグメント o セグメントは、新しいデータをかき出すための大き なフリーの拡大領域を保持しなければならない o ディスクは、大きな固定長のセグメントと呼ばれる 領域に分割される （Sprite LFSでは512KB） o セグメントは、常に、一方の端から他方へとシー ケンシャルに書き出される o 古いセグメントは、再利用される前に、クリーンに されなければならない
- 130. 空きスペースを固定長のセグメントへ の分割で管理するためのデータ構造 o I-node: ファイルのブロックの位置の情報を持 ち、保護ビット、修正時刻等の情報を保持する Logの中に置かれる o I-node map: ログの中での i-nodeの位置 情報を持ち、最終アクセス時刻とバージョン・ナン バーの情報を保持する Logの中に置かれる o Indirect block: 大きなファイルのブロックの 位置情報を持つ Logの中に置かれる http://stanford.io/1aRpQA8
- 131. 空きスペースを固定長のセグメントへ の分割で管理するためのデータ構造 o Segment summary: segmentの中身 （ファイルの数、それぞれのブロックのoffset等） を同定する Logの中に置かれる o Segment usage table: segmentに残さ れている利用可能なバイト数を数え、segment 中のデータの最終書き込み時刻を格納する Logの中に置かれる o Superblock: segmentの数やsegmentの サイズのような、静的な構成情報を保持する 固 定領域に置かれる http://stanford.io/1aRpQA8
- 132. 空きスペースを固定長のセグメントへ の分割で管理するためのデータ構造 o Checkpoint region: i-node mapと segment usage tableの位置情報を持ち、ロ グ中の最後のcheckpointを同定する Fixed o Directory change log: ディレクトリーの操 作を記録し、i-node中のreference countの整 合性を維持する Logの中に置かれる http://stanford.io/1aRpQA8
- 133. セグメントのクリーンニング (I) o 古いセグメントは、次のデータを含んでいる n liveデータ n deadデータ 削除されたファイルに含まれて いたデータ o セグメントのクリーニングは、liveデータの書き出 しを含んでいる o セグメント・サマリー・ブロックが、セグメント中のそ れぞれの情報の断片を同定する
- 134. セグメントのクリーンニング (II) o セグメントのクリーニング・プロセスは、次のもの を含む 1. たくさんのセグメントをメモリーに読み込む 2. live データを同定する 3. それらを、少数のクリーンなセグメントに書き 出す o 基本的な問題は、どこにこれらのlive データをか き出すかである n 安定しているファイルを繰り返し移動するのを 避けたい
- 135. Threaded logと Copy and Compact
- 136. Write cost u = utilization
- 137. セグメントのクリーニング・ポリシー o Greedy policy: 常に、最も使われていない セグメントをクリーンにする o Cost-benefit policy: ベニフィットとコスト の比率が一番高いものを選ぶ
- 138. ライフブロックのコピー o Age sort: n ブロックを、最後に修正された時間でソートする n 似た年代のブロックを一緒にグループとしてまとめ、 新しいセグメントに入れる o ブロックの年代は、その生き残りのいい予想を 与える
- 139. シミュレーションの結果(I) o 二つのファイルアクセスのパターンを考える n Uniform n Hot-and-cold: (100 - x) % のアクセスが x % のファイルを巻き込んでいる 90%のアクセスが 10%のファイルを巻き込む (どちらかというと雑なモデル)
- 140. Greedy policy
- 141. Comments o ディスク・スペースの利用にとってWriteコスト は非常にセンシティブである n 高度なディスクの利用は、より頻繁なセグメント・ク リーニングの結果として得られる n より多くのliveデータを含んだセグメントをクリーン にする
- 142. Segment utilizations
- 144. Using a cost-benefit policy
- 145. Using a cost benefit policy
- 146. Comments o Cost benefit policyがいい
- 147. Sprite LFS o 小さなファイルへのwriteでは、現在のUnix ファイル・システムより数段勝っている o readと大きなファイルのwriteでは、Unixと同 等かそれ以上の性能 o これは、セグメント・クリーニングのオーバー ヘッドを含めた性能である n 書き込みのディスクの帯域の70%を使うことがで きる n Unix のファイルシステムでは、典型的なケースで は、その5-10%だけしか使っていない
- 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を更新する
- 150. Roll-Forward o 可能な限り多くの情報を回復するために、Sprite LFSは、 最後のCheckpointの後に書き込まれた情報を、ログ segmentの中でスキャンする。この操作は、Roll- Forwardと呼ばれる。 o Roll-Forwardの間、Sprite LFSは、最近書かれたファ イルのデータを回復するために、Segment Summary ブロックの情報を使う。Summaryブロックが、新しい inodeの存在を示せば、Sprite LFSは、Checkpointか ら読んだ inode mapを更新する。こうして、新しいinode mapは、このinodeの新しいコピーを参照することになる。
- 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.
- 152. SUMMARY o Log-structured ファイルシステムは n disk I/Oあたり、大量の新しいデータの書き込 みを行う n ディスクの帯域の大部分を利用できる o 空きスペースの管理は、ディスクを固定長の セグメントに分割することで行われる o cost-benefit policyで、セグメントのクリー ニングのオーバーヘッドを最小にする
- 153. Heuristic Cleaning Algorithms in Log-Structured File Systems Trevor Blackwell, Jeffrey Harris, Margo Seltzer Harvard University http://bit.ly/1EAsv8w
- 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が非同期に実行され、かつ、処理期間中にクリーニング が実行されるので、トータルの実行時間は短くなる。
- 156. log-structured File Systemと データベース “Damn Cool Algorithms: Log structured storage” http://bit.ly/19EWBQN
- 157. 一個だけのデータ Foo Aは、Index nodeで、データ Foo をポイントしている。 二個目のデータ Barを追加 A’は、新しいIndex nodeで、 データ Bar とデータ Fooを ポイントしている。
- 158. Fooの値を、新しいFoo’で置き換える A’’は、新しいIndex nodeで、新しい データFoo’ と データ Bar をポイントしている。 上のデータを整理する A’’’は、新しいIndex node。データ Barがコピーされ、 コピーされたBarとデータFoo’ をポイントしている。 先頭のsegmentは、現在のi-nodeからはポイントされない。 GC可能
- 159. Garbage Collection の対象は、柔軟に選べる o Log-structure FSのアプローチは、他のファイルシステ ムに対して、幾つか有利な点がある。まず、一番古い segmentを最初に消去するよう制限されているわけでは ないということだ。例えば、もし、中間のsegmentがほと んど空だったら、代わりに、そのsegmentをGCすること を選ぶことができる。このことは、長い期間同じままにとど まるようなデータや繰り返し上書きされるようなデータを持 つデータベースには特に役に立つ。我々は、同一の修正 されていないデータを書き換えるのに、多くの時間をかけ るのは望んでいない。我々は、GCがいつ起きるのかを もっと柔軟に決められる。通常は、GCが起きる前に、 segmentが大部分古いものになるまで待つことができる。 さらに、行わなければいけない仕事の量を最小にできる。
- 160. ログファイルはいらない データベース・ファイルがWALになる o データベースのこのアプローチの優位性は、これだけにと どまらない。典型的には、データベースではトランザクショ ンの整合性を維持するために、 “Write Ahead Log”, WAL を利用している。データベースが、トランザクション をディスクに保存しようとするときには、最初に全ての変 更を WALに書き出し、それをディスクにフラッシュし、そ れから実際のデータベース・ファイルを更新する。これに よって、WALに記録された変更を再生することで、クラッ シュからリカバーできる。もし、log structuredストレージ を使っていれば、しかしながら、Write Ahead Logが データベース・ファイルになる。だから、一回だけデータを 書けばいいことになる。
- 161. リカバリーと書き出しの最適化 o リカバリーの状況では、最後に記録されたIndex headerから始めて、順番に線形に検索して、進むにつれ て、どんな失われたIndexの更新も、再構成できる。 o さらに、こうしたリカバリーの方式の利点を使えば、書き込 みの最適化も可能となる。毎回、更新されたIndexノード をディスクに書き出す代わりに、それらをメモリーにキャッ シュして、定期的にディスクに書き出すことができる。 o 我々のリカバリー・メカニズムは、終了したトランザクション と終了できなかったトランザクションとをなんらかの方法で 区別を与えることができる限り、クラッシュ時のデータの再 構築の面倒をみていくだろう。
- 164. ロックのない読み出しが可能 o 我々は、この問題を、Multiversion Concurrency Control, MVCCで克服できる。ノードがデータベースか ら読み込みをしたい時、現在のルートのIndexノードを調 べて、 それをこのトランザクションのアラームとして使う。 o 既存のデータは、log-basedなストレージでは修正される ことはないので、そのプロセスは、それが処理の権限を得 た時点でのデータベースのスナップショットを得ることにな る。並行して走るトランザクションは、そのデータベースの viewに、全く影響を与えることはない。こうして、ロックの ない読み出しが可能になる！ Snapshot Isolation !
- 165. データの書き出し Optimistic concurrencyを使う o データの書き戻しでは、我々は、Optimistic concurrencyを利用することができる。典型的なread- modify-writeのサイクルでは、まず最初に、上に述べたス タイルで、読み出し操作を実行する。 ついで、データベース にwriteロックをかけて変更を書き出す。そして、最初の局 面で読み出したデータが変わっていないことを検証する。 o indexを見て、問題のデータのアドレスが最後に見たのと同 じであることをチェックすることで、このことを迅速に行うこと ができる。もし、それが同じであれば、書き込みは起きてい ないということなので、自分自身の修正に進むことができる。 もし、違っていたら、競合するトランザクションが起きたという ことなので、単に、最初のreadのフェーズにロールバックす ればいい。
- 166. LFS（に近い）アルゴリズムを 使っているデータベース o 私が大きな声でLFSを褒める歌を歌ったので、このアルゴ リズムをどのシステムがすでに使っているか知りたいと 思ったかもしれない。驚くべきことに、私が知る限り、そう いうシステムはほとんどない。ただ、次のような有名なシ ステムが、いくつかある。 o もともとのBerkeley DBは、かなり標準的なアーキテク チャーを使っているのだが、そのJavaへの移植版である BDB-JEは、ここで述べた全ての要素を使っている。 o CouchDB は、ここで述べたシステムを使っている。ただ し、ログをsegmentに分割し、ガーベージコレクションを 行う代わりに、不要なデータが十分に溜まったら、データ ベース全体を書き直している。
- 167. LFS（に近い）アルゴリズムを 使っているデータベース o PostgreSQL は、MVCCを使っている。そのWrite Ahead Logは、我々が述べたインクリメンタルなバック アップができるように構造化されている。 o App Engine datastoreは、BigTableに基づいてい る。それは、ディスク上のストレージでは違うアプローチを 取っているのだが、トランザクション層は、Optimistic Conccurencyを使っている。
- 168. Cache, Log and File System 2006年 Google: BigTable http://bit.ly/1BgmxYs 2011年 Google: LevelDB http://bit.ly/1943U47
- 169. BigTableシステム構成 Bigtable セル メタデータのオペレーションを実行 ロードバランシング Bigtable Tablet Server サーバデータ フェイルオーバのハンドリング モニタリング タブレットデータの 保持 ログ メタデータ保持、 マスター選定のハンドリング Bigtable Tablet Server サーバデータ Bigtable Tablet Server サーバデータ Bigtable Master Cluster Sheduling System Google File System Chubby Lock Service Bigtable Client Bigtable Client Library Open
- 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
- 171. Write Op Read Op memtable GFS Memory SSTable files Tablet Log
- 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も、辞書式順にソート されたデータ構造であるので、マージは効率 的に行われる。
- 174. データ圧縮 memtableからSSTableへの変換 o 書き込みが実行されると、memtableのサイ ズが増大する。 o それが、ある値を超えると、memtableは凍 結され、新しいmemtableが生成される。 o 凍結されたmemtableはSSTableに変換さ れ、GFSに書き出される。 o この「小圧縮」は、tabletサーバのメモリーの 利用量を減らし、サーバが死んだ場合のふっ リカバリの際に、読み込むlogの量を少なくす る。
- 175. データ圧縮 merging compaction o 小圧縮の度に、新しいSSTableが生成される。 こうしたことが続けば、readの要求の度に、沢 山のSSTableのmerge操作が必要になる。 o そうしたことを避ける為に、SSTableの数に制 限を設けて、バックグラウンドで定期的に、 merging compactionを実行する。 o これは、いくつかのSSTableとmemtableの 中身を読み込んで、新しいSSTableを書き出 す。
- 176. データ圧縮 major compaction o 全てのSSTableを、一つのSSTableに書き 換えるmerging compactionを、「大圧縮 （major compaction）」という。 o 大圧縮以外の圧縮では、元のSSTableに含 まれているdeleteのマークがついたデータは、 そのまま移されるが、大圧縮のときには、こう したデータは、消去される。
- 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
- 178. “SSTable and Log Structured Storage: LevelDB” http://bit.ly/18tMGf9
- 179. Facebook: Real-Time Analytics Systemのアーキテクチャ このFacebookのシステムの重要な特徴は、 m-tierモデルではなく、WAL write ahead logに基づく、Tailingアーキテク チャーである。それは、中小規模のシステム にも応用可能である。 2012年5月 「Facebookのリアルタイム Big Data処理」 http://bit.ly/1FMOMUF
- 180. WALを利用した、 Tailingアーキテクチャー o HBaseは、沢山の分散したマシン上に、データを 格納する。 o Tailingアーキテクチャを利用する。 o ユーザーは、Webページ上の「いいね」をクリック する。 o Facebookに、AJAXリクエストが飛ぶ。 o AJAXリクエストは、Scribeを使って、ログ・ファイ ルに書き出される。
- 181. WALを利用した、 Tailingアーキテクチャー o 新しいイベントはScribeでログ・ファイルに格納 され、 ログは、PTailで、後ろから処理される。 o システムは、ログからイベントを巻き取り、Puma で処理し、HBaseストレージに書き出す。 o UIは、ストレージからデータを引き出し、ユー ザーに表示する。 Web -> Scribe -> PTail -> Puma -> HBase
- 182. Write Ahead Log o Facebookのシステムで、スケータビリティと信頼 性に取って、本質的に重要な特徴は、WAL write ahead logである。 おこると想定される操 作のログ。 o キーに基づいて、データは、リージョン・サーバに 分割される。 o データは、まず最初に、WAL に書き出される。
- 183. Write Ahead Log o データはメモリーにおかれ、ある時点で、あるい は、十分なデータが集積したら、ディスクにフラッ シュされる。 o もしも、マシンが倒れたら、WALからデータを再 生できる。 o ログとメモリー内ストレージを組み合わせて利用 することで、極めて高レートのIOを、確実にハン ドルできる。
- 185. SSD File System 注目すべきことは、Auroraのストレージに使われて いるSSDの内部も、Log-Structured File System と同じ構造をしていることである。SSD上のファイルシ ステムについての研究も存在している。 現在、NANDのFlashメモリーには、コントローラーを 介して、DRAMのDDRx型のインターフェースが付け られているが、クラウドのストレージ・サービスが、直 接、Flashメモリーをコントロールすることも可能なの かもしれない。
- 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
- 189. ブロックコピー ページ内のデータを 書き換える場合は、 そのページを含むブ ロック全体のデータ をバッファに読み出 し、別のブロックに待 避する必要がある http://bit.ly/1C5f97e
- 190. ウェアレベリング ウェアレベリングは、書き 込み回数を平準化する機 能。記録エリアを監視し、 特定の場所に書き込みが 集中しないように管理して いる http://bit.ly/1C5f97e
- 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/
- 195. Appendix p 「Amazon RDS for Aurora 製品の詳細」 p 「主な特徴」 p Amazon RDS のセットアップ
- 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
- 197. 「Amazon RDS for Aurora 製品 の詳細」より http://amzn.to/1BUo4XJ
- 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 まで自動的に拡張できます。
- 203. 主な特徴 o パフォーマンスとスケーラビリティ n 低ジッターで高スループット n ボタンを押すだけのコンピューティングスケーリング n ストレージの自動スケーリング n Amazon Aurora レプリカ o 信頼性 n インスタンスのモニタリングと修復 n 耐障害性と自己修復機能を備えたストレージ n 自動的かつ継続的な増分バックアップと特定時点の 復元 n データベースのスナップショット
- 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 のバックアップは 自動的かつ継続的な増分バックアップで、データベースの パフォーマンスに影響を与えません。
- 213. データベースのスナップショット o データベースのスナップショットはお客様が開始して Amazon S3 に保存するバックアップで、お客様が明示 的に削除するまで保持されます。お客様は自動的な増分 スナップショットを活用して必要な時間とストレージを削減 できます。ご希望の際にいつでも、DB スナップショットか ら新しいインスタンスを作成することができます。
- 214. Amazon RDS のセットアップ p AWS にサインアップする p IAM ユーザーを作成する p 要件の特定 p セキュリティグループの作成
- 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 集約型ワークロー ド（特にデータベースワークロード）の要件を満たす ように設計されている。
- 237. セキュリティグループの作成
- 238. o セキュリティグループは、関連付けられた DB イ ンスタンスのファイアウォールとして動作し、イン バウンドトラフィックとアウトバウンドトラフィックの 両方をインスタンスレベルで制御する。 o DB インスタンスが作成されると、アクセスを禁止 するファイアウォールがデフォルトで設定されます。 このため、DB インスタンスへの接続を可能にす るルールをセキュリティグループに追加する必要 がある。前の手順で決定したネットワークと設定 に関する情報を使用して、DB インスタンスへの アクセスを許可するルールを作成する。
- 239. o 作成する必要があるセキュリティグループは、VPC セキュリティグループまたは DB セキュリティグ ループのいずれかである。これは、DB インスタン スが VPC 内にあるかどうかによって決まる。 o 2013 年 3 月以降に作成された AWS アカウント の場合、デフォルトの VPC を所有しており、その VPC 内に DB インスタンスが作成される可能性 がある。VPC 内の DB インスタンスでは、インスタ ンスへのアクセスを許可するルールを VPC セ キュリティグループに追加する必要がある。