O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 22 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

Anúncio

Semelhante a 161218 cybozu SRE (20)

Mais recentes (20)

Anúncio

161218 cybozu SRE

  1. 1. サイボウズのSRE サイボウズ株式会社 運用本部 サービス運用部 SRE 齊藤 倫德
  2. 2. SREとは? ▌Site Reliability Engineer ▌サイトの信頼性を向上させるソフトウェアエンジニア/チーム ▌Googleが提唱して、様々な企業が取り入れている  日本では以下など: インフラチーム改め Site Reliability Engineering (SRE) チームになりました - Mercari Engineering Blog http://tech.mercari.com/entry/2015/11/18/153421
  3. 3. サイボウズのSRE ▌ SRE チームを設立します - Cybozu Inside Out | サイボウズエンジニアのブログ ▌ http://blog.cybozu.io/entry/2016/09/01/ 080000
  4. 4. サイボウズのSRE ▌L7〜 ・デプロイ ・監視・メトリクス収集 ・障害 ・インフラツール ・ミドルウェア ・linux kernel ▌L3〜 ・ルーティング ・スイッチ ・物理サーバ ・回線 ・データセンタ ▌L4〜 ・ロードバランス ・https
  5. 5. サイボウズのSRE ▌信頼性・可用性の維持向上 ▌ログ収集・分析基盤の構築 運用 ▌需要予測に基づいて、機材 増強・入替・構築 ▌セキュリティの担保 ▌緊急警告対応〜 根本対処まで ▌アプリケーションのデプロイ ▌調査依頼など
  6. 6. SREの取り組み1: セッションキャッシュ, yrmcds ▌2013年ごろ:お客様が増えてきた  MySQLにセッション入れてたけど遅いしIO負荷すごい  オンメモリ化しよう!  耐障害性ほしい&低コストで運用したい  memcachedはレプリケーションがない  レプリケーションがあるRedisとかは運用が大変そう  プロトコル簡単だし作ろう。  せっかくだからオープンソースにしよう!  yrmcds 0.9.0 リリース http://blog.cybozu.io/entry/5436
  7. 7. SREの取り組み2: DoS対策, yrmcds ▌2014年ごろ:お客様がよくキーボードの上に本を落とすよ! F5だよ!  同時アクセス数を制限しよう  作ったyrmcdsでカウントしよう!  nginx の拡張モジュールを書いて DoS 対策をした http://blog.cybozu.io/entry/8363  yrmcds 1.1.1 + libyrmcds 1.2.0 をリリースしました http://blog.cybozu.io/entry/8453
  8. 8. SREの取り組み3: オープンソース化, golang, cybozu-go ▌最近ではGoを採用していて、Go系のオープンソースも公開  Go でいい感じのコマンドを作れるツールキットの紹介 http://blog.cybozu.io/entry/cybozu-go-cmd  Cybozu Go · GitHub https://github.com/cybozu-go/
  9. 9. SREの取り組み4: データ移行, gosyncd ▌新システムへのデータ移行のやり方の一つ:  初期同期:バックアップ・スナップショットから新環境にコピー  差分同期:変更されたファイルを監視して新環境にコピー ▌通常運用負荷に同期負荷が乗るので障害になりやすい  同期速度で負荷をコントロール  ファイルキャッシュを汚さない  gosyncd - 安定して、データ移行を行うためのツール
  10. 10. SREの取り組み5: 透過SOCKSプロキシ ▌NAT -> 透過SOCKSプロキシに切り替え ▌メール周りの障害が少なくなり、調査がぐっとやりやすく!  SPAMフィルタ問題  tcp_tw_recycle問題  NAT をやめて、透過 SOCKS プロキシを導入した  http://blog.cybozu.io/entry/2016/03/14/130000
  11. 11. SREの取り組み6: LVM Thin Provisioning, リストア ▌バックアップのリストアが遅い!  毎月の全環境のアップデートリハーサル  バックアップベリファイ / 障害調査 / リストア依頼 ▌リストア時にブロック差分を都度マージしていた  LVM Thin Provisioningを導入してスナップショットの形 でバックアップしよう!  スナップショットとり放題  いつでもすぐ使える ▌全環境リストアは12時間強 -> 30分に!
  12. 12. SREの取り組み7: WalB ▌現在のバックアップ形式: 日次スナップショットからブロックデバイス単位でバイナリ差分を取得  バックアップ取得負荷がきつい。 ▌常に取り続けられるように!書き込まれる都度にバックアップ!  サイボウズ・ラボの星野・光成が開発して、SREと一緒に導 入  WalB v1.0 リリース http://blog.cybozu.io/entry/5130
  13. 13. SREの取り組み8: Zabbix, Datadog ▌サービスインより、メトリクス監視はZabbixで運用 ▌現在は自社DCも複数サイト運用し、監視対象は1000台を 越える  2-3年後にはさらに2倍の規模も見えてくる ▌さすがにZabbixでは辛いので、よりよい監視の導入を検討  Cloud Monitoring as a Service | Datadog https://www.datadoghq.com/
  14. 14. 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/
  15. 15. SREの取り組み10:その他 ▌presto(hadoop)  アクセスログの基盤として先行投入  1日分の集計に13時間 -> 20秒に!  アプリケーションログ・syslogなどの収集・分析基盤も導入検討中 ▌可視化!  ggplot2でWebサーバのレスポンスタイムをざっくり可視化する方 法  http://blog.cybozu.io/entry/8039 ▌現在Ubuntu 16.04への移行作業中  upstartからsystemdへ
  16. 16. ▌NVMe SSDの導入  高速化:MySQL / ElasticSearch ▌Graylog  ネットワークスイッチのログ収集 ▌DC運用  cybozu.com のラック設計 http://blog.cybozu.io/entry/6766 ▌AS運用  131912 CYBOZU JP00137545 https://www.nic.ad.jp/ja/ip/as-numbers.txt SREの取り組み11:その他
  17. 17. SREチームを作ったわけ ▌サービスイン当初は全員で運用も開発もしていた。 ▌規模が大きくなるにつれ、障害対応や調査、特殊な対応など、 優先度の高い割り込みが増加  集中して開発できない DevとOpsを分割 → しばらくはうまくいっていたが…
  18. 18. DevとOpsチームの間で問題が… ▌Opsチームの開発スキルが上がらない!  最初はOpsメンバーもコードを書いていた  新メンバーも増えるにつれ、徐々に開発が少なく ▌Devチームの作ったシステムの移行・運用コストが高すぎる!  ある日のデプロイから突然始まる、計画外の三ヶ月間の 巨大オペレーションプロジェクト…(とても良い機能だけど…)
  19. 19. SREチームに統合! ▌Dev/Opsに分かれるのをやめて、役割を固定しすぎないように。 ▌ソフトウェアエンジニアに立ち戻る!
  20. 20. 現在の課題 ▌アーキテクチャが古くなっている  サービスイン当初から基本的に変わってない  ストレージまわりが特にやばい!  刷新する人手が足りない(>_<) ▌若手の教育  プログラミング初心者もいるので、底上げが必要
  21. 21. SREでやりたいこと! ▌ログ収集・分析基盤 ▌検索基盤 ▌デプロイ ▌サービスディスカバリ ▌リソースプール  アーキテクチャ刷新プロジェクト「Neco」 の概要 http://blog.cybozu.io/entry/2016/03/11/080000 ▌分散基盤 ▌より簡易なオペレーション ▌リソースの統合監視 ▌キャパシティプランニング
  22. 22. ▌懇親会にも出ますので、お気軽にお声がけください!

