見出し画像

2019-06-04 NoOps Meetup Tokyo #6 #NoOpsJP

2019/06/04 に開催された NoOps Meetup Tokyo #6 のイベントレポートです。

●イベント概要
NoOps = No "Uncomfortable" Ops


NoOps Japanでは 「システム運用保守の"嬉しくないこと"をなくそう!」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有していきたいと考えています。

※ NoOpsとは?:NoOps Definition

NoOps Meetup Tokyo #6 では、業界の第一人者のみなさんに登壇いただき、それぞれの視点でのNoOpsをお話いただきます。


■オープニング

岡 大勝 さん [NoOps Japan 発起人]

●NoOpsのライフサイクル
・Safety
・Resiliency
・Observability
・Configurability
・Less Toil

●NoOps Japan サポーター
・活動に賛同、貢献いただいた方
  登壇していただいた方
  優先してmeetupに参加できます
・個人スポンサー制度も検討中
・スタッフも随時募集中!

●スポンサー募集中
・会場スポンサー
・懇親会スポンサー
・ウェアスポンサー

@okahiromasa かスタッフまでお声がけください


■Observabilityを支えるStackdriver

山口 能迪 さん [Google]

↑ 埋め込めなかったので、画像リンクです。

●自己紹介
・Stackdriverの開発
・Go言語による並列処理

●Observability in NoOps
・オブザーバビリティ(可観測性)がなぜ必要だと考えるのか
・DevOpsからSREへ
  各種書籍が出てきた
・SREはDevOpsの実践方法の一つ
  システムの信頼性のために方針を持ってDevOpsを行う
・意思決定にデータを用いる
  主観ではなく
・運用課題をソフトウェア・エンジニアリングで解決

●SLI / SLO / SLA は 表裏一体
・ユーザの幸福度につながるように
・SLI: 割合
・SLO: SLIの限界許容値
  100%では意味がない
・SLA: SLOを破ったら、の規約
・SLOは、ビジネス側の人間も一緒に考える
  新しい機能を提供したが
  安定しなければお客さんには価値がない

●エラーバジェット
・許容可能なエラー率
・この空いた時間で改善や機能開発
  可用率 99.99% なら 52.6分

●オブザーバビリティ
・システム運用で判断に必要な情報が取得できること
・テスト、パフォーマンス、使い勝手
  -> 自分たちで取りに行く
・関連書籍
  入門監視
  入門Prometheus
・SLIとなるメトリクスの取得と収集
  メトリクス収集して外部へ
・SLO違反に対応するための体制
  可視化
  違反時の通知、トリガー
  障害対応に使うデータの収集
・public cloudでOSなどの負荷は軽減
  アプリケーションメトリクスの重要性が増した
  -> Stackdriver

●Stackdriver製品群
  Logging, Monitoring, Trace,
  Error Reporting, Profiler, Debugger,
  IRM, OpenSensus & OpenTelemetry

●GCPがStackdriverを提供する意味
・インフラの下にあるものはプラットフォーマーしか提供できない
・SREのプロセスを社内に導入しやすく
  Google内部の製品に近い
・他の製品と連携
・いろいろな製品にログインするよりまとめて見れるように

●運用プロセスで必要なデータ
・通常運用
・高負荷・調査
・障害対応
・振り返り

●通常運用
・システムの全体感
  メトリクス
    統計的に問題ないか
  アラートの設定
    SLO違反に備える
・定量的にデータを取得
  アプリケーションメトリクス
  事前定義メトリクス
・Stackdriver Monitoring
  外形監視
  事前定義メトリクス
    GCP
      appengine, cloudfunctions, compute, k8s
    エージェント
      MWごとの定型を事前に準備してある
  カスタムメトリクス
    OpenCensusなど
    アプリ固有の指標
      ファイルを読み込んだ行数
      画像サイズの入ってきた量など
      ユーザビリティにつながるものを送る
  ログベースメトリクス
    構造化ログのデータ
    -> カスタムメトリクス
    -> チャート
  URL以外のuptimeも確認できる
    インスタンスが上がっているか
    LB, AppEngine
  アラート設定
    SLOを超えた状態が5分以上続いたら
    Slack, PagerDuty, Mailなどに通知

