見出し画像

NoOps Meetup Tokyo #6

昨年の#03に初めて参加して、AWS西谷さんとアメリカに行く前のMicrosoft牛尾さんと豪華な登壇者と濃厚なコンテンツに圧倒されたのだけれど、その後はタイミング合わず参加できず。今回も抽選になるほどの人気だったけれど当選!次回7/8のTech-onのテーマが「OpsとDevの蜜月な関係」ってことで、DevOpsのOpsにフォーカス。NoOps Meetupのコンセプトとも通じるところが多いので、楽しみにしてきました。オープニングとメインの3セッションのレポートです。

オープニング

発起人の岡さんからのコミュニティ紹介。
NoOps = No "Uncomfortable" Ops
「システム運用保守の"嬉しくないこと"をなくそう!」

<Compassより>
NoOps の目標
・システム運用保守がユーザー体験を妨げないシステムの実現
・システム運用保守で発生する「トイル」の最小化
・システム運用保守コストの最適化

NoOps Japan で扱う主なテーマ
・Architecture = Design for Resiliency(NoOps)/DevOps
・Technology = Container/Serverless/Observability/Configurability/Zero-Trust Network
・SRE = Less Toil/Ops Automation

Meetupで知の供給、Open Hackでものづくり。

共感駆動のSRCAサイクル
①共感:Share Passion with empathy
②尊重:Respect
③貢献:Contribute
④感謝:Appreciate

No Opsの活動の分類

Observabilityを支えるStackdriver

Google山口さんによるSRE、SLI・SLO・SLAの定義から、オブザーバビリティ(可観測性)のためのStackdriver製品群の活用まで。

SREとSLI・SLO・SLAの定義
安定を価値として取り組む。SLOを100%と設定しない。
エラーバジェット:許容可能なエラー率(時間、範囲、レベル)
どのくらいのSLOに設定すれば安定した価値を届けられるかをビジネス側含め合意を取る。

オブザーバビリティ(可観測性)
システムを運用する上で判断に必要な情報が取得できている。
・入門 監視
・入門 Prometheus
はこの辺を詳しく知るためにオススメ。

SLIとなるメトリクスを取得し、SLOの可視化を行う。
ダッシュボードに表示はするが眺めているわけにはいかないので監視。

クラウド化でインフラ側を見ることは減ってきて、アプリケーションメトリクスを見ることの重要性が増えてきている。

Stackdriver製品群:最小限の実装でオブザーバビリティを提供
障害対応用のダッシュボードにも提供
GCPとAWSにも
分散トレース、メトリックスを取得するためのツール
OpenCensus&OpenTelemetry

GCPがStackdriverを提供するのは、
APIより内側はプラットフォームしか提供できない
SREの実戦経験を共有する一番の近道
全てダッショボードとして一箇所で提供できるのがいい

各運用プロセスで必要なデータ
メトリクス:アプリケーションメトリクス(開発者が自分で組み込む)+事前定義メトリクス(マネージドとして提供:ランタイム、ストレージ)

カスタムメトリクス
アプリケーション側にOpenCensusなどを使って組み込む
Latency、Line数、何バイト入ってきたのか
設定しておくとモニタリングダッシュボードで可視化ができるようになる。

ログベースメトリクス
構造家ログのデータからチャートを作成
JSONで必要なmethod、statusなどを設定しておくと、必要な情報を表示

稼働時間(uptime)の確認
URL外形監視ができ、状態がダッシュボードで可視化できる。

Stackdriver profiler
アプリケーションのボトルネックを発見
CPU使用率のどこの関数が一番使っているか

Stackdriver trace
サービスをまたがったトレースが可能

SLI・SLO・SLAの定義も頭では認識していたけれど、QAで岡さんが言ってたSECIモデルでも暗黙知から脱却してなくて、システム運用において共同化も表出化もできていないことが多い。
SLIとなるメトリクスを取得し、ダッシュボードでSLOの可視化を行って、監視も行う。この辺りをなんとか表出化して、連結化し、チームメンバーの内面化まで持っていきたい。
Stackdriverも使ってみたいのだけれど、AWS環境のオブザーバビリティにも活用できそうだけど、GCPにアカウント作るところをどうするかだな。

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

