ログ検索体験から逆算するログ基盤設計

Transcript

1. ログ検索体験から逆算するログ基盤設計 hiroshi tokudomi / 株式会社タイミー プラットフォームエンジニアリング 増え続けるログ、どこに置き、どこまで残すか ── AI時代のObservability / Security基盤 ファインディ × Imply Data
2. Timee ⾃⼰紹介 徳富 博 所属 タイミー プラットフォームエンジニアリングチーム チームでやっていること o11y 設計 セキュリティ 開発⽣産性向上 パフォーマンスチューニング コスト管理 信頼性向上 インフラ構築 Embedded SRE
3. Timee 2ヶ⽉前のログ、 普段使っているツールで、そのまま検索できますか？
4. Timee 「このログ、調べられますか？」が基盤チームに⾶んでくる 以前はこうだった Datadog の保持 それを過ぎたログ 結果 15〜45⽇ S3 + Athena 基盤チームに集まる （ログの種類による） で引くしかない 開発チームからの調査依頼として 開発者の中で頑張る ⼿順を調べ直す → 基盤チームに来る 書ける⼈に聞く → 基盤チームに相談 → 開発者にとっても、基盤チームにとっても幸せじゃなかった だから、ログ基盤の設計を⾒直しました 復元 / 調査待ち
5. Timee ここから どういう⽅針で⾒直したか 「何を⼤事にして、どこを割り切るか」の考え⽅を先に共有します 1 考え⽅ ⽬的と制約 トレードオフ‧決め⽅ 2 → 3つのケース アプリ / セキュリティ / Runner ログ 3 → まとめ 全体像と 持ち帰ってほしいこと
6. Timee ログ設計は「⽬的」と「制約」で整理する ⽬的 1 2 3 検索体験を最⼤化する 制約 必ず守る 誰でも引ける(AIを利⽤するか) 使いやすさ 予算 検索スキルにばらつきがあっても、迷わず引けるか 保存‧取り込み‧検索のコスト 速く引ける スピード 法的な保存規定 どれだけ速く結果が欲しいか 保存しておく期間（法令‧契約） 遡って引ける 検索できる期間 「検索できる期間」は⽬的、 「保存しておく期間」は制約 「何⽇残すか」ではなく「何⽇前まで調べる可能性があるか」 制約は必ず守る。その中で、検索体験を最⼤化する
7. Timee ただし予算の中で、全部は伸ばせない 制約｜予算の枠 3つ全部を最⼤まで伸ばすと、予算の枠を超える ① 誰でも引ける 制約 予算の枠は超えない ⽬的 枠の中で、どの軸をどこまで伸ばすか決める ⽬的 検索体験 ② 速く引ける 例：開発者全員が使うなら①に投資∕攻撃対応なら②を優先∕たまにしか⾒ ないなら全部低くてよい ③ 遡って引ける どこを割り切るかを決めるのが設計
8. Timee 注意｜予算を意識しすぎると、こうなりがち ⚠ よくある落とし⽳ 保持期間‧置き場所を 「安さ」で先に決める → 検索のしやすさが 後から犠牲になる → 「ログはあるけど、 調べ⽅がわからない」 → 安いけど、 使われない基盤 避けるために 理想の検索体験を描いてから、予算と照らし合わせる 削るのは、検索体験に響かない所から 予算は守る。でも、コストを理由に検索体験は犠牲にしない
9. 検索体験を起点に、予算の枠の中で⾏き来して決める Timee 制約｜予算‧法令の枠 ▼ ここから考え始める 安さから決めると、「ログはあるけど調べ⽅がわからない」になるため 誰が調べるか 検索スキルのばらつきは？ ⇄ どれだけ速く‧どこまで遡るか 直近だけ？ 何⽇前まで？ ⇄ どこに置き、どう引くか Hot / Cold、ツール、AI（コスト） 1つを決めると、他の2つと予算に響く。枠に収まるまで⾏き来して決める（割り切るポイントを探していく） 決めた結果（基本形） Hot ストレージ Datadog 基本的なログ検索は、Hot ストレージだけで完結するよう にする Cold ストレージ 求められる期間（法令‧契約）を満たすように保持期間を 決める 検索体験は、予算内で成り⽴って初めて意味がある。 次は「検索体験を削らずに」予算に合わせる⽅法 → S3
10. Timee 予算は「ログの種別を整理」で守る 検索体験は削らずに、ログを⽤途で分けて、それぞれに合った持ち⽅をする A B そもそも送らない 短期しか⾒ないものは分けて 短く捨てる C ⻑期で⾒るものはティアを分 ける • 誰も⾒ないログはログ基盤（Datadog） に送らない • ⼀時的‧短いスパンでしか検索しないロ グは、Index を分けて保持を短く • アラートに必要な期間だけ Standard （極⼒短く） • 例：Sidekiq の start / end • 全体を短くするのではなく、短くていい ものだけ分離 • 調査にしか使わない期間は Flex • Flex でも同じ Log Explorer‧同じクエリ で引ける 検索体験への影響 なし 検索体験への影響 なし 検索体験への影響 なし 「送らない」×「分けて短く捨てる」×「⻑期は安いティアに寄せる」の3⼿で予算に合わせる 3⼿とも、調べたいログの検索体験は削っていない
11. Timee ここから どこを割り切って適⽤したか 1 考え⽅ ⽬的と制約 トレードオフ‧決め⽅ 2 → 3つのケース アプリ / セキュリティ / Runner ログ 3 → まとめ 全体像と 持ち帰ってほしいこと
12. Timee この考え⽅を、3種類のログに当てはめる(どこで割り切るのか) ケース1 ケース2 ケース3 アプリログ セキュリティログ self-hosted runner ログ 利⽤者は開発者全員 攻撃時に基盤チームの誰でも 即時性も信頼性も要らない 1 1 1 2 3 3軸とも伸ばしたい → 予算の中で ③ の⽇数を絞る 検索体験の3軸 ① 誰でも引ける 2 3 2 ② の速さは直近だけ最⼤化 → 過去は Cold で割り切る ② 速く引ける ③ 遡って引ける 3 3軸とも低くてよい → 安い置き場を選ぶ ⾼ 中 低
13. Timee この考え⽅を、3種類のログに当てはめる ケース1 ケース2 ケース3 アプリログ セキュリティログ self-hosted runner ログ 利⽤者は開発者全員 攻撃時に基盤チームの誰でも 即時性も信頼性も要らない 1 1 1 2 3 3軸とも伸ばしたい → 予算の中で ③ の⽇数を絞る 2 3 2 ② の速さは直近だけ最⼤化 → 過去は Cold で割り切る 検索体験の3軸 ① 誰でも引ける ② 速く引ける ③ 遡って引ける 3 3軸とも低くてよい → 安い置き場を選ぶ ⾼ 中 低
14. Timee 利⽤者は開発者全員、そして45⽇の壁 ✕ これまで（Datadog の保持は45⽇） 45⽇を超えたら S3 アーカイブを調べ直す ◦ 検索体験の3軸で⾒ると ⾼/中/低 誰が調べるか（検索スキルのばらつき） 1 開発者全員（ばらつきが⼤きい） ↓ ⾼ ↓ Athena / Rehydrate（ログを Datadog に戻す作業）は開 発者だけでは難しい どれだけ速く必要か（頻度が⾼い） 2 障害対応なので、速く ↓ ⾼ ↓ どこまで遡って必要か 基盤チームに問い合わせて待つ 3 ⻑め ── でも、何⽇あれば⾜りる？ ↓ ↓ 開発者も基盤チームも調査⼯数をとられる 3軸とも伸ばしたい 3軸とも伸ばしたい。でも、予算の枠がある → 伸ばしどころを絞るため、③「何⽇遡れればいいか」を数えた ⾼
15. Timee 必要な保持期間を過去の記録から調査棚卸し 31件 ⽉平均 2.3件 通常ログ調査依頼27 + 障害対応4 リードタイム 中央値 6⽇ 68% 管理画⾯系に集中 保持期間ごとのカバー率 97% 調査の68%が管理画⾯系。どこをどれだけ伸ばすかは、数えるま で分からなかった。 63% 19% 15⽇ ⼀律に伸ばす必要はない → ③ は「管理画⾯系だけ1年」で⾜りる 90⽇ 365⽇
16. Timee 設計：Hot を「越えさせない」⻑さにする 1 2 制約｜予算 ③ 遡って引ける 3 ① 誰でも引ける Standard を全インデックス15 ⽇に短縮 浮いた予算を管理画⾯系の Flex 12ヶ⽉に回す Bits AI を検索の⼊⼝にする 直近の障害対応（②速く）はこれで⾜りる 「⻑期は安いティアに寄せる」の適⽤例 検索スキルのばらつきを AI で吸収する 短縮したのは Standard の⽇数だけ。調べられる期間は 45⽇ → 1年 に伸びている 開発者 → AI → Datadog Standard 15⽇ + Flex 12ヶ⽉ → 基本は Datadog の中で完結し、S3 まで⾏くのは保持期間を過ぎた場合だけ S3 （保持期間を過ぎた場合）
17. 検索体験はそのまま1年に、そこに AI 検索を⾜した ✕ これまで ◦ Timee いま Log Explorer で遡れるのは45⽇まで Log Explorer でそのまま1年遡れる ③ 超えたら Athena‧基盤チーム待ち MCP / Bits AI で⾃然⾔語のログ検索もできる ① Datadog のクエリ構⽂を知っている⼈しか引けない 構⽂を知らなくても同じ結果に辿り着ける ① Athena ⾏きも基盤チーム待ちも原則起きない（365⽇なら調査の97%で完結） 制約も守った これをやっても⽉額はほぼ維持
18. Timee この考え⽅を、3種類のログに当てはめる ケース1 ケース2 ケース3 アプリログ セキュリティログ self-hosted runner ログ 利⽤者は開発者全員 攻撃時に基盤チームの誰でも 即時性も信頼性も要らない 1 1 1 2 3 3軸とも伸ばしたい → 予算の中で ③ の⽇数を絞る 2 3 2 ② の速さは直近だけ最⼤化 → 過去は Cold で割り切る 検索体験の3軸 ① 誰でも引ける ② 速く引ける ③ 遡って引ける 3 3軸とも低くてよい → 安い置き場を選ぶ ⾼ 中 低
19. Timee 利⽤者も「調べる⽬的」も別物 ✕ これまで（必要になってから調べる） WAF‧CloudTrail‧GitHub Audit log 等を S3 に保存 ◦ 検索体験の3軸で⾒ると ⾼/中/低 誰が調べるか（検索スキルのばらつき） 1 セキュリティ / インフラの少数‧専⾨ ↓ 中 ↓ どれだけ速く必要か（頻度は低いが緊急度が⾼い） 必要になるたび Athena で個別に調査 2 直近の攻撃は「⼀刻を争う」 ↓ ⾼ ↓ 調査に時間がかかる（攻撃⼿法‧攻撃⾯は多様化） どこまで遡って必要か 3 数年前まで遡るが「急がない」 ↓ ↓ 検知から封じ込めまでに時間がかかる構造 ② の速さが要るのは「直近」だけ 封じ込めまでの時間＝被害量。「必要になってから Athena で引く」では②を満たさない ただし、②の速さが要るのは直近だけ ⾼
20. Timee 「今攻撃されている」と「過去に侵害がなかったか」を分ける ① 今攻撃されている ② 過去に侵害がなかったか ⼀刻を争う 直近1年：Hot Datadog Cloud SIEM + AI で⾼速検索 ② 速く を最⼤化 • • • GitHub / AWS を横断して Cloud SIEM が Signal を出す （単⼀ソースでは⾒えない攻撃を拾える） Signals の⾃動トリアージで、アクセスキーが漏洩した 場合に、どこを触られたかを辿れる ③ 遡る、でも急がない 秒は争わない それ以前：Cold S3 + Athena • 全ログは S3 に⻑期保管（保管の正本はこちら） • 侵害の疑いが出たら、Athena で数年前まで遡って調査 （1〜2⽇早めても効果が薄い） • 結果が出るまで時間はかかるが、それでいい Bits AI で引けるので、基盤チームの誰でも緊急時に調 査できる（① も確保） ⽬的が違うなら、この⼆つに同じストレージを使う必要はない
21. Timee 割り切りの理屈 緊急対応（封じ込め） → 直近1年あれば⾜りる(Datadog SIEM) → Hot で⾼速に 過去の侵害有無 → 3年分の調査を1〜2⽇早めても効果が⼩さい(S3) → Cold で割り切る 速さが価値になる期間にだけ、Hot のコストを払う
22. Timee この考え⽅を、3種類のログに当てはめる ケース1 ケース2 ケース3 アプリログ セキュリティログ self-hosted runner ログ 利⽤者は開発者全員 攻撃時に基盤チームの誰でも 即時性も信頼性も要らない 1 1 1 2 3 3軸とも伸ばしたい → 予算の中で ③ の⽇数を絞る 2 3 2 ② の速さは直近だけ最⼤化 → 過去は Cold で割り切る 検索体験の3軸 ① 誰でも引ける ② 速く引ける ③ 遡って引ける 3 3軸とも低くてよい → 安い置き場を選ぶ ⾼ 中 低
23. Timee 検索体験の3軸が全部「低い」ログ ✕ 出発点（いまの困りごと） ジョブが終わると、ログを調べられない ◦ 検索体験の3軸で⾒ると 誰が調べるか（検索スキルのばらつき） 1 基盤チームのみ（ログ検索に慣れている） ↓ なぜ起動に失敗したのか追えない 低 ↓ どれだけ速く必要か（頻度は低い） 2 低 遅くてよい ↓ 直近、何が起きたかが分からない ⾼/中/低 ↓ どこまで遡って必要か 3 直近1週間くらいあれば⼗分 ↓ 必要なのは「直近、何が起きたか」だけ 3軸とも低くてよい ＝ 属⼈性の排除への投資も AI も、ここでは要らない 「誰でも引ける」を捨てたのではない。慣れた⾃チームだけなので、すでに満たせている 低
24. Timee なぜ社内標準の Datadog に送らないのか 通常なら：社内標準の Datadog に送る。 でも、このログの使われ⽅と Datadog の課⾦体系は合うか？ このログ（self-hosted runner） 噛み合わない Datadog の課⾦体系‧強み ログ量が多い ✕ 取り込み‧インデックスは「量」に⽐例して課⾦される 慣れた⾃チームしか⾒ない ✕ 全社横断の検索や AI で「誰でも引ける」のが強み たまにしか⾒ない ✕ インデックスを作って「よく検索する」ほど元が取れる 量に払うのに、ほとんど引かない ＝ Datadog の課⾦体系と合わない → どこでお⾦が発⽣するかで、置き場を⽐較する
25. Timee 設計の根拠：どこでお⾦が発⽣するかで選ぶ Datadog が合わないなら、どこに置くか。「どこでお⾦が発⽣するか」で候補を⽐べる 取り込み インデックス 保存 検索 Datadog 課⾦ 課⾦が重い 課⾦ — CloudWatch Logs 課⾦が重い — 課⾦ スキャン課⾦ Loki + S3 ⾃前運⽤ ラベルのみ S3（安い） S3 スキャン分の課⾦ このログ：量は多い × 検索はたまに × ⾒るのは慣れた⾃チームだけ ↓ インデックスに⾦を払うメリットがない → Loki + S3
26. Timee 割り切りと⾒直しトリガー 利⽤者が慣れた⾃チームだけ → ログ基盤の信頼性要件を下げてよい → 信頼性を上げるための 運⽤⼯数はかけない 検索体験の3軸が全部「低い」 → 検索体験への投資（Hot‧AI‧冗⻑性）をしない → Loki + S3 で⾃前運⽤で⼗ 分 ◦ 現状：直近の起動‧失敗が、⾃チームで追えるようになった ⾒直しトリガー（どれかが起きたら、3軸を⾒直す） ① 利⽤者が⾃チーム外に広がる ② 検索頻度が上がる ③ 遡る期間の要件が伸びる 同じ3軸で⾒ただけで、ケース1‧2と正反対の答えになる
27. Timee 1 考え⽅ ⽬的と制約 トレードオフ‧決め⽅ 2 → 3つのケース アプリ / セキュリティ / Runner ログ 3 → まとめ 全体像と 持ち帰ってほしいこと
28. Timee まとめ 1 検索体験は⽬的、予算と法令は制約 2 制約は必ず守り、その中で検索体験を最⼤化する。コストを 理由に検索体験は犠牲にしない 3 枠の中で、どの軸を伸ばすかを選ぶ(割り切り) 3つの問いを⾏き来して決める。Hot / Cold の境界は「速さが 価値になる期間」で引く 検索体験は3軸で⾒る ① 誰でも引ける ② 速く引ける ③ 遡って引ける 「誰が調べるか」は検索スキルのばらつきを⾒るため 4 予算は「調べられる期間」を削らずに守る ログの種別を整理する：送らない / 分けて短く捨てる / ⻑期は 安いティアに寄せる まず、過去1年の調査依頼を数えてみてください 「何⽇遡れればいいか」は、数えるまで分からなかった
29. 積極採用中です！！ タイミーの開発組織は新しいフェーズに突入しており、新しい仲間を募集してます！ ぜひお気軽にお声がけください！