趣味と仕事の違い、現場で求められるアプリケーションの可観測性

自己紹介 - 株式会社LIFULL 相原魁 - ソフトウェアエンジニアスペシャリスト(Platform Engineering, SRE) - 仕事ではKubernetesをベースとした内製PaaS KEELを開発・運用 - 趣味では主にRustを書いています - 全文検索ライブラリ - 分散検索エンジン - eBPF Copyright© LIFULL Co.,Ltd. All Rights Reserved.

5.

自己紹介 - 株式会社LIFULL 相原魁 - ソフトウェアエンジニアスペシャリスト(Platform Engineering, SRE) - 仕事ではKubernetesをベースとした内製PaaS KEELを開発・運用 - 趣味では主にRustを書いています - 全文検索ライブラリ - 分散検索エンジン - eBPF 分散システムを開発する中で可観測性に注力 Copyright© LIFULL Co.,Ltd. All Rights Reserved. 可観測性のプラットフォームも開発する立場

6.

「したい暮らしに、出会おう。」をコンセプトに掲げ、簡単で便利な住まい探しをお手伝いする不動産・住宅情報の総合サービスです。物件の探しやすさや住まいに関する情報の見つけやすさ、検討がしやすくなるように、様々な機能や情報を拡充していきます。今後も、ユーザーに寄り添いながら、ともに理想の住まい探しを実現します。 Copyright© LIFULL Co.,Ltd. All Rights Reserved.

7.

LIFULLの内製PaaS KEEL - コマンドを1発叩くだけで完璧なアプリケーション実行環境が手に入る内製PaaS - デプロイ、セキュリティ、可観測性、信頼性、パフォーマンス - コードジェネレータを中心とした開発者体験の提供 - Pull Requestを作成するとプレビューできる機能やLint, Content Trustまで備える - https://www.lifull.blog/archive/category/Kubernetes Copyright© LIFULL Co.,Ltd. All Rights Reserved.

https://www.lifull.blog/archive/category/Kubernetes

8.

9.

10.

[beta]

エラーをとりあえずでロギングするだけ
func doSomething() *RetVal {
retval, err := maybeError()
if err != nil {
log.Printf("an error occurred: %+v", err)
}
return retval
}
Copyright© LIFULL Co.,Ltd. All Rights Reserved.

11.

12.

[beta]

Rustだったらunwrap()するだけとか
fn doSomething() RetVal {
let result: Result<RetVal> = maybeError();
let retval = result.unwrap();
retval
}

Copyright© LIFULL Co.,Ltd. All Rights Reserved.

13.

14.

実行時間の計測をログで頑張る func doSomething() *RetVal { start := time.Now() retval := maybeSlow() elapsed := time.Since(start) log.Printf("maybeSlow took: %s", elapsed) return retval } Copyright© LIFULL Co.,Ltd. All Rights Reserved.

15.

16.

[beta]

折角もらったエラーを適当に標準エラーする

func main()
retval, err := doSomething()
if err != nil {
fmt.Fprintf(os.Stderr, "%+v", err)
}
}
func doSomething() (*RetVal, error) {...}
Copyright© LIFULL Co.,Ltd. All Rights Reserved.

17.

18.

19.

20.

https://ja.wikipedia.org/wiki/状態空間_(制御理論)#可観測性

21.

22.

23.

24.

25.

26.

https://openmetrics.io/

27.

余談: OpenMetrics - Prometheusというモニタリングシステムを参考に標準化されたフォーマット - summary, gauge, counter, statesetといったいくつかのデータタイプでMetricsを表現 - エージェントあるいはアプリケーションがこのフォーマットに従って出力する - Datadogをはじめ多くのモニタリングシステムがサポート Copyright© LIFULL Co.,Ltd. All Rights Reserved.

28.

29.

https://github.com/kubernetes/autoscaler/blob/5cf3b9657f53324e4d6d7cc06bee8837d0e51503/cluster-autoscaler/main.go#L384-L395

30.

[beta]

Garbage Collectorに関する情報
- ランタイム内に持っているGCの情報
- アプリケーション内で収集して出力する
pp GC.stat
#{:count=>13,
# :heap_allocated_pages=>50,
# :heap_sorted_length=>69,
# :heap_allocatable_pages=>19,
# :heap_available_slots=>20383,
# :heap_live_slots=>20256,
# :heap_free_slots=>127,
# :heap_final_slots=>0,
# :heap_marked_slots=>17090,
# :heap_eden_pages=>50,
# :heap_tomb_pages=>0,
# …}
Copyright© LIFULL Co.,Ltd. All Rights Reserved.

