SRE が駆動するプロダクト品質と アーキテクチャ進化の仕組み

Transcript

1. 2025.09.18 渋⾕でビール⽚⼿に第3⽊曜LT会! srest プロダクトオーナー 兼 SRE マネジャー ⼭北 尚道 SRE が駆動するプロダクト品質と アーキテクチャ進化の仕組み
2. © Metaps Holdings, Inc. ⾃⼰紹介 ベトナム‧ハノイでのオフショア事業⽴ち上げからキャリアをスタートし、 アプリケーション開発からマネジメントまでを経験 2015 年に当社参画。徐々にクラウドインフラにも携わり、現在は横断的な テックリードや SRE チーフエンジニアとして従事 「AWS DevDay Tokyo」登壇、「Amazon Web Services ブログ」、 「builders.flash」寄稿、「Community Builder」メンバーなど 昨年より SRE のためのダッシュボード「srest」プロダクトオーナーを兼任 ⼭北 尚道 株式会社メタップスホールディングス srest プロダクトオーナー 兼 SRE マネジャー Naomichi Yamakita ＠sre_yamakita 2
3. AWS コスト管理ツール「スレスト」 srest は AWS ファンデーショナルテクニカ ルレビュー (FTR) の認定ソフトウェアです
4. © Metaps Holdings, Inc. 4 srest とは • AWS アカウント運⽤における コスト管理の⼿間を削減 するサービス ◦ 複数の AWS コスト関連サービスを組み合わせ、シンプルで使いやすいダッシュボードで AWS コストデータを多⾓的に可視化 ◦ 詳細なコスト分析を⾏うことができ、継続的な AWS コスト最適化 を⽀援
5. srest は SRE チームから⽣まれたプロダクト • 社内外含め、複数のプロダクトを SRE チームが横断して管理 • AWS や Datadog、PagerDuty など、様々 なサービスから通知されるイベントログ を⼀元的に管理するため内製で作られた • srest = SRE + Rest (SRE を休ませる) とい う造語
6. コスト可視化へのシフトチェンジ • AWS を横断的に管理する上で、各 プロダ クトの運⽤にかかるコストの可視化 が必 要に • AWS 請求アカウントでアカウントごとの コストデータは確認できるが、別の Organization のコストを⾒るにはアカウ ントの切り替え作業が発⽣してしまう
7. © Metaps Holdings, Inc. 可視化 詳細分析 AWS Cost Explorer 操作が簡単で素早くデータを確認可能。データ保 持期間はデフォルトで 13 ヶ⽉。 AWS Data Exports (CUR 2.0) AWS Cost Categories コストの⽣データを CSV や、Amazon QuickSight に連携す る形で提供。Cost Categories や Budgets と連携すること で、コストの按分やアラート通知も可能。 コストアナリティクス 必要最⼩限の機能に絞り開発者以外にも分かりやすい UI を提供。データ保持は 13 ヶ⽉以上可能 コストアロケーション コストの取り込みから 可視化、按分、 アラート通知 までを⼀元管理。 異常検知 AWS Budgets AWS Cost Anomaly Detection Amazon SNS アカウント単位での異常検知が可能。 Amazon SNS と連携することで通知も可能。 コストインサイト AWSサービスごとのコスト異常を⾃動で検知し通知。コ スト上昇を早期発⾒ し、原因特定の⼯数を削減。 AWS と srest の可視化‧詳細分析機能⽐較
8. © Metaps Holdings, Inc. • コンテナオーケストレーション ◦ ECS? EKS? • オブザーバビリティ ◦ CloudWatch? Datadog? New Relic? • デプロイメント ◦ Rolling Update? Blue-Green? Canary? • IaC ◦ CloudFormation? Terraform? CDK? • ログ管理 ◦ CloudWatch? S3? 技術選定はどうしてますか? (AWS)
9. © Metaps Holdings, Inc. srest のケース • srest の SRE チームでは、プロダクトの成⻑段階と要件に応じて 段階的に技術選定 を ⾏っている • 初期フェーズでは開発速度を重視し、運⽤コストが低く学習コストの低い技術 を採⽤ • データ量の増加やパフォーマンス要件の変化に応じて、過度な先⾏設計を避けつつ、 実際の課題が明確になった適切なタイミングでリアーキテクト を実施
10. • アーキテクチャ設計 • IaC • CI/CD • セキュリティ • オブザーバビリティ • 運⽤‧オンコール体制 • BI ツールの選定 • 開発⾔語の選定 • フレームワークの選定 • 開発規約の作成 • API 設計 • データベース設計 • アプリケーションの実装 • テストツール導⼊ srest はインフラ基盤‧開発含め SRE チームで設計
11. © Metaps Holdings, Inc. • 開発時間の確保 ◦ SRE は 稼働時間の 20〜50% を開発 に割き、プロダクトの改善に直接貢献 • 仕組み理解による信頼性向上 ◦ アプリケーションの構成や仕組みを深く理解し、運⽤‧監視‧可⽤性設計に フィードバック • ダッシュボード活⽤で課題抽出 ◦ ⽇常的にダッシュボードを活⽤し、プロダクトのボトルネックを可視化 SRE が開発に携わる上でのガイドライン
12. プロトタイプ アーキテクチャ (2023年) • AWS や Datadog のイベントをトリガーと するイベント駆動アプリケーション • システムの特性上、アプリケーションとイ ンフラが密に連携するため、インフラ基盤 は Terraform、アプリケーションと連携す るエンドポイントは Serverless Framework で実装 • イベントは突発的なスパイクアクセスが発 ⽣するため、ECS ではなくスケーラビリ ティの⾼い Kinesis + Lambda 構成 を採 ⽤
13. サービスローンチ後のアーキテクチャ (2024年) • DocumentDB は初期フェーズで開発コス トが低かったものの、扱うイベントデー タが増えるにつれパフォーマンスがボトル ネックに • ⼤規模な時系列ログを柔軟に検索できる OpenSearch Service への移⾏ を⾏う
14. DWH への移⾏ (2025年) • srest が扱う AWS のコストデータは CUR (Cost and Usage Reports) 形式。AWS の 利⽤形態にもよるが、1 年あたり 1 アカウ ント数百万〜数千万レコードのデータ量 となる • OpenSearch で⼤規模なデータを⾼速に書 き込むにはシャーディング + Bulk API と なるが、費⽤感の割に⾼スループットは出 しづらい • 今⽉より、ClickHouse への移⾏検証 を開 始
15. • 列指向データベース (OLAP) のため⾼速な 集計が可能 ◦ 分析クエリで必要な列のみを読み込むた め、⾏指向 DB と⽐較して⼤幅に⾼速 • ⼀般的な SQL 構⽂が使える ◦ 標準 SQL に近い構⽂でクエリ可能、学習 コストが低い • ⾼速なリアルタイム検索 ◦ 数⼗億⾏のレコードに対しても秒未満での 応答が可能。Materialized Views を作成す ることで、複雑な集計結果を事前計算して 保存し、重い集計処理でも瞬時に結果を取 得可能 ClickHouse の特徴
16. © Metaps Holdings, Inc. データ基盤の移⾏選定理由 データ基盤 選定理由 移行理由 DocumentDB * ログデータを柔軟に扱いたい * マスターデータを扱える * 導入、月額コストが低い * メモリの使用効率 * マスターデータの運用コスト OpenSearch Service * 時系列ログを柔軟に扱える * コスト機能においては、書き込み速度 がボトルネックとなる * 月額コスト ClickHouse * 列指向のため、コスト機能 (Parquet データ) との相性が良い * 大規模集計を効率的に行える プロトタイプ (2023年) ログ機能 (2024年) コストの横断 (2025年)
17. © Metaps Holdings, Inc. • 重要なのは「完璧な技術選定」を最初から⽬指すのではなく、現在の課題を解決しつ つ、将来の拡張性も考慮した段階的なアプローチ • SRE の視点から、運⽤‧監視‧コスト の観点も含めて総合的に判断し、必要に応じて ⼤胆にアーキテクチャを⾒直すことで、持続可能なプロダクト開発を実現 する プロダクト成⻑に合わせたリアーキテクト戦略
18. ご清聴ありがとうございました