【勉強会】NoOps Tokyo Meetup #3
20181207_NoOpsMeetupTokyo#3
AWSのマインドセット
光り輝くTBD（仮）
AWS Japan 西谷 圭介 さん
Undifferentiated Heavy Lifting
- 付加価値を産まない作業のこと
- 認証認可って必要だけどそれ自体は価値を産まないよね、とか
プロダクトを差別化するのはソフトウェア
Amazonのアプローチ
→Microservices/DevOps
組織体制
Two-pizza Teams
- 作るものに対する全てを負う
- ロードマップ／開発／運用／カスタマーサポート
- 独立性高く、個別に、全部やる
- QAもTwo-pizza Team
- オンコールもTwo-pizza Team
Opsは何をするのか
- Opsというポジションは存在しない
- SREもいない
- 各チームに各役割に集中するメンバーを置く
チームの水準を高く維持するために
特にテストを重視している
テストで大事なこと
- Automate Everything
- テストをしやすいようにアーキをデザインする
運用で大事なこと
- Automate Everything
- Two-pizza Teamsは人が少ないので自動化大事
まとめ
運用ゼロは幻想、NoOpsは難しくてもLessOps
テスト自動化／自動回復
Serverlessの自動化と自動回復のためのアーキテクチャ
Microsoft 牛尾剛 さん
www.slideshare.net
今日のキーワード
- サーバレス
- 自動化
- 自動回復
Markdown Translator
テストピラミッド
- E2E/ITは、SmokeTest、HappyPath、いくつかの異常系、ぐらいにしておく
- UTが80%くらい
テストがないコードは存在しないと同じ
よいユニットテストとは
- リグレッションエラーを検出できる
- False Positive（モックが本来落ちないといけないところで落ちない、とか）の割合が少ない
- 素早いフィードバック
- メンテナンスコストが低い
- シンプル
Heaganal Architecture
- アリスターコバーンが提唱
- Domain 素のクラス
- ApplicationLayer 他との会話
- その周りにいろんなサービス
モックをどこでやるか
- できるだけDomainから離れた、境界をモックにする
- なるべく自分の書いたコードをテストするようにする
- ApplicationLayerにロジックを書かず、Domainにロジックを書く
- Contorollerにロジックを書かないイメージ
- Domainはモックもなくテスト可能だから
- ネットワークコールとかどうしようもないところだけモックにする
DIとWrapper
- モックしたいクラスには絶対Interfaceをつける
- Interface単位でモックにできるから
- ライブラリでInterfaceがない時は、Wrapperで包む
テスト可能な設計のためのTips
- Domain Object
- コラボレータとの接点をMockする
- Bindingsを使う
- 単一責務の法則 一つのクラスやメソッドの役割は一つにする
- インターフェースの導入、だめならWrapper
- リポジトリパターンを使う
自動回復のためのアーキテクチャ
Durability Functions
回復させたい単位をなるべく小さく作ってリトライさせる
自動回復のためのポイント
- 単一責務の法則（Single Responsibility Principal）
- 冪等性
- リトライしたい単位で小さく関数化する
