サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2>はじめに</h2>

<p>この記事は&nbsp;<a href="https://qiita.com/advent-calendar/2023/dmm" rel="nofollow">DMMグループ Advent Calendar 2023</a>&nbsp;の2日目の記事です。</p>

<p>こんにちは、プラットフォーム事業本部 マイクロサービスアーキテクトグループで認証認可サービスの開発と運用をしている渡部です。<br />
この記事では私のチームがSLI/SLOを導入し、運用を進める中で出会った課題や学びを共有します。特に複数のマイクロサービスが依存しあっている状況において、開発者目線のSLIからユーザー目線のSLIへ見直した経緯について述べます。</p>

<h2 id="SLIの見直し:開発者目線からユーザー目線へ-SLO/SLIの導入前">SLI/SLOの導入以前からの課題</h2>

<p>私たちのチームが開発する認証認可サービスはレガシーなシステムに依存していました。この依存関係により、サービス品質の低下が私たちのサービス起因なのかそれとも依存先システム起因なのかの判別に手間がかかり、運用負荷が高まっていました。つまり、私たちのマイクロサービスが実際にどの程度の品質を保持しているのかをうまく把握するのが困難な状況でした。</p>

<p>そのような状況の中で、DMMプラットフォームにSLI/SLOを導入する取り組みが始まり、認証認可サービスにもSLOを導入することになりました。<br />
このDMMプラットフォームにSLOを導入する取り組みについて、詳しくは同僚のKudoさんが<a href="https://cloudopsdays.com/" target="_blank">Cloud Operator Days Tokyo 2023</a>で登壇した資料を見ていただければと思います。<br />
(参考:&nbsp;<a href="https://speakerdeck.com/junjunjunk/dmmpuratutohuomuni-zerobesudeslodao-ru-siteiruqu-rizu-mi-shi-qie-naslimo-suo-nogui-ji" rel="nofollow">DMMプラットフォームに ゼロベースでSLO導入している取り組み 適切なSLI模索の軌跡</a>&nbsp;)</p>

<p>そして私たちのチームは「依存先システムの影響で自サービス単体の品質がうまく把握できない」という課題感を持ってSLO導入に取り組むことになりましたが、これがユーザー視点のSLO運用から離れていくきっかけとなったのでした...。</p>

<h2 id="SLIの見直し:開発者目線からユーザー目線へ-最初のSLI設計">どのようなSLIを採用したか</h2>

<p>結論から述べると、依存先レガシーシステムに影響されないメトリクスをSLIとして採用しました。例えば、レイテンシについては依存先システムの応答時間を除外するようにし、エラーレートの計算からは依存先システム起因のエラーを除外するようにしました。</p>

<p>つまり、以下のような自サービスに限定したメトリクスを計測し、サービスの信頼性を評価するSLIとして使用することとしました。</p>

<ul>
	<li>依存先の応答時間を含まないレイテンシ</li>
	<li>依存先に起因するエラーを除外したエラーレート</li>
</ul>

<p>このような監視をGoで実現した具体的な方法については、<a href="https://inside.dmm.com/articles/dmmgo-6/#content3" rel="nofollow">DMM.go #6 マイクロサービスの効率的な監視〜不安定な依存先との闘い〜</a>&nbsp;で紹介しましたのでよければご参照ください。</p>

<h2 id="SLIの見直し:開発者目線からユーザー目線へ-得られた成果と課題">得られた成果と課題</h2>

<p>依存先システムの影響を除いたSLIを採用することで、普段のチームの運用負荷は軽減しました。</p>

<p>なぜなら、他チーム管轄の依存先システムが不調になったとしても私たちのサービスを監視するアラートは発火せず、対応を迫られることがないからです。加えて、今までは依存先システムの応答時間に覆い隠されていた自サービスレイテンシの小さな不調にも気づけるようになりました。</p>

