SlideShare a Scribd company logo
1 of 73
MongoDBのアレをアレする

             株式会社サイバーエージェント
             アメーバ事業本部ピグディヴィジョン



                             桑野 章弘




12年7月8日日曜日
アジェンダ

    MongoDBCasual
    もんごたんについておさらい
    運用時にあったこと集
    障害時何見る?
    まとめ




12年7月8日日曜日
自己紹介

    桑野章弘
       サイバーエージェント
              Ameba を運営しています。
              ピグライフの運用/構築を担当

       Twitter
              @kuwa_tw

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

       著書/活動
              「MySQLによるタフなサイトの作り方」



12年7月8日日曜日
MongoDBCasual
         ですね!


12年7月8日日曜日
Casualですね!



12年7月8日日曜日
なんかカジュアルじゃ
    ないっぽい、、、


12年7月8日日曜日
という人のためにこれ
    がカジュアルだとい
     うのを見せます
                5
12年7月8日日曜日
4
12年7月8日日曜日
俺だ!俺たちがカジュ
      アルだ!

                5
12年7月8日日曜日
と、



                  5
12年7月8日日曜日
その前にちょっと宣伝



                5
12年7月8日日曜日
ピグゲーム
  ピグのキャラクターで遊べるゲームのラインナップ
      ピグライフ
      ピグアイランド




                             6
12年7月8日日曜日
ピグゲーム




                3
12年7月8日日曜日
サービス情報

    ピグライフ
       2011/05/31オープン
       会員数360万人(2012/01現在)


    ピグアイランド
       2012/05/22オープン
       リリース後5日で会員数100万人突破




                              8
12年7月8日日曜日
ピグライフのアーキテクチャ:全体構成
                                        BackEnd
              FrontEnd

                                                   ユーザ/エリ
      staticサーバ            Node.jsサーバ
                           Socketサーバ               ア等の状態
                                                    データ

                                           mongodbサーバ
         Flashデータ            必要なデータ
          →リクエス                の取得
           ト/取得
  HTTP

             WebSocket接続


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


                                                            11
12年7月8日日曜日
MongoDBの構成
アプリケーションサー
     バ




   mongos            Mongod[ShardA]




                     Mongod[ShardB]




        mongoc
                     Mongod[ShardC]




12年7月8日日曜日
アーキテクチャについて

    システムアーキテクチャ
       冗長化
              ReplicaSets

       スケーラビリティ
              Sharding




                             13
12年7月8日日曜日
アーキテクチャの課題

    ReplicaSets
       相互死活監視&投票により冗長性を保つ。最小単位は
        3台。

                     プライマリ




             セカンダリ       セカンダリ




                                   23
12年7月8日日曜日
アーキテクチャの課題

    ReplicaSets
       相互死活監視&投票により冗長性を保つ。最小単位は
        3台。

     生きているサーバ        プライマリ
     で投票が行われ新
     しいプライマリが
     選ばれる




             セカンダリ   セカンダリ → プライマリ



                                     24
12年7月8日日曜日
アーキテクチャの課題

    Sharding
       データをChunkの細かい粒度に分割し、各
        mongodに分散して渡すことで各サーバの負荷を分
        散します




                                    19
12年7月8日日曜日
MongoDBの構成
                 Sharding
アプリケーションサー                                    ReplicaSetsに
                 データをChunk
     バ                                        よりサーバの冗長
                 の単位に分ける
                                              性を確保
        DATA


   mongos


                             Mongod[ShardA]




                             Mongod[ShardB]

        mongoc



                             Mongod[ShardC]




                                                             20
12年7月8日日曜日
MongoDBの構成
                          Sharding
アプリケーションサー                                             ReplicaSetsに
                          データをChunk
     バ                                                 よりサーバの冗長
                          の単位に分ける
                                                       性を確保
 ChunkA ChunkB ChunkC



   mongos

               mongocは
                                      Mongod[ShardA]
               シャーディング情
               報を持つ



                                      Mongod[ShardB]

         mongoc


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



                                                                      21
12年7月8日日曜日
MongoDBの構成
アプリケーションサー                                              ReplicaSetsに
     バ                                                  よりサーバの冗長
                       Sharding
                       データをChunk                        性を確保
                       の単位に分ける

   mongos

             mongocは
                              ChunkA   Mongod[ShardA]
             シャーディング情
             報を持つ



                              ChunkB   Mongod[ShardB]

        mongoc


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



                                                                       22
12年7月8日日曜日
アーキテクチャの課題

    MongoDBのこれら機能により、アプリ側の実
     装コストは軽く、スケーラビリティを保ったシス
     テム構築を手軽に使うことができます。
    サーバレベルの細かなチューニングは基本的には
     必要ありません(できない)と言う所は大きなメ
     リット
    サーバアーキテクチャをもんごに合わせていくイ
     メージ


                               25
12年7月8日日曜日
とはいえ



                    26
12年7月8日日曜日
ハマる部分はあるわけ
        で

                26
12年7月8日日曜日
もんごたんのきもちしりたい
      おっおっおっお(^ω^=^ω^)




                         26
12年7月8日日曜日
ということで



                      26
12年7月8日日曜日
運用時にあったこと集



                26
12年7月8日日曜日
 あれ、クラスターが遅いよ?
              必要なデータを一気にデータをインポートする
              oplogデータ量範囲を超えてレプリケーションが停止
              一度に入れたため、PrimaryShardにChunkが溜まって
              しまいI/Oバウンドに
              負荷が高いのでBalancerは動かない


                       _人人 人人_
                       > 突然の死 <
                        ̄Y^Y^Y^Y ̄


                                                  32
