シェア
はてブ
2024年6月28日、ファインディ株式会社が主催するイベント「開発生産性Conference 2024」が開催されました。本記事では、New Relic株式会社 ソリューションコンサルタントの板谷 郷司さんと、合同会社DMM.com ITインフラ本部 SRE部の湯浅 省吾さんによるセッション「開発生産性向上のための監視運用の改善」の内容をお届けします。
本セッションでは、板谷さんから開発生産性やNew Relicについてお話しいただいた後、湯浅さんからDMM.comにおけるNew Relicの活用事例についてお話しいただいています。また、セッション最後には、板谷さんから湯浅さんへのインタビューが行われました。
■プロフィール
板谷 郷司（いたたに さとし）
New Relic株式会社 ソリューションコンサルタント
長年インフラエンジニアとして従事。オンプレミスおよびクラウドでの大規模Webインフラの設計、構築、運用を専門とする。物理、ネットワークからアプリまで幅広い開発構築経験もあり、バックエンド全体の知識を有する。最近のブームはIoT鉄道模型。
湯浅 省吾（ゆあさ しょうご）
合同会社DMM.com ITインフラ本部 SRE部
SIerにて金融系、社会インフラ系サービスなどでオンプレのアプリケーション基盤の設計・構築などに携った後、2019年6月にDMM.comに入社。社内システムのオンプレからAWSへの移行支援やCI/CD環境の整備、オブザーバビリティの向上など、システムの信頼性向上のためのさまざまな支援を行なっている。猫が好き。
オブザーバビリティプラットフォームを提供するNew Relic
板谷：まずは私、New Relicの板谷からお話をさせていただきます。板谷と申しまして、PHPカンファレンスで実行委員長を務めたりしています。実はもともとDMM.comにいた過去もあり、インフラからアプリまでいろいろなところに携わってきました。最近はラズパイなどを使って、家で開発したりもしています。
板谷：ではさっそく、本題の方に入りたいと思います。今回、「開発生産性Conference」というイベントですので、実際に開発生産性が高い状態とは、どういったことを指しているのかといった内容からお話ししたいと思います。
開発者の方々はいろいろな機能をつくるなど、開発に専念できるのが理想的な状態かと思います。そして、開発された機能が頻繁にリリースされ、リリース時に障害なく安定稼働している。それによって、さらにまた次の機能の開発に専念できるという、いわゆるDevOpsのサイクルが滞りなく回っている状態が、開発生産性が高い状態だと言えるでしょう。
板谷：ただ、実際にはリリース後に障害が発生してしまうというのは、よくあることかと思います。障害が起こるほど、開発の方々が保守運用や障害復旧にリソースを割くことになり、開発に専念できるリソースがどんどん減って、リリースが滞るという負のスパイラルに陥ってしまいます。つまり、DevOpsのサイクルを正しく回すことができない状況が発生します。
そういったDevOpsのサイクルを正常化するアプローチとして、稼働状況を見ながら品質向上に取り組み、障害を減らしていく。そして、障害が発生した際には、すぐに気づける状態をつくっていくことが重要です。
また、問題を把握するのに必要な情報が集約されていたり、問題の原因特定が誰でも簡単に特定できたりすることが理想で、そういったところにNew Relicが貢献させていただいています。
板谷：New Relicは、オブザーバビリティ（可観測性）を提供するプラットフォームで、ビジネス、ユーザー体験、システムなどからさまざまなデータを集約し、可視化を行います。もともとは熟練のエンジニアが独自の方法で実施することが多かった部分だと思いますが、可視化によりシステムの問題にすぐ気づき、素早く原因にたどり着くことが可能になります。
問題解決フローの改善例として、障害発生後にクレームが発生し、そこから原因特定に数日、場合によっては1ヶ月以上かかっていたところが、障害発生の予兆を検知し、クレームを発生させることなく、原因特定にかかる時間を83%削減できたというデータがあります。
このようにNew Relicを活用することで、クレームや障害が発生する前に対処し、ユーザー体験を損なうことなく、かつ新規開発やテストに集中してより良い状態をつくっていただくことができます。では、ここから実際にDMM.comさんでNew Relicをどのように活用をいただいているか、湯浅さんからお話しいただきます。よろしくお願いいたします。
多岐にわたるサービスへの支援を行うDMM.com SRE部
湯浅：DMM.com ITインフラ本部 SRE部に所属している、湯浅と申します。DMMオンラインサロンやDMM通販などで、SREとしてサービスの信頼性向上やAWS関連の技術支援などを行っています。
今回、DMMオンラインサロンでNew Relicを導入したので、その中でどのように監視運用を改善していったのか、その結果どのように開発生産性が向上したのかについてお話できればと思います。
湯浅：まずDMM.comがどういう会社なのかというと、「何でもやってる会社です」という回答になるかと思います。有名なところで言うと、例えばサッカーチームの経営をやっていたり、電子書籍をやっていたり、それから3Dプリントをやっていたりなど、ありとあらゆるところでいろいろなサービスを提供している会社です。
その中で、今回事例としてご紹介するDMMオンラインサロンについて、簡単に触れたいと思います。DMMオンラインサロンは、オンラインサロンやファンクラブの新しいカタチを目指して提供している、日本最大級の「学べる・楽しめる」会員制コミュニティサービスです。
DMMオンラインサロンの中には、大きく2つのシステムがあります。今回事例として紹介するシステムをメインに取り上げますが、1つはオンラインサロンの入会/管理システムで、こちらはオンラインサロンに入りたいユーザーさんの入口になるサイトです。
どのようなサロンがあるか載っていたり、サロンを検索できたり、実際に入会して課金するページがあったりします。管理システムとしては、オーナーさんがオンラインサロンを管理する仕組み、それからDMM.com社内で管理するための仕組みがあります。
もう1つのシステムは、オンラインサロンのコミュニティツールですね。こちらはサロンのオーナーさんとメンバーがクローズドなところでやり取りできたり、オーナーさんが配信した動画をメンバーが見たりできるもので、スマホのアプリとして動いています。
続いて、SRE部の業務についても簡単にご紹介しておきたいと思います。SRE部では、「DMM.comのすべてのサービスとインフラストラクチャを、ソフトウェアの力で最適化する」というミッションを掲げており、先ほど紹介したさまざまなサービスを多岐にわたって支援しています。
SRE部は大きく2つのチームで活動しています。1つは事業支援チームで、DMMオンラインサロンを始めとして、さまざまなサービスの技術支援を行っています。もう1つが信頼性向上チームで、こちらはSLOの導入推進や自動化の推進、トイル削減など、全社横断的に信頼性を高める動きをしているチームです。
湯浅：ここからは、DMMオンラインサロンでNew Relicを導入した事例を紹介していきたいと思います。まずは、導入のきっかけとなる出来事からお話しします。2020年ごろから数年かけてレガシーの脱却を行っていました。いわゆるLift & Shiftですね。もともとオンプレで動いていたものをクラウド化し、さらにはコンテナ化していきました。
先ほど挙げた2つのシステムについて、入会/管理システムはオンプレで動いていたものをAWS EC2に載せ替え、さらにその先でコンテナ化してAWS ECS Fargateに載せ替えました。もう1つのコミュニティツールは、もともとAWS Elastic Beanstalkで運用していたものを、入会/管理システムに合わせてAWS ECS Fargateに移行し、それぞれレガシー脱却をはかりました。
実行環境そのもの以外でもクラウド最適化のための取り組みをしていて、今までオンプレでやってきたことをクラウドに載せ替えるにあたり、いろいろと最適化しなければならない部分が出てきたので、そのあたりの見直しも合わせて行っています。
例えば、CI/CDをCircleCIに移行してビルドやデプロイを自動化したり、AWS環境構築をTerraform化して、IaCで構成管理したりするようにしました。そして、この流れの中で監視の部分についても最適化する必要があったことで、New Relicの導入につながっていきました。
監視における課題と、New Relicの活用による課題解決
湯浅：監視における既存の課題がいくつかあったため、それを説明したいと思います。大きくは3点あり、まず1点目は各システムで監視ツールがバラバラだったこと。入会/管理システムではZabbixやStatusCake、コミュニティツールではMackerelやCloudWatchを使っていて、それぞれにバラバラの監視ツールを使っている状態でした。
2点目は、インフラや監視基盤がサイロ化していたこと。開発自体はDMMオンラインサロンの開発部が担当していましたが、インフラや監視基盤は別部門が管轄していました。そのため、何か設定変更などを行いたい場合に、インフラや監視基盤の担当者に作業をお願いする必要があり、毎回時間がかかってしまっていました。
3点目は、アプリケーションの状況把握に時間がかかっていたこと。もともとアプリケーションの状況が把握できるような監視ツールが入っておらず、何か起こったときにログを見る際には、オンプレのサーバにSSHして都度確認する必要がありました。
これら3点の課題について、New Relicの導入によって対応していこうということになりました。導入にあたっては、我々SRE部とオンラインサロン開発部が協力しながら進めていきました。
湯浅：この3点の課題に対して、どのようにアプローチしていったかを順番に説明していきます。まず1点目の課題については、各システムの監視ツールをNew Relicに統一しました。これにより監視運用の手法を統一でき、運用がかなり効率化したと思います。
システム横断で状態を把握できるようになりましたし、障害調査や分析を効率的に行えるようになりました。統一されたツールでの運用になったことで、それまでバラバラに覚えていたものが集約され、学習コストも下がりました。
2点目の課題については、監視設定をセルフマネジメント化しました。New Relicを使い始めたことで監視ツールがSaaS化され、監視ツール自体の基盤構築や運用が不要になっただけでなく、監視設定を自分たちで行えるようになりました。
そこからさらに監視設定をTerraform化して、その設定を構成管理し、そのTerraformのコードでパラメータを書いて自動反映できるようにしました。New Relicを導入する前は、監視設定を担当部署に依頼すると5営業日くらいかかっていたのですが、自分たちですぐに反映できるようになり、リードタイムが短縮されました。
3点目の課題に対しては、APMを活用することで、アプリケーションの細かい動きが把握できるようになりました。どの処理にどれくらいの時間がかかっているのかが可視化されるので、調査がかなり捗ります。こちらのスライドの左側の画像のように、どの処理にどれくらいの時間がかかっているかが割合でグラフ化され、そのトレースが右側の画像のように表示されます。
湯浅：また、Logsも活用しています。導入前はサーバに都度SSHログインして中を確認していたのですが、これによってブラウザから簡単にシステム横断でログを参照できるようになりました。
もともとは、例えば踏み台経由でログインしなければならなかったり、本番サーバではログ参照のために立会いが必要だったり、複数サーバにログがある場合は各サーバからログを収集する必要があったりなど、かなりの手間がかかっていました。それをブラウザから簡単に一括検索できるようになり、かつオンプレのサーバ側でユーザーを用意しなくてもよくなって、とても楽になりました。
さらに、この3点にプラスしてNew Relicのダッシュボードも活用しています。現在のシステムの状態を簡単に俯瞰的に確認できるので、日々の異変にすぐ気づけるように朝会でダッシュボードを確認するようにしました。朝会には、リーダーやエンジニアリングマネージャーなど意思決定できる人が同席しているため、何か異常があればスピーディーに対応判断を行えます。
導入当初は慣れていないので、ダッシュボードを眺めて気になるところをディスカッションする、「監視ツールを眺める会」を隔週で行っていました。これにより、監視ツールの使い方を覚えたり、監視ツールを見るクセがついたと思います。また、システム性能だけではなく、AWS料金もダッシュボード上で可視化したことで、意図しないコスト増加にも対処できるようになりました。
朝会で見ているダッシュボードのイメージを、参考にいくつか紹介したいと思います。まず、日々のエラー率のグラフや過去からの相対的なエラーの増加率、直近のエラー数とそのトップ20の内容などを表示するようにしています。これにより、日々の変化や今問題になっているところが俯瞰的にわかるようになりました。
湯浅：次は、デプロイメントマーカーです。現在はチェンジトラッキングという名称に変わっていますが、デプロイしたタイミングが履歴として残せて、かつ既存のグラフと横並びで見られる機能です。
この機能では、デプロイしたタイミングがピンで示されます。そのため、直近のリリース後に何かパフォーマンスが悪くなった場合、「このデプロイ直後に発生しているから、ここが影響していそうだ」とすぐに気づけるようになりました。
湯浅：次は、AWS料金の可視化ですね。AWSアカウントごとに料金をグラフ化し、ダッシュボードで表示させました。こちらのグラフの例で言うと、一番左のところに急にいつもよりも上がっている箇所があります。
そうした箇所から、不要なインスタンスが立っていたり、使う予定ではなかったサービスがまだ生きていたりすることに気づくことができ、すぐに削除するなどの対応ができます。そういった形で、想定外のコスト増にも気づけるようになりました。
湯浅：加えて、New Relicでは障害発生時のアラートをSlackで通知することができますが、そのアラートメッセージ内にRunbookのリンクを付与するようにしました。Runbookとは、簡単に言うと手順書にあたるもので、そのURLを含めて障害発生時に通知する仕組みにしています。これにより、アラートが来たときに今何をすべきなのか、Runbookを開けばわかるようになります。
障害が起こったとき、何から手をつけていいかわからなくなってしまうことがあるかもしれませんが、そういったときでもまずはRunbookを見ると、例えば今の状況を確認するためのコマンドが書いてあったり、明確に対処方法が決まっているものに関しては対応手順が書いてあったりします。こうしたRunbookにより、心理的な不安も軽減されたと思います。
New Relicの活用による効果、障害件数は約73%削減へ
湯浅：New Relicを導入して想定していた効果と、当初想定していなかった副次効果があったので、それをご紹介していきたいと思います。まず想定していた効果として、ツールを集約して設定も自分たちで管理したいという部分については、自分たちで取り回せて最適化できるようになったと思います。また、New Relicを使うことで、より細かくシステムの状態が見られるようになりました。
そして、当初想定していなかった副次効果ですが、日々の変化に気づけるようになり、障害の未然防止にも寄与できています。異常が発生したときにも、先ほど挙げたRunbookなどを活かして、速やかに初動対応ができるようになりましたし、より開発に集中できる環境が整ったと思います。
例えて言うなら、大きな病気をして初めて気づくのではなく、日々お医者さんに健康診断をしてもらい、もし何か初期症状が出ていたらきちんと検査をして、大きな病気になる前に手を打って、より健康に過ごせるようになったイメージですね。障害が発生してからあたふたするのではなく、常にどういう状況なのか日々見えるようになったことが大きいと思います。
実際に、レガシー脱却を行った直後の2020年と、数年経ってNew Relicを使いこなすようになった2023年を比較すると、障害件数を約73%削減できたというデータが出ています。
開発に集中できる仕組みが整うことによって品質が向上しますし、品質が向上することで障害発生の数も減っていきます。仮に障害が発生したとしても迅速な対応ができたり、障害が発生する前に未然に防止できたりすることで、さらに開発に集中できて品質が上がっていきます。そういう良いサイクルが生まれたことで、障害件数の削減につながったのではないかと分析しています。
湯浅：では、まとめです。New Relicを活用し、既存の監視運用を改善することができました。当初想定していた以上に開発に集中できる環境が整えられ、それによって障害件数の削減にも寄与できました。
New Relicを導入して活用していく取り組みは、DMMオンラインサロンに限らず、支援先では当たり前になってきています。導入し始めた2020年ごろは、あまり使っている事業部は多くなかったのですが、今では社内のいろいろな事業部で使われるようになっています。
今後の展望としては、さらに進んだ取り組みとしてNew Relicも活用しながら、SLO（Service Level Objective）を全社的に導入していこうとしています。開発に注力できる環境を整えるだけでなく、SLOを導入していくことで、よりユーザーさんの満足につながるサービスを事業部と一緒に実現していきたいと思っています。以上、ご清聴ありがとうございました。
New Relic板谷さんから、DMM.com湯浅さんへインタビュー
板谷：それでは、残った時間で湯浅さんに少しインタビューできればと思います。New Relicを導入いただいた当初、使いづらいと感じたり、ツールの移行にあたって迷ったりしたことはありましたか？
湯浅：もともとは各システムでバラバラのツールを使っていたために、あまり使いこなせていないという反省点がありました。ですが、New Relicに統一したことで、それに集中できる環境になったと思います。やっぱり実際に使ってみると早いので、朝会で使いながら慣れていったことで、導入時の難しさはあまり感じなかったですね。APMの見やすさも、とても助かっています。
板谷：ありがとうございます。朝会ではNew Relicをどのような形で活用いただいていますか？
湯浅：オンプレの時代にはダッシュボードなどがなかったので、自分でログを集めてきて、データをもとにまわりに説明する内容を考えなければいけませんでした。でも、New Relicでは、ダッシュボードで俯瞰的に見せることができ、リーダーやエンジニアリングマネージャーの人たちにもわかりやすく伝えられます。New Relicが共通言語になることで、上手く伝わるようになったと思います。
板谷：New Relicが共通言語になるというのは、それまでバラバラだったツールが統一されたから、ということでしょうか。
湯浅：それもありますし、説明するための資料をつくると、内容は人によってまちまちになってしまいます。ですが、New Relicで見せれば、お互いに同じ画面を見ることになるので、そこも大きいと思います。
板谷：New Relicを導入いただいて何年か経ったと思いますが、開発生産性や効率性について実感したことはありますか？
湯浅：オンプレの時代は、中身をくわしく知っている人でないと対応しづらいところがありました。そのため、くわしく知っている人が「障害対応を助けてほしい」と呼び出されたりして、特定の人に負荷が集中しがちだったと思います。
でも、New Relic導入後は誰でも障害対応がしやすくなりました。New Relicを使って中身を把握できるようになり、どこが問題なのかを誰でも見られるようになったので、その部分でかなり効率化したのではないかと思っています。
板谷：先ほどRunbookのお話もされていましたが、そういった部分の整備は湯浅さんを含むSREの方々がされているのでしょうか？
湯浅：最初はフォローしていますが、実際に使っていくなかで、例えば障害が出てRunbookを見たときに使いづらいなと思う部分があったら、オンラインサロンの開発部の人たちが自身で手直しして使いやすくしていっています。
板谷：なるほど。導入支援をしたあとは、実際に使っている方々が改善して効率性を上げていると。
湯浅：そうですね。最初はしっかり手助けしているのですが、徐々に自走できるような形で支援しているので、今はもうオンラインサロン開発部のメンバー主体で動いています。
板谷：Xのハッシュタグを見てみると、ご紹介いただいたダッシュボードのイメージについて反応がありますが、最初にダッシュボードをつくる段階でSREの方々が意識されていることはありますか？
湯浅：ベストプラクティスや正攻法のようなものは特にないですが、やはりダッシュボードには俯瞰的に、端的に表せる情報を載せるべきだと思っています。あまりいろいろな情報を含めるとごちゃついてしまうので、まずは本当にやりたいことだけに絞って見られるように進めていきました。
例えば、コストに関する部分やエラーの発生状況などもそうですし、そもそもサービスが生きているのか落ちているのかといった、根本的に大事な情報を載せてスタートするようにしました。
板谷：SRE部として、今後どのように動いていくかといった展望はありますか？
湯浅：今後の取り組みとしては、やはりユーザー目線で満足できるサービスやシステムをつくるうえでSLOが大事だと考えているので、New Relicの機能も使いながらSLOを推進していきたいと考えています。
そのほかの動きとしては、プラットフォームとまではいかないのですが、今SREで共通システムや共通ツールをつくっている最中です。SREとして、縁の下の力持ち的な動きもあれば、実際に自分たちでモノをつくっていく動きもあるので、そういったところに興味がある方がいれば、ぜひ一緒にやっていきたいと思っています。
板谷：それでは、そろそろお時間となりますので、こちらで本セッションを終了とさせていただきます。ありがとうございました。
