ITの地殻変動はどこで起きているのか～アーキテクチャ設計技術にクラウドが必須になった時代

2014年になって、ITの地殻変動がどこに起こっているのか、を考えてみる。
＃ラフなメモ書き。

【1】最近感じることは、Webアプリをプログラミングするアプリケーションエンジニアよりも、サーバー基盤を構築するインフラエンジニアの方が目立つというか輝いて見える時が多い。
何故なのだろう？

また、先月の日経BP主催のITアーキテクト カンファレンスでは、エンタープライズシステムの構築に携わるITアーキテクトを対象にしているが、その内容はすべて、クラウドがキーワードだった。
DOAやOOAは全く含まれていない点が衝撃だった。

ITアーキテクト カンファレンス 2013

最近の流れを見ると、アーキテクチャ設計の技術では、DOAやOOAは既に古い技術であり、クラウドが席巻しているように見える。

【2】最近のバズワードである「クラウド」には、否定的な意見を持つ人も多い。
ITの歴史の延長線上にあるだけで、そんなにすごい価値があるわけではないだろう、と。
単に仮想化なんでしょ、と。

クラウドサービスも、大昔のデータ計算センターや電算受託から始まったシステムサービス提供形態の現時点での変化形に過ぎない、と。

実際、ERPやメールサーバなどをクラウドへ構築する場合でも、フィットギャップ分析、セキュリティレベル、運営のコンセプト確認、負うべきリスクの整理、サービスレベル(SLA)の定義、など、従来の手法で検討する必要がある点は変わらない。
システム、ネットワークなどの利用面の進展があっても、利用に当たっての検討項目は本質的には同じである。

【3】しかし、クラウドが新しい観点をもたらし、アーキテクチャ設計に大きな影響を与えた点は2つあると思う。

【3-1】一つは、インフラ構築もアジャイルにプログラミングで開発できること。
その意味については、下記の記事で色々考察した。

クラウドの本質はインフラ管理のIT化: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例: プログラマの思索

「Infrastructure as Code」というキーワードがまさにそうであるように、サーバー構築手順は全てプログラム化できる。
従来は、サーバー購入や構築手順をあらかじめ計画段階で入念に実施し、レビューしてから作るというウォーターフォール型開発っぽいやり方しかなかったけれど、クラウドのおかげでサーバー構築もアジャイルに開発できる。

アジャイルに開発できる利点の一つは、失敗を何度も許容できる点があるだろう。
特に、サーバーの障害テストや負荷テストを何度もやり直せる利点はとても大きい。
従来なら、サーバーの負荷テストや障害テストは、準備も実行もすごく手間がかかりすぎて、何度もやり直すべき作業ではなかった。
アジャイルに障害テストや負荷テストを実施できることで、最初の計画を完璧にしなくても、プロトタイプのようにサーバーを構築して実現可能性(フィージビリティ)を調査したり、運用に合わせてハードウェア構成を柔軟に変える、などのオプションを持つことができる。

障害を故意に起こさせるツールで耐障害性を高める: プログラマの思索

また、クラウド化することで新たに判明する点は、ソフトウェアの品質がそのままコストに跳ね返ってくる点だろう。
例えば、CPU使用量やメモリ使用量を10%削減できれば、請求代金を10％削減できるのだ。

クラウドではソフトウェアの品質が課金の差として出てくる: プログラマの思索

つまり、クラウドでは下記の公式が成り立つ。

ソフトウェアの品質の差＝パフォーマンスの差＝課金の差＝コストの差＝利益率の差

従来は、一度、サーバーを構築したら、そのハードウェア構成を変えるのは、次のハードウェアリプレースまでできなかったが、クラウドなら、柔軟にハードウェア構成を変えることができる。
したがって、クラウドによって、ソフトウェアの品質特性として、特に効率性(パフォーマンス)がより重要になってきた側面があるだろう。

他にも、クラウドによって、システムの移植性が高まる、信頼性の観点は壊れないシステムよりもすぐに直せるシステムの方が重要、など、品質特性の観点が変わってきた。
今後は、クラウドとエンタープライズのシステムの組合せでは、機能性や信頼性よりも、保守性・移植性・効率性の品質の方が重視されてくるだろう。

アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索

アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索

なお、クラウドで使われるツールで注意すべき点は、Chefなど、Rubyで書かれたプログラムが多いこと。
クラウド時代のサーバー構築では、Rubyという技術が必須になってきているように思える。

