ビッグデータだけじゃない Amazon DynamoDBの活用事例

1. ビッグデータだけじゃない！ Amazon DynamoDBの活用事例 Cassandraから DynamoDBへの移行で見えたその特徴 2014.07.17 サイバーエリアリサーチ株式会社中西健 TC-01

2. 中西健（なかにしけん） – ken@arearesearch.co.jp サイバーエリアリサーチ株式会社 – 「どこどこJP」サービス担当データベースエンジニア最近気になっているAWSサービス – Amazon Kinesis 自己紹介

3. 弊社サービスのご紹介 Cassandraシステム運用時の課題 DynamoDBについて実装とチューニングコスト比較まとめアジェンダ

4. 弊社サービスのご紹介

5. アクセスユーザーの地域認識技術であるIPジオロケーションデータベース「SURFPOINT」を提供する、国内オンリーワン企業 – http://www.arearesearch.co.jp/ IPジオロケーション技術 – インターネットに接続されたコンピューター等に割り当てられたIPアドレスから、アクセスユーザーの位置情報やインターネット接続環境を認識・マッピングするための技術。 – インターネット広告配信・コンテンツ配信制御・アクセス解析 – 銀行・証券取引におけるオンラインセキュリティ分野での利用も注目を集めています。サイバーエリアリサーチ株式会社

6. IPジオロケーション情報を提供するWebAPI – IPアドレスに「位置情報・組織情報・回線情報・気象情報」など最大74種類の属性を紐付け – 出力フォーマット：XML、JSON、JavaScript – 用途：コンテンツ配信制御、アクセス解析、不正検出バックエンドに「SURFPOINT」データ – 全世界分のIPv4アドレスに対応 – １IPアドレス単位で属性情報の修正に対応１IP＝１レコードでデータを保持しておきたい「どこどこJP」サービス

7. 「どこどこJP」サービス http://api.docodoco.jp/v4/search? key1=APIキー1&key2=APIキー2&ipaddr=IPアドレス

8. Cassandraシステム運用時の課題

9. Cassandraとは – NoSQLのオープンソース製品 – USではメジャーな製品で、スケーラビリティと高可用性が特徴構成 – オンプレ 6ノード、各ノード2TBx4のRAID0 – 42億レコードのIPアドレス属性情報 – データベース中のデータ量は実効1.5TB程度旧Cassandraシステムの構成

10. 高負荷 / イマイチな安定性 – ガベージコレクションのメモリ負荷＆ディスク負荷 – 結果、データ取得をミスする / ノードがDownする – テーブル設計にも問題があった焼津IDC~お客様システム間のレイテンシへの懸念今後のシステム拡張におけるコスト面への懸念 × 別のIDCにCassandraシステムのコピーを構築 → 解決にならない旧Cassandraシステムの課題

11. 速度面・安定性を重視したい多くのアドテク界隈のお取引先がすでにAWS環境上にシステム構築でもDBはどうしたらいいだろう？ – CassandraをEC2上で構築する? → 解決にならない解決策

12. 「DynamoDB, あります」レコード数40億以上なんですけど… 「へっちゃらです」データ量500GB位になりそうなんですけど… 「へっちゃらです」レスポンスが遅いと怒られるんですけど… 「問題ありません」 DynamoDB

13. DynamoDBについて …公式プレゼンから抜粋してざっくりとご紹介

14. DynamoDBの特徴 “NoSQL as a Service” 管理不要で信頼性が高いプロビジョンドスループットストレージの容量制限がない ※「AWS Black Belt Techシリーズ Amazon DynamoDB」等より

15. SPOFの存在しない構成データは3箇所のAZに保存されるので信頼性が高いストレージは必要に応じて自動的にパーティショニングされる特長１：管理不要で信頼性が高いクライアント

16. ReadとWrite、それぞれに対して必要な分だけのスループットキャパシティをプロビジョンする（割り当てる）ことができる一般的なReadヘビーなDBなら • Read : 1,000、Write : 100 WriteヘビーなDBなら • Read : 500、Write : 500 この値はDB運用中にオンラインで変更可能 – ただし、スケールダウンに関しては日に４回までしかできない特長２：プロビジョンドスループット

