Edited at

NoOps Meetup Tokyo #2 カンファレンスノート


イベント情報

NoOps Meetup Tokyo #2 - connpass


NoOps = No "Uncomfortable" Ops

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

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


NoOps Meetup Tokyo #1 カンファレンスノート - Qiita

第一回のカンファレンスノートはこちら


資料リンク集


オープニング/NoOps Japan 発起人 岡 大勝 @okahiromasa


MicroserviceでのNoOps戦略/鈴木 雄介 @yusuke_arclamp グロースエクスパートナーズ


  • NoOpsとは / 歴史経緯


    • ITサービスのライフサイクルを早くする(企画、実装、運用、利用)

    • 2001年 アジャイル


      • アジャイルソフトウェア開発宣言


      • 企画→開発 のスピードアップ



    • 2009年 DevOps



    • 2011年 NoOps



    • その後の議論


      • 2012年 Netflix / Ops, DevOps and PaaS (NoOps) at Netflix


        • カナリアリアリリース、アラート収集、Cassandra用運用ツール

        • DevOps/SREチームがこれらのツールを作成

        • 運用するための組織は存在せず,開発者は運用者と話す必要はない

        • 開発者を運用から開放し、セルフサービスツールを提供する




      • Why 2013 is the year of ‘NoOps’ for programmers [Infographic]


        • 90年代 データセンター集約

        • 2006 API(AWS)

        • 2011 SysOps(Puppet/Chef)

        • 2012 AppLifecycle(CloudFoundry/OpenShift)

        • 2013 NoOps(Heroku)





    • NoOps総論


      • 運用作業の自動化とツール化


        • ツール化するエンジニアがいる



      • 開発者はツールを使って運用作業を行う


        • 作る と 動かす の距離がなくなる



      • ツール化により役割分担が変わった


        • 機能要件だけでなく非機能要件まで

        • プログラマの役割が変わってきた





    • 2014年 Microservices


      • 先端的なウェブサービス企業が似たようなアーキテクチャスタイルを取っている

      • なぜMicroservices?


        • 目的:サービス全体を止めずに一部を変更する

        • 解決:変更発生単位にサービスとして分割し、APIで連携させることで変更時にサービス全体を止めない





    • MicroservicesとNoOps


      • Microservices にNoOpsは織り込み済み


        • 運用作業の自動化、ツール化は重要な土台

        • 「アプリを作る」から「サービスを動かす」へ



      • 全員が NoOpsを目指すべき



    • NoOps とは まとめ


      • 「サービス全体を止めに一部を変更する」ために主に「運用作業の自動化とツール化」を推進すること

      • 開発者にとっては「作る」から「作って動かす」へ

      • 「うちはAWSじゃない」「既存のツールが使えない」は思考停止





  • サービスを管理せよ


    • アプリとインフラを一体で管理する


      • 「インフラを用意して、アプリをインストールする」ではなく「サービスとして管理する」

      • PaaS


        • そもそも対障害性、無停止リリース機能を持ったPaaSを利用する

        • すごく便利だが制約に従う必要がある、実現できることと制約が比例する



      • コンテナ


        • ネットワーク/ミドルウェアを含めた構成のバージョン管理

        • ほぼ制約なし

        • コンテナ対応PaaSを利用すると便利



      • 発想の転換:動かす時にインフラ調達


        • 「インフラを用意してアプリを置く」ではなく「アプリを動かす時にインフラを調達する」

        • バッチサーバという概念はいらない、バッチジョブを起動するタイミングでインフラ調達する







  • ありがちな課題の解決


    • 固定IP、固定ドメイン前提になってる→動的対応する

    • エージェントが必要→エージェント不要にしていく

    • 設定ファイルで環境切り替え→設定をリポジトリ化

    • DB関連が手動→コード化



  • その先へ


    • コンテナオーケストレーション、サービスメッシュ

    • イベントソージング




