【勉強会】Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo
2016−08−31 Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo
これに行けなかった
はてなのログ運用これまでとこれから
ReverseProxy->AppServer->DB
access log error log various logs
はてなのログ運用
アクセスログ
課題->使われなくなっていく * 初期化が遅い * 環境構築が難しい * 定期的に回すとコストが
アプリケーションのログ
- 構造化されたログを出す
- 全サービスで特定のpathにJSONではく
- fluentdで配送
- 各ホストはin_tail＋out_forwardのみ、飛ばすだけ
- 中央のaggregatorがよしなに処理
- 品質はベストエフォート
- S3にも配送、生データを保存で、何かコケてもS3で担保
- mackerelにも配送、レイテンシ、エラーレート、KPI
- Slackにも配送、エラーログ集める、エラー多いとgrep必要
- Elasticsearch＋kibanaで可視化
今後
- syslogからの脱却
- 開発者以外も活用できる仕組み
- 行動ログ基盤
はてなのサーバプロビジョニングについて
Chef運用の課題など
本番環境でのChef適用フロー
- GitHubにchef−repoファイル群をpush/merge
- Jenkinsでtarballに固めてファイルサーバにアップロード
- Chef適用
Chef課題
- 学習コスト、挙動が直感的じゃない
- cookbookの書き方のトレンド整理
- テストが回せていない
全体課題
- CIツールで継続的ビルドしたい
- 作成のみ自動化しても、実行を自動化しないと陳腐化する
- いつの間にか動かなくなる
- 自動化するには、必然的に質の高いテストが必要
MySQL運用とらぶるすとーり〜2
テーブルの行数制限
- binlog破損
アプリケーションエンジニアからみたはてなのインフラの話
- id:kgaさん
はてなにおけるDevとOpsの関わり方のご紹介 * 知りたい情報は基本的になんでも見られる、改善できる * お互いを尊重しつつ、得意分野をカバーしあう体制
- ChefのレシピやSQLは、PullRequest・レビュー
- DBインデックスや負荷など相談できる
- 開発-運用定例会で情報共有、アクセス予測やMackerelグラフ
- Mackerelでサーバ状態を常に可視化
- インフラ情報、作業ログ、システム構成図、全部オープン
- Slackは基本的にパブリック、デプロイのログ、アラートも
東京にいながら仕事のほとんどを京都のエンジニアと一緒にしている私のリモートワークの話
東京・京都に分断されたOpsチームのコミュニケーションツール * Slack * GoogleHangout * 日報
リモートはどうしても暗黙のコミュニケーションが減る 強制的にコミュニケーションする場を設けるべき
チーム構成
- 東京にひとり（チームリーダー）
- 京都に他全員（サービス運用チーム） リモートコミュニケーションが頻繁に発生
リモートワークでの悩み
- 技術についての雑談ができない
- メンバーの現状が分かりづらい
悩み対策
- 気軽にコミュニケーションを行える環境
- 強制的にコミュニケーションする場
事例
Slack
- 挨拶などで、やり取りの閾値を下げる
- やりすぎると話が流れすぎて追えなく
日報
- 今日何をしたか、明日何をするか
- チーム全員が書く
- 状況は把握できるようになる
SlackCall
- 雑談用
Google Hangout
- 週次、1on1MTG
- 最近困っていること、担当サービスのスケジュール
- 聞いた内容はチーム内に共有
セールスエンジニアとして今後身につけていきたい技術
セールスエンジニア（＝Mackerel担当）として身につけたい技術 * サーバ構成はChefで管理 * ServerspecとCircleCIでインフラCI * deppbotで常に最新の状態に * ログはfluentd経由でBigQueryに
www.slideshare.net
