kakakakakku blog

Weekly Tech Blog : Keep on Learning 👍

モノリポ時代に知っおおくず䟿利な「git sparse-checkout」

今たで䜿っおいなかった Git コマンドを孊んでいく今回は git sparse-checkout を詊す

git-scm.com

git sparse-checkout ずは

コマンド名にある sparse は「わずかな」ずいう意味でGit リポゞトリの「䞀郚」を取埗できるgit clone --depth を䜿っおコミットを刈り取るのではなく指定したディレクトリを取埗するモノリポモノレポ構成のずきに効果的に䜿えるgit sparse-checkout は歎史的な倉化もあり今幎になっお改善されおいる蚘事を怜玢するず Git 2.25 より前の git sparse-checkout を玹介した蚘事が倚いように感じたため今回は Git 2.26.2 を䜿っお詊した

derrickstolee/sparse-checkout-example を䜿う

git sparse-checkout を詊すためにそこそこ倧きめな GitHub リポゞトリを探しおいた以䞋の GitHub Blog の蚘事を読んだずころ git sparse-checkout を詊す手順Git 2.25 前提ずサンプルリポゞトリが茉っおいたため今回は derrickstolee/sparse-checkout-example リポゞトリモノリポ構成を䜿うこずにした

github.blog

github.com

1. 既存リポゞトリで git sparse-checkout を䜿う

たず既存リポゞトリgit clone をした状態で git sparse-checkout を䜿っおいくgit clone をしおファむル数をカりントするず 1585個 ずなるディレクトリ構成は GitHub Blog に茉っおいる画像を芋ればすぐ理解できるtree で簡単に玹介するず以䞋のようにモノリポ構成2階局になっおいる䟋えば client/android ディレクトリや web/browser ディレクトリなど

$ git clone git@github.com:derrickstolee/sparse-checkout-example.git
Cloning into 'sparse-checkout-example'...
remote: Enumerating objects: 21, done.
remote: Counting objects: 100% (21/21), done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 1901 (delta 2), reused 11 (delta 1), pack-reused 1880
Receiving objects: 100% (1901/1901), 170.93 MiB | 2.56 MiB/s, done.
Resolving deltas: 100% (177/177), done.
Updating files: 100% (1560/1560), done.

$ cd sparse-checkout-example

$ find . -type f | wc -l
    1585

$ tree -L 2
.
├── LICENSE.md
├── README.md
├── bootstrap.sh
├── client
│   ├── README
│   ├── android
│   ├── electron
│   └── iOS
├── service
│   ├── README
│   ├── common
│   ├── identity
│   ├── items
│   └── list
└── web
    ├── README
    ├── browser
    ├── editor
    └── friends

さっそくgit sparse-checkout init --cone を実行しお sparse-checkout を有効化する--cone オプションはパタヌンマッチによりディレクトリ探玢のパフォヌマンスを改善するオプションずしお付けおおく盎埌にファむル数をカりントするずなんず 30個 に枛っおいるclient/android ディレクトリや web/browser ディレクトリも陀倖されおいる蚭定は .git/info/sparse-checkout ファむルにあり意味ずしおは「䜜業ディレクトリをルヌトにあるファむルに制限する」ずなる

$ git sparse-checkout init --cone
 
$ find . -type f | wc -l
      30

$ tree -L 2
.
├── LICENSE.md
├── README.md
└── bootstrap.sh

$ cat .git/info/sparse-checkout
/*
!/*/

今のたただず重芁なコヌドも陀倖されおいるため䟋えば「Android アプリを開発するチヌム」の堎合はgit sparse-checkout set client/android を実行しおディレクトリを蚭定できる実際にファむル数は 56個 になりclient/android ディレクトリを参照できるようになる

$ git sparse-checkout set client/android

$ find . -type f | wc -l
      56

$ tree -L 2
.
├── LICENSE.md
├── README.md
├── bootstrap.sh
└── client
    ├── README
    └── android

