tshohe's memo

おぼえたことをかく

NoOps Meetup #2 のメモ

参加したので酔った頭でメモ。
「システム運用保守の"嬉しくないこと"をなくそう!」 がテーマの勉強会。

https://noops.connpass.com/event/103846/

オープニング

  • 岡 大勝さん@okahiromasa NoOps Japan 発起人

  • どなたかの言葉

    • Opsは嫌い
    • べきじゃなくて武器
    • Noを掲げてやめる(やめるのが難しい)
    • 運用をやめるということではない
    • これ以上Opsが減らないというスイートスポットを目指す
    • Toil削減、可観測性の向上といったことはSREとしてやることをやっていれば行き着くところ
    • 堅牢性 より Resiliency
  • 前回のsummary

    • 「”やめる”ことを決める」事が大事
    • NoOpsに向かう準備は整っている
    • みんな違ってみんないい
  • NoOps Japan Community: ナレッジを集めてOSSで公開するとか

  • SRCAサイクル(共感 → 尊重 → 貢献 → 感謝)

MicroserviceでのNoOps戦略

  • 鈴木 雄介さん@yusuke_arclamp グロースエクスパートナーズ
  • NoOpsの歴史
  • 2001年にアジャイルソフトウェア開発宣言
  • アジャイルをインフラにも適用したい -> DevOps
  • 2009年 Velocity 2009
    • DevOps Daysが始まる
  • 2011年: NoOps登場
    • Argument DevOps With NoOps
    • NoOpsは協業ではなくて自動化を目指す
    • I Don't want DevOpsとも...
      • Opsを敵に回し炎上
  • 2012年: Ops, DevOps and PaaS
    • Netflixではビルドデプロイの自動化はされていてデプロイはDevでやっている
    • 各チームが好きなタイミングで実施
    • ツールの開発はDevOps/SREチーム
    • 単純なオペレータは存在しない
    • 開発者はツールを使って運用作業を実施する
  • NoOpsが変えたこと
    • 作ると動かすの距離がなくなる
    • アプリケーションエンジニアはアプリを作るのではなくサービスを作る(機能要件に従ってコードを書くだけではない)
  • 2014年: Microservice

    • 「Microservice Java the Unix way」がバズる
    • サービス全体を止めずに一部を変更する(それぞれの変更タイミングはバラバラ)
    • 変更発生単位でサービスを分割
  • NoOpsとは「サービス全体を止めずに一部を変更する、ために、主に、運用作業の自動化とツール化を推進すること」

    • ビジネス価値を最大化するのが対局目標
  • 代表的な取り組み

  • 障害からの自動復旧
  • ミドルバージョンアップ自動化
  • 日中無停止リリース

  • アプリとインフラをセットで管理する、というのがまだない?

    • PaaS: 層が上がると制約が上がる
    • コンテナ: 構成の変更をセットで扱える
  • 動かすときにインフラ調達

  • 「インフラを用意してアプリを置く」、ではなく「アプリを動かそうとするときにインフラを調達する」
  • PaaSがまさに

  • バッチサーバは不要(バッチ実行時にインフラを調達する)

  • 固定IP/ドメイン -> 使わずに、自動払い出ししてサービスリポジトリに登録しに行く
  • 設定ファイルはサービス起動したら撮ってくるようにするとか

  • その先

    • k8s, istio
    • イベントソーシング: CQRS

ITインフラの NoOps を実現する戦略と方法論

中島 倫明さん @Irix_jp レッドハット

  • Ansible案件がメイン
  • 戦う階層を変えること = NoOps
    • UncomfortableなOpsをやめて一つ上の階層で戦う
  • これまで
    • 安全に確実に動かす、コストを最適化する
    • ずっと変化せずに減価償却期間中ずっとそのまま
  • そのままにはできない
  • どうすればComfortable?
  • 戦略
    • 状態を作る
    • クラウドファースト、コンテナファースト、自動化ファースト
    • 状態に行き着くためのギャップを抽出
    • 解消できるギャップ、できないギャップを整理
    • 到達可能なToBeを決める
  • バリューストリームマップで現状を可視化
  • すぐ解消できるもの、将来的にやること、やらなくていいこと に分類する
  • プロセスの再定義、自動化実装

  • 自動化の方法

    • 置換 -> AnsibleのPlaybook化とか
    • 機械化 -> 別の人に実行してもらう
    • 連結 -> 複数の機能をつなげて実行できるようにする
  • 環境は変えてもいい

なかなか楽にならない証明書の話 各パブリッククラウドの証明書周りの自動化についてお話します

  • しばやん さん @shibayan

  • 12ヶ月に一度くらいの頻度なので忘れがち

  • こういうのこそ自動化すべき
  • 自動化されない理由

    • 手順がむずい: CSRの作成、ドメイン所有の確認、配置場所がWebサーバによってまちまち
    • 認証局APIとか提供してくれてない
  • 更新を忘れると警告画面が出るしやばい

  • 常時SSLが当たり前
  • HSTSでHTTPSの使用を強制されているともう証明書治すしかない
  • Azureも過去に更新に失敗して11時間証明書が失効していたことも

  • ACM

  • 外部の認証局とパートナーシップを結んでいる
    • Azure Key Vault / App Service Certificate
  • Let's/ACME

  • Azure Key Vault

    • DigiCert/GlobalSignと連携
    • アカウント情報を入れておく
    • 事前に登録したポリシーに従って更新してくれる
    • 自己署名証明書も作れるらしい
  • App Service Certificate

    • GoDaddyと連携
    • Azure Potalから購入
    • 有料
  • Let's Encrypt

  • キー管理

    • HSM: hardware security module
    • AWSはKMS/CloudHSM
    • GCPはCloudKMS
    • AzureはKeyVauld
  • 結論としてはACM最強

  • Azureは無料で使えるSSL証明書がない
  • AzureとLet's Encryptの連携があれなのはパートナーに配慮した結果...?

  • Let's Encrypt感謝(大事)

  • Key VaultはCSR作成機能がある

  • キーの漏洩の心配がない