サイロ化が招く大規模障害 巨大企業のインフラを「わずか4人」で救った方法：既存ツールを捨てないインフラ刷新

システム規模の拡大に伴い、監視ツールにかかる費用や運用負荷の肥大化が顕在化する。金融大手のMSCIはわずか4人で、乱立した監視ツールを即座に捨てることなく、高額な維持費とベンダーロックインから抜け出した。

[TechTargetジャパン]

　複数ベンダーのクラウドサービスやオンプレミスシステムが混在し、数千人規模の従業員を抱える企業にとって、監視の複雑化は避けて通れない課題だ。金融サービス大手のMSCIも例外ではなく、過去の企業買収などを経てサイロ（分断）化された旧来の監視ツール群が乱立し、運用が不透明な状態に陥っていた。

　MSCIはある日、顧客に提供している自社サービスで大規模な障害に見舞われた。稼働ログが複数のツールに分散しており、事象の相関関係を特定するのに時間を要した。結果として、顧客の業務時間帯に影響を及ぼし、収益や企業ブランドを脅かす事態となった。

　このインシデントを機に、MSCIは監視体制の根本的な見直しに着手する。高額なライセンス費用やデータ量に応じた従量課金、特定の製品に依存した「ベンダーロックイン」状態からの脱却を目指し、標準技術の採用を決断した。これによって、障害の平均検出時間を30％短縮することに成功している。

　巨大なインフラを抱えながら、わずか4人のチームでいかにしてこの大規模な移行を成し遂げたのか。その裏には、既存のツールを即座に捨てるのではなく、データの中継役となる「抽象化レイヤー」を挟み込むという戦略的な手法があった。

4人でサイロ化した大規模インフラを刷新

併せて読みたいお薦め記事

インフラ刷新術を事例から学ぶ

• SAP連携の「終わらぬ切り分け」に終止符　LIXILが障害調査を年200時間削った訳
• ライオンが脱レガシーシステムのパートナーに「Google Cloud」を採用した理由

　本プロジェクトの全容は、ITカンファレンス「KubeCon + CloudNativeCon Europe 2025」のセッション「From Legacy Vendor Tooling To OTEL: Scaling Observability at MSCI With a Four-Person Team」で解説された。登壇したのは、MSCIのバイスプレジデントであるアフタブ・カーン氏と、エグゼクティブディレクターのザック・アーノルド氏だ。

　MSCIの変革をけん引したのは、わずか4人のエンジニアで構成されたチームだ。彼らが指針としたのは「サービスの規模に比例して人的リソースを増やさなければならないシステムは失敗する」という、Googleが提唱するSRE（サイト信頼性エンジニアリング）の原則だった。人員を増やさずに全社規模の監視システムを構築するために彼らが着目したのが、オープンソースアプリケーション観測ツール「OpenTelemetry」だ。

　導入の契機は、利用していたクラウドサービス群の監視ツールの中に、OpenTelemetryのライブラリが組み込まれているのを発見したことだった。これを機に、特定の製品仕様に適合させる方法ではなく、データを収集するための標準的な枠組みとして扱う戦略へとかじを切った。

　移行における最大のポイントは、既存のサイロ化されたツール群をいきなり撤廃しなかった点にある。社内の各開発チームが使い慣れたツールの使用を認めつつ、データの収集と転送の間にOpenTelemetryを利用した中継地点（コレクター）を配置した。これによって、ログ、メトリクス（指標）、トレース（処理の追跡）といった稼働データを統一された形式で受け取り、任意の保存先に転送できるデータパイプラインを構築した。

　コレクターの稼働インフラには、アプリケーションの配備や運用を自動化する「Kubernetes」を採用し、設定変更や処理工程の更新を迅速に実行できるようにした。アプリケーションの設定を変更することなく、新しい保存先や監視ツールを容易に試すことが可能になった。

　構築された新しいアーキテクチャでは、ピーク時に毎秒約1GBのデータをオンプレミスシステムで稼働する検索・分析エンジン「Elasticsearch」に投入し、1日当たり2TB超のデータも扱っている。分散処理を追跡する仕組みには「Jaeger」、数値データの収集には「Prometheus」を利用し、それらをデータ可視化ツール「Grafana」で一元的に可視化する構成を採用した。

　これらのオープンソースツールの組み合わせによって、MSCIは特定のベンダーによる制約から解放され、大幅な費用の最適化を実現している。自動化された仕組みを整備したことで、新しいアプリケーションの監視設定にかかる手間は、数日から数分へと劇的に短縮された。開発者は設定の負荷を負わずに、パフォーマンスの可視化という本来の目的に集中できるようになった。

　技術的な刷新だけではなく、企業全体の意識を変えるための地道な活動も実施した。当初は未知のオープンソースツールを運用することへの懸念や、使い慣れた画面を作り直す手間に対する反発もあったという。

　推進チームは、開発者向けの導入用資料を作成し、移行による具体的な恩恵を明示した。ペアプログラミングを通じた技術移転や社内での実演、啓発活動を繰り返し実施して、チームごとの自律的な運用を支援した。その結果、監視対象アプリケーションの80％でデータ収集の仕組みが組み込まれ、新たな標準として社内に定着した。

　MSCIは現状の安定したインフラに満足することなく、さらなる高度化を見据えている。そのためにカーネル（OSの中核）で動作し、システム内部を詳細に監視する技術「eBPF」【extended Berkeley Packet Filter】）の習得を進めており、アプリケーションのソースコードに手を加えることなく、システムレベルでの詳細な通信や依存関係を把握することを目指している。

　エンドユーザーの操作に基づいた監視から洞察を抽出し、データを製品の機能改善や意思決定に直接生かす仕組みづくりも視野に入れている。限られた人員であっても、適切な技術選定と抽象化のアプローチを用いれば、大規模で複雑なシステム構成を大きく改善できることを、MSCIの事例は示している。