b.l0g.jp

渋谷ではたらくインフラエンジニアのブログ

AWSのEBSボリュームのスナップショットを定期的に取る

コメントなし


小ネタだけど、久しぶりに技術的な内容の記事を書いてみる。最近はこういうのはQiitaに書くのが流行り?

EBSボリュームのスナップショット

インスタンスストレージ(インスタンスに無料で付いてくるローカルストレージ)と比べてEBSを使うことの利点の一つに、スナップショットを取れるというのがある。これはもちろんAWSのコンソールからの操作でも、awscliのようなツールを使ってもできるんだけど、いちいちこれらの操作をやるのは面倒になってくる。そうすると、

  • 自動で定期的にスナップショットを取りたい
  • 古いスナップショットは自動的に消したい
  • 複数のEBSボリュームのスナップショットをまとめて取りたい
  • 全ボリュームのスナップショットを取る必要はなく、一部だけ取っておきたい

みたいな話が出てくる。

そういう時にはもちろんawscliや各言語のSDKを使って自分でこれを実装してもいいのだが、AWS Missing Toolsと言う、AWSに関するちょっと痒いところに手が届くツール集があって、これに含まれるEBSスナップショット取得用のスクリプト ec2-automate-backup.sh を使うと便利。

ec2-automate-backup.shの使い方

拡張子でわかる通り単なるシェルスクリプトで、中ではawscliを駆使して処理を行っている。なので、前提としてawscliがインストールされていて、credentialの設定が終わっている必要がある。awscliのインストール方法については割愛。

awscliの用意が済んだら、リポジトリをクローンしてきてコマンドを叩けばよい。

git clone https://github.com/colinbjohnson/aws-missing-tools.git
cd aws-missing-tools/ec2-automate-backup

コマンドのオプションはREADMEに書いてあるが、イマイチわかりにくい。最低限以下がわかればとりあえずのバックアップは取れる。

  • -s [volumeid|tag] : バックアップ対象のボリュームをボリュームID指定するか、特定のタグが付いているもので指定するかを選択する。tagを選んでおくと、例えば「Backup=true」と付いているボリュームを一括でバックアップする、ということが可能。
  • -v ボリュームID : -s volumeidを指定した場合にボリュームIDを指定する。
  • -t 'タグ名,Values=値' : -s tagを指定した場合にタグ名を指定する。上の例のように「Backup=true」のタグが付いているボリュームをバックアップする場合、-t 'Backup,Values=true'と指定する。ここちょっとわかりにくい。なお、タグはEC2インスタンスではなくEBSボリュームに付ける
  • -r リージョン : リージョン指定。ap-northeast-1とか。
  • -n : タグ指定でスナップショットを取った時、スナップショットのNameタグに、元のボリュームIDを入れる
  • -k 日数 : 指定した日数以上経過したスナップショットは削除可能タグが付けられる
  • -p : -kで指定した日数以上経過したスナップショットを実際に削除する

具体的には、以下のようにコマンドを実行する。これは「Backup=trueタグが付いたボリュームのスナップショットを作成し、7日以上経過したスナップショットを削除する」例。

bash ec2-automate-backup.sh -s tag -t 'Backup,Values=true' -r ap-northeast-1 -n -k 7 -p

実際の挙動的には、-k 7オプションがあるので7日経つとスナップショットにPurgeAllow=trueタグが付けられ、次の実行で-pオプションが効いてPurgeAllow=trueがついているスナップショットが消される、という流れになる。

これをcrontabに書いておくなりJenkinsで定期実行するなりしておけば、うっかりファイルを消してしまったとか、データベースがぶっ壊れたみたいな時にもサクッと戻せて幸せになれる。


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

10月 19th, 2015 at 1:33 pm

カテゴリ AWS

Twitterボットを作るのがひそかな趣味

コメントなし


 

プログラミングの勉強にと思ってTwitterボットを作ってみたら、ことあるごとに「あっ、これもボットになってたら便利そう」と思うようになってしまって、さらにいくつか作るという流れ。それなりに便利なのができると、ほっといてもフォロワーが増えていくのが楽しくなってしまう。今まで作ったボットのまとめ。

深田久弥bot  @fukadakyuya_bot

TLでフォロワーのみなさまと盛り上がったのがきっかけで、初めて作ったTwitterボット。ボットをフォローしているユーザが深田久弥の著書「日本百名山 (新潮文庫)」に含まれる山名を含んだつぶやきをすると、同書の中からその山の特徴などを表した部分をリプライする。また、1日1回7:00にはランダムに抜粋をつぶやく。

最初はPHPで書いたのだがいつの間にかうまく動かなくなったりして、Rubyで書き換えた。ソースコードはGithubに上げてある。作った頃はRubyのエコシステムが良く分かってなくて、bundler使わずにやってたりして、自分でもどうやって動いてるのか理解してなかったなあw リプライする山名にどういう傾向があるのか気になったので、山名ごとにリプライ数を集計する仕組みも作ってみた。基本的に富士山がダントツに多いのだが、例えば最近だと吾妻山や蔵王山(火山活動活発化)、立山(アルペンルート開通)といったように、急にリプライ数が増えた山があると、大体そこでは何かあったということが分かって面白い。

山の天気 @yamatenki

毎朝7:30前後に、その週末に天気がいい(登山日和になりそうな)山を地域ごとにツイートする。 土曜と日曜それぞれ分けて判断するようになっている。祝日などの連休にも対応させたいが、めんどくさそうなので先送りしてしまっている。

山名を含んだメンションを送ると、少し詳しい天気予報をリプライしてくれる。

こちらも最初はPHPで作ったが今はRuby製。天気が一覧で見れるページも定期的に生成している。 深田久弥botと違ってうざくない作りなのもあってか、フォロワーが4600以上(2015年5月)もいて、自分の作ったボットの中では一番多い。

