【勉強会メモ】Mix Leap Study #40 - Spring BootベースのDDDサンプル徹底解説！
- 日時：2019/04/04(木) 19:00 〜 21:30
- 場所：ヤフー株式会社 大阪グランフロントオフィス
プラットフォームとプロセスを活かすための設計
遅刻したので聴けませんでした。
たかが命名、されど命名
山崎 好洋 さん
思いやりのある命名をしよう
命名にどれだけ時間を使っているか？
- クラス名
- メソッド名
- 変数名
命名にこだわらなくても動く
なぜ名前をつけるか？
- 自分の書いたコードを理解するため
- 他の人にも（未来の自分含む）
- 全貌の把握に時間がかかる
- 変更・削除の判断
- 機能追加・変更に臆病
⇒サービスの成長鈍化
良い命名
- 仕様のどの部分を表現しているのかがわかりやすい
- 探しやすさ
- 理解しやすい⇒こっちの話
理解しにくい命名は？
- 仕様が理解できていない
- 単語で命名しようとしている
- クラスやメソッドがいろんなことをしようとしている
名前を考える
- パターンを覚える（Dtoとか）
- 文法をチームで決める（createとか）
付けちゃダメ
- Manager
- Util
Howを考えて分解する
判断する方法
- 他の人にコードレビューしてもらう
- 時間をおいてセルフレビュー
伝える方法
- 命名
- コメント
- ドキュメント
コードとの距離
- 命名のほうが近い
- コードとの距離が遠いと情報の鮮度が落ちる
いつ、だれに、どれだけ伝えたいか？
思いやりをもった命名を
Spring Bootベースのドメイン駆動設計のサンプルコード徹底解説
増田 亨さん
ドメイン駆動設計サンプルコードの徹底解説 from 増田 亨
www.slideshare.net
- Spring Boot
- MVC
- MyBatis
- Thymeleaf
なぜ作ったか
- 実アプリ並の具体例がほしかった
- コードがいちばん具体的に伝えることができる
- 質問が具体的になり、考え方の違いがはっきりする
何の具体例？
ソフトウェアの核心にある複雑さに立ち向かう
ドメイン駆動設計
- 関心の分離の工夫
- モジュール構造の工夫
複雑さに立ち向かう3つのキーワード
要点を絞り込む
何の具体例か？
- ビジネスルールが複雑さの原因
- 計算のモデリング
- 型指向でプログラミングする
関心の分離の工夫
- 計算（ビジネスルール）を実行するモジュール群
- データを入出力するモジュール群
この2つを徹底的に分ける
同じモジュール（ソースファイル）に、計算と入出力を書かない
モジュール構造の工夫
手続き的な入出力モジュールに計算を埋め込む（トランザクションスクリプト）
↓
計算を型（値の種類）でモジュール化して組み合わせる（ドメインモデル）
サンプルアプリケーションの概要
- 時給ベースの給与計算アプリケーション
- 背景にあるビジネスルール
- 計算に必要な事実
- 勤務実績（いつ、何時間）
- 給与計算ルールを62種類の型で記述
- 本日は、給与（Payroll）型を中心に説明
給与型を中心にレイヤごとに説明
- ドメイン層
- アプリケーションそう
- データソース層とデータベース
- プレゼンテーション層
ビジネスルールを記述する3要素
- Fact
- 事実の表現
- Rule
- Factを使った計算や判定ロジック
- Goal
- 知りたいこと
ドメイン層の設計の考え方
計算モデルが息づく場所
- mdoelパッケージ
- typeパッケージ
⇒modelに置くか、typeに置くかは書いてみながら判断・調整
型指向のプログラミング
- wiki：設計ガイドライン · masuda220/business-logic-patterns Wiki · GitHub
- スライド：ドメイン駆動設計 本格入門
- 書籍：現場で役立つシステム設計の原則
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
Plain Old Java
60種類の独自の型を9つのパッケージに整理 特定のパッケージに矢印が集まっていないかなどをチェック
- 区分ごとのロジックの整理
- 区分に依存するロジックの視覚化
アプリケーション層
ビジネスの記述を独立させる
- ビジネスルールの記述をビジネスロジック層に移動
- 理論的にはアプリケーション層はとてもシンプルになる
- 現実にはアプリケーション層に複雑な記述が残りやすい
アプリケーション層の要素分解
- Factoryサービス
- 計算モデルのインスタンスを生成⇒データソース層で事実を元に生成
- Queryサービス
- 計算結果を返す⇒プレゼンテーション層へ
- Operationサービス
- 計算結果を記録／通知⇒データソース層へ
※ 3つに分けるかどうかは設計の考えどころ
データベース層とデータベース
- 計算モデルとデータモデルのマッピング
データソース層設計の考え方とやり方
- データの入出力の実装
- MyBatis SQL Mapper
- SELECTの実行→計算用のオブジェクトの生成
- 記録すべき事実をもったオブジェクト→INSERTの実行
- ContractDataSource
- Thymeleaf
データベース設計の考え方とやり方
- プログラムからは独立したデータの記録と参照の仕組み
- イミュータブルなデータモデル：事実の履歴＋最新状態
- 事実の履歴→INSERTオンリー
- 最新状態の導出結果→DELETE/INSERT
- NO UPDATE
- NO update_atカラム
- 制約指向
- データ型
- NOT NULL制約、外部キー制約、ユニーク制約
- とことん日本語
プレゼンテーション層
- 計算モデルのビュー
- ドメインオブジェクトをそのまま表示（naked objectパターン指向）
- Spring MVC
- Direct Field Access → WebDataBinder#initDirectFieldAccess()
- Thymeleaf
- Semantic UI
- PayrollControllerクラス
- temples/payroll/list.html
※参考
www.slideshare.net
JIG
irof（のざきひろふみ）さん
三層＋ドメインモデルのアーキテクチャで実装されたコードから分析・設計情報を出力するツール
- ドキュメントは一時的に見るもの
コードによる設計のためのツール
依存関係の逆転
- ドキュメントからコードではなく、コードからドキュメントに
- 意図を込めてコードを書いて意図が表現されたドキュメントを見る
コード→ドキュメント→設計
※設計へのフィードバック
- コードがドキュメントに見えればコードで設計できる
- 良いコードはドキュメント化が容易
前提条件を加える
三層＋ドメインモデル
not UML
- 汎用的なクラス図などは既存ツールにまかせて良い
- ビジネスルールが際立つものを
- 意図を込めたところを読み取る
- 想定外の作りはいびつに見えればよい
実現方法
コードを読むとき、いつも同じ
- ところを見ている
- たどり方をしている
- 絵を描いている
コードの理解をモデリングできれば
- 複数の分析設計ドキュメントを作成できる
- 設計へのフィードっバックを早められる
使い方
※参考
【読書メモ】マインドセット「やればできる! 」の研究
- 作者: キャロル・S・ドゥエック,今西康子
- 出版社/メーカー: 草思社
- 発売日: 2016/01/15
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
会社で社長から紹介されたので図書館で借りて読んでみました。ちなみに図書館に置いてあったのは旧版ですが、内容はほぼ同じだと思います。
「やればできる!」の研究―能力を開花させるマインドセットの力
- 作者: キャロル S.ドゥエック,今西康子
- 出版社/メーカー: 草思社
- 発売日: 2008/10/27
- メディア: 単行本
- 購入: 5人 クリック: 48回
- この商品を含むブログ (41件) を見る
マインドセット
著者のキャロル・S・ドゥエック博士によると、マインドセットには人の知能は固定的であると考えるマインドセットと、努力しだいで知能も成長すると考えるマインドセットの2種類があるとされています。そして、そのマインドセットの持ち方しだいで「学習意欲や学習行動、ひいては成績に大きな違いが出てくる」と言われています。
固定型マインドセット（固定的知能観）
- 自分の能力は石版に刻まれたように固定的で変わらないと信じている
- 能力を固定的にみる世界では、努力は忌まわしいこととみなされる
- 人間を学習から遠ざけてしまう
成長型マインドセット（拡張的知能観）
- 人間の基本的資質は努力しだいで伸ばすことができる
- 能力は伸ばせると考える世界では、努力こそが人を賢く、有能にしてくれる
どちらか一方ではない
ほとんどの人が「両方のマインドセットを併せ持っている」とのことです。ただし、「能力は伸ばせると信じている分野の能力は、実際に伸びていく」の述べられています。実際に子どもたちに難しいパズルの問題を与えた実験では「能力をほめると生徒の知能が下がり、努力をほめると生徒の知能があがった」ようです。
自己洞察力
成長型マインドセットの人は自己洞察力も優れているようです。理由は次のように述べています。
学ぶことに重点をおくとなると、効果的な学習をするためには、今現在の能力についての正確な情報が必要になる
一方で固定型マインドセットの場合は以下のように正確な自己洞察ができなくなるのです。
もう伸ばしようがない能力が値踏みされていると思うと、どうしても受けとめ方がゆがんでしまう
対人関係におけるマインドセット
人間関係について考える場合にはさらに2つのことが関わってくる
対人関係では相手のマインドセットと、お互いの関係性のマインドセットの2つが重要になってきます。なぜなら、「人間関係は、育む努力をしないかぎり、だめになる一方で、けっして良くなりはしない」からです。お互いに成長型マインドセットで関係を築いていくことがより良い関係性が築けるのです。これは組織論やチームビルディングの考え方にもつながるように思いました。
生徒や子どもへのマインドセット
子どもを甘やかして、好き放題にさせているわけではけっしてない。高い基準を設け、どうすればそこに到達できるかを教えようとする。そして、あくまで子供を尊重しつつ、公正で思慮に富んだ判断に立って、だめなときはだめと言う。
このあたりは「褒め方」の技術に通じる部分もあります。具体的な行動や考え方を褒めるというのはよく言われることです。生徒や子どもだけでなく人材育成にも応用できるマインドセットです。
学びにフォーカス
成長型マインドセットによって、現時点の能力を受けとめて楽しみながら学習する行動につながると言えます。読みながら「仕事は楽しいかね？」に書かれていることにも通じると感じました。
変わるということ
理論は理解できたとしても、実際にマインドセットを変えることは簡単ではありません。マインドセットを成長型変えていくために本書では「信念」という言葉を使っています。「人の能力は固定で変えられない」という信念を「努力しだいで能力を伸ばせる」という信念に変えていくのです。本書ではそのためのヒントが事例とともに多数紹介されています。
私は今でも、何かうまくいかないことがあったり、期待どおりに事が運ばなかったりすると、一瞬、自分はもうダメだと思ってしまう。（中略）「変わる」といっても、外科手術をウケたように変わるわけではない。たしかに変化は起きていても、摩耗した膝や腰の関節を新しいものと取り替えるように、古い信念がすぐに一掃されるわけではない。古い信念がまだ残っているところに、新しい信念が芽生え、それがだんだんと強くなるにつれて、今までとは違った考え方や感じ方、ふるまい方ができるようになるのである。
本書や関連する情報を追いかけて「成長できる」と信じて行動することで成長型マインドセットが自分に根付いていくのだと思います。以降に読書の過程で得た情報をいくつかリストアップしておきます。
参考情報
必ずできる！― 未来を信じる 「脳の力」
実はこの本に書かれていることの概要は著者自身がTEDで述べています。10分ほどの動画なのでこれを観てから本を読むと理解しやすいでしょう。
The power of believing that you can improve | Carol Dweck
ブログや記事
【勉強会メモ】Mix Leap Study #37 - 世界の最先端量子コンピュータ技術と機械学習
- 日時：2019/03/19(火) 18:30 〜 21:30
- 場所：ヤフー株式会社 大阪グランフロントオフィス
最先端への興味だけで参加してきましたが専門外のためサッパリわかりませんでした…しかしせっかく取ったメモなので残しておきます。わからないなりに興味深い内容ではありました。ハンズオンは量子コンピューターSDKのBlueqatを使いました。量子コンピューターのソフトウェア開発がPythonライブラリで簡単にできることだけで驚きでした。とはいえ今回やったことはHello, worldレベルの「基礎のキ」だとは思います。今回のハンズオンと同様の内容は下記サイトから誰でも試すことができます。
第1部：「2018年末までの量子コンピュータ業界／技術の総括」
清水 徹（ヤフー株式会社）さん
※途中から参加しました
エラー訂正の壁
Quantum Volume
- コヒーレン時間の向上
- 量子的な重ね合わせをどれだけ保っていられるか
量子コンピューターのYES/NO
量子コンピューティング入門
量子ビット、qubit
- コインの裏表みたいな2つのうち必ずどちらかの選択肢・状態をとるもの
向こう5年くらいの応用分野
開発
- Forest SDK
量子アニーリングがチョットワカルようになる記事 - Yahoo! JAPAN Tech Blog
第2部：「今後の量子コンピュータの展望 ～機械学習への活用～」
湊 雄一郎（MDR株式会社 CEO）さん
ゲートの基本
- 量子ビットの初期化
- ゲート演算
- 測定
量子シュミレーション
- シュレーデンインガー方程式
量子ゲートとVariational method
- 現在の主流
- 量子計算機で小さい計算を行って既存計算機で足し合わせ
- 最適化計算を既存計算機でやる
実用化
自動車メーカー
- VWがダントツ
- 自動車の経路最適化
- コスト関数と制約条件
量子機械学習
- Variational Quantum Eigensolver（量子ゲート）
- ハイブリットで計算
Rigetti
- 量子ボルツマンマシン（量子アニーリング）
- NASA Qboost（量子アニーリング）
- Matrix Factorization（量子アニーリング）
- Anneal, Pause and Quench（量子アニーリング）
- Xanadu Pennylane
- hybrid computation
- HHL
- 連立方程式を高速に解く
- NISQ素因数分解
- Quantum Neuron（量子ゲート）
- 量子オートエンコーダ（量子ゲート）
- Qvector（量子ゲート）
- Vanqver（量子ゲート）
- 量子GAN
みんなやりたいこと「少ない量子ビットで大きなデータを効率的に扱いたい」
Blueqat SDKを用いたハンズオン
今回の発表資料とハンズオンの資料はSlackに公開されている。下記connpassグループからSlackへ参加できる。
【勉強会メモ】自己組織化されたチームへの道筋
- 日時：2019-03-18（月）19:30 - 21:30
- 場所：株式会社ラクス 大阪オフィス
いつもお世話になっているDevLove関西さんですが、今回は弊社にお招きして開催して頂きました。いつも様々な学びを頂いているのでささやかながらお返しできて嬉しいです。
今回は「自己組織化」をテーマに2つの発表を聴きました。1つ目は自己組織化されたチームが得られるメリットにフォーカスした内容で、2つ目はそもそも自己組織化って何だろう？という問いかけを与えられる内容でした。それぞれ違った切り口の発表で、一度立ち止まって「自己組織化」について深く考える機会を得られたように思います。スクラムガイドにも書かれているように、自己組織化されたチームを目指すことは大事なことではありますが、手段が先行してしまうと却ってチームを壊してしまう危うさもあると感じました。
Managerを求められながら尖ったEngineerであるために自己組織化チームに挑む
藤井さん
- ある程度のキャリアを積んだエンジニアにマネジメントを求めることは普通にある
- 組織構造があればマネジメっとは必須
- 経年でいつかスポットが当たる
- 次第にマネジメントの楽しさを覚える
- 気がつくとコード書いていない
コンテキスト
- 組織の責任者
- 課長という職責
- 初級管理者
- 部下は数名
- とあるサービスの開発・運用
- サービス開発のためにプロジェクト立ち上げ
- プロジェクトチームには社員以外も加わっていた
- スクラムを取り入れていた
初級管理者
- 係長、主任、主査、リーダー
- 部下・後輩に対する指導力
- 担当業務について高い専門能力
- 幹部候補生
初級管理者の3つのタイプ
- マネジメント中心型
- バランス型
- 専門能力中心型
どれに向いているとかではない
- マネジメント中心型でも専門能力を高める努力は重要
- 自立心を持つ
- サービスの開発運用で成果を出す
仮説を立てる
チームが自己組織化されていれば自分のエンジニアリングを損なわずに結果をだすことができるのではないか？
自己組織化チーム
作業を成し遂げるための最善の索をチーム外からの支持ではなく自分たちで選択する （スクラムガイド）
HRTの原則
類似性と相違性のバランスの上に作られる
ELASTIC LEADER SHIP
- 作者: Roy Osherove,島田浩二
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/05/13
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
Management 3.0
自己組織化チーム＝ほったらかしできるチーム？
自己組織化チームに向けて
権限を与える制約を整える
- 安心
- チーム自身が権限について安心できる
- スコープ
- 自発的に動ける範囲を確保する
- 自由な立場
- 自由に立場を変えられる状況を作る
実際に取り組む
- 透明性
- タスクはPull
- モブプログラミング（安心、スコープ、自由な立場）
透明性
- プロセスの用語を参加者全員で共有
- 作業する人とそのインクリメントを検査する人が「完成」の定義を共有
- 自分たちも見えていないと説明できない
- スクラムイベントをきちんと計画通りに実施
- 見積もりは相対見積もりと時間見積もり
- POの安心感と自分たちの安心感
- デイリースクラムの司会を当番で回す
- 問題をあえて放置することで以外な活躍をする人がチームから出てくる
- デイリースクラムは毎日いろいろな工夫を凝らせる場であり取り返しが付きやすい
タスクはPull
- 担当者を割り当てることをすると進捗把握することになりがち
- タスクは場に浮かびあがっている状況をつくる
- タスクを宙に浮かすためにタスクのWhy What How
モブプログラミング
- チームの共感認識を築いていくのにとても良い
- 進捗について自信を持てる
- 相互に良い意味で監視
- モブプロを取り入れなかった場合、各個人のタスクを把握し続ける必要が出てくる
任せる領域
- 自然と特定の分野のプロが生まれてくる
- プロを軸にするノリが生まれる
- プロに弟子入り制度をつくる
- うまく弟子が育ってきたらその弟子を軸に置く
- 流れを回す
結果どうだったか？
- 自身が組み込まれていなくても自走するような流れにすることができた
- スクラムイベントには参加
- マネージャー業をしている間もチームが自走
- 自分もスポット的にタスクをPull
- 全体を俯瞰する視座を持つ
自身の領域を確保する信用を獲得していくことから
自己組織化についてなにか話す
@spring_aki さん
自己組織化ってなんだろう？
- どういう状態
- そもそもなぜ自己組織化するか？したいのか？
※私が議論した内容
- ひとつの生命のように行動できる組織 - 誰かが欠けてもカバーできる - 自主的にリーダーシップを取れる
- 自己＝自分たちで
- 組織的な動きをする？
ひとりならどうか？
- 自己組織化とはいわない。自律的であるとはいえる
自己組織化とは
- 自律的な行動を取れればいい？
- 自律的なチームとは？
人にフォーカス
- 人と一緒に働くにはその人についてのことを知らなければ
- まずは知らないということを知る
互いと自分を知る
- なぜ知るのか
- 相手のことをよく考えないとうまくコミュニケーションとれない
- モチベーション
- 喜怒哀楽のトリガー
- 考え方、自分が何を考え、なぜそう考えるのか
- 価値観
- こんなとき自分ならこうする、ケーススタディ
⇒これを持ち帰ってやればうまくいくわけではない
これらを知りながら自分のことも知る
自分たちの働き方に合意する
- 日々の過ごし方、働き方
- 取り組む姿勢
- ルールではない
自分自身にオーナーシップを持つ
- 所有権、所有者、責任感、当事者意識
- 責任が一番近い？
- 自分自身の生き方、行動に自分で責任を持てる選択
- なにかするのもやらないのも選択、できないのは誰かのせいでもない
自分から変わる
- 自分がコントロールしたいだけってことはないか？
- 優越の箱に入っていませんか？
- 「まだまだだよねー」を１回やってしまうと、次もそんなつもりない発言も相手にフィルターがかかってしまう
- 自分の内面を探索して人に伝えるのは難しい
- そもそも自分が気づいていない思い込みに気づくことが難しい
リーダー、マネージャ、管理職のみなさんへ
自己組織化させるためにはどうしたらいいか？と思ってませんか？
- 自分自身が学び、成長する
- 権限委譲し、支援する
- 相互リスペクト
「任すからやっといて」⇒権限委譲？
- どれだけ権限委譲しているか？
- 権限委譲された人は自由に動けている？
- 権限委譲された人は困っていないか？
HRTの原則
- 上司部下関係なく相互にHRTの原則が守れているか？
- あらゆる人間関係の衝突は謙虚・尊敬・信頼の欠如によるもの
試してみることに、失敗はない
- 人は失敗を通じてしか学ばない
- 失敗を経験し、自ら変わろうとする
- 試行と学習がセットで繰り返し行われるとき、大きな推進力が得られる
Have fun
- 楽しむ
好奇心は簡単に死ぬんやで。あんたが殺したんや。
自己組織化ってなんだろう
- どういう状態？
- そもそもなぜ自己組織化するか？
- なぜ自己組織化したいか？
【勉強会メモ】Cloud Native Kansai #02
- 日時：2019/03/15(金) 19:00 〜 21:30
- 場所：エムオーテックス株式会社 – MOTEX Inc.
Kubernetes and Cloud Native Products
※遅刻したため聴けませんでした…
30分でわかる Google Kubernetes Engine
Container@Google
Googleは毎週40億のコンテナを起動
Borg
- クラスター管理システム
Large-scale cluster management at Google with Borg
- BorgからKubernetes
- Borgの開発に参加していた開発者がk8sへ
What's GKE
Simple to Start
信頼性
- Auto Repairing
- 故障したり問題のあるNodeを自動でリプレイス
- Auto Upgrade
- Regional Cluster
- マスターを同一リージョン内の3つのゾーンで持つ
- Regional Persistent Disks BETA
可用性
- Pod・Node双方に対して水平・垂直のスケーリング機能
- HPA:Podの水平スケーリング
- VPA:Podの垂直スケーリング
- CA:Nodeの水平スケーリング
Integration
Other Feature
- Private Cluster
- Public IPを持たないNodesを利用可能
- Authorized Network
- Firewallで許可されたネットワークからのみアクセス可能
- Shared VPC
- 異なるプロジェクトあkんで同じVPCにワーカーノードを配置可能
- Container Native Load Balancing BETA
- HPPTS(S)ロードバランサーから直接PodのIPを参照
- double-hop問題を解決
- GKE On-Prem BETA
- オンプレミスのクラスたをGoogle Cloud COnsoleから一元的 に管理
- Cloud IdentityかオンプレミスのIdpを使う
Webアプリ開発向けゆるふわDocker使いがCloud Naive開発に必要なetc.
www.slideshare.net
おすすめ本
Twelve-Factor Appのおさらい
Cloub Native
- 近代的でダイナミックな環境
- スケーラブル
- 組織
変化の激しい環境下でスケーラブルな開発を行うための能力を組織にもたらす
- 本当に必要ですか？
- 頻繁に変化が求められていますか？
- 1日に10回20回リリースしたい？
「とりあえず導入」はやめたほうがいい
今までPerlやRubyで開発していた人がSclalaやHaskellで開発するぐらいインパクトがある
- 覚悟、同士（3人以上）と信頼貯金
とはいえキャッチアップしておきたい
- まずはコミュニティに参加
- プロダクトのコンテキストが変わるので、適している設計がある
- CNの定義としてマイクロサービスをアプローチの代表例にあげている
- 分散システムを目指すことになる
Cloud Nativeにシステム構築するには？
Design patterns for container-based distributed systems
※参考
コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ - kakakakakku blog
コンテナベースの開発向けデザインパターン
Designing Distributed Systems EZ-Book（Azure）
日本語約が4/19に発売 分散システムデザインパターン
分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計
- 作者: Brendan Burns,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/04/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
BredanさんのGithub
Sidecar Pattern
- 共有Volumeを中継してSidecarが主コンテナを補助する
Ambassadors
- 主コンテナの変わりに通信を肩代わりするコンテナを配置
- 利点
- Appは自分の責務に集中
- 通信はAmbassadorに丸投げ
Adapters
- Ambassadorとは逆にコンテナグループから外部に対してメトリクスをエクスポート
- Adapterはモニタリングのみ行う
- モニタ対象となるAppは複数でもよい
Replicated Load-Balanced Services
LBを軸にしてその先を縮退
Sharded Service
レプリカじゃなくてシャード、つまり、分割
- 分割によって均等に分散
Scatter/Gather
- 散布/収集
- リクエストをRootNodeに投げ
- 散布、収集
Functions and Event-Driven Processing
- FunctionはFaaSと考える
- リクエストに装飾しながら処理を加える
Ownership Election
- オーナー選出のみを専門で行うコンテナを配置することでアプリは自分の責務だけを果たす
- PaxosやRAFTのような分散合意アルゴリズムを使う
Work Queue Systems
- 並列に大量の処理を実行する
- いわゆるバッチ
Event-Driven Batch Processing
- 入力が派生したりFilterされるなどして出力が作成されるワークフローシステム
Coordinated Batch Processing
- 分割した出力を一定ルールに基づいて集約する
どこから始めるか？
Cloud Native Trail Mpaを参考に段階的に始めていく
開発スタイルの再検討
- GitOps
※参考
GitHub Appを使ってGitOpsする - Qiita
どうやって始めるか？
- Rancher Labsの有償サポート
Datadog ここ掘れワンワン 春の陣
Datadogでコンテナモニタリングしよう
- リアルタイムのパフォーマンス可視化
- 強力なアラート
- 履歴の分析
サービスのかどうをモニタリングするための三本柱
- Trace
- Metrics
- Logs
依存関係やボトルネックを可視化
- 環境構築にかかる時間短縮
- 環境依存のエラーが減って開発効率向上
- 簡単に環境構築で手軽に検証
- デプロイやロールバックが楽になった
クラウド時代のモニタリングのポイントは？
ペットではなく家畜
Tag
- メトリクスに付帯
- フィルタリング／グルーピング
- カスタマイズ可能
何をどうやってモニタリング
- 基本的にはDatadogエージェントのコンテナを動かすと同一ホスト内の全コンテナとホストのメトリクスを取れる
タグをつける
- 環境変数に設定
- DD_TAGS
- DD_DOCKER_LABELS_AS_TAGS
- DD_KUBERNETES_POD_LABELS_AS_TAGS
コンテナはラベル管理必須
- どんなタグ？
- 迷ったときはまず以下のタグ
- source
- service
- env
- role
k8sのモニタリング
- Node Pod ReplicaSet Deployment DaemonSet問うの状態
- NodeごとPodごとコンテナ事のリソース使用率 など
マイクロサービスのトレース
- 分散トレーシング
- X-Datadog-Trace-Id
- 外形監視
- GAになった
- サービスを外側から監視
複数の拠点から任意のサイトやAPIエンドポイントにHTTP(S)リクエストを送信して監視
DockerからKubernetesへのシフト
www.slideshare.net
状況に応じた構成
- Docker/docker-composeでだいたいやりたいことができる
Dockerからk8s
Compose on k8s
どこで使える？
VUIエンジニアが考える「VUIでKuberenetes」
- デプロイ後に急に嫁におつかいを頼まれてお使い中にポッドを確認したくなった
- 料理中にふとポットの数を増やしたい
- Alexaなら自発的な会話が再生できる
コンテナの疲れをk3sとRemoで癒やした話
コンテナ疲れ
- 技術がてんこ盛り
- チャレンジングで楽しみたいけどToo Match
k3s
- Lightweight Kubernetes
- ARM対応
コンテナの疲れはコンテナで癒やす
- ラズパイ
- Nature Remo
温度、湿度、照度
