SlideShare a Scribd company logo
CyberAgentにおける
MongoDB
株式会社サイバーエージェント
アメーバ事業本部 テクノロジーグループ Ameba Infra. Unit

                桑野 章弘

13年12月12日木曜日
アジェンダ
n Amebaのサービス
n サービス環境の変遷
n サービスを支えるMongoDB
n 困ったことなど
n 運用について
n まとめ

13年12月12日木曜日
自己紹介
n 桑野章弘
l サイバーエージェント
l Ameba を運営しています。
l ピグソーシャルゲームの運用/構築を担当

l Twitter
l @kuwa_tw

l Blog
l http://d.hatena.ne.jp/akuwano/

13年12月12日木曜日
ピグライフ

13年12月12日木曜日
ピグライフ
n サービス情報
l 2011/05/31オープン
l 自分の庭の育成ゲーム

13年12月12日木曜日
ピグアイランド

13年12月12日木曜日
ピグアイランド
n サービス情報
l 2012/05/22オープン
l 自分の島育成ゲーム

13年12月12日木曜日
ピグカフェ

13年12月12日木曜日
ピグカフェ
n サービス情報
l 2012/08/21オープン
l カフェ経営ゲーム

13年12月12日木曜日
ピグワールド

13年12月12日木曜日
ピグワールド
n サービス情報
l 2012/11/27オープン
l 自分の街をつくろうゲーム

13年12月12日木曜日
なぞってピグキッチン

13年12月12日木曜日
なぞってピグキッチン
n サービス情報
l 2013/11/19オープン
l スマートフォンのブラウザゲーム
l パズルをクリアして自分のキッチンを育てようゲーム

13年12月12日木曜日
ゲーム概要
n PC
l ユーザ数は100万ユーザ∼300万ユーザ以上
l ピーク帯同時接続数10万以上
l オンプレミス

n SPサービス
l リリースしたばかり
l AWS上で構築

13年12月12日木曜日
全ゲーム
MongoDBを使用

13年12月12日木曜日
サービス環境の変遷

13年12月12日木曜日
n まずは弊社サービスの成長の変遷について説明し
ます

13年12月12日木曜日
アーキテクチャ
n アプリケーションサーバ
l Node.js
l Nginx

n データストアサーバ
l MongoDB

13年12月12日木曜日
アーキテクチャ
BackEnd

FrontEnd

ユーザ/エリア等の状態
staticサーバ

Flashデータ

必要なデータの取得

→リクエスト/取得
HTTP
WebSocket接続

・ユーザ情報
・チャットデータ
→リクエスト/取得

ユーザ
(ブラウザ:Flash)

13年12月12日木曜日

データ

Node.jsサーバ
Socketサーバ

mongodbサーバ
[ピグライフ]の変遷

13年12月12日木曜日
ピグライフ
n リリースから現在
l βテスト時代
l リリース後
l 現在

13年12月12日木曜日
ピグライフ
n リリースから現在
l βテスト時代
l リリース後
l 現在

どんなフェーズを経たか

13年12月12日木曜日
ピグライフ:βテスト時代
n 4/26∼5/31
l テストユーザ数5000∼30000
l 毎日リリース、機能追加、インフラ構成変更
l サーバも最小限を用意

13年12月12日木曜日
ピグライフ:βテスト時代
βテスト時に実
装

6
mongos
Staticサーバ

Node.jsサーバ

MongoDB

13年12月12日木曜日

行動ログの保存
MongoDB Log
ピグライフ:リリース後
n 問題点洗い出しのフェーズ
l Node.jsのサーバや、mongodbも、パフォーマン
スが出ていなかったため増設
l Swfファイルをnode.jsのサーバから静的ファイル専
用のサーバへと切り出す

13年12月12日木曜日
ピグライフ:リリース後
n 5/31 ∼
l ピグライフ、正式リリース
l 人気が爆発、予想以上の伸び
l 開始3週間(6/22)で100万人突破
l とにかく増設の時期

13年12月12日木曜日
リリース時構成
大量追加

44

3
mongos
Staticサーバ

Node.jsサーバ

行動ログの保存
サーバにも取得
MongoDB Log

1シャード追加
(合計4シャー
ド)

MongoDB

13年12月12日木曜日
ピグライフ:リリース後
n パフォーマンス確保のフェーズ
l ボトルネック調査
l 状況を見つつサーバ台数、リソースの確保

13年12月12日木曜日
ピグライフ:現在
n 9/1 ∼
l 順調な成長
l 開始3ヶ月弱(8/22)で200万人突破

13年12月12日木曜日
現在時構成
リリース時切替
高スペックサー
バにリプレイス

5

5

10
mongos

Staticサーバ_A系 Staticサーバ_B系 Node.jsサーバ_A系

・・・・・

MongoDB

13年12月12日木曜日

10
Node.jsサーバ_B系
mongos
行動ログの保存
DB統合

23シャード追
加(合計27シャ
ード=81台)
ピグライフ:現在
n 運用改善のフェーズ
l メンテ時間短縮のため稼働グループを分割
l A系、B系での切替

