MongoDB Ops ManagerでSharded Cluster Automation Deployしてみた。
多分Cloud版MMSの人は既に使ってるかもしれないんですけど、On-Premises版のOps Managerが出たのでAutomationをやってみました。 いわゆる使ってみた系記事です。
やり方はOps ManagerのDocument通りなので、スクショ取りながら備考録。
Install直後
Automation, Backup, Monitoring なんか左から順番にやりたくなりがちですが、全て揃えなければいけないわけでなくて、Monitoringだけでも十分だと思います。 Automationは簡単に色々Deployできるのですけど、手動で作業しないといけなかったり、再起動がかかったりとかあるので、ちゃんと理解してから使ったほうがいいなと思いました。 既にMongoDBで色々運用されている場合は手助けになるかと思います。 BackupはCloudだと有料サービスだったと思うんですけど、On-PremisesだとStorageの見積もりとかいろいろ準備が必要なので、今回は試していません。
Automation configuration
今回はAutomationに絞って紹介するので、AutomationをGET STARTED。
Deploy Destination
Localは自分の今接続しているPCにAutomation AgentをInstallして、自分のlocalにMongoDB (cluster)をSetupします。テスト用ですね。 Remoteの他のいろんなServerにDeployする場合はOther Remoteを選択してください。 こんかいはこっち。
Deploy Type
次にSetupするMongoDBの種類を選びます。
- Standalone
mongod
1 Processだけインストールします。 - Replica Set
mongod
を奇数台インストールして、Replica Setを構築します。 - Sharded Cluster
指定したShard数分のReplica Setと、
mongos
、そしてConfig Serverを構築します。 立ち上がるProcess数は、mongod (replSet * shard + 3 config) + mongos (任意) 分です。 config serverはServer数によって1台となる時もあります。
今回はSharded Clusterを選択しました。
Sharded cluster configuration
Sharded cluster全体の設定を行います。
今回Cluster NameとShard Name Prefixを同じにしていますが、分けたほうが良かったかなーと思います。
dbPath
が/data/mongodb/test-sharded/{Cluster Name}_{Shard Name Prefix}_{Shard num}_{ReplSet num}/
となるためです。
ShardやNodeの数は後で増やせるので最小でもOKかと。(画像の設定が最小です)
Install automation agent
各ServerにAgentをInstallする画面です。 これは各Serverに入って手動でやることとなります。 まぁただ手順はコピペ+config file数行編集で終わります。
Server上でAutomation Agentが起動されて、Verifyされるとこんなかんじで●がついて、次のServerのAgentがDownloadできるようになります。
ちなみにI have [***] severs:
の部分を変更すると、実際のServer数を変更できます。
Process数自体は先の手順である程度決まっていますが、MongoDBは同じServer上に複数のmongod/mongosを共存させることができるので、それぞれの環境に合わせて変更してください。
今回はtestなので、1
にします。
Directoryについて
MongoDB binaryなどをインストールするディレクトリはDefaultで/var/lib/mongodb-mms-automation
です。
これを変更する場合は[Administration] → [Agents] → [Binary Download Directory]
で変更できます。
気づきにくいので変更する場合は注意してください〜。
Review & Deploy
Deploy確認画面です。 ここでどのServerにどのProcessをInstallするかをDrag&Dropで変更することができます。 (今回は1台しかないのでそのままです)
CNAME
この画面でCNAMEに関するWarningが出ています。 これはMongoDB Config ServerのHAに関するものです。 簡単に説明すると、障害などでConfig ServerをReplaceするときに、mongosのconfigDBで設定した値をOnlineで変更することができないため、同一のHostnameを持つようDNSなどで設定が必要になります。 もし、mongosのconfigDBを変更するとしたらCluster全体の再起動が必要となります。 このため、Production環境ではCNAMEをすべてのConfig Serverに割り当てておく必要があります。 (今回はTestのためCNAME割り当てずに進めています)
Deployment
Deployが開始されると、Ops Managerと各Server上のAutomation Agentで通信して、MongoDBのSetupが始まります。 しばらく待てば以下の様な画面でDeployが完了されます。 (大体2-3分程度で終わった)
この状態でview modeにするとMonitoringのSetupも既に完了されていることが確認できます。 あとは使うだけ、と言った感じですね。
とりあえず完全まっさらなServerに対して新規にMongoDB clusterを構築するところまでやりました。 昨今だといろんなToolでDeploy自動化されてたりすると思うんですけど、MongoDBは1つのServer上に色々なProcess走らせたりするので、こういう選択肢もあっていいかなと。
でも、先述したとおり変更に対する影響はしっかり考えなければいけないです。 「Deployおわらないwww」で調べたら「データ消さないといけないwwwwwwww」になるパターンも簡単に再現できます。(当たり前ですけどStorage Engine変更とか)
現状だとConfigurationがDefaultのままなので、次はCluster全体にいろいろ設定を変更させてみようと思いますー。
MMS - MongoDB Management Service Mongioring agent 2.xへ
つい先日、MongoDBのMonitoring/Backupをクラウドで行うシステム、 MMSのMonitoring Agentがメジャーアップグレードしました。(今気づきました)
- MMS - http://mms.mongodb.com/
- MMS Monitoring Agent Changelog - http://mms.mongodb.com/help/monitoring/changelog/
主な変更としては、これまでの1.x系で使われていたpythonを使用しなくなったとのこと。 たまたま機器入れ替えがあって、Monitoringシステムチェックしてたので入れてみました。
とりあえず、速いっす。⊂(^ω^)⊃ これまでpython版のMMS agentはデーモン立ち上げの時とか少しラグが出てる感じでしたけど、なんか速いっすね。 あんまり中身まで見ていないのでフィーリングですが。 (pythonだと外部通信のところでちょっと処理が遅い気がします。urllibあたり。フィーリングです。)
インストールの方法も簡単です。 rpmダウンロードしてインストールするだけ。(前もそうでしたけど。サービス登録の手間とか云々) http://mms.mongodb.com/help/monitoring/tutorial/set-up-mms/
ただ、自分の担当しているMongoDBは、MMS上で幾つかのグループにわけてあるのですが、 rpmでインストールされる起動スクリプトでは一つのmmsApiKeyしか対応できないので、少しいじりました。
以下にGist置いときます。
MMS Monitor agent: Modify to be able to launch eac ...
起動方法は以下。
1. /etc/mongodb-mms/monitoring-agent-
|sh| $ /etc/init.d/mongodb-mms-monitoring-agent start
||<
Upgradeでrpm上書きしたら消えそうだけどね(´・ω・`)
歌舞伎座.tech#3「Real World Erlang/OTP」memo
メモです。}
なぜErlangにしたのか? by 太田@dwango
- サーバ(プロセス)を自由に組み合わせ可能
- 設計の自由度が高まる
Voyage GroupでのErlang/OTP(仮) by ajiyoshi@VOYAGE GROUP
インターネット広告にErlang
- とくにRTBに使ってる
Bidリクエスト
重要な要件
- 複数のネットワークコネクション
- 非同期IO or マルチスレッド
- ソフトリアルタイム性 - 何が何でも早めに返す
- 100ms程度の応答(厳密でない)
多言語との比較
- node.jsなどのシングルスレッド+非同期IO - event-driven
- 低オーバーヘッド
- 扱いやすい
- シングルスレッドなのでマルチコア環境では一工夫いる
- ノンプリエンティブ
- コールバック地獄かも
- JVMでマルチスレッド
- 早い
- マルチコア環境でもスケール
- full GCがちょっとこわい
- 1connection/threadは無理そう
- ソフトリアルタイムに書くのが難しそう
- Erlang, golang
- 1connection/process
- ソフトリアルタイム性確保が簡単
- ProcessごとのGC
アーキテクチャ
- Erlangによるhttp APIサーバとして設計
- 内部向けI/Fにhttpなのはトレードオフあり
- 外部向けhttpレスポンスに比べりゃ小さい
- 1conc/proc
- 生存次回の短いprocess
- messageのタイムアウトでソフトリアルタイム性
実測値
- 3万bits/s
- 16億bits/day
- 8000万 RTB imp/day
運用
- Jenkinsでビルド&rebar generate
- 100G/dayのログをHiveで解析し、最低入札価格の最適化
- Growth Forecastでかんたんに可視化
Elixir (仮) by mururururu@VOYAGE GROUP
Elixirなにがすごいの
Erlang vs Elixir
- meta-programming - Everything is a expression
- Embedded database
- Define modules on shell
- macros <- Elixirは構文木
- ErlangのmacrosはC-like
- protocols
- standard libraryが整備されている
- Eralngに比べてオーバーヘッドはとくにない
時雨堂とErlang/OTP事例紹介 by voluntas@時雨堂
- ピザ食ってました…
- オーム社のヒコーキ本
メモ - 第2回 MariaDB/MySQL コミュニティ イベント in Tokyo at DeNA
中盤2セッションだけメモりました。本当にメモです。
MySQL to MariaDB Migration - SkySQL Colin
- Googleの話
- Wikipediaの話
- Tumblr
- Jetpants - tool of re-sharding, scale writes, eliminate SPoF
- multi-source replication, MariaDB 10.0
- Jetpants - tool of re-sharding, scale writes, eliminate SPoF
- SpamExperts
- Web of Trust
- over 114m user
- MySQL5.0 -> MySQL5.1 これはいくつかの問題、バグが有る
- TokuDB integration
- performance, crash revocery, hot schema changes, indexing <- オンライン変更
- Limelight Networks (CDS)
- Kakao Talk
- Fusiion-IO fixes
- Demo済
- Fusion-IO atomic writes make Fusion-IO use MariaDB for all their demos
- LuxBet (part of TabCorp,Australia)
- Demo済
- WiredTree (& Other web hosts)
- SlashGear
- OLX
- 40m page views/day
- information_schema enhancements for user statistics, virtual columns exist
- 80% performance gain
- Safe in finance
- SkySQL helps migrations!
- That's not the only migrations
- NoSQL -> SassandraSE on MariaDB/ RocksDB (LevelDB - key-value) exists(HBase)
- Problems with 5.6
- GTID requires a complete restart of your topology!
- PERFORMANCE_SCHEMA overheads
- Single threaded slowdowns
- Semi-sync, group commits, requires enhancement
- See: 356 commits (fixes, features) in FB tree
- See: 68 bugs fixed in Percona Server 5.6 (not in MySQL5.6)
- See: 1991 bugs fixed in 5.6, 3763 bugs fixed since 5.5 GA
- http://mariadb.org/
- Galera Cluster
- 12社程度移行実績
- MariaDB 10.0 - 10.1くらい?
- 使用したらfeedbackほしいってよ
- Slideアップされてるって言ってた気がするんですが、どなたかご存じないですか。。。
HandlerSocket 2.0 - DeNA Higuchi
- MySQL/MariaDBの「非SQL」フロントエンド
- DBキャッシュサーバの回避
- 予測可能で安定した性能
- パフォーマンス起因のシステム障害を防ぐ
- 同時接続数や通信料などのネックを回避し、システム全体のスケーラビリティを確保
- MariaDB 5.3以降に含まれている
- 各言語クライアントライブラリあり
- プロトコルが単純
- バイナリログにも対応 (row-based)
- レプリケーションOK
- HandlerSocketのときはthread-poolはoffのほうがいいかも
- sleepしうる処理はone-thread-per-connectionsのほうが向いている (Lockとったり)
- HANDLERクエリ
- 参照クエリのみサポート
- Prepared Statementは少しパフォーマンス上がるよ
- HandlerSocket Requestのpipelining
- ver2.0
- クエリ解釈ロジックを外部モジュールで定義できるようになる
- 外部モジュールはサービス停止なしで更新可能
- ねらい
- Stored Procedureの置き換え
- ver2.0でもできないこと
- 自動コミットを抑制できない
- rollbackはできない
- つかいどころ
- 基本参照だけどチョビっと更新あるからキャッシュしたくないあたり
- Userデータとか?Masterデータはクライアントで持っておけばおk。
- Slave側にHandlerSocket、Masterは通常のMySQLDriver-lib
- 基本参照だけどチョビっと更新あるからキャッシュしたくないあたり
MySQL5.6でクッソ遅くなるSQL実行しました
MySQL5.6.3から、FROM句サブクエリにおける一時テーブルで、インデックスが作成されると聞いたので、テストしてみた。
MySQL :: MySQL 5.6 Reference Manual :: 8.13.16.3 Optimizing Subqueries in the FROM Clause (Derived Tables)
比較対象はMySQL5.5.32とMySQL5.6.12です。
SELECT * FROM (SELECT * FROM test_tbl) y WHERE col3=3;
正直こんなSQL発行するなっていう文ですが。
対象テーブルtest_tblはこんなかんじ。
CREATE TABLE `test_tbl` ( `col1` int(11) NOT NULL AUTO_INCREMENT, `col2` varchar(10) DEFAULT NULL, `col3` int(11) DEFAULT NULL, `col4` int(11) DEFAULT NULL, PRIMARY KEY (`col1`), KEY `test_idx` (`col3`,`col2`) ) ENGINE=InnoDB AUTO_INCREMENT=5636010 DEFAULT CHARSET=utf8 INSERT INTO test_tbl(col2, col3, col4) values('abc',1,1); # 3,145,728 rows INSERT INTO test_tbl(col2, col3, col4) values('abc',2,1); # 2,097,152 rows INSERT INTO test_tbl(col2, col3, col4) values('abcde',2,1); # 4 rows INSERT INTO test_tbl(col2, col3, col4) values('abcde',3,1); # 10 rows
実行結果
MySQL5.5.32 | MySQL5.6.12 | |
---|---|---|
SELECT * FROM (SELECT * FROM test_tbl) y WHERE col3=3; tmp_table_size=64M |
4.43 sec | 86.38 sec |
SELECT * FROM (SELECT * FROM test_tbl) y WHERE col3=3; tmp_table_size=1G |
3.86 sec | 11.84 sec |
SELECT * FROM test_tbl; tmp_table_size=64M |
4.42 sec | 4.44 sec |
MySQL5.6クッソ遅い(´・ω・`)
原因
まず、先述したとおり、MySQL5.6では一時テーブルにもインデックスが作成されます。
当然、その処理には対象となるインデックスのアクセスや再構築が必要で、
その分の処理時間やサイズ増加によるI/O負荷などがボトルネックかと思われます。
まだ具体的にソースまで追っかけてないので予想ですけども。
あとoptimizer_traceしたらコストがおかしい?
とりあえずLast_query_costは0でした。
こんなSQL最適化しないってか。
他に考えられる原因あれば教えて下さい!
とりあえずここまで。
MySQLで複数バージョンを使い分ける方法
複数バージョンのテストするときに、なるだけミニマルにそれぞれを使い分けたかったのでメモ。
そんなに難しくないです。
ちなみにmysqlenvというMySQL環境管理ツールを作っている方もたくさんいらっしゃいます。
インストールとかを簡単にしたい人はこちらも併せてご確認ください。
https://github.com/xaicron/mysqlenv
https://github.com/shim0mura/mysqlenv
MySQL Download
from http://dev.mysql.com/downloads/mysql/
$ wget http://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.12-linux-glibc2.5-x86_64.tar.gz/from/http://cdn.mysql.com/ $ tar zxvf mysql-5.6.12-linux-glibc2.5-x86_64.tar.gz $ mv mysql-5.6.12-linux-glibc2.5-x86_64 mysql-5.6.12 $ cd mysql-5.6.12
私はだいたいLinux - Generic (glibc 2.5) (x86, 64-bit), Compressed TAR Archive使ってます。
コンパイルするのめんどいから(´・ω・`)
my.cnf
$ cp ./support-file/my-default.cnf ./my.cnf $ vim my.cnf
port = 5612 user = mysql basedir = /path/to/mysql-5.6.12 datadir = /path/to/mysql-5.6.12/data tmpdir = /path/to/mysql-5.6.12/tmp socket = /path/to/mysql-5.6.12/tmp/mysql.sock pid-file = /path/to/mysql-5.6.12/logs/mysqld.pid log-error = /path/to/mysql-5.6.12/logs/mysqld
まぁ、パスを自分のディレクトリ配下にしちゃいましょう。
この場合、tmpとlogsも作っちゃってます。
んで、ポートとソケットを指定します。
これらを通じてクライアント・サーバ通信が行われます。
つまりこれらがそれぞれのバーションでかぶってなければ、同時起動してもいけると。
あとのmy.cnfはお好みで。
mysqld_safe
$ /path/to/mysql-5.6.12/bin/mysqld_safe \ --default-file=/path/to/mysql-5.6.12/my.cnf &
-
- default-fileオプションでmy.cnfの場所を指定します。
これがないと/etc/my.cnfを読み込んじゃうようです。
さらにはこのオプションは他のオプションよりも前、つまり先頭にないと機能しないらしいですね。
他のオプションつけるときは注意。
まぁ、my.cnfの中でひと通り指定しちゃえば、こんなけでおk。
サイト制作備考録
気をつけること
基本html5マークアップ
どんどん追記予定
- htmlのlang
<html lang="ja">
- モバイルサイトに飛ばすときは以下のコード
var agent = navigator.userAgent; if(agent.indexOf('Android') != -1 || agent.indexOf('iPhone') != -1 || agent.indexOf('iPod') != -1|| agent.indexOf('iPad') != -1){ location.href = './sp/'; }
- スマホ用に以下のコード
<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1, maximum-scale=1"> <meta name="format-detection" content="telephone=no"> <meta name="apple-mobile-web-app-capable"> <meta name="apple-mobile-web-app-status-bar-style" content="black">
- stylesheetにnomalize.css(好み)
http://necolas.github.com/normalize.css/
- LESS使うときは以下のコード http://lesscss.org/
<link rel="stylesheet/less" type="text/css" href="styles.less"> <script src="less.js" type="text/javascript"></script>
- jQueryはこちら
<!--[if lt IE 9]> <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script> <![endif]-->
- OPGに対応
http://ogp.me/
別記事予定