17. 使った分だけの従量課金制のストレージデータ容量が増えてきたのでディスクを足したり、ノードを足したりという作業が不要データの保存はSSDに対して行われる特長３：ストレージの容量制限がない

18. プロビジョンドスループットで決まる時間料金 – Read/Writeそれぞれプロビジョンしたスループットによって時間あたりの料金がきまる – 大規模に利用するのであればリザーブドによる割引もありストレージ利用量 – 保存したデータ容量によって決まる月額利用料金 – 計算はGBあたりの単価が適用される DynamoDBのシンプルな料金体系実際の料金については下記を参照 http://aws.amazon.com/jp/dynamodb/pricing/

19. ちょっとブレイク「ビッグデータ」と「どこどこJP」

20. 「ビッグデータ」どこどこJP レコード数データ量レコード数は巨大増大し続けるデータレコード数は巨大データ量の変化は小 Write 常に書き込みが発生定期的・比較的少量 Read 複雑なクエリや分析クエリは単純１レコードを返信「ビッグデータ」との比較

21. DynamoDBへの実装とチューニング

22. IP情報テーブル地域情報テーブル組織情報テーブル属性情報テーブルの分割 22 ・ 36億レコード・ 500GB ・ 60万レコード・ 500MB ・ 120万レコード・ 800MB

23. 公式 AWS SDK for PHP version 2 を使用参考：“Performance Guide” http://docs.aws.amazon.com/aws-sdk-php/guide/latest/performance.html – PHPを5.4以上にアップグレード – PHP5.5を使う / APCのようなOpcodeキャッシュを使う – Classmap autoloader “Composer” を使う速度追求部分には非公式PHPライブラリで対応 – “php-simple-amazon-dynamodb” https://github.com/ttsuruoka/php-simple-amazon-dynamodb チューニング（１） 23

24. 95rps : C1.medium, NginX, 公式SDK, preloader適用前 131rps : C1.medium, NginX, 公式SDK, preloader有効 731rps : C1.medium, NginX, 非公式ライブラリ 109rps : C1.medium, Apache, 公式SDK, preloader適用前 132rps : C1.medium, Apache, 公式SDK, preloader有効 419rps : C1.xlarge, Apache, 公式SDK, preloader有効 1183rps :C1.xlarge, Apache, 非公式ライブラリチューニング（２）

25. 現在のシステム構成 IP DynamoDB Geo Org お客様AWS環境天気お客様システムデータ更新監視アカウント管理フォーマット変換

26. RDBMS的にはよくある処理が一発で完了できない「全レコード一括削除」「テーブル名変更」スループット消費し地道に処理するしかない場合も速い？速くない？ HTTP通信のオーバーヘッドは無視できない複数並列処理が大前提処理の得意不得意はありますキー / ハッシュの設計はよく考えないと！ DynamoDB以外のサービスと結合して実現する手も DynamoDB：ここが不満 26

27. アプリケーションの移植負荷は？ 27 移植自体はそこまで手間はかからなかったテストは少しハマった – 負荷テストにApacheBenchを使用したが・・・ DynamoDBのスループットを可変にした – プロビジョンドスループットはできるだけ抑えてケチりたい – 指定したスループットを超えた場合でもなんとかしたい

28. DynamoDBの負荷テスト

29. 謎の挙動：最初の数十秒だけ高性能 http://localhost/rest.php?ip=220.216.104.1 (結果の例) – 1回目結果 = 1200req/s – 2回目結果 = 240req/s エラー出まくり – しばらく時間をおくと、性能が復旧する ?? ⇒ DynamoDBの内部データ構造に起因負荷テストに ab コマンドを使った結果

30. DynamoDBの内部データ構造 ※「AWS Black Belt Techシリーズ Amazon DynamoDB」より

31. DynamoDBの内部データ構造

