TO THE FUTURE NSSOL STORIES TO THE FUTURE NSSOL STORIES

2019-03-11 DX
TwitterTwitterでシェア FacebookFacebookでシェア

次世代企業システムを性能面から支え続ける

~NSSOLの強みと性能管理の潮流~

Benchmark & Consultation Center(BCC)の 原 伸樹さん

クライアントの望む機能は実装した。でもいざ運用をはじめたら、思ったようなパフォーマンスが発揮できていないため、評価が芳しくなかった。そのようなシステムを構築しないためにも企画段階からはもちろん、運用も含めた開発の全フェーズにて重要になるのが「システム性能管理」というエンジニアリング手法です。

NSSOLではシステム性能管理の専門チーム「Benchmark & Consultation Center(以下、BCC)」を1997年に設立し現在に至るまでシステムの性能管理技術を追い続けてきました。そして、今システムその手法のトレンドに変化がおこりつつあり、注目が集まっています。

システム性能管理とはなにか。なぜ今、システム性能管理なのか。BCC 原 伸樹さんにお話をお聞きしました。

システムがベストに動作するようチューニング

―― 「性能管理に新しいトレンドがきている」とのことですが、そもそもシステムの性能管理とはなんでしょうか。

原:性能には「量を返す能力」と「速さを出す能力」という二面があるのですが、システム要件やコスト制約を満たしながらこの両者の性能バランスを最適に管理することです。システムを開発するときには、要件定義に沿って開発を進めますが、この要件定義は「機能」が中心になります。「性能」は通常、機能には含まれないため、性能が速いとか遅いとかいうのは機能を満たす、満たさないとは全く別の観点で管理していかなければなりません。

―― 性能は開発時にはあまり気にされていない?

原:気にされてないことはないと思いますが、機能そのものの実装が確定してない中、先に性能要件を決めること自体はお客様にとっても開発ベンダにとってもリスキーな側面があるため、よほど性能が重要な指標ではない限り要件として定義することが難しいのではないかと考えています。とはいえ、お客様の立場に立って考えると、当然常識的な範囲では性能が良いことを期待されていると思います。

―― そうした要件がない状態だとどういうことが起こりますか。

原:開発の各フェーズでは、たくさんのチームに分かれて開発を進めていきます。そうした中で性能に対して特別に要件がない場合には、機能優先の開発になりがちなため、遅くなる因子がどんどん後ろのフェーズに積み重なっていき、リリースしてみたら何らかの性能問題が起こる可能性が高くなります。

―― お客様から「遅い」と言われたらどうなるのでしょうか。

原:お客様からしたら「常識として遅いだろう」ということなので、いまの開発スコープの中での修正要求がくることになりがちです。場合によっては、お客様からそう言われると修正せざるを得なくなり赤字プロジェクトにつながってしまうこともあるでしょう。

性能を担保するのはシステムインテグレータの仕事。
いち早く性能管理に取り組む

―― BCCはそうならないようにするための組織ですが活動は1997年からですね。きっかけは何だったのでしょう。

原:1990年代は、さまざまなメーカーのコンピューター、ソフトウェア、そのほか周辺機器を組み合わせてシステムを構築する、オープンシステムが広まった時代でした。しかし、異なるメーカーの製品を組み合わせることでインテグレーションの難易度が上がってしまうため、性能が出なくなる問題が頻発しました。この時、それぞれのメーカーにトラブルの解決策を問い合わせても、それは製品の問題ではないと言われてしまうことが多かったのです。そこでNSSOLではシステムの性能を担保するのはシステムインテグレータの仕事だと早い段階で位置付けて取り組んできました。

―― BCCはそうした中でつくられた部隊ですね。

原:はい。90年代前半からシステム研究開発センター(以下、シス研)で取り組んできた研究を土台に、1997年にシステム性能に関するエンジニアリング専門部隊であるBCCを設置しました。当初から「システムの性能は造り込むもの」というコンセプトでNSSOLが手掛けるシステムの品質を主に性能面で支えてきました。当時はまだ性能をどうみたらいいかもよくわからないし、性能を出すためのチューニングのノウハウも十分に浸透していない時代だったと思うので先進的な取り組みだったと思います。今でも性能の専門部署を構えているシステムインテグレータはあまりないのではと思っています。

―― これまでどれくらいの案件に携わってきたのでしょうか。

原:私個人では大小に渡り70-80件くらい、BCC全体では600件以上あると思います。私自身BCCに入ったときは、インフラ以外の知識はそれほどありませんでしたが、現場で多数のプロジェクトに携わったことで、システム開発の各フェーズでシステムの全レイヤに渡るシステム性能管理の勘所を学ぶことができました。

―― そういう専門家がBCCに何人もいるのは本当に強みですね。


クラウドとアジャイル開発における性能管理とは

―― 現在はオープンシステムからクラウドが主流になりつつあると思いますが性能管理という点で変化はありますか。

原:当然、勘所が違ってきます。これまでのオープンシステムではハードウェアのキャパシティプランニングやサーバーサイジングを行って、これくらいのトラフィックだったらこれくらいのサーバーが何台必要だと性能の「量を返す能力」を設計してきました。また専用ハードウェア適用などによるインフラとしての「速さを出す能力」の増強も有効な手段として採用されることも多くありました。これがクラウドだとCPUやメモリなどのリソースを簡単に増やすことができるので、キャパシティプランニングは事前に入念に行う必要はなくなりつつあります。また、インフラはクラウドを利用することでコモディティ化されるため、ハイエンドな専用ハードウェアを使った高速化など、インフラ面だけでは「量を返す能力」「速さを出す能力」ともに性能の差別性を出すことが難しくなりつつあると感じています。これからは、クラウドネイティブな手法を活用しながらフロントエンド、バックエンド含めたアプリケーション側で性能を作り込むことが今まで以上に重要な勘所になってくると思います。