12年7月8日日曜日
 あれ、クラスターが遅いよ?
              シャードするコレクションを、シャード設定漏れ
              PrimaryShardでデータファイルが多くなり続けてメモリ
              マップドファイルのサイズを超えたためI/Oバウンドに
              シャードしてないのでもちろんBalancerは動かない




                      _人人 人人_
                      > 突然の死 <
                       ̄Y^Y^Y^Y ̄


                                                 32
12年7月8日日曜日
 シャード設定の不備に関して
              ほんとに突然パフォーマンスダウンする
              「10分前は快調だった、、、」「みんなそういうの」
              PrimaryShardは潤沢な状態にしておく
              シャード設定は定期的に確認、もしくはシャードの設定を自
              動化する




                                             32
12年7月8日日曜日
 運用スクリプト
       台数がおおくなってくると「標準のコマンドだと表示
        が辛いとか」「今のマスターの一覧が欲しいな」とか
        があるのでそのへんはスクリプト作成して対応
       このへんが作りやすいのは魅力




                                   32
12年7月8日日曜日
 運用スクリプト:内容
       ロックタイムの取得
       シャードに入っているmongod一覧のリスト出力
       レプリカセットのマスター検索
       レプリカセットのプライオリティ検索
       printShardingStatusの整形
       レプリカセット一括作成




                                   32
12年7月8日日曜日
 バックアップ
       mongodump
              mongosに対してmongodump実行するのはバックアッ
              プとしては一番簡単だけど、稼働中にかけると完全なポイン
              トイン・タイムのバックアップにはならないよ




                                                35
12年7月8日日曜日
 バックアップ
       稼働中にスナップショットバックアップを取得するに
        はこんな感じでやりましょう
              mongos経由でAutoBalancingをOff
              各レプリカセットにfsync lockをかける
              各mongodにmongodumpを実行してデータ取得
              各レプリカセットにfsync unlock
              mongos経由でAutoBalancingをOn




                                             35
12年7月8日日曜日
 ロック
       同じサーバ上に異常に書き込みの多いコレクションが
        あるとクラスタ全体のアクセスに影響します
       現状はクラスタを複数に分けています
       アプリ実装はコレクション間を疎結合で作る必要あり
       2.2系でコレクションレベルロックが実装されるとこ
        のような手間はなくなる(予定)です




                                    36
12年7月8日日曜日
 ロック




             Collection A   Collection B   Collection C




                                                          37
12年7月8日日曜日
 グローバルロック




             Collection A   Collection C   Collection B




                                                          38
12年7月8日日曜日
 グローバルロック




             Collection A   Collection C   Collection B




                                                          38
12年7月8日日曜日
もんごたんのきもちしりたい
      おっおっおっお(^ω^=^ω^)




                         26
12年7月8日日曜日
障害時何見る?



                       10
12年7月8日日曜日
障害の時じゃなくてもいいんですけど
      トレンドの変化がみたいとか。
      現状が把握したいとか。
      障害でもいい。
      まずはツールで。




                        11
12年7月8日日曜日
mongostat
      トレンドの変化がみたいとか。
      現状が把握したいとか。
      すべての基本です




                        12
12年7月8日日曜日
$ ./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


 192.168.8.41:27018      0 418 144     0  231  567   0 36.1g 76.2g 14.3g         0
 1.9      0   0¦0  2¦0 100k 908k 3056 RSTest1001 M 11:16:58
 192.168.8.62:27018      0 465 170     0  255  582   0 30.1g 63.9g 15.6g         1    3
 0    0¦0   2¦0 108k   1m 2587 RSTest1002 M 11:16:58




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




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



                                  12
12年7月8日日曜日
mongostat
      discoverオプションで、レプリカセットのメン
       バー、クラスタに入っているメンバーを全て抽出する
       ことが可能なので利用すると楽




                                   12
12年7月8日日曜日
mongotop
      現在重いmongodのどのcollectionへアクセスがか
       かっているかを確認したりとかできまする。
      障害の時がメイン
       mongostatで状況確認→mongotopでサーバ確認
       みたいな




                                        15
12年7月8日日曜日
$ /usr/local/mongodb2_1/bin/mongotop --host mongos_ip --port 27018
 connected to: mongos_ip


                     ns total     read       write      2012-05-23T02:14:10
              local.oplog.rs 1929ms 1929ms 0ms
           life_prd_main.Test 6ms    6ms    0ms
      life_prd_main.TestPoint 5ms      0ms    3ms
       life_prd_main.Test2Soil 5ms     0ms    5ms
                                                       writeに時間
   life_prd_main.TestMaterial 1ms        0ms   1ms     がかかってい
     life_prd_main.TestOnline 1ms       0ms   1ms
                                                           る
       life_prd_main.Test3 1ms      1ms    0ms
      life_prd_main.TestQuest 1ms       1ms    0ms
        life_prd_main.TestBan 0ms      0ms   0ms


                     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
           life_prd_main.Test 5ms    5ms   0ms
      life_prd_main.TestPoint 4ms      0ms   2ms
   life_prd_main.TestMaterial 2ms       0ms   2ms
       life_prd_main.Test3 1ms      1ms   0ms
      life_prd_main.TestQuest 1ms       1ms   0ms
        life_prd_main.TestBan 0ms      0ms  0ms




                                                                              17
12年7月8日日曜日
mtop
      標準ツールじゃないよ
      mongostatと同じようなデータが取れるけど、
       ちょっと足りないです。
      今流れているクエリを追える所がメリット、、、だけ
       ど db.currentOp()でいいかも。




                                   18
