Auroraクラスタのレプリケーションクラスタを作成 | 外道父の匠
とあるAuroraクラスタの、完全なデータコピーかつ最新データも元クラスタからレプリケーションで反映し続けるクラスタって作れるのかなーと調べてみると、公式のユーザーガイドにも一般情報にも見つからないしで、裏技臭がしたので書き留めておきます。 実はわりと常識レベルだったりしたらゴメンナサイって感じですが・・・おそらく仕様変更など入らず、ずっと使い続けられるテクニックだと推測できる内容であります。それでは、Auroraクラスタの完全コピーを作りたくなった理由も含めて、まとめていきたいと思います。 Auroraの基本的なレプリケーション Auroraの復習ですが、Writer(=Master) と Reader(≒Slave) は共通のディスクを利用することで、極小さな遅延（10-20ms）でのデータ共通化を実現しています。なので、Writer/Reader間は従来のbinlogを用いたMySQ
IT企業の勤務時間帯と子育てについて | 外道父の匠
私は、それまで 9:30-18:30 だった勤務時間を、４月から 8:30-17:30 に変更しました。理由は単純で、息子の為なのですが、この１ヶ月間で感じたことでもツラツラと書いてみます。 最近のIT企業では、フレックス制だの、午後から出勤だの色々ありますが、その辺の事情も気になったのでついでに軽く調べつつ、現状の見直しでもしてみようかなと思った次第です。 私の育児事情 私の家庭はいわゆる共働きなのですが、家事育児の99％は私が稼働することで成立しています。ゼロ歳の生まれたての頃から、夜な夜な三時間おきに起床してミルクをあげつつ、通常通り業務をこなしていました。と言えば、わかる人には大体わかってもらえるでしょう。 稼働率を50/50に近づけたいという希望は一瞬ありましたが、人間、得手不得手がありますし、ストレスを一切溜めずに家事・育児・教育、全てこなせてしまう私がやってしまうことが、ベス
EC2拡張ネットワーキングの性能と設定手順 | 外道父の匠
AWS VPC内のLinuxでは、拡張ネットワーキング（Enhanced Networking）という機能が使えます。利用条件はあるものの、この機能を有効にするだけでネットワークが速くなるので有用なのですが、何がどれくらい速くなるのか気になったので計測してみました。 この機能自体は2013年末に発表されたものなので、目新しくはないです。ただ、公式の説明やその辺の情報を調べても、イマイチ情報がわかりやすくまとまっていない部分があったので、設定についてもまとめ直してみました。 デフォルトと拡張ネットワーキングの性能比較 この機能のON/OFFによって、変化するのは通信のレイテンシであり、最大Bandwidthが変わるわけではありません。また、インスタンスタイプによってレイテンシの変化量が変わるわけでもありません。 そのため、ここで載せるのは１つのインスタンスタイプにおいて、バージョン違いを含め
現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
エンジニアが初めて書籍を執筆するにあたって | 外道父の匠
新年一発目のブログは腰が重いがゆえに、いざ書き出すと長くなる悪い癖──ですが、今年も継続アウトプット頑張っていきます。よろしくお願いします！ ──昨年9月に、書籍『たのしいインフラの歩き方』を発売させていただきましたが、数ヶ月が経って年も変わったので、執筆話の発生からどのような経緯があったのかなどについて、まとめてみます。一冊しか書いていないのでアレかもですが、私のように職業ライターではない、本職がエンジニアの方の初執筆や、会社内における調整などの参考にしていただければと思います。 目次 執筆話の発生 会社との調整 執筆契約と〆切 著作権 印税 執筆作業 編集 告知 発売後 執筆について 執筆話の発生 初動 ブログに設置してある、問い合わせフォームからメールがきました。技術評論社の編集者と名乗る方から、ITインフラについての書籍を執筆してみませんか、という内容です。 メールの『執筆』という
Amazon Auroraを真に理解するための性能検証 | 外道父の匠
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較 | 外道父の匠
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
MySQL + ioDrive + XFSにおけるbinlogローテート問題 | 外道父の匠
前回の問題とはまた別件で、今度はbinlogのローテート切り替わりタイミングに更新クエリが停滞する、という問題を調べることになりました。 調査の過程で何を誤ったか、Twitterという魔法陣から最強クラスの重鎮魔神を召喚してしまい、恐れ多くも原因の特定と対応方針の決定ができてヘコヘコな感じでございます。 binlogローテート時の障害 数十分に１回、更新クエリが停滞してアプリケーションにエラーログが残るということから、他のエンジニアが、どうもbinlogの切り替わり時にそれが起きているっぽいことを特定してくれました。発生時は1～3秒は更新機能が停止するので、結構なレベルの障害ということでした。 binlogは1GBでローテートするように設定していたのですが、dstat -d でwrite容量を見ていると、確かに切り替わり時に800～900MBの書き込みを確認できました。 このことから、bi
Percona Server 5.5にて10秒間隔でDisk I/Oが重くなる問題 | 外道父の匠
久しぶりにDBAとしてお手伝いした時の汚いメモになります。 Percona Server5.5＋ioDriveのMySQLで、イベント時やピークタイムにアプリケーションからのDB利用が重くなる、ということで調査から対応方法まで考えてみました。 問題点の大雑把な特定 高トラフィック時に、RubyからMySQLの接続やクエリがちょこちょこ重くなり、レスポンス速度に影響が出る、とのこと。で調査開始。今回のPercona Serverのバージョンは 5.5.34 でした。 top -d1 で触診してみると、謎の10秒間隔でiowaitが5～10％に上がることを確認 5分平均のiowaitグラフを見ても、ピーク時は50～60％であることを確認。ioDriveでこれはイカン dstat で見ると、平時はwrite数MB/s～十数MB/sのところが、やはり10秒間隔でwrite 数百MBを確認。ピーク時
エンジニアの評価基準とキャリアパスのお話 | 外道父の匠
春になって暖かくなると、ついつい意識が高ぶってしまいますね。 今回はあくまで個人的な、エンジニアの評価基準とキャリアパスについての私見を、どちらかというと新人の方向けに垂れ流してみたいと思います。 はじめに 新人の方々は今頃は、研修に追われていたり、それが終わっても配属先で揉みくちゃにされる日々が待っているでしょう。中には既に後ろ向きな思考になっている人もいるかもしれませんが、そういう人には今回どうでもよい話で、前向きな人がそのエネルギーをエンジニアとしての成長に無駄なくつぎ込むために、若いうちにあまり考えないけど、考えておいた方がよい話をします。 ITエンジニアとして始動すると、目の前に与えられた仕事だけでも楽しいのに（その過程で苦しむのは別として）、さらにその先にIT知識が広く深く待ち受けていて、こんなことをやりたいんだ、全部マスターしてやるんだと意気込むかもしれません。そして、目の前
サービス品質の改善効率を高める仕組み | 外道父の匠
最近うぇぶ業界では、開発効率や構築効率を求める動きが活発のように見受けられますが、ここで改善効率について手を伸ばしてみましょう。 改善効率とは、開発後期やサービス開始後の運用フェーズにおいて、クソコードやクソクエリ、データの蓄積によるレスポンスの悪化などを、自動的に検知し、開発者にオラオラ改修をプッシュするための仕組みのことでございます。 はじめに ここで紹介する内容はドリコムで実際に運用しているものですが、別にドヤ顔するようなものではなく、中規模以上の企業ならば似たようなことやそれ以上のことをやっているであろう、至極当然な内容です。それでも、それなりに種類が増えてきたことと、それなりの効果を得られていることが実感できているため、いったんまとめてみようと思った次第です。 ウチのサービスのサーバーサイドは Ruby on Rails + MySQL が基本なので、その対策手法になります。WE
エンジニアの成長と反抗期 | 外道父の匠
最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う？ と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会食にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3～5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥／改悪サービスに
sshguardでブルートフォースアタック対策 | 外道父の匠
sshdログとiptablesを用いて、SSHのブルートフォースアタック（総当たり攻撃）から守る sshguard を試す機会があったのでメモっておきます。 ぶっちゃけ、お外からSSHで繋げるサーバとかほぼ皆無だし、鍵認証だしで、実際に活躍することなどないのですが・・・開ける必要があったり、ミスって開いちゃってたりした時に、iptables でがっちりカットできるので使いドコロはまぁまぁあるかもしれません。 OSとsshguardのバージョンについて ここでの構築は、Debian Wheezyで行っています。 Wheezyのパッケージは、ちゃんと設定ファイルとデーモンになっていてナイスです。 SqueezeやLenny、CentOS5 などもパッケージはあるのですが、内容は /usr/sbin/sshguard が入っているだけのクソパッケージです。その理由がおそらく、sshguard の
Percona XtraBackupの実践スクリプト | 外道父の匠
これまでちょこちょことXtraBackupについて紹介してきましたが、MyISAMなども一緒に取得する必要があるため結局利用するのはinnobackupexになります。で、そのinnobackupexをどう使うかという説明はすっ飛ばして、実際にどのような方法でバックアップ／リストアしているかを紹介したいと思います。 が、要は私が書いて実際に利用しているスクリプトを公開するだけの質素な内容になります。 はじめにおことわり 変更した場合はブログやスクリプト内コメントにも書くつもりですが、gistに上げるのでその辺はよしなに 具体的な使い方、処理内容はスクリプト内に書いてあるのでそちらを参照してください 動作確認は、DebianとCentOSで行っています 概要 バージョンについて XtraBackupのバージョンは2系の最新を利用してください。 結構頻繁にバグフィックスされているので、こまめに
ドリコムのソフトウェア選択のお話 | 外道父の匠
mixiのサーバOS移行のお話 – mixi Engineers’ Blog とその続編に触発されて、私の寄生先であるドリコムではどのように考え、何を選択してきたのか振り返ってみたいと思います。 こういう情報の公開は、確かにしないに越したことがない類のものかもしれませんが、年末ですし、当たり障りのない範囲で思い出エントリで締めくくろうかなと思い立った次第であります。 OSの選択を振り返る 2001年あたりから覚えている範囲でザッと振り返ると、 RedHat 7-9 FedoraCore 1-3 Debian 3-6 CentOS 4-6 という感じで、現在はDebian(5/6)とCentOS(5/6)を主流で利用しています。あとはたまにBtoB案件とかでWindowsServerやRHELもちょこちょこありましたが、今はないですね。 こういう選択をしていった理由は、 まずRedHat～F
キャパシティプランニング 発表資料 | 外道父の匠
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
これからはじめるインフラエンジニア 発表資料 | 外道父の匠
新卒採用のイベントで『知的ヘンタイ六番勝負』というのをやっていまして、その『第三戦 大規模インフラ・解析勉強会』にてインフラについて話してよ、と人事オファーをいただきまして発表した次第でございます。 エンジニア志望とはいえ、不特定多数の人間に対してインフラの話と一口で言われても、誰が何をどれくらい理解してるのかわからないので厳しい案件ではありましたが、せっかく来ていただくので真面目に張り切った結果、質疑応答含めて１時間弱に渡る発表＋風邪でノドが潰れた資料がこちらになります。 補足 新卒の方々に向けて これまで新卒の人に関わる機会がなく、インフラについてどの程度理解があるのか全くの不明でしたが、思っていたより勉強しているなという感触と、良いエンジニアになれそうな匂いを発している野郎も結構多かったな、という印象でした。 資料でも触れてますが、WEBエンジニアを目指した時に、何を武器に何エンジニ
Percona XtraBackupの抽出と圧縮の並列処理 | 外道父の匠
久々にXtraBackupの話題です。 以前に紹介した基本手順では、tarアーカイブをgzip圧縮していました。 実はこれよりもっと速い方法がありまして、データサイズが大きくなると必須になってくるのではないかと思います。その、計測内容と結果について紹介していきたいと思います。 リンク 本件に関係ありそうなドキュメントのリンクになります。 The xtrabackup Option Reference Streaming and Compressing Backups The xbstream Binary Accelerating with –parallel copy and –compress-threads Making a Compressed Backup (qpress) 本家ブログのベンチマークもあります。 Compression for InnoDB backup – My
Cloudera Impala発表資料 | 外道父の匠
11/26 の『Hadoopソースコードリーディング 第13回』でCloudera Impalaの発表をしてきました。 きっかけはTwitter上で、ビールの化身 も◯す の外道父を呼べば？から始まって、１分かからず依頼ツィートが飛んできて引き受けた感じで、Twitterで数分で全てが完結する非常にフットワークの軽い業界になります。 それでは、発表資料や補足などを書いていきます。 リンク Eventbrite : Hadoopソースコードリーディング 第13回 Twitter #hadoopreading togetter : Hadoopソースコードリーディング 第13回 まとめ Inside Impala Coordinator at HSCR 13th – Go ahead! by @repeatedly Inside Impala -Query Exec Engine- by @o
Fluentd Meetup #2 発表資料 | 外道父の匠
このブログやTwitterをご縁に、Fluentd meetup in Japan #2 で登壇させていただくことになり、張り切って発表してきました。 発表資料はアニメーションを多様していたのでSlideShareだとわかりづらいかもですが、アップロードしましたので御覧くださいませ。 内容の補足 いくつか質問を受けて答えたりTwitterで見た点について、資料の補足をしておきます。 Agent -> Collector通信経路について Q. なぜVPNにしなかったのか A. VPNは可用性／負荷分散性の点で弱いため。また、VPNサーバや他にもGatewayなど余計な経路を通ることになり無駄である。Agentの増加に対してボトルネックができない構成にしたかったため。政治的な理由で、ある環境だけVPNをはれないといった場合もあり、総合するとGlobal＋暗号化 が良い落とし所だった。 圧縮／暗
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
