[よくわかるクラウドデータベース] CassandraからAmazon DynamoDBへの移行事例

© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.

サイバーエリアリサーチ様における

CassandraからAmazon DynamoDBへの移行事例

2014.01.17

アマゾンデータサービスジャパン株式会社

エマージングソリューション部

部長/ソリューションアーキテクト

大谷晋平([email protected])


2

自己紹介

大谷晋平

• [email protected]

• @shot6

アマゾンデータサービスジャパン所属

• 技術本部エマージングソリューション部

• 部長/ソリューションアーキテクト

好きな言葉

• Less is More

好きなAWSサービス

• S3

• DynamoDB

mailto:[email protected]


3

アジェンダ

DynamoDBとは

サイバーエリアリサーチ様について

どこどこJPとは

CassandraからDynamoDBへの移行

コスト比較

今後の課題

まとめ


4

DynamoDBとは


5

DynamoDBとは

NoSQL as a Service

超高速・予測可能な一貫したパフォーマンス

シームレスなスケーラビリティ、そして低コスト

運用管理必要なし

低レイテンシ、SSD

プロビジョンスループット

無限に使えるストレージ


6

DynamoDBの生い立ち

Amazon.comではかつて全てのアクセスパターンをRDBMSで処理していた

規模が大きくなるにつれて、RDBMSの課題に直面

• スケーラビリティ

• 処理能力を向上させるのが難しい。データの再配置、より大きなHWを導入するなどの対処が必要。

• 可用性

• RDBMSは可用性よりもデータの整合性を重視する設計

• トランザクション処理が不要な場面でも、全てはトランザクションとして処理されるパフォーマンスのオーバーヘッド大


7

DynamoDBの生い立ち

RDBMSの課題に対処するため、Amazon Dynamo (DynamoDBの先祖)を設計・開発

Amazon Dynamoの特長

• ベネフィット

• 結果整合性モデル採用による可用性向上

• HWを追加する毎に性能が向上するスケーラビリティ

• クエリーモデルが単純なためパフォーマンスが予測できる

• 妥協点

• 強い整合性モデルではない

• スケールアップの際にHWの追加やクラスタのリバランスが必要

• 開発者がDB管理作業から開放されるわけではない ”Amazon S3のようなサービスとして使いたい”という声


8

DynamoDBの誕生

AWS上に「サービス」として構築

パフォーマンスのためにデータの堅牢性・可用性を妥協しない

常に低レイテンシーで応答を返す

開発者（利用者）はスケーラビリティを気にしなくて良く、いつでも簡単に増減できる

サーバーやディスク台数ではなく、シンプルに必要な読み書きの性能数値を指定するだけ

管理作業が不要


9

DynamoDBの特徴

管理不要で信頼性が高い

プロビジョンスループット

ストレージの容量制限がない


10

特長１：管理不要で信頼性が高い

SPOFの存在しない構成

データは3箇所のAZに保存されるので信頼性が高い

ストレージは必要に応じて自動的にパーティショニングされる

クライアント


11

特長２：プロビジョンスループット

ReadとWrite、それぞれに対して必要な分だけのスループットキャパシティをプロビジョンする（割り当てる）ことができる

例えば一般的なReadヘビーなDBなら • Read : 1,000

• Write : 100

ライトヘビーなDBなら • Read : 500

• Write : 500

この値はDB運用中にオンラインで変更可能 • ただし、スケールダウンに関しては日に４回までしかできない

ので注意


12

特長３：ストレージの容量制限がない

使った分だけの従量課金制のストレージ

データ容量が増えてきたのでディスクを足したり、ノードを足したりという作業が不要


13

DynamoDBのシンプルな料金体系

プロビジョンスループットで決まる時間料金 • Read/Writeそれぞれプロビジョンしたスループットによって時

間あたりの料金がきまる

• 大規模に利用するのであればリザーブ度による割引もあり

ストレージ利用量 • 保存したデータ容量によって決まる月額利用料金

• 計算はGBあたりの単価が適用される

実際の料金については下記を参照 http://aws.amazon.com/jp/dynamodb/pricing/

http://aws.amazon.com/jp/dynamodb/pricing/




14

DynamoDBを使い始めるには

1. テーブルのKeyやIndexを決める

2. Read/Writeそれぞれのスループットを決める

That’s it, write your code!