【3-2】もう一つは、DOAやOOAやサーバー構築の設計では、その時代の技術の制約があったために、バッドノウハウになっていた箇所に対し、クラウドを使うことで本来の目的がクローズアップされたこと。

クラウドを使ったサーバー構築の設計では、クラウドデザインパターンがまとめられているので、参考にすべきだろうと思う。

クラウドデザインパターン～インフラ方式設計のベストプラクティス集: プログラマの思索

クラウドアーキテクティング原則 - AWS-CloudDesignPatternに掲げられた下記の原則は、クラウドの使い方について的確に示していると思う。

◆できるだけサービスを利用
◆机上実験よりも実証実験
◆スモールスタートからスケールアウト
◆変化に対し全レイヤで対処
◆故障のための設計(Design For Failure)
◆最初だけでなく周期的なカイゼン

また、DOAでは、サマリ系テーブルは夜間の日次バッチ処理(特にCobol)で作る、とか、正規化しているために参照関係の複雑なテーブルを結合して参照するしかない、などの弱点が従来はあった。
でも、クラウドが出てきて変わった点は、MapReduceのような並列処理と相性が良いので、大量データを短時間で処理できる設計も可能になったこと。

更には、RDBを使うとパフォーマンスが出ない場面では、クラウドと相性の良いNoSQLを組み合わせて、KVSやドキュメント指向DB、列指向DBなどを使うことで、問題解決できる場面があること。
よく聞く場面は、SNSやソーシャルゲームのログイン時にユーザ情報を参照する処理のように、単純な参照処理だが大量のアクセスが発生する状況で使われる。

データベース技術の今後の動向: プログラマの思索

最近「ビッグデータ」というバズワードが頻出される理由は、クラウドが並列処理と相性が良く、大量データを短時間に処理できるために、大量データから意味ある論理を導くデータマイニングが注目されているからだろうと思う。
従来のDOAでは、データウェアハウスのような設計思想もあったけれど、パフォーマンスが悪くて、なかなか手軽に使えなかった状況があったからだ。

現場の業務システムは、運用後にかなりのトランザクションをためているものの、それらのデータを解析(データマイニング)して、そこから得られた知恵を再利用する手法はほとんど取られていない。
よくある例は、購買履歴から顧客の購買動向を分析するCRMが欲しいという要望が多かったが、その仕組みが従来はなかなか作りにくかった、という弱点があったと思う。
Amazonのおすすめ商品のような協調フィルタリングを実装するのは敷居が高い。

他にも、従来のDOAでは、製造業向け生産管理システムのMRP(部品の所要量計算)、会計システムの自動仕訳とPL・BSレポート出力も、普通は日次バッチ処理で1日1回(または月次バッチで月末1回、年次バッチで1年に1回)作られるだけだった。
従来のDOAを支えるRDBMSの制約、バッチ処理プログラムの性能が出ないなどの制約などの理由で、夜間バッチ処理でしか対応できなかったのだ。

「オンプレミス・システムの終わり」の始まり～AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道

基幹系バッチ処理をHadoopで高速化: プログラマの思索

Hadoopの本質は分散I/Oにあり～クラウド時代の非同期処理: プログラマの思索

クラウドのもう一つの本質～ソフトウェアの可搬性を確保する: プログラマの思索

でも、クラウドとデータマイニング・データ集計の並列処理を組合せることで、CRMのデータを手軽に作り出せる。
MRPによる原価計算や、自動仕訳後のPL・BS出力も1日数回以上実施できるようになる。
そうすれば、原価計算や会計処理、CRMなどの経営分析も、アジャイル開発っぽく、何度も試行錯誤しながら仮説検証していくスタイルを実施しやすくなる利点がある。

最近、リーンスタートアップという経営手法が注目されている。
その理由は、経営手法でもアジャイル開発のやり方を実践して効果が出せるからだと思うが、その背景には、クラウドを使って、少人数でWebサービスをリリースすればすぐにビジネスを開始でき、スケールアップも容易である特徴を生かしているからだと思う。

クラウドという単なる一つの技術が、従来のDOAやOOAでは解決しにくかった問題に対して有効である場面が増えてきている。
それら効果についても今後、追いかけてみる。

【追記】
クラウドとセットで語られるNoSQLについては、7つのデータベース 7つの世界の本が個人的にはお勧め。
7種類のDB(PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4J、Redis)の特徴について、広く深く記載している。サンプルソースもあるので、とっつきやすい。