モダンとレガシーが混在するDMMブックスで培った SRE Practices

Transcript

1. © DMM.com モダンとレガシーが混在する DMMブックスで培った SRE Practices 合同会社 DMM.com SRE部 小野 博志 2022/05/15
2. © DMM.com 自己紹介 2 小野 博志 / Ono Hiroshi 合同会社DMM.com ITインフラ本部 SRE部 エンジニアリングマネージャー Facebook: https://www.facebook.com/onohiroshi2 ２００５年に新卒で中小独立系 Slerに入社。Javaを使ったWeb系開発に従事。 ２００８年よりMSP（マネージド・サービス・プロバイダ）の業務に従事。アカウント SEから始ま り、サービス企画やテクニカルディレクターを務める。 エンタープライズの領域 で大規模なコー ポレートサイト、WebCMSを中心として担当していた。 ２０２０年にDMM.comに入社し、DMMブックスを中心に複数のサービスを SREとして担当しつ つ、NewRelicを社内に広める活動も合わせて実施している。
3. © DMM.com アジェンダ 3 • SLI/SLOにCore Web Vitalsも加えた話 • NewRelicへのログ出力をCloudWatch Logsを経由しないようにしコストを下げた話 • 検証環境を自動構築できるようにした話
4. © DMM.com DMMのSRE体制 4
5. © DMM.com 横断組織としてのSRE部とSREチーム 5 事業部 動画 電子書籍 プラットフォーム Team A Team B Team C Team A Team B SRE Team Team A Team B SRE Team SRE部 セキュリティ部など横断組織 コーポレート組織 コーポレート 人事・総務 など DMMブックスでは電子書籍事業部の SREチームとSRE部が 一体になって日々の活動に取り組んでいる
6. © DMM.com 話題のコミックや小説などを パソコンやスマホで 読めるプラットフォーム コミック、雑誌、小説、写真集等の電子書籍を配信しております。現在は 67万冊以上の作品を取り揃えており、 さまざまなジャンルの作品を提供しています。
7. © DMM.com 今だけ！お得な70%OFFクーポンがあります
8. © DMM.com SLI/SLOの拡充 8
9. © DMM.com 背景 9 • かねてからユーザから表示が遅いとのフィードバックがあった。 • そのため、速度改善も兼ねてモノリスからマイクロサービスへチャレンジすることになった。 • 一旦は、主要ページに留めてFE/BE分離、非同期通信による改善を行いページ表示速度は明らかに 改善されたが実際どれくらいのユーザが満足できているのかは分かっていなかった
10. © DMM.com 現状はどうなっていたか 10 シンセティック監視（いわゆる外形監視）で主要ペー ジのレスポンスタイムを測定しているだけだった。
11. © DMM.com SLI/SLOとは 11 • SLI • サービスレベル指標の略 • 提供しているサービスのレベルを測るための定量的な値 • SLO • サービスレベル目標の略 • 設定したSLIに基づいてサービスとして目標とする値 サービスが 正常でない 状態になったとき、それを正常に戻すためのトリガーとするため
12. © DMM.com Core Web Vitalsの導入 12 • Core Web Vitalsとは • Googleが提唱するユーザ体験の満足度につながる指標のこと。以下の３つが定義されている。 • 読み込み時間（Largest Contentful Paint） • インタラクティブ性（First Input Delay） • ページコンテンツの視覚的な安定性（Cumulative Layout Shift） 引用：https://web.dev/vitals-business-impact/
13. © DMM.com データは既に貯めていた 13 • DMMブックスではNewRelicでモニタリングを行っており、データ自体はすでに溜め込んでいた。ただ し、NewRelicでは8日間のデータしかなかったため、Metric Aggregatorで長期トレンドへと変換した
14. © DMM.com 結果 14 • デバイス別、回線別(Wi-Fi/SIM)など多角的な分析が出来、改善すべきページが明らかになった。 • デプロイとCore Web Vitalsを紐付けることでCore Web Vitalsに影響を与えるリリース内容が分析でき るようになった。 • そして、感覚的に持っていたユーザが不満を持っているページが明らかになった。
15. © DMM.com 結果（２） 15 • Core Web Vitalsの一部の指標は日々の朝会で確認し、悪化があれば原因を調査している
16. © DMM.com CloudWatch Logsから NewRelic Logsへ 16
17. © DMM.com 背景 17 • DMMブックスは多くの機能をAWS上で構築しているが、サービスが成長するにつれて全体コストに対 してCloudWach Logsの費用が大きくなっていった。 • 調べてみるとDataProcessing-Bytesが大きなコストを占めており、更に読み解くと、PutLogEvents で ありログを登録する場合にかかる費用であることも分かった。
18. © DMM.com コストが掛かっていた理由 18 CloudWatch Logs アプリケーション newrelic-log-ingestion CloudWatch LogsへのPutEventに多くのコストが掛かっていた ロググループ単位で集計するとアプリケーションが稼働しているアクセスログおよびアプリケーションロ グで多くのコストが掛かっており、更にログの保管ではなく登録に多くのコストが掛かっていた。元々ロ グ検索はNewRelicを使っておりログの保存でのみ使っていた
19. © DMM.com CloudWatch Logsの料金 19 収集（データの取り込み）：0.76USD/GB 保存（アーカイブ）：0.033USD 意外と割高な料金設定となっている
20. © DMM.com CloudWatch Logsを利用しない構成へ 20 アプリケーション FireLens Kinesis Data Streams S3 CoudWatchを経由せずにKinesis Data Streams(+S3バックアップ）へ変更したところ、運用を変えず にコスト削減を実現できた
21. © DMM.com 結果 21 当初Kinesis FirehoseのVPCエンドポイントを作成してなかったため、NATGatewayのコストがかさみ、 コスト削減効果はほぼ無いと思われたが、VPCエンドポイントを作成したところ、約４割減のコスト削減 に繋がった。
22. © DMM.com ECS での検証環境の 自動構築 22
23. © DMM.com 背景 23 • DMMブックスでは拡大するチーム・プロジェクトに対してそれぞれステージング環境とは別に検証環境 が必要であり、その構築に一定のコストが掛かっていました。そのためブランチごとに検証環境が自動 構築される仕組みを用意する必要がありました
24. © DMM.com Stagingと 共通 作成した仕組み 24 push stg/**** CIの実行 CodePipline CircleCI CodeBuild 自動構築範囲 アプリケーション FireLens アプリケーションのデプロイ TerraformによりAWSリソースの作成 検証環境として ALBを１つ用意 土日はタスクを止めて コスト削減
25. © DMM.com 考慮した点 25 • データストアはステージングと共通のものを利用する • 弊社のステージング環境はユーザ系のデータ以外、ほぼ本番と同等のデータが格納されており、 これはテストにおいて重要な意味を持ちます。このデータを利用したくデータストア系のものはス テージングと共通にすることにしました • ALBは１つ作成し、すべての検証環境は同一のALBを利用してリスナーで振り分ける • ６０環境ほど検証環境が必要であり、ALBまで作成してしまうとコストが嵩むため • EventBridge+Lambdaの組合せで土日はECS Serviceのタスクを０にし費用がかからない仕組みにし た
26. © DMM.com 今後取り組みたい点 26 • 現状は本番環境と同じECS Fargateで構築したが、やはり60環境(約240サーバ)もあると検証環境だ けでもかなりのコストが掛かる。この点はECS on EC2に変えることで、さらなる最適化を目指していき たい • そう多くないが、データストアの変更が必要、かつ互換性が無い場合はこの仕組では検証することがで きないため、そのパターンでも自動構築にチャレンジしていきたい
27. © DMM.com まとめ 27
28. © DMM.com まとめ 28 • Core Web VitalsはSEOとしても評価されるため、この数字を追いかけることはビジネス的にもSRE的 にも双方わかりやすく、かつ定量的に図れるもののためメリットは大きかった。 • ECSのログ出力先としてCloudWatch Logsは簡易に導入ができ、一定の利便性もあるが規模が大き くなるとどうしてもコストが嵩むため、規模が大きなサービスは使わない方がおすすめであることが分 かった。