アイキャッチ編集

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

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

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


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

※ NoOpsとは?:NoOps Definition

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


会場は WingArk1stさんでした。


■オープニング

岡大勝さん [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で、トラフィックや故障による障害はかぎりなくゼロに近づけられるかもしれませんね!

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


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

イベントレポ

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

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

ありがとうございます!シェアしてもらえるとうれしいです!
4
プロセスのデザイナー兼エンジニア https://suwa-sh.github.io/profile/

この記事が入っているマガジン

イベントレポート
イベントレポート
  • 88本

各分野の最新情報と事例、熱量を体感しに参加しているイベントのレポート

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。