hatebu english @hatebu_e

はてなブックマークが一定数以上付いた日本語以外の(正確には、タイトルと本文に全角文字を含まない)記事をツイートする。Yakstという主に英語のブログ記事などを翻訳して公開するサイトを解説しているのだが、そのネタ探しの足しになるかと思って作った。

誰得なのかよく分からないボットなので、フォロワーは少ないw

AWS障害情報(全リージョン) @awsstatusjp_all

AWS障害情報(東京リージョン) @awsstatusjp

仕事でAWSを本格的に使い始めたので、手軽にAWSのステータス情報を知れる手段がないかと思ったのだが、いい感じのボットがなかったので作った。時刻を日本時間に直し、定型的な文言はなるべく日本語に翻訳するようにしている。GCPとかのボットもなければ作ってみようかな。

ちなみに、プロジェクトでHipchatやSlackなどのチャットツールを使っている場合、それぞれのTwitter連携機能を使ってこのボットのツイートを拾うようにすれば、AWSの障害情報が流れてくるようになって便利。

ボットを作ると、プログラミングの基礎もだが、Twitter APIやスクレイピングのテクニックなど、作るボットに応じて色々な技術が必要とされるので、新しい言語を覚える人とか、そもそもプログラミング初心者にはもってこいの課題になる。オススメです。


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

5月 22nd, 2015 at 1:26 pm

カテゴリ 雑記

「SQLパフォーマンス詳解」という本を翻訳しました

コメントなし


 

sqlperformanceexplainedja題の通り、「SQLパフォーマンス詳解」(原文タイトルSQL Performance Explained)という本を翻訳しました。PDFは既に上記サイトから購入できるようになっていて、印刷されたものは夏以降に提供予定です。

リレーショナルデータベースにおいて、SQLとインデックスがどのように関連し、どのようにすればSQLのパフォーマンスを良くできるのかを解説した本です。特定のデータベース製品に焦点を当てた本は多数ありますが、この本ではOracle Database、PostgreSQL、MySQL、SQL Serverの4つのメジャーなリレーショナルデータベース製品を同時に扱っていて、それぞれのクセや特徴も分かるように書かれている点が非常にユニークになっています。また、ORMが生成するSQL文の違いなどにも言及されています。

前書きにもあるように、データへのアクセスパスを知っているのは他ならぬ開発者なので、開発者自身がSQLとインデックスについての知識を深めなければ本当の高速化はできない、というのが著者の考えのようですが、もちろんアプリ開発者だけでなくインフラエンジニア、データベースエンジニアの方々にもおすすめできる内容だと思います。

目次とそれぞれの内容は以下の通りです。

  • 第1章 インデックスの内部構造
    • インデックスとはそもそも何か、インデックスはどのような仕組みか
  • 第2章 where句
    • where句とインデックスの関連、例えば=を使った場合、likeを使った場合など演算子の違いによるインデックスの活用方法など
  • 第3章 パフォーマンスとスケーラビリティ
    • インデックスの作り方の違いによるパフォーマンスとスケーラビリティの違い
  • 第4章 結合処理
    • 結合(join)とインデックスの関連
  • 第5章 データのクラスタリング
    • データのクラスタリング(HAクラスタなどではなく、いわゆるクラスタリングインデックスのこと)
  • 第6章 ソートとグルーピング
    • ソート(order by)やグルーピング(group by)とインデックスの関連
  • 第7章 部分結果
    • MySQLで言うlimitやPostgreSQLのfetch firstのような、結果の一部分を取得するSQL文とインデックスの関連
  • 第8章 データの変更
    • update, insert, deleteといった更新処理とインデックスの関連
  • 付録A 実行計画
    • 各データベース製品での実行計画の表示方法とその読み方

既にご存知の方もいるかもしれませんが、Use The Index, Lukeという名でほぼ全文がWeb上で公開されています。とはいえWeb上で通しで読むのはかなり辛いですし、PDFあるいは印刷版を購入いただければ、作者・訳者とも嬉しい限りです。

私は、Yakstというサイトで海外のブログ記事などを翻訳して公開するというのをやっているのですが、原著者(Markus Winandさん)が書かれたブログ記事を翻訳させてもらったのがきっかけで、この本の翻訳をやることになりました。オンライン販売だけの予定なので書店に本が並ぶわけではないとは言え、自分が訳した本が人に読まれることになるというのは、不思議な感覚です。Markusさんはオーストリア人で英語のネイティブスピーカーではないこともあり、原文は非常に分かりやすい英語で書かれているのですが、それでも翻訳の難しさ、自分の未熟さをひしひしと感じました。素晴らしい本を書いてくださった原著者のMarkusさん、私のつたない訳を丁寧にレビューしてくださった@matsuuさん、ありがとうございました!

訳の問題など、ご意見ご感想ありましたら@dblmktまでいつでもご連絡ください。

ちなみに、海外の有益な技術系ブログを翻訳して公開しているYakstで、翻訳を一緒にやっていただける仲間も募集しておりますので、良かったらそちらも是非よろしくお願いします。


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

4月 7th, 2015 at 8:45 am

カテゴリ 未分類

MySQL Casual Talks Vol. 7まとめ

コメントなし


ふう、MySQL Casual Talks Vol. 7行って参りました。前回は自分が発表者でもあったので、正直なところ他の人の発表を聞く余裕はなく(汗) 今回は、同僚の発表もあったので楽しみにしていったら、相変わらずの濃ゆい話が盛りだくさんで、非常に楽しめました。毎度の事ながら、@myfinderさん始め、会場提供・準備していただいたLINE
のみなさま、Oracleのみなさまに感謝です。

yoku0825さん MySQL Fabricつらい

