元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2014/07/11

「MySQL Casual Talks vol.6」に参加してきた&資料まとめ #mysqlcasual


久しぶりにMySQLガチュアルカジュアルに参加してきたので、そんなログと資料をまとめておこうと思います。


尚、このイベントの過去の参加記録は以下。

vol.4がエア参加で、vol.5・・・っていつやったの。。。な感じで久しぶりに参加させていただきました。


TokuDB試してみる (@yoku0825)


TokuDB、InnoDBの3倍くらい圧縮が効くとのことで、レイテンシが多少上がっても、容量がほしいときは良さそう。(InnoDBに比べて、場合によってはメモリにのりやすい)


MySQLゆるふわ運用のためのアグレッシブ開発 〜データを増やさないための設計と運用方針について (@songmu)


データをメモリに載せきるために、パーティションを活用するとか、論理削除を避けましょうとか、データを増やさない(型に気をつける)とか、データを効率よく消していくための仕組みとかの話。

# MySQL 5.6 以降でEXCHANGE PARTITIONってのがあるらしいので調べてみよう。


Better Groonga Replication (@Yappo)

Senna+MySQLの運用昔話から、Groonga+MySQLでレプリケーションを実装した話。binlogを入れるテーブルを作るとな。

かぜぶろえもん、一家に一台じゃなくて、一社に一人ほしい。おいくらですか...


N:1 Replication meets MHA (@do_aki)


N:1 レプリケーションの話を聞くと、MySQL Casualに来た感あるなぁ、としみじみ感じましたw


ふつうのWeb開発者のためのクエリチューニング (@kamipo)


明らかにやばそうなクエリシリーズ。MySQLCasualLogでヤバいところが赤くなるヤツよさそう!


続・Amazon RDS Casual Talks (@monry)


カジュアルな雰囲気でいいっすねw


next-key lock (@karupanerura)

ロックの話。いまさら・・・って話でしたが、大変勉強になりました。後半の図解わかりやすい!


MySQL Fabric使いたいんだけどどうなんすか (@dblmkt)


MySQL Fabricは、MySQLサーバ群を管理する統合フレームワークで、スレーブの自動昇格とか、シャーディング・クエリのロードバランスとか、スレーブの複製とかしてくれる。現段階では注意点もあるみたいだけど、かなり期待できそうな雰囲気!

有用記事を翻訳しているYakst(http://yakst.com/ja)もよろしくお願いします、とのこと。


LTしたい (@studio3104)


スロークエリログの解析とツールの話。ちなみに、かぜぶろえもん、再登場の巻。


MHA on AWS+Rails (@sgwr_dts)


クックパッド社のMHA運用の話。MySQL on EC2+VPCな感じで運用されてるとの事。参考になります。



(@RKajiyama氏のコーナー)

  • mysqlreplms
    • 複数のマスタから1台のスレーブに集める的なやつ(さっき聞いた?w)
    • GTIDを使う
    • 切り替え間隔はデフォで60秒、最小30秒

あわせて読みたい


おまけ

イベント会場であったOracle社より1枚。

Oracle社より

2014/07/04

General Purpose(SSD)なEBSボリュームのベンチマーク追試(バースティング終了後の性能)


先日のエントリ「新しいSSDベースのEBSボリューム(General Purpose)のベンチマークをとった」で、最近発表されたAmazon EBSの新しいタイプのボリュームである「General Purpose (SSD)」のベンチマークをとりましたが、このエントリの最後で、

次回予告(宿題)として、バースティングできるクレジットを使い切ったときにどの程度のパフォーマンスになるかを挙げておきますw

新しいSSDベースのEBSボリューム(General Purpose)のベンチマークをとった - 元RX-7乗りの適当な日々

と挙げていたので、続きをやってみたログです。

(General Purpose (SSD)の基礎ベンチマークについては、前回のエントリをご覧ください。)


前提

前回のエントリとほぼ同じ条件で、EBSボリュームのサイズを"50GB"にしてやってみました。

理論値として、Base Performanceは、3 * 50 = 150(IOPS)となります。


結果と考察

ほぼ公表どおりの結果ではありますが、僕がさっきテストしてみた感じだと、、、


  • 最初の30数分間は、前回のエントリに書いたような3000〜5000(IOPS)/1ボリュームのパフォーマンスが出る
  • その後は、シーケンシャル/ランダムアクセスのRead/Writeともに、150IOPS前後でキャップされる
    • 今回のテストでは、50GBのEBSボリュームを使ったので150IOPSは仕様通り
  • 長く負荷をかけ続けていると時折(肌感として数十秒に1回)2〜3秒のレベルで数十IOPS(10〜140の間)に落ちる時もあった
    • ランダムライトで確認、リードは未確認
  • アクセスを止めてしばらく時間を置くと、またバーストクレジットが復活して、3000〜5000(IOPS)のパフォーマンスが既定時間続く

となります。

動きとしては、割と公表されている仕様に従っている挙動になるので、この特性を見極めて使う分には、全然アリな感じでしょう!


ただシーケンシャルアクセスに関しては、多少IOPS値が変動しますが(未保証)、従来タイプ(Magnetic volumes)のEBSボリュームを使うと、1時間ほど負荷をかけ続けましたが、終始2000〜4000IOPS(時折、IOPSが1000台に入ることも)のパフォーマンスでアクセスできていました。

Magneticタイプのボリュームについては、I/Oリクエスト数に応じても課金されるようになっているので、AWS的にもパフォーマンスを出来る限り高める(数多くのI/Oリクエストを捌く)方が、I/Oリクエストに対する従量的な売り上げに繋がるので、これは理に適っています。

なので、ログとか履歴データとかをそれなりに書き続けるとか、シーケンシャルアクセスを高頻度で多用するケースでは、Magneticタイプのボリュームの方が向いているかもしれません。(Provisioned IOPS使えや、という話もあるw)


とはいえ、General Purpose (SD)は容量に対する課金しかないので、価格的に見積もりやすいという点もあるので、選択肢が増えた分、ご利用は計画的にってことですね。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́



まとめ



オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)