Notas do Editor

  • コンセプト:聞いた人に、SREっておもしろそうだな、応募してみようかな、と思ってもらう!
    タイトル:SREチーム発足!
    1) サイボウズの運用本部のSREチームの齊藤と申します。
    今回は自分のチームの紹介をさせていただきたいと思います。
  • 2) SREとは?
    ・Site Reliability Engineer
    ・サイトの信頼性を向上させるソフトウェアエンジニア・チーム
    ・Googleが提唱して、様々な企業が取り入れている。
     日本では以下など:
      インフラチーム改め Site Reliability Engineering (SRE) チームになりました - Mercari Engineering Blog
      http://tech.mercari.com/entry/2015/11/18/153421

    3) SREとは?
    ・SREはもともとソフトウェアエンジニア。
     ソフトウェアエンジニアがインフラを扱う。
     
     プログラムを書くだけ、だったり、
     インフラの作業をするだけ、ではなく、
     どちらもやりますし、それ以上のこともします。

  • サイボウズでも2016年の9月からSREチームを設立しました!

    #SRE チーム発足の Inside Out 記事をちら見せ
    SRE チームを設立します - Cybozu Inside Out | サイボウズエンジニアのブログ
    http://blog.cybozu.io/entry/2016/09/01/080000
  • 4a) サイボウズのSRE
    サイボウズは基本自社DC運用なので、他社のSREさんよりハードよりのことも扱います。
  • 4b)(もしくはこう)
    (改善)
    >  ・可用性やパフォーマンスの維持・向上
    >  ・ログ収集・分析基盤の構築運用
    >  ・需要予測に基づいて、機材増強・入替・構築
    >  ・セキュリティの担保
    (障害)
    >  ・緊急警告対応~根本対処まで
    (依頼)
    >  ・アプリケーションのデプロイ
    >  ・調査依頼など
    ※自社DCについて突っ込まれたら、
     ・B2B。セキュリティなどを細かく気にするお客さまも多い。
     ・もともとJPリージョンがないころから始めていて、進めていくうちにコストメリット、という話。
  • 5) SREの取り組み1: セッションキャッシュ, yrmcds
    サイボウズのSREが具体的にどんなことに取り組んでいるのか、紹介していきます。

    いろいろ知っていただきたいので、ちょっとたくさん紹介します!(^^
    ただ運用してるだけじゃなくて、自分たちで工夫して運用してきてるんだよ、というのを知っていただければ!

    1. 2013年ごろ:お客様が増えた
     -> MySQLにセッション入れてたけど遅いしIO負荷すごい。
     -> オンメモリ化しよう!
     -> セッションだし、耐障害性がほしい&冗長構成は低コストで組んで、運用を楽にしたい。
     -> memcachedはレプリケーションないし、レプリケーションがあるRedisとかは運用が大変そう
     -> プロトコル簡単だし作ろう。
     -> せっかくだからオープンソースにしよう
     yrmcds 0.9.0 リリース - Cybozu Inside Out | サイボウズエンジニアのブログ
     http://blog.cybozu.io/entry/5436
  • 6) SREの取り組み2: DoS対策, yrmcds
    2. 2014年ごろ:お客様がよくキーボードの上に本を落とすよ!F5だよ!
     -> 同時アクセス数を制限しよう
     -> yrmcdsでカウントしよう!
     nginx の拡張モジュールを書いて DoS 対策をした - Cybozu Inside Out | サイボウズエンジニアのブログ
     http://blog.cybozu.io/entry/8363
     yrmcds 1.1.1 + libyrmcds 1.2.0 をリリースしました - Cybozu Inside Out | サイボウズエンジニアのブログ
     http://blog.cybozu.io/entry/8453
  • 7) SREの取り組み3: オープンソース化, golang, cybozu-go
     最近ではGoを採用しているので、Go系のオープンソースも。
     Go でいい感じのコマンドを作れるツールキットの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
     http://blog.cybozu.io/entry/cybozu-go-cmd
     Cybozu Go · GitHub
     https://github.com/cybozu-go/
  • 8) SREの取り組み4: gosyncd
     運用には、新システムへのデータ移行がつきもの。
     これがないとサービスを止めないで新機能投入できない!
     大容量データを新システムに移行するときの一つのやり方は
     1. 初期同期:現時点のバックアップデータ・スナップショットを用意して、新環境にコピー
     2. 差分同期:現行環境側で変更されたファイルを監視して新環境にコピー(削除やリネームなども)
     ただ、素直にやると、通常運用負荷に同期負荷が乗るので障害を呼びがち。
     -> 負荷の少ない時間に速度を上げて、日中は下げられるようにする。
     既存のアプリに影響が出ないようにファイルキャッシュなどをあまり汚さないようにしたり。
     安定して、データ移行を行うためのツール:
      gosyncd
  • 13) SREの取り組み9: 透過SOCKSプロキシ, transocks, usocksd
     メール周りの障害が少なくなり、調査がぐっとやりやすく!
     ・SPAMフィルタ問題
     ・tcp_tw_recycle問題
      NATサーバは発信元サーバが付けたタイムスタンプをそのまま使う
      値が行ったり来たりしているように外からは見えてしまい、たまたま値が古かった方の接続要求を無視する
      インターネットでは普通に起こるので、閉じたネットワークでのみ設定すべきだが。。
     NAT をやめて、透過 SOCKS プロキシを導入した - Cybozu Inside Out | サイボウズエンジニアのブログ
     http://blog.cybozu.io/entry/2016/03/14/130000
  • 9) SREの取り組み5: LVM Thin Provisioning, バックアップ, リストア
     ・バックアップのレストアが遅い!
      ・毎月の全環境のアップデートリハーサルやバックアップベリファイ・障害調査・リストア依頼など
     -> それまでは、レストア時にブロック差分を都度マージしていた。
     -> LVM Thin Provisioningにして、スナップショットの形でバックアップしよう!
      ・スナップショットとり放題
      ・いつでも使える
     -> それまでの全環境リストアは12時間強
      -> 30分になったよ!!
  • 11) SREの取り組み7: WalB
     ・現在は日次スナップショットからブロックデバイス単位でバイナリ差分を取得してのバックアップ
      ・バックアップ取得負荷がきつい。
     ・常に取り続けられるように!書き込まれる都度にバックアップ!
      WalB v1.0 リリース - Cybozu Inside Out | サイボウズエンジニアのブログ
      http://blog.cybozu.io/entry/5130
  • 12) SREの取り組み8: zabbix, Datadog
     ・サービスインより、メトリクス監視はZabbixで運用
     ・現在は自社DCも複数サイト運用し、監視対象は1000台を越える
      -> 2-3年後にはさらに2倍の規模も見えてくる。
     ・さすがにZabbixでは辛いので、よりよい監視の導入を検討
      Cloud Monitoring as a Service | Datadog
      https://www.datadoghq.com/
  • 14) SREの取り組み10: artifactory
      svnでの管理 -> artifactoryの導入
      aptやPythonなどのレポジトリのように透過的にそのまま扱える。
     > アーティファクトの管理について、あるいは go-apt-cacher / go-apt-mirror の紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
     > http://blog.cybozu.io/entry/2016/07/19/103000
     > Artifactory - Universal Artifact Repository Manager
     > https://www.jfrog.com/artifactory/
  • 15) SREの取り組み11: アクセスログ, presto, hadoop, airpal
     ・ログ収集・分析基盤を導入検討中
     ・presto(hadoop)をアクセスログの基盤として先行投入
     -> 1日分の集計に13時間 -> 20秒に!
    16) SREの取り組み12: その他いろいろ
     ・現在Ubuntu 16.04への移行作業中。
      upstartからsystemdへ。
     ・可視化!
      ggplot2でWebサーバのレスポンスタイムをざっくり可視化する方法 - Cybozu Inside Out | サイボウズエンジニアのブログ
      http://blog.cybozu.io/entry/8039
      Rでkintoneのデータを取得するパッケージをCRANで公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
      http://blog.cybozu.io/entry/2016/11/28/080000
  •  ・graylog
      ネットワークスイッチのログ収集

     ・NVMe SSDの導入
      ・MySQL DB プールに利用して高速化
      ・ElasticSearchのData nodeに利用して高速化
     ・DC運用
      cybozu.com のラック設計 - Cybozu Inside Out | サイボウズエンジニアのブログ
      http://blog.cybozu.io/entry/6766
     ・AS運用
     > 131912 CYBOZU JP00137545
     > https://www.nic.ad.jp/ja/ip/as-numbers.txt

  • 17) SREチームを作ったわけ
    そんなSREチームですが、SREチームというのができるには理由がありました。
    1. まず、.comのサービスイン当初は全員で運用も開発もしていた。
    2. 規模が大きくなるにつれ、障害対応や調査、特殊な対応など、優先度の高い割り込みが増加
    -> 集中して開発できない ->DevとOpsを分割 -> しばらくはうまくいっていたが…
  • 18) DevとOpsチームの間で、深刻な問題が…
    ・Devチームの作ったシステムの移行コスト、運用コストが高すぎる!
    ある日のデプロイから突然始まる、計画外の三ヶ月間の巨大オペレーションプロジェクト…
    # その際デプロイした物はとても良いもので、今はめっちゃ大助かりだけど。。
    -> 本番環境の実際のメトリクスや、オペレーションの観点が、開発時の移行手順設計から抜けてしまっていた。
    ・Opsチームの開発スキルが上がらない!
     最初はOpsメンバーもコードを書いていたものの、
     新メンバーも増えるにつれ、まずは、目先のオペレーションをこなす必要もあり、
     徐々に開発が少なくなる。
     Devチームと別チームなので、最新の知見や空気感も徐々にわからなくなる。
     -> 目先の対処が優先され、改善が進まない。。
  • 19) そのため、SREチームに統合!
    ・Dev/Opsに分かれるのをやめて、役割を固定しすぎないように。
    ・ソフトウェアエンジニアに立ち戻る!
  • 20) 現在の課題
     ただ、1000台越えの環境でまだ13人…
     -> DevもOpsも全員やるようになって、人手不足がはっきりした
  • 21) やりたいこともたくさん!
    ・ログ収集・分析基盤
    ・検索基盤
    ・デプロイ
    ・サービスディスカバリ
    ・リソースプール
    ・分散基盤
    ・より簡易なオペレーション
    ・リソースの監視・キャパシティプランニング
    > アーキテクチャ刷新プロジェクト「Neco」 の概要
    > http://blog.cybozu.io/entry/2016/03/11/080000
  • 21) 結び
    ・このようなことをやっていますので、ぜひ、良かったらサイボウズのSREチームで大きなインフラを一緒に支えていきませんか?
    > サイボウズエンジニアの職場環境 @ 2016 - Cybozu Inside Out | サイボウズエンジニアのブログ
    > http://blog.cybozu.io/entry/2016/05/23/080000#oss
    というお誘いで、今日の私からのSREチームの紹介を締めくくらせていただければと思います。
    懇親会にも出るので、気になるテーマがある方がいれば是非お声がけください!
    ご清聴ありがとうございました!

×