31.

http://nginx.org/en/docs/http/ngx_http_stub_status_module.html

32.

余談: Prometheus Exporter - Metricsを出力するためのPrometheus用のエージェント - PrometheusのMetrics表現はOpenMetricsと互換性があるため広く利用できる - OSSとして多くのPrometheus Exporterが存在する - MySQL Server Exporter - Redis Exporter - NGINX Prometheus Exporter - cAdvisor - 利用するミドルウェアに対応するPrometheus Exporterを探すことができる - EXPORTERS AND INTEGRATIONS Copyright© LIFULL Co.,Ltd. All Rights Reserved.

33.

インデックスとカーディナリティ - MetricsはラベルというKey-Valueを元にインデックスする - ラベルの数が多いとカーディナリティが高くなりコスト増 - e.g. {uri=”/items/1”}, {uri=”/items/2”}, … {uri=”/items/9999”} - こういった詳細な情報の表現はLogsの方が向く Copyright© LIFULL Co.,Ltd. All Rights Reserved.

34.

Metrics - 依存関係を持つメタデータの有向非巡回グラフ - Spanというデータ構造の集合からなる Traces Logs - OpenTelemetryで標準化が進んでいる - 計測も保存も比較的コストが高い - サンプリング(間引き)をすることが一般的 - 出力方法 - アプリケーション内で計測して出力 Copyright© LIFULL Co.,Ltd. All Rights Reserved.

https://opentelemetry.io/

35.

余談: OpenTelemetry - OpenTracingとOpenCensusが統合されて生まれたプロジェクト - OpenTracingはTracesの標準化をしていたプロジェクト - OpenCensusはTracesとMetricsの収集を補助するライブラリ - OpenTracingはベンダー中立にPropagationするための仕様を策定していた Copyright© LIFULL Co.,Ltd. All Rights Reserved.

36.

https://www.jaegertracing.io/docs/1.32/

37.

https://www.jaegertracing.io/docs/1.32/

38.

https://www.jaegertracing.io/docs/1.32/

39.

https://opentracing.io/specification/

40.

Propagation - アプリケーションをまたいだ依存関係を持つことができる - アプリケーション間の依存関係はHTTPヘッダで引き回す - W3C Trace Context - traceparent Header - trace-id - parent-id - sampled - microservicesの依存関係を可視化することができる Copyright© LIFULL Co.,Ltd. All Rights Reserved.

https://www.w3.org/TR/trace-context/

41.

再掲実行時間の計測をログで頑張る func doSomething() *RetVal { start := time.Now() retval := maybeSlow() elapsed := time.Since(start) log.Printf("maybeSlow took: %s", elapsed) return retval } Copyright© LIFULL Co.,Ltd. All Rights Reserved.

42.

再掲実行時間の計測をログで頑張る func doSomething() *RetVal { start := time.Now() maybeSlowが複雑な依存関係を持つ場合Metricsだけでは調査しづらい retval := maybeSlow() Tracesも収集することで依存関係のボトルネックを探せるようにしたい elapsed := time.Since(start) log.Printf("maybeSlow took: %s", elapsed) return retval } Copyright© LIFULL Co.,Ltd. All Rights Reserved.

43.

https://grafana.com/docs/grafana/latest/basics/exemplars/

44.

ここまでのまとめ - 実装に詳しくない人が状況を判断できるよう可観測性が重要 - 可観測性には3つの性質の違う主要なシグナルがある - Logs: 自由度が高くフォーマットを持たないテキストデータ - Metrics: 詳細な情報を安価に表現するインデックスつきの数値データ - Traces: 複雑な依存関係を表現できるメタデータの有向グラフ - それぞれ補完しあう関係にあるため組み合わせて使う - Metricsはコストが安いが詳細情報や依存関係を持てない - Logsは詳細情報を持てるがコストが高い - Tracesは依存関係を持てるが表現が限定的でコストが少し高い Copyright© LIFULL Co.,Ltd. All Rights Reserved.

45.

余談: 周辺エコシステム - Logs - Grafana Loki, ElasticSearch - Amazon CloudWatch Logs - Cloud Logging - Metrics - Prometheus(Cortex) - All-in-one - Datadog - NewRelic - Grafana(?) - OSSのObservability Platform - Loki, Cortex, TempoのGrafana Labsが開発 - Amazon CloudWatch - Cloud Monitoring - Traces - Grafana Tempo, Jaeger - AWS X-Ray - Cloud Trace Copyright© LIFULL Co.,Ltd. All Rights Reserved. OpenMetrics, OpenTelemetry含め殆どがCNCF周りのもの

