#ssmjp 2018年7月を聴講してきた記録

勉強会

運よく抽選で当選したので、7/24 に#ssmjp の７月会を聴講してきました。
業務で、ネットワークインフラに触れる機会が多かったので関連する勉強会で自身の不足している要素を見つけたかったのが、主な理由です。 この勉強会は connpass で参加募集しているのですが、倍率 2 倍強で、人気のある勉強会となっています。

同僚が抽選から漏れてしまったのですが、とても参加したがっていたので、せめてこちらの記事にメモを残そうかと思います。

前説 @tigerszkさん

  • 通称「ささみの会」
  • もともとはインフラ運用の勉強会
  • 「アウトプットしないのは知的な便秘」
  • ネタは何でもOK 「お風呂洗剤の話」をした方もいらっしゃった
  • Slack に 50 チャンネルあり。HP からリンク

DNS Summer Day 2018報告ー海賊版ブロッキング問題を中心にー 石田さん

  • DNS Summer Day 2018 の開催報告
    • なぜ権威サーバを立てるのか、fuzzing するため、とかいう話もあった。。
    • DDOS の話。
    • ID4me。ドイツを中心に DNS での認証が進んでいる話。
    • BIND 9.9。ESV 移行の話。9.11 へ。
    • 脱 BIND の動き。
    • インターネット上の海賊版サイトに対する検討会議が明日開催

「CloudFormation と FaaS のはざま - Kubernetes の設計思想を探る - 」 @koyhogeさん

  • インフラ運用の視点では巨大な yml は避けたいよね。
  • コンテナ+オーケストレーションが熱い
    • OS 実行イメージの単位で分離
    • 最近流行っているのは Docker + Kubernetes(k8s) 読み方はくーばんてぃす。元ネタは スタートレック。Borg
    • イミュータブル。一度作ったら、変更しない。変更せずに新しいものを作る思想。
    • 宣言的設定。あまったものは減らす、などあるべき物を定義する。
    • 自己回復する。コンテナが死んだら別のコンテナを自動で立ち上げる。
    • サービスの OSS 基盤として標準になりつつある。

      質疑応答

  • kubernetes はサポートが短くてどんどん先に行く思想と聞いている。
    • インフラ屋さんが手を出したとして、例えば3年後に変化についていけるものなのか。
    • 変化が速いというか仕様が頻繁に変更するという話はあるが、3年後なら大丈夫では。

『続 運用自動化、不都合な真実 ～ なぜコスト削減目的で運用自動化してはいけないのか』@tcshさん

  • AWS クラウドフォーメーションの人
  • 運用自動化で「工数削減いうな」 -「運用工数」が増えても価値が上がればいいのでは。
  • 運用工数の削減ではなく、効率化すべき
  • なぜ「コスト(OPEX)削減目的」がダメなのか。
  • 絶対的削減。キャッシュアウトの削減。
    • それ以外にできることがないときにやるもの。
    • 経営危機の際には有効
    • 現場の能力と選択肢も同時に削減されていく。「運用価値」の削減スパイラル。
  • 相対的削減。費用対効果の改善である。
    • 工数は増えるが、費用対効果も増える。
    • リソースを何も変えずに改善するのは「無理」
    • まずは「納期」を改善すると、目に見やすいので存在感を得やすい。
    • コスト削減を要求されたときは、「納期短縮」して条件闘争を。

『マインドフルネスのススメ』@_keihinoさん

  • IOT とか PoC の方。
    • 調身、調息、調念
    • ストレスフルな日常に瞑想を。
    • (全員参加型で瞑想していたのと、ひたすら笑っていたのでメモとれず。)
    • スピリチュアルな光景

『OPNsenseをUTMに入れて使う』@Alice_Youさん

  • NXG150 という UMT に OPNsenseを入れて使うという事例の紹介
  • @infra_imouto の中の人
  • 同人サークル Alicesystem
  • ネットワーク系同人誌書き
  • NXG150でたいていの OS が動く。
    • SEILx86 の動作も確認
  • C94 で postfix の入門本を出すかも。
  • OPNsenseって？

『「DNS浸透いうな」と言うけれど…』@goto_ipv6さん

浸透ってどこに？

  • アプリケーション？
    • いつまでキャッシュする？アプリ側で考えないといけないので、浸透するような実装はなさそう？
  • web ブラウザへ浸透？
    • Ff や Chrome はキャッシュを持っている
    • Chrome は保持しているキャッシュ情報を閲覧可能
    • DNS over HTTPS で Web ブラウザ自体が名前解決する仕組みは存在する。
    • 自身が解決した キャッシュを保持するなら...それは浸透といえそう？
  • OS へ浸透？
  • フルリゾルバ？
    • インタラクティブな問い合わせをする。
    • キャッシュを持つことがおおい。
    • だがしかし要求を受けないと保持されないので「浸透」ではない
    • ネガティブキャッシュによって、情報を保持しているのに応答しない。よって、「浸透」ではない。
  • 権威サーバ
    • ドメインに関しての情報しか持たない。ゾーン転送を制御することもできる。よって「浸透しない」
  • ルートサーバ
    • (するわけない)
  • 既存の権威サーバが新しいサーバへの切り替え手順を間違えると、「DNS が浸透しない」状態となる
    • 移譲元への変更申請と、権威サーバに対するドメイン名の変更は別。
  • レジストリとレジストラの話。
  • 利用しているアプリがに他人の情報が浸透してきてたら怖くないですか？
    • 浸透先なんてそもそもいない。 -「浸透」を待たなくても、フルリゾルバになりきって dig で interative な問い合わせをしてみましょう。
    • ネガティブキャッシュなどに関しては先生の資料で説明しているので、読んでください。

資料

ssm.pkan.org

感想

DNS のふるまいを中心に話していただいた「浸透」回りの話は大体理解できた一方、「Kubernetes」あたりで話された近年のトレンド回りの話題に弱いことに気づきました。
もう少し、アンテナを広げていろいろな新しいツールに手を出してみようとおもった。 一方、非常に興味深かったのが、運用自動化に関しての講話で言及されていた「絶対的削減」と「相対的削減」の違いは、普遍的な仕事に通ずるところがあると思っていて、長期的なキャッシュアウトを減らしたいのであれば、その取り組みを行う上で短期的なオーバーヘッドは許容せねば、かならずどこかにひずみを生じさせてしまい、状況次第では組織の弱体化につながりかねない、というのは同じかなと。

「工数削減とは、キャッシュアウトを減らすことではなく、効率化であるべき」を考えの中心においてみたいと思います。