はじめに

本稿では、デジタル時代における更なるビジネス拡大を視野に、性能観点での競争戦略について紹介していきます。
ビジネスと性能と聞いて「そうそう。確かに重要な要素だね」という人は、既に性能で「痛い目」を見た人が多いのではないでしょうか。もしかすると数千万・数億円単位の損失を被った方もいるかもしれません。
一方で、そうでない人にとってはなかなかピンと来ない点もあると思います。

性能担保力(=性能競争力)がビジネス格差となってきており、そうした中で「痛い目」にあってから気付きを得てください、では手遅れにもなりかねません。
我々は性能専門組織として年間300案件以上を対応してきており、その知見がみなさんの役に立つことを期待して、ビジネスにおける性能競争戦略について紹介します。

ビジネスとシステム性能との関係性

皆さん感じている通り、コロナ禍をきっかけにNew Normalの生活様式に移りつつあり、急速に非対面・非接触化が進んできています。
これは、これまでの「人と人との直接のやり取り」から、「人と人との間にシステムが入る」ことを示しており、今後より一層システムを介した社会にシフトしていくことは間違いありません。

こうした社会において、人は何を求め、システムやサービス提供者としてどう応えていくべきでしょうか。
そのカギは顧客体験向上にあります。
顧客体験向上のためには、顧客がシステムに触れた際のフィードバックを逐次捉え継続的な改善が必須であるため、短いスパンでのシステムへの機能追加や構成変更が必要となります。

この際に、課題となるのが性能です。
システム開発を経験した方はイメージしやすいと思いますが、サービス提供中のシステムへの機能追加/改善を行うにあたり、性能まで担保するのは容易ではありません。なぜなら、たった1か所の遅延個所がシステム全体の遅延を招くため、システム全体を通したテストの必要性がありますが、これが容易ではないのです。システム全体のテストのためにシステムを1~5日停める必要があるので、そう簡単に実施とはいきません。そうすると、代わりとなる商用環境同等のテスト環境が必要となりますが、今度はその環境コスト負担が大きく現実的な解とならないのです。

では、性能担保が難しいからと言って、対策を行わず性能問題を発生させてしまった場合、解決までにどれぐらい時間がかかるのでしょうか?
我々のこれまでの実績からすると、解決までに2週間~数か月かかるケースが多いです。もちろん、有識者を多数抱えているプロジェクトはもう少し短いですが、そもそも世の中に性能有識者は少なく、そういったプロジェクトは残念ながら多くはありません。

システムが遅延している状況が続いた際に、エンドユーザーは根気強く待ってはくれません。サイトにアクセスしたりスマホアプリを使った際に「遅いな」と感じると、他のサービスに移ったり、レビューで低評価をつけることになるでしょう。

このように、サービス開始後の性能担保は必要でありつつも実現は難しいと感じている人は多いです。また、実はもっと手前の段階、つまり、そもそもサービス開始前の開発フェーズにおいても性能問題に悩まされている顧客は多く、起きてしまった問題に対する当方への相談も年間100件を超えています。

システム性能担保のステージ

ビジネス競争力と性能担保の関係性、その難しさについては冒頭に述べた通りですが、もう少し整理をすると下記の図1の通りとなります。

性能担保力(=性能競争力)は大きく4つのStageに分けられ、Stageが進むにつれてビジネス競争力向上の恩恵をより多く受けることができます。

ただ、大半が Stage1 に留まっており、一部の先進的な企業・プロジェクトがStage2に進んでいるのがこれまででした。

図1 ビジネス競争力と性能競争力のフェーズ

図1 ビジネス競争力と性能競争力のフェーズ

発生した性能問題解決に時間を取られ足踏みをしているStage1,2のプロジェクトがある一方で、DXを活用し、既にStage3まで進み性能問題発生を未然に防いでいるプロジェクトも出てきました。

Stage2 と Stage3 との違いは、問題を発生してから対応するか、問題を未然に防ぐかにあります。

具体的には、AIなどを活用し、多角的に分析することで性能問題の発生を予兆し、問題が発生する前に対策を打つことで問題発生を未然に防ぐといった取り組みです。
従来のように「人間が四六時中張り付いて何かあった際に慌てて原因究明を行う」のに比べ、そもそも問題を起こさないことを目指しており、ビジネス機会損失やブランド失墜を防ぐという点でメリットは大きいです。

事例紹介にあたり、技術的なキーワードが並び小難しく思えるところはあるかもしれませんが、場合によっては次の章は読み飛ばしてもらっても構いません。
ただ、共通する点として、実現するための技術は複雑に見えるものの、利用する側としては意外とすんなりと活用でき「今までなぜ使ってこなかったのか?」と思うものばかりである点を認識しておいていただければと思います。