ITインフラの NoOps を実現する戦略と方法論/中島 倫明 @Irix_jp レッドハット


  • NoOps = 戦う階層を変えること


    • 従来インフラではストレージ、サーバ、DB等と戦ってきた



  • 安全に確実に動かす、コストを最適化する、に加えて「変化への対応」という3軸目が重要に


    • 1度作ったインフラが変化するのは当たり前


      • パッチ適用、バージョンアップ、設定変更、リソース増減 …





  • 戦略的なアプローチ


    • 先に考えること:状態


      • どういう状態にするか、どういう状態になればComfortableなのか



    • 後で考えること:方法


      • どう作るか、どうやって実現するか





  • 戦略的な考え方とは



  • クラウドファースト、コンテナファースト、自動化ファースト

  • NoOpsへの戦略的アプローチ


    • モデルとなる状態を定義:他の成功者を参考にすると近道

    • その状態に行き着くために障害となるギャップを抽出

    • 解消できるギャップ、出来ないギャップ(法律とか業界とかの縛りなど)を整理して、ToBeを描く

    • ギャップ測定


      • バリューストリームマッピングで抽出・可視化


        • 理想的な環境ではどうなるか

        • 現状とのギャップ、障害となるものは何か



      • 今すぐできること、将来的にやること、やらなくて良いことを整理



    • 自動化の戦術


      • 置換:単純に手順を置き換える、

      • 機能化:サービスとして切り出して別の人に実行してもらう

      • 連結:小さな機能を連結して大きな機能を作る





  • アンチパターン:全部自動化しなといけない、一気通貫で自動化しなければならない、今の環境のまま自動化しないといけない


    • 戦略的:運用が発生しないアーキテクチャで始める

    • 戦略的:自動化しやすい環境を整える

    • 戦術的:簡単なやりやすいところから自動化してしまう

    • 戦術的:難しいもの、複雑なものをそのまま自動化する




なかなか楽にならない証明書の話/しばやん @shibayan


  • SSL/TLS証明書の管理がしんどい


    • 12ヶ月に一回位の作業

    • 認証局からのメールで期限を思い出したり忘れたり



  • DV証明書発行の流れ


    • 認証局にCSRを投げる

    • ドメインの所有を確認する


      • whoisに登録されているメールアドレスにリンク送信、指定されたTOKEN入のファイルをサーバに置く、DNSで指定されたレコードを追加するなど



    • 証明書が発行される


      • 中間証明書と一緒にサーバに配置したり、PFXにしたり





  • 自動化されない理由


    • 自動化が難しい作業ばかり:CSR作成、ドメイン所有の確認、証明書と秘密鍵の配置

    • 12ヶ月ごとなので、手動でもなんとかなっちゃう雰囲気(自動化のコストが割に合わない)

    • そもそも認証局が自動化前提の作りじゃない



  • 更新忘れると



  • 楽にしようとする動き


    • クラウドベンダが認証局をもつ:AWS Certificate Manager

    • 外部認証局とパートナーシップを結んでる:Azure Key Vault/App Service Certificate

    • Let's Encrypt を利用している/ACMEプロトコルの導入:GCP の Managed SSL、さくら など数多くの例



  • AWS Certificate Manager


    • ELB/ALB/CloudFront/APIGatewayで使える


      • パブリック向けの場合、ワイルドカード証明書も発行可能、マルチテナントのアプリケーションにも使いやすい



    • 自動的に証明書の更新を行ってくれる


      • 条件:ドメインが利用中かつSSL/TLSで外部からアクセス可能な場合

      • IP制限している場合は、メールが飛んできてURLを踏む必要がある(今までと同じく手動の作業が出てくる)



    • 無料



  • Azure Key Valt


    • DigiCert と GlobalSignと連携、予めアカウントを作る必要がある

    • 事前に指定したポリシーに従って更新してくれる

    • 自己証明書の発行もできる

    • おそらく有料



  • App Service Certificate


    • GoDaddyと連携している、AzurePotalから購入可能

    • 自動更新

    • 有料:1ドメイン$69.999、ワイルドカード$299.999



  • Let's Encrypt


    • ACMEプロトコルに基づいた自動での証明書発行


      • 公式のcertbotを使って管理可能

      • v2からはワイルドカードも可能



    • HTTPかDNSを利用してドメイン所有の確認

    • 無料で使える



  • ACMEプロトコルについて


    • 認証局が証明書発行に必要な機能を定義している

    • REST-API

    • 対象のドメイン全てに対してHTTPSかDNSで確認される


      • 特殊なファイル、もしくはTXTレコード書き換え



    • certbot が使えるケース


      • nginxやApacheを直接公開している場合

      • Let's Encrypt公式クライアントなので安心


        • 各クラウドのManagedDNSに対応(Azure除く)



      • Linuxのみサポート





  • 所感


    • AWS Certificate Managerが突出して便利

    • Let's Encrypt周りを面倒見てくれるManaged SSL良さ

    • Azureは無料で使えるSSL証明書がない



  • まとめ


    • SSL/TSL証明書管理は自動化できる(DVのみ)

    • AWSならAWS-CM、GCPならManagedSSLを使う

    • Azureはお金払うか、コミュニティ作成のIssuerを使う

    • Let's Encryptに感謝を