l 構成はシンプルにしていく
l CDNなどの導入検討
(CDNを入れられるように仕様変更)

13年12月12日木曜日
ピグライフ:成長速度
n 成長速度
l リリースから3ヶ月程度で、サーバ規模としては8倍
に。それにともなって、トラフィック(1.3Gbps)、
総コネクション数(18万)も増加。
l その期間は3ヶ月余り。3週間の伸びは単位にすれば
30倍

サービスの予想以上の成長

13年12月12日木曜日
サービスを支える
MongoDB

13年12月12日木曜日
この成長速度を支えた
MongoDBの基本的
な機能
13年12月12日木曜日
MongoDBの構成
アプリケーションサー
バ

mongos

Mongod[ShardA]

Mongod[ShardB]

mongoc
Mongod[ShardC]

13年12月12日木曜日
アーキテクチャについて
n システムアーキテクチャ
l スキーマレス
l 冗長化
l ReplicaSets

l スケーラビリティ
l Sharding

13年12月12日木曜日
アーキテクチャの課題
n スキーマレスなデータ構造による柔軟なデータ管
理
l ユーザ情報なども柔軟に持つことができるので、機能
追加時等が比較的楽
l 次ページ例

13年12月12日木曜日
アーキテクチャの課題
n スキーマレスなデータ構造
l ユーザーコレクションに趣味を追加したい場合
{
"_id" : "1234567889",
"userid" : "akuwano",
"username" : "Akihiro Kuwano"
}

{
"_id" : "1234567889",
"userid" : "akuwano",
"hobby" : Movie ,
"username" : "Akihiro Kuwano"
}

13年12月12日木曜日
アーキテクチャの課題
n ReplicaSets
l 相互死活監視&投票により冗長性を保つ。最小単位は
3台。
プライマリ

セカンダリ

13年12月12日木曜日

セカンダリ
アーキテクチャの課題
n ReplicaSets
l 相互死活監視&投票により冗長性を保つ。最小単位は
3台。
生きているサー
バで投票が行わ
れ新しいプライ
マリが選ばれる

セカンダリ

13年12月12日木曜日

プライマリ

セカンダリ → プライマリ
アーキテクチャの課題
n Sharding
l データをChunkの細かい粒度に分割する。
各mongodに分散して渡すことで各サーバの負荷を
分散します

13年12月12日木曜日
MongoDBの構成
アプリケーションサー
バ

Sharding
データをChunk
の単位に分ける

ReplicaSetsに
よりサーバの冗長
性を確保

DATA
mongos
Mongod[ShardA]

Mongod[ShardB]
mongoc

Mongod[ShardC]

13年12月12日木曜日
MongoDBの構成
アプリケーションサー
バ

Sharding
データをChunk
の単位に分ける

ReplicaSetsに
よりサーバの冗長
性を確保

ChunkA ChunkB ChunkC

mongos
mongocはシャ
ーディング情報を
持つ

Mongod[ShardA]

Mongod[ShardB]
mongoc
ChunkA -> ShardA
ChunkB -> ShardB
ChunkC -> ShardC

13年12月12日木曜日

Mongod[ShardC]
MongoDBの構成
アプリケーションサー
バ

ReplicaSetsに
よりサーバの冗長
性を確保

Sharding
データをChunk
の単位に分ける

mongos
mongocはシャ
ーディング情報を
持つ

ChunkA

Mongod[ShardA]

ChunkB

Mongod[ShardB]

mongoc
ChunkA -> ShardA
ChunkB -> ShardB
ChunkC -> ShardC

13年12月12日木曜日

ChunkC

Mongod[ShardC]
アーキテクチャの課題
n MongoDBのこれらの基本機能により、アプリ
側の実装コストは軽くなります。
n 前述した、9台→100台への変更においても、ア
プリ側のDB接続部分の変更点は殆どありませ
ん。
n スケーラビリティを保ったまま、シンプルなサー
ビス構築を行うことができています。

13年12月12日木曜日
ユースケース

13年12月12日木曜日
ユースケース
n MongoDBにかぎらず、NoSQLはできる、で
きない、がハッキリしています
n NoSQL使うならできる部分を伸ばす必要があり
ます。もし、できない部分を突き詰めると
RDBMSとなります

13年12月12日木曜日
ユースケース:得意なもの
n データ量が大き過ぎない
n 書き込みが多過ぎない
n 単位時間あたりの処理データが各シャードのメモ
リ量を超えない処理は得意
n 得意なユースケース
l ゲーム系Webアプリケーション
l 一時的ログ解析基盤

13年12月12日木曜日
ユースケース:苦手なもの
n ホットデータが無い様なデータの使い方は苦手
l データ量が爆発的に増える
l 常に全データへのアクセスを行うような

n 苦手なユースケース
l ソーシャル系等のWebアプリケーション
l 継続的 or 統合的 ログ解析基盤

13年12月12日木曜日
なぜか?

