自己紹介桑野章弘(くわのあきひろ) ソリューションアーキテクト主にメディア系のお客様を担当しております渋谷のインフラエンジニア仮をしてました好きなAWSのサービス ElastiCache 好きなデータストア MongoDB 2

Size: px

Start display at page:

Download "自己紹介桑野章弘(くわのあきひろ) ソリューションアーキテクト主にメディア系のお客様を担当しております渋谷のインフラエンジニア仮をしてました好きなAWSのサービス ElastiCache 好きなデータストア MongoDB 2"

あきおみしま
5 years ago
Views:

1 Black Belt Online Seminar AWS で使う MongoDB 2016/04/26 アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト桑野章弘 1

2 自己紹介桑野章弘(くわのあきひろ) ソリューションアーキテクト主にメディア系のお客様を担当しております渋谷のインフラエンジニア仮をしてました好きなAWSのサービス ElastiCache 好きなデータストア MongoDB 2

3 内容についての注意点本資料では 2016 年 4 月 26 日時点のサービス内容および価格についてご説明しています最新の情報は AWS 公式ウェブサイト ( にてご確認ください資料作成には十分注意しておりますが資料内の価格と AWS 公式ウェブサイト記載の価格に相違があった場合 AWS 公式ウェブサイトの価格を優先とさせていただきます価格は税抜表記となっています日本居住者のお客様がサービスを使用する場合別途消費税をご請求させていただきます AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided. 3

4 アジェンダ Introduction MongoDBとは AWS 環境でのMongoDB MongoDBのユースケースまとめ 4

5 アジェンダ Introduction MongoDBとは AWS 環境でのMongoDB MongoDBのユースケースまとめ 5

6 Introduction Amazon Web Service(AWS) では様々なマネージドデータベースサービスを提供すると同時に EC2 上で様々なデータベースを運用することができます今回はドキュメント指向データストアである MongoDB を題材に MongoDB のメリットデメリット AWS での活用方法についてお話します 6

7 アジェンダ Introduction MongoDBとは AWS 環境でのMongoDB MongoDBのユースケースまとめ 7

8 8 MongoDB とは

9 MongoDB とはドキュメント指向データストアの一つドキュメント指向データストアとしては最も使われているプロダクトで高機能な NoSQL データストア 9

10 マネージドサービスとの比較 AWS にも様々なサービスが存在しるので必要に応じマネージドサービスの使用も検討に入れるゲームなどのアプリケーションの場合は DynamoDB や RDS ログ解析用途であれば小規模なら Elasticsearch Service, 大規模なら S3+EMR or Redshift 10

11 DynamoDB の特徴 AWSの提供するマネージドサービスシームレスな拡張性高速なパフォーマンスデータの耐久性 (3AZにデータレプリカ) 従量課金 11

12 DynamoDB との検討ポイント DynamoDB 高パフォーマンス / 可用性従量課金ユーザ側でのリソース拡張不要構築が必要ない MongoDB Javascript によるリッチなクエリが必要 JSON が格納できれば良いのか JSON の要素に対してクエリを投げたいのかスキーマレスを活かせる構成か 12

13 S3 の特徴 AWSの提供するオブジェクトストレージどこからでも任意のデータを保存 / 取得可能 % の耐久性容量無制限スケーラブル従量課金 13

14 S3 との検討ポイント S3 容量無制限使った容量と転送量のみの従量課金ユーザ側でのリソース拡張不要スケーラブル構築が必要ない MongoDB JSON が格納できれば良いだけなのか JSON の要素に対してクエリを投げたいのか MongoDB のみで解析を行う必要がある 14

15 それ以外にもマネージドサービス Aggregation Framework 等を使用したいのであれば Elasticsearch service の Aggs が使える大規模な解析を行う場合に S3 に格納したデータを EMR や Redshift で解析する 15

16 MongoDB の基本的な機能スキーマレス冗長化レプリカセット負荷分散シャーディングストレージエンジン複数の選べるストレージエンジン (MMAPv1,WiredTiger 他 ) 16

17 スキーマレスデータの形を厳密に決める必要が無い例後から趣味の項目を追加した場合 { "_id" : " ", "userid" : "akuwano", "username" : "Akihiro Kuwano" } { "_id" : " ", "userid" : "akuwano", "hobby" : MongoDB, "username" : "Akihiro Kuwano" } 17

18 プライマリ冗長化レプリカセットセカンダリ 3台のmongodでVoteして Primaryのサーバを決定 Failoverを行う Arbiterプロセスセカンダリプライマリ->Failed データを持たずにVote権だけ持つプロセスセカンダリ 18 セカンダリ->プライマリ

19 負荷分散 Clients シャーディング mongos データをChunkの細かい粒度に分割各mongod に負荷を分散 ChunkB ChunkA -> ShardA ChunkB -> ShardB ChunkC -> ShardC mongod ShardA ChunkA ChunkA 19 mongoc ChunkA mongod mongod ShardB ShardC ChunkB ChunkB ChunkC ChunkC

20 ストレージエンジン MongoDB 3.0 からストレージエンジンを選択できるようになった MMAPv1 WiredTiger 現在では殆どのワークロードでは WiredTiger を使用した方が良い結果が出る 20

21 アジェンダ Introduction MongoDBとは AWS 環境でのMongoDB MongoDBのユースケースまとめ 21

22 AWS で MongoDB を構築するメリット容易に始められる運用効率化簡単なスケールアップ / アウトバックアップ構築自動化 AWS の他サービスとの連携 S3 EMR 22

23 MongoDBの構成 App + mongos mongod データノード mongoc シャーディング情報の格納 mongos:適切なシャードへの割り振り mongoc シャーディング情報を保存する特殊なデータノード mongos mongoc シャーディング時に適切なシャードへと処理を振り分けるルーティングプロセス mongod:実際のデータの格納 mongod 23

24 MongoDB の構成種別例 MongoDB on EC2の基本的な構成例事業のステージや規模によって使い分けるスタンドアロン冗長化構成シャーディング構成 24

25 スタンドアロン 1 ノードで処理出来る程度のワークロードで使う場合消えても良いデータ一時的な使い方使用例開発環境や試験環境他のデータベースからの抽出データを持つ Availability Zone Clients App mongod 25

26 冗長化構成 Clients データ量は多くないが消えると困るデータ負荷にはスケールアップで対応参照はスケールアウト可使用例直近のログ保存マスタデータ用DB 26 App mongod レプリカセット Availability Zone Availability Zone

27 シャーディング構成 Clients データを多数のノードに分散し大規模に使う場合消えると困るデータ負荷にはスケールアップとスケールアウトで対応使用例 App mongod レプリカセットシャーディングゲームのユーザデータ用 DB DMP基盤 Availability Zone 27 Availability Zone

28 28 MongoDB on EC2 環境の考え方

29 mongod のインスタンスタイプの選定用途によって以下のタイプから選定する MMAPv1 ストレージエンジン r3 インスタンスルができないためメモリが多く必要 WiredTiger ストレージエンジン r3, m4, c3, c4 を使い分けよって選択高スループットを求める場合 i2 インスタンス仕様上 CPU は使い切れずキャッシュコントローユースケースリソースの使用状況にエフェメラルディスクを使用する前提 29

30 その他のプロセスのインスタンスタイプの選定選定基準は以下の通り考える mongos アプリケーションサーバに同居することが多いがアクセス量や Aggregation Framework を使用する場合には CPU リソースを多く使う場合が感がられるので負荷試験等で必要なリソースを確認する mongoc シャードの情報を持っているだけなので基本的には殆どデータ量は持たない CPU も使わないので基本的には t2 シリーズでも十分事足りる Arbiter レプリカセットの Vote のやり取りを行うだけのサーバなのでリソースはほぼ使わないため t2 シリーズなどで他サーバへの同居も検討する 30

31 ディスク選定各ノードのディスク選定指針基本的には汎用 SSD の EBS 高スループットが必要な場合は汎用 SSD の EBS ボリュームのソフトウェア RAID0 Provisioned IOPS SSD の EBS ボリューム i2 インスタンスタイプ等のインスタンスボリュームインスタンスボリュームは EBS よりも高速だが再起動でデータが失われるバックアップ用のノードは EBS にする 31

32 AZ構成の考え方レプリカセットはスプリットブレイン対策のためレプリカセット全体の過半数のノードにアクセス出来なければプライマリ昇格できない AZの数が重要 AZの数による生存戦略 2ノードあるのでプライマリ昇格できるプライマリネットワーク分断 3AZ以上あるリージョンの場合は各AZにノードを配置 2AZのリージョンの場合は片側AZ断時には即時プロセスをあげられるようにするか別リージョンにプロセスを置く 32 セカンダリ 1ノードではプライマリに昇格できないセカンダリレプリカセット

33 AZ 構成の考え方 :3AZ mongoc mongod Availability Zone Availability Zone Availability Zone 3AZ あるリージョンの場合は各 AZ にノード配置 33

34 AZ 構成の考え方 :2AZ mongoc mongod Availability Zone Availability Zone AZ 断した際には生き残っているサーバから再構築 Availability Zone Availability Zone 34

35 AZ 構成の考え方 :2AZ mongoc mongod Availability Zone Availability Zone Availability Zone 1 つのサーバを別リージョン ( 東京であればソウルなど ) に置く priority を低くしたり Hidden メンバにすることでこのノード郡は使用しない Arbiter としてもよい 35

36 36 構築

37 構築の種類 AWS環境構築ノード環境構築 37

38 AWS 環境の構築フルスクラッチ自動化サービス AWS CloudFormation AWS リソースのプロビジョニングサービス AWS で出しているクイックスタートリファレンスもあります Terraform Hashicorp 社のオーケストレーションツール 38

39 各ノード環境の構築フルスクラッチ自動化プロダクトの使用 Packer Ansible Chef 39

40 MongoDB の PaaS サービス MongoDB を AWS 上で構築運用するための DaaS サービス mlab( 旧 mongolab) MongoDB Cloud Manager 40

41 41 監視可視化

42 主な監視項目 CLI コマンド mongostat コマンド ( 実データは db.serverstatus()) 可視化等は Cloudwatch のカスタムメトリクスや munin 等のソフトウェア各種監視 SaaS mlab や MCM 等を使うことで可視化までをワンストップで行う事も可能 42

43 主な監視項目 :mongostat MMAPv1 insert query update delete getmore command flushes mapped vsize res faults qr qw ar aw netin netout conn time *0 *0 * G 32.4G 2.1G m 14k T07:21:57Z *0 *0 * G 32.4G 2.1G m 14k T07:21:58Z *0 *0 * G 32.4G 2.2G m 14k T07:21:59Z (snip) 8187 *0 *0 * G 144.3G 2.5G m 13k T17:09:54Z 7885 *0 *0 * G 144.3G 2.5G m 13k T17:09:55Z 8286 *0 *0 * G 144.3G 2.5G m 13k T17:09:56Z 7129 *0 *0 * G 144.3G 2.5G m 13k T17:09:57Z 43

44 主な監視項目 :mongostat WiredTiger insert query update delete getmore command % dirty % used flushes vsize res qr qw ar aw netin netout conn time *0 *0 * G 2.4G m 38k T02:17:23Z *0 *0 * G 2.4G m 39k T02:17:24Z *0 *0 * G 2.4G m 39k T02:17:25Z *0 *0 * G 2.4G m 39k T02:17:26Z (snip) *0 *0 * G 3.3G m 19k T04:39:37Z *0 *0 * G 3.3G m 19k T04:39:38Z *0 *0 * G 3.3G m 19k T04:39:39Z 44

45 mongostat の主な監視項目全体的な項目 qr qw この値が多ければクエリが滞留しているサーバ負荷が低ければロックの可能性を疑うサーバ負荷が高ければクエリ増による高負荷を疑う 45

46 mongostat の主な監視項目 MMAPv1 の項目 faults が多い場合キャッシュメモリ溢れの可能性メモリもしくはシャード追加 Locked % が高い場合書き込みのクエリを見直す or クラスタ分割 WireTiger の項目 Dirty % が高い場合マージ前のデータの目安で単位時間での更新量が多い一定の値で安定していれば問題なし 46

47 その他確認項目スロークエリの調査ログに実行時間が遅かったクエリが出る profile に一定以上時間の掛かったクエリを出力する事が可能 47

48 48 バックアップリストア

49 バックアップリストア mongodump mongodかシャード環境ならmongoc, mongosから dump取得 Point In Time Recovery 以下PITR にはならない mongoc BackupServer mongos mongodump 実行 49 shard

50 バックアップリストア Snapshot取得主にシャード環境レプリカセット環境時に使用レプリカセットから各バックアップ用のメンバを指定してEBS Snapshotを取得 db.fsynclock()で読み書きロック db.fsyncunlock() でアンロック 50 mongoc 読み書きロック後にSnapshot取得 mongod

51 バックアップリストア MongoDB Cloud Manager でのバックアップ PITR を SaaS としてサービス提供バックアップのみの使用も可能 51

52 52 セキュリティ

53 セキュリティ MongoDB の認証ユーザ認証データベースに対するユーザロールベースのアクセスコントール鍵認証レプリカセットシャード環境で使用可能キーファイルによるアクセスコントール 53

28017ポートを使用する 54 Public Subnet Public Subnet PrivateSubnet

54 セキュリティ AWSのセキュリティ VPC構成 Ohter Subnet App Public/Private構成セキュリティグループ必要なNW以外からのアクセスをブロックデフォルトでは , 28017ポートを使用する 54 Public Subnet Public Subnet PrivateSubnet PrivateSubnet mongodb セキュリティグ Availability Zone ループを設定 Availability Zone

55 55 性能面での TIPS

56 性能面での TIPS クエリ関連 INDEX Targetedオペレーション Write concern データモデリング正規化 / 非正規化シャードキーの選定 56

57 INDEX 各クエリから適切な INDEX を貼る Profiling でリリース前のテスト時に全クエリ出すようにしてチェック INDEX を張り過ぎるとメモリを圧迫するので必要な物を最低限作成する DEX ツールの活用 57

58 DEX mlab 製のツール遅かったクエリと必要な Index をレコメンドする $ dex -f /var/log/mongodb/mongodb.log mongodb://localhost { (snip) 'results': [ { 'querymask': '{"$query":{"name":"<val>"}}', 'namespace': 'd1.users', 'recommendation': { 'index': '{"name": 1}', 'namespace': 'd1.users', 'shellcommand': 'db[ users"].ensureindex({"name": 1}, {"background": true})' }, 58

59 Targeted オペレーションシャード環境時のオペレーションタイプには Targeted Broadcast の 2 つがある Targeted は必要なシャードにだけアクセスするが Broadcast は全シャードにアクセスする Targeted オペレーションを行うには INDEX が必要なので INDEX 作成の際の指標にする 59

60 Targeted オペレーション必要なシャードへのみアクセス shard App mongos BroadCast オペレーション 60 shard App mongos Targeted オペレーション

61 Write Concern 書き込みの整合性保証デフォルトはPrimaryが成功したらAckを返す全台OKまで待ったり 1台もOKじゃなくてもすぐAck を返したりできる Primaryが書き込みOKならAckを返す App Write Concern w=1 61 App 全てのメンバが書き込みOKなのをまってAck を返す Write Concern w=3

62 データモデリング MongoDB は JSON を使って柔軟なデータモデルを表現できるが RDB の様なリレーショナルモデルではない正規化 / 非正規化シャードキーの選定 62

63 正規化非正規化非正規化すればアクセスするデータ量が減るかどうかどのようなクエリが支配的かがポイント { { "_id" : " ", "userid" : "akuwano", "hobby" : MongoDB, "username" : "Akihiro Kuwano" } "_id" : " ", "userid" : "akuwano", } { "_id" : " akuwano", "hobby" : MongoDB, "username" : "Akihiro Kuwano" } 63

64 シャードキーの選定シャードキーは RDBMS で言えばプライマリキーデフォルトでは 45feae f の様なキーが割り振られるが自分で決めても良いシャード分散にも使われるのでできるだけカーディナリティが高くランダム性の高いキーシャードを特定しやすいように決まった値を設定する ( 日時ユーザ ID 等 ) 最初に決まったシャードキーの値を他のコレクション側でも引き回すのもアリ 64

65 65 コスト削減

66 コスト削減のポイント App + mongos MongoDB で最低限の冗長化と 2 シャード環境を実現するには 9 台のサーバが必要 mongod * 6 mongoc * 3 mongos はアプリケーションサーバと同居 mongoc mongod 66

67 コスト削減のポイント App + mongos レプリカセット中1台のサーバをArbiterプロセスにする mongoc 冗長性は落ちるがArbiterプロセスはリソースを食わないためインスタンス数 or タイプを節約 arbiter mongod 67 対向のレプリカセット対向のレプリカに属すArbiterプロセセットに属すスを常駐するか別途 Arbiterプロセスを集約したArbiterサー常駐バを構築する

68 コスト削減のポイント確定したリソースにはリザーブドインスタンスを活用する 1 年間または 3 年間常に利用可能なキャパシティ予約により最大 75% の割引 68

69 アジェンダ Introduction MongoDBとは AWS 環境でのMongoDB MongoDBのユースケースまとめ 69

70 70 MongoDB は運用が辛い

71 誤 MongoDB は運用が辛い正分散型データストアは運用が辛い 71

72 分散データベースの運用が辛い理由こういった事が殆どユースケースが間違っている運用ナレッジが溜まっていない基本的に 1 プロセスで動いている RDB とくらべて多数のノードが強調して動く分散データストアは非常に運用ナレッジを貯めるのが大変ユースケースを明確にする事が大事 72

73 MongoDB のユースケースホットデータが存在するアクセスパターン全データを舐めていくようなアクセスパターン 73

74 MongoDB が得意なユースケースホットデータが存在するアクセスパターン CappedCollectionが活用できる主な使用用途ゲーム短期的なログ解析他 DBから抽出した一時データ 74

75 MongoDBが得意なユースケースゲームのアーキテクチャはアクティブユーザによるホットデータが支配的ユーザ 75 Game app mongodb

76 MongoDBが得意なユースケース数十GB程度のログ保存解析には CappedCollectionを使用しキャッシュを効率的に使わせるユーザ 76 Game app mongodb 分析者

77 MongoDBが得意なユースケース大量のデータベース解析から一部の対象だけをフィルタしてMongoDB側に送るデータベース 77 ETL Application mongodb Amazon EMR

78 MMAPv1 のメモリ管理 : ホットデータ mongod プロセスメモリ (MMAP) ストレージ層 78

79 MongoDB が苦手なユースケース全データを舐めていくようなアクセスパターン主な使用用途長期的なログ解析基盤 SNS 等でのソーシャルグラフ大量のデータに同時にアクセスして複雑な処理を頻繁に行う処理が MMAPv1 では特に苦手 79

80 MongoDBが苦手なユースケース DMP基盤の様な大量のログ数TB を処理したい場合にはシャード数を増やす必要が出てくる EC2等で動的に増やしていく事は可能だがコストはかかるユーザ Game app Amazon EMR mongodb 80

81 MMAPv1のメモリ管理大量アクセス mongod プロセスメモリ MMAP ストレージ層 81 データへのアクセス範囲回数が多すぎるとキャッシュ改廃が大量に発生しストレージへのアクセスが頻発する

82 アジェンダ Introduction MongoDBとは AWS 環境でのMongoDB MongoDBのユースケースまとめ 82

83 まとめ実際のワークロードに適しているかを良く確認する MongoDB の性能を最大化しコストを最小化するための構成を検討する AWS をうまく活用することで MongoDB での弱点である運用負荷を軽減することが可能マネージドサービスを活用できる部分には活用し運用コストを下げる AWS にはそのための部品として DynamoDB や Elasticsearch Service を始め様々なサービスが揃っている 83

84 84 Q&A

85 参照リンク MongoDB マニュアル MongoDB FAQ ホワイトペーパー :MongoDB on AWS AWS 上の MongoDB クイックスタートリファレンスデプロイガイド 85

86 参照リンク Amazon Elasticsearch Service ユーザーガイド Amazon Elasticsearch Service FAQ DynamoDB ユーザーガイド DynamoDB FAQ 86

87 参照リンク Amazon Elastic MapReduce ユーザーガイド Amazon Elastic MapReduce FAQ Redshift ユーザーガイド Redshift FAQ 87

88 MongoDB その他の機能本編で紹介しきれなかった機能について Javascriptによる柔軟なクエリ WiredTigerの主な設定値 Aggregation Framework CappedCollection 88

89 JavaScriptによる柔軟なクエリ制御構造等も含んだ様々なクエリが実行可能 # Insert (データ入力) db.user.insert({userid: kuwano', username: Akihiro Kuwano }); # find (データ取得) db.user.find() {"_id" : " ", "userid" : "kuwano", "username" : "Akihiro Kuwano" } # update (データ更新 db.user.update({userid: kuwano'}, {$set:{username: MongoDB'}}) db.user.find() {"_id" : " ", "userid" : "kuwano", "username" : "MongoDB" } # remove (データ削除 db.user.remove({userid:"kuwano"}) 89

90 ストレージエンジン :WiredTiger WiredTiger ストレージエンジンの主な設定値 cachesizegb キャッシュするメモリ領域の指定スレッドや Index でもメモリを使うのでシステムメモリの 6 7 割とる形が良い blockcompressor データ圧縮を行うかデフォルトは snappy 速度 :none>snappy>gzip 圧縮率 :gzip>snappy>none 90

10000000 ops 500 thread MongoDBサーバ - c4.

91 ベンチマーク結果ストレージエンジンによる暫定比較実ワークロードでは無く実行時の要素によって変わるので参考値構成 ycsb使用 obj ops 500 thread MongoDBサーバ - c4.xlarge 負荷サーバ - c4.2xlarge 91 WiredTigerが3 割増

92 マルチコア対応 MMAPv1はシングルコア 92 WiredTigerはマルチコア

93 Aggregation Framework Aggregation Framework 主に集計処理のために使用されるフレームワークパイプラインとして定義された処理をつなぎ合わせる事で複雑なクエリを実現する例 : ユーザ kuwano の点数の合計値を返す 1. $match で name が kuwano のデータを抽出 2. $project で集計対象のフィールドを point に指定 3. $group で集計処理を実行 $sum で該当する point の値を合計して表示 93

94 Aggregation Framework 例 : ユーザ kuwano の点数の合計値を返す > db.point.find() { "_id" : ObjectId("101"), "name" : "tsukada", "point" : 100 } { "_id" : ObjectId("102"), "name" : "narita", "point" : 100 } { "_id" : ObjectId("103"), "name" : "mori", "point" : 150 } { "_id" : ObjectId("104"), "name" : "kuwano", "point" : 500 } { "_id" : ObjectId("105"), "name" : "kuwano", "point" : 100 } { "_id" : ObjectId("106"), "name" : "kuwano", "point" : 200 } { "_id" : ObjectId("107"), "name" : "tateoka", "point" : 1000 } > db.point.aggregate(... { $match : { "name" : "kuwano" } }, (1)... { $project : { "point" : 1 } }, (2)... { $group : { "name" : "kuwano", "totalpoint" : { "$sum" : "$point" } } } (3)... ); { "result" : [ { "name" : "kuwano", "totalpoint" : 800 } ], "ok" : 1 } 94

95 CappedCollection コレクション作成時に最大データ量を指定しそれ以上のデータを保存する場合は古いデータから削除を行う特殊なコレクション最大データ量をメモリ量以下にすれば効率よくキャッシュされたデータを扱うことが出来る CappedCollection Data Data Data Data Data Data 95

96 mongocサーバの集約 App + mongos MongoDB 3.2からレプリカセット内に mongocの機能を集約可能サーバ台数が削減可 mongoc レプリカセットの数台がmongoc の機能を兼ねる mongod 96

Presentation Title Here

Presentation Title Here AWS Black Belt Online Seminar Amazon Pinpoint 2017.04.26 アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト清水崇之 0 自己紹介清水崇之ソリューションアーキテクト ( 西日本担当 ) 大阪から沖縄まで西日本のお客様にもプライム対応で参上します AWS 芸人 ( 詳しくは https://www.slideshare.net/shimy_net/)

自己紹介 桑野 章弘(くわの あきひろ) ソリューションアーキテクト 主にメディア系のお客様を担当しております 渋谷のインフラエンジニア 仮 をしてました 好きなAWSのサービス ElastiCache 好きなデータストア MongoDB 2

自己紹介桑野章弘(くわのあきひろ) ソリューションアーキテクト主にメディア系のお客様を担当しております渋谷のインフラエンジニア仮をしてました好きなAWSのサービス ElastiCache 好きなデータストア MongoDB 2