Tweet
Tweet

Slide 1

Slide 1 text

© DMM.com モダンとレガシーが混在する DMMブックスで培った SRE Practices 合同会社 DMM.com SRE部 小野 博志 2022/05/15

Slide 2

Slide 2 text

© 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を社内に広める活動も合わせて実施している。

Slide 3

Slide 3 text

© DMM.com アジェンダ 3 • SLI/SLOにCore Web Vitalsも加えた話 • NewRelicへのログ出力をCloudWatch Logsを経由しないようにしコストを下げた話 • 検証環境を自動構築できるようにした話

Slide 4

Slide 4 text

© DMM.com DMMのSRE体制 4

Slide 5

Slide 5 text

© 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部が 一体になって日々の活動に取り組んでいる

Slide 6

Slide 6 text

© DMM.com 話題のコミックや小説などを パソコンやスマホで 読めるプラットフォーム コミック、雑誌、小説、写真集等の電子書籍を配信しております。現在は 67万冊以上の作品を取り揃えており、 さまざまなジャンルの作品を提供しています。

Slide 7

Slide 7 text

© DMM.com 今だけ！お得な70%OFFクーポンがあります

Slide 8

Slide 8 text

© DMM.com SLI/SLOの拡充 8

Slide 9

Slide 9 text

© DMM.com 背景 9 • かねてからユーザから表示が遅いとのフィードバックがあった。 • そのため、速度改善も兼ねてモノリスからマイクロサービスへチャレンジすることになった。 • 一旦は、主要ページに留めてFE/BE分離、非同期通信による改善を行いページ表示速度は明らかに 改善されたが実際どれくらいのユーザが満足できているのかは分かっていなかった

Slide 10

Slide 10 text

© DMM.com 現状はどうなっていたか 10 シンセティック監視（いわゆる外形監視）で主要ペー ジのレスポンスタイムを測定しているだけだった。

Slide 11

Slide 11 text

© DMM.com SLI/SLOとは 11 • SLI • サービスレベル指標の略 • 提供しているサービスのレベルを測るための定量的な値 • SLO • サービスレベル目標の略 • 設定したSLIに基づいてサービスとして目標とする値 サービスが 正常でない 状態になったとき、それを正常に戻すためのトリガーとするため

Slide 12

Slide 12 text

© 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/

Slide 13

Slide 13 text

© DMM.com データは既に貯めていた 13 • DMMブックスではNewRelicでモニタリングを行っており、データ自体はすでに溜め込んでいた。ただ し、NewRelicでは8日間のデータしかなかったため、Metric Aggregatorで長期トレンドへと変換した

Slide 14

Slide 14 text

© DMM.com 結果 14 • デバイス別、回線別(Wi-Fi/SIM)など多角的な分析が出来、改善すべきページが明らかになった。 • デプロイとCore Web Vitalsを紐付けることでCore Web Vitalsに影響を与えるリリース内容が分析でき るようになった。 • そして、感覚的に持っていたユーザが不満を持っているページが明らかになった。

Slide 15

Slide 15 text

© DMM.com 結果（２） 15 • Core Web Vitalsの一部の指標は日々の朝会で確認し、悪化があれば原因を調査している

Slide 16

Slide 16 text

© DMM.com CloudWatch Logsから NewRelic Logsへ 16

Slide 17

Slide 17 text

© DMM.com 背景 17 • DMMブックスは多くの機能をAWS上で構築しているが、サービスが成長するにつれて全体コストに対 してCloudWach Logsの費用が大きくなっていった。 • 調べてみるとDataProcessing-Bytesが大きなコストを占めており、更に読み解くと、PutLogEvents で ありログを登録する場合にかかる費用であることも分かった。

Slide 18

Slide 18 text

© DMM.com コストが掛かっていた理由 18 CloudWatch Logs アプリケーション newrelic-log-ingestion CloudWatch LogsへのPutEventに多くのコストが掛かっていた ロググループ単位で集計するとアプリケーションが稼働しているアクセスログおよびアプリケーションロ グで多くのコストが掛かっており、更にログの保管ではなく登録に多くのコストが掛かっていた。元々ロ グ検索はNewRelicを使っておりログの保存でのみ使っていた

Slide 19

Slide 19 text

© DMM.com CloudWatch Logsの料金 19 収集（データの取り込み）：0.76USD/GB 保存（アーカイブ）：0.033USD 意外と割高な料金設定となっている

Slide 20

Slide 20 text

© DMM.com CloudWatch Logsを利用しない構成へ 20 アプリケーション FireLens Kinesis Data Streams S3 CoudWatchを経由せずにKinesis Data Streams(+S3バックアップ）へ変更したところ、運用を変えず にコスト削減を実現できた

Slide 21

Slide 21 text

© DMM.com 結果 21 当初Kinesis FirehoseのVPCエンドポイントを作成してなかったため、NATGatewayのコストがかさみ、 コスト削減効果はほぼ無いと思われたが、VPCエンドポイントを作成したところ、約４割減のコスト削減 に繋がった。

Slide 22

Slide 22 text

© DMM.com ECS での検証環境の 自動構築 22

Slide 23

Slide 23 text

© DMM.com 背景 23 • DMMブックスでは拡大するチーム・プロジェクトに対してそれぞれステージング環境とは別に検証環境 が必要であり、その構築に一定のコストが掛かっていました。そのためブランチごとに検証環境が自動 構築される仕組みを用意する必要がありました

Slide 24

Slide 24 text

© DMM.com Stagingと 共通 作成した仕組み 24 push stg/**** CIの実行 CodePipline CircleCI CodeBuild 自動構築範囲 アプリケーション FireLens アプリケーションのデプロイ TerraformによりAWSリソースの作成 検証環境として ALBを１つ用意 土日はタスクを止めて コスト削減

Slide 25

Slide 25 text

© DMM.com 考慮した点 25 • データストアはステージングと共通のものを利用する • 弊社のステージング環境はユーザ系のデータ以外、ほぼ本番と同等のデータが格納されており、 これはテストにおいて重要な意味を持ちます。このデータを利用したくデータストア系のものはス テージングと共通にすることにしました • ALBは１つ作成し、すべての検証環境は同一のALBを利用してリスナーで振り分ける • ６０環境ほど検証環境が必要であり、ALBまで作成してしまうとコストが嵩むため • EventBridge+Lambdaの組合せで土日はECS Serviceのタスクを０にし費用がかからない仕組みにし た

Slide 26

Slide 26 text

© DMM.com 今後取り組みたい点 26 • 現状は本番環境と同じECS Fargateで構築したが、やはり60環境(約240サーバ)もあると検証環境だ けでもかなりのコストが掛かる。この点はECS on EC2に変えることで、さらなる最適化を目指していき たい • そう多くないが、データストアの変更が必要、かつ互換性が無い場合はこの仕組では検証することがで きないため、そのパターンでも自動構築にチャレンジしていきたい

Slide 27

Slide 27 text

© DMM.com まとめ 27

Slide 28

Slide 28 text

© DMM.com まとめ 28 • Core Web VitalsはSEOとしても評価されるため、この数字を追いかけることはビジネス的にもSRE的 にも双方わかりやすく、かつ定量的に図れるもののためメリットは大きかった。 • ECSのログ出力先としてCloudWatch Logsは簡易に導入ができ、一定の利便性もあるが規模が大き くなるとどうしてもコストが嵩むため、規模が大きなサービスは使わない方がおすすめであることが分 かった。