MySQL Fabricつらい from yoku0825
  • GAから半年なのに誰も使ってない
  • アメリカのイベントでは、MySQL Fabricだけに布がプレゼントされた(白目
  • Fabric対応コネクタが各種言語向けに用意されてる
  • yokuさん謹製fabric対応mysqlクライアント
    • fabricとConnector/C経由で通信する
    • ro(スレーブ、分散される)とrw(マスタ、当然1台)のモードがある
    • マスタを落とすとちゃんと切り替わりますよ(デモ)

tatsuruさん MySQL on EC2

  • 3年ぐらい運用、結構消耗
  • MHA組んでおく
    • ENIをつけておいて、マスタ切り替えはそれを付け替える
  • Mackerelでモニタリング
  • バックアップスレーブでsnapshotとってる
  • スレーブ作る
    • snapshotから作る
    • dumpから作る
    • 落ちたら捨てる前提(信頼性落とす、ダウンしたら捨てる)
  • 取りあえず2セット作って入れ替える、が可能なのがよい
  • スレーブのオートスケールは結構難しい
    • warmup難しい
    • 5.7はできそう(buffer poolリストア)
  • データはEBSに置いている
    • IOできなくなって死ぬことがある
    • ヘルスチェック工夫しよう
  • RDSはちょっと高いけど楽
    • フェイルオーバーが長い
    • 可用性がちょっと微妙でやめた(2012年ぐらいの話なので古いかも)
  • ELBはDNSベースなのでちょっとってことでhaproxyで分散している
  • もはや自前でMySQL運用する時代じゃないよね

ヤフー三谷さん @mita2 Percona Live行ってきた

  • Oracle(200セット), MySQL/Percona(300セット)を運用中
    • Exadataとかも
  • Percona Live 10月にロンドンで開催されたのに参加してきた
  • XtraDB Cluster
    • ActiveActiveの構成、高い冗長性
    • ヨーロッパでは広く普及
    • OpenStackのバックエンドに使われている
    • 本家のGroup Replicationと似てる
    • どのノードに書いても同期レプリされる
    • MySQL Clusterよりは本家MySQLに近くてハードル低い
    • Writeのスケールはできない(MySQL Cluster使おう)
    • SST(丸ごとコピー)、IST(差分)でDonorからデータを送る
    • ノードへの分散はHAProxyとか使う
    • ヘルスチェックの仕組みもXtraDB型に準備されてる
    • 書き込みは楽観的ロック
    • コミットしてノード間の情報が食い違ってるとコミット時にエラー
    • 従って書き込みはできるだけ1台がいい
    • オンラインalterはできない(今後サポート予定)ので、ローリングで変更していく

ペパボ okumuraさん @hfm MySQL 4.0をリプレイスした

MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話 from Takahiro Okumura
  • ブログ記事
  • 2005年 4.0.25 -> 9年 -> 5.0.96にバージョンアップ
  • @tnmt 氏がカジュアルに5.6バージョンアップを指示するイシューを投げたところから始まった
  • しかしやる事になった時は何にも知識ありませんでした
  • たくさんの爆弾が仕込まれていた。。
    • マスタとスレーブの食い違いなどなど
    • ハードもソフトも古い
  • 検証の過程で色んなバージョンをインストールしたので、MySQL-AllStarというbox提供してます(4.0から5.6まで全部入り)
  • 結局5.0まで上げることに
  • 6/20 イベントがあるとレンタルサーバのアクセスが減るからwという理由でメンテ実施
    • ダンプからリストア、切り替えまで同じタイミングでやった
    • insertを実行するとbinlogが壊れることが発覚
    • 失敗として切り戻し
    • 5.0系を特定のgccでコンパイルすると起きるバグ?
    • gccの最適化のレベルによってテストが通ったり通らなかったり
  • その後別のバグ発生
    • rpmbuild中に必要なファイルが消える
    • 邪魔してたパッケージ消してビルド成功
  • 8/22無事バージョンアップ成功
  • 4.0に入っていたデータの一部がリカバリできなかったのは手動で戻した

サイバーエージェント @strsk さん ソーシャルゲームDBの危機回避

  • ブログ記事
  • ギフトとかカードの情報が増えまくる
    • 1日数十GB、論削だけで物理削除してなかったり
    • 削除するのではなく、必要なデータだけをINSERT SELECTで抽出してテーブルを作り直すと速い
    • deleteしてもテーブル容量減らない(MVCCのバージョン管理のため)
    • pt-online-schema-changeでテーブル再構築
  • レプリ遅延
    • truncateすると遅れる(deleteより遅い)
    • バッファプールを大きく使ってると遅くなるというバグ
    • 結局deleteしました

@ryopeko さん Q4M

  • ブログ記事
  • パーフェクトRuby出しました
  • Rubyの人はRedis使う人多い(sidekiqで)けどQ4M
    • shinq
    • ActiveJobを利用
    • Rails 4.2に入る予定のキュー機能

サイバーエージェント @kakerukaeru さん continuous restore

  • ブログ記事
  • DBのバックアップだけじゃなくてリストアも繰り返しやって、復旧可能性を担保
  • バァーン、バァーン、バババァーン

@ijin さん ConsulでMySQLのフェイルオーバー

  • 元ネタのブログ記事
  • consulはraftを使ってcap定理のcpを実現している
  • MHA発動時に実行されるfailover scriptでconsulのAPIを叩いてマスタのDNS名を変更する
  • consul event
    • eventをノードに伝えると伝播される(no guarantee)
    • watchで検知してスクリプトを動かす
  • consul templateを使いましょう

@kazeburo さん isuconのためのMySQLチューニング

ISUCON4 予選問題で(中略)、”my.cnf”に1行だけ足して予選通過ラインを突破するの術 from Masahiro Nagano
  • my.cnfをチューニングする
    • innodb_flush_log_at_trx_commit=2で結構上がる
    • innodb_flush_method=nosync/O_DIRECTでも上がる
    • この2つのオプションさえちゃんとやっておけばおk
    • データ量に応じてinnodb_buffer_pool_sizeも

@neofact さん@kuwa_tw さん NVMFS

NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴 from Akihiro Kuwano
  • ブログ記事
  • 圧縮効いて8〜6割の性能
  • 容量的には半分ぐらいに圧縮できた
  • 圧縮伸長でCPU食う(元々ioDriveではCPUバウンドだけどさらにきつくなる)

@do_aki さん N:1レプリケーション

  • いつもの
  • 特に進捗なし
  • Raspberry piでN:1 replication動きましたw

@kamipo さん ActiveRecord


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

12月 15th, 2014 at 9:11 am

カテゴリ MySQL

日本Chefユーザ会 Meetup メモ

コメントなし


Chef_Vertical_Website_Reg

日本Chefユーザ会なるものがいつの間にかできていたようで、Chef社の人も招いてMeetupが開催されると聞き、参加してきた。

先日発表されたChef 12(参考日本語記事)の簡単な紹介と、Chefのテスト環境に流れを追っての概要とデモがあった。新しい情報はそれほどなかったように思ったが、テストについてのデモ後は質問が活発に出たりしてなかなか面白かったので、メモ公開。

ちなみに、Chefユーザ会のハッシュタグは #getchef_ja だそうなので、日本語のChefに関連するつぶやきはここを見ておくのがよさそう。

Chef 12の紹介 (Michael Ducyさん)

  • 新しくなったchef server
    • 従来1組織しか管理できなかったがmulti tenantサポート
  • chef client
    • chef pushというクライアント側へのプッシュ機能が付く予定
  • Chef development kitがバージョンアップ
    • test-kichenやfoodcriticなどを含む
  • Enterprise版の機能
    • HA
    • replication
      • 複数のchefサーバを立てて同期できる
    • analytics
    • 25ノードまでは有料版の機能を無料で使える
      • さらに30日間はサポートも無料
    • 日本でEnterprise版を使いたければ、まずクリエーションラインさんに問い合わせ

テストについて (Seth Thomasさん)

  • クックブックのテストをする時は、以下のツールを使っていくことが多いよ、という話
  •  test-kitchen
    • chef dev kitの一部
    • 仮想マシンでクックブックをテスト
  • foodcritic
    • chef dev kitの一部
    • chefのお作法に沿った文法かチェック
  • rubocop
    • Rubyのお作法チェック
  • guard
    • ファイルシステム変更確認
    • これでcookbookの変更とかをチェックして、test-kichenやfoodcritic、rubocopとか走らせる
    • 下の質問にもあるが、ローカル環境で動かしておいて、コミット前のテストを自動化するのに使う
  • serverspec
    • クックブックを実行した後に、対象のノードがどうなったかのチェックするのに使う
    • chefspecは、どうなるべきかクックブックで実装できてるかをチェックするツール

質問

  • クラスタがちゃんとセットアップできたかのチェックとかやりたいんだけど
    • chef metalを使えばできる
    • ただしまだベータです
  • serverspecのspecファイルはどこに置くの
    • mysqlだとクックブックのディレクトリのtest/integration以下に置いてる
    • MySQLのクックブックが一番ちゃんとテストしてあって色々な点で参考になる。読むなら一番いい
    • test-kitchenのサンプルとしてもMySQLがいい
  • Windowsで使いにくいんだけど
    • 手順とか公開してます
  • serverspecは全部実行した後にやると思うけどchefspec, test-kitchenとかはどのタイミングでかける?
    • chefspecはlocalで実行する
    • その後test-kitchenで確認する
  • guardはどう使う感じ?
    • 基本はローカルで動かしておいてコミット前のチェックまで自動でやるもの
    • リモートで動かして使うことももちろんできる
  • cookbook内のattributeをserverspecで使いたい時はどうしたらいい?
    • serverspec側を何とかいじってattributeの書いてあるファイルを見るとかする他ない
  • test-kitchenするのにいいのありますか?(EC2だとお金かかっちゃうから)
    • DigitalOceanは(chef社からは)速いよ(ただし西海岸は。DigitalOceanはChefのユーザでもあるし)
    • 速いところを探して使うしかない
    • test-kitchen –parallelを使えば並列実行できて速い
  • kitchen.yamlでnodeの情報にアクセスしたい
    • chef-zeroを使えばいい
    • chef-soloは将来的にdeprecatedになる予定
  • 日本でのchefコミュニティを活性化させるにはどうしたらよいと思うか?
    • ビールが必要(笑)
    • 頻繁に勉強会やmeetupやっていきたい
  • (逆に参加者への質問)女性chef関係者はいないのか?w

10/25の楽天テクノロジーカンファレンスでも、Michealさんが話をするそうで、参加者へのアンケート(?)の結果、Dockerと関連してChefを使う話を予定しているとのこと。

この後、Chef社とクリエーションライン社のおごりで、楽しくビールを飲みながらChefの話をしてお開き。

発表いただいたChef社の方、会場の準備などしていただいたクリエーションラインの方々、ありがとうございました。ビールごちそうさまでした。


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

9月 19th, 2014 at 1:23 pm

カテゴリ Chef

WEB+DB PRESS vol. 79の記事を書きました

コメントなし


cover

同じ会社で働いてる @kuwa_tw さんから紹介いただいて、WEB+DB PRESS vol. 79の記事を書かせていただきました。雑誌に、というか印刷物に自分の書いたものが掲載されるのは初めての経験です。あまり歓迎されないけれども避けては通れない、メンテナンスという切り口で書かせていただいています。

始め、執筆の話をもらった時は、自分の書いた文章が印刷されて世に出るなんて想像もつかない出来事だなあと思っていましたが、実際手元に届いても、これが広く読者の方々に読まれるというのがどういうことなのかよくわかっておりませんw 皆さんからマサカリが飛んできて初めて理解できるものなのかもしれません。ご意見などありましたら @dblmkt までいただけるとうれしいです。

執筆のチャンスをくれた @kuwa_tw さんを始め、不慣れな我々をサポートしてくれた技術評論社の編集者の方、一緒に記事を執筆し色々なアドバイスをくれた同僚達にこの場を借りて感謝を表したいと思います。ありがとうございました!


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

2月 21st, 2014 at 9:00 am

カテゴリ 雑記

CentOS 6になったらTomcatのJVMが仮想メモリを大量に確保するようになった

コメントなし


 

CentOS 5+Tomcat 7+JDK 7+Apacheという組み合わせで動かしていたサーバ群に、OSだけCentOS 6にしてミドルウェアのバージョンは変えないサーバを何台か追加したところ、CentOS 6の方が、Tomcatが確保している仮想メモリ量が圧倒的にでかいことに気づいた。

ちなみに、どちらのサーバもヒープサイズは「-Xmn1024m -Xmx2048m -Xms2048m」となっており、本来なら2GBプラスアルファ(コードキャッシュ他の領域分)しかメモリは食わないはずだ。もちろん、ロードバランサではどちらのサーバにも同じ重みでアクセスを流していおり、負荷は同じのはず。

CentOS 5のサーバ

こちらはざっくり3GB弱の仮想メモリを確保していると出ている(左から5番目、VSZの列)。ヒープサイズから考えるとまあこんなものかというレベル。

# ps auwx
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
31234 10315 110 8.8 3134280 1447956 ? Sl Nov14 6870:09 /usr/local/java/bin/java -Djava.util.logging.config.file=/usr/l cal/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -XX:MaxPermSize=128m -XX:PermSize=128m -XX:SurvivorRatio=2 -Xmn1024m -Xmx2048m -Xms2048m (後略)

CentOS 6のサーバ

一方こちらは10GB弱ものメモリを確保していることになっている。ヒープサイズとの差分9GB近くはどっから出てきたのか?

# ps auwx
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
31234 19463 156 33.6 11270576 2708744 ? Sl Nov14 9532:10 /usr/local/java/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -XX:MaxPermSize=128m -XX:PermSize=128m -XX:SurvivorRatio=2 -Xmn1024m -Xmx2048m -Xms2048m (後略)

CentOS 6の方のサーバのTomcatのプロセスIDを指定してpmapコマンドでメモリの確保状況を見てみると、何やら同じ容量(64MBぐらい)を確保しているanonという行がたくさん表示されているのが目につく。これが悪さしているようだ。ちなみに、一番右の列には通常そのメモリを確保しているファイル名が出るが、anonというのは匿名で割り当てのみがされた領域を示しているようだ。

# pmap -x 19463 | sort -k2 -n
Address Kbytes RSS Dirty Mode Mapping
(略)
00007f08d0218000 63392 0 0 ----- [ anon ]
00007f0878215000 63404 0 0 ----- [ anon ]
00007f099c208000 63456 0 0 ----- [ anon ]
00007f08941fe000 63496 0 0 ----- [ anon ]
00007f09341fb000 63508 0 0 ----- [ anon ]
00007f091c1ea000 63576 0 0 ----- [ anon ]
00007f08901e5000 63596 0 0 ----- [ anon ]
00007f08fc1e3000 63604 0 0 ----- [ anon ]
00007f09c01e0000 63616 0 0 ----- [ anon ]
00007f094c1d8000 63648 0 0 ----- [ anon ]
(略)

調べてみたところ、この現象は、CentOS 6に含まれているglibc 2.11の挙動によるものだそうだ。glibc 2.10から、スレッドごとにメモリ空間を割り当てるような実装に変わったとのこと。なお、CentOS 5ではglibcは2.5。以下、glibcのコミッタUlrich Drepper氏による2.10のchangelog解説からの抜粋。

glibcに対する今回の変更では、スレッドごとにメモリプールを作るようになった。これで多くの場面で間違った割り当てを排除することができる。メタデータは通常1つのスレッド内でしかアクセスしない(スレッドは割り当てられたコアから移動されないのが望ましい)。アドレス空間を吹き飛ばしてしまうようなメモリのハンドリングを防ぐため、メモリプールの使い過ぎに上限が設けられた。デフォルトでは、32ビットマシンではコアあたりメモリプール2つ、64ビットマシンではコアあたりメモリプール8つを生成する。

プールが確保するサイズは64MBであり、上の例のCentOS 6のマシンの場合、CPUは24コアの64ビットマシンなので、「24コア x 8 x 64MB」が仮想メモリとして確保されているため、VSSの列の値が大きくなっていたというわけだ。なお、このプール用のメモリはあくまで割り当てられただけで使用されているわけではない。そのため、実際に使われているメモリはRSS(Resident Set Size)の列に表示されているものである(当然だが)。

Tomcat動かしてて気づいたのでタイトルが「TomcatのJVMが~」となっているが、同じようなつくりのメモリを大きく確保するアプリケーションでは同じことになるのは言わずもがな。

参考1 : Quoraのやりとり「なぜいくつかのアプリケーションはRHEL5と比べてRHEL6では明らかに大きな仮想メモリを使うのか?」

参考2 : IBM developerWorksの記事「Linuxのglibc 2.10以上(RHEL6)のmallocは仮想メモリの使用量を過大に表示するのか」

参考3 : StackOverflowのやりとり「Linux上でのJavaの仮想メモリ使用量が大きすぎる」
解説が非常に詳しくてためになる。

参考4 : 上述glibcコミッタUlrich Drepper氏の記事


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

11月 18th, 2013 at 7:47 pm

カテゴリ Java,Linux

MySQL Casual Talks vol.5 メモ

コメントなし


 

MySQL Casual Talks vol. 5に行ってきたので、自分なりのメモと資料へのリンク。

途中、アラートが鳴り始めて確認してたりしてメモが適当なところがあるが仕方なしw

かなりのスピードでじゃんじゃんプレゼンが進んで行ったが、どれも面白い・役立つ内容ばかりで、楽しいひと時でした。発表者の皆様、会場の提供や調整などしてくださった@myfinderさんはじめとする皆様、ありがとうございました。自分の隣でビール缶を次々と「カシュッ」と空けていた@oranieさんのような余裕を持ちつつ、次回は自分も何かネタを提供できるといいなあ。

@yuryuさん GTIDを使い始めてやめた話

MySQL5.6でGTIDを試してそっと閉じた from Haruka Iwao
  • GTID – 全てのトランザクションを一意に識別、一貫性保証
  • マスタを切り替えると、マスタのUUIDが変わるのでGTIDが2個になる
  • 利点
    • change master to … master_auto_position=1で簡単にレプリをはれる
    • mysql workbenchのmysqlfailoverとか使える
  • 欠点
    • クラスタ全部GTID有効にする必要
    • MyISAM使用不可
    • HAしたいならMHAでいいんじゃね?
  • バグ
    • GTID有効でFLUSH LOGSするとレプリ停止(5.6.11のみ)
    • stop/start slaveするとトランザクションがスキップされる可能性あり
    • ネットワーク切断でトランザクションスキップの可能性
  • 結局、本格的に使うには時期尚早なので辞めました、ということ

@con_mameさん MySQL 5.6移行記

僕らのMySQL5.6移行記(仮) from Yutaka Hoshino
  • クックパッでは5.5のサーバを5.6にバージョンアップしたり最初から使ったり
  • レプリしてクエリ流してコンフィグいじり始めた
    • うまく行ったのは最初だけで問題勃発
  • EBSでスナップショット取ったボリュームを5.6マシンにぶら下げてmysql_upgrade実行
  • Kage
    • リクエストをコピーしてsandbox環境に流す仕組み(ユーザへはproductionからの結果が返る)
    • レスポンスのdiffも取れる
    • バックエンドを5.6にして違いを確認
  • バージョン違い、設定違いのサーバを並べて比較
  • 開発用DBを先に新しくしてリリース前に新環境を試す
  • バグ確認用(最新) → 検証用(1つ前) → 本番用(安定版)
  • 各バージョンが入ったAMIを用意しておいてすぐ起動できるようにしてある
  • GTID有効だとsql_slave_skip_counter使えない
  • AWSだと色んな検証がCasualにできる
  • bugsは見ましょう!
  • 5.6で遅くなるところもあるので、得意な部分から本番投入していっている

@yoshi_kenさん 5.0 Tritonnから5.6 mroongaへの移行

Tritonn (MySQL5.0.87+Senna)からの mroonga (MySQL5.6) 移行体験記 from Kentaro Yoshida
  • 技評の記事の裏話
  • 旧構成 マスタはDRBDでミラー、スレーブにレプリ
  • 5.6スレーブを追加してそこに孫をぶら下げて旧環境を切り離し
  • 本番環境のアクセスログから抜き出したURLを使ってテスト
    • 5.6で遅くなったクエリをチューニング
    • SQLMODE厳格化への対応
  • テスト中に見つけたmroongaのバグはすぐに修正してもらえた
  • HWトラブル
    • マスタ死亡、起動しない、焦げ臭い!さらにもう一台も焦げた。。
  • GTIDよりsemi sync repl + MHAがいいのでわ
  • innodb_file_per_tableでなかったのでダンプしてバージョンアップした
  • memcached APIはバグで使えなかった

@yoku0825さん アプリ担当が出してきたDDLがドイヒーな話

とあるイルカのバーボンハウス from yoku0825
  • すごい心が痛い&共感出来る内容だったけどテンポ早すぎてメモできなかったw
  • MariaDB 10からもGTIDが使えるようになった(ただしMySQLとは結構違う)
  • ログ用テーブル
    • 突っ込みどころたくさんww
  • インデックス名はidx_カラム名_カラム名_…とすると長いけどexplainのときに分かりやすい
  • フレームワークが作る通りではなくDBの特性を考える
  • SQL文を見るだけでどのインデックスを使うかなどの意図が分かる名前付け

@kamipoさん mysql-build

プレゼン資料

  • この辺りトラブル発生してメモがおろそか
  • いろんなMySQLをインストールして使い分ける仕組み
  • percona serverのmysqldumpにはkeyを消してダンプして作り直すオプションがある
    • ダンプが高速化
  • fbの5.6にはlogical key readのオプションがある

@do_akiさん multi master replication

殿堂入りのアレ~Multi-Source Replication を添えて~ from do_aki
  • MySQL Casual定番の内容
  • change masterを2秒ごとに切り替えてマルチマスタ
  • 5.7では標準でできるようになった
  • 過去に色々な方法でマルチマスタを試みている人がいるww

@RKajiyamaさん 5.7 Multi-source replication

MySQL Casual Talks vol.5 – MySQL Labs – @RKajiyama from rkajiyama
  • labsにはDMR以前のものがありますよ
    • hadoop applier for mysql
      • hadoopをMySQLスレーブのように使う
    • JSON UDF
    • Multi source replication
    • MySQL Utilities Fabric
      • シャーディングの情報を管理する仕組み
    • Fabric + multi source replication + multi thread slaveの組み合わせ良さげ

@songmuさん

プレゼン資料

  • GitDDL::Migrator, SQLTranslator(SQLFairy)
    • ブランチごとにテーブルやカラムが違うと大変
    • テーブル構成の違いなどが表示できる
    • ブランチを行ったり来たりしながらalterしたりできる
  • App::RunCron
    • perlのラッパー、レポータを書くと色々できる
    • cronのログってnullに捨てちゃうけど困るよね
    • cronlog
    • cronの処理をラップしてエラー処理が可能

@nekogeruge_987さん DB2からMySQL5.5への移行

  • 13年運用されてるデータベース
  • レコードをCSVにしてload infile
  • シェルスクリプトで自動化
  • 4時間以内に終わらせるという時間制約
    • loadを高速化する工夫
    • ジョブフローの最適化(jenkins build flow plugin)
    • ジョブフローをGroovyで書ける(並列実行などなども可)
    • データ移行自体をCIする(1クリックデータ移行!)
    • /var/lib/mysql以下の並列rsync

@monryさん Amazon RDS

20131025 my sql casual talks vol.5 from Tetsuya Mori
    • マスタ1台、スレーブ5台
        • 243ドル/月
    • 物理サーバが1台13万以上ならRDSの方が安い(3年償却)

@chobi_eさん ストレージエンジンを作ってみた


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

10月 26th, 2013 at 2:06 pm

カテゴリ MySQL

MyNA会2013年9月 メモ

コメントなし


 

MyNA(日本MySQLユーザ会)会 2013年9月

先週のMySQL Cluster Casual Talksに続いて、週末にかけて行われたMySQL Connectで発表された最新情報を聞けるということで、MyNA会に参加してきた。基調講演の内容は既に報道されていたので(Publickey (1), (2), (3))ある程度分かっていたが、一番うれしかったのはMySQL Fabricのデモが見られたこと。MySQL Utilitiesの機能でシャーディングができるようになるということでどんな感じか見てみたかったので、(ラボ版で一部動かないところがまだあるということだったが)興味深かった。発表者のみなさま、会場を提供していただいたOracleのみなさまなど関係者の方々ありがとうございました。

@RKajiyamaさん MySQL Connect基調講演の概要

  • いつOracleはMySQLを殺すのかと言われてきた → うわさを打ち消すために3年半の間大量のリリースをしてきた
  • チーム全体も増員、特に品質管理チーム
  • DMR(Development Milestone Release)というやり方
    • リリース候補版になったコンポーネントを含んだリリース
    • 18から24ヶ月ごとにメジャーリリースしたい
  • Webや組み込み系に強いDBとしてOracleにとっても価値がある
    • 現在もLinux系の最も重要なスキル=MySQL
    • 今もユーザは多数
  • 5.7.2 DMRの発表
    • Release noteが超長かった=たくさんの更新が含まれている
    • InnoDBパフォーマンス向上
    • explain for connectionで別セッションのexplain
    • Optimzerの結果をWorkbenchでさらに詳しく
    • performance schema改善
      • メモリの使用状況
      • storedの詳細
    • tmpテーブルがInnoに
    • 同じDB内でのマルチスレッドレプリケーション
  • 5.7の以後のバージョンでの予定
    • マルチソースレプリケーション
  • MySQL Utilities 1.3
    • レプリケーションのフェイルオーバをデーモンで
  • MySQL Utilities 1.4から
    • Fabric
      • アプリから意識せずにシャーディングできる
      • Connectorが接続を受けて振り分ける
      • レンジかハッシュ、リシャーディング

いちいさん@Gree, いけださん@SCSK MySQL Connectの感想

  • Oracle OpenWorld、JavaOneと一緒にやってる
  • SFのホテルいくつも貸し切り、道路も閉鎖して休憩スペースに
  • FacebookのMySQLの話
  • まつのぶさん MySQL 5.6@Facebook
    • 5.1にパッチ当てたのを使っている
      • 圧縮、クラッシュセーフスレーブ、フラッシングの高速化など
    • シャドウサーバ
    • 5.5を飛ばして5.6へ
      • 低リスクのところから徐々に移行
  • GoogleがMySQLをやめてMariaDBに全面移行するというのは、XLDBというカンファレンスでの話を元にした記者の煽り記事で、Googleの人曰く迷惑しているそうだ

@yyamasaki1さん JSON UDFs

ドキュメントデータベースとして MySQLを使う!? ~MySQL JSON UDF~ from yoyamasaki
  • MySQL json UDFs
  • カラムにJSONをつっこんだものをファンクションで処理できる

@RKajiyamaさん MySQL Fabric

  • ラボ版のMySQL Utilitiesに搭載された新機能
  • マスタにスレーブがぶら下がってる構成
    • これを1つのシャード(グループ)として扱う
  • アプリからConnectorを使ってアクセスする
    • ConnectorはFabricに問い合わせ先を確認してからシャードにアクセス
    • state storeに情報保存
      • スキーマの情報などだけもってデータは持たない
  • グローバルグループ
    • 全体に影響のある処理に関係するメタ情報を持つ
  • アクセス時にRWかROを指定すると、Fabricが自動でマスタあるいはスレーブにアクセスを振る
  • lab版は罠だらけなので気をつけよう。。
  • 開発者の方のブログが役に立つ

赤井さん GNU 30周年とMySQL

  • GNUプロジェクトが始まって30年
  • MySQLの成長はGNUの恩恵を受けた
  • GNUへのリスペクトを忘れないようにしよう

 


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

10月 1st, 2013 at 9:25 am

カテゴリ MySQL

MySQL Cluster Casual Talksメモ

コメントなし


MySQL Cluster Casual Talks

一応仕事でMySQLをよく触っている身として、軽く検証はしてみたものの、担当している業務では参照メインのDBが多いこともあって実運用では使ったことがなかったMySQL Cluster。改めて利点も欠点も聞いておきたいと思ったのと、会社からすぐ近くのGMOさんが会場ということもあって参加してみた。

MySQL Clusterの本も書かれている@nippondanjiこと奥野さんから、MySQL Clusterは何に向いていて、どう使えばよさを引き出せるのかを聞いたうえで、そのサポートを受けながら4年間運用されている@tsakuradaさんの実運用上のハマりどころを聞くことで、どういうところにMySQL Clusterを使えばいいのかイメージが浮かんだので、非常に今後の役に立ちそう。

発表者のみなさま、会場提供していただいたGMOのみなさまありがとうございましたm(__)m さくらのクラウド2万円分クーポンももらったし、GMOクラウドのキャラクタのシールもたくさんもらったので宣伝しますw

既にまとめはgarage-kidさんが書いてくれているので、これは個人的なポイントのまとめ。

@RKajiyamaさん MySQL Cluster大地に立つ!「5.6とは違うのだよ、5.6とは!」

  • MySQL Clusterの概要
    • 分散型、共有ディスク不要のHAクラスタ
  • 使用しているユーザ
    • 元々はモバイル通信の位置情報をリアルタイムかつ高可用性を持って保存するためにできた
    • SQLインタフェースは昨今ゲーム業界などで使われ始めてから追加されてきた機能
    • 艦○れでも使われている?

@nippondanjiさん カジュアルにMySQL Clusterを使ってみよう

カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09 from Mikiya Okuno

データノード、SQLノード、管理ノードの3種類からなる

  • 1台だけならndb(MySQL Clusterのエンジン)よりInnoDBの方が速い
  • ただしNDB APIを使うならClusterの方が圧倒的に速い
  • ノードを増やすとスケールしていく点に優位性があるが、いつでも速くなるとは限らない(後述)
  • 新しいバージョン使いましょう

シェアードナッシング型

  • データノードは2台ペアでノードグループを構成
  • データをフラグメントに分けて、それをノードグループ内で同期レプリする
  • RAID10的な感じでグループ内で1台落ちてもデータは保全される

InnoDBとは特性が違う & いつでもノードを増やせばスケールするとは限らない

  • 主キーを使った検索 → データノード数に応じてスケール
  • (少数の行を取ってくる)スキャンは苦手
    • データがノードに分散しているので複数ノードをスキャンする必要があるため
    • フェッチするレコードが多いと並列処理できるので早くなる
    • Engine Condition Pushdown : where句部分を丸ごとデータノードに渡して並列処理して高速化する仕組み
    • sysbenchをただ走らせると遅いのはこのせい
  • ユーザ定義パーティション
    • スキャンを高速化させる仕組み
    • 2つのテーブルの関連を考慮してデータノードへの分散を定義すれば、読み書きを特定のノードに抑えられるので高速に
  • レプリケーション
    • ndbに不得意な処理があるならInnoDBのスレーブを作るという手もある
    • データノードが書き込みしたことをSQLノードに通知し、それをbinlogに書き込んでスレーブに送るという仕組み
    • 通知を受け取るのがbinlog injector thread
  • インメモリDBだけど永続化処理が多いのでディスク書き込み多い=速いディスクがいい
  • blobを別テーブルに保存するのでJOIN的処理が発生して遅くなる
    • varcharで頑張ろう
  • NoSQLインタフェースを使えば爆速
    • 各種言語のインタフェースあり
    • InnoDBのmemcachedインタフェースよりMySQL Clusterの方が現時点では賢い

まとめ(MySQL Clusterの使いどころ)

  • 大量の更新をさばきたい
  • HA機能が欲しい
  • 高速JOINしたい

@tsakuradaさん MySQL Clusterと丸4年の付き合いを振り返ってのよもやま話と、Version 7.3への期待(もっとユーザが増えるといいな~)

MCCT20130926 tsakuradac from Takeshi Sakurada

使用開始時の期待と使ってみたギャップ、現在の期待

  • インメモリだから速いはず
    • 参照に関していえばFIO+InnoDBでも変わらないかも
  • スケールアウト簡単
    • 構成によってはスケールしないこともあるので要考慮
  • 高可用性
    • 期待通り、フェイルオーバーは数秒で完了
  • ライセンスがGPLでオープンソース
  • 7.3でInnoとの互換性が上がって期待

サーバの構成

  • SQLノードと管理ノードは同居してもよい、データノード2台と合わせて最低4台からが現実的
  • データが多いならデータノードを増やす(が制約はあるので注意)
  • アクセスが多いならSQLノードを増やす。制約は少ないので割と簡単
  • せっかくのMySQL ClusterなんだからHW構成上もSPOFを減らそう
  • クエリがキャンセルされた時それを検出して後続処理をやるアプリ作り込み必須
    • ノード障害時にクエリがキャンセルされるため

InnoDBとの組み合わせ

  • Innoと同じ感覚でテーブル設計してもよいか?
    • 場合による。最近のバージョンではやってみる価値あり
  • InnoDBスレーブとの組み合わせ
    • 分離レベルが違う点は要注意だがおおむね問題なし

ハマりどころ(資料が詳しいのでそちら参照)

  • GCP Stop
  • ローリングリスタート
  • ボトルネックが見えづらい
  • データのライフサイクルを考えよう
  • リストアが大変

4年間でだいぶ地雷を踏んだのでもう大丈夫w 皆さんMySQL Cluster使いましょう

@yyamasaki1さん MySQL Cluster Auto-Installerのデモ

5分で作るMySQL Cluster環境 from yoyamasaki

Auto-Installer簡単なので使いましょう

  • ブラウザベースでぽちぽちやればインストール可能
  • 初期パラメータをいくつかいじった方がいい

@yoku0825さん ウチがNDBCLUSTERを使わない理由をもう一度考える

MySQL Clusterというと紛らわしいので、NDB Clusterと言いましょう


海外の役立つブログ記事などを人力で翻訳して公開するYakstというプロジェクトをやっています。よろしければそちらもどうぞ!

投稿者 doublemarket

9月 27th, 2013 at 9:25 am

カテゴリ MySQL