Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo に参加してきました
(最初文で書いてたけど、読みづらかったのでメモに置き換えた〜)
個人的には勉強会に参加したらやっぱり、記事を書くべきだと思ってる。 参加したくても様々な事情で参加できなかった人のためになるし、感想を書くと発表された側、発表を聞いた側のモチベーションにもなると考えてる!
内容と感想
LT も面白かったけど、メモなしで聞く方を重視したので記事で触れるのは通常のトーク 3 つ。
id: wtatsuru さん: はてなのログ運用のこれまでとこれから
- 前提となるシステム構成
Reverse Proxy -> Application Server -> DB - ログの種類
アクセスログ、エラーログ: Reverse Proxy が書き出し
アプリケーションログ: Application Server が書き出し
ほとんどのサービスで同じような構成をとっているのでログの処理も同じ- アクセスログの運用・分析
フォーマットは LTSV
ログの保存は rsyslog でリモートに転送
ローカルから s3 にも保存して二重化していて、しばらく日が経過したら glacier に保存している
SSD 上のサーバにも転送して、 SSD 上のサーバで分析、レスポンスタイム、レイテンシを計算
発展して EMR 上で分析、 EMR はクラスタの初期化が遅いので今は google big query を検証中(embulk を挟む) - アプリケーションログの運用
構造化ログ(json) の出力、すべてのサービスで特定の場所に出力
fluentd で中央の aggregator に出力、集約の精度はベストエフォート、完全に保証しない
他に s3 に保存、mackerel に転送、 elasticache に転送
- アクセスログの運用・分析
- 今後
syslog からの脱却、開発者以外も活用できる仕組み、行動ログ基盤
rsyslog を廃止する課題を挙げられていたのだけれど、弊社では journald を使ったログ転送の仕組みを試行錯誤していて、この課題の解決には journald のログ転送あるいは自作のログ転送ツールを利用されたりするのかなあと思った。 また、行動ログを取りたいという話をされていて、懇親会で話していると行動ログを取るんだったら時系列 DB を利用しないといけないねという話になった。 時系列 DB は http://druid.io/ というものがでてきていて、いい感じ(?)らしい。
id: hagihala さん: はてなのサーバプロビジョニングの話（仮）
- プロビジョニング
chef, AMI の運用について
今回の話は Configuration, Bootstrapping、 Orchestration の話はない
サーバ環境は最近専用サーバ(さくらさん)、他に DC, Amazon VPC
物理サーバのプロビジョニングは物理層はさくらさん、PXEブート、 Xen domU 上の仮想サーバは EC2 と同じ扱い
ツールは chef、 chef 昔、本よんだくらいで全然わからないのでなかなかついていけない
はてな内部でも動きが抽象的だったりして chef の評判はよくないらしい
問題はたくさんある、テストが回せていない、コードを外部に出せていない
AMI は debian のものを元にすべての元になる AMI を作成している、使っている技術は open-vz, packer
あと Chef を使っていて、問題はたくさんあってテストが回せていない、コードを外部に使えないところなど、プロビジョニングツールあるあるみたいな知見が共有されていてよかった。 懇親会で若手インフラのメンバと話していたのだけれど、プロビジョニングツールを使ってセットアップの設定を書いていると、テストがそれと被るようになってテストを書くモチベーションが下がるというものあるあるらしい。
プロビジョニングするには何か理由があってされているはずなので、プロビジョニングを意識するに至った理由やツールを選択された理由があれば聞きたかった。 最近、実戦的に Ansible を使って一部プロビジョニングをしているのだけれど、仕事で Ansible を導入したのには下記に書くような理由があって、 Chef を導入された理由があるようなら知りたかったなあと思うなど。
- Ansible を採用した理由
id: hagihala さん: MySQL運用とらぶるすとーり〜3
- テーブル行数制限のはなし
The table 'relword' is full のエラーログ
不要なデータを削除して延命
DB は Mysql-4.0.25(?) (Senna, MyISAM)
--with-big-tables が configure に見当たらない
テーブルの最大行数制限に引っかかる
MySQL 4.0 -> 5.1 へのアップデート
はまりどころ共有(Timestamp とか)
4.0 -> 5.0 -> 5.1 のレプリケーション
参照系のみ 5.1 をみるようにして互換を参照 - binlog 破損から救いを求めた話
Master の Disk full
古い binlog を削除するとレプリケーションエラーが発生
mysqlbinlog コマンドで binlog を確認しようとすると binlog が開けない
各 slave の binlog のポジションが同じ
master の binlog が壊れて、壊れた binlog を読もうとして失敗していた
binlog のバイナリを hexdump で読む..バイナリを見ても壊れている
backup のバイナリログポジションを壊れているポジションを飛ばして修正
バイナリログは追記形式なので途中で壊れたとしても後続は壊れない
普段、 RDS しか運用していなくてレプリケーション遅延やログバッファサイズやその他パラメタのパフォーマンスチューニングしか MySQL を調査したことがなかったのでこの手の話は新鮮でとても面白く聞けた。
イベントを開催してくださった皆様、発表者の皆様、ありがとうございました!!
