Dynamo

Transcript

1. Dynamo: Amazon’s Highly Available Key-value Store 2020.12.25 @a2ito
2. はじめに Dynamo: Amazon’s Highly Available Key-value Store • 出典 ◦ 2007 ◦ http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.115.1568 • 著者 ◦ Amazonの方々 ▪ Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash ▪ Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels
3. はじめに Dynamo: Amazon’s Highly Available Key-value Store • Amazon は世界中のデータセンターに配置された数万台のサーバーを使い、ピーク時は数千万のカスタマが利用する、ワールドワイドな e-commereプラットフォームを展開している ◦ 信頼性が最も重要 ▪ わずかな停止でさえ、多大な影響と顧客の信頼にインパクトをもたらす ▪ 加えて、継続的な成長のために、プラットフォームは高度にスケーラブルである必要がある • Amazonのプラットフォームにはデータストアに主キーアクセスしか必要ないサービスが多く存在 ◦ ベストセラーリスト、ショッピングカート、カスタマー設定、セッション管理、セールスランク、製品カタログ etc ◦ リレーショナルデータベースを利用する一般的なパターンは、スケーラビリティと可用性の非効率性や制限が掛かってしまう • Dynamo は Amazon のeコマースプラットフォームにおけるコアサービスを支えてきた ◦ 例えば、ショッピングカートを保持するサービス (Shopping Cart Service)は一日で300万チェックアウトを達成する 1000万リクエストを受 け、セッション状態を管理するサービスは 10万並列のアクティブセッションをハンドルした
4. システムの前提及び要件 Dynamo: Amazon’s Highly Available Key-value Store • Query Model ◦ キーによって一意に識別されるデータアイテムのためのシンプルな readとwriteのオペレーション ◦ 複数のデータアイテムにまたがるオペレーションは存在せず、リレーショナルなスキーマは不要 ▪ Amazonのサービスの大部分はシンプルなクエリモデルで動作可能でリレーショナルスキーマが不要 ◦ Dynamoは比較的小さな (通常1MB以下)オブジェクトをストアするアプリケーションをターゲットにしている • ACID Properties ◦ Dynamoは、高い可用性を達成するために弱い一貫性で運用されるアプリケーションをターゲットにしている • Efficiency ◦ このシステムは普通のハードウェアインフラストラクチャ上で機能すること ◦ Amazonのプラットフォームでは、サービスは一般的に分布の 99.9パーセンタイルで計測される厳しいレイテンシ要件をもつ ◦ そのような厳しい SLAを満たす能力のあるストレージシステムはサービス運用において非常に重要な役割 • その他 ◦ DynamoはAmazonの内部サービスのみで使われるので、その運用環境は非敵対的で、認証や認可と言ったセキュリティ上の要件は存在 しない ◦ 各サービスは個別の Dynamoインスタンスを使い、数百のストレージホストまでスケール可能
5. CAP における Dynamo Dynamo: Amazon’s Highly Available Key-value Store https://www2.slideshare.net/AmazonWebServices/dynamodb-adaptive-capacity-smooth-performance-for-chaotic-workloads-dat327-reinvent-2017
6. Service-oriented architecture of Amazon’s platform Dynamo: Amazon’s Highly Available Key-value Store • 動的なWebコンテンツは Page Rendering Components にクエリを投げた結果 から生成される • キャッシュは使用するが基本的にはステートレス
7. 厳しいSLA Dynamo: Amazon’s Highly Available Key-value Store • 業界的にパフォーマンス指向の SLAは平均値、中央値、予想される変動値で定義されることが多い ◦ 「多数の」ではなく「全ての」カスタマーが良い経験を得られるような SLAとしたい ◦ Amazonでは、SLAは分布の99.9パーセンタイルで計測 • 99.9%としたのは、それ以上の性能の達成にはコストが大きく上昇するため
8. 結果整合性 Dynamo: Amazon’s Highly Available Key-value Store • 商用システムで使われるデータレプリケーションアルゴリズムの多くは、強一貫性のデータアクセスインターフェイスを提供するため、伝統的に 同期的なレプリカコーディネーションを行う ◦ 一貫性と可用性はトレードオフ ◦ 例えば、答えの正しさの不確実さを扱うよりも、データが絶対に正しくなるまで使用不可能とする ◦ レプリケーションデータベースの黎明期から、ネットワーク障害の可能性を取り扱うとき、強一貫性と高データ可用性は同時に達成出来な いことが知られている • 楽観的レプリケーション、つまり変更はバックグラウンドで並行して伝播し、ネットワーク切断されての動作を容認することで可用性をあげられな いか ◦ このアプローチの課題は、検知して解決しなければならないような変更の衝突を招く可能性がある ▪ それをいつ解決するのか、誰が解決するのか。 • Dynamoは結果整合性をもつデータストアとして設計されており、全ての更新は全てのレプリカに「結果的に」到達する
9. 衝突検知を「いつ」解決するのか Dynamo: Amazon’s Highly Available Key-value Store • 衝突検知を「いつ」解決するのか ◦ 多くの伝統的なデータストアは衝突解決を Write の実行中に行うことで、 Read の処理をシンプルに保つ ▪ この場合、Write は却下される • 一方、Dynamo は always writeable なデータストア(すなわち、writeの可用性の高いデータストア )という設計を目指している ◦ Amazonサービスにとって、カスタマーの更新の却下は顧客体験に直結する ◦ 例えば、ショッピングカートサービスは、ネットワークやサーバーの障害の最中であろうがショッピングカートに商品を追加と削除を保証しな いといけない ▪ Write が決して リジェクト されないことを保証しなければならない ◦ 衝突解決の複雑性を read に任せている
10. 衝突検知を「誰」が解決するのか Dynamo: Amazon’s Highly Available Key-value Store • 衝突検知を「誰」が解決するのか ◦ データストア or アプリケーション • Dynamo ではどちらでも実装可能 ◦ 開発者が面倒なら、データストアに押し付けることもできる ◦ 「最後の書き込みが勝つ (“last write wins”) 」のようなシンプルなポリシーしか使えない ◦ アプリケーションで実装すると、クライアントにとって最適な衝突解決を行うことができる ▪ 例えば、カスタマーのショッピングカートを保持するアプリケーションはバージョン衝突に「結合 (“merge”)」を選択して単一の統合され たショッピングカートを返却することが可能
11. その他のシステム要件 Dynamo: Amazon’s Highly Available Key-value Store • Incremental Scalability ◦ システム管理者とシステム自体にとって最小のインパクトで一度にひとつのストレージホスト (以下、"node")をスケールアウト出来るべき • Symmetry ◦ nodeやnode群における役割の区別はしない • Decentralization ◦ リーダ不在 • Heterogeneity (異種混交性) ◦ パフォーマンスが異なるサーバでも構成できる ▪ 一度に全てのホストをアップグレードすることなしにより高性能なノードを追加したい
12. Dynamo の前提・要件 Dynamo: Amazon’s Highly Available Key-value Store • Dynamo の前提と要件 1. 『いつでも書き込み可』なデータストア 2. 構成ノード全てが信頼出来るノード 3. スキーマレス 4. 厳しいSLA (少なくとも99.9%のread/writeオペレーションが数百ミリ秒で実行される事が求められる )
13. Dynamo 採用技術サマリ Dynamo: Amazon’s Highly Available Key-value Store
14. Dynamo 採用技術サマリ Dynamo: Amazon’s Highly Available Key-value Store
15. Partitioning Dynamo: Amazon’s Highly Available Key-value Store • Consistent Hashing ◦ リング上にノードを配置し、データもリング上に配置し、担当ノードを決める ◦ ノードの追加や削除の影響が最小（隣のノードにのみ影響があり、その他のノードは影響を被らない）
16. Partitioning Dynamo: Amazon’s Highly Available Key-value Store • 一般的な consistent hashing における問題点 ◦ リング上での各ノードのランダムな位置割り当ては不均一なデータと負荷の分散 ◦ ノードのパフォーマンスのばらつきを考慮していない • Dynamoは「仮想ノード」の概念を採用 ◦ 各ノードは一つ以上の仮想ノードを持ち、リング上では複数ノードのように見える ◦ データがより分散しやすく、追加や削除があっても、データ分散が偏りにくい ◦ 仮想ノード数は、各ノードのパフォーマンス・キャパシティから決定できる
17. Dynamo 採用技術サマリ Dynamo: Amazon’s Highly Available Key-value Store
18. Data Versioning Dynamo: Amazon’s Highly Available Key-value Store • 結果整合＝データは各レプリカに非同期に伝搬 ◦ 最新データが返却されない可能性がある • 一方で、整合性を守るべきパターンがある ◦ ショッピングカートへの更新処理 ◦ 最終的にはマージされる A B A C 古いバージョンに 商品”C”を追加 Node #1 Node #2 Ito さんのショッピングカー ト情報 Ito さんのショッピングカー ト情報
19. Data Versioning Dynamo: Amazon’s Highly Available Key-value Store • Dynamoは各変更の結果をデータの新しく不変のバージョンとして扱う ◦ オブジェクトの複数のバージョンが同時にシステム内に存在することを許容 ◦ 多くの場合、新しいバージョンは前のバージョンを包含し、システム自身が正式なバージョンを決定する事が可能 ▪ できない場合もある • Dynamoは Vector clock [12]を使用 ◦ (node, counter)ペア のリスト ◦ Dynamoでは、クライアントがオブジェクトの更新を望むとき、アップデートする対象のバージョンを指定する必要がある ◦ Read リクエストを処理する際、（シンプルにコーディネート出来ない複数のブランチにアクセスした場合） Dynamoは付随するバージョン情 報をcontextに格納して、全てのオブジェクトを返却 ▪ 枝分かれしたバージョンのコーディネート [12] Lamport, L. Time, clocks, and the ordering of events in a distributed system. ACM Communications, 21(7), pp. 558-565, 1978.
20. Data Versioning Dynamo: Amazon’s Highly Available Key-value Store Sxが更新
21. Data Versioning Dynamo: Amazon’s Highly Available Key-value Store Sxが再度更新
22. Data Versioning Dynamo: Amazon’s Highly Available Key-value Store SyとSzがそれぞれ更新(Syが更 新し終わる前にSzが更新した ケース)
23. Data Versioning Dynamo: Amazon’s Highly Available Key-value Store クライアントが複数バー ジョンを受け取り、 コー ディネートされた結果を Sx が write
24. Data Versioning Dynamo: Amazon’s Highly Available Key-value Store • Vector clock の採用によって起こりうる問題 ◦ たくさんのサーバーがオブジェクトの writeをコーディネートした場合、 Vector clock のサイズが大きくなってしまう • 実際には、write は通常 preference list の先頭Nノードのうちのひとつによってハンドリングされるため、発生確率は低い ◦ ネットワーク分断か複数のサーバー障害の場合、 writeリクエストはpreference listの先頭Nノード以外のノードによってハンドリングされる 可能性があり、これが vector clockのサイズ増大を引き起こす • この問題においては、 Vector clock の制限を掛けるために クロック切り捨て を採用している ◦ それぞれの(node, counter)ペアとともに、そのデータアイテムを更新した最後の時刻を示すタイムスタンプを保存 ◦ ベクタークロック内の (node, counter)ペアの数がしきい値に達したら、最も古いペアはクロックから除外する ▪ ただし、この切り捨て手法は親子関係を正しく辿れなくなる • 切り捨てが発生してしまうと、正しく coordination できなくなるが、プロダクション環境で発生した事は無い
25. Dynamo 採用技術サマリ Dynamo: Amazon’s Highly Available Key-value Store
26. Replication Dynamo: Amazon’s Highly Available Key-value Store • Dynamo におけるデータは N台のホストにレプリケートされる（ Nはパラメータ） ◦ キー k は Coordinator に割り当てられ、そのレンジに登録されるデータのレプリケーションを行う ◦ レンジ内の各キーのローカル保存に加えて、 Coordinator はこれらのキーをリング上を時計回りに N-1個までのノードに複製する • 例 ◦ ノードB は Key K をノードCとDに複製し、加えてローカルに保存 ◦ ノードD は レンジ(A,B], (B,C], そして(C,D] のレンジに入ってきたキーを保存
27. Preference list Dynamo: Amazon’s Highly Available Key-value Store • 特定のキーをストアする責任のあるノードのリストを、 preference listと呼ぶ ◦ 例：Key K を含むレンジの preference list には、B, C, D が入っている • 仮想ノードが存在する場合、「担当ノードが複数の物理ノードにまたがらない可能性がある」ため、リング上の位置を飛び飛びでリスト化されて いる
28. Execution of get() and put() operations Dynamo: Amazon’s Highly Available Key-value Store • 各ストレージノードは get/put を処理 • Coordinator によって get/put リクエストがハンドリングされる ◦ Preference list Coordinato r
29. Execution of get() and put() operations Dynamo: Amazon’s Highly Available Key-value Store • レプリカ内の一貫性保持のため、 quorum systems で使われているものに似たプロトコルを採用 ◦ R：read の成功ノードの最小数 ◦ W：write の成功ノードの最小数 • R+W>N となるようなR、Wを設定することで、 quorum-like system として稼動 ◦ get/put のレイテンシは最も遅い R/W のレプリカに依存 • put リクエスト Coordinator
30. Execution of get() and put() operations Dynamo: Amazon’s Highly Available Key-value Store • get リクエスト ◦ Coordinator はN個のノードからデータを取得し、 R個のノードからのレスポンスを待つ • 枝分かれしたバージョンがあった場合は、 coordinate され、マージされた新バージョンは write back される Coordinator
31. Hashing Failures: Hinted Handoff Dynamo: Amazon’s Highly Available Key-value Store • Sloppy quorum ◦ 可用性のため、従来の quorum 方式の代わりとして採用 ◦ 必ずしも「preference list における N個のノード」に限定しないという意味で sloppy • “ヒント付きデータ ” ◦ レプリカを保持すべきノードの情報をメタデータに含めておく ◦ レプリカを保持すべきノードが障害であっても、一旦別ノード受け取って、そのノードに後ほど再送
32. Hashing Failures: Hinted Handoff Dynamo: Amazon’s Highly Available Key-value Store • 高可用性ストレージシステムとして (複数の)データセンター全体の障害をハンドリング可能であることは必須 • Dynamo はそれぞれのオブジェクトを複数のデータセンターにレプリケーションするように設計されている ◦ 各キー の preference list を複数のデータセンター間に散らばったストレージノードで構成
33. Dynamo 採用技術サマリ Dynamo: Amazon’s Highly Available Key-value Store
34. Handling permanent failures: Replica synchronization Dynamo: Amazon’s Highly Available Key-value Store • ヒントつきレプリカがオリジナルレプリカノードに返却される前に利用不能になるケース ◦ Dynamo は レプリカ同期 によってレプリカを同期状態に保っている ◦ レプリカ間の不整合を素早く検知して転送データ量を最小化するため、 Dynamoはマークル木(Markle tree)を利用
35. Dynamo 採用技術サマリ Dynamo: Amazon’s Highly Available Key-value Store
36. Membership and Failure Detection Dynamo: Amazon’s Highly Available Key-value Store • Dynamoリングへのノードの追加や削除は明示的な開始メカニズムを使用 • 管理者がコマンドラインツール orブラウザでDynamoノードに接続してノードのリングへの追加か削除をするメンバーシップ変更を発行する ◦ リクエストを受けたノードはメンバーシップ変更と、その発行時刻を永続的ストレージに書き込む ◦ gossipベースのプロトコルはメンバーシップ変更を伝播させる ◦ 各ノードはランダムに選択される peerに連絡し、そのふたつのノードは効果的にかれらの持続的な変更履歴を統合する • 障害検知も同様に gossip を使用
37. Adding/Removing Storage Nodes Dynamo: Amazon’s Highly Available Key-value Store • 新しいノード(Xとする)がシステムに追加されたとき、リング上をランダムに選択するいくつかのトークンが割り当てられる ◦ Xへの担当割当に伴って、いくつかの既存のノードは、特定のキーレンジをストアしなくてもよくなるので、これらのノードは Xにそれらの キーを転送する • 例：AとBの間に ノードX が追加される場合 ◦ Xの担当： (F,G],(G,A],(A,X] ◦ B, C, D の担当範囲が狭まる ◦ ノードB,C,D は適切なキーセットの転送を Xに提案して承諾を得る • ノードがシステムから除外されたときは、逆のプロセスでキーの再配置が発生 x
38. Implementation Dynamo: Amazon’s Highly Available Key-value Store • Storage node は request coordination, membership and failure detection, local persistence engine の3つのコンポーネントで構成されてお り、すべてJavaで実装されている • Local Persistence Engine はプラガブルに設計されている ◦ アプリケーションのアクセスパターンにもっとも適したストレージエンジンを選択出来るようにするため ▪ BDBは一般的にほぼ数十キロバイトのオブジェクトを扱うのに対して、 MySQLはもっと大きいサイズのオブジェクトを扱う ▪ アプリケーションはオブジェクトサイズの区分によって永続化エンジンを選択 ◦ Dynamoのプロダクションインスタンスの大半は BDB Transactional Data Store を利用 Request Coordination Membership and failure detection Local persistence engine BDB MySQL In-memory buffer Storage node
39. Dynamo 利用パターン Dynamo: Amazon’s Highly Available Key-value Store • Business logic specific reconciliation ◦ 最も popular なユースケース ◦ 各データオブジェクトは複数のノード間でレプリケートされる ◦ バージョン分岐の場合、クライアントアプリケーションはそれ自身の調停ロジックを実行 ◦ 例：ショッピングカート • Timestamp based reconciliation ◦ "last write wins“ ▪ 最大の物理timestamp値を持つオブジェクトが正しいバージョンとなる調停ロジックを実行 • High performance read engine ◦ Write が少なく Read が多いケース ▪ 一般的に R: 1, W: N となる ◦ 製品カタログや商材を保持するサービスはこのカテゴリに向く
40. おしまい Dynamo: Amazon’s Highly Available Key-value Store • ありがとうございました • 残りは、性能テストの結果とか出ていましたので、ご興味ある方はどうぞ