2025.09.18 渋⾕でビール⽚⼿に第3⽊曜LT会! srest プロダクトオーナー 兼 SRE マネジャー ⼭北 尚道 SRE が駆動するプロダクト品質と アーキテクチャ進化の仕組み 

© Metaps Holdings, Inc. ⾃⼰紹介 ベトナム‧ハノイでのオフショア事業⽴ち上げからキャリアをスタートし、 アプリケーション開発からマネジメントまでを経験 2015 年に当社参画。徐々にクラウドインフラにも携わり、現在は横断的な テックリードや SRE チーフエンジニアとして従事 「AWS DevDay Tokyo」登壇、「Amazon Web Services ブログ」、 「builders.flash」寄稿、「Community Builder」メンバーなど 昨年より SRE のためのダッシュボード「srest」プロダクトオーナーを兼任 ⼭北 尚道 株式会社メタップスホールディングス srest プロダクトオーナー 兼 SRE マネジャー Naomichi Yamakita ＠sre_yamakita 2 

AWS コスト管理ツール「スレスト」 srest は AWS ファンデーショナルテクニカ ルレビュー (FTR) の認定ソフトウェアです 

© Metaps Holdings, Inc. 4 srest とは ● AWS アカウント運⽤における コスト管理の⼿間を削減 するサービス ○ 複数の AWS コスト関連サービスを組み合わせ、シンプルで使いやすいダッシュボードで AWS コストデータを多⾓的に可視化 ○ 詳細なコスト分析を⾏うことができ、継続的な AWS コスト最適化 を⽀援 

srest は SRE チームから⽣まれたプロダクト ● 社内外含め、複数のプロダクトを SRE チームが横断して管理 ● AWS や Datadog、PagerDuty など、様々 なサービスから通知されるイベントログ を⼀元的に管理するため内製で作られた ● srest = SRE + Rest (SRE を休ませる) とい う造語 

コスト可視化へのシフトチェンジ ● AWS を横断的に管理する上で、各 プロダ クトの運⽤にかかるコストの可視化 が必 要に ● AWS 請求アカウントでアカウントごとの コストデータは確認できるが、別の Organization のコストを⾒るにはアカウ ントの切り替え作業が発⽣してしまう 

© 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 の可視化‧詳細分析機能⽐較 

© Metaps Holdings, Inc. ● コンテナオーケストレーション ○ ECS? EKS? ● オブザーバビリティ ○ CloudWatch? Datadog? New Relic? ● デプロイメント ○ Rolling Update? Blue-Green? Canary? ● IaC ○ CloudFormation? Terraform? CDK? ● ログ管理 ○ CloudWatch? S3? 技術選定はどうしてますか? (AWS) 

© Metaps Holdings, Inc. srest のケース ● srest の SRE チームでは、プロダクトの成⻑段階と要件に応じて 段階的に技術選定 を ⾏っている ● 初期フェーズでは開発速度を重視し、運⽤コストが低く学習コストの低い技術 を採⽤ ● データ量の増加やパフォーマンス要件の変化に応じて、過度な先⾏設計を避けつつ、 実際の課題が明確になった適切なタイミングでリアーキテクト を実施 

● アーキテクチャ設計 ● IaC ● CI/CD ● セキュリティ ● オブザーバビリティ ● 運⽤‧オンコール体制 ● BI ツールの選定 ● 開発⾔語の選定 ● フレームワークの選定 ● 開発規約の作成 ● API 設計 ● データベース設計 ● アプリケーションの実装 ● テストツール導⼊ srest はインフラ基盤‧開発含め SRE チームで設計 

© Metaps Holdings, Inc. ● 開発時間の確保 ○ SRE は 稼働時間の 20〜50% を開発 に割き、プロダクトの改善に直接貢献 ● 仕組み理解による信頼性向上 ○ アプリケーションの構成や仕組みを深く理解し、運⽤‧監視‧可⽤性設計に フィードバック ● ダッシュボード活⽤で課題抽出 ○ ⽇常的にダッシュボードを活⽤し、プロダクトのボトルネックを可視化 SRE が開発に携わる上でのガイドライン 

プロトタイプ アーキテクチャ (2023年) ● AWS や Datadog のイベントをトリガーと するイベント駆動アプリケーション ● システムの特性上、アプリケーションとイ ンフラが密に連携するため、インフラ基盤 は Terraform、アプリケーションと連携す るエンドポイントは Serverless Framework で実装 ● イベントは突発的なスパイクアクセスが発 ⽣するため、ECS ではなくスケーラビリ ティの⾼い Kinesis + Lambda 構成 を採 ⽤ 

サービスローンチ後のアーキテクチャ (2024年) ● DocumentDB は初期フェーズで開発コス トが低かったものの、扱うイベントデー タが増えるにつれパフォーマンスがボトル ネックに ● ⼤規模な時系列ログを柔軟に検索できる OpenSearch Service への移⾏ を⾏う 

DWH への移⾏ (2025年) ● srest が扱う AWS のコストデータは CUR (Cost and Usage Reports) 形式。AWS の 利⽤形態にもよるが、1 年あたり 1 アカウ ント数百万〜数千万レコードのデータ量 となる ● OpenSearch で⼤規模なデータを⾼速に書 き込むにはシャーディング + Bulk API と なるが、費⽤感の割に⾼スループットは出 しづらい ● 今⽉より、ClickHouse への移⾏検証 を開 始 

● 列指向データベース (OLAP) のため⾼速な 集計が可能 ○ 分析クエリで必要な列のみを読み込むた め、⾏指向 DB と⽐較して⼤幅に⾼速 ● ⼀般的な SQL 構⽂が使える ○ 標準 SQL に近い構⽂でクエリ可能、学習 コストが低い ● ⾼速なリアルタイム検索 ○ 数⼗億⾏のレコードに対しても秒未満での 応答が可能。Materialized Views を作成す ることで、複雑な集計結果を事前計算して 保存し、重い集計処理でも瞬時に結果を取 得可能 ClickHouse の特徴 

© Metaps Holdings, Inc. データ基盤の移⾏選定理由 データ基盤 選定理由 移行理由 DocumentDB * ログデータを柔軟に扱いたい * マスターデータを扱える * 導入、月額コストが低い * メモリの使用効率 * マスターデータの運用コスト OpenSearch Service * 時系列ログを柔軟に扱える * コスト機能においては、書き込み速度 がボトルネックとなる * 月額コスト ClickHouse * 列指向のため、コスト機能 (Parquet データ) との相性が良い * 大規模集計を効率的に行える プロトタイプ (2023年) ログ機能 (2024年) コストの横断 (2025年) 

© Metaps Holdings, Inc. ● 重要なのは「完璧な技術選定」を最初から⽬指すのではなく、現在の課題を解決しつ つ、将来の拡張性も考慮した段階的なアプローチ ● SRE の視点から、運⽤‧監視‧コスト の観点も含めて総合的に判断し、必要に応じて ⼤胆にアーキテクチャを⾒直すことで、持続可能なプロダクト開発を実現 する プロダクト成⻑に合わせたリアーキテクト戦略 

ご清聴ありがとうございました