13年12月12日木曜日
ユースケース
n MongoDBのメモリ管理
l アクセスしたデータファイルはmmapとしてキャッ
シュ
l メモリからあふれた場合はアクセスされた物を入れ
て、使われてないものを削除
l LRU的な仕組みはなく、OS任せ

13年12月12日木曜日
ユースケース
mongodb

mmap

datafile.0

13年12月12日木曜日

datafile.1

datafile.2
mmap
ユースケース
mongodb

mmap

datafile.0

13年12月12日木曜日

datafile.1

datafile.2
mmap

datafile.3
ユースケース

mongodb

メモリ量以上のデ
ータアクセス毎に
メモリ<ー>ディスク
へのアクセスが頻
発

mmap

datafile.0

13年12月12日木曜日

datafile.1
mmap

datafile.2
困ったことについて

13年12月12日木曜日
運用中に困ったことに
ついて

13年12月12日木曜日
n クラスターのスローダウン
l 必要なデータを一気にデータをインポートした場合
l oplogデータ量範囲を超えてレプリケーションが停止
l 一度に入れたため、PrimaryShardにChunkが溜
まってしまいI/Oバウンドに
l 負荷が高いのでBalancerは動かないためクラスタの
スローダウン
→Oplogの容量を増やすことができるのでそれらで対
応

13年12月12日木曜日
n シャード設定のスローダウン
l ほんとに突然パフォーマンスダウンする
「10分前は動いてたけど、、、」
l PrimaryShardはリソースを潤沢な状態にする
l 各シャードのmmapの容量が実メモリを超えてきた
ら注意する

→シャード設定は定期的に確認&シャードの設定を自
動化

13年12月12日木曜日
n データ肥大
l 運用していくに連れてデータの肥大化する
l 定期的なデータのコンパクションが必要です
l repairコマンドは、データ容量と同容量のスペース
を利用するので注意
l データ容量が小容量かつ、一時的にMongoDBを止
められる場合、データdrop→データresoreの方が
簡単です。
l RS組んでいるならローリングコンパクション

13年12月12日木曜日
日々の運用

13年12月12日木曜日
ここからは実際の運用
でやっていること

13年12月12日木曜日
n MongoDBに使用するハードウェア
l CPU
l (現在は)CPUはあまり負荷が来ないためそれほど良い物で
なくて良い
l そのかわりノードを増やすことになるのであればラックの効
率を上げるため消費電力の少ないものを選択する

13年12月12日木曜日
n MongoDBに使用するハードウェア
l メモリ
l 積めば積むほどキャッシュが効くのでできるだけ積む
l 現在は1ノード32GBのサーバを用意

13年12月12日木曜日
n MongoDBに使用するハードウェア
l DISK
l こちらも書き込み、読み込みが早いに越したことは無い
l 今までは、SAS * 4 RAID10 -> SSD * 2 RAID0
l 現在はSSDはSASの3倍のiops
l FileSystemはxfs or ext4
- 高速なfallocate()がサポートが必要

13年12月12日木曜日
n MongoDBに使用するハードウェア
l DISK
l ioDriveでの検証は、現状では8000opsを超えた位で
ReplicaSetsのoplogの転送が止まる事を確認していた
l が バージョン2.4ではこの現象はない=ioDrive 等を上手く
活用することでサーバ台数を減らすことができる

13年12月12日木曜日
n バックアップ
l mongodump
l mongos経由の実行
l ポイントイン・タイムバックアップ

l ReplicaSetsのDelay

13年12月12日木曜日
n バックアップ
l mongodump
l mongosに対してmongodump実行するのはバックアッ
プとしては一番簡単
- 稼働中ではポイントイン・タイムバックアップではない
l mongodumpはmongodが起動していなくてもデータフ
ァイルに直接かけてBSONファイルを取得できるので、これ
を利用してポイントイン・タイムのバックアップを実装して
います

13年12月12日木曜日
n バックアップ
l 稼働中にスナップショットバックアップを取得
l RSメンバとしてarbiterとnovoteのプロセスを起動
l 1,mongos経由でAutoBalancingをOff
l 2,各レプリカセットのnovoteプロセスをダウン
l 3,各mongodからmongodumpでデータ取得
l 4 , mongos経由でAutoBalancingをOn
l 5 ,各Dumpデータの収集
l

13年12月12日木曜日
バックアップの構成
アプリケーションサーバ

1、Chunkがバ
ックアップ中に移
動させない

バックアップサーバ

5,各シャードか
らデータを取得

3,各シャードで
Dumpデータを
生成

mongos
Arbiter
Mongod[ShardA]

✕

no vote

Dump

Arbiter
Mongod[ShardB]
no vote

mongoc

Arbiter
Mongod[ShardC]
no vote

13年12月12日木曜日

2,no vote
プロセスダウン
n バックアップ
l ReplicasetsのDelay
l バックアップと言うよりはオペミスの防止
l 常に最新の状態よりも一定期間古い状態となる、
Replicasetsを追加します

13年12月12日木曜日
MMS
n MongoDB Management Service(MMS)
l 監視
l Muninプラグインとして提供

l バックアップ
l シャード環境でのポイントイン・タイムバックアップを提供
-