12年7月8日日曜日
$ ./mtop.py -s 192.168.0.100:27218
 192.168.0.100. v2.0.5, 64 bit. Conns: 1304/18696. Lock %: 0.02
 Mem: 12182 resident, 37120 virtual, 16617 mapped
 Ops: 2816 total, 633 getmore, 0 insert, 523 update, 602 command, 1058 query,
 0 delete
      ID         CLIENT    OP A LOCKW NS
 1184788867 192.168.0.112:43976 query T
 1184789134 192.168.0.149:48588 query T
 1184792427 192.168.0.143:36964 query T
 1184866702 192.168.0.103:58179 query T
 1184867005 192.168.0.126:55974 query T
 1184867347 192.168.0.102:36019 query T
 1184867986 192.168.0.129:37664 query T
 1184868008 192.168.0.151:59313 query T
 1184868757 192.168.0.105:46522 query T
 1184869686 192.168.0.154:43275 query T
 1184870569 192.168.0.107:58733 query T
 (snip)



                                                                          19
12年7月8日日曜日
mongosniff
      最後はパケットキャプチャですので、何か会った際の
       アクセス状況の確認が可能
      mongosのアクセス状況とか、複雑なクエリを見た
       い場合はこれで見るのが良い(これでみるしかない)
       です。




                                   21
12年7月8日日曜日
# 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




                                                                                            22
12年7月8日日曜日
ステータスコマンド




              23
12年7月8日日曜日
profiling
      遅いクエリ等の調査




                   24
12年7月8日日曜日
# mongo
 # プロファイルオンにする。この場合は10ms以上かかった、リード、ライトクエリが入る。
 PRIMARY> db.setProfilingLevel(2,10);
 { "was" : 2, "slowms" : 100, "ok" : 1 }


 (Profile確認)
 { "ts" : ISODate("2012-07-05T04:13:48.408Z"), "op" : "update", "ns" : "testdatabase.TestCol01", "query" : { "_id" :
 "4334521d75462355" }, "updateobj" : { "$set" : { "747465656e80aa0b" : 10 } }, "idhack" : true, "millis" : 0, "client" :
 "192.168.0.100", "Test" : "" }


 # もとに戻す
 PRIMARY> db.setProfilingLevel(0);
 { "was" : 2, "slowms" : 10, "ok" : 1 }




                                                                                                                       25
12年7月8日日曜日
Loglevel変更
      これもクエリもでるし、MongoDBの動作がおかし
       かった場合に必要
      ログの量が半端なくなるので注意




                                   26
12年7月8日日曜日
# mongo
 # ログレベルを5(最大)にする。
 PRIMARY> db.adminCommand({setParameter:1, logLevel:5})
 { "logLevel" : 0, "ok" : 1 }


 (ログ確認する)


 # もと(ログレベル0)に戻す
 PRIMARY> db.setProfilingLevel(0);
 { "logLevel" : 5, "ok" : 1 }




                                                          27