46.

余談: CNCF - > Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えてます。私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。 (https://github.com/cncf/toc/blob/main/DEFINITION.md) Copyright© LIFULL Co.,Ltd. All Rights Reserved. 引用: CNCF Landscape

47.

https://landscape.cncf.io/

48.

ケーススタディ: レスポンス速度の遅延 1.どうやらレスポンス速度が遅くなっているらしいと監視から通知を受け取る 2.まずはMetricsからどんなアプリケーションのどのリクエストが遅延したか確認 foo Applicationの /bar が遅延していた 3.次はLogsでfoo Applicationの /bar でエラーログが出力されていないかどうかを確認このリクエストはrequestid=bazでこのrequestidにエラーログはなかった 4.Tracesでrequestidを調べるとMySQLにクエリしていてその速度が遅延していた 5.MySQLに関するMetricsを確認すると同時間帯に接続数が増大していた Copyright© LIFULL Co.,Ltd. All Rights Reserved.

49.

50.

51.

[beta]

再掲
エラーをとりあえずでロギングするだけ
func doSomething() *RetVal {
retval, err := maybeError()
if err != nil {
log.Printf("an error occurred: %+v", err)
}
return retval
}
Copyright© LIFULL Co.,Ltd. All Rights Reserved.

52.

53.

[beta]

再掲
Rustだったらunwrap()するだけとか
fn doSomething() RetVal {
let result: Result<RetVal> = maybeError();
let retval = result.unwrap();
retval
}

Copyright© LIFULL Co.,Ltd. All Rights Reserved.

54.

55.

[beta]

指針
1.
2.

エラーをどう取り扱うかは呼び出し元に決めさせる
必要なコンテキストを付与する
①

func doSomething() (*RetVal, error) {
retval, err := maybeError()
② 独自のエラー型・例外でラップするなど
if err != nil {
return nil, xerrors.Errorf("failed to execute maybeError: %w", err)
}
return retval, nil
}

Copyright© LIFULL Co.,Ltd. All Rights Reserved.

56.

余談: 例外を乱用しない - 例外でラップする例を挙げたが例外は乱用してはならない - フロー制御として使うにはコストが高い - 例外はあくまで”例外”であるため普段起こりうるフローでは利用しない - Replacing Throwing Exceptions with Notification in Validations - エラーハンドラ Copyright© LIFULL Co.,Ltd. All Rights Reserved.

https://martinfowler.com/articles/replaceThrowWithNotification.html

57.

58.

HTTPのURIに秘匿情報を含めない - アクセスログにそのままpasswordが記録されてしまう GET /secrets?password=foobar HTTP/1.1 Host: example.com User-Agent: curl/7.58.0 Accept: */* 指針: ユーザの個人情報など秘匿情報を記録しない Copyright© LIFULL Co.,Ltd. All Rights Reserved.

59.

[beta]

外部からの入力をそのままログにしない
- パラメータとしてユーザの電話番号を受け取っていた場合ログに出力されてしまう

def validation(parameters)
parameters.each do |parameter|
if rules[parameter[:key]].valid?(parameter[:value])
STDERR.puts "#{parameter[:value]} is invalid"
end
end
end

指針: ユーザの個人情報など秘匿情報を記録しない

Copyright© LIFULL Co.,Ltd. All Rights Reserved.

60.

[beta]

再掲
折角もらったエラーを適当に標準エラーする

func main()
retval, err := doSomething()
if err != nil {
fmt.Fprintf(os.Stderr, "%+v", err)
}
}
func doSomething() (*RetVal, error) {...}
Copyright© LIFULL Co.,Ltd. All Rights Reserved.

61.

HTTPサーバならRequestIDを含める - 慣例的にHTTPではX-Request-Idというヘッダでリクエストを一意に識別する - 最前段のHTTPサーバで発行して、各HTTPクライアントはそれを引き回す - これをアクセスログやエラーログに含めておくとリクエストをまとめて検索できる指針: どのイベントに紐づくログであるかを記録する Copyright© LIFULL Co.,Ltd. All Rights Reserved.

62.

ログの出力元やStack Traceを含める - ソースコードのどこで原因となるイベントが発生したかを調べられる必要がある - Stack Traceはデータ量が大きい反面、情報量が多い - ログを見た後、詳細な調査が必要なエラーでStack Traceを出力することが多い - 前述の通り呼び出し元がエラーを受け取りStack Traceを出力する指針: どのイベントに紐づくログであるかを記録する Copyright© LIFULL Co.,Ltd. All Rights Reserved.

63.

必要に応じてJSONで出力する - 主要なLogsのObservability PlatformはJSONをParseする機能を備えている - HTTPサーバのアクセスログなどログを元に分析する場合はJSONが好ましい - syslogやLTSVなどその他のフォーマットもあるがPlatformのサポートが厚いのはJSON 指針: 分析のしやすいフォーマットにする Copyright© LIFULL Co.,Ltd. All Rights Reserved.

64.

余談: ログレベル(持論) - ログレベルとは対象のログの深刻度を示すもの - 一般に以下のようなログレベルが採用されることが多い - DEBUG - INFO - WARN - ERROR - CRITICAL - ログは前述の通りコストが高いため無視されるログは必要がない - 不用意にログレベルを増やすと無視されるログを増やすことに繋がる - 全てのエラーは等しく対応をすべきだとして以下のみから始めることが多い - DEBUG - INFO - ERROR Copyright© LIFULL Co.,Ltd. All Rights Reserved.

65.

66.

USEメソッド - Brendan Greggによって提唱されたMetrics収集の方法論 - あるリソースに対してUtilization, Saturations, Errorsを収集する - 各リソースのMetricsの例示は The USE Method を参照 - ハードウェアリソースはエージェントが既に収集していることが多い - エージェントの不足分やソフトウェアリソースをUSEメソッドに従って収集する ECONNREFUSED - 古典的なTCPサーバで考えた場合 - Utilization: ActiveなWorker数 / 総Worker数 - Saturations: Backlogに積まれたIn-QueueなConnection数 - Errors: ECONNREFUSEDが返った数 Master Worker Copyright© LIFULL Co.,Ltd. All Rights Reserved. Worker Worker

https://www.brendangregg.com/usemethod.html

67.

https://www.brendangregg.com/usemethod.html

68.

REDメソッド - USEメソッドがリソース単位であることに対してREDメソッドはサービス単位 - REDメソッドの適用先はより限定的 - It is fair to say this method only works for request-driven services(The RED Method) - あるサービスに対してRate, Errors, Durationを収集する - microservicesの場合はデータストア含む依存するサービスに対して収集を考える - 検索エンジンで考えた場合 - Rate: 検索エンジンに対するRequests per second - Errors: レスポンスのエラー数 - Duration: レスポンスのレイテンシ Copyright© LIFULL Co.,Ltd. All Rights Reserved.

https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/

69.

再掲実行時間の計測をログで頑張る func doSomething() *RetVal { start := time.Now() retval := maybeSlow() elapsed := time.Since(start) log.Printf("maybeSlow took: %s", elapsed) return retval } Copyright© LIFULL Co.,Ltd. All Rights Reserved.

70.

再掲実行時間の計測をログで頑張る func doSomething() *RetVal { start := time.Now() retval := maybeSlow() この手のものはMetricsとして管理してコストを安くしたい elapsed := time.Since(start) log.Printf("maybeSlow took: %s", elapsed) return retval } Copyright© LIFULL Co.,Ltd. All Rights Reserved.

71.

出力の方法 - アプリケーションがOpenMetrics形式でMetricsを出力する - Prometheusのクライアントライブラリを入れるなど - アプリケーションのMetricsをエージェントが収集して出力する - nginxの/nginx_statusをNGINX Prometheus Exporterが出力するなど Copyright© LIFULL Co.,Ltd. All Rights Reserved.

https://github.com/nginxinc/nginx-prometheus-exporter

72.

メソッドに従うことのメリット - Metricsは収集した後に監視・可視化をするが、処理を共通化させやすい - 抜け漏れなくMetricsを収集することができる - これらはあくまで指針であるためアプリケーション固有のものは別途収集する - Garbage Collectorの情報 - アプリケーションの状態 - ランタイム固有のグリーンスレッドの数 Copyright© LIFULL Co.,Ltd. All Rights Reserved.

73.

74.

- CPUの使用率にPod間の偏りが存在する(Sticky Session下での過負荷など) - cgroupで設定したlimits.memoryまでメモリを使い切れていない - メトリクスの収集に失敗している - NetworkのReceiveでパケットが落とされている - NetworkのTransmitでパケットが落とされている - Podがrestartを短時間に繰り返している - Podがスケジュール待ちなど不正な状態が継続している - PodのHealthCheckが失敗している - 全てのPodのHealthCheckが失敗している - PodがImageの取得に失敗するなどして待機状態になっている - Podのメモリが不足し始めている - Nodeのリソース不足などが原因でPodが大量に退避させれている - Podがスケールアウトの限界に近付いている - Podのエラーレートが増加している - Podの特定のURIのエラーレートが増加している and more... Copyright© LIFULL Co.,Ltd. All Rights Reserved.

75.

76.

77.

再掲余談: OpenTelemetry - OpenTracingとOpenCensusが統合されて生まれたプロジェクト - OpenTracingはTracesの標準化をしていたプロジェクト - OpenCensusはTracesとMetricsの収集を補助するライブラリ - OpenTracingはベンダー中立にPropagationするための仕様を策定していた Copyright© LIFULL Co.,Ltd. All Rights Reserved.

78.

再掲余談: OpenTelemetry - OpenTracingとOpenCensusが統合されて生まれたプロジェクト - OpenTracingはTracesの標準化をしていたプロジェクト - OpenCensusはTracesとMetricsの収集を補助するライブラリ OpenTelemetryもOpenCensusに引き続き各言語向けにライブラリを提供 - OpenTracingはベンダー中立にPropagationするための仕様を策定していた Copyright© LIFULL Co.,Ltd. All Rights Reserved.

79.

80.

OpenTelemetry SDKの機能 - OpenMetrics, OpenTracing(OpenTelemetry)に準拠したMetrics, Tracesの出力 - Prometheusのクライアントライブラリを別途入れる必要なし - 各種クライアントの自動Metrics, Traces収集, 自動Propagation - HTTPクライアント - DBクライアント - とりあえずOpenTelemetryを入れるだけで外部IOへのTracesは概ね完了 - IOを伴わない部分のTracesは後から考えれば十分 - 個別でSpanを埋める対応が必要となる - Metricsは自身での追加のMetricsの収集が必要 - Log Data ModelでログのサポートもあるがSDK側は未実装が多い - 将来はこれだけでLogsまで任せられる可能性も Copyright© LIFULL Co.,Ltd. All Rights Reserved.

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md

81.

再掲 HTTPサーバならRequestIDを含める - 慣例的にHTTPではX-Request-Idというヘッダでリクエストを一意に識別する - 最前段のHTTPサーバで発行して、各HTTPクライアントはそれを引き回す - これをアクセスログやエラーログに含めておくとリクエストをまとめて検索できる指針: どのイベントに紐づくログであるかを記録する Copyright© LIFULL Co.,Ltd. All Rights Reserved.

82.

再掲 HTTPサーバならRequestIDを含める - 慣例的にHTTPではX-Request-Idというヘッダでリクエストを一意に識別する - 最前段のHTTPサーバで発行して、各HTTPクライアントはそれを引き回す - これをアクセスログやエラーログに含めておくとリクエストをまとめて検索できる OpenTelemetry導入後は代わりにtrace-idを利用することができる指針: どのイベントに紐づくログであるかを記録する Copyright© LIFULL Co.,Ltd. All Rights Reserved.

83.

まとめエラーハンドリング 1. エラーをどう取り扱うかは呼び出し元に決めさせる 2. 必要なコンテキストを付与する Logs 1. ユーザの個人情報など秘匿情報を記録しない 2. どのイベントに紐づくログであるかを記録する 3. 分析のしやすいフォーマットにする Metrics 1. USEメソッド 2. REDメソッド Traces 1. とりあえずOpenTelemetryを使っておく Copyright© LIFULL Co.,Ltd. All Rights Reserved.

84.

最後に - 可観測性は実装に詳しくない人が状況を判断するために必要 - 仕事の現場では自身だけがメンテナンスし続けるわけにはいかない - 指針に従ってPrimary Signalsを収集することで可観測性を向上させることができる - それぞれは補完しあうためどれも欠けてはならない可観測性やパフォーマンスのような非機能要件こそ腕の見せ所可観測性に優れたアプリケーションを実装しましょう CNCFでも可観測性(Observability)は大きなトピックで投資価値は十分あると思います Copyright© LIFULL Co.,Ltd. All Rights Reserved.

85.

86.

プロファイラ - プログラム実行中の関数の呼び出し回数や実行時間などを計測するためのソフトウェア - 実行時にオーバーヘッドを伴うものが多く開発時に利用することが一般的 - プログラムのボトルネックを特定できる - 代表的なソフトウェア - Linux perf - Valgrind - google/pprof - Go - V8’s sample-based profiler(google/pprof-nodejs) - Node.js Copyright© LIFULL Co.,Ltd. All Rights Reserved. 引用: https://github.com/google/pprof

https://github.com/google/pprof

87.

sample-based profiler - 統計的なアプローチで精度と引き換えにオーバーヘッドを最小化するプロファイラ - google/pprof - V8’s sample-based profiler(google/pprof-nodejs) - 定期的にコールスタックを読んで収集する - Event profilerは精度が高い一方でイベント数が多くオーバーヘッドが大きい - Linux perfは両方に対応している Copyright© LIFULL Co.,Ltd. All Rights Reserved.

88.

継続的プロファイリング - プロファイラはオーバーヘッドが大きく開発時しか利用できなかった - sample-based profilerと言えどもオーバーヘッドはある - それらを利用した継続的プロファイリングを提供するサービスが開始 - Cloud Profiler - Datadog Continuous Profiler - 継続的プロファイリングでは1分間に10秒間だけのようにプロファイリングする - Tracesと比較して個別で対応することなく関数のボトルネックを探すことができる - プロファイリングはネットワークを跨ぐことはできないためその点でTracesは有用 - 可観測性を更に向上させるSignalの一つとなりつつある Copyright© LIFULL Co.,Ltd. All Rights Reserved.

89.

eBPF - eBPFはLinuxカーネルにおけるJavaScriptのようなもの - JavaScriptと同様にサンドボックスなVM上で稼働する - JavaScriptがHTMLにすることと同様にLinuxカーネルのイベントに処理をアタッチする - C言語でeBPFプログラムを記述するとそれがカーネル空間で安全に実行される - ユーザ空間に渡す必要がないから高速 - 様々なイベントに対応していて可観測性に対して大きな力を持つ - kprobe/kretprobe: カーネルの関数呼び出し・終了 - uprobe/uretprobe: バイナリの任意のオフセットの関数の呼び出し・終了 - 可観測性の他にセキュリティ分野でも注目されていてCNCFの熱いトピックの一つ - アプリケーションに影響を与えることなく危険なsyscallの実行を監視したり Copyright© LIFULL Co.,Ltd. All Rights Reserved.

90.

PyroScope - オープンソースの継続的プロファイリングのプラットフォーム - Cloud Profiler他と同様にgoogle/pprofなどを使いながら継続的プロファイリングをする - eBPFのサポートもありより小さいオーバーヘッドでの実行が期待できる - ※ 現時点ではbccに依存していていくつかの問題がある - 興味があれば: BPF Portability and CO-RE Copyright© LIFULL Co.,Ltd. All Rights Reserved.

91.

再掲 LIFULLの内製PaaS KEEL - コマンドを1発叩くだけで完璧なアプリケーション実行環境が手に入る内製PaaS - デプロイ、セキュリティ、可観測性、信頼性、パフォーマンス - コードジェネレータを中心とした開発者体験の提供 - Pull Requestを作成するとプレビューできる機能やLint, Content Trustまで備える - https://www.lifull.blog/archive/category/Kubernetes Copyright© LIFULL Co.,Ltd. All Rights Reserved.

https://www.lifull.blog/archive/category/Kubernetes

趣味と仕事の違い、現場で求められるアプリケーションの可観測性

株式会社LIFULL

関連スライド

pmconf2023【プロダクトマネジメントで高速PDCA】アウトカムが激増したLIFULL HOME’Sのグロース事例

CloudWatch LogsからGrafana Lokiにログ基盤を移行

HNSWの内部構造

LIFULL HOME'SでのSolrの構成と運用の変遷

PrometheusとGrafanaで追求する、より良いアプリケーションの可観測性

#ED6103との付き合い方

各ページのテキスト

趣味と仕事の違い、現場で求められるアプリケーションの可観測性

株式会社LIFULL

関連スライド

pmconf2023【プロダクトマネジメントで高速PDCA】 アウトカムが激増したLIFULL HOME’Sのグロース事例

CloudWatch LogsからGrafana Lokiにログ基盤を移行

HNSWの内部構造

LIFULL HOME'SでのSolrの構成と運用の変遷

PrometheusとGrafanaで追求する、より良いアプリケーションの可観測性

#ED6103との付き合い方

各ページのテキスト

pmconf2023【プロダクトマネジメントで高速PDCA】アウトカムが激増したLIFULL HOME’Sのグロース事例