16



17

サイバーエリアリサーチ様

アクセスユーザーの地域認識技術であるIPジオロケーションデータベース「SURFPOINT」を提供する、国内オンリーワン企業様。 • http://www.arearesearch.co.jp/

IPジオロケーション技術とは？ • インターネットに接続されたコンピューター等に割り当てられ

たIPアドレスから、アクセスユーザーの位置情報やインターネット接続環境を認識・マッピングするための技術。

• インターネット広告配信・コンテンツ配信・アクセス解析をはじめ、幅広い分野において利用されています。さらに近年では、銀行・証券取引におけるオンラインセキュリティ分野での利用も注目を集めています。

• 専任スタッフで調査を基に定期的なデータベース更新を行う


18

SURFPOINT™ for DMPにおける CassandraからDynamoDBへの移行


19

SURFPOINT™ for DMPとは？

IPアドレスに「位置情報・組織・回線」など55種類*のデータを紐付けたデータベース。

位置情報のみならず、企業名・業種・上場区分や従業員数・売上高・資本金コードなどの企業情報を含めたIPアドレスベースのデータを提供し、より付加価値の高い情報を提供できる

日本国内では全IPアドレスをカバーし、全世界約43億のIPv4アドレスに対応しています。

http://www.surfpoint.jp/dmp/index.html#hero2






20

現状のSURFPOINTの課題

システムへの高負荷 / イマイチな安定性

• データ取得ミス / データ更新への影響

• Cassandra 6ノードを利用

焼津IDC~お客様システム間のレイテンシ

システム拡張におけるコスト面での懸念

→AWSが検討の材料に上がる


21

Cassandraの構成

Cassandraとは

• NoSQLのオープンソース製品

• USではメジャーな製品で、スケーラビリティと高可用性が特徴

構成と現状

• オンプレ 6ノード、各ノード2TBx4のRAID0

• DBは実効3TB程度、42億件のIPアドレス情報

• リクエストには12.2KBのXMLを返す。

課題

• 参照負荷に耐えられていない

• 時々Keyに対してValueを返さないなど、暴れがち。

→運用管理に大きな負荷がかかっていた


22

解決案

別のIDCに現システムのコピーを構築

• Cassandraシステムを複製しても根本的解決にならない

多くのアドテクのお取引先が、すでにAmazonクラウド上にシステム構築

• AWS上で作ったらどうだろう？

• システム構成をAWSの機能にあわせる


23

解決策

速度面・安定性を重視

IP属性データ提供サービスとして構築

× アクセス数に応じた従量課金

× 管理画面

でもDBはどうしたらいいだろう？

• CassandraをEC2上で構築する？

• 他に選択肢は？


24

24

DynamoDBを検討

DynamoDB

DynamoDB

同時Read数/同時Write数に応じて課金

データ量への課金は今回あまり影響しない

並列読み込み・書き込みが前提

テーブル構成の変更

IPアドレス

地域属性組織属性


25

属性情報テーブルの分割

25

・ 42億レコード・ 500GB

・ 36万レコード・ 300MB

・ 100万レコード・ 600MB


26

26

テスト１

Amazon EC2

DynamoDB

Client

c1.xlarge

AmazonLinux

NginX + php-fpm + APC

PHP + AWS sdk

Readスループット＝80

Writeスループット＝10


27

27

テスト2

管理サーバー

DynamoDB

EC2 ( c1.xlarge )

AmazonLinux

NginX + php-fpm

PHP + AWS sdk

監視

XML出力

データ

rea

d/w

rite

お客様システム

お客様システム


28

28

チューニング（１）

Amazon EC2

DynamoDB

Client

c1.xlarge

AmazonLinux

NginX + php-fpm + APC

PHP + AWS sdk

Readスループット＝80

Writeスループット＝10

https(SSL接続)で通信している →httpで通信するよう変更


29

95rps : C1.medium, NginX, 公式sdk, preloader適用前

131rps : C1.medium, NginX, 公式sdk, preloader有効

731rps : C1.medium, NginX, 非公式sdk

109rps : C1.medium, Apache, 公式sdk, preloader適用前

132rps : C1.medium, Apache, 公式sdk, preloader有効

419rps : C1.xlarge, Apache, 公式sdk, preloader有効

1183rps : C1.xlarge, Apache, 非公式sdk

