2019-07-29 NoOps Meetup Tokyo #7 #NoOpsJP

2019/07/29 に 開催された NoOps Meetup Tokyo #7 のイベントレポートです。

NoOps Meetup Tokyo #7 (2019/07/29 19:00〜)

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

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

※ NoOpsとは？：NoOps Definition

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

会場は WingArk1stさんでした。

WingArk1stさんの素晴らしい会場で進行中 #NoOpsJP pic.twitter.com/1ODZ9GuGEy

— 岡 大勝 (@okahiromasa) July 29, 2019

会場からの景色もスゴイ！ #NoOpsJP pic.twitter.com/KxFPqjaBmB

— 岡 大勝 (@okahiromasa) July 29, 2019

■オープニング

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

※遅刻でお話は伺えず。

■入門サービスメッシュ

Taiki Ono さん [Tetrate]

※遅刻でお話は伺えず。

■kubernetesのデータ管理どうする？主に永続化ストレージについて

渡邊 誠さん [NetApp]

●k8sストレージの必要性と基礎
・コンテナ自体がステートレス
　　停止時にはデータは消えてしまう
・コンテナオーケストレータを意識すると
　　Podがどこにスケジュールされてもデータにアクセス
・求められる要件
　　オンデマンドなプロビジョニング
　　高可用性が必要

●ストレージ周りのk8sオブジェクト
・PVC
　　どんな要件のストレージが必要か
・PV
　　バックエンドのストレージとマッピング
・Storage Class
　　サービスレベルを指定

●k8sストレージの役割分担
・アプリの定義
　　Dev/利用者
　　Deployment
・インフラの定義
　　Ops/管理者
　　StorageClass

●PVの使い方は2種類
・Static Provisioning
　　Manual Provisioning
　　※最近はこっちの記載
・Dynamic Provisioning
-> StorageClass, PV, バックエンドストレージの紐付けが
　　動的 or 静的の違い

●Container Storage Interface(CSI)
・ストレージベンダーはオーケストレータごとにドライバを実装していた
-> CSIで共通化
-> 利用者側には影響が出ない
　　Pod, PVCからは見えない

●CSIのDesign Doc
　　https://kubernetes-csi.github.io/docs
　　アーキテクチャ
　　機能実装

●Volume Cloning
・概要
　　コピー元を指定してPVCを作成
・課題
　　CSIドライバのみ
　　DynamicProvisioningが前提
　　同一namespaceのみ
　　実装は確認が必要

●Volume Snapshot
・概要
　　ある時点のボリュームの断面を取得
・利用の流れ
　　Volume Snapshot Class 作成
　　Volume Snapshot 作成 & 取得
　　PVC作成時にsnapshotを指定
　　-> PVCのオブジェクト関係と近い
・課題
　　CSIドライバのみ
　　DynamicProvisioningが前提
　　実装は確認が必要

●NetApp Trident
・CSI実装の1つ
・ver 19.07 でCSI1.1対応予定
・各種コンテナプラットフォームに対応
　　Rancher, DockerEE, OpenShift
　　NKS, AKS, EKS, GKE

■データドリヴンなサービス運営を目指して～機械学習インフラの設計思想と可能性～

佐々木 明夫さん[Microsoft Corporation]

※中抜けで前半のお話は伺えず。

●Single Source of Truth
・VMが出てから爆発的にインスタンスが増加
　　Telemetry情報 が肝
　　共通で信頼できる唯一無二の存在
・クラウドでは
　　仕様が常にアップデートされる
　　パフォーマンスは常に変化
　　アップデートは毎週
・Telemetry情報、SLA、課金に情報が集約される
　　ミッションクリティカルでなければ
　　稼働情報が悪くても、SLAを下げられる
　　など

●機械学習の例
・世界で一番攻撃を受けているのはペンタゴン
　　二番は、MSのデータセンター
・ネットワークトラフィック、異常検出を組み合わせて、傾向が見える
　　国ごとに傾向があったりする

●HW故障の予兆検知
・あらゆるシグナルが対象
・発生率の均一化が難しい
　　発生率は 1/10,000 程度
・壊れそうなHWを集中して監視
・0.1〜1.6secで移行できるからLiveMigration
・直接の原因がわかるまでリグレッションテスト

●機械学習に影響を受けるアプリケーション
・instance base vs. serverless
　　変化への耐性で判断
　　　　扱うデータが変わるなら、serverlessは合わない
　　　　VMは柔軟だが、OSが変化に弱い
　　agentベースが終わり、プラットフォームが情報を持つ
・auditログ、運用ログを分割
　　運用管理でも2種類のデータ
　　First Data, Big Data
　　ラムダアーキテクチャ的な考え方が必要

●クラウド進化に追従するサービス進化
・インフラの選定 x ヒトの予測
　　-> IaaS/Paas
・オートスケールトリガーの設定 x ヒトの予測
　　-> テレメトリーデータ & 機械学習
・データドリブンにスケール x プラットフォームが判断
　　バーストの時刻を予測して事前にウォームアップ
　　など

●Azure Data Explorer
・秒間 10億クエリ を視野に入れている
　　アドホックにクエリしても一発で正解にたどり着けない
　　連鎖的なひらめきを重ねていくにはスピードが必要

■前回の様子

■感想

社用で遅刻、中抜けになってしまい、お話を伺えず残念でした。。。が、実況ツイートはありがたいですね！聞けなかった部分のコンテキストが繋げられました！

お話は伺えませんでしたが、サービスメッシュの歴史を読んでいて、マイクロサービスはDDDと同じアプローチなのだなと、改めて感じました。システム化領域が広がったので、解決方法でアーキテクチャや通信を扱うようになっていますが、概念の抽象化や分割単位、組み上げるパターンは、フラクタル。次にフラクタルを感じるのは、どんなモノをあつかっているのか、ワクワクしますね。

Observabilityが上がって、データが蓄積されれば、スケールの予測が立てられる。蓄積したデータの量が増えれば、予測の精度は上がっていく。DevOps Daysで伺った事例では、運用データからリリース障害を予測して、必要な体制を提案するというものもありました。機械学習とDesign for NoOpsで、トラフィックや故障による障害はかぎりなくゼロに近づけられるかもしれませんね！

登壇者の皆さん、参加者の皆さん ありがとうございました！
運営の皆さん お疲れさまでした！！