サイボウズ山本さんによる自社の物理データセンターをKubernetes中心のアーキテクチャに1年半で刷新し、NoOpsに繋がるプラットフォームを構築。その名も”Necoプロジェクト"!。

現在のデータセンター
国内数カ所のデータセンターでオンプレで、数十台から数千台まで同じアーキテクチャできたが、分散システム基盤はsshでなんとかするやつ。
手作業・Toilが多く、低いスケーラビリティ、自作に偏りすぎと課題が山積み。

こうありたい
・撃ちっぱなし可能な宣言的オペレーション
・継続的なデリバリー
・高速開発・運用のワークフロー(DevOps)
・数千台の規模を活かせるスケーラブルなシステム
・自作からの脱却

Necoプロジェクト
2018年1月から始動。3ヶ年計画。
物理サーバに依存したくないので、コンテナ・マイクロサービス時代の勝ち馬k8sを採用。宣言的APIで大規模システムの運用を容易にし、拡張性が高い。

Necoの設計原則
1. Be Declarative
2. Define by Software
3. Test Everything

CKE
k8sクラスタの運用を自動化
管理者が望みのクラスタを宣言すると、CKEが適当な物理サーバを選んで構築。k8sの自動バージョンアップも。
CKEの詳しい話は、CloudNative Days Tokyoで。

BGP+BFD+ECMPで経路管理&冗長化
Linux/k8sから経路を自在に制御可能
・BIRDと組み合わせ可能なCNIプラグイン「Coil」
・MetalLBでもLoadBalancerを実装
・ルーターもソフトウェアで実装可能
専門的な話はブログで

仮装データセンター
Necoの開発・試験のため、開発者に仮想データセンターが必要。
データセンターでの動作も自動試験したい。
placematという仮想データセンター構築ツールを開発

Necoのデータデリバリー戦略
・システムをk8sの上と下で分離する
・システム全体をデリバリー前に試験する

ミドリが世の中のソフトウエア、ピンクがNecoのソフトウエア。
世の中のソフトウェアも中身は徹底的に理解する。

今後の予定
ストレージ管理:自社製CSIプラグインTopoLVMを開発中
テナント管理:2019年7月に本番データセンター構築予定
テナントに使ってもらうための教育、ドキュメント、利用者向け開発環境

現在のシステムの課題をNecoの設計原則を最初に決めて、徹底的に原則に沿ったアーキテクチャ、設計を貫いて、k8sだけじゃなく、必要なソフトウェアは自社開発、成果物を全てgithub.comでOSS公開。ここまで推し進められるのに現在でも10人体制で社内人材だけというから驚きでした。CI/CDプラットフォームも最初に決めるべきって、JAWSでもポジティブな Toriさんが言ってたけれど(先日のX-TECH JAWSでは少しトーンダウンしてたけどw)最初にきっちり設計原則を固めて、スキルチェックシートを作って、陣頭指揮をとられた山本さんの存在は大きいんだろうな。世の中のソフトウェアも含め、中身を徹底的に理解して作るという考え方も、開発観点でも運用観点でも大事なので、DevOpsのあるべき方向性だと思いました。

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

スタディストのかつひささんによるNoOpsの登場背景についての考察と、SREとNoOpsの関係、スタディストでのToilの計測までのお話。

NoOpsの一連の話題
コラボレーションを重視する DevOpsに対し
自動化をより重視するNoOpsという概念構造
NoOpsの"Ops"は職種や役割ではなく、一連の業務群をソフトウェアで行うこと
岡さんの「No "Uncomfortable" Ops」もこの辺の背景があるはず。

SREとNoOps
SREでは、「No "Uncomfortable" Ops」に相当する文脈として、「Eliminating Toil」がある。
SREはToilを業務時間の50%以下におさえる。
⇒ どうやってToilを撲滅する?そもそもどうやってToilを計測する?

Eliminating Toil at Studist SRE Team
SREの業務分類
Toilは繰り返すことでの価値が得られないもの
System Enginneringは設定すれば恒久的に価値が得られるもの

全ての業務にポイント(業務に要する時間の目安)を付与し週の終わりに割合を計測。Toilに要した時間や、OKR(Objectives and Key Results)に集中できた時間を可視化。
ベロシティも計測しているが作業時間割合の計測をより重視し、チームの時間の使い方の健全性を維持。
今期のToilの割合は、5%〜10%。昔はToilまみれだったけど、ここまできた。

