こんにちは！
アイレット広報の羽鳥です。
いきなりですが、みなさんはアイレットの提供するクラウドの導入設計から構築・運用・監視保守までのフルマネージドサービス「cloudpack」の強みといったら何を挙げますか？

いくつか挙がる中に「24時間365日有人による監視運用」が入ってくるのではないでしょうか。お客様のインフラ環境やITシステムの安定運用を実現しているのは、アイレットのManaged Service Provider（MSP）チームが交代制でお客様のサーバーを見張っているからなのです。

そんなMSPにおいて、アイレットではインシデント管理システムである「PagerDuty」を4年前から導入し、アラート対応を実施しています。監視対象となるアラートをすべて「PagerDuty」に集約して一元管理することで、監視業務の効率化と顧客サービスにおける信頼性の向上を実現しました。

また、昨年には「PagerDuty」のAPIやWebhook機能を利用して「次世代監視基盤（Advanced Monitoring System：AMS）」を開発し、監視業務の一次対応を自動化する仕組みの導入を進めています。

今回は、AMSの開発を担当した大阪オフィスMSP開発セクションの高橋修一にインタビューを実施し、開発秘話や「PagerDuty」を利用することのメリットなどを語ってもらいました。

MSPの業務効率化を実現する「AMS」

よろしくお願いします！
まずはMSP開発セクションが何をやっているのかを簡単に教えてください。

cloudpackサービスの根幹でもある「MSP」のクオリティを高めていくために日々様々な業務を改善したり、自動化に向けた開発を行ったりしています。

MSPのチームは、24時間365日体制でお客様のインフラ環境やITシステムの環境のアラートを有人監視しています。今回は、MSPチームからアラートの一次対応のうち、定型のものはできるだけ自動化していきたいという話があり、AMSを開発することになりました。

AMSは次世代監視基盤ということですが、どのようなことができるのでしょうか？

もともと、MSPでは以下の作業を手動で行っていました。

1.アラートのオープン
2.手順書確認
3.動作確認、情報取得
4.必要に応じて復旧対応、復旧確認
5.エスカレーション
6.アラートのクローズ

AMSでは、上の監視業務を全て自動化します。
また、アラートのタイトルに含まれたAMS用のキーワードを解析し、事前に定義済みの一次対応シナリオを特定して、動作確認・情報取得・復旧対応・復旧確認などの一次対応を自動実行します。

具体的には「PagerDuty」のAPIを利用して一次対応シナリオの処理状況と処理結果をインシデントのTitleとTimelineに出力します。
また、一次対応シナリオの処理結果とシナリオ設定にあわせて、インシデントのステータスを更新します。

自動化することでのメリットが大きいですね！
MSPからの反響はいかがでしょうか？

監視業務の負荷軽減、オペレーションミスの削減、対応時間の短縮、サービスレベルの均一化を実現できているとのことで、評価してもらっています。

障害時も止まらない仕組みを構築

開発で苦労した点はありますか？

もともと人が運用していた手順をシステム上のシナリオに落とし込む時に苦労しましたね。MSPの担当者が臨機応変に対応してくれていたところなどは運用手順が曖昧になってしまっているケースもあり、今回を機に手順をしっかり改める必要がありました。

また、AMSを運用し始めてからでてきた要望や課題を、優先順位や仕様の整合性、さらにシンプルさを考えながら対応していくのに、今現在でも苦労しています。

障害時の対策などは何かしていますか？

そうですね。リージョン障害が発生しても最低限のダウンタイムで継続してアラートを捌き続ける必要があったため、そこの設計に苦労しました。結果的には、マルチサイトのActive/Active構成で可用性を確保しつつ、重複処理することがないよう排他テーブルを用意する設計に落ち着きました。

様々な障害や利用環境のパターンが考えられるため、テストについても障害のシミュレーション方法、観点、実施方法、自動化について相談し、作成しました。また、２リージョンで平行稼働し、高負荷時は自動スケールアウトなど、高い可用性を備えています。

様々な工夫によって、お客様環境の安定運用を実現しているんですね。

「PagerDuty」を活用してさらなる進化を目指す

構成図を見ると「PagerDuty」がMSP業務の中心になっているんですね。

「PagerDuty」は4年前から「cloudpack」のMSP業務の根幹となっています。AMSもその運用の流れに溶けこむ形で導入できるよう、同じく「PagerDuty」を基点としてアラートの処理を行います。

まず、「PagerDuty」から対応が必要なアラートをイベントとして受け取ります。そして必要な一次対応を行い、提供されているAPIで対応の経過や結果を「PagerDuty」に更新しています。もともとの運用を大きく変えずに済んでいるので、徐々に自動化の割合を増やしていっています。

また、完全に自動化しきれないケースではAMSが必要な情報の収集まで行い、その先のオペレーションは人間に引き継ぐといった使い方もしています。

色々な使い方ができそうですね！


はい、MSPから柔軟性がある点についても評価してもらっています。Backlogへの課題投稿は自動で行い、電話連絡は担当者がかけるといった設定も可能ですし、システムが外的要因などにより期待するシナリオを実行できなかった場合は通常の一次運用者が手動で対応するフローへ遷移も可能です。

ただ一次運用の幅を広げて「こんなこともできるかな？」といった要望も日々でてくるので整合性をとりながらより柔軟に対応できるようにしていきたいです。

柔軟に対応できるのはMSP側も嬉しいですね！

あと、「PagerDuty」は数多くのサービスとのインテグレーションが提供されています。また、通知を発行する手段も豊富なんです。様々な環境を監視しているcloudpackですが、「PagerDuty」がこれらを一括でまとめてくれているのでAMSとしてはそれらによる違いを意識して異なる実装をする必要が少なくできています。

様々な環境から発生したアラートや、人間が行った対応、そしてAMSが行った対応も「PagerDuty」に集約されるため、分析や振り返りにも利用しています。

開発はまだまだ続いていくと思いますが、今後はどんな使い方ができそうでしょうか？

「PagerDuty」には様々な機能がありますが、正直、使いこなせていない機能もまだまだあります。PagerDuty社の方々とミーティングをする機会もあり、こちらの利用方法から新たな提案をいただけることも多いです。
例えばAWS Event Bridgeもローンチ段階で「PagerDuty」が対応していました。イベントを受ける仕組みとしてこれを採用するのもありかな？と考えていたところちょうどPagerDutyさんからご提案いただき、こちらの疑問や懸念などについても情報をいただくことができました。
​
これからもお互いにフィードバックしながらMSP業務の改善を進めていけたらと思っています。また、AMS自体は開発をスタートしてから２年以上が経過しています。その間にも新しいサービスや機能がリリースされているので、検証しながら必要な部分で有効活用していきたいです。

MSP業務はさらにクオリティが高くなったら、MSPチームもお客様も安心できますね。

そうですね。そのためにPagerDutyさんと協力しながら日々改善を繰り返していきたいですね。

編集後記

「お客様環境を守る」をミッションに、24時間365日お客様の環境を監視し、安定運用を実現しているのがMSPチームです。そして、そのMSP業務の効率化を目指し活動をするのがMSP開発チームです。

今回のインタビューを通じて、今後もお客様が安心してcloudpackにお任せいただけるよう、PagerDuty 社と協力してMSPを進化させていきたいという気持ちが強く伝わってきました！

アイレットは運用監視における豊富なノウハウ・実績を活かして、さらにレベルアップしていきます！

運用監視でお困りの際はぜひcloudpackにお任せください！