コドモンSREにおける オブザーバビリティ改善の道のり

「【日経×コドモン×RevComm】サービスの安定性、信頼性を高めるDevOps/SREの取り組み」での発表資料です。
https://nikkei.connpass.com/event/292415/

Transcript

1. コドモンSREにおける オブザーバビリティ改善の道のり 2023年09月21日 日経×コドモン×RevComm サービスの安定性、信頼性を高めるDevOps/SREの取り組み
2. 2 経歴 音響エンジニア(PA)からITエンジニアに転職。SIerや派遣でのインフ ラ業務を数社経験後、2020年10月にコドモンにSREとして入社。 妻が保育士で、保育の現場を肌で感じながら、日々プロダクトの信頼 性向上を目指す。 趣味は週末のランニングで、社内にランニングクラブを立ち上げたの で、リレーマラソンに会社で出るのが直近の目標🏃󰝋 自己紹介 田中 知英 たなか ともひで
3. 3 Mission
4. 4 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。
5. 5 今日話すこと オブザーバビリティとは フェーズにおける改善の取り組み 今後 まとめ 1 2 3 4
6. 6 今日話すこと オブザーバビリティとは フェーズにおける改善の取り組み 今後 まとめ 1 2 3 4
7. 7 CONFIDENTIAL © 2022 CoDMON Inc. 7 オブザーバビリティとは • クラウド、マイクロサービス、分散システムの 普及に伴い、システムの複雑性が増している • システムで「いつ、何が、どこで起こっている のかを観測可能に保つ」考え方 • オブザーバビリティのシグナルの3本柱 　　　 「メトリクス」「ログ」「トレース」 参考：「Observability Whitepaper」CNCF https://github.com/cncf/tag-observability/blob/main/whitepaper.md
8. 8 CONFIDENTIAL © 2022 CoDMON Inc. 8 オブザーバビリティとは メトリクス • システムの状態を数値化したもの ◦ 例： CPU使用率、メモリ使用率、レスポンスタイム、リクエスト数 • 「何が」起きているかを把握するのに大きな役割を果たす • メトリクス単体で必ずしも原因が明らかになるわけではない
9. 9 CONFIDENTIAL © 2022 CoDMON Inc. 9 オブザーバビリティとは ログ • システムの状態をテキストで記録したもの ◦ 例： アプリケーションログ、アクセスログ、エラーログ • 特定の状況に至るステップを追うことができる • 障害が発生した瞬間の状態を把握することができる 　
10. 10 CONFIDENTIAL © 2022 CoDMON Inc. 10 オブザーバビリティとは トレース • トランザクション中の処理の流れを記録したもの ◦ 例： リクエストの処理時間、DBへのクエリ • トランザクションの処理の流れを追うことができる 　
11. 11 今日話すこと オブザーバビリティとは フェーズにおける改善の取り組み 今後 まとめ 1 2 3 4
12. 12 2019 2023 2022 2021 開始 初期 マイクロ サービス 導入開始 マイクロ サービス 拡大 現在
13. 13 サービス開始初期
14. 14 CONFIDENTIAL © 2022 CoDMON Inc. 14 サービス開始初期 • 開発部人数：約8名 • インフラ（現SRE）人数：2名 • アーキテクチャ：モノリス 　 体制（2019年）
15. 15 CONFIDENTIAL © 2022 CoDMON Inc. 15 サービス開始初期 メトリクス • CloudWatch ログ • CloudWatch Logs トレース • なし その他 • MSP（マネージドサービスプロバ イダ） 技術スタック
16. 16 CONFIDENTIAL © 2022 CoDMON Inc. 16 サービス開始初期 • インフラ担当としては2名いたが、セールスエンジニア的な仕事も担ってお りリソースが不足 • インフラ整備に対して稼働を割けない 課題
17. 17 CONFIDENTIAL © 2022 CoDMON Inc. 17 サービス開始初期 監視はAWSサービスを活用 • システムはモノリスのため、対象のリソースはそれほど多くない • 最低限のメトリクスをCloudWatchにて監視 • ログの保存先としてCloudWatch Logsを利用 MSPによりリソース不足を対応 • MSPを利用することで、社外のリソースを活用し監視を実装
18. 18 マイクロサービス導入開始期
19. 19 CONFIDENTIAL © 2022 CoDMON Inc. 19 マイクロサービス導入開始期 • 開発部人数：約30名（+22名） • SRE人数：4名（+2名） • アーキテクチャ：1機能をマイクロサービス化にてリプレイス 　 体制（2021年）
20. 20 CONFIDENTIAL © 2022 CoDMON Inc. 20 マイクロサービス導入開始期 メトリクス • Datadog ログ • CloudWatch Logs トレース • なし その他 • PagerDuty 技術スタック
21. 21 CONFIDENTIAL © 2022 CoDMON Inc. 21 マイクロサービス導入開始期 • システム全体の稼働状況の把握が難しい • 外形監視などのサービスレベルでの監視観点の不足 • MSPが活用しきれず費用対効果が薄い 課題
22. 22 CONFIDENTIAL © 2022 CoDMON Inc. 22 マイクロサービス導入開始期 Datadogの導入 • SREメンバーが増えたことで運用改善にリソースを割ける状態に • ダッシュボードによるシステム全体のリソース状況を可視化 • マルチアカウントの情報を一括で管理 • PagerDutyとの連携でオンコールを実装 • MSPから自社での監視運用に切り替え、コスト削減する
23. 23 マイクロサービス拡大期
24. 24 CONFIDENTIAL © 2022 CoDMON Inc. 24 マイクロサービス拡大期 • 開発部人数：約50名（+20名） • SRE人数：4名 • アーキテクチャ：新機能やリプレイスはすべてマイクロサービス化 　 体制（2022年）
25. 25 CONFIDENTIAL © 2022 CoDMON Inc. 25 マイクロサービス拡大期 メトリクス • Datadog ログ • Datadog • S3(Athena) + Redash トレース • DatadogAPM その他 • PagerDuty • SlowQueryReport 技術スタック
26. 26 CONFIDENTIAL © 2022 CoDMON Inc. 26 マイクロサービス拡大期 • ユーザー増加に伴うシステム負荷の高騰 • ユーザー増加に伴う問い合わせ数や調査コストの増加 • SREに依存した監視運用 課題
27. 27 CONFIDENTIAL © 2022 CoDMON Inc. 27 マイクロサービス拡大期 Datadogの利用範囲の拡充 • アプリケーションの問題の特定を容易にするため、DatadogAPMの導入 • アプリケーションレベルの異常の早期検知と調査が容易に • ログ情報をDatadogに集約することで、ログのリアルタイム監視や Datadogで調査を完結できる状態に • 週次で各開発チームとDatadog見る会を開催し、システム構成の理解を高 めてもらいながら、Datadogを操作することに慣れてもらう
28. 28 CONFIDENTIAL © 2022 CoDMON Inc. 28 マイクロサービス拡大期 Redashによるログ分析 • ログの永続領域としてはS3を利用することで保持コストを下げ、 Athenaを活用することでRedashでの分析を容易に • Redashをインタフェースとすることで、 ビジネスサイドも分析として活用できる状態に 自前でのレポートツールの作成 • DB負荷の潜在的なリスク検知のため、pt-query-digestを利用し 日次でのSlowQueryのレポートをSlack通知する運用を開始
29. 29 CONFIDENTIAL © 2022 CoDMON Inc. 29 マイクロサービス拡大期
30. 30 現在
31. 31 CONFIDENTIAL © 2022 CoDMON Inc. 31 現在 • 開発部人数：約80名（+30名） • SRE人数：6名（+2名） • アーキテクチャ：新機能やリプレイスはすべてマイクロサービス化 　 体制（2023年）
32. 32 CONFIDENTIAL © 2022 CoDMON Inc. 32 現在 メトリクス • NewRelic ログ • NewRelic • Fluentd + S3(Athena) トレース • NewRelicAPM • NewRelicMobile その他 • PagerDuty • SlowQueryReport • AWSCostReport 技術スタック
33. 33 CONFIDENTIAL © 2022 CoDMON Inc. 33 現在 • 開発チームが増えることでSREとのコミュニケーションコストが増加 • SREが開発におけるボトルネックになってしまう • 機能やモニタリング範囲拡大による監視コストの増加 課題
34. 34 CONFIDENTIAL © 2022 CoDMON Inc. 34 現在 DatadogからNewRelicに移行 • SREがボトルネックにならず、各開発チームが自律的に動ける体制が必要 • 担当のコンサルタントがつき、初期導入のオンボーディングや、導入後も TAMがついてくれるなどサポート体制が充実 • SREが介在せずに開発チームが直接サポートとやりとりできるため、新し い機能の導入や改善の動きを開発チームが自律的に行える体制
35. 35 CONFIDENTIAL © 2022 CoDMON Inc. 35 現在 ログ管理方法の見直し • すべてのログはFluentdを利用しS3へ直接保存し、 監視が必要なアプリケーションログだけNewRelicへ送信する仕組みに • ログレベルによる送信先の判断を容易にできるよう、アプリケーションロ グのレベルの改善を推進
36. 36 CONFIDENTIAL © 2022 CoDMON Inc. 36 現在 AWSコストの可視化 • 何にコストがかかっているのか、どうコストが変動したのかわかりにくい • Cost and Usage ReportをS3に保持することでRedash経由で参照 • 前月とのサービス毎のコスト変動や、タグを用いてサービス単位での コストを可視化 • 開発内だけではなく、ビジネス側の数字の判断材料としても利用可能に
37. 37 CONFIDENTIAL © 2022 CoDMON Inc. 37 現在
38. 38 今日話すこと オブザーバビリティとは フェーズにおける改善の取り組み 今後 まとめ 1 2 3 4
39. 39 CONFIDENTIAL © 2022 CoDMON Inc. 39 オブザーバビリティ成熟度モデル 『オブザーバビリティの成熟度モデルと 監視からオブザーバビリティへ』https://speakerdeck.com/newrelic2023/20230523-findy-newrelic-o11y1 成熟度 特徴 KPI 予測的 積極的 受動的
40. 40 CONFIDENTIAL © 2022 CoDMON Inc. 40 オブザーバビリティ成熟度モデル 成熟度 特徴 KPI 予測的 積極的 受動的 『オブザーバビリティの成熟度モデルと 監視からオブザーバビリティへ』https://speakerdeck.com/newrelic2023/20230523-findy-newrelic-o11y1
41. 41 今日話すこと オブザーバビリティとは フェーズにおける改善の取り組み 今後 まとめ 1 2 3 4
42. 42 CONFIDENTIAL © 2022 CoDMON Inc. 42 まとめ • サービスや組織の規模に適したオブザーバビリティツールを選択し、 変化するニーズに対応しながら継続的に改善してきた • すべてのデータを取得・管理するのが理想的だが、 比例してコストは肥大化するので、データの重要度やリアルタイム性を 考慮して、コストバランスをとりながら管理することが大切と感じた • オブザーバビリティはツールの導入がゴールではなく、ツールを活用する 文化の醸成を意識しながら導入を進めることで、はじめて効果がでる • 今後も日々の改善を重ねながら、サービスの信頼性を高めて行きたい
43. 43 終わりに
44. 44 コドモン採用ページ 開発ブログ コドモンでは一緒に働きたい仲間を募集しています！
45. 45 ご清聴ありがとうございました！