[市場動向]

2014年9月16日(火)情報サービス産業協会（JISA）

はじめに

　コンピューティング・コストが極限まで安くなると何が起きるか?　あらゆるモノがインテリジェントになるとどうか？　そこまで行かないにしても、クラウドの進展は企業に何をもたらすのか?　そして、アプリケーション（ソフトウェア）開発のスタイルはどうなっていくのか？

──こうしたことを探るため、米国のIT／ソフトウェアの先端動向に詳しい成本正史氏（米マイクロソフト　パターンズアンドプラクティス シニアプログラムマネージャー）を招いた討論会「アメリカのTOPエンジニアとこれからの『IT』を語り合おう」を、情報サービス産業協会（JISA）が実施した。聞き手はJISA副会長の横塚裕志氏（元・東京海上日動システム社長）、コメンテータは細川努氏（アーキテクタス代表）である。

　ある種の極論が含まれるが、それでも成本氏の話は示唆に富む。「今までもソフトウェアは重要だったのですが、これからはソフトウェアが企業の優劣を決定づけるようになります。IT を活用できている会社とできていない会社では、当然できている会社が勝つわけです──<中略>──ITが利益を生むので、コストダウンするのではなくて、ITに倍払ってもいいから、例えばエネルギー効率を2倍改善してくれということになってくるのです」といった下りがその1つだ。

　そこでJISA会報（2014 Summer）に掲載された討論会の記事を、同協会の許可を得てそのまま転載する。なお、この記事の想定読者は情報サービス企業の経営層であることに注意頂きたい。ユーザー企業のCIOなどITリーダーの方々には多少違和感のある記述もあるが、そこは読み飛ばして頂ければ幸いである。

　なお、記事は3回に分けて掲載し、本稿はその「第2回」となる（本誌）。

第1回：クラウドやIoTは何を引き起こすのか？ 米国TOPエンジニアが語る「これからのIT」

---

設計の可視化

横塚　次にソフトウェア・アーキテクチャと開発スタイルに関して、成本さんからお話をいただきながら、議論をしていきたいと思います。

成本　新しい時代のアーキテクチャ、開発スタイルとはどういうものかをお話しします。まずクラウドでどういうふうに変わってくるかというと、設計の良し悪しが完全に可視化される時代になります。

　パブリッククラウドでは、ある意味、同じ土俵でいろいろなアプリが動いている状態になります。A社のシステムは2インスタンスで、同時アクセスユーザー500人以上に対応でき、可用性は99.9%を達成しています。

　かたやB社のシステムは16インスタンスも必要で同時アクセスは100人にもならず、可用性は99%しかないというようなことが起きます。今後こういったケーススタディがどんどん出てくるので、うちより規模が大きいところなのに8分の1のインスタンスで可用性も1桁多い数字を達成しているといったことが白日の下にさらされます。

　またクラウドではプラットフォームの品質が明確に定義されています。たとえばWindowsAzureのコンピュートでは2インスタンスで99.95％提供し、リレーショナルデータベースでは99.9％の可用性を提供しています。

　ストレージの性能はスケーラビリティターゲットとして、毎秒何万リクエストまで対応しますというふうに数値が全部公表されています。こういった数値からあまりにかけ離れた性能しか出せない場合には、使い方がおかしいということになります。

　コストも使った分だけ払うモデルなので、かたや年間10万円で済んでいる会社もあれば、100万円かけている会社もある。インスタンス数を10倍使っているからそうなるのですが、当社だけがコスト高であるということが全部見えてしまいます。

　当然、成功事例になりたいわけですが、そのためには設計が非常に重要になるといえます。我々がデザインパターンやガイダンスを積極的に提供している背景にはそういう理由があるのです。

Resiliency（復元性）

　サービス品質がビジネスに直結するケースが増えています。極端な例ではシステムが1分間落ちたら、1億円の損害を被るような金融システムもあります。1億円分のトランザクションの機会をロスするので、それを防ぐための構成が必要ということです。

　eコマースでも、例えばネットワークの遅延が1秒間起きたら、10％の顧客を失うということが起こり得ます。性能や可用性によってビジネスの売上の喪失に直結するということです。これはオンラインへの依存がどんどん強まっていることによる結果です。

　クラウドは高度分散システムです。オンプレミスという従来の企業内システムでも分散環境にあったものは設計要素という意味ではそんなに変わらないのですが、どちらかというとクラウドは分散をほぼ強制するようなアーキテクチャになっています。