●高負荷・調査
・問題を特定する手段があるか
  プロファイラー
  分散トレース
・アプリケーションのパフォーマンス
・Stackdriver Profiler
  アプリケーション内のボトルネックを探す
・Stackdriver Trace
  複数のサービスにまたがってトレース

●障害対応
・原因を手早く調査、全員で状況を共有
  エラーレポート
  IRM(Incident Response and Management)
・Stackdriver Error Reporting
  ぱっと見でどんなエラーが出ているか
    自動でグルーピングして、頻度を確認
  ドリルダウンでstacktraceまで
・Stackdriver IRM
  Google社内の障害管理に似せてつくっている
  チャットなどのコミュニケーションチャンネルもリンク
  誰に連携するか、も管理

●ふりかえり
・データのエクスポート
  BigQueryやpubsubへ

プラットフォームのObservabilityを確保
開発者の幸福度を高める


■NAVITIME JAPAN

●約499人の壁
・社員約499人より先に障害に気づいて対応が必要

ネットワークに障害
  -> 40〜499人に影響
状況と予定を通知したい
  -> Zabbix

・なぜzabbix4.0?
  2.xが活用されていなかった
  社内に知見があった
  ディスカバリで追加が楽
  テンプレートが便利
  インフラエンジニアの熱いプッシュ!

・導入してみて
  オンプレの機器監視には有用
  コンテナやクラウド環境も使える
    が、適しているかは検討
    オンプレ、クラウド両方みたいなら良いかも


■物理データセンターでも NoOps

山本 泰宇 さん [サイボウズ]

●サイボウズ
・グループウェア
・サイボウズOffice は20年
・もともとはパッケージソフト
  単調に規模が拡大してきた

●開発当初
・AWS東京リージョンもなかった
・数十台のオンプレからスタート
・手作り感

●課題
・手作業・toilが多い
・スケーラビリティが低い
・自作に偏りすぎ

●プログラムの更新
・手順書
・手順書レビュー
・複雑な手順がアドホックに自動化
・リハーサル
・本番で指差し確認
・完了まで端末前で待機
-> 数え役満w

●こうありたい
・宣言的オペレーション
・継続的デリバリー

●Neco プロジェクト
・インフラ刷新
・2018年1月から 3ヶ年計画
・k8sでopenに

●なぜk8s?
・物理サーバ脱却
・コンテナ、マイクロサービスの勝ち馬
・宣言的APIがオペレータの望んだものそのもの

●Necoの設計原則
・Be Declarative
・Define by Software
・Test Everything
  ぶっつけ本番やめましょう!

●CKE
・k8sクラスタの運用を自動化
  etcdが1台壊れた -> 自動回復
  k8sのバージョンアップも
・詳しい情報は #CNDT2019 で!

●BGP + BFD + ECMP
・全部ソフトウェアで経路経路制御
・詳しい情報は necoのネットワーク で検索

●仮想データセンター
・Necoはデータセンターは管理するソフトウェア群
  -> データセンターをまるごと仮想化
・placemat
  IPMI, UEFIなどもvirtualに

●Necoのデリバリー戦略
・k8sの上下で分けた
  上はargo CD
  下は自作で宣言的にデリバリー
・データセンターの全ての電源が落ちた状態からテスト

●これから
・ストレージ管理
  CSIプラグインTopoLVMを開発中
    LVMから動的に切り出して提供
    空き容量を考慮
  ES & MySQLオペレーター
・テナント管理
  開発者に使っていってもらうために

●Neco OSSレポジトリ


■ZOZOテクノロジーズ

・ZOZOテクノロジーズ
  ZOZOTOWN
  WEAR
  プライベートブランドZOZO

・ZOZOはオンプレからクラウドへ移行中
  検索するとAzureがよくヒットする
  GCP、AWSも使ってます

・楽しく働く!

※補足: 岡さん
  入社して2ヶ月経ちますが、楽しいですw


