日本最大の即レスサービス「アンサー」を支える Amazon DynamoDB

Transcript

• 1. 日本最大の即レスサービス 「アンサー」を支える Amazon DynamoDB 2015/6/3 at AWS Summit Tokyo 2015 デベロッパーカンファレンス nanapi Inc. Masahiro Akita
• 2. 自己紹介 •2011年4月nanapi入社 (5年目) •主にサーバーサイドをやってます •akiyan.com という個人ブログを書いてます 秋田 真宏 / あきやん 株式会社 nanapi エンジニア (社員) 2
• 3. アンサーとは •即レスコミュニケーションサービス •iOS / Android ネイティブアプリ展開 •リリースから約1年半 •2014年12月時点で累計1億コメント 3
• 4. こんな感じ 4
• 5. DynamoDBとは •フルマネージドで管理不要なデータストア •マルチAZに分散保存で高可用性 •設定値だけで自動スケール •合計容量の限界なし •スループット課金 •スキーマレス •インデックスが作れる 5
• 6. デベロッパーにとってのDynamoDBとは なんかすごい夢のデータストアサービス？ 6
• 7. DynamoDBを運用する前のイメージ •お金をかければかけたぶんだけスケール するらしくてすごい •KVS(NoSQL)だけどインデックスも張れ るからRDBの代わりにもなりそう •インデックスを張らなくても強引にRDB 的なこともできそう 7
• 8. DynamoDBを運用した後のイメージ •DynamoDBはKVSである •RDBの代わりとして使うべきではない •前提を理解していればスケールする •前提を理解していなければスケールしな い 8
• 9. 今回の発表の立ち位置 アンサーにおけるDynamoDBの 運用後に得られた経験から 運用前の自分に向けて伝えたいこと 9
• 10. 話す内容 •DynamoDBの基礎と導入の経緯 •スループットにまつわるあれこれ •スケーラビリティの確保 •インデックスとは何か •インポートのベストプラクティス •バックアップは難しい •おすすめの学習方法 10
• 11. DynamoDBの基礎知識 11
• 12. DynamoDBの基礎の基礎 •テーブルの種類 •スループット •主なAPI 12
• 13. テーブルの種類 •テーブルは2種類ある •HASHテーブル •HASH + RANGEテーブル 13
• 14. HASHテーブル •一意なキーでItemが決定する、いわゆる KVS的なテーブル •できることがKVS以上でも以下でもない ので、安心して使える 14
• 15. HASH + RANGE テーブル •HASHキーとRANGEキーの2種類の値の組み 合わせでItemが決定する •HASHとRANGEの組み合わせはユニークで ある必要がある •HASHキーのみでも取り出すことができる •HASHキーに追加でRANGEキーを対象に範 囲など条件指定して取得が可能 •取得時にRANGEキーで昇順降順のソートが 可能 15
• 16. スループットとは •DynamoDBが内部のパーティション(ス トレージ)からItemを読み書きした容量 •ネットワークの転送量ではない •必要なスループットは予め設定し、設定 値によって1時間単位で課金される •設定値は「キャパシティーユニット (CU)」 と呼ぶ •設定値の変更はオンラインで実行可能 16
• 17. 主なAPI •getItem (1件取得) •query (1HASHに対してRANGEキーで 検索複数取得) •putItem (1件更新) •updateItem (特定のカラムを更新、アト ミックインクリメント等) 17
• 18. DynamoDBの導入経緯 18
• 19. RDBの限界 •RDS上のMySQLでマスタースレーブ構成 •1000万レコード級のALTERは辛い •ALTERすると派手にスレーブ遅延する •ALTERするときは一時的にマスターDBをス ケールアップしてアクセスを集中させていた •マスターDBのスケールアップの限界が見え てきた 19
• 20. 少ない手間でスケールする点に注目 •DynamoDBは設定だけでスケールして限 界が無いのが素敵すぎるしフルマネージ ドで管理不要 •レスポンスは十分速そう •容量課金は安そう •スループット課金はどれくらいになるか わからないが、他のメリットが大きいの で許容されるリスクとした 20
• 21. 実際の用途 •投稿内容のレプリカ •スポット参加状態のレプリカ •ユーザーログインセッション •シーケンス生成器 21
• 22. スループットのコスト 22
• 23. コストはキャパシティーユニットの設定値で決まる •キャパシティーユニットは読み書き別々に 設定する •書き込みユニットは1WCUあたり1KBの 性能で、10ユニットで $0.00742 (Tokyo) / 時間 •読み込みユニットは1RCUあたり4KBの性 能で、50ユニットで $0.00742（Tokyo) / 時間 •性能は「秒間あたり」の性能となる 23
• 24. スループット課金額例 •毎秒 100KB の読み込みスループットを 確保するには 100KB / 4KB = 25 RCU が必要 •$ 0.00742 * 25(RCU) * 24(hour) * 30(days) = $ 133 / Month 24 Itemサイズ平均 １KB 1リクエストあたり 10Item読み込み 秒間アクセス 10アクセス
• 25. スループット消費量の確認方法 •現在消費しているスループットはマネジ メントコンソールから5分単位で確認でき る •リクエストごとに消費したスループット は、APIの返り値で確認できる（ただしお およそで、多めに盛られ気味） 25
• 26. スループット消費グラフ 26
• 27. 消費スループットのAPIの返り値 # aws dynamodb query … ̶return- consumed-capacity TOTAL ¦ jq .ConsumedCapacity { "CapacityUnits": 1.5, "TableName": expample_table } 27
• 28. DynamoDBの主なコストはスループット •DynamoDBのコストボトルネックはスルー プット量になる •容量課金は安い (そもそも大きなデータを 格納できないし、しないし、データが大 きいとスループットのほうが先に高額に なる） •転送量課金も安い（同一リージョン内な ら無料） 28
• 29. スループット増大に注意 29
• 30. RDBのように使うとスループットが増えがち •RDBのように多めのレコードを富豪的に 読み込もうとすると、スループット破産 する •どうしてもRDB的に使うなら、テーブル をカラムごとの利用頻度によって分割し たり、アイテムごとにキャッシュしてス ループット消費を抑えよう 30
• 31. スループット破産例 •例えば256KBのItemを50件読み込む要 件があると、少なくとも一度に「1,600 RCU」を消費する •1600 RCU をプロビジョニングすると月 額 $170 (Tokyo) が必要 •この要件で毎秒あたり10ユーザーが同時 アクセスして遅延なく応答するには 16,000 RCU が必要になり月額 $1,900 の課金になる。 31
• 32. KVSのように使おう •RDBのように使わずKVSのように使って いれば現実的なスループットに収まるは ず •スループット消費を抑えようとすると、 結果的にKVS的な利用に限定される •スループット課金額からして、DynamoDB はそもそもKVS的な利用を想定している と思う 32
• 33. KVS的な使い方とは •KVSでは毎回大量のItemを読み書きした りはしない •KVSでは1Itemをやたら大きくしたりは しない •256KBはDynamoDBとしては大きすぎ る部類。最大でも400KB 33
• 34. 節約できそうでできない スループット 34
• 35. DynamoDBは一度に複数Itemの取得が可能 •「query」で、RANGEテーブルやインデッ クスから一度に複数Itemを読み込むこと ができる •HASH のみか、HASH と RANGE の条 件指定での読み込みが基本 35
• 36. LIMITをつけてもスループットは節約できない •「LIMIT」はquery APIのパラメータ •パーティションから複数のItemを読み込ん だ後に、結果セットの数を制限してくれる •LIMITの指定でスループットは減ることは ない •HASH + RANGE テーブルで、RANGEの 指定無しでもLIMITをつければいかにもス ループットが減りそうだが、減らない 36
• 37. HASH + RANGE テーブルでスループット消費を抑えるには •先頭n件を取得する場合、スループットを 節約しようとするなら、適当なRANGEキー を範囲指定しなければならない •適当なRANGEキーの決定は通常は無理が ある場合がほとんど •スループット消費低減のためにインデック スを用意すると、追加の書き込みスループッ トが必要になるので悩ましい •あちらを立てればこちらが立たず状態 37
• 38. そもそもn件取得はKVS的でない •「先頭/末尾のn件を取得」という要件が、 そもそもKVS的でない (DynamoDBに向 いていない) •時系列データをスループット消費の観点で 効率的に読み込むには前提と工夫が必要 •例えば「Itemは24時間以内に必ずexpire する」などの前提があれば、RANGE値を 24時間のexpireに限定してクエリに指定 できる 38
• 39. フィルタを指定してもスループットは節約できない •「フィルタ」はquery APIのパラメータ •パーティションからItemを読み込んだ後 に、結果セットのデータを絞り込んでく れる機能 •絞り込み条件にはあらゆるキーを指定出 来る •読み込んだあとの絞り込みなので、スルー プットは絞り込み前の結果で消費される 39
• 40. フィルタの使いどころ •query は結果セットの容量に1MBの制限 がある •結果セットが1MBを超えるようなリクエ ストで、取得後に絞り込みが必要な場合 の、リクエスト回数の削減用 •転送量の削減にもなる •アプリケーションサーバー側のCPU節約 としてもよい 40
• 41. LIMITとフィルタを組み合わせると、LIMITが先に適用される •LIMITとフィルタを組み合わせると、 「LIMITで制限してからフィルタで絞り込 む」という挙動になり、LIMITの数より少 ない結果セットになる •RDB脳からすると直感的でない挙動 41
• 42. スループットの主な節約手段 •キャッシュの活用 •「結果整合性」での読み込み 42
• 43. 「結果整合性」とは •DynamoDBからの読み込みには「強い整 合性」と「結果整合性」の2種類があり、 場合によって選択可能 •「結果整合性」は「強い整合性」の読み 込みに比べて、 半分のスループットで読 み込める 43
• 44. 整合性をRDBに例えるなら •「強い整合性」はマスターDBからの読み 込み相当。完了済みの書き込みAPIリクエ ストの結果が確実に取得できる •「結果整合性」はスレーブDBからの読み 込み相当。書き込み同期遅延(レプリカラ グ)の発生が前提 •遅延が許される箇所であれば積極的に「結 果整合性」での読み込みを行う 44
• 45. スループットが足りない時は 45
• 46. いつスループットが足りなくなるのか •一度のリクエストで消費できるスループッ トは限られている •プロビジョニングされたスループットと、 現在消費されているスループットの差で、 1度に消費できるスループット量が決まる 46
• 47. スループットが足りないときの挙動 •getItem(1件の取得)であれば、回復まで 待たされるかタイムアウトする •query(複数件の取得)の場合、残量ぶんの Itemを読み込んだらその次点で結果セッ トを返す •ゆえに、複数取得では1リクエストで全て のItemを取得できないことがある 47
• 48. 複数取得では再帰実行が必須 •複数件を確実に取得するには、再帰的な 処理を仕込む必要がある •APIの返り値に追加読み込み用の項目があ るので、それを元に再帰実行するかを判 断できる •結果セットの容量に1MBの制限があり、 こちらも同様の考慮が必要になる 48
• 49. スループットのオートスケーリングは無い •DynamoDBの機能としてのオートスケー リングは無く、サードパーティ製のスケー ラがあり、公式から推奨されている •KVS的な利用に限定していれば、そこそこ の規模まで十分安く運用できるのでオート スケールは最初は気にしなくていい •スケールアップ回数は無限だが、スケール ダウンは1日4回まで 49
• 50. 隠れスループットの存在 •設定値とは別に隠れたスループットが用意 されており、ユーザーも使用可能 •ただしこれはAWS側がメンテナンスのた めに用意したスループットなので、いつで も使えることを期待してはいけない •とはいえ開発環境用の小さなスループット 設定のテーブルに対してバッチ実行をする ときなどに、スループットがバーストして いるように振る舞うのでそこそこ便利 50
• 51. スケーラビリティの確保 51
• 52. スケールに必要な前提とは •ハッシュアクセスを分散させる •パーティションの分割を想定する 52
• 53. ハッシュアクセスを分散させる •同一HASHへの連続した書き込みは、分 散したHASH書き込みに比べて性能が低 い •PVや投票のような激しい書き込み用途に 使う際は、HASHを分割して保存するな ど工夫が必要 •RANGEが異なってもHASHが同じ場合は、 同一HASHとみなされる 53
• 54. パーティションの分割を想定する •容量もしくはプロビジョニング量によってデータ が複数のパーティションに分割され、プロビジョ ニングされたスループットはパーティションごとに 均一に振り分けられる •パーティション分割は容量が10GB単位、スループッ トは RCUを3000で割った数とWCUを1000で割っ た数の合算値で決まる •パーティションが複数で、アクセスされるハッシュ が偏ると、スループットを使い切れない場合がある 54
• 55. 容量増加で性能低下する場合がある •10GBと3,000 RCUはそうそう到達しないが、 それでも想定する必要はある。特に容量 •アンサーではコメントデータをDynamoDB に同期しているが、20GBを超えており3パー ティション化されている •アンサーのコメントはHASHがスポットID、 RANGEがコメントIDになっている •スポットIDへのアクセスは十分に分散してい るので、スループットを使いきれている 55
• 56. インデックスの特性 56
• 57. インデックスの実態は「自動で作られる別のテーブル」 •ローカルセカンダリインデックス(LSI)も、 グローバルセカンダリインデックス(GSI) も、実態としては「別のテーブル」 •インデックスに対して読み込みにおいて できることは HASH+RANGE テーブル にできること以下になる •多少の例外はあるが、やはり基本はテー ブルと同じ 57
• 58. LSIの特性 •LSIの実態は「テーブルと同じHASHで別 のRANGEを持った複製テーブル」 •例えばテーブルの定義ではRANGEを「作 成日」にして、LSIでは「更新日」にする など •複製したぶんだけ容量が増え、書き込み スループットも追加で要する •スループットはテーブルと共有する 58
• 59. LSIの制限 •LSIはテーブル作成時にしか定義できない のでよーく考えてつけるべき •作成出来るLSIはテーブルあたり5つまで •LSIは「強い整合性」での読み込みが出来 る（ラグなしで読み込める） •アンサーではまともに使っている箇所は ない 59
• 60. GSIの特性 •GSIの実態は「選択したカラムをHASHと して複製したテーブル」 •RANGEありなし、どちらもOK •例外として、GSIではHASH or HASH+RANGEはユニークでなくても別々 のItemとして保存され、参照可能 •スループットは独自に設定する 60
• 61. GSIの制限 •テーブルとLSIでは1HASHあたり10GB の容量制限があるが、GSIには無い •テーブル作成後でも作れるし削除できる •作成出来るGSIはテーブルあたり5つまで •「強い整合性」での読み込みが出来ない （ラグの発生を前提にしなければならな い） 61
• 62. インデックスにも十分なスループットが必要 •書き込みリクエストにおいて、インデッ クス側のみスループットが足りないとき でも、テーブルへの書き込み性能が低下 する。 •インデックスの作り方によってはHASH が集中するので、HASH集中による性能 低下が起きないか注意が必要 62
• 63. インデックスの運用は結構難しい •追加の書き込みスループットが必要 •とりあえず作っておけばいいものではな い •RDBとの併用を考えるべき 63
• 64. インポートのベストプラクティス 64
• 65. マネジメントコンソールからインポートできる •マネジメントコンソールから簡単にイン ポート操作が行える 65
• 66. インポートの動作 •DataPipelineとして動作する •インポートするファイルはS3を経由する •インポート速度（スループット消費量） は指定できる 66
• 67. データフォーマットはマニュアルに載ってる •PHP SDKにエクスポート用のデータ列に フォーマットして返す機能は見つけられ なかった •フォーマットはシンプルなので、マニュ アル通りに自分でフォーマットすればよ い •「AWS Data Pipeline」の項目に記載さ れている 67
• 68. データフォーマット •STX/ETX/LF で区切られたそこそこシン プルな行指向データ 「データエクスポートファイルの確認」
 で検索するとヒットするはず 68
• 69. HASH分散しないと速度がでない •素朴に時系列でデータを並べてインポート したらスループットを使い切れなかった •サポートに問い合わせると、同一HASHへ の連続した書き込みが起きていて使い切っ てないようだ、というアドバイスを得た •HASHを分散して並べたデータをインポー トさせたらちゃんとスループットが出た •HASH分散超大事 69
• 70. HASH集中してるデータをインポートするには •そうはいってもどうしてもHASHが集中し ているデータをインポートする場合がある •その場合はゆっくりじっくり時間をかけて インポートするしかない…と思う •アンサーで行ったのは最大で10日間 •インポート時にはタイムアウト時間を設定 する必要があり、UIからは9999時間まで 設定できそう 70
• 71. バックアップは難しい 71
• 72. マスターデータのバックアップをどうするか •DynamoDB はレプリカやユーザーセッ ションとして使い始めた •どちらもDynamoDB自体のバックアップ は不要 •慣れてきたのでDynamoDBをマスターデー タとして使い始めてみた •そういえばバックアップはどうしよう？ 72
• 73. DynamoDBのバックアップに銀の弾丸なし •結論として、大容量のテーブルに大して は、現状で簡単なソリューションは無い •全てのデータを読み込むことはできるが、 現実的な時間で完了させるにはスルー プット消費がとんでもないことになる •「データ全体にアクセスする」「大量の Itemを一気に読み込む」といった要件に ついて、DynamoDBは無頓着っぽい 73
• 74. データが消えることは無いはず •3つのAZに複製されるのでItemが消える ことはないはず •大量のItemを一度に消す方法はテーブル 削除以外にはないので、誤操作のリスク は限定的 •誤操作はIAMの権限で防止しよう 74
• 75. データの向き不向き 75
• 76. DynamoDBに向いているデータ •例えば、スレッド型掲示板のコメント、 ユーザーの行動ログ •遅延が許されない要件 •何らかの順序で小さく分割可能 •アクセスが分散すること •際限なく増えるデータ 76
• 77. DynamoDBに向いていないデータ •インデックスの必要性が高い •データ全体の走査が必要 77
• 78. おすすめの学習方法 78
• 79. SlideShareのDynamoDB関係資料を通読 •AWS マイスターシリーズ •AWS Black Belt Techシリーズ •Deep Dive •公式以外も有用なものが多い 79
• 80. 「よくある質問」の通読 •マジでよく書かれてる •サポートに質問していた内容がほとんど すべて載っていた 80
• 81. 手を動かす •悩んだらテーブルを作ってクエリを打つ •マネジメントコンソールからデータを編 集できる •単発のクエリは aws cli が便利 81
• 82. DynamoDBを今後も使うか 82
• 83. DynamoDBは今後も使いたい •使ってみてよかった。簡単にスケールす るインフラは素敵だ •KVS的な要件があれば今後も積極的に使 いたい •前提さえ守れば運用はスループットを監 視するだけなので手間が少ない •将来的に AWS Lamda との併用も魅力 83