　クラウドに特徴的な要素としてResiliencyという項目があります(図４）。これはいったんコケた後、いかに早く復帰できるかということです。もともとはReliability、堅牢性ということで、いかに壊さないかというメトリックスでした。

　

　もちろん壊さないほうがいいのですが、クラウドではコモディティ化されたハードウェアを使用しているので、どこかの時点で壊れると想定するべきなのです。何億円のサーバを使っているのではなくて、安いサーバを何万台、何十万台も水平にスケールアウトするモデルです。

　可用性が99.9%ということは、毎月43分間落ちる可能性があります。99.9%のサービスが5つあればシステム全体の可用性は99.5%になってしまいます。いずれかのサービスが落ちた場合に正常なものとスワップをして、また元の状態に戻します。いかに素早くそれができるかが、Resiliencyです。

　それからITILというIT運用の標準の中で、RTO（Recovery Time Objective）というメトリックスが非常に重要視されています。システムがダウンしてから復帰するまでの時間を示します。

　すべての前提としてあるのは、どこかの時点でシステムは落ちるということです。システムが落ちるのは困るから100％にしてくれというのは、経済合理性の観点から現実的ではない。100％でなくて、99.9なり99.95にする代わりにコストは10分の1になっているということがクラウドのメリットなので、それを前提にした設計にしなければいけません。

　そのためにあるのがデザインパターンです。たとえば失敗したらもう一回再試行しますというリトライです。簡単に聞こえるかもしれませんが、このリトライが正しくできている割合は非常に少ないです。

　しかし顧客のトラブルに対してアドバイスするときに、かなりの割合がこのリトライを正しくインプリすることで解決されます。そのほか、サーキットブレーカーや補正トランザクションなどのパターンを適用することで、処理が失敗した際にもその影響を最小限にとどめることが可能になります。

今後の開発スタイル

　デザインパターンは、クラウド用のものとして20～30個提供しています。この30個のパターンを使っていただければ、一通りの問題に対応できますし、それをライブラリ化する計画もあります。既存のライブラリもあります。

　さっき言ったリトライは、うちのパターンズアンドプラクティスというチームから出しているライブラリがあるので、それらを使っていただければ多くの問題は解決されます。

　パターンや既存のコンポーネント、ライブラリを全部調べるためには、常にアンテナを張っておく必要があります。皆さんの社内でも、マイクロソフトやオープンソースソフトで、どういうものが使われていて自分たちのプロジェクトの役に立ちそうか定期的に調べることをお勧めします。

　それから継続的デリバリーとは、アプリケーションがクラウド上でオンラインで動いているので、開発からテスト、リリースまでを手がけてそのままプロダクションとして提供することを継続して繰り返すモデルです。

　従来のパッケージソフトは早くても1年、マイクロソフトのOSも3年周期でリリースしていました。クラウドプラットフォームであるMicrosoft Azureは、極端な話をすると1日とか、1カ月で機能が変わっています。

　リファクタリングとは、デザインパターンなどのプラクティスを適用して既存のプログラム・コードを最適化することです。先ほどもお話したとおり、クラウドのQoS（Quality of Service）は可視化されているため、アプリケーションの設計の良し悪しが見えてしまうわけです。ある呼び出しをしたら、その呼び出しの遅延がどれだけあるかが分かります。毎月落ちていた時間が数値として出て、可用性が悪いことがわかってしまうということです。

　問題があるところには、パターンを適用してそれを直すチャンスがあります。これからは問題を発見してリファクタリングし、すぐにサービスを更新して運用した結果をフィードバックすることで継続的に改善していくという開発スタイルが主流になるでしょう。我々もこれからそういう作業をサポートするためのツールを提供していきます。

　今日ではベンダーやオープンソースのコミュニティからツールが山のように出てきます。これらが毎月のようにバージョンアップし、新しいコンポーネントが出て、いまあるコンポーネントがディプリケートされてサポートされなくなりますから、ツールの取捨選択スキルが非常に大事です。

　アジャイル開発についても話しましょう。米国でアジャイルの話をすると、「アジャイルは日本から来たものでしょう？」「スクラムとかは、日本から来たのだから日本では当然進んでいるでしょう」と言われます。

　しかし日本の現場で導入されているかというと、必ずしもそうでもないですよね。私はアジャイルの専門家ではないのですが、向こうで働いていて感じるのは、コミュニケーションスタイルが非常に大きな要因だということです。

　日本のコミュニケーションは効率的です。一度言ったことは2度言わないという人が多いでしょう？一方でアメリカとか、アメリカに来ているほかの外国人はどうかというと、無駄なことをたくさんしゃべっているのです。同じことを1回、2回と繰り返し話すし、「あれはどうなった？」と、昨日と同じことを平然と聞くわけです。でもみんな特に嫌な顔もせず答えます。

　そうこうするうち、こちらではそういうコミュニケーション・スタイルなんだということに気づきました。効率的な会話は一見良さそうに聞こえるのですが、ともすると会話の阻害要因にもなりかねません。

　一方で同じ内容で何度でも気にせずに会話を続けるのは、効率は悪いのですが、確実ですし、そこから派生する会話などが新たな気づきをもたらすことも少なくありません。自分のプロジェクト管理の経験からすると、コミュニケーションの量を増やし、かつ質を上げることはものすごく大きな成功要因だと思っており、自分のプロジェクトではそういった雰囲気づくりに努めています。

細川　私は大きなプロジェクトを2つ見ています。どちらも1秒間あたり数十万トランザクションを動かす、かなり大規模なミッションクリティカル・システムです。片方は数十億円ぐらいの規模で、従来技術を使って堅牢性を重視した2フェーズコミットをガチンガチンに使い、少数のTOPエンジニアがいるほか、全体はあまり理解していないけれども一生懸命頑張る人たちがいっぱいいるという従来型のプロジェクトです。

　もう片方のプロジェクトは、数億円の規模ですが、少数精鋭で全員がアーキテクト的にシステムのデザインをどうするべきと考えながら、しかもアジャイルでやっているプロジェクトです。両方を見ていると、前者のほうが儲かるかなと思うのですが、要求変化への対応力、ものづくりのスピード感からすると、やはり後者のほうが競争力はかなり高いわけです。

　ビジネス的には前者がおいしいのですが、やっていると後者のほうが楽しいし、トラブルも後者のほうが少ないのです。こういう実態からすると、後者のスタイルも今後必要になってくるのではないかと思います。

　したがってキーワードはデザインパターン、継続的デリバリー、アジャイル、それにDevOpsです。私が見るところインフラの構築だけで数億、下手をすると10億ぐらいというケースもあります。DevOpsで優秀なプログラマーが短期間でインフラを構築するスピード感で見ると、やはり今後、情報サービス産業の変化は大きいのではないかと思っています。