―― 開発手法の変化という点ではどうですか?

原:そうですね。これまでのウォーターフォール型の開発は、お客様の要件に基づいた、いわば品質重視の開発スタイルです。そういう意味で事前に仕様が決まっているわけで、設計時のサイジングをしっかりやれば、リリース後は想定外の事態にならない限り性能問題は起こりづらい状況でした。一方で、アジャイル型の開発はスピード重視で、リリースされた後も短期間で機能改廃をしていくのでシステム構成もそれに合わせて頻繁に変更されます。こうした度重なる構成変更に加え、性能テストを実施できる期間も限られていることなどで相対的にシステムの性能品質を担保する難易度は上がっていくと思います。

―― 単純に聞いているとトラブルが発生しそうですよね。

原:そうしたシステム開発において、従来のテスト手法や運用手法を進化させないままだと、人手に負える範囲の限界を迎えてしまうような気がしますよね。こうした手法そのものの見直しが必須になってきます。これからは障害が発生しても素早く復旧できるレジリエントなシステム・アーキテクチャの採用、問題が起こったらすぐに影響範囲を限定し、原因を取り除く信頼性優先の運用の2つの観点が重要と考えています。

―― ところで、アプリケーションの性能の作り込みってコストがかかりそうですね。

原:はい。「量を返す能力」はリソースをスケールしていけば基本的に上がりますが、「速さを出す能力」はいかに低レイテンシを実現するか、となるのでよりアーキテクチャや実装ロジックに踏み込んだ難しい検討工程が必要で相対的に高コストになります。だからやみくもに行うとシステムの構築コストが上がってしまいます。この作り込みには常識的な数値というより、そのサービスのもたらすビジネス的な指標と合わせて考えたほうがよいです。例えば、あるECサイトでお買い物をするときレスポンスが遅いとどう思いますか?

―― ページを閉じるか、他のECサイトにいってしまうかな・・・。

原:そう。特にこうしたECサイトの場合は、ユーザが体感するレスポンスの速さが売上に直結する非常に重要な要素になってきます。実際にアメリカではWebサイトのレスポンスを100ミリセック速くするだけでショッピングサイトの購買率が数パーセント上がると言います。巨大ECサイトの場合、数パーセントといってもすごい金額です。実際特にこうしたB2Cビジネスでは、パフォーマンスそのものが競争力に直結します。米国のWeb市場では、ユーザを囲い込みたい各企業ではユーザ体感速度はビジネス上非常に重要な指標と認識されています。デジタルビジネス市場がこれから本格化してくる日本でもまさにこれからこうしたパフォーマンスへの要求が今まで以上に強くなると思います。

―― なるほど、ビジネス的なニーズとの兼ね合いで性能の目標を決めていくことが重要なのですね。

トレンドに沿った取り組み
~ノウハウの共有、ツールの自社開発や先端的な製品の導入~

―― こうしたトレンドの変化に対してどういう対策をしているのでしょうか。

原:システム性能管理は、特定分野の技術に強いだけでは難しく、システム全体に渡る広範な知識や分析方法論、またそれら方法論を実行可能にするツール群の活用が欠かせません。
まずは、システム全体のロジックやアーキテクチャ、もっと言えばコンピューターがなぜ動くのか、プログラムがどのようにコンピューター上で実行されるのか。このようなコンピュータサイエンスに関する基本を知ること。また、プロジェクトのどのフェーズでどのレイヤで性能を造り込むべきかを理解して設計を進めていかないと、最適なパフォーマンスを出すことが困難です。こうした基本や勘所は、短工期でシステムをリリースしていかなければならないアジャイルのような開発スタイルでは、非常に重要です。そこでシス研では、システム性能管理に関するサイエンスな部分を集約した性能管理ポータルを立ち上げて、社内で広くノウハウを共有しています。

―― 先ほど話が出たテストやリリースした後の運用面での対策はありますか。

原:こちらはツールの部分になりますが、シス研ではアジャイル型のスピードを阻害しない形で性能テストを行うための負荷試験プラットフォームcloadiosを開発し、既に実案件において利用を開始しています。cloadiosは、BCCのノウハウをベースにパブリッククラウドをフル活用して開発され、CI/CDの仕組みで継続的に性能テストを実施することが可能になっているため、アジャイル開発の現場における強力な性能テスト手法になります。

図:cloadiosのアーキテクチャ

また運用面ではまずはシステムの可観測性を上げるために、監視の品質強化に取り組んでおり、最新型のアプリケーションパフォーマンス管理製品(APM)に注目しています。この製品は、構成が刻々と変化するシステムに対して自動的に追随し、メトリック、ログ、トランザクションのトレースを高い精度で計測することができます。クラウドやマイクロサービスなど分散型のシステムの場合でも、ユーザ体感速度トリガで異常を自動検知し、どこの処理で何秒かかっているかがすぐわかるのでボトルネックになっているところをいち早く見つけて解決すべきポイントを提示してくれます。

―― 今までこうしたツールはなかったのでしょうか。

原:同じような機能を提供するツールはありました。ただ、クラウドのような分散システムの構成変更に追随することが難しく、対応スピードや対応コストの面で大きな課題がありました。ツールを使うだけで手間がかかってしまっては本末転倒ですからね。cloadiosやAPMは、ともにこうした課題をクリアし、次世代企業システムにおけるサービス信頼性を継続的に支え続ける技術として必須になるものと確信しています。

―― 画期的なツールですね。これからもNSSOLがシステム性能の分野で変わらず存在感を発揮できるよう期待しています。

関連リンク