13年12月12日木曜日
MMS
n MongoDB Management Service(MMS)
l 監視
l Muninプラグインとして提供

l バックアップ
l シャード環境でのポイントイン・タイムバックアップを提供
-

13年12月12日木曜日
RS Delayの構成
アプリケーションサー
バ

この Replica
Sets のみ、他の
RSよりも3時間
前のデータを持つ

mongos
Mongod[ShardA]

Mongod[ShardB]
mongoc

Mongod[ShardC]

13年12月12日木曜日
n Index
l indexが効いているかはexplain()で確認
l できるだけPK=_id で検索する実装にする
replSetTest1001:PRIMARY> db.User.find({'Field01': 'test'}).explain()
{
"cursor" : "BtreeCursor testIndex_1",
"nscanned" : 1,
"nscannedObjects" : 1,
"n" : 1,
"millis" : 7,
"nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,

13年12月12日木曜日
n Index
l 詳しいオプティマイザの実行結果が欲しい場合
は .explain(true)
replSetTest1001:PRIMARY> db.User.find({'_id': 'test'}).explain(true)
"allPlans" : [
{
"cursor" : "BtreeCursor _id_",
"n" : 1,
"nscannedObjects" : 1,
"nscanned" : 1,
"indexBounds" : {
"start" : {
"_id" : "test"
},

13年12月12日木曜日
n ロック
l 同じサーバ上に異常に書き込みの多いコレクションが
あるとクラスタ全体のアクセスに影響するため、コレ
クションを分ける
l アプリ実装はコレクション間をできるだけ疎結合に
l 2.2以降DBレベルロックなのでDB分割

13年12月12日木曜日
n ロック

Collection A

13年12月12日木曜日

Collection B

Collection C
n ロック

Collection A

13年12月12日木曜日

Collection C

Collection B
n 運用効率化
l どうしても台数が多くなる傾向にあります。
l そのため「標準のコマンドだと表示が多すぎて見づら
い」「今のマスターの一覧が簡単に出したい」等の不
満がでます。
l これらはスクリプト作成等で対応しています、このあ
たりもJSONで各種データを取ってこれるために管理
ツールなどは作りやすいです。

13年12月12日木曜日
n 運用効率化 :運用スクリプトの内容
l ロックタイムの取得
l シャードに入っているmongod一覧のリスト出力
l レプリカセットのマスター検索
l レプリカセットのpriority検索
l printShardingStatusの整形
l レプリカセット一括作成/設定変更(現在のRSに
Delayホスト追加するなど)

13年12月12日木曜日
n 各種コマンド、ステータスなど
l トレンドが見たい
l 現状が把握したい

13年12月12日木曜日
n 各種コマンド、ステータスなど
l mongostat
l mongotop
l mongosniff

13年12月12日木曜日
n mongostat
l クエリや、プロセスの現状を確認するコマンド

$ ./mongostat --host 192.168.8.41:27018,192.168.8.62:27018
insert query update delete getmore command flushes mapped
vsize res faults locked % idx miss %
qr¦qw ar¦aw netIn netOut conn
set repl
time
192.168.8.41:27018
0 361 132
0
209
437
0 36.1g 76.2g
14.3g
1
2.2
0
0¦0
2¦0 85k 698k 3056 RSTest1001 M
11:16:57
192.168.8.62:27018
0 384 164
0
245
480
0 30.1g 63.9g
15.6g
0
2
0
0¦0
2¦0 96k 652k 2587 RSTest1002 M
11:16:57

13年12月12日木曜日
n mongostat - 見るべき項目
l faults - 1秒当りのページフォールト数
l Locked % - グローバルライトロックの時間割合
l idx miss % - indexのヒット率の時間割合
l qr¦qw - 読み込みキュー¦書き込みキュー の大きさ

13年12月12日木曜日
n mongostat - 見るべき項目
l faults が多い場合
キャッシュメモリ溢れの可能性があるので、メモリ、
もしくはサーバを増設
l Locked % が高い場合
書き込みのクエリを見直す or クラスタ分割。
l qr¦qw が高い場合
サーバ負荷が低ければ、ロックの可能性を疑う。負荷
が高ければ単純なクエリ増による高負荷を疑う。

13年12月12日木曜日
n mongotop
l 現在重いmongodのどのcollectionへアクセスがか
かっているかを確認したりとかできまする。
l 障害の時がメイン
$ /usr/local/mongodb2_1/bin/mongotop --host
mongos_ip --port 27018
connected to: mongos_ip
ns total
read
write
2012-05-23T02:14:12
local.oplog.rs 1929ms 1929ms 0ms
life_prd_main.TestOnline 0ms 500ms
10ms
life_prd_main.Test2Soil 8ms
0ms
8ms

13年12月12日木曜日

writeに時間
がかかってい
n mongosniff
l 最後はパケットキャプチャですので、何か会った際の
アクセス状況の確認が可能
l mongosのアクセス状況とか、複雑なクエリを見た
い場合はこれで見るのが良い
# mongosniff --source NET eth0 27017
# 以下にパケットがズラズラっと並ぶ
127.0.0.1:55858 -->> 127.0.0.1:27017 testdatabase.TestCol1 89 bytes
id:kjkjkjkj
14086840
query: { _id: "1234567891234567" } ntoreturn: -1 ntoskip: 0
127.0.0.1:27017 <<-- 127.0.0.1:55858 205 bytes id:77383268
2000171624 - 14086840

13年12月12日木曜日
n ステータス確認・変更
l profiling
l loglevel変更
l Working Set Analyzer
l db.adminCommand("connPoolStats")
l db.serverStatus()
l db.currentOp()
l db.collection.stat()
l db.stats()

13年12月12日木曜日
まとめ

13年12月12日木曜日
まとめ
n MongoDBを上手く使用することで、以下の様
なことが実現できています
l 運用の安定
l 構成を変えずスケーラビリティを確保
l JSONを直接扱える事で開発スピードを早く

13年12月12日木曜日
まとめ
n ですが、運用するにあたって気をつけなければな
らない点などがあり、上手い運用にはある程度の
ノウハウが必要とも考えています
n その辺りは私達もこのような場で適宜露出してい
ますし、サポートしていただける所も今後増えて
いくのではないでしょうか。

13年12月12日木曜日
まとめ

n ですがNoSQLは適材適所、という言葉もあり、
徐々に使って慣れていくのが大事だと思います。
スモールスタートでまずは使ってみてはどうでし
ょうか。

13年12月12日木曜日
ご清聴ありがとう
ございました

13年12月12日木曜日
質疑応答
13年12月12日木曜日

More Related Content

What's hot

AWS Batch Fargate対応は何をもたらすか
AWS Batch Fargate対応は何をもたらすかAWS Batch Fargate対応は何をもたらすか
AWS Batch Fargate対応は何をもたらすか
Shun Fukazawa
 
nginx入門
nginx入門nginx入門
nginx入門
Takashi Takizawa
 
MongoDBの監視
MongoDBの監視MongoDBの監視
MongoDBの監視
Tetsutaro Watanabe
 
後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜
Masakazu Matsushita
 
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
Masahito Zembutsu
 
WiredTigerを詳しく説明
WiredTigerを詳しく説明WiredTigerを詳しく説明
WiredTigerを詳しく説明
Tetsutaro Watanabe
 
AWS CLIでAssumeRole
AWS CLIでAssumeRoleAWS CLIでAssumeRole
AWS CLIでAssumeRole
Tetsunori Nishizawa
 
AWS Black Belt Online Seminar AWS上のJenkins活用方法
AWS Black Belt Online Seminar AWS上のJenkins活用方法AWS Black Belt Online Seminar AWS上のJenkins活用方法
AWS Black Belt Online Seminar AWS上のJenkins活用方法
Amazon Web Services Japan
 
Firebaseを利用するためにGCPとCloud IAMの 基本を理解しよう
Firebaseを利用するためにGCPとCloud IAMの 基本を理解しようFirebaseを利用するためにGCPとCloud IAMの 基本を理解しよう
Firebaseを利用するためにGCPとCloud IAMの 基本を理解しよう
kbigwheel
 
ログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについてログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについて
cyberagent
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
 
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティスAmazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon Web Services Japan
 
Amazon Inspectorについて
Amazon InspectorについてAmazon Inspectorについて
Amazon Inspectorについて
Amazon Web Services Japan
 
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分けビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
Recruit Technologies
 
組織の問題も解決するアーキテクチャ BackendsForFrontends
組織の問題も解決するアーキテクチャ BackendsForFrontends組織の問題も解決するアーキテクチャ BackendsForFrontends
組織の問題も解決するアーキテクチャ BackendsForFrontends
PIXTA Inc.
 
失敗から学ぶAWSの監視
失敗から学ぶAWSの監視失敗から学ぶAWSの監視
失敗から学ぶAWSの監視
株式会社オプト 仙台ラボラトリ
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
 
Kinesis Firehoseを使ってみた
Kinesis Firehoseを使ってみたKinesis Firehoseを使ってみた
Kinesis Firehoseを使ってみた
dcubeio
 
基礎からのEBS
基礎からのEBS基礎からのEBS
基礎からのEBS
宗 大栗
 

What's hot (20)

AWS Batch Fargate対応は何をもたらすか
AWS Batch Fargate対応は何をもたらすかAWS Batch Fargate対応は何をもたらすか
AWS Batch Fargate対応は何をもたらすか
 
nginx入門
nginx入門nginx入門
nginx入門
 
MongoDBの監視
MongoDBの監視MongoDBの監視
MongoDBの監視
 
後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜
 
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
 
WiredTigerを詳しく説明
WiredTigerを詳しく説明WiredTigerを詳しく説明
WiredTigerを詳しく説明
 
AWS CLIでAssumeRole
AWS CLIでAssumeRoleAWS CLIでAssumeRole
AWS CLIでAssumeRole
 
AWS Black Belt Online Seminar AWS上のJenkins活用方法
AWS Black Belt Online Seminar AWS上のJenkins活用方法AWS Black Belt Online Seminar AWS上のJenkins活用方法
AWS Black Belt Online Seminar AWS上のJenkins活用方法
 
Firebaseを利用するためにGCPとCloud IAMの 基本を理解しよう
Firebaseを利用するためにGCPとCloud IAMの 基本を理解しようFirebaseを利用するためにGCPとCloud IAMの 基本を理解しよう
Firebaseを利用するためにGCPとCloud IAMの 基本を理解しよう
 
ログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについてログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについて
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティスAmazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティス
 
Amazon Inspectorについて
Amazon InspectorについてAmazon Inspectorについて
Amazon Inspectorについて
 
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分けビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
 
組織の問題も解決するアーキテクチャ BackendsForFrontends
組織の問題も解決するアーキテクチャ BackendsForFrontends組織の問題も解決するアーキテクチャ BackendsForFrontends
組織の問題も解決するアーキテクチャ BackendsForFrontends
 
失敗から学ぶAWSの監視
失敗から学ぶAWSの監視失敗から学ぶAWSの監視
失敗から学ぶAWSの監視
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
 
Kinesis Firehoseを使ってみた
Kinesis Firehoseを使ってみたKinesis Firehoseを使ってみた
Kinesis Firehoseを使ってみた
 
基礎からのEBS
基礎からのEBS基礎からのEBS
基礎からのEBS
 

Similar to CyberAgentにおけるMongoDB

MacRubyとHotCocoaでMacのアプリを作ってみた
MacRubyとHotCocoaでMacのアプリを作ってみたMacRubyとHotCocoaでMacのアプリを作ってみた
MacRubyとHotCocoaでMacのアプリを作ってみた
Yukimitsu Izawa
 
LLTLIVE in Shibuya 2013.12.13
LLTLIVE in Shibuya 2013.12.13LLTLIVE in Shibuya 2013.12.13
LLTLIVE in Shibuya 2013.12.13maru_cc
 
MongoDBざっくり解説
MongoDBざっくり解説MongoDBざっくり解説
MongoDBざっくり解説
知教 本間
 
ngx_small_light
ngx_small_lightngx_small_light
ngx_small_light
Tatsuhiko Kubo
 
CasualなMongoDBのサービス運用Tips
CasualなMongoDBのサービス運用TipsCasualなMongoDBのサービス運用Tips
CasualなMongoDBのサービス運用Tips
Naoki Sega
 
とある会社のエンジニアたちのAndroidへのフリーダムな取り組み
とある会社のエンジニアたちのAndroidへのフリーダムな取り組みとある会社のエンジニアたちのAndroidへのフリーダムな取り組み
とある会社のエンジニアたちのAndroidへのフリーダムな取り組み
Kei Nakazawa
 
WEBアプリケーションビルド・ テストツール YEOMAN
WEBアプリケーションビルド・ テストツール YEOMAN WEBアプリケーションビルド・ テストツール YEOMAN
WEBアプリケーションビルド・ テストツール YEOMAN
kamiyam .
 
Google IO 2012 つまみ食い(1) ADT r20 の新機能
Google IO 2012 つまみ食い(1) ADT r20 の新機能Google IO 2012 つまみ食い(1) ADT r20 の新機能
Google IO 2012 つまみ食い(1) ADT r20 の新機能Takuya Fujimura
 
Agile japan2012懇親会事例発表
Agile japan2012懇親会事例発表Agile japan2012懇親会事例発表
Agile japan2012懇親会事例発表
Atsuyuki Matsuda
 
20130719 始めるdev ops
20130719 始めるdev ops20130719 始めるdev ops
20130719 始めるdev opsaktsk
 
Getting started raspberry pi osc hamamatsu
Getting started raspberry pi osc hamamatsuGetting started raspberry pi osc hamamatsu
Getting started raspberry pi osc hamamatsu
Masafumi Ohta
 
セプテーニさんでのセミナー
セプテーニさんでのセミナーセプテーニさんでのセミナー
セプテーニさんでのセミナー
Tokusei Noborio
 
Sinatraでwebアプリケーション開発を学ぶ
Sinatraでwebアプリケーション開発を学ぶSinatraでwebアプリケーション開発を学ぶ
Sinatraでwebアプリケーション開発を学ぶHiroshi Oyamada
 
「ほげエンジニア」の定義について #operationcasual
「ほげエンジニア」の定義について #operationcasual「ほげエンジニア」の定義について #operationcasual
「ほげエンジニア」の定義について #operationcasualSATOSHI TAGOMORI
 
配布用Supervisordによるnode.jsの運用
配布用Supervisordによるnode.jsの運用配布用Supervisordによるnode.jsの運用
配布用Supervisordによるnode.jsの運用
yut148atgmaildotcom
 
CodeIgniterでXMLを処理してみる
CodeIgniterでXMLを処理してみるCodeIgniterでXMLを処理してみる
CodeIgniterでXMLを処理してみる智之 大野
 
ゲームエフェクトセミナー:BISHAMONの導入と実践
ゲームエフェクトセミナー:BISHAMONの導入と実践ゲームエフェクトセミナー:BISHAMONの導入と実践
ゲームエフェクトセミナー:BISHAMONの導入と実践
Makoto Goto
 
雲と幻と呪われし姫君〜AWSにしてみた〜 in WordCrab Fukui 2013
雲と幻と呪われし姫君〜AWSにしてみた〜 in WordCrab Fukui 2013雲と幻と呪われし姫君〜AWSにしてみた〜 in WordCrab Fukui 2013
雲と幻と呪われし姫君〜AWSにしてみた〜 in WordCrab Fukui 2013Odyssey Eightbit
 
ソーシャルゲームのEMR活用事例
ソーシャルゲームのEMR活用事例ソーシャルゲームのEMR活用事例
ソーシャルゲームのEMR活用事例
知教 本間
 

Similar to CyberAgentにおけるMongoDB (20)

MacRubyとHotCocoaでMacのアプリを作ってみた
MacRubyとHotCocoaでMacのアプリを作ってみたMacRubyとHotCocoaでMacのアプリを作ってみた
MacRubyとHotCocoaでMacのアプリを作ってみた
 
LLTLIVE in Shibuya 2013.12.13
LLTLIVE in Shibuya 2013.12.13LLTLIVE in Shibuya 2013.12.13
LLTLIVE in Shibuya 2013.12.13
 
MongoDBざっくり解説
MongoDBざっくり解説MongoDBざっくり解説
MongoDBざっくり解説
 
ngx_small_light
ngx_small_lightngx_small_light
ngx_small_light
 
CasualなMongoDBのサービス運用Tips
CasualなMongoDBのサービス運用TipsCasualなMongoDBのサービス運用Tips
CasualなMongoDBのサービス運用Tips
 
とある会社のエンジニアたちのAndroidへのフリーダムな取り組み
とある会社のエンジニアたちのAndroidへのフリーダムな取り組みとある会社のエンジニアたちのAndroidへのフリーダムな取り組み
とある会社のエンジニアたちのAndroidへのフリーダムな取り組み
 
WEBアプリケーションビルド・ テストツール YEOMAN
WEBアプリケーションビルド・ テストツール YEOMAN WEBアプリケーションビルド・ テストツール YEOMAN
WEBアプリケーションビルド・ テストツール YEOMAN
 
Google IO 2012 つまみ食い(1) ADT r20 の新機能
Google IO 2012 つまみ食い(1) ADT r20 の新機能Google IO 2012 つまみ食い(1) ADT r20 の新機能
Google IO 2012 つまみ食い(1) ADT r20 の新機能
 
Agile japan2012懇親会事例発表
Agile japan2012懇親会事例発表Agile japan2012懇親会事例発表
Agile japan2012懇親会事例発表
 
20130719 始めるdev ops
20130719 始めるdev ops20130719 始めるdev ops
20130719 始めるdev ops
 
Getting started raspberry pi osc hamamatsu
Getting started raspberry pi osc hamamatsuGetting started raspberry pi osc hamamatsu
Getting started raspberry pi osc hamamatsu
 
セプテーニさんでのセミナー
セプテーニさんでのセミナーセプテーニさんでのセミナー
セプテーニさんでのセミナー
 
Sinatraでwebアプリケーション開発を学ぶ
Sinatraでwebアプリケーション開発を学ぶSinatraでwebアプリケーション開発を学ぶ
Sinatraでwebアプリケーション開発を学ぶ
 
「ほげエンジニア」の定義について #operationcasual
「ほげエンジニア」の定義について #operationcasual「ほげエンジニア」の定義について #operationcasual
「ほげエンジニア」の定義について #operationcasual
 
配布用Supervisordによるnode.jsの運用
配布用Supervisordによるnode.jsの運用配布用Supervisordによるnode.jsの運用
配布用Supervisordによるnode.jsの運用
 
CodeIgniterでXMLを処理してみる
CodeIgniterでXMLを処理してみるCodeIgniterでXMLを処理してみる
CodeIgniterでXMLを処理してみる
 
ゲームエフェクトセミナー:BISHAMONの導入と実践
ゲームエフェクトセミナー:BISHAMONの導入と実践ゲームエフェクトセミナー:BISHAMONの導入と実践
ゲームエフェクトセミナー:BISHAMONの導入と実践
 
雲と幻と呪われし姫君〜AWSにしてみた〜 in WordCrab Fukui 2013
雲と幻と呪われし姫君〜AWSにしてみた〜 in WordCrab Fukui 2013雲と幻と呪われし姫君〜AWSにしてみた〜 in WordCrab Fukui 2013
雲と幻と呪われし姫君〜AWSにしてみた〜 in WordCrab Fukui 2013
 
ソーシャルゲームのEMR活用事例
ソーシャルゲームのEMR活用事例ソーシャルゲームのEMR活用事例
ソーシャルゲームのEMR活用事例
 
Sacss sp5
Sacss sp5Sacss sp5
Sacss sp5
 

More from Akihiro Kuwano

今日はMongoDBの話はしない
今日はMongoDBの話はしない今日はMongoDBの話はしない
今日はMongoDBの話はしない
Akihiro Kuwano
 
銀河レベルのLT(とは)
銀河レベルのLT(とは)銀河レベルのLT(とは)
銀河レベルのLT(とは)
Akihiro Kuwano
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
 
AWSのNoSQL入門
AWSのNoSQL入門AWSのNoSQL入門
AWSのNoSQL入門
Akihiro Kuwano
 
ログ管理のベストプラクティス
ログ管理のベストプラクティスログ管理のベストプラクティス
ログ管理のベストプラクティス
Akihiro Kuwano
 
ビックデータ最適解とAWSにおける新しい武器
ビックデータ最適解とAWSにおける新しい武器ビックデータ最適解とAWSにおける新しい武器
ビックデータ最適解とAWSにおける新しい武器
Akihiro Kuwano
 
MongoDBの可能性の話
MongoDBの可能性の話MongoDBの可能性の話
MongoDBの可能性の話
Akihiro Kuwano
 
実環境にTerraform導入したら驚いた
実環境にTerraform導入したら驚いた実環境にTerraform導入したら驚いた
実環境にTerraform導入したら驚いた
Akihiro Kuwano
 
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
Akihiro Kuwano
 
WiredTigerストレージエンジン楽しい
WiredTigerストレージエンジン楽しいWiredTigerストレージエンジン楽しい
WiredTigerストレージエンジン楽しい
Akihiro Kuwano
 
NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
Akihiro Kuwano
 
Chef環境の闇
Chef環境の闇Chef環境の闇
Chef環境の闇
Akihiro Kuwano
 
アメーバピグにおける自作サーバ運用それからどうなった
アメーバピグにおける自作サーバ運用それからどうなったアメーバピグにおける自作サーバ運用それからどうなった
アメーバピグにおける自作サーバ運用それからどうなったAkihiro Kuwano
 
後悔しないもんごもんごの使い方 〜サーバ編〜
後悔しないもんごもんごの使い方 〜サーバ編〜後悔しないもんごもんごの使い方 〜サーバ編〜
後悔しないもんごもんごの使い方 〜サーバ編〜
Akihiro Kuwano
 
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。Akihiro Kuwano
 
AmebaのMongoDB活用事例
AmebaのMongoDB活用事例AmebaのMongoDB活用事例
AmebaのMongoDB活用事例Akihiro Kuwano
 
MongoDBのアレをアレする
MongoDBのアレをアレするMongoDBのアレをアレする
MongoDBのアレをアレする
Akihiro Kuwano
 
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)Akihiro Kuwano
 
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)Akihiro Kuwano
 
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。Akihiro Kuwano
 

More from Akihiro Kuwano (20)

今日はMongoDBの話はしない
今日はMongoDBの話はしない今日はMongoDBの話はしない
今日はMongoDBの話はしない
 
銀河レベルのLT(とは)
銀河レベルのLT(とは)銀河レベルのLT(とは)
銀河レベルのLT(とは)
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
AWSのNoSQL入門
AWSのNoSQL入門AWSのNoSQL入門
AWSのNoSQL入門
 
ログ管理のベストプラクティス
ログ管理のベストプラクティスログ管理のベストプラクティス
ログ管理のベストプラクティス
 
ビックデータ最適解とAWSにおける新しい武器
ビックデータ最適解とAWSにおける新しい武器ビックデータ最適解とAWSにおける新しい武器
ビックデータ最適解とAWSにおける新しい武器
 
MongoDBの可能性の話
MongoDBの可能性の話MongoDBの可能性の話
MongoDBの可能性の話
 
実環境にTerraform導入したら驚いた
実環境にTerraform導入したら驚いた実環境にTerraform導入したら驚いた
実環境にTerraform導入したら驚いた
 
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
 
WiredTigerストレージエンジン楽しい
WiredTigerストレージエンジン楽しいWiredTigerストレージエンジン楽しい
WiredTigerストレージエンジン楽しい
 
NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
 
Chef環境の闇
Chef環境の闇Chef環境の闇
Chef環境の闇
 
アメーバピグにおける自作サーバ運用それからどうなった
アメーバピグにおける自作サーバ運用それからどうなったアメーバピグにおける自作サーバ運用それからどうなった
アメーバピグにおける自作サーバ運用それからどうなった
 
後悔しないもんごもんごの使い方 〜サーバ編〜
後悔しないもんごもんごの使い方 〜サーバ編〜後悔しないもんごもんごの使い方 〜サーバ編〜
後悔しないもんごもんごの使い方 〜サーバ編〜
 
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
 
AmebaのMongoDB活用事例
AmebaのMongoDB活用事例AmebaのMongoDB活用事例
AmebaのMongoDB活用事例
 
MongoDBのアレをアレする
MongoDBのアレをアレするMongoDBのアレをアレする
MongoDBのアレをアレする
 
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
 
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
 
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
 

CyberAgentにおけるMongoDB