バクラクにおける可観測性向上の取り組み #LayerXテックアドカレ

バクラク事業部 Platform Engineering 部 DevOps チームの uehara です。

LayerX Tech Advent Calendar 2024 の4日目となる本記事では、バクラクにおける可観測性向上の取り組みについて紹介します。

はじめに

2024年10月30日に行われたイベントで同じタイトルの発表をさせていただきました。

当日の発表では時間の関係で盛り込めなかった部分も含めて紹介します。

LayerX はコンパウンドスタートアップとして新しい事業やプロダクトを継続的に立ち上げており、バクラク事業部にもすでに7つのプロダクトが存在します。

フェーズや性質の異なるプロダクトが複数並行で開発されており、システム可観測性の観点で以下の課題を抱えていました。

DevOps チームは「お客様へ価値を届けるためにプロダクト開発チームを全力で支える」ことをミッションとしています。課題の状況を踏まえて、まずはサービスインフラの可観測性向上に注力することとしました。

運用改善や課題解決のヒントを探るため、2024年8月に開催された SRE NEXT 2024 にていくつかのセッションに参加しました。

参加したセッションで印象に残ったフレーズや取り組みについて一部紹介します。リンク先の公式サイトではセッション動画も公開されていますので、併せてご覧ください。

SLOの理解を深めて、ユーザーエクスペリエンスを向上する方法
- すべての値がいい SLI になるわけではない
- いい SLI とはユーザー体験に紐づいているもの (レスポンス成功率やレイテンシ等)
Enabling Client-side SLO
- 現場のエンジニアに寄り添ったアラートチューニング
- 文化醸成のためにダッシュボードを作成して定期的に確認する場を設けた

上記の発表内容を参考に、実際の運用見直しに取り掛かりました。

まずは監視ツールとして採用している Datadog の情報を棚卸ししました。

その結果、プロダクトごとに開発時期やアーキテクチャが異なるため取得データにバラつきがあったり、一見データが取れていても計測範囲や単位 (ミリ秒やマイクロ秒) が揃っていなかったりと、新たな課題も見つかりました。

この課題には、Enabling チームと連携してプラットフォーム側から改善を進めています。全プロダクトのロガーとログフォーマットを統一し、項目名や処理時間の計測基準などを揃えました。今後新たなプロダクトが増えても同じ基盤を活用できるように整備しています。

パフォーマンス可視化の観点では Datadog APM や Profiler を既存プロダクトへ展開したほか、新規マイクロサービスへの組み込みを容易にする仕組みも実装されました。

Datadog APM や Profiler の利用拡大に伴うコスト上昇を抑えるため、ログ出力内容の見直しや Datadog Subscription 契約のコミットメント最適化なども並行して進めています。

Datadog を活用した改善として、新たに全プロダクト横断ダッシュボードを整備しました。

前提としてバクラクでは複数プロダクトの連携から成る機能が多数存在します。とあるプロダクトでの障害が他プロダクトへ影響を与える可能性も否定できません。

まずは全プロダクトの健全性を1ページで確認可能なダッシュボードを作成し、誰が見ても判断できる統一された軸 (リクエスト成功率) を指標として仮設定しました。

以下は検証用ダッシュボードの例ですが、しきい値を下回った場合は赤い表示に切り替わり、異常をひと目で検知できます。

これまで各プロダクトやプラットフォーム共通リソースのダッシュボードは存在していたものの、全プロダクトの状況を一括で確認できる画面はありませんでした。

現在は本番環境へのデプロイ時や設定変更後にこのダッシュボードを必ず確認するルールとして運用中です。

「自動化されたアラートで何もせずとも適切な通知が来る」という形が理想ですが、まずはプロダクトの健全な状態を知る・異常発生時に気づける土台を作ることも重要であると考えています。

ここまで紹介した取り組みによって、すでにいくつかの成果を得られました。

ロガー (ログフォーマット) の統一
- 出力項目を追加する際に各プロダクトでの個別対応が不要になった
- 項目名の統一により複数サービスのログを同時に参照する際の認知負荷が減った
全プロダクト横断ダッシュボード
- 既存監視よりも早く異常を検知できた事例があった
- 複数プロダクトへ影響する問題に早い段階で気がつけた

加えて、プロダクト開発チームから監視設計や Datadog の活用について相談を受ける機会も増えてきました。メトリクスやログ・ダッシュボードの整理によって、改善自体も進めやすくなったと感じています。

冒頭に示した課題の解消にはまだ道半ばの段階です。今後もさらなる取り組みを予定しています。

プロダクトごとにより適切な SLI を模索する
- 重視したい体験を軸に、プロダクト開発チームや PdM と詳細を固める
- 守るべき指標を定めることでより効率的な監視を行える
ユーザー体験への影響度に合わせた監視の整備
- レイテンシやエラー率など体験に直結する値を重視
- 数日以内の対応でよいものなどは、通知方法を見直してアラート割り込みを減らす
パフォーマンス監視
- 性能問題が発生した場合の調査材料を増やす (APM / Profiler 活用方法の周知)
- 大規模テナントや特定ユースケース単位での可視化の土台作り