事例紹介

DevPerfOps による自動性能最適化

DevOps の概念により迅速な機能改善とシステムの安定稼働を両立させる動きは従前からありますが、性能担保に関しては解決策がないのが課題でした。これを解決するソリューションとして、当部署が海外を中心に展開しているのがDevPerfOpsです。日本においてAgile開発が増えるに伴い、海外だけでなく日本への案件適用も始まってきています。DevPerfOps ではオートメーション化を徹底的に進め、リリースに併せて性能テスト・問題時の通知・情報収集・可視化・問題切分けを自動で行い、迅速な性能担保を可能にしています。

図2 DevPerfOps における性能自動最適ポイント

図2 DevPerfOps における性能自動最適ポイント

AIパフォーマンスマネジメントによる予兆検知

問題発生を未然に防ぐためには、システムの状況を瞬間でとらえるのではなく、時系列でとらえることが重要です。
時系列で見ることで、将来の性能問題の予兆が初めて可能となります。時系列でみるために、これまではシステムの利用状況をごく単純な予測で行っているケースが多くありました。それまでのCPU使用率の伸びや業務量の伸びなどを基に線形予測をするイメージです。

実際には単純に線形に伸びることはあまりなく、特異点となるデータが含まれることが多いため、それらを「職人芸」によって異常かそうでないかを判断しているのが実状だと思います。一方で、機能追加サイクルが短くなってくるとこうした職人芸では限界を感じたりコスト負担を感じるケースが出てきました。そこで、AIによるパターン分析やアクセス業増加予測モデルを活用し、高度に性能キャパシティ管理を行うプロジェクトが出てきています。

さらに、近年、マイクロサービス化やSaaS活用が進み、システムが複雑化しており予測を捉えることが難しくなってきています。これを解消するためにAIによる相関分析を活用し人間も気が付かない予兆検知を行う取り組みも行っています。
もともと統計分野で考案された相関分析は、因果関係のメカニズムが明確でない状況において、因果関係の存在を推定するための手法であり、スローダウンの検知のような問題にも応用できる可能性があることが分かってきました。現在、JubatusやLognosisなどの分析フレームワークの応用可能性を模索しているところです。

図3 DevPerfOps における性能自動最適ポイント

DEM (Digital Experience Management) によるCXモニタリング

従来のサーバーレスポンスだけではなく、利用者つまりエンドユーザー視点でサービス全体の健全性を把握する事例です。上述の通り、遅延による顧客体験への影響はビジネス損失に直結することになるため、遅延度合いを迅速に把握することは非常に重要です。これには、エンドユーザーの視点でアプリケーションパフォーマンスを計測できるDEM(Digital Experience Monitoring)と呼ばれる手法が有効です。 ユーザー側のアプリケーション (WebやモバイルAP) 内部とそのトランザクションのパフォーマンスをリアルタイムにモニタリングすることで、ユーザー影響を把握し、ビジネス損失を極小化するアクションを判断することが可能になります。

図4 DEMによる異常検知と特定

最後に

New Normal におけるビジネス競争力を獲得・拡大に向けて、性能観点でのパラダイムシフトとなるのは、問題が起きてから対応するというリアクティブな発想から、いかに問題を起こさないようにするかというプロアクティブな発想への転換です。
これまでは実現困難と思われていましたが、様々な性能問題解決事例とデジタルテクノロジを組み合わせて活用することで、次の性能競争力のステージ (図1でのStage3)へ到達することができました。

今回は紹介できませんでしたが、さらに先の Stage4 への取り組みも始めています。
Stage4 では、システムキャパシティがビジネスの限界、という概念を変えます。例えば、キャンペーンなどの際に、システムがダウンしないように流量制御を入れるケースがありますが、ある意味これは機会損失とも言えます。この限界を超え、ビジネスチャンスを極大まで生かすために、自動的に性能ボトルネック箇所を捉え自動でその個所に手当てを行う「オートパフォーマンスヒーリング」といった概念が必要となってきます。
現在は手動での実現個所も多く「完全オート」には至っていませんが、人間が行えることはシステムで置き換えられるため、遠くない将来にこの Stage4 を実現したいと考えています。

今回、ビジネス競争力と性能担保について紹介させていただきました。今起きている性能問題対応に追われているプロジェクトと、問題を起こさないようにするプロジェクトとの格差は広がりつつあり、これがビジネス競争力の格差となりつつあります。この点に悩みや焦りを抱いている多くの方に向けて一助となるべく、我々としても今後も継続的に情報発信をしていきたいと思います。

関連リンク
まかせいのう公式ページ