Toil Management Strategy
① Engineer Toil Out of the System
 そもそもToilが生まれないようなシステムにする。
 既存のシステムのToilを減らすことに投資する前に、システムを変えられないかを考える。
 Design Documentを必ず書く。Postmortemを書くのと同じくらい重視。

より信頼性の高いコンポーネントに置き換える
なぜ信頼性が高いのかをハラオチする
マネージドサービスであっても公開情報から内部情報を知ることができる場合も多い(Auroraもこの論文から知ることができる)

② Use SLOs to Reduce Toil
 稼働率100%ではなく、99.9%のようにダウンタイムを許容する。
 SLOを定義しておくことで、必要以上の性能目標を目指し、Toilが誇張しすぎることを防ぐ。(この辺りは、Google山口さんの話にも通じる)
チームと基準値を共有すると、性能面に先手を打つアイデアが生まれ、新たなToilが生まれないようになる。

③ Provide Self-Service Methods
 チケットドリブンではなく、開発者自身が自らやるようにする。
 Self-Seviceを構成する3つの要素
 ① Definition of the automated procedure
 ② Execution of the automated procedure
 ③ Governance of the automated procedure

 従来型のOpsでは、3つの要素ともOpsがやっているが、Self-Seviceのあるべき姿は、Opsはガバナンスだけ聞かせて、開発者はDefineとExecutionをやる。メルカリも同じようなことをやってると思う。

AWS Organizationを利用したGovernance構築
 OU(Organizational Unit)単位に分割
 AWS権限を与えるだけでなく、ドキュメントを整備
 今後やること:Teraformで必要な環境を構築するtemplate整備、SREチームへの留学制度

デプロイの責務を開発者に移管
 開発者が二人以上でApprove必須
 前提としてCircle CIでのテスト実行
 Productionデプロイ後に問題が起これば、1クリックでロールバック

開発者による問題検知を促進するモニタリング基盤
 StackdriverによるUptime Check、カスタムメトリックスを活用したジョブキューの可視化(キューの滞留時間を計測するため、空ジョブでの「キューに突っ込む時間」と「実際に処理された時間」をカスタムメトリックスとしてポストし可視化)。
 Stackdriver Error Reportingで新着バグを検知し、開発者がプロダクションで起こった問題に即座に気づくことができる。開発直後なら開発者も記憶に新しく原因分析も迅速にできる。

Toilの計測もSLOの可視化もGoogle山口さんが説明されていたことを、かつひささん自らSRE本をベースに理解し、実際にチームでもToilを計測して可視化することで、開発者が自ら行動することを促すようにするまでを実践。最初からできたわけではなく、一つ一つ積み重ねてToilを削減してきたアプローチは、ぼくのスクラムチームでもスプリント毎に改善を重ねてきたことと重なって、できることから始めていこうという気になってきました。これまでは開発よりのプロセスの改善に注力し、Ops、とりわけオブザビリティについては後手に回っているので、今ぼくらもフォーカスすべきはOpsという考えは間違ってなさそう。

まとめ

SREについて、NoOpsについて理解していたことは、組織やプロセス、自動化を推進することばかりだったので、今回のNo Ops Meetupに参加して、当日は理解が追いついていなかったことも含め、こうしてブログにまとめることで、すーっと理解が繋がっていきました。どのセッションもOpsとDevののあるべき姿への思いに近づくために、原則と信念と確かな論理を貫いて作り上げたものだったので、雰囲気で監視をやるのではなく、これまでもやり方とこれからのやり方を見つめ直すいい機会になりました。

Tech-onの次回テーマとも、自分のチームの課題とも、不思議とシンクロしていくのは、Tech-onの関心軸の設定が間違っていないことの証明にもなりそう。ここまで重厚で良質のコンテンツとはいかないまでも、こうやってNo Ops Meetupにまで足を運べてないけれど、Tech-onに興味を持って足を運んでもらった皆さんに少しでも持って帰ってもらえるように頑張ります!

よろしければサポートお願いします。いただいたサポートは、コミュニティ活動や、インプットに使わせていただきます。