2024/6/15 CloudNative Days Summer 2024 #CNDS2024 https://gyazo.com/5d3a01dd3204a0309669052f6c5b6f54
クラウドネイティブな省エネサービスの內製開發で、BizDevOpsを實現する
Mys$ ^3
多額の初期投資ができない + 社内に知見をためたい→內製開發
兼業でやってる
安價で自由度を高く
パブリッククラウド
マイコン + IoT ゲートウェイ
もともと SORACOM
frontend から device を書き換へたい→AWS IoTAWS IoT.icon へ移行 社内 community の「やってみた」の繰り返し
onboarding を省略
補完
example がいっぱい
CI/CD を組んだ
core 機能だけだが test も組んだ
檢討してる
Sysdig CSPM
TiDB Serverless
生成 AI
cloud native→事業により注力できる
リードタイム、コストを最適化しながら恢復性を求めるクラウドネイティブ戰略
Reposaku
Momonto Cache
timeout
手前が長くて、奧にいく程短くする
逆轉すると、奧で成功しても手前が front に失敗を返してしまふ
retry
結果整合でいいなら非同期處理にする
edge が retry の責任を逃れられる
buffer
device に 3 日分の data を溜めておける
開發環境
local debug
SAM template
SAM CLI
CI/CD
GitLab Flow
main branch + staging branch + production branch
次世代のクラウドネイティブ基盤、Wasmの今と未來
Wasm runtime
stack machine
random access できる linear memory も持ってゐる
64 Kb 每
IO は WASI
warg
wa.dev
component model
core Wasm には
int64 と float しか無い
他の data 型は compiler 依存
WIT (Wasm interface type)
header file だな
canonical ABI
エンドツーエンドの可視性を實現するクエスト
infra
host map
cluster map
serverless view
log
application performance
user と synthetic
cloud security
cost management
cloud は豫算を讀みにくい
DatadogDatadog.icon の service 紹介だった 成長し續けるTVerサービスを支へるオブザーバビリティとカスタマーサポート
frontend も多種多樣。TV とか…
frontend からは、端末 ID が付與されて情報を蒐集する
view の permalink を CS に傳へて、communication が效率的
これ大切だなne-sachirou.icon
deploy timing が可視化されてる
自動で可視化したいよねne-sachirou.icon
と自動生成を活用した、フューチャフラグの宣言的集約管理
feature flag
deploy 便利
要らなくなったら早目に消さないと、消していいのかどうかわからなくなりがち
https://gyazo.com/cdbaf03c285d417f6718c5c71121c8ff
https://gyazo.com/71fe8052e33a237d2485ffb3b9380149
release toggle
experimental toggle
ops toggle
permission toggle
feature flag as a service
ConfigCat
Flagsmith
SaaS 等 (provider) の抽象化層
複數の provider を混ぜられる
cache したり、SaaS から變更を傳播したり、default 値を返したり
protoc から feature flag 用の code を自動生成する
typo の防止
reminder test
消し忘れを警吿する。指定した日數を經過してゐたら CI を落とす
外部 SaaS と遣り取りするのだから、OpenTelemetryOpenTelemetry.icon の span も入れようねぇ 課題
release branch 運用との兼ね合ひ
「自動計裝」ではなく自動實裝ではないかなne-sachirou.icon
Service Weaver で始めるモジュラー モノリス、そしてマイクロサービスへ
資料 : ?
複數 team の關はる monolithic より、microservice のはうが理論的には release cycle が短くなる筈 Service Weaver
OTP Application (ぉ
core library + deployer
core library
component 同士が呼び出す code を自動生成する
log
profile
$ weaver gke profile cache
test
色んな runner (deployer 環境。Local、Multi、RPC) で test
weavertest.Fake で module を stub
deployer
單一環境や分散環境に deploy する
$ go run .
$ weaver multi deploy
$ weaver ssh deploy
$ weaver gke deploy
multi region
routing
custom resource の管理
$ weaver kube deploy ; kubectl apply
テレメトリーシグナルの相關、してますか？第一原理からのデバッグを支える計裝
資料 : ?
8 オブザーバビリティを実現するためのイベント解析
8.2 第一原理からのデバッグ
第一原理
第一原理からの debug
推測なしに演繹できる data を積み重ねて根本原因を特定する
假說驅動型 debug (假說を立て、それを確認するために data を探索する手法)
←→推測だらけの debug
「エスパー」ってやつだne-sachirou.icon
telemetry
log (event 每)、trace (event 每)、metrics (統計)
時系列變化
原 trace から trace と log の生成を考へるといいと思ってるんだよなne-sachirou.icon
「trace は特殊な log 形式」ではない…
trace は文字列表現を持つ、と云ふだけ
文字列はこれを充分表現可能、と云ふのは意義があるな
span はどこから遣って來たと言ふのか。原 trace から來たんだ
相關
log に trace_id と span_id を埋め込む
trace には trace_id と span_id が勿論埋め込まれてゐる
event に trace_id を埋め込む
sqlcommenter
histogram の exempler
log を metric 化する
聯繋してない別々の tool を使っても相關しない
profile
時系列統計
一定時閒內の、stacktrace の處理の樣子
時系列變化は見えない
view 次第では?ne-sachirou.icon
まぁその view はもう trace か
總當たり
attribute を埋めてゆく