現在、多くの企業がDX（デジタルトランスフォーメーション）によるビジネス変革に取り組んでいます。DXを実現するにはより高い頻度でのアプリケーションのリリースや改善が必要になるため、従来の硬直したモノリシックなシステムでは対応できません。そこで求められているのがアプリケーションモダナイゼーションと、それを支えるAPMです。
求められるアプリケーションモダナイゼーション
アプリケーションモダナイゼーションとは、主にアプリケーションのWeb化、クラウドへの移行、AIの活用など、既存のIT資産を活かしながらアプリケーション構造を最新の技術や設計で最適化することです。
DXへの取り組みは、世界的な潮流といえるでしょう。特に日本では、経済産業省による「DXレポート～IT システム『2025 年の崖』の克服と DX の本格的な展開～」が大きな根拠となっています。このレポートでは、2025年に多くのシステムのサポートが終了するとともに、それらのシステムを構築してきた人材が定年を迎えます。従来のシステムにはモノリシックなものが多く、しかもメンテナンスできる人たちはいなくなってしまうため、ブラックボックス化してしまいます。
モノリシックなシステムは、千トンもあるような巨石のようなもので、機能や冗長なロジックが何層にも折り重なり、何千行ものコードが単一の言語で記述されています。モノリシックアーキテクチャを小さいコンポーネントに分けることは難しく、容易に拡張することはできません。必要な部分だけを拡張できず、環境全体を拡張する必要があります。
そこで政府では、クラウドサービスの利用のモダナイズを推進しています。クラウドを活用すれば、スモールスタートから大規模環境にスケールすることも可能ですし、常に最新の技術を利用できます。政府では、新たなシステムを構築する際には、まずクラウドから検討するという「クラウド・バイ・デフォルト原則」を発表しています。さらにクラウドサービスでは、マイクロサービス化も大きなメリットです。
マイクロサービスは、モノリシックな巨石を大量の小石に切り分けたようなものです。それぞれのコンポーネントは分散していて、それぞれが一連の固有のビジネス機能を担っています。マイクロサービスアーキテクチャでは、異なる機能をカプセル化するためにコンテナが多用されるため、ニーズの変化に応じて各サービスを簡単に拡張できます。
マイクロサービスのアプローチで構築されるアプリケーションは、一般にさまざまな言語で開発され、それぞれのサービスは個別に拡張できます。また、各サービスが独立しているため、導入スケジュールを分けられます。このため、俊敏性が向上し、コードを頻繁にプッシュできるようになり、ユーザーからのフィードバックを短い間隔で反映できるようになります。
このように、例えばモノリシックなシステムを柔軟なマイクロサービスのアーキテクチャへ移行することも、アプリケーションモダナイゼーションの１つのパターンです。
APMソリューションの重要性
アプリケーションモダナイゼーションによるマイクロサービス化はいいことづくめのように感じますが、そうでもありません。例えば、マイクロサービス化によってコードをプッシュする頻度が高まり、独立したコンポーネントを頻繁に更新するようになるため、複雑な監視プロセスが必要になります。そもそも、イノベーションを加速し、デジタルやクラウドへの投資を守るには、クラウド向けに構築された最新のインフラストラクチャ監視ソリューションとAPM（アプリケーションパフォーマンス監視）ソリューションの導入を最優先させることが重要です。
インフラの監視が問題の有無を見極めることに役立つのに対し、アプリケーションパフォーマンスの監視は問題が起きている箇所の特定を可能にします。APMツールは、アプリケーションを中断することなく適切なサービスレベルを維持できるように設計されています。アプリケーションが社内向けであっても、消費者向けであっても、アプリケーションの速度とアップタイムは企業の収益に直結します。環境のどこで障害が発生しているかを把握することで、インシデントをはるかに迅速に解決できるようになり、システム停止の影響を大幅に軽減できます。
ただし、従来型のAPMでは、コンテナ、Kubernetes、サーバーレス関数、マイクロサービスといった最新のテクノロジーや、DevOpsのプラクティスなどのサポートによって生じる運用上の新たな課題を解決することはできません。マイクロサービスは、多くのメリットをもたらす一方で、複雑化を招きます。
従来型のAPMでは、例えばトレースデータが部分的にしか取り込まれないため異常が見逃され、開発者による導入や開発者の生産性が低下したり、バッチ方式の分析のため、問題の検出が遅れたり、価格体系が複雑でパフォーマンスに問題があるため、必要でも拡張できず成長が妨げられたりすることがあります。また、ベンダー固有の重量なエージェントがイノベーションの妨げとなったり、さらにはオブザーバビリティツールがいくつも散在しているために、手順を繰り返さなければならなかったりします。
マイクロサービスは、相互に通信する必要があり、個別に作成、更新されるそれぞれのコンポーネントは他のコンポーネントと連携しなければなりません。そのうえ、遅延を最小限に抑える必要もあります。つまり、マイクロサービスで構成されるアプリケーションの管理とは、相関するコンポーネントからなるアプリケーション同士のネットワークを管理することです。サービス間のやりとりを効率的に監視することが、全体の信頼性の確保には欠かせません。
また、現実には、全てのアプリケーションがクラウドネイティブアプリケーションへ移行される訳ではなく、企業ごとにオンプレミスのアプリケーション資産も存在し続け、適材適所なハイブリッド運用も多く存在します。その場合に、従来型のオンプレミスアプリケーションから、クラウドネイティブな最新テクノロジー環境下のアプリケーションまで、全てを網羅的に統合的に監視する、ということも必要となってきます。
最新のAPMガイドはこちらからダウンロードできます。
現代の企業のために設計されたSplunk APM
パブリッククラウドやクラウドネイティブアプリケーションへの移行は、容易なスケーリング、処理能力の迅速な調整、データセンターの運用負荷の軽減など、多くのメリットをもたらす一方で、新たな課題も生み出しています。APMはその解決の一助となりますが、適切に行わなければ意味がありません。
多くのAPMソリューションは、分析するデータの量をサンプリングによって減らした上で、パフォーマンスの低下やエラーを検出します。しかし、動作の問題に関するインサイトを正確に得るには当然、すべてのデータを取り込んで分析する必要があります。APMをユーザーエクスペリエンスの向上、ブランドイメージの維持、商品の迅速な市場投入につなげるためには、すべてのトランザクションデータをリアルタイムで取り込むソリューションが欠かせません。
OpenTelemetryなどのオープンスタンダードをベースとしているSplunk APMなら、単一ベンダーによる制約からコードを開放し、最適な言語やフレームワークをあらゆるスタック、あらゆる規模で使用できます。また、OpenTelemetryはオブザーバビリティデータの3つのクラス（メトリクス、トレース、ログ）すべてをサポートしているため、データの利用が促進され、ベンダーロックインを防ぐことができます。
メトリクスとは、基盤となるシステム、ネットワーク、ストレージのプロセス、アクティビティ、ステータスについてのインサイトをもたらす数値です。一般に、メトリクスは経時的に測定され、「時系列」とも呼ばれます。
トレースとは、アプリケーションでのリクエストの進行状況を記録したもので、アプリケーションを構成する無数のサービスすべてを対象とします。個々のトレースでは通常、スパンやエラー、各サービス内の重要な操作にかかった時間、カスタム属性といったデータを取得します。
ログとは、ある期間に発生した各イベントの永続的な記録です。イベントログはプレーンテキスト、構造化テキスト、またはバイナリ形式で存在します。
オブザーバビリティを獲得するには、この3つをいずれも詳細に分析できなければなりません。メトリクスからは問題があるかどうかがわかりますし、トレースは問題のトラブルシューティングに役立ちます。ログは問題の原因を特定する手段となります。この3つの柱をすべて組み込んだSplunkのようなオブザーバビリティソリューションなら、問題を検出し、根本原因を突き止めた上でトラブルシューティングできるため、MTTRを短縮し、システムの稼働を維持できます。
外部からの問い合わせで発覚していたインシデントをいち早く検知
実際の導入事例を紹介しましょう。日本取引所グループ（JPX）は、2013年1月に東京証券取引所グループと大阪証券取引所が経営統合して誕生しました。同グループ傘下の東京証券取引所（東証）は、金融商品取引法に基づく金融商品取引所の免許を受け、金融商品市場を運営する事業会社です。その事業領域は、株券等有価証券の売買やデリバティブ商品の取引を行う市場施設の提供、あるいは相場の公表や売買等の公正性の確保に関する業務など、広範囲に及びます。
JPXでは、約30ある情報系システム基盤をハイブリッドクラウド環境へ移行していく中で、複雑化するシステムの障害ポイントが可視化しにくいという課題があり、ユーザー視点に立ったパフォーマンス監視を行う仕組みが必要とされていました。
そこで同社は、「サービスの提供状況の把握（クラウドサービスの死活監視）」「パフォーマンス状況把握」「API 稼働状況の把握」の3点を目的に、各システムにアクセスして統合的に定点観測する仕組みとして、外形監視ソリューション「Splunk Synthetic Monitoring」を導入し、運用を開始しました。
導入の結果、現行システムに手を入れることなく、外部からの問い合わせで発覚するインシデントを開発チームでいち早く検知することができるようになりました。また、すぐに使い始めることができ、URLを追加するだけで死活監視が開始できることに加え、Webサイトの表示パフォーマンス計測によりユーザー体験の改善が可能になったといいます。
Splunkでは、すべてのログ、メトリクス、トレースを収集して、プラットフォーム内のあらゆるイベントを理解しやすい形で把握できるので、問題に対する答えを得ることができます。アプリケーションモダナイゼーションの監視に検討してみてはいかがでしょうか。
Splunkへのお問い合わせはこちらから。
----------------------------------------------------
Thanks!
三船 亜由美
