161218 cybozu SRE

サイボウズのSRE
サイボウズ株式会社運用本部サービス運用部 SRE
齊藤倫德

SREとは？
▌Site Reliability Engineer
▌サイトの信頼性を向上させるソフトウェアエンジニア/チーム
▌Googleが提唱して、様々な企業が取り入れている
 日本では以下など：
インフラチーム改め Site Reliability Engineering (SRE) チームになりました -
Mercari Engineering Blog
http://tech.mercari.com/entry/2015/11/18/153421

▌ SRE チームを設立します - Cybozu Inside Out
| サイボウズエンジニアのブログ
▌ http://blog.cybozu.io/entry/2016/09/01/
080000

▌L7〜
・デプロイ
・監視・メトリクス収集
・障害
・インフラツール
・ミドルウェア
・linux kernel
▌L3〜
・ルーティング
・スイッチ
・物理サーバ
・回線
・データセンタ
▌L4〜
・ロードバランス
・https

▌信頼性・可用性の維持向上
▌ログ収集・分析基盤の構築
運用
▌需要予測に基づいて、機材
増強・入替・構築
▌セキュリティの担保
▌緊急警告対応〜
根本対処まで
▌アプリケーションのデプロイ
▌調査依頼など

SREの取り組み1: セッションキャッシュ, yrmcds
▌2013年ごろ：お客様が増えてきた
 MySQLにセッション入れてたけど遅いしIO負荷すごい
 オンメモリ化しよう！
 耐障害性ほしい＆低コストで運用したい
 memcachedはレプリケーションがない
 レプリケーションがあるRedisとかは運用が大変そう
 プロトコル簡単だし作ろう。
 せっかくだからオープンソースにしよう！
 yrmcds 0.9.0 リリース
http://blog.cybozu.io/entry/5436

SREの取り組み2: DoS対策, yrmcds
▌2014年ごろ：お客様がよくキーボードの上に本を落とすよ！
F5だよ！
 同時アクセス数を制限しよう
 作ったyrmcdsでカウントしよう！
 nginx の拡張モジュールを書いて DoS 対策をした
 yrmcds 1.1.1 + libyrmcds 1.2.0 をリリースしました

SREの取り組み3: オープンソース化, golang, cybozu-go
▌最近ではGoを採用していて、Go系のオープンソースも公開
 Go でいい感じのコマンドを作れるツールキットの紹介
http://blog.cybozu.io/entry/cybozu-go-cmd
 Cybozu Go · GitHub
https://github.com/cybozu-go/

SREの取り組み4: データ移行, gosyncd
▌新システムへのデータ移行のやり方の一つ：
 初期同期：バックアップ・スナップショットから新環境にコピー
 差分同期：変更されたファイルを監視して新環境にコピー
▌通常運用負荷に同期負荷が乗るので障害になりやすい
 同期速度で負荷をコントロール
 ファイルキャッシュを汚さない
 gosyncd - 安定して、データ移行を行うためのツール

SREの取り組み5: 透過SOCKSプロキシ
▌NAT -> 透過SOCKSプロキシに切り替え
▌メール周りの障害が少なくなり、調査がぐっとやりやすく！
 SPAMフィルタ問題
 tcp_tw_recycle問題
 NAT をやめて、透過 SOCKS プロキシを導入した
 http://blog.cybozu.io/entry/2016/03/14/130000

SREの取り組み6: LVM Thin Provisioning, リストア
▌バックアップのリストアが遅い！
 毎月の全環境のアップデートリハーサル
 バックアップベリファイ / 障害調査 / リストア依頼
▌リストア時にブロック差分を都度マージしていた
 LVM Thin Provisioningを導入してスナップショットの形
でバックアップしよう！
 スナップショットとり放題
 いつでもすぐ使える
▌全環境リストアは12時間強 -> 30分に！

SREの取り組み7: WalB
▌現在のバックアップ形式：
日次スナップショットからブロックデバイス単位でバイナリ差分を取得
 バックアップ取得負荷がきつい。
▌常に取り続けられるように！書き込まれる都度にバックアップ！
 サイボウズ・ラボの星野・光成が開発して、SREと一緒に導
入
 WalB v1.0 リリース

SREの取り組み8: Zabbix, Datadog
▌サービスインより、メトリクス監視はZabbixで運用
▌現在は自社DCも複数サイト運用し、監視対象は1000台を
越える
 2-3年後にはさらに2倍の規模も見えてくる
▌さすがにZabbixでは辛いので、よりよい監視の導入を検討
 Cloud Monitoring as a Service | Datadog
https://www.datadoghq.com/

SREの取り組み9: artifactory
▌Subversionでの管理 -> JFrog Artifactoryの導入
▌aptやPythonなどのレポジトリとして透過的に扱えるように！
 アーティファクトの管理について、あるいは go-apt-cacher / go-
apt-mirror の紹介
http://blog.cybozu.io/entry/2016/07/19/103000
 Artifactory - Universal Artifact Repository Manager
https://www.jfrog.com/artifactory/

SREの取り組み10:その他
▌presto(hadoop)
 アクセスログの基盤として先行投入
 1日分の集計に13時間 -> 20秒に！
 アプリケーションログ・syslogなどの収集・分析基盤も導入検討中
▌可視化！
 ggplot2でWebサーバのレスポンスタイムをざっくり可視化する方
法
 http://blog.cybozu.io/entry/8039
▌現在Ubuntu 16.04への移行作業中
 upstartからsystemdへ

▌NVMe SSDの導入
 高速化：MySQL / ElasticSearch
▌Graylog
 ネットワークスイッチのログ収集
▌DC運用
 cybozu.com のラック設計
▌AS運用
 131912 CYBOZU JP00137545
https://www.nic.ad.jp/ja/ip/as-numbers.txt
SREの取り組み11:その他

SREチームを作ったわけ
▌サービスイン当初は全員で運用も開発もしていた。
▌規模が大きくなるにつれ、障害対応や調査、特殊な対応など、
優先度の高い割り込みが増加
 集中して開発できない
DevとOpsを分割
→ しばらくはうまくいっていたが…

DevとOpsチームの間で問題が…
▌Opsチームの開発スキルが上がらない！
 最初はOpsメンバーもコードを書いていた
 新メンバーも増えるにつれ、徐々に開発が少なく
▌Devチームの作ったシステムの移行・運用コストが高すぎる！
 ある日のデプロイから突然始まる、計画外の三ヶ月間の
巨大オペレーションプロジェクト…(とても良い機能だけど…)

SREチームに統合！
▌Dev/Opsに分かれるのをやめて、役割を固定しすぎないように。
▌ソフトウェアエンジニアに立ち戻る！

現在の課題
▌アーキテクチャが古くなっている
 サービスイン当初から基本的に変わってない
 ストレージまわりが特にやばい！
 刷新する人手が足りない(>_<)
▌若手の教育
 プログラミング初心者もいるので、底上げが必要

SREでやりたいこと！
▌ログ収集・分析基盤
▌検索基盤
▌デプロイ
▌サービスディスカバリ
▌リソースプール
 アーキテクチャ刷新プロジェクト「Neco」の概要
http://blog.cybozu.io/entry/2016/03/11/080000
▌分散基盤
▌より簡易なオペレーション
▌リソースの統合監視
▌キャパシティプランニング

▌懇親会にも出ますので、お気軽にお声がけください！

161218 cybozu SRE

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie 161218 cybozu SRE

Ähnlich wie 161218 cybozu SRE (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

161218 cybozu SRE

Hinweis der Redaktion