■NoOpsを実現するSREの存在意義と役割 / class SRE implements NoOps

かつひさ さん [スタディスト/SREラウンジ]

●自己紹介
・Linuxカーネルと同い年
  -> 27歳
・Teach me Biz
  Visual SOPつくってます
  ビジュアルベースの手順書

●NoOpsとは
・2011/4 フォレスターリサーチ社
  Augument DevOps With NoOps
  DevOpsはコラボ、NoOpsは自動化
・2012/3 Netflix
  コミュニケーションしなくても自動化されてるよ
・2012/3 gist
  それってopsだよね
・Opsを職種と捉えると拒否反応が出る
  業務群だと捉えると、自動化はごく自然なこと
  -> 認知の離散化が起きないように議論しよう
・No Ops != No Operations

●SREでのNo Uncomfortable Ops
・Eliminating Toil
・toil
  マニュアル的で、繰り返し実施して、自動化できる
  戦術的で、価値を生まない、規模に応じて増えるもの
・SREではoperational workと表現している
・SRE は toilを 業務時間の50%以下に抑えよう

●SREの業務分類
・Software engineering
  設計、コード
・System engineering
  一度実施すれば、恒久的に価値を生む
・Toil
  おいときます
・Overhead
  採用、会議、トレーニングなど

●スタディストでは
・OKR Work
  OKRの達成につながる
・Project Work
  Issueで管理する
・Toil
・Overhead

●KANBANのレーンでタスク管理
・全ての業務にポイントを付与
・ベロシティよりも、作業時間の計測を重視
  週の終わりに割合を計測
・チームの時間使い方の健全性を維持
・今季のtoil割合は、5~10%程度
  昔はtoilまみれだった

●Engineer Toil Out of the System
・そもそもtoilが生まれないシステム
・toilをへらすことに投資する前に、システムを変えられないか?
・DesignDocumentを書く
  不可逆性の高い部分、性能面で詰まるのはどこか?
  なぜその設計だと駄目なのか?
・信頼性の高いコンポーネントに置き換える
  マネージドでもドキュメントから内部を把握できることも

●SLOの活用
・性能面に先手を打つうことで新たなtoil発生を防ぐ
・SREチームの協力があってこそ!

●Ticket-Driven Request Queues Are Expensive
・依頼仕事だと時間がかかる
  セルフサービスにしていこう
・Self-Service を構成する要素
  Define / Execute / Govern
・Self-Service
  Consumers of Ops
    Define / Execute
  Ops
    Govern
  -> メルカリの世界線が近いのかもしれない

●AWS OrganizationでGovernance構築
・AWSアカウントを分割して、絶対にさわれないように
・権限付与 & ドキュメント整備
・terraform template整備
・SREチームへの留学制度

●デプロイを開発者に移管
・PRは2人以上の承認
・CircleCIでのテストを通っている
・デプロイ後に問題が起きれば1クリックロールバック

●開発者が問題を検知できるしくみ
・性能的な問題
  Stackdriver
    実際のキューにからジョブを投入、処理時間を計測
    滞留時間が長くなるとアラート
  NewRelic
・機能的な問題検知
  Stackdriver Error Reportingで新着アラート
    グルーピングしてくれるので新着に気づける
    開発した直後なら分析もスムーズ
・分析基盤
  fluentdからES/kibanaへ

●Recap
・全部知りたい人は、一緒にやりましょう
#srelounge にもきてね
#sresession にもきてね


■Microsoft

・クラウドデベロッパーちゃんねる
・de:code 2019 振り返り Night! Sponsored by Qiita


■パネルQA

※片付けでほとんどお話を伺えませんでしたが、組織や文化のQAで盛り上がっていたようですね!


■前回の様子


■感想

・プラットフォーマーとしての可観測性提供の意味
・データセンターを仮想化する発想
・つくった人がハンドルを握る効果

などなど、たくさんの気づきをいただけました!
登壇者の皆さん ありがとうございました!


この記事が参加している募集

イベントレポ

いつも応援していただいている皆さん支えられています。