32. DynamoDBの自動スケーリング

33. 公式SDKを使いCapacityUnitsを読み書きスループットを上げる条件 – 利用率が 80% を超えていたら ⇒ CapacityUnit を現在の150%に上げるスループットを下げる条件 – 利用率が 25% 以下の状態が2時間(5分間隔×24回)継続 ⇒ CapacityUnit を現在の25%に下げる DynamoDBの自動スケーリング 33 $x = $dynamo->getreadCapacityUnits( $tableName ); $x = $dynamo->getwriteCapacityUnits( $tableName ); $x = $dynamo->getConsumedReadCapacityUnits( $tableName ); $x = $dynamo->getConsumedWriteCapacityUnits( $tableName );

34. 自動スケーリングの実行例 34 プロビジョンしたスループット実際に消費したスループット

35. 自動スケーリングの実行例 35

36. 自動スケーリングの実行例 36

37. 一方、書き込みスループットは自動スケーリングの実行例

38. 「ビッグデータ」との比較「ビッグデータ」 SURFPOINT レコード数データ量レコード数は巨大増大し続けるデータレコード数は巨大データ量の変化は小 Write 常に書き込みが発生定期的・比較的少量 Read 複雑なクエリや分析クエリは単純１レコードを返信コスト↓ コスト↓

39. コスト比較オンプレミス環境でのシステム構築 vs AWS環境でのシステム構築

40. オンプレミス環境 AWS環境開発期間約18カ月約6カ月初期費用約300万円ほぼ０円ランニングコスト月額約15万円月額約15万円比較

41. 開発期間：約18カ月 – 本番サーバースペック選定のための実証テスト – サーバー機の調達 / 200v電源は確保できるのか？初期費用：約300万円 – Cassandraノード用 x86サーバー 6台 – API提供用 x86サーバー 4台などランニングコスト：月額約15万円 – IDC費用（設置場所＋電源＋ネットワーク） – ファイヤーウォールやロードバランサーのコストは別オンプレミス環境でのシステム構築に要したコスト

42. 開発期間：約6カ月 – （注）旧システムから仕様/プログラムの一部を継承初期費用：ほぼ０円 – AWSサインアップ → 無料利用枠を活用ランニングコスト：月額約15万円 – 「どこどこJP」EC2インスタンスやELBの費用を含む – DynamoDB単体での利用料金は月額 5万円弱 AWS環境でのシステム構築に要したコスト

43. $0 $1,000 7月度 8月度 9月度 10月度 11月度 12月度 (1月度) 仕様検討開発実データ投入負荷テストチューニングテスト環境公開サービス開始→ → → 36億件投入 AWS環境でのシステム構築に要したコストコスト↓

44. まとめ

45. 本番サーバースペック選定のための実証テスト – スペック見積や電源確保がいらない – microインスタンスでいきなりプロトタイプ開発を開始 – 様子を見つつインスタンスタイプを変更システム構築完了から売上計上まで間のコスト – 負荷テスト終了後、一旦 ”休眠状態” にさせておいたインフラ調達に関わるコストやリスク – 万が一の際(?)にもすぐにサービス撤収ができる安心感 AWSへのシステム移行で悩まなくて済んだこと 45

46. オンプレミス環境からAWS環境へ移行 – 要求事項を考慮し DynamoDB を選択 – 時間的・金銭的コストを大幅削減 – ビジネスの成長に伴うインフラ不安からの解放「DynamoDBを導入したので、休日に安心して外出できるようになりました」まとめ

47. おまけ・・・新しい悩み

48. 「有効活用を考えてよ!」 (^▽^;)

49. ご静聴ありがとうございました！

SlideShare for iOS

ビッグデータだけじゃない Amazon DynamoDBの活用事例

by Ken Nakanishi

on Jul 25, 2014

Statistics

Views

Actions

1 Embed 9

Accessibility

Categories

Upload Details

Usage Rights

Report content

ビッグデータだけじゃない Amazon DynamoDBの活用事例 Presentation Transcript