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で盛り上がっていたようですね！
■前回の様子
■感想
・プラットフォーマーとしての可観測性提供の意味
・データセンターを仮想化する発想
・つくった人がハンドルを握る効果
などなど、たくさんの気づきをいただけました！
登壇者の皆さん ありがとうございました！
いいなと思ったら応援しよう！