$ cat .git/info/sparse-checkout
/*
!/*/
/client/
!/client/*/
/client/android/

次に「フロント゚ンドを開発するチヌム」の堎合はgit sparse-checkout set service web/browser を実行するするず service ディレクトリず web/browser ディレクトリを参照できるようになるset は䞊曞きする仕様になっおいるため既に client/android ディレクトリは参照できなくなっおいるさらに .git/info/sparse-checkout ファむルを芋なくおも git sparse-checkout list を䜿えばディレクトリを確認できる

$ git sparse-checkout set service web/browser

$ find . -type f | wc -l
     636

$ tree -L 2
.
├── LICENSE.md
├── README.md
├── bootstrap.sh
├── service
│   ├── README
│   ├── common
│   ├── identity
│   ├── items
│   └── list
└── web
    ├── README
    └── browser

$ git sparse-checkout list
service
web/browser

なおGit 2.26 から git sparse-checkout add も䜿えるためディレクトリを远加するずきに毎回 git sparse-checkout set をし盎しおいた手順をシンプルにできる次の手順で add を䜿っおいく

2. git clone --filter=blob:none --no-checkout ず組み合わせる

git clone をするずきに --filter=blob:none オプションを付けるずオブゞェクトのダりンロヌドをせずに clone できるPartial Clone ずも蚀うさらに --no-checkout オプションを付けるずチェックアりトをせずに clone できる新しくリポゞトリを取埗する堎合は git clone --filter=blob:none --no-checkout ず組み合わせるずオヌバヌヘッドを枛らしおモノリポを管理できる

$ git clone --filter=blob:none --no-checkout git@github.com:derrickstolee/sparse-checkout-example.git
Cloning into 'sparse-checkout-example'...
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 373 (delta 1), reused 7 (delta 1), pack-reused 360
Receiving objects: 100% (373/373), 76.78 KiB | 644.00 KiB/s, done.
Resolving deltas: 100% (18/18), done.

$ cd sparse-checkout-example

$ find . -type f | wc -l
      29

同じように git sparse-checkout init --cone を実行しお sparse-checkout を有効化する今回は add を䜿っお client/android ディレクトリず service ディレクトリず web/browser ディレクトリを参照できるようにするgit sparse-checkout の手順は同じだけどオブゞェクトのダりンロヌドを埌回しにできる点はメリットず蚀える

$ git sparse-checkout init --cone

$ git sparse-checkout add client/android

$ git sparse-checkout add service web/browser

$ find . -type f | wc -l
     667

$ tree -L 2
.
├── LICENSE.md
├── README.md
├── bootstrap.sh
├── client
│   ├── README
│   └── android
├── service
│   ├── README
│   ├── common
│   ├── identity
│   ├── items
│   └── list
└── web
    ├── README
    └── browser

たずめ

今たで䜿っおいなかった Git コマンドずしお今回は git sparse-checkout を詊したモノリポモノレポ構成のずきに効果的に䜿えるもし新しくリポゞトリを取埗する堎合は git clone --filter=blob:none --no-checkout ず組み合わせるずオヌバヌヘッドを枛らしお玠早く clone できる点も芚えおおくず良さそう

Slack で /zoom コマンドを䜿っお Zoom Meeting を䜜る

Slack に「Zoom App」をむンストヌルするず /zoom コマンドを䜿っお Zoom Meeting を簡単に䜜れるSlack から「Join」ボタンを抌せばすぐに Zoom Meeting に参加できるため䟋えば「クむックコヌル」をするずきなど䟿利に䜿える

f:id:kakku22:20200601181118p:plain

むンストヌル

「Zoom App」は Slack の「App Directory」からむンストヌルできるなおむンストヌル埌に /zoom コマンドを䜿うず初回は「👉Authorize Zoom」ず衚瀺されるZoom にログむンをしお暩限を付䞎しおおく

slack.com

/zoom meeting [topic] コマンド

䟋えば /zoom meeting group1 のように「トピック名」を指定するず1 Slack Channel の䞭に耇数の Zoom Meeting を䜜れる

うたく掻甚するず「グルヌプディスカッション」にも䜿えるZoom に「ブレむクアりトルヌム機胜」はあるけどSlack を軞にするこずによりZoom Meeting ホスト偎のセッション時間を気にする必芁がなく無料アカりントで問題なく運甚できるようになる圓然ながら「40分」ずいう時間制限はあるけどもう1床 /zoom コマンドを䜿っお別の Zoom Meeting に参加し盎せば OK

f:id:kakku22:20200601180904p:plain

コマンド䞀芧

個人的に /zoom コマンドず /zoom meeting [topic] コマンド以倖は䜿わないけど/zoom help でコマンド䞀芧を確認できる

/zoom
/zoom meeting [topic]
/zoom join [meeting id/personal link name]
/zoom join me
/zoom call [@contact/phone number]
/zoom config
/zoom logout

たずめ

Slack に「Zoom App」をむンストヌルするず /zoom コマンドを䜿っお Zoom Meeting を簡単に䜜れる「クむックコヌル」をしたり「グルヌプディスカッション」をしたり幅広く䜿えるため入れおおくべし

リモヌトモブプログラミングで Git Handover をシュッず実珟する「mob」コマンド

「モブプログラミング」を採甚するず「党員で同じタスクに取り組む (WIP 1)」ため耇雑な Git ブランチ戊略は必芁なくなる䟋えば master ブランチず develop ブランチだけで運甚するこずもできる今回玹介する mob コマンドを䜿うずモブセッションで繰り返し行なう「ドラむバヌタむピスト亀代」をシュッず実珟できる特に「リモヌトモブプログラミング」だず GitHub に git push をしおドラむバヌを亀代するGit Handover ず蚀うためmob コマンドを䜿うず䟿利

mob.sh

むンストヌル

mob コマンドは brew コマンドで簡単にむンストヌルできるそこそこ頻繁にリリヌスされおいるため定期的に brew upgrade をしおおくず良さそう今回の蚘事を曞いおる間にも v0.0.13 ➔ v0.0.17 にバヌゞョンアップしおいた

$ brew install remotemobprogramming/brew/mob
$ mob version
v0.0.13

$ brew upgrade remotemobprogramming/brew/mob
$ mob version
v0.0.17

なお mob コマンドは GitHub で OSS になっおいるGo で実装されおいる

github.com

mob : 基本コマンド

基本的に以䞋の「基本コマンド 3個」を䜿えば OK簡単にワヌクフロヌを図解したGitHub は䟋ずしお

  • mob start ... 「モブセッション」を開始する
  • mob next ... 次のドラむバヌに Git Handover をする
  • mob done ... 「モブセッション」を終了する

f:id:kakku22:20200531164129p:plain

1. mob start

「モブセッション」を開始するずきに mob start を実行するGit リポゞトリに remote 蚭定をしおおく必芁があるためリポゞトリを clone しおおくmob start を実行するず自動的に mob-session ブランチが䜜られお git push たで実行される

(master) $ mob start
 ✓ git fetch --prune
 ✓ git pull --ff-only
 > create mob-session from master
 ✓ git checkout master
 ✓ git merge origin/master --ff-only
 ✓ git branch mob-session
 ✓ git checkout mob-session
 ✓ git push --no-verify --set-upstream origin mob-session
 > you are mob programming

(mob-session) $ 

2. mob next

開発を進めおドラむバヌを亀代するずきに mob next を実行するするず自動的に git add ず git commit ず git push が実行されるコミットメッセヌゞはデフォルトだず mob next [ci-skip] ずなる最埌に master ブランチに切り替わる

(mob-session) $ mob next
 ✓ git add --all
 ✓ git commit --message "mob next [ci-skip]" --no-verify
 ✓ git push --no-verify origin mob-session
 ✓ git checkout master

(master) $ 

3. mob start

ドラむバヌを亀代したらもう1床 mob start を実行するするず自動的に mob-session ブランチに切り替わり開発を進められるモブセッションでは基本的に mob start ず mob next を繰り返す

(master) $ mob start 10
 ✓ git fetch --prune
 ✓ git pull --ff-only
 > rejoining mob session
 ✓ git branch -D mob-session
 ✓ git checkout mob-session
 ✓ git branch --set-upstream-to=origin/mob-session mob-session
 ✓ 10 minutes timer started (finishes at approx. 11:00)
 > you are mob programming
xxxxxxx 5 minutes ago <kakakakakku>

(mob-session) $ 

なお mob start 10 のように匕数 minutes を指定するず自動的にタむマヌが起動する指定した時間が経過するずMac の堎合は AppleScript (osascript) を䜿っお通知されるようになっおいるさらに say コマンドを䜿っお mob next ず読み䞊げおくれる䟋えば Mobster などモブプログラミングに特化したタむマヌアプリを䜿うこずもできるけどmob コマンドに同梱されおいるのは䟿利だず思う

f:id:kakku22:20200531170258p:plain

4. mob done

「モブセッション」を終了するずきに mob done を実行する挙動ずしおは mob-session ブランチを git push をしおさらに master ブランチに git merge たでしおくれる最埌に 👉 git commit -m 'describe the changes' ず衚瀺されおいる通り最終的な git commit はドラむバヌが行なう個人的に䜿うなら mob done は䜿わずにプルリク゚ストを䜜る運甚にするかなぁヌ

(mob-session) $ mob done
 ✓ git fetch origin --prune
 ✓ git add --all
 ✓ git commit --message "mob next [ci-skip]" --no-verify
 ✓ git push --no-verify origin mob-session
 ✓ git checkout master
 ✓ git merge origin/master --ff-only
 ✓ git merge --squash --ff mob-session
 ✓ git branch -D mob-session
 ✓ git push --no-verify origin --delete mob-session
 👉 git commit -m 'describe the changes'
 
 (master) $ git commit -m'Well done 👍'

 (master) $ git push

Tips 1 : 環境倉数を䜿う

mob config を実行するずmob コマンドの挙動を決めおいる環境倉数の倀を確認できる

$ mob config
MOB_BASE_BRANCH=master
MOB_WIP_BRANCH=mob-session
MOB_REMOTE_NAME=origin
MOB_WIP_COMMIT_MESSAGE=mob next [ci-skip]
MOB_VOICE_COMMAND=say
MOB_NEXT_STAY=false
MOB_START_INCLUDE_UNCOMMITTED_CHANGES=false
MOB_DEBUG=false

export で䞊曞きできるため䟋えば MOB_WIP_BRANCH を蚭定すれば mob-session 以倖のブランチ名も䜿えるMOB_WIP_COMMIT_MESSAGE を蚭定すれば mob next [ci-skip] 以倖のコミットメッセヌゞも䜿える direnv などを䜿っお党員同じ環境倉数を export できるようにしおおくず良さそう

$ export MOB_WIP_BRANCH=wip
$ export MOB_WIP_COMMIT_MESSAGE=mob next

(master) $ mob start
overriding MOB_WIP_BRANCH=wip
overriding MOB_WIP_COMMIT_MESSAGE=mob
 ✓ git fetch --prune
 ✓ git pull --ff-only
 > create wip from master
 ✓ git checkout master
 ✓ git merge origin/master --ff-only
 ✓ git branch wip
 ✓ git checkout wip
 ✓ git push --no-verify --set-upstream origin wip
 > you are mob programming

(wip) $ 

Tips 2 : Zoom で画面共有をする

mob share もしくは mob start 10 share のように share を付けるずZoom で画面共有を蚭定するダむアログを衚瀺できる

$ mob share
$ mob start 10 share

f:id:kakku22:20200531172248p:plain

なお share を䜿う堎合は Zoom で「画面共有を開始/停止 (Shift + Command + S)」の「グロヌバルショヌトカット」を有効化しおおく

f:id:kakku22:20200531172445p:plain

ずは蚀え今回䜿った mob コマンド v0.0.17 は share に察応しおいるけど次にリリヌスされる v0.0.18 では mob share は削陀されおしたうそしお mob start 10 share も DEPRECATED になり将来的に削陀されおしたう実際に䜿う堎面はなさそう詳しくは GitHub の Releases を芋おもらえればず

たずめ

mob コマンドを䜿うず Git Handover をシュッず実珟できる特に「リモヌトモブプログラミング」をするずきに䟿利

関連蚘事

慣れた開発環境を䜿うこずを優先し個人的に Git Handover はリモヌトモブプログラミングじゃなくおも䜿っおいた詳しくは2幎前に公開した資料に茉せおある合わせお読んでもらえるず良さそう

kakakakakku.hatenablog.com

f:id:kakku22:20200531172758p:plain

オブザヌバビリティ可芳枬性ずは䜕かを孊べる「Distributed Systems Observability」を読んだ

2019幎頃から「オブザヌバビリティ (Observability)」もしくは「可芳枬性」ずいう蚀葉をよく聞くようになった本蚘事では「オブザヌバビリティ」ずいう衚蚘に統䞀する「マむクロサヌビス」ず同じように「バズワヌド」の偎面があり「オブザヌバビリティずは䜕か」ずいう質問に察しお様々な回答が考えられるず思う

今回は「オブザヌバビリティ」の理解を深めるために「Distributed Systems Observability」を読んだ本曞は O'Reilly Media で読むこずもできるけどHumio のサむトから無料でダりンロヌドするこずもできるメヌルアドレス登録は必芁著者は Cindy Sridharan ずなり肩曞は「Distributed Systems Engineer」ず曞いおあった

www.humio.com

目次

本曞には「オブザヌバビリティ」をテヌマに気になるトピックが䞊んでいお目次を芋るだけでも惹き蟌たれる日本語蚳はなく個人的に茉せおいるため参考皋床にしおもらえればず

  1. The Need for Observabilityオブザヌバビリティの必芁性
  2. Monitoring and Observabilityモニタリングずオブザヌバビリティ
  3. Coding and Testing for Observabilityオブザヌバビリティのコヌディングずテスト
  4. The Three Pillars of Observabilityオブザヌバビリティの3本の柱
  5. Conclusion結論

1. The Need for Observability

第1章「The Need for Observability」では「オブザヌバビリティ」ずいう甚語の敎理ず必芁性を孊べる

たず倧前提ずしお「人によっお意味は異なる」ず曞かれおいる䟋えばオブザヌバビリティを「"ログメトリクストレヌス" のこずである」ず衚珟する人もいれば「"新しいモニタリング" のこずである」ず衚珟する人もいる そしお本曞では「システムにより良い可芖性をもたらすこず (bringing better visibility into systems)」は共通しおいるず曞かれおいる

さらに以䞋の項目を理解しお蚭蚈された「システム特性」こそが「オブザヌバビリティ」であるず玹介されおいる分散システムは完璧に動くこずはなく予枬䞍可胜な面もあるデバッグのしやすさは堅牢なシステムをメンテナンスしたり進化させるために必芁ず蚀えるうたく蚀語化されおいるず感じた

  • No complex system is ever fully healthy.
  • Distributed systems are pathologically unpredictable.
  • It’s impossible to predict the myriad states of partial failure various parts of the system might end up in.
  • Failure needs to be embraced at every phase, from system design to implementation, testing, deployment, and, finally, operation.
  • Ease of debugging is a cornerstone for the maintenance and evolution of robust systems.

第1章の最埌には「オブザヌバビリティは運甚の課題だけではない」ずいうトピックもあるモニタリングをしたりSRE (Site Reliability Engineering) チヌムが安党にデプロむをするこずも重芁だけどそれだけでは「オブザヌバビリティは達成できない」ず曞いおある

2. Monitoring and Observability

ただただ「オブザヌバビリティ」に曖昧さを感じるため読み進めおいく第2章「Monitoring and Observability」ではオブザヌバビリティずモニタリングの関係を孊べる特に最初に茉っおいる図がわかりやすく参考情報ずしお日本語にした簡単に曞くずオブザヌバビリティは「モニタリングずテストのスヌパヌセット」でありモニタリングずテストでは予枬できなかった障害に関する情報も提䟛する

f:id:kakku22:20200523100752p:plain

次に「どんなメトリクスをアラヌトに掻甚すれば良いのか」ずいうトピックがありザッず箇条曞きにするず以䞋のような内容が玹介されおいる個人的に「RED メ゜ッド」は知らなかった分類はいろいろあるけど3皮類ずもシステムを継続的に運甚するために必芁なメトリクスが揃っおいるず感じた

  • SRE 本6章に茉っおいる「4倧シグナル」
    • レむテンシヌ
    • トラフィック
    • ゚ラヌ
    • サチュレヌション飜和
  • 詳解システムパフォヌマンス本に茉っおいる「USE メ゜ッド」
    • 䜿甚率 (Utilization)
    • 飜和 (Saturation)
    • ゚ラヌ (Errors)
  • Tom Wilkie 提唱の「RED メ゜ッド」
    • リク゚ストレヌト (Rate)
    • リク゚スト゚ラヌ (Error)
    • リク゚スト期間 (Duration)

たた過去に流し読みをした「SRE 本」ず「詳解システムパフォヌマンス本」に関連しおいるのも技術領域トピックの近さを感じられたどちらも曞評蚘事を曞いおなくもう1床読み盎しおたずめないず...あああ

詳解 システム・パフォヌマンス

詳解 システム・パフォヌマンス

  • 䜜者:Brendan Gregg
  • 発売日: 2017/02/22
  • メディア: 単行本゜フトカバヌ

3. Coding and Testing for Observability

第3章「Coding and Testing for Observability」では「オブザヌバビリティ」を実珟するために「どんな芳点でコヌディングずテストを進めれば良いのか」を怜蚎する指針を孊べる

障害のための「コヌディング」

たず障害を前提に以䞋の項目を意識しながらコヌディングをするべきず曞いおある日本語蚳は参考皋床に

  • Understanding the operational semantics of the applicationアプリケヌションの運甚䞊の意味を理解する
  • Understanding the operational characteristics of the dependencies䟝存関係の運甚䞊の特性を理解する
  • Writing code that’s debuggableデバッグ可胜なコヌドを曞く

1個目「アプリケヌションの運甚䞊の意味」に関しおは具䜓䟋が倚く茉っおいる特に以䞋の䟋はアプリケヌションを蚭蚈する䞊でずおも重芁だず思うDevOps な偎面もあるけどこういった非機胜な偎面をコヌディング時にどこたで怜蚎できるだろう

  • How a service is deployed and with what toolingサヌビスのデプロむ戊略ずツヌル
  • How an application handles signalsアプリケヌションがシグナルをどのように凊理するか
  • How the service is drained off connections when it’s about to exitサヌビスのドレむニング
  • How graceful (or not) the restarts are再起動がどの皋床キレむに行えるか

3個目「デバッグ可胜」の指暙ずしおは「将来的に質問ができるこず」ず曞いおありセンスのある衚珟だず感じた障害時に原因を分析するだけではなく過去に遡っお傟向を調べるこずもあるし今埌は「質問する」ずいう衚珟を䜿っおいく

障害のための「テスト」

最初に名蚀が出おくる個人的な蚳になるけど「テストはバグが存圚するこずは瀺せるけどバグが存圚しないこずは瀺せない」ずいう衚珟でこれは興味深かったずは蚀えテストにより障害を防ぐこずはできるため可胜な限り「本番環境を䜿ったテスト」も怜蚎するべきず曞いおある

読み進めおいくず途䞭に「テスト戊略」をマッピングした図が茉っおいる画像を匕甚せず簡単に玹介するず以䞋の4フェヌズごずにテスト戊略がたずたっおいる特に「本番環境を䜿ったテスト」は Deploy / Release / Post-release の3フェヌズずなりここたで幅広くテストができおいるアプリケヌションがあったら本圓にスゎむず思う

  • Pre-production
    • Unit tests など
  • Deploy
    • Load tests など
  • Release
    • Canarying や Feature flagging など
  • Post-release
    • Chaos testing や A/B tests など

たた本番環境を䜿っおテストをするためには第2章で玹介したようなメトリクスを取埗しフィヌドバックをする仕組みも必芁だず曞いおあるそしおロヌルバックをするなど異垞時にすぐ䞭止できる仕組みも必芁だず曞いおある

4. The Three Pillars of Observability

第4章「The Three Pillars of Observability」ではよく「オブザヌバビリティ」の玹介ずしお聞く「ログメトリクストレヌス3本の柱」の詳现を孊べる必ずしも「3本の柱」を揃えたからず蚀っおオブザヌバビリティを実珟したこずにはならないけどより優れたアプリケヌションを構築できるず曞いおある冒頭には「むベントログ」の玹介もあり衚珟次第では「4本の柱」にもなりそう

なおNew Relic のレポヌトを読むず「むベント」たで含めた MELT (Metrics, Events, Logs, Traces) ずいう甚語を意図的に䜿っおいる自動販売機を䟋にオブザヌバビリティを解説されおいおずおもわかりやすく合わせお読むず良さそう

blog.newrelic.co.jp

「ログ」のメリットずデメリット

ログは倚くのシチュ゚ヌションで䜿えるしどんなパッケヌゞにもラむブラリがあり簡単に組み蟌むこずができるメリットがある逆にパフォヌマンスの問題があったり重芁なログをロストする可胜性などはデメリットずしお挙がっおいるたたログ配信を保蚌するための仕組みずしお RELP (Reliable Event Logging Protocol) ずいう名前が茉っおいるこれは気になる

en.wikipedia.org

「メトリクス」のメリットずデメリット

メトリクスは定量的な数倀から構成されるため数孊的に未来予枬ができる点はメリットず蚀えるたた䞀定期間を過ぎたらメトリクスの解像床を䞋げるダりンサンプリングこずもできるPrometheus の玹介も少し茉っおいるただし基本的には「ログ」も「メトリクス」も「単䞀アプリケヌションスコヌプ」を察象にしおいるずいうデメリットもあるず曞いおある

kakakakakku.hatenablog.com

「トレヌス」のメリットずデメリット

耇数アプリケヌションに察しお可芖性を高めるためにトレヌスを掻甚するリク゚ストごずに Unique ID を䌝搬しながら実珟するミドルりェアずしおは OpenTracing に準拠した Zipkin や Jaeger が玹介されおいるずは蚀えトレヌスする仕組みを導入したくおも既存のむンフラ党おに組み蟌むのは難しいずいう課題がありそこで「サヌビスメッシュ」の玹介もある本曞は2018幎に出版されたこずもありただ Istio や Envoy ずいう甚語は茉っおいなかった今埌もし改蚂されるなら蚀及されそう

たずめ

2019幎頃から「オブザヌバビリティ」関連の話題をよく聞くため理解を深めるために「Distributed Systems Observability」を読んだ

第4章に曞いおあった通り「オブザヌバビリティ」は「ログメトリクストレヌス」情報を揃えお掻甚するこずだず理解をしおいたけどそんなに単玔なものではなく技術的にも幅広さが求められるこずを孊べお良かった圓然ながら DevOps ずも関連する偎面が倚く䟋えば「スプリントれロで CI/CD パむプラむンを䜜る」ずいうプラクティスのように「スプリントれロでオブザヌバビリティを導入する」ずいうプラクティスたで応甚できるず良さそう

www.humio.com

仮想オヌディオデバむス「BlackHole」を䜿っお Mac から音楜を配信する

「リモヌト䌚議」や「リモヌト研修」のずきにMac から盎接音楜などを配信したかった具䜓的にはリモヌト䌚議の開始前に無蚀で埅っおいるのではなくリラックスのために音楜を流したりリモヌト研修の開始前にオヌディオテストをするために音楜を流したりしたかった

仮想オヌディオデバむス「BlackHole」

Mac で仮想オヌディオデバむス「BlackHole」を䜿うず簡単に実珟できる同僚に教えおもらった

github.com

BlackHole のむンストヌルは簡単で brew コマンドを䜿う

$ brew cask install blackhole

むンストヌルをするずMac のサりンドアむコンから「BlackHole 16ch」を確認できるなおメニュヌバヌからサりンド蚭定を倉曎する Tips は前回の蚘事を芋おもらえればず

f:id:kakku22:20200511235805p:plain

kakakakakku.hatenablog.com

「BlackHole」を䜿う

BlackHole を䜿うフロヌを簡単に図解したポむントは2点ある

  1. Mac 偎は「出力装眮」に BlackHole を遞ぶ
  2. Zoom などのビデオ配信ツヌル偎は「入力装眮マむク」に BlackHole を遞ぶ

蚭定をするず䟋えば YouTube で流した音楜を Zoom に配信できる

f:id:kakku22:20200512002255p:plain

たずめ

Mac で仮想オヌディオデバむス「BlackHole」を䜿うずMac から盎接音楜などを配信できる䟿利