読者です 読者をやめる 読者になる 読者になる

試行錯誤のおと

日々の試行錯誤した結果です。失敗することが多い記録、それだけでっす!

Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo に参加してきました

(最初文で書いてたけど、読みづらかったのでメモに置き換えた〜)

個人的には勉強会に参加したらやっぱり、記事を書くべきだと思ってる。 参加したくても様々な事情で参加できなかった人のためになるし、感想を書くと発表された側、発表を聞いた側のモチベーションにもなると考えてる!

内容と感想

hatena.connpass.com

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 を採用した理由
    • 動作に必要な Python はどのディストリにも大体システム標準で入っている
    • Python で実装されているのでいざとなれば読めばいいし読みやすい
    • べき等性が保証されたコードを書くことができる

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 を調査したことがなかったのでこの手の話は新鮮でとても面白く聞けた。

イベントを開催してくださった皆様、発表者の皆様、ありがとうございました!!