こんにちは。2024年11月にIVRyにSWEとしてジョインした渡部(ryuichi_1208)です。最近は肉うどんとコーヒーにハマっています。会社には肉うどん部とコーヒー部があって日々レベルの高い(?)議論がされておりとても面白いです。
概要
IVRy では目に見える機能開発の他にも、サービスレベルを高めクライアントに提供するシステムが安定稼働し続けることを目指して、様々なシステム改善を日々実施しています。
今回は、IVRy のSREチームが行っている取り組みについて紹介します。
前回の取り組み記事
2年半前の記事もありますのでよければ🙏
IVRyにおけるSREチームの位置付け
SREチームは、『チームトポロジー』におけるプラットフォームチームとしての役割を担っています。IVRyでは複数のプロダクトが存在し、それぞれにストリームアラインドチームが配置されています。SREチームはこれらのストリームアラインドチームを支援する横断的なチームとして位置付けられており、プラットフォームの提供や共通の課題解決を通じて、プロダクトチームが本来の業務に集中できる環境を整備しています。
取り組み
SLI/SLOの導入
システムの信頼性を定量的に評価するために、SLO（Service Level Objective）を設定しています。まず、クライアントにとって最も重要なユーザー行動（Critical User Journey, CUJ）を特定し、それを元にSLI（Service Level Indicator）を設計しました。
現在、電話応答速度やAPIのレスポンス時間といった指標をモニタリングし、p99の応答時間にSLOを設定しています。また、インフラ会議で定期的にレビューを行い、異常検知や改善点の議論を通じて、サービスの信頼性向上を目指しています。
アプリケーション改善の具体的な取り組み
SLI/SLOのダッシュボードを眺める会で検出したエラーレートの悪化やレスポンスの悪化はアプリケーションチームと協力して修正しているものもあれば、SREチーム単独で調査、改善まで行えているものもあります。具体的にはDBのスロークエリの改善、タイムアウトの設定、グレースフルシャットダウンの実装などです。
PagerDutyの利用開始
インシデント対応を迅速かつ効率的に行うため、PagerDutyの導入を決定しました。このツールを利用することで、インシデント発生時に適切な担当者が即座に通知を受け取り、迅速に対応できる仕組みを構築しています。
PagerDutyの導入により、これまで曖昧だった担当者割り当てが明確化され、対応のスピードと正確性が飛躍的に向上しました。さらに、複数の通知チャネル（メール、電話、モバイルアプリ）を活用することで、Slack通知だけだとすぐに気づけなかったアラートも確実に通知が届く体制を整えました。当番のローテーション頻度、レイヤー設計などを実施しすでにドキュメント化まで実施し運用を開始しています。
オブザーバビリティの改善
システムの現状をより詳細に把握するため、オブザーバビリティの改善にも取り組んでいます。Datadogを活用し、各サービスのメトリクスやログを一元的に管理することで、障害発生時の根本原因特定が迅速化しました。メトリクスやAPM、プロファイラといった機能を活用しています。
また最近ではAWSから新しくリリースされたContainer InsightsやDatabase Insightsといった機能も有効化して使用しています。Container Insightsではログからメトリクスの参照などが同一画面から行えたりDatabase InsightsではPerformance Insightsと合わせて調査する際にシームレスな操作で大変便利です。
↓ Database Insightsの例
インフラコード化の徹底
手動で構築・管理されているインフラは、変更や復元時に人的ミスが発生しやすく、信頼性を低下させる要因となります。IVRyでは、主要な機能を提供しているインフラについてはコード化がされていた一方で一部の設定がコード化されておらず意図しない設定がリリースされてしまうといった障害が起きていました。以降コード化することを徹底しています。具体的には全てのリソースにTerraformのDefaults Tagsを設定しておきタグが無いリソースをコードに落とし込むということをやっております。
また直近ではDatadogやPagerDutyもコード管理しており手動操作を極力無くすように取り組んでいます。
すでに存在するリソースの一括コード化にはTerraformerというツールを使っています。
MTG関連
テックニュースを眺める会
使っているツールのアップデート、SRE関連のニュースをSlackの専用チャンネルに流してみんなで同期的に眺めるという時間を作っています。最近だとAurora DSQLの発表はすごく盛り上がっていました。他にもTerraformのアップデート時の新機能や運用周りの便利ツールなどをみんなで共有する場として運用しています。以下の記事でDuckDBが流行っていると書いているのですがそのDuckDBも便利情報が集まるチャンネルに投下されたことがきっかけでした。
もくもく会
IVRyのSREメンバーは出社とリモートのハイブリッドなメンバーで構成されています。チャットで聞くまでも無いけどという質問やコメントを話す場としてHuddleでもくもく会を週一ペースでやっています。もくもく会とは言いつつも誰かが画面共有して作業をしてると知らないツールが出てくるとその話題で雑談が始まったりしてあまりもくもくしておらず会の名前を変えるか検討中です(笑)
読書会
有志で読書会をしています。書籍は「内部構造から学ぶPostgreSQL」です。私の入社前から行われているのですがPostgreSQLはほぼ触ったことがない状態でまさか内部構造の話の本で正直ビビりながら参加したのですがこれからみんなで学んでいくというフェーズで和気藹々と読んでいます。(IVRyでは現在Amazon Aurora PostgreSQLをメインで使っていますが一部でRDS for PostgreSQLを使用しています)
次はSLO サービスレベル目標の読書会も計画されています。
今後の展望
信頼性向上の取り組みをさらに深化させるため、以下のポイントに注力し、組織全体としてのシステム信頼性を向上させていきます。
SLI/SLOの全社展開とモニタリング体制の確立
現在、SLI/SLOはSREチーム内で運用されている状態ですが、今後はこれを全社レベルにまで拡大することを目指します。具体的には以下を進めます：
- 統一された指標の策定
- 各サービスが共通して参照できるSLI/SLO指標を策定し、全社での一貫性を確保します。
- ダッシュボードの強化
- SLI/SLOをリアルタイムで可視化できるダッシュボードを各部門に導入し、迅速な意思決定を支援します。
- 定期レビューとフィードバックの体制構築
- 全社的なSLOレビュー会議を設け、改善提案や新たな目標設定を定期的に実施します。
インシデントレスポンスの最適化と迅速化
インシデント対応プロセスを見直し、効率的かつ迅速な対応を可能にする取り組みを強化します。
- 初動対応のテンプレート化
- インシデント発生時の初動対応手順をテンプレート化し、未経験者でもスムーズに対応できる環境を整えます。
- 対応手順の標準化
- 各種インシデント対応フローを標準化することで、個々のスキルや経験値に依存しないプロセスを構築します。
- シミュレーションとトレーニングの実施
- 定期的なシミュレーションや勉強会を通じて、インシデント対応能力の底上げを図ります。
サービスレベルのさらなる向上
より高いサービスレベルを提供するため、技術的な基盤強化とプロセス改善を並行して進めます。
- 自動化の推進
- モニタリング、復旧、障害検知といったプロセスを自動化し、人為的ミスを削減します
- 先回りした対応の実現: 過去のインシデントデータを基に、予測分析を導入し、潜在的な問題を事前に検知・解決する体制を整えます
- カスタマーエクスペリエンスの向上
- 信頼性向上による安定したサービス提供を通じて、顧客満足度を最大化します
これらの取り組みを通じて、IVRyのサービスがさらに安定し、クライアントにとって信頼性の高いプラットフォームとなることを我々SREチームは目指します。
まとめ
IVRyは電話自動応答のSaaSとして、時間帯や曜日を問わず安定したサービスを提供することが求められます。このような環境下で信頼性を高め、常に高いサービスレベルを維持する取り組みは、非常にチャレンジングでありながらやりがいのあるテーマです。個人的にも大変面白フェーズであると思っています。
もし、興味を持っていただけた方は、是非お声がけください！！
Discussion