NoOps Meetup Tokyo #3に行ってきた

noops.connpass.com

さて、久しぶりにソフトバンク本社へ。サイオスビルの入口前にある古川橋バス停から新橋行きに乗って新橋五丁目で降りてちょっと歩く、G-Suiteでオシッコのひっかけ合いしてたときには何度も行き来して慣れた道のり約30分。今日の目的、NoOps Meetupに参加してきました。イベントには直前水曜日に登録したのではじめ補欠だったのだけど、今日になって朝からどんどん繰り上がって昼すぎには参加できるようになりました。某からリクエストもあったのでセッションのメモを貼っておきます。メモは今回も時系列ではなく聴きながら内容で上下整理しながらまとめたもの。

西谷さん from AWS

  • Opsは悪なのか?
    • Undifferentiated Heavy Lifting (本質ではない作業)
    • プロダクトを差別化するのはソフトウェア。その他のセットアップなどの作業をなくす
      • コードをなるべく書く環境を作る
    • 単一目的のサービス、HTTPSAPIのみによる通信、お互いをブラックボックス
      • -> Microservice/DevOps
  • Amazon流のサービス開発。Two-Pizza Teams
    • 2枚のピザで足りるような、少数精鋭チームが効果的
    • 作るもの全てに責任をもつ。
      • ロードマップの作成
      • 開発
      • 運用とカスタマーサポート
      • You Build it, you run it.
      • QAもオンコールもチームの中でやる
      • チームには権限が与えられていて、多くの自由が認められている
    • チームの水準を高く保つ
      • Hiringも各チームで行う。ヘッドカウントを持っている。
    • テストで大事なこと。
    • 運用で大事なこと。
      • Automate Everything! 自動化が重要。
      • 運用ゼロは幻想。NoOpsは難しくとも、LessOpsはできる。
      • LessOpsはServerlessでできる。
  • Our Leadership Principles、Amazonクレド
    • Customer Obsession
      • 全て、お客様から。単純な顧客第一主義には止まらない。
    • Ownership
      • 長期的な視野
      • DevOpsをやるのに大事なことがオーナーシップ。
    • Think Big
      • お客様に貢献するために、従来と異なる新たな視点を持つ。
    • Insist on the Highest Standard
      • 常に高い水準を目指す
      • Code Reviewをちゃんと行う
    • Deliver Result
      • 結果をだす。そのために重要なことにフォーカスする。
      • イテレーションを重視して、貯め込まずに早めにレビューを繰り返していく
      • Minimum Viable Product
      • お客様と一緒に製品を作る

牛尾さん from MS、Serverlessの自動化と自動回復(リトライ)

  • https://github.com/TsuyoshiUshio/MdTranslator
  • Serverlessとは
    • サーバー抽象化、イベント駆動、スケールアップ。
    • イベント -> トリガー -> インプットバインディング -> コードに書かれた内容 -> アウトプットバインディング
  • ユニットテストをとにかくちゃんとやる。
  • テスト可能な設計のためのTips
    • Functionにはインとアウトのバインディングのモックさえちゃんと作ればテストしやすい
      • ネットワークコールやストレージ呼び出しなどもモックで!
      • コラボレーターとの接点はモック、テスト対象がInterfaceを切ってればそれを自動で実装するライブラリがある。Interfaceを切ってなければWrapper経由の呼び出しにする
      • 他人のコードはテストしなくて良い
    • Functionの本体にはなるべくコードを書かない
      • テストがしやすいドメインオブジェクトにしてFunctionの外に出す
  • リトライ
    • APIの制限などで正常系がちゃんと動かないのが普通
    • 単一責務にすると、テストも単純になるし、自動リトライができるようになる
    • 冪等性を守るとリトライが楽にできる。
    • リトライ単位でのFunction設計が望ましい。

そのほか

  • NoOps = No Uncomfortable Ops
  • Toilを潰す
  • node-red: nodeで動くIoT向けフローベース。

感想

牛尾さんのユニットテストをしっかり書くというのは私も普段からの信条なのでとても参考になりました。テスト書くためにアーキテクチャを磨く、そしてテストTipsは、これからテスト書くときに勇気になる。これでいいんだって。

私がAWS Lambdaでポツポツ作る時は、Jestの高度なexpect機能とnockで手数なくできてる。特にnockが強烈。けど、DynamoDBのところはテストしてない。ここもServerless.comのオフラインプラグインを使うか、関数を引数に渡す&Jestモック機能か?

週末にちょっとトライしてみようと思う。