<p>一方で(本末転倒な話ではありますが)SLO導入の本来の目的であった、ユーザーが体験するサービス品質を正確に可視化することができなくなりました。</p>

<p><img alt="" height="293" src="https://image.dmm-corp.com/jjik9qfrkn0tndc8ny8ullyz6guc" width="600" /></p>

<p>また、依存先システムの影響を除外する仕組みの実装により、SLIの定義だけでなくアプリケーションの実装も複雑化し、認知負荷が増大しました。</p>

<p>結果として、運用負荷の軽減という成果は一定程度得られましたが、ユーザーの満足度を可視化し、ビジネス的な意思決定に活用できるSLO運用とはかけ離れた形となりました。</p>

<h3>成果</h3>

<ul>
	<li>依存先システム起因の品質悪化時にアラート対応を迫られない</li>
	<li>自サービス単体の品質が可視化され、小さな不調に気づける</li>
</ul>

<h3>課題</h3>

<ul>
	<li>SLIがユーザーの満足度を表す指標でない</li>
	<li>認知負荷の増大</li>
</ul>

<h2>まとめと展望</h2>

<p>今後は依存先のパフォーマンスを含むシンプルなメトリクスへ修正しようと考えています。</p>

<p>また依存先システムの影響を除いたメトリクスの有用性は変わらないため、そのようなメトリクスは自サービス監視の一部として引き続き使用する予定です。</p>

<p>ユーザー目線であるべきSLIでは依存先も含めた全体の品質を計測しつつ、開発者・運用者のために自サービス単体の品質も別で可視化する、という状況を目指すのが良いのではないかと考えています。</p>

<p>私たちのチームでのSLI/SLO運用は今も手探りな状況ですが、この見直しの経緯を共有することで同じような問題を抱える方の参考になれば幸いです。</p>


プラットフォーム

サーバサイド

バックエンド

アドベントカレンダー2023

SLIの見直し 開発者目線からユーザー目線へ

プラットフォーム開発本部

facebook

twitter

DMM TV

DMMブックス

DMM pictures

DMM GAMES

DMMオンクレ

DMMスクラッチ

DMMくじ

DMM Factory

ぷらさぷ ～＋SURPRISE～

DMMオンラインサロン

DMMいろいろレンタル

DMM DVD／CDレンタル

DMM通販

DMMオンラインクリニック

デジタルコミック事業

DMMチャットブースト

DMM英会話

DMM FX

DMMかりゆし水族館

ベルリング

ハッシャダイソーシャル

ヤンキーインターン

シント=トロイデンVV

DMM 地方創生

DMM.make 3Dプリント

DMM.make PRODUCTS

Seamoon Protcol by DMM Crypto

DMMバヌーシー

DMM EV ON

DMM WEBCAMP

DMMぱちタウン

DMM競輪

Waitinglist

Algoage

DMMポイントクラブ

社会課題

エンターテインメント

動画

電子書籍

アニメ

ゲーム

アプリゲーム

コミュニティ

オンラインサロン

PCゲーム

通販

オンラインイベント

ビジネスソリューション

教育

英会話

水族館

ハードウェア・プロダクト

救急車両

消防車両

モノづくり施設

サッカー

スポーツ

地方創生

VR体験

Web3

生成AI

研究開発

アプリ

ブロックチェーン

横断開発

社会インフラ

アミューズメント

ダイバーシティ

同人

フロントエンド

ネットワーク

セキュリティ

ITインフラ

配信基盤

ペイメント

Android

データベース

ビッグデータ

データ分析

機械学習（ML）

MLOps

VR開発

フルスタック

プロトタイピング

グラフィックデザイン

イラスト作成

3DCG

モーショングラフィック

プロダクトデザイン

SLIの見直し開発者目線からユーザー目線へ

シェア

関連する求人

関連する記事

SLIの見直し 開発者目線からユーザー目線へ

シェア

関連する求人

関連する記事

SLIの見直し開発者目線からユーザー目線へ