12年7月8日日曜日
db.adminCommand("connPo
    olStats")
      シャーディング環境におけるコネクションプールの統
       計




                                  28
12年7月8日日曜日
mongos> db.adminCommand("connPoolStats")
 {
    "hosts" : {
        "192.168.0.241:27019::0" : {
              "available" : 1,
              "created" : 1


 (snip)


     "createdByType" : {
          "master" : 175,
          "set" : 24,
          "sync" : 8
     },
     "totalAvailable" : 24,
     "totalCreated" : 207,
     "numDBClientConnection" : 215,
     "numAScopedConnection" : 28,
     "ok" : 1
 }




                                            29
12年7月8日日曜日
db.serverStatus()
      サーバの現在の状態の確認
      mongostatとか各種状況確認はほぼこれを見ている
      見られる項目
         Replicasets
         Journaling
         NW
         Index
         要するにほとんどすべて


                                     30
12年7月8日日曜日
PRIMARY> db.serverStatus()
 {
     "host" : "test-mongo01:27018",
     "version" : "2.0.5",
     "process" : "mongod",
     "uptime" : 731083,
     "uptimeEstimate" : 726409,
     "localTime" : ISODate("2012-05-23T05:55:14.419Z"),
     "globalLock" : {
          "totalTime" : 731082571520,
          "lockTime" : 21521333332,
          "ratio" : 0.029437623286867328,


 (snip)
     },
     "mem" : {



 (snip)




                                                          31
12年7月8日日曜日
(snip)


 "dur" : {
             "commits" : 27,
             "journaledMB" : 0.548864,
             "writeToDataFilesMB" : 1.069064,
             "compression" : 0.48677963816836817,
             "commitsInWriteLock" : 0,
             "earlyCommits" : 0,
             "timeMs" : {
                  "dt" : 3091,
                  "prepLogBuffer" : 3,
                  "writeToJournal" : 305,
                  "writeToDataFiles" : 17,
                  "remapPrivateView" : 2
             }
     },




                                                    31
12年7月8日日曜日
db.currentOp()
      データベースインスタンスについて進行中の現在の操
       作の確認




                                  32
12年7月8日日曜日
PRIMARY> db. currentOp()
 MongoDB shell version: 2.0.5
 connecting to: 127.0.0.1:27218/test
 {
      "inprog" : [
           {
 (snip)
                "opid" : 1654293341,
                "active" : false,
                "lockType" : "read",
                "waitingForLock" : false,
                "op" : "query",
                "ns" : "testdb.TestPoint",
                "query" : {
                     "_id" : "77667f763200000"
                },
                "client" : "192.168.0.125:34831",
                "desc" : "conn",
                "threadId" : "0x7f431322f700",
                "connectionId" : 53986,
                "numYields" : 0
           },
 (snip)


                                                    33
12年7月8日日曜日
まとめ



                   42
12年7月8日日曜日
もんごたんのきもちが
    わかるようになりま
       したか?
                5
12年7月8日日曜日
ね?



                  5
12年7月8日日曜日
Casualだったで
                 しょ?

                          5
12年7月8日日曜日
みんなもカジュアルに
    100シャード運用し
      てみようね!!
                 5
12年7月8日日曜日
このあともカジュアル
    なトークがいっぱい
       あるよ!
                5
12年7月8日日曜日
ご清聴ありがとうござ
      いました!

                5
12年7月8日日曜日

More Related Content

What's hot

MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜Takahiro Inoue
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説増田 亨
 
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界Yoshinori Nakanishi
 
MongoDB Configパラメータ解説
MongoDB Configパラメータ解説MongoDB Configパラメータ解説
MongoDB Configパラメータ解説Shoken Fujisaki
 
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話Yuta Shimada
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースHajime Yanagawa
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーyoku0825
 
MongoDBのはじめての運用テキスト
MongoDBのはじめての運用テキストMongoDBのはじめての運用テキスト
MongoDBのはじめての運用テキストAkihiro Kuwano
 
TIME_WAITに関する話
TIME_WAITに関する話TIME_WAITに関する話
TIME_WAITに関する話Takanori Sejima
 
PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発infinite_loop
 
MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座Mikiya Okuno
 
ストリーム処理におけるApache Avroの活用について(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
ストリーム処理におけるApache Avroの活用について(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)ストリーム処理におけるApache Avroの活用について(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
ストリーム処理におけるApache Avroの活用について(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)NTT DATA Technology & Innovation
 
カジュアルにMongo dbのbackup機能説明
カジュアルにMongo dbのbackup機能説明カジュアルにMongo dbのbackup機能説明
カジュアルにMongo dbのbackup機能説明Masakazu Matsushita
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較Yoshiyasu SAEKI
 
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方Hiroshi Tokumaru
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Yuki Morishita
 
MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜Naruhiko Ogasawara
 
Mongo dbを知ろう
Mongo dbを知ろうMongo dbを知ろう
Mongo dbを知ろうCROOZ, inc.
 

What's hot (20)

MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
 
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
 
MongoDB Configパラメータ解説
MongoDB Configパラメータ解説MongoDB Configパラメータ解説
MongoDB Configパラメータ解説
 
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
 
MongoDBのはじめての運用テキスト
MongoDBのはじめての運用テキストMongoDBのはじめての運用テキスト
MongoDBのはじめての運用テキスト
 
NoSQL3
NoSQL3NoSQL3
NoSQL3
 
TIME_WAITに関する話
TIME_WAITに関する話TIME_WAITに関する話
TIME_WAITに関する話
 
PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
 
MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座
 
ストリーム処理におけるApache Avroの活用について(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
ストリーム処理におけるApache Avroの活用について(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)ストリーム処理におけるApache Avroの活用について(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
ストリーム処理におけるApache Avroの活用について(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
 
カジュアルにMongo dbのbackup機能説明
カジュアルにMongo dbのbackup機能説明カジュアルにMongo dbのbackup機能説明
カジュアルにMongo dbのbackup機能説明
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較
 
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
 
MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜
 
Mongo dbを知ろう
Mongo dbを知ろうMongo dbを知ろう
Mongo dbを知ろう
 

Similar to MongoDBのアレをアレする

大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)Akihiro Kuwano
 
AmebaのMongoDB活用事例
AmebaのMongoDB活用事例AmebaのMongoDB活用事例
AmebaのMongoDB活用事例Akihiro Kuwano
 
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい) 泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい) Akihiro Kuwano
 
CasualなMongoDBのサービス運用Tips
CasualなMongoDBのサービス運用TipsCasualなMongoDBのサービス運用Tips
CasualなMongoDBのサービス運用TipsNaoki Sega
 
Crooz meet fusion io3 open
Crooz meet fusion io3 openCrooz meet fusion io3 open
Crooz meet fusion io3 opentakaoka susumu
 
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?Hiroaki Kubota
 
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニックinfinite_loop
 
ソーシャルゲームログ解析基盤のMongoDB活用事例
ソーシャルゲームログ解析基盤のMongoDB活用事例ソーシャルゲームログ解析基盤のMongoDB活用事例
ソーシャルゲームログ解析基盤のMongoDB活用事例知教 本間
 
Couch Db勉強会0623 by yssk22
Couch Db勉強会0623 by yssk22Couch Db勉強会0623 by yssk22
Couch Db勉強会0623 by yssk22Yohei Sasaki
 
B 2-1 はじめての Windows Azure
B 2-1 はじめての Windows AzureB 2-1 はじめての Windows Azure
B 2-1 はじめての Windows AzureGoAzure
 
ソーシャルアプリを分析してみた
ソーシャルアプリを分析してみたソーシャルアプリを分析してみた
ソーシャルアプリを分析してみたDrecom Co., Ltd.
 
MongoDBざっくり解説
MongoDBざっくり解説MongoDBざっくり解説
MongoDBざっくり解説知教 本間
 
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~じゅん なかざ
 
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version - ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version - Tetsutaro Watanabe
 
Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14Masahiro Nagano
 
Mongo dbを知ろう devlove関西
Mongo dbを知ろう   devlove関西Mongo dbを知ろう   devlove関西
Mongo dbを知ろう devlove関西Ryuji Tamagawa
 
20130313 OSCA Hadoopセミナー
20130313 OSCA Hadoopセミナー20130313 OSCA Hadoopセミナー
20130313 OSCA HadoopセミナーIchiro Fukuda
 

Similar to MongoDBのアレをアレする (20)

大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
 
AmebaのMongoDB活用事例
AmebaのMongoDB活用事例AmebaのMongoDB活用事例
AmebaのMongoDB活用事例
 
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい) 泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
 
CasualなMongoDBのサービス運用Tips
CasualなMongoDBのサービス運用TipsCasualなMongoDBのサービス運用Tips
CasualなMongoDBのサービス運用Tips
 
ヤフーを支えるフラッシュストレージ
ヤフーを支えるフラッシュストレージヤフーを支えるフラッシュストレージ
ヤフーを支えるフラッシュストレージ
 
Crooz meet fusion io3 open
Crooz meet fusion io3 openCrooz meet fusion io3 open
Crooz meet fusion io3 open
 
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?
 
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
 
ソーシャルゲームログ解析基盤のMongoDB活用事例
ソーシャルゲームログ解析基盤のMongoDB活用事例ソーシャルゲームログ解析基盤のMongoDB活用事例
ソーシャルゲームログ解析基盤のMongoDB活用事例
 
Couch Db勉強会0623 by yssk22
Couch Db勉強会0623 by yssk22Couch Db勉強会0623 by yssk22
Couch Db勉強会0623 by yssk22
 
Osc 20130223
Osc 20130223Osc 20130223
Osc 20130223
 
B 2-1 はじめての Windows Azure
B 2-1 はじめての Windows AzureB 2-1 はじめての Windows Azure
B 2-1 はじめての Windows Azure
 
Metaspace
MetaspaceMetaspace
Metaspace
 
ソーシャルアプリを分析してみた
ソーシャルアプリを分析してみたソーシャルアプリを分析してみた
ソーシャルアプリを分析してみた
 
MongoDBざっくり解説
MongoDBざっくり解説MongoDBざっくり解説
MongoDBざっくり解説
 
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
 
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version - ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
 
Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14
 
Mongo dbを知ろう devlove関西
Mongo dbを知ろう   devlove関西Mongo dbを知ろう   devlove関西
Mongo dbを知ろう devlove関西
 
20130313 OSCA Hadoopセミナー
20130313 OSCA Hadoopセミナー20130313 OSCA Hadoopセミナー
20130313 OSCA Hadoopセミナー
 

More from Akihiro Kuwano

今日はMongoDBの話はしない
今日はMongoDBの話はしない今日はMongoDBの話はしない
今日はMongoDBの話はしないAkihiro Kuwano
 
銀河レベルのLT(とは)
銀河レベルのLT(とは)銀河レベルのLT(とは)
銀河レベルのLT(とは)Akihiro Kuwano
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス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
 
アメーバピグにおける自作サーバ運用それからどうなった
アメーバピグにおける自作サーバ運用それからどうなったアメーバピグにおける自作サーバ運用それからどうなった
アメーバピグにおける自作サーバ運用それからどうなったAkihiro Kuwano
 
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDBCyberAgentにおけるMongoDB
CyberAgentにおけるMongoDBAkihiro Kuwano
 
後悔しないもんごもんごの使い方 〜サーバ編〜
後悔しないもんごもんごの使い方 〜サーバ編〜後悔しないもんごもんごの使い方 〜サーバ編〜
後悔しないもんごもんごの使い方 〜サーバ編〜Akihiro Kuwano
 
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。Akihiro Kuwano
 
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)Akihiro Kuwano
 
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。Akihiro Kuwano
 
qpstudy 〜初心者にやさしいインフラ勉強会〜 の紹介
qpstudy 〜初心者にやさしいインフラ勉強会〜 の紹介qpstudy 〜初心者にやさしいインフラ勉強会〜 の紹介
qpstudy 〜初心者にやさしいインフラ勉強会〜 の紹介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環境の闇
 
アメーバピグにおける自作サーバ運用それからどうなった
アメーバピグにおける自作サーバ運用それからどうなったアメーバピグにおける自作サーバ運用それからどうなった
アメーバピグにおける自作サーバ運用それからどうなった
 
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDBCyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
 
後悔しないもんごもんごの使い方 〜サーバ編〜
後悔しないもんごもんごの使い方 〜サーバ編〜後悔しないもんごもんごの使い方 〜サーバ編〜
後悔しないもんごもんごの使い方 〜サーバ編〜
 
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
勉強会コミュニティがぼくの エンジニア人生にもたらした事。 あと、NoSQLとの付き合い方。
 
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮)
 
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
オンプレエンジニアがクラウドエンジニアを夢見て。じっと手を見る。
 
qpstudy 〜初心者にやさしいインフラ勉強会〜 の紹介
qpstudy 〜初心者にやさしいインフラ勉強会〜 の紹介qpstudy 〜初心者にやさしいインフラ勉強会〜 の紹介
qpstudy 〜初心者にやさしいインフラ勉強会〜 の紹介
 
[大図解]ピグライフはこう動いている
[大図解]ピグライフはこう動いている[大図解]ピグライフはこう動いている
[大図解]ピグライフはこう動いている
 

Recently uploaded

Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Yuma Ohgami
 
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...Toru Tamaki
 
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムsugiuralab
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略Ryo Sasaki
 
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A surveyToru Tamaki
 
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Danieldanielhu54
 
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する       2024/04/19 の勉強会で発表されたものですSOPを理解する       2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものですiPride Co., Ltd.
 
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNetToru Tamaki
 
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdfTSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdftaisei2219
 

Recently uploaded (9)

Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
 
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
 
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
 
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
 
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Daniel
 
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する       2024/04/19 の勉強会で発表されたものですSOPを理解する       2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
 
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
 
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdfTSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
 

MongoDBのアレをアレする

  • 1. MongoDBのアレをアレする 株式会社サイバーエージェント アメーバ事業本部ピグディヴィジョン                 桑野 章弘 12年7月8日日曜日
  • 2. アジェンダ  MongoDBCasual  もんごたんについておさらい  運用時にあったこと集  障害時何見る?  まとめ 12年7月8日日曜日
  • 3. 自己紹介  桑野章弘  サイバーエージェント  Ameba を運営しています。  ピグライフの運用/構築を担当  Twitter  @kuwa_tw  Blog  http://d.hatena.ne.jp/akuwano/  著書/活動  「MySQLによるタフなサイトの作り方」 12年7月8日日曜日
  • 4. MongoDBCasual ですね! 12年7月8日日曜日
  • 6. なんかカジュアルじゃ ないっぽい、、、 12年7月8日日曜日
  • 7. という人のためにこれ がカジュアルだとい うのを見せます 5 12年7月8日日曜日
  • 9. 俺だ!俺たちがカジュ アルだ! 5 12年7月8日日曜日
  • 10. と、 5 12年7月8日日曜日
  • 11. その前にちょっと宣伝 5 12年7月8日日曜日
  • 12. ピグゲーム  ピグのキャラクターで遊べるゲームのラインナップ  ピグライフ  ピグアイランド 6 12年7月8日日曜日
  • 13. ピグゲーム 3 12年7月8日日曜日
  • 14. サービス情報  ピグライフ  2011/05/31オープン  会員数360万人(2012/01現在)  ピグアイランド  2012/05/22オープン  リリース後5日で会員数100万人突破 8 12年7月8日日曜日
  • 15. ピグライフのアーキテクチャ:全体構成 BackEnd FrontEnd ユーザ/エリ staticサーバ Node.jsサーバ Socketサーバ ア等の状態 データ mongodbサーバ Flashデータ 必要なデータ →リクエス の取得 ト/取得 HTTP WebSocket接続 ・ユーザ情報 ・チャット データ →リクエス ユーザ ト/取得 (ブラウザ) 11 12年7月8日日曜日
  • 16. MongoDBの構成 アプリケーションサー バ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 12年7月8日日曜日
  • 17. アーキテクチャについて  システムアーキテクチャ  冗長化  ReplicaSets  スケーラビリティ  Sharding 13 12年7月8日日曜日
  • 18. アーキテクチャの課題  ReplicaSets  相互死活監視&投票により冗長性を保つ。最小単位は 3台。 プライマリ セカンダリ セカンダリ 23 12年7月8日日曜日
  • 19. アーキテクチャの課題  ReplicaSets  相互死活監視&投票により冗長性を保つ。最小単位は 3台。 生きているサーバ プライマリ で投票が行われ新 しいプライマリが 選ばれる セカンダリ セカンダリ → プライマリ 24 12年7月8日日曜日
  • 20. アーキテクチャの課題  Sharding  データをChunkの細かい粒度に分割し、各 mongodに分散して渡すことで各サーバの負荷を分 散します 19 12年7月8日日曜日
  • 21. MongoDBの構成 Sharding アプリケーションサー ReplicaSetsに データをChunk バ よりサーバの冗長 の単位に分ける 性を確保 DATA mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 20 12年7月8日日曜日
  • 22. MongoDBの構成 Sharding アプリケーションサー ReplicaSetsに データをChunk バ よりサーバの冗長 の単位に分ける 性を確保 ChunkA ChunkB ChunkC mongos mongocは Mongod[ShardA] シャーディング情 報を持つ Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB Mongod[ShardC] ChunkC -> ShardC 21 12年7月8日日曜日
  • 23. MongoDBの構成 アプリケーションサー ReplicaSetsに バ よりサーバの冗長 Sharding データをChunk 性を確保 の単位に分ける mongos mongocは ChunkA Mongod[ShardA] シャーディング情 報を持つ ChunkB Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB ChunkC Mongod[ShardC] ChunkC -> ShardC 22 12年7月8日日曜日
  • 24. アーキテクチャの課題  MongoDBのこれら機能により、アプリ側の実 装コストは軽く、スケーラビリティを保ったシス テム構築を手軽に使うことができます。  サーバレベルの細かなチューニングは基本的には 必要ありません(できない)と言う所は大きなメ リット  サーバアーキテクチャをもんごに合わせていくイ メージ 25 12年7月8日日曜日
  • 25. とはいえ 26 12年7月8日日曜日
  • 26. ハマる部分はあるわけ で 26 12年7月8日日曜日
  • 27. もんごたんのきもちしりたい おっおっおっお(^ω^=^ω^) 26 12年7月8日日曜日
  • 28. ということで 26 12年7月8日日曜日
  • 29. 運用時にあったこと集 26 12年7月8日日曜日
  • 30.  あれ、クラスターが遅いよ?  必要なデータを一気にデータをインポートする  oplogデータ量範囲を超えてレプリケーションが停止  一度に入れたため、PrimaryShardにChunkが溜まって しまいI/Oバウンドに  負荷が高いのでBalancerは動かない _人人 人人_ > 突然の死 <  ̄Y^Y^Y^Y ̄ 32 12年7月8日日曜日
  • 31.  あれ、クラスターが遅いよ?  シャードするコレクションを、シャード設定漏れ  PrimaryShardでデータファイルが多くなり続けてメモリ マップドファイルのサイズを超えたためI/Oバウンドに  シャードしてないのでもちろんBalancerは動かない _人人 人人_ > 突然の死 <  ̄Y^Y^Y^Y ̄ 32 12年7月8日日曜日
  • 32.  シャード設定の不備に関して  ほんとに突然パフォーマンスダウンする 「10分前は快調だった、、、」「みんなそういうの」  PrimaryShardは潤沢な状態にしておく  シャード設定は定期的に確認、もしくはシャードの設定を自 動化する 32 12年7月8日日曜日
  • 33.  運用スクリプト  台数がおおくなってくると「標準のコマンドだと表示 が辛いとか」「今のマスターの一覧が欲しいな」とか があるのでそのへんはスクリプト作成して対応  このへんが作りやすいのは魅力 32 12年7月8日日曜日
  • 34.  運用スクリプト:内容  ロックタイムの取得  シャードに入っているmongod一覧のリスト出力  レプリカセットのマスター検索  レプリカセットのプライオリティ検索  printShardingStatusの整形  レプリカセット一括作成 32 12年7月8日日曜日
  • 35.  バックアップ  mongodump  mongosに対してmongodump実行するのはバックアッ プとしては一番簡単だけど、稼働中にかけると完全なポイン トイン・タイムのバックアップにはならないよ 35 12年7月8日日曜日
  • 36.  バックアップ  稼働中にスナップショットバックアップを取得するに はこんな感じでやりましょう  mongos経由でAutoBalancingをOff  各レプリカセットにfsync lockをかける  各mongodにmongodumpを実行してデータ取得  各レプリカセットにfsync unlock  mongos経由でAutoBalancingをOn 35 12年7月8日日曜日
  • 37.  ロック  同じサーバ上に異常に書き込みの多いコレクションが あるとクラスタ全体のアクセスに影響します  現状はクラスタを複数に分けています  アプリ実装はコレクション間を疎結合で作る必要あり  2.2系でコレクションレベルロックが実装されるとこ のような手間はなくなる(予定)です 36 12年7月8日日曜日
  • 38.  ロック Collection A Collection B Collection C 37 12年7月8日日曜日
  • 39.  グローバルロック Collection A Collection C Collection B 38 12年7月8日日曜日
  • 40.  グローバルロック Collection A Collection C Collection B 38 12年7月8日日曜日
  • 41. もんごたんのきもちしりたい おっおっおっお(^ω^=^ω^) 26 12年7月8日日曜日
  • 42. 障害時何見る? 10 12年7月8日日曜日
  • 43. 障害の時じゃなくてもいいんですけど  トレンドの変化がみたいとか。  現状が把握したいとか。  障害でもいい。  まずはツールで。 11 12年7月8日日曜日
  • 44. mongostat  トレンドの変化がみたいとか。  現状が把握したいとか。  すべての基本です 12 12年7月8日日曜日
  • 45. $ ./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 192.168.8.41:27018 0 418 144 0 231 567 0 36.1g 76.2g 14.3g 0 1.9 0 0¦0 2¦0 100k 908k 3056 RSTest1001 M 11:16:58 192.168.8.62:27018 0 465 170 0 255 582 0 30.1g 63.9g 15.6g 1 3 0 0¦0 2¦0 108k 1m 2587 RSTest1002 M 11:16:58 13 12年7月8日日曜日
  • 46. mongostat - 見るべき項目  faults - 1秒当りのページフォールト数  Locked % - グローバルライトロックの時間割合  idx miss % - indexのヒット率の時間割合  qr¦qw - 読み込みキュー¦書き込みキュー の大きさ 12 12年7月8日日曜日
  • 47. mongostat - 見るべき項目  faults が多い場合 キャッシュメモリ溢れの可能性があるので、メモリ、 もしくはサーバを増設  Locked % が高い場合 書き込みのクエリを見直すか、クラスタを分ける。  qr¦qw が高い場合 サーバ負荷が低ければ、ロックの可能性を疑う。負荷 が高ければ単純なクエリ増による高負荷を疑う。 12 12年7月8日日曜日
  • 48. mongostat  discoverオプションで、レプリカセットのメン バー、クラスタに入っているメンバーを全て抽出する ことが可能なので利用すると楽 12 12年7月8日日曜日
  • 49. mongotop  現在重いmongodのどのcollectionへアクセスがか かっているかを確認したりとかできまする。  障害の時がメイン mongostatで状況確認→mongotopでサーバ確認 みたいな 15 12年7月8日日曜日
  • 50. $ /usr/local/mongodb2_1/bin/mongotop --host mongos_ip --port 27018 connected to: mongos_ip ns total read write 2012-05-23T02:14:10 local.oplog.rs 1929ms 1929ms 0ms life_prd_main.Test 6ms 6ms 0ms life_prd_main.TestPoint 5ms 0ms 3ms life_prd_main.Test2Soil 5ms 0ms 5ms writeに時間 life_prd_main.TestMaterial 1ms 0ms 1ms がかかってい life_prd_main.TestOnline 1ms 0ms 1ms る life_prd_main.Test3 1ms 1ms 0ms life_prd_main.TestQuest 1ms 1ms 0ms life_prd_main.TestBan 0ms 0ms 0ms 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 life_prd_main.Test 5ms 5ms 0ms life_prd_main.TestPoint 4ms 0ms 2ms life_prd_main.TestMaterial 2ms 0ms 2ms life_prd_main.Test3 1ms 1ms 0ms life_prd_main.TestQuest 1ms 1ms 0ms life_prd_main.TestBan 0ms 0ms 0ms 17 12年7月8日日曜日
  • 51. mtop  標準ツールじゃないよ  mongostatと同じようなデータが取れるけど、 ちょっと足りないです。  今流れているクエリを追える所がメリット、、、だけ ど db.currentOp()でいいかも。 18 12年7月8日日曜日
  • 52. $ ./mtop.py -s 192.168.0.100:27218 192.168.0.100. v2.0.5, 64 bit. Conns: 1304/18696. Lock %: 0.02 Mem: 12182 resident, 37120 virtual, 16617 mapped Ops: 2816 total, 633 getmore, 0 insert, 523 update, 602 command, 1058 query, 0 delete ID CLIENT OP A LOCKW NS 1184788867 192.168.0.112:43976 query T 1184789134 192.168.0.149:48588 query T 1184792427 192.168.0.143:36964 query T 1184866702 192.168.0.103:58179 query T 1184867005 192.168.0.126:55974 query T 1184867347 192.168.0.102:36019 query T 1184867986 192.168.0.129:37664 query T 1184868008 192.168.0.151:59313 query T 1184868757 192.168.0.105:46522 query T 1184869686 192.168.0.154:43275 query T 1184870569 192.168.0.107:58733 query T (snip) 19 12年7月8日日曜日
  • 53. mongosniff  最後はパケットキャプチャですので、何か会った際の アクセス状況の確認が可能  mongosのアクセス状況とか、複雑なクエリを見た い場合はこれで見るのが良い(これでみるしかない) です。 21 12年7月8日日曜日
  • 54. # 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 22 12年7月8日日曜日
  • 55. ステータスコマンド 23 12年7月8日日曜日
  • 56. profiling  遅いクエリ等の調査 24 12年7月8日日曜日
  • 57. # mongo # プロファイルオンにする。この場合は10ms以上かかった、リード、ライトクエリが入る。 PRIMARY> db.setProfilingLevel(2,10); { "was" : 2, "slowms" : 100, "ok" : 1 } (Profile確認) { "ts" : ISODate("2012-07-05T04:13:48.408Z"), "op" : "update", "ns" : "testdatabase.TestCol01", "query" : { "_id" : "4334521d75462355" }, "updateobj" : { "$set" : { "747465656e80aa0b" : 10 } }, "idhack" : true, "millis" : 0, "client" : "192.168.0.100", "Test" : "" } # もとに戻す PRIMARY> db.setProfilingLevel(0); { "was" : 2, "slowms" : 10, "ok" : 1 } 25 12年7月8日日曜日
  • 58. Loglevel変更  これもクエリもでるし、MongoDBの動作がおかし かった場合に必要  ログの量が半端なくなるので注意 26 12年7月8日日曜日
  • 59. # mongo # ログレベルを5(最大)にする。 PRIMARY> db.adminCommand({setParameter:1, logLevel:5}) { "logLevel" : 0, "ok" : 1 } (ログ確認する) # もと(ログレベル0)に戻す PRIMARY> db.setProfilingLevel(0); { "logLevel" : 5, "ok" : 1 } 27 12年7月8日日曜日
  • 60. db.adminCommand("connPo olStats")  シャーディング環境におけるコネクションプールの統 計 28 12年7月8日日曜日
  • 61. mongos> db.adminCommand("connPoolStats") { "hosts" : { "192.168.0.241:27019::0" : { "available" : 1, "created" : 1 (snip) "createdByType" : { "master" : 175, "set" : 24, "sync" : 8 }, "totalAvailable" : 24, "totalCreated" : 207, "numDBClientConnection" : 215, "numAScopedConnection" : 28, "ok" : 1 } 29 12年7月8日日曜日
  • 62. db.serverStatus()  サーバの現在の状態の確認  mongostatとか各種状況確認はほぼこれを見ている  見られる項目 Replicasets Journaling NW Index 要するにほとんどすべて 30 12年7月8日日曜日
  • 63. PRIMARY> db.serverStatus() { "host" : "test-mongo01:27018", "version" : "2.0.5", "process" : "mongod", "uptime" : 731083, "uptimeEstimate" : 726409, "localTime" : ISODate("2012-05-23T05:55:14.419Z"), "globalLock" : { "totalTime" : 731082571520, "lockTime" : 21521333332, "ratio" : 0.029437623286867328, (snip) }, "mem" : { (snip) 31 12年7月8日日曜日
  • 64. (snip) "dur" : { "commits" : 27, "journaledMB" : 0.548864, "writeToDataFilesMB" : 1.069064, "compression" : 0.48677963816836817, "commitsInWriteLock" : 0, "earlyCommits" : 0, "timeMs" : { "dt" : 3091, "prepLogBuffer" : 3, "writeToJournal" : 305, "writeToDataFiles" : 17, "remapPrivateView" : 2 } }, 31 12年7月8日日曜日
  • 65. db.currentOp()  データベースインスタンスについて進行中の現在の操 作の確認 32 12年7月8日日曜日
  • 66. PRIMARY> db. currentOp() MongoDB shell version: 2.0.5 connecting to: 127.0.0.1:27218/test { "inprog" : [ { (snip) "opid" : 1654293341, "active" : false, "lockType" : "read", "waitingForLock" : false, "op" : "query", "ns" : "testdb.TestPoint", "query" : { "_id" : "77667f763200000" }, "client" : "192.168.0.125:34831", "desc" : "conn", "threadId" : "0x7f431322f700", "connectionId" : 53986, "numYields" : 0 }, (snip) 33 12年7月8日日曜日
  • 67. まとめ 42 12年7月8日日曜日
  • 68. もんごたんのきもちが わかるようになりま したか? 5 12年7月8日日曜日
  • 69. ね? 5 12年7月8日日曜日
  • 70. Casualだったで しょ? 5 12年7月8日日曜日
  • 71. みんなもカジュアルに 100シャード運用し てみようね!! 5 12年7月8日日曜日
  • 72. このあともカジュアル なトークがいっぱい あるよ! 5 12年7月8日日曜日
  • 73. ご清聴ありがとうござ いました! 5 12年7月8日日曜日