チューニング（２）


30

今回のシステム構築で悩まなくて済んだこと

本番サーバースペック選定のための実証テスト • microインスタンスでいきなりプロトタイプ開発を開始

• 様子を見つつインスタンスタイプを変更

システム構築完了から売上計上までのコスト • 負荷テスト完了後、一旦”休眠状態”にさせておくことができた

インフラ調達に関わるコストやリスク • 万が一(?)の際にもすぐにサービス撤収ができる・・・のも事実

30


31

アプリケーションの移植負荷は？

移植自体はそこまでかからなかった

テスト自身もそこまでかからなかった

DynamoDBのプロビジョンスループット • 万が一、指定したプロビジョンスループットを超えた場合でもきちん

と対応したい

• →自前でオートスケール部分をやや作りこんだ

31


32

32

工夫した点：DynamoDB オートスケール

$x = $dynamo->getreadCapacityUnits( $tableName ); $x = $dynamo->getwriteCapacityUnits( $tableName ); $x = $dynamo->getConsumedReadCapacityUnits( $tableName ); $x = $dynamo->getConsumedWriteCapacityUnits( $tableName );

公式SDKを使い、CapacityUnitsを読み書き CapacityUnitsを

読み書きする wrapper関数を書きました

CapacityUnitsを上げる条件：

CapacityUnitsを下げる条件：

CapacityUnit 利用率が 80% を超えていたら ⇒ CapacityUnit を現在の200%に上げる

CapacityUnit 利用率が 25% 以下の状態が2時間(5分間隔×24回）継続したら ⇒CapacityUnit を現在の25%に下げる


33

33

オートスケーリングの実行例

プロビジョンしたIOPS

実際に消費したIOPS


34

34

オートスケーリングの実行例


35

35

自動的なスケーリングの実行例


36

36

バースト的トラフィックが発生した時


37

37

CloudWatch

監視可能な値「ネットワークトラフィック」「今月の課金金額」などなど値を指定してアラートを上げる事が出来る公式SDKで読み書きすることができる


38

現在のシステム構成

IP 地域組織

管理用 / XML出力

お客様Server

極めてシンプルな構成 DynamoDBのスケールを十二分に活かすオートスケールする工夫で手間いらず AWS上の多数お客様もそのまま利用可能


39

今後の構成

お客様EC2

お客様Server

IP 地域組織天気株価・・・

管理用EC2


40

コスト比較


41

旧Cassandraシステム構築時にかかった費用

開発期間：約18カ月 • 本番サーバースペック選定のための実証テスト

• サーバー機の価格交渉・ 200v電源は確保できるのか？

• などなど

初期コスト：ざっと数100万円 • Cassandraノード用x86サーバー ×6台

ランニングコスト：月額数10万円 • IDC費用（設置場所＋電源＋ネットワーク）

• 加えて、ファイヤーウォールやロードバランサーのコスト


42

$0

$1,000

7月度 8月度 9月度 10月度 11月度 12月度 (1月度)

DynamoDB利用でかかった期間と費用

仕様検討

開発

実データ投入

負荷テスト

チューニング

テスト環境公開サービス開始 → → →

41億件すべて投入


43

費用見積もり

10億res/月を処理するシステムのAWS費用見積もり

データ転送量（AWS外部へ送信）は「1レスポンス３KB」として計算


44

比較

CassandraでのTCO • 開発期間18か月の人的コスト＋初期ハードウェアコスト300万円

(＋α)＋ランニングコスト月額15万円(＋α)

DynamoDBでのTCO(1ドル100円換算) • 初期データ投入コスト約20万円＋月額15万円

差分 • 開発期間18か月分人的コストとハードウェアコスト300万円(+α)

• 18か月というリードタイム

ご参考 • DynamoDBのリザーブドキャパシティで更にお得に！

• http://aws.amazon.com/jp/dynamodb/pricing/


45

まとめ


46

サイバーエリアリサーチ様はCassandraからDynamoDBへ移行 • 時間的・金銭的コストを大幅削減

• シンプルなアーキテクチャ

• ビジネスの成長に伴うインフラ不安からの解放

「DynamoDBを導入したので、温泉旅行にいけるようになりました」

まとめ


47

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

Technology

[よくわかるクラウドデータベース] CassandraからAmazon DynamoDBへの移行事例