はじめに
皆さん、こんにちは。
アイレットのクラウドインテグレーション事業部の蓮沼です。
MSPとして求められる期待値が数年で目まぐるしく変わってきていると感じます。
本記事では、私の整理も兼ねてこれからのMSPに求められる能力（次世代のMSP）の一部を綴りながら、弊社の次世代MSPに向けた取り組みを紹介させていただきます。
そもそもMSPの定義とは何でしょうか？
Wikipediaには以下のように記載されています。
マネージドサービスプロバイダー（Managed services provider, MSP）は、ほとんどの場合、情報技術（IT）サービスプロバイダーであり、企業システムの運用・監視などを請け負う事業者のことである。
これはいわゆる”従来型MSP”の定義であり、皆さんの中のイメージでもあるのではないでしょうか。
それでは次世代のMSPとはどういったものでしょうか。
AWSの定める”次世代MSP(Next-Generation Cloud Managed Services)”では以下のように定義されています。
Next-generation (next-gen) MSPs are full life cycle support providers focusing on consulting, professional services, managed operations, and continuous optimization. [1]
（Google翻訳）次世代 (次世代) MSP は、コンサルティング、プロフェッショナル サービス、管理された運用、継続的な最適化に重点を置いた完全なライフサイクル サポート プロバイダーです。
「Next-Generation Cloud Managed Services: A Full Lifecycle Support Engagement」AWS Partner Network (APN) Blog
full life cycle support providersと書かれているように、「次世代MSP」を目指すためには、構築や運用だけを担う従来型MSPから進化する必要があることが分かります。
従来型MSPの “システムの運用・監視などを請け負う事業者” = MSP という概念は変わりつつあります。
顧客のクラウドジャーニーを支援するために、計画から入り込み、設計・構築（移行）・運用・最適化までをサポートできる単なるアウトソースではない「パートナー」こそが次世代のMSPと言えます。
この定義をベースにするとインフラ・アプリといった境界もありません。
話がかなり壮大ですが・・・
それでは具体的にどういったポイントから次世代MSPに向けて進化していけば良いのでしょうか。
従来型MSPに必要なこと
従来型MSPと次世代MSPとの間には様々な相違点があります。
全部はとても書ききれないので、ここでは一部をご紹介します。
まず、AWSは “クラウドマネージドサービスの進化” について次のように述べています。
The shift from on premises to cloud has created new paradigms for MSPs. Traditional managed services address break-fix issues, but with cloud the role of an MSP has now evolved into proactive and predictive managed services.
Traditionally, MSPs focused primarily on building and running IT infrastructures. Now, MSPs are expected to be full-stack players, and their focus has shifted to include applications. While traditional managed services service-level agreements (SLAs) focused on the performance of hardware and infrastructure, capacity management, data accessibility, and incident management, next-gen MSPs are now able to create SLAs based on performance of the applications and business outcomes which are best aligned with meeting the ultimate needs of end customers.
（Google翻訳）オンプレミスからクラウドへの移行により、MSP に新しいパラダイムが生まれました。従来のマネージド サービスは故障対応の問題に対処しますが、クラウドでは MSP の役割がプロアクティブで予測的なマネージド サービスに進化しました。
従来、MSP は主に IT インフラストラクチャの構築と運用に重点を置いていました。現在、MSP はフルスタック プレーヤーであることが期待されており、その焦点はアプリケーションを含めることに移ってきています。従来のマネージド サービスのサービス レベル アグリーメント (SLA) は、ハードウェアとインフラストラクチャのパフォーマンス、容量管理、データ アクセシビリティ、およびインシデント管理に焦点を当てていましたが、次世代 MSP は、アプリケーションのパフォーマンスとビジネスの成果に基づいて SLA を作成できるようになりました。最終顧客の最終的なニーズを満たすのに最適です。
「Next-Generation Cloud Managed Services: A Full Lifecycle Support Engagement」AWS Partner Network (APN) Blog
ここで求められることの一つは、CPU・メモリ・ディスクといったシステム監視（モニタリング）だけの従来型MSPからの脱却です。
予め決められた監視項目のしきい値を超えたとき、既知の事象に対処するモニタリングから、普段との振る舞いの違いから未知の事象に備える予防的なアプローチへの変革が求められています。
そのためには、システム全貌の把握が必要で、以下のような様々なデータを収集する必要があります。
- OS・MW・アプリケーションといったシステムデータ
- クラウド・サードパーティ製品などのエコシステムデータ
- ユーザー体験・ビジネスKPIなどのビジネスデータ
- 脆弱性情報やセキュリティイベントなどのセキュリティデータ
これらのデータを組み合わせて、動的な機械学習を用いた予測的な監視をすることや、プロアクティブに様々な角度からシステムの全貌を把握することが、未知の事象に向けたアプローチであり、次世代MSPに求められる「オブザーバビリティ（可観測性）」という能力だと私は解釈しています。
つまり、「オブザーバビリティ（可観測性）」を既存のモニタリングにどう取り入れるかが重要になります。
とはいえ、現実はアンチパターンと言われるチェックボックス的なモニタリングをしなければならない場合もあるのではないでしょうか。
いきなり全てのシステム監視を廃止するわけにもいきません。全ての監視項目に対して動的にしきい値を設定してしまえば、大量のノイズに悩まされることも目に見えています。
MSPとしてサービスを提供する顧客が、システムとして見ているのか、ソフトウェアとして見ているのか、立場の違いによっても関心ごと（前者はシステムの健全性、後者はユーザー体験など）は変わってきます。
それでは一体どうすれば、従来のシステム監視を良さを活かしつつ、オブザーバビリティを強化し、次世代のMSPに近づけるでしょうか。
サービスレベルを策定する
そこで、重要になることの一つがサービスレベルの策定ではないでしょうか。
ここでいうサービスレベルとはMSPとしてのインシデント管理やホストごとの稼働率といったものとは異なり、システム全体のサービスレベルを指します。
ウェブサービスであれば、規定のレスポンスタイム（応答速度）やレスポンスコード（可用性）を満たすリクエスト数の割合、バックエンドのバッチ処理であれば許容可能なデータの鮮度などユーザー体験にクリティカルな箇所を指します。
運用に入る前に、ビジネス要件を踏まえ、これらの指標を設計し測定ができることが肝心です。
サービスレベルという羅針盤があることで、従来型のシステム監視で発生したアラートに対しても、サービスレベルへのインパクトに応じて、しきい値を変えたり、監視項目を見直したりといった運用設計が可能となります。
こうした運用設計と運用改善の積み重ねはアラート疲れの解消に繋がり、顧客のビジネスに影響度の大きいインシデント対応に注力できると考えています。
ですが、状況は様々です。
次世代MSPとしてはアプリとインフラの境界線がなくなりつつあるとはいえ、プロジェクトによってはインフラとアプリケーションとが役割分担をしている場合が少なくありません。そうした状況下において、どのようなアプローチができるでしょうか。
システム監視からAPM領域（アプリケーションパフォーマンスモニタリング）に拡張する
従来型のシステム監視が中心のMSPでは、上がったアラートに対してインフラとアプリとの切り分けがよく行われました。インフラ起因ではないことを確認すると、アプリケーション開発者（もしくは顧客・別ベンダ）にエスカレーションします。
こうした状況下において、サービスレベルという羅針盤を得た次に何ができるでしょうか。
その一つがまさに「APM」だと考えます。
従来のOSSの監視ソフトウェアと比べ、SaaS型の製品ではAPMエージェントなどの登場によりAPMのインサイトを得ることはとても簡単になりました。
アプリケーションの開発言語に依存せず、事前にSaaS製品で定義されている様々な機能からの観測が可能で、システム・開発などの異なる立場でも同じデータを見て分析することができます。
これは、アプリケーションの中身を把握していなかったとしても、パフォーマンスに影響を及ぼすアプリケーションの被疑箇所の特定・共有まではシステム担当のオペレーションに組み込める可能性を意味します。
私も何度か講習を受けましたが、SaaS製品では簡単な数回の操作で、最も遅いTOP10のクエリや多発しているエラー、時間のかかっているリクエストなどを我々に示してくれます。
そんなAPM領域へのマネージドサービスの拡張を、オブザーバビリティプラットフォームである「New Relic」を活用して弊社では行っています。
取り組みの例の一つを以下にご紹介します。
New Relic の APM を利用した DB のボトルネック特定とパフォーマンス改善
さて、我々は追加のプラクティスを実行するだけでなく、既存の一次対応における継続的なサービス品質の改善にも取り組んでいます。
最後にその取り組みをご紹介します。
一次対応の継続的な改善の取り組み
継続的な改善にはまず状況の可視化が必要です。
我々は一次対応の状況の可視化に 「Looker」 を利用しています。
Looker は Google Cloud が提供する次世代型の「データプラットフォーム」です。
Looker は一般的には BI ツールのカテゴリーに分類されることも多いですが、独自のモデリング言語を記述することでデータの一貫性を担保し、全員が同じ分析結果を得ることでデータガバナンスを担保します。また基本的な BIの機能であるダッシュボードの用途だけではなく、データをチャットツールや E メール、その他サードパーティーやオートメーション製品と連携させ、データ分析と業務をシームレスに連携させることも出来るようになります。(詳細: https://cloud.google.com/looker?hl=ja)
Lookerを利用したダッシュボード画面の一部をご紹介します。
この画面では、弊社MSPとしての一次対応におけるサービスレベルの遵守状況をプロジェクトごとに示しています。
このダッシュボードをもとにサービスレベル目標に対して、達成率の低いプロジェクトのインシデントの内訳を確認したり、運用チーム(*)ごとに俯瞰したりすることで、継続的な運用改善を実現しています。
(*) 24/365の一次運用チームとは異なるプロジェクトごとの運用設計を担当する二次運用チーム
（継続的な運用改善イメージ）
これらの可視化・分析結果をもとに、監視設計の見直しやAMSのシナリオによる自動化などで、継続的なサービス品質の向上が実現できています。
また、Looker のレポート機能を使ってサービスレベルの遵守状況を内部に向けて定期レポーティングすることも可能となり、組織内の意識改革やより細かいサイクルで更なる継続的な品質向上が期待できます。
まとめ
以上が、弊社が次世代MSPに向かっていく上でのオブザーバビリティを中心とする取り組みのご紹介となります。
関心ごとの異なるインフラとアプリ、またはそのほかの関係者が、お互いの領域のインサイトを共有しサービスレベルという共通認識を持つことで、よりシステムの信頼性を保ちながらサービス改善やビジネスの拡大に向けた取り組みが加速できるのではないでしょうか。
また、そうした基盤を提供することが次世代MSPへの進化の過程で重要になってくるのではないかと考えています。
今回ご紹介したのは次世代MSPに求められる能力のほんの一部分に過ぎず、ゴールはないと思っています。
引き続き、従来型MSPの良さは大切にしつつ、次世代MSPとして求められるプロアクティブなマネージドサービスの強化に尽力していきます。
そんな日々の努力が実を結び・・・弊社では MSPとしての能力を評価される MSPプログラムを AWS ・ Google Cloud ともに更新しています。
アイレット、AWS の「マネージドサービスプロバイダ（MSP）プログラム認定」を更新
https://www.iret.co.jp/news/20230907.html
アイレット、Google Cloud のマネージド サービス プロバイダ（MSP） 認定を更新
https://www.iret.co.jp/news/20230328.html
年々ハードルが上がっており、これまで以上に組織的な取り組みが求められていることを肌で感じます。
次回は違った角度から次世代MSPへの取り組みをご紹介できればと思います。
ここまで見ていただきありがとうございましたっ！
