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

サイバーエリアリサーチ様における
CassandraからAmazon DynamoDBへの
移行事例
2014.01.17
アマゾンデータサービスジャパン株式会社
エマージングソリューション部
部長/ソリューションアーキテクト
大谷晋平(ohtani@amazon.com)
© 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.

自己紹介
大谷晋平
• ohtani@amazon.com
• @shot6

アマゾンデータサービスジャパン所属
• 技術本部エマージングソリューション部
• 部長/ソリューションアーキテクト

好きな言葉
• Less is More

好きなAWSサービス
• S3
• DynamoDB
2

アジェンダ
DynamoDBとは
サイバーエリアリサーチ様について
どこどこJPとは
CassandraからDynamoDBへの移行
コスト比較
今後の課題
まとめ
3

DynamoDBとは

4

DynamoDBとは
NoSQL as a Service
超高速・予測可能な一貫したパフォーマンス
シームレスなスケーラビリティ、そして低コスト
運用管理必要なし
低レイテンシ、SSD
プロビジョンスループット

無限に使えるストレージ

5

DynamoDBの生い立ち
Amazon.comではかつて全てのアクセスパターンを
RDBMSで処理していた
規模が大きくなるにつれて、RDBMSの課題に直面
• スケーラビリティ
• 処理能力を向上させるのが難しい。データの再配置、より大きな
HWを導入するなどの対処が必要。

• 可用性
• RDBMSは可用性よりもデータの整合性を重視する設計
• トランザクション処理が不要な場面でも、全てはトランザクション
として処理される
パフォーマンスのオーバーヘッド大

6

DynamoDBの生い立ち
RDBMSの課題に対処するため、Amazon Dynamo
(DynamoDBの先祖)を設計・開発
Amazon Dynamoの特長
• ベネフィット
• 結果整合性モデル採用による可用性向上
• HWを追加する毎に性能が向上するスケーラビリティ
• クエリーモデルが単純なためパフォーマンスが予測できる

• 妥協点
• 強い整合性モデルではない
• スケールアップの際にHWの追加やクラスタのリバランスが必要
• 開発者がDB管理作業から開放されるわけではない
”Amazon S3のようなサービスとして使いたい”という声
7

DynamoDBの誕生
AWS上に「サービス」として構築
パフォーマンスのためにデータの堅牢性・可用性を妥協
しない
常に低レイテンシーで応答を返す
開発者（利用者）はスケーラビリティを気にしなくて良
く、いつでも簡単に増減できる
サーバーやディスク台数ではなく、シンプルに必要な読
み書きの性能数値を指定するだけ
管理作業が不要

8

DynamoDBの特徴

管理不要で信頼性が高い
プロビジョンスループット
ストレージの容量制限がない

9

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

クライアント

10

特長２：プロビジョンスループット
ReadとWrite、それぞれに対して必要な分だけのスルー
プットキャパシティをプロビジョンする（割り当てる）
ことができる
例えば一般的なReadヘビーなDBなら
• Read : 1,000
• Write : 100

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

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

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

12

DynamoDBのシンプルな料金体系

プロビジョンスループットで決
まる時間料金
• Read/Writeそれぞれプロビジョンしたスループットによって時
間あたりの料金がきまる
• 大規模に利用するのであればリザーブ度による割引もあり

ストレージ利用量
• 保存したデータ容量によって決まる月額利用料金
• 計算はGBあたりの単価が適用される
実際の料金については下記を参照
http://aws.amazon.com/jp/dynamodb/pricing/
13

DynamoDBを使い始めるには

1. テーブルのKeyやIndexを決める
2. Read/Writeそれぞれのスループッ
トを決める

That’s it, write your code!

14


16

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

IPジオロケーション技術とは？
• インターネットに接続されたコンピューター等に割り当てられ
たIPアドレスから、アクセスユーザーの位置情報やインター
ネット接続環境を認識・マッピングするための技術。
• インターネット広告配信・コンテンツ配信・アクセス解析をは
じめ、幅広い分野において利用されています。さらに近年では、
銀行・証券取引におけるオンラインセキュリティ分野での利用
も注目を集めています。
• 専任スタッフで調査を基に定期的なデータベース更新を行う
17

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

18

SURFPOINT™ for DMPとは？
IPアドレスに「位置情報・組織・回線」など55種類*の
データを紐付けたデータベース。
位置情報のみならず、企業名・業種・上場区分や従業員
数・売上高・資本金コードなどの企業情報を含めたIPア
ドレスベースのデータを提供し、より付加価値の高い情
報を提供できる
日本国内では全IPアドレスをカバーし、全世界約43億の
IPv4アドレスに対応しています。

19

現状のSURFPOINTの課題
システムへの高負荷 / イマイチな安定性
• データ取得ミス / データ更新への影響
• Cassandra 6ノードを利用

焼津IDC~お客様システム間のレイテンシ
システム拡張におけるコスト面での懸念
→AWSが検討の材料に上がる

20

Cassandraの構成
Cassandraとは
• NoSQLのオープンソース製品
• USではメジャーな製品で、スケーラビリティと高可用性が特徴

構成と現状
• オンプレ 6ノード、各ノード2TBx4のRAID0
• DBは実効3TB程度、42億件のIPアドレス情報
• リクエストには12.2KBのXMLを返す。

課題
• 参照負荷に耐えられていない
• 時々Keyに対してValueを返さないなど、暴れがち。
→運用管理に大きな負荷がかかっていた
21

解決案
別のIDCに現システムのコピーを構築
• Cassandraシステムを複製しても根本的解決にならない

多くのアドテクのお取引先が、すでにAmazonクラウド
上にシステム構築
• AWS上で作ったらどうだろう？
• システム構成をAWSの機能にあわせる

22

解決策

速度面・安定性を重視
IP属性データ提供サービスとして構築
× アクセス数に応じた従量課金
× 管理画面
でもDBはどうしたらいいだろう？
• CassandraをEC2上で構築する？
• 他に選択肢は？
23

DynamoDBを検討
DynamoDB
同時Read数/同時Write数に応じて課金
データ量への課金は今回あまり影響しない
並列読み込み・書き込みが前提
テーブル構成の変更

IPアドレス
DynamoDB
地域属性

組織属性

24

24

属性情報テーブルの分割

・ 42億レコード

・ 36万レコード

・ 100万レコード

・ 500GB

・ 300MB

・ 600MB

25

25

テスト１
Amazon EC2
c1.xlarge
AmazonLinux
NginX + php-fpm + APC
PHP + AWS sdk
Client

Readスループット＝80
Writeスループット＝10

DynamoDB

26

26

テスト2
管理サーバー
EC2 ( c1.xlarge )
AmazonLinux
NginX + php-fpm
PHP + AWS sdk

XML出力

監視

データread/write

お客様システム

お客様システム

DynamoDB

27

27

チューニング（１）
Amazon EC2
c1.xlarge
AmazonLinux
NginX + php-fpm + APC
PHP + AWS sdk
Client

https(SSL接続)で通信している
→httpで通信するよう変更
Readスループット＝80
Writeスループット＝10

DynamoDB

28

28

チューニング（２）
1183rps : C1.xlarge, Apache, 非公式sdk

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

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

132rps : C1.medium, Apache, 公式sdk, preloader有効
131rps : C1.medium, NginX, 公式sdk, preloader有効
109rps : C1.medium, Apache, 公式sdk, preloader適用前
95rps : C1.medium, NginX, 公式sdk, preloader適用前
29

今回のシステム構築で悩まなくて済んだこと
本番サーバースペック選定のための実証テスト
• microインスタンスでいきなりプロトタイプ開発を開始
• 様子を見つつインスタンスタイプを変更

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

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

30

30

アプリケーションの移植負荷は？
移植自体はそこまでかからなかった
テスト自身もそこまでかからなかった
DynamoDBのプロビジョンスループット
• 万が一、指定したプロビジョンスループットを超えた場合でもきちん
と対応したい
• →自前でオートスケール部分をやや作りこんだ

31

31

工夫した点：DynamoDB オートスケール
公式SDKを使い、CapacityUnitsを読み書き
CapacityUnitsを
読み書きする
wrapper関数を書きました

$x
$x
$x
$x

=
=
=
=

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

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

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

32

32


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

プロビジョンしたIOPS

実際に消費したIOPS

33

33

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

34

34

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

35

35

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

36

36

CloudWatch

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

37

37


現在のシステム構成

お客様Server
管理用 / XML出力

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

IP

地域

組織

38

今後の構成
管理用EC2
お客様EC2

お客様
Server

IP

地域

組織天気株価・・・

39

コスト比較

40

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

開発期間：約18カ月
• 本番サーバースペック選定のための実証テスト
• サーバー機の価格交渉・ 200v電源は確保できるのか？
• などなど

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

ランニングコスト：月額数10万円
• IDC費用（設置場所＋電源＋ネットワーク）
• 加えて、ファイヤーウォールやロードバランサーのコスト

41

DynamoDB利用でかかった期間と費用
41億件すべて投入

$1,000

$0
7月度

8月度

9月度

10月度

11月度

12月度

仕様検討
実データ投入
チューニング
→
→
→
開発
負荷テスト
テスト環境公開

(1月度)

サービス開始

42

費用見積もり
10億res/月を処理するシステムのAWS費用見積もり
データ転送量（AWS外部へ送信）は「1レスポンス３KB」として計算

43

比較
CassandraでのTCO
• 開発期間18か月の人的コスト＋初期ハードウェアコスト300万円
(＋α)＋ランニングコスト月額15万円(＋α)

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

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

ご参考
• DynamoDBのリザーブドキャパシティで更にお得に！
• http://aws.amazon.com/jp/dynamodb/pricing/
44

まとめ

45

まとめ

サイバーエリアリサーチ様は
CassandraからDynamoDBへ移行
• 時間的・金銭的コストを大幅削減
• シンプルなアーキテクチャ
• ビジネスの成長に伴うインフラ不安からの解放

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

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

47

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

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

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

Plus de Amazon Web Services Japan

Plus de Amazon Web Services Japan (20)

Dernier

Dernier (9)

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