エンタープライズにおけるDevOpsとマイクロサービス - JavaOne2015レポート
バズワード過ぎてタイトルにするのも憚られるのですが、JavaOne2015でキーワードになったことは間違いないので...。
JavaOne2015でもDevOpsやマイクロサービスについてのセッションが多く見られました。昨年はマイクロサービスというとWebアプリケーションフレームワークからの理想論的な話が多かったですが、今年はわりと事例に基づいた話が多かったように思います。ただ事例は事例で抽象的な話にならざるを得ないわけで、目新しい話があったわけではないように思います。
あと「Java（JVM）を使っているよ」というだけのことで、直接的に「Javaでどうすべき」という話は少ないです。これもDevOpsやマイクロサービスが特定の技術の依存しているわけではないから当然のことかと思います。
事例そのものはよく知られたWebサービス系の事例が中心となっていますので、Netflix、Gilt、Twitter、Foursquareなどが色々な話をしていました。これらの事例は、まさにマイクロサービスとして数百のサービスを稼働させています。
よって、技術的なキーワードはランタイムの制御を行うことに力点が置かれていました。具体的には以下のようなものがあげられます。
- デプロイ管理：Jenkins、spinaker
- コンテナ：Docker
- コンテナ管理：Kubernetes、Marathon+Mesos、spinaker
- ルーター：Vamp、Zuul+Ribbon、ロードバランサ
- サービスレポジトリ：ZooKeeper、Eureka
- 分散ログ集約＋視覚化：Elasticsearch+Kibana、Vector
これらの技術群はサービス全体をダウンさせることなしに継続的にサービスの変更を許容するための仕掛けです。代表的な概念が「カナリアリリース」でしょう。
カナリアリリースは現状バージョンのサービスがリリースされている状態で新バージョンのサービスを並列してリリースし、段階的にアクセス先を新バージョンに切り替えていきながら、何か問題が発生したら現バージョンにアクセスを切り戻す（ロールバックする）というものです。「A/Bテスト」や「ブルー・グリーン・デプロイメント」と呼ばれる手法とも近しいものですね。
カナリアリリースの説明。新しいバージョンに5%を振ることでA/Bテストになる
カナリアは炭鉱で鳥かごにいれられて天井近くに吊るされており、有毒ガスが発生すると騒ぐため「問題の発生を先んじて発見する象徴」として使われています（カナリアにとっては迷惑な話でしょうが）。
Giltの事例では「ダークカナリアリリース」という言葉で「開発者だけがアクセスできるテストバージョンのサービスをリリースする」という話をしていました。マイクロサービス環境ではサービスをテストするのに周辺サービスをセットアップしないと稼働確認がしにくいわけですが、周辺サービスのセットアップは大変なので、そうであれば本番環境にテストバージョンのサービスをリリースしてしまい動作確認をしたほうが効率的というわけです。もちろん課金などの関わる本番に影響を与えるようなサービスについてはテスト環境を持っていると話していましたが、そうではないサービスは本番でテストしたほうが効率的なのでしょう。
Giltのセッションでの1ページ。『我々は本番環境でのテストはいけてると考えている』
また、NetflixにはChaos Monkeyという「障害をランダムに発生させるツール」があるのですが、AWSのインスタンスは毎週、アベイラビリティゾーンあるいはリージョン丸ごとは毎月障害を発生させているそうで、知ってはいたものの実際に聞いても信じられないという思いが先に来てしまいます。
Netflixのセッションで紹介された動画。左上のリージョンがダウンし、アクセスが他のリージョンに移った後、リージョンが復旧して戻っていく様子
エンタープライズ業界にいるとダークカナリアもChaos Monkeyも「それは厳しい」という話かと思います。もちろん「テスト環境よりも本番環境でテストしたほうが良い」とか「本番で障害訓練をしていたほうが本当の障害に対応できるようになる」というのが合理的であることは間違いありません。しかし、その結果として「全体的にサービス品質を高めるためには部分的な品質劣化を許容する」というのは「部分の品質を積み上げることで全体の品質を担保する」というエンタープライズ的な考え方からすると理解しがたいものです。
Netflixの考え方は「運が悪いユーザーがいることを許容することで大規模なサービスダウンを未然に防ぐ」というものですが、講演者も「Netflixがダウンすることは悲しいけど、とはいえ、絶対にダウンしてはいけないサービスではないことが前提だ」と強調していました。「軍事、医療、金融といった分野で許される考え方だとは思わない」と。
よって、DevOpsというか、マイクロサービスというか、Web企業の先端的な取り組みについては「それはそれで効率的なことは理解する」ものの「すべてのサービスがそうなるべきかは別の話」ということでしょう。
また、マイクロサービスにしても「チーム個別の自治権を許容する」ということは、チームごとに品質のばらつきがあることを許容することと同じです。これもまた従来型の品質管理からすると受け入れがたいものですね。
もちろん、エンタープライズにおいてもカナリアリリース的発想は重要でしょうし、それが認められる分野も間違いなく存在します。システム連携が複雑になる中で「単体アプリケーションレベルでの完璧な品質」など意味がないのであれば、サービス全体の品質を判断基準にしていくのは当然のことでしょう。
ただ、現状で取り組もうとすると先ほど上げたような技術群は安定的とはいいがたく維持コストは相当なものとなるはずです。とはいえ、エンタープライズでもDockerがデファクトスタンダードになりつつあるわけで、コンテナ技術を前提としたプラットフォームマネジメントツールが一般的になってくるのは間違いないものでしょう。
たとえばAzureではセキュリティアップデートのために仮想マシンの自動的な再起動が起きるため、これを前提としたアーキテクチャ（異なるロール間の受け渡しにはキューを利用する）を採用する必要がありますが、こうした割り切りは今後も増えていくはずです。
クラウドを契機に品質の概念はずいぶんを変わったものになりつつあります。例えて言うなら「ガベージコレクションがメモリ管理を不要にした」のと同じように「プラットフォーム管理ツールがインスタンス管理を不要にする」という未来が待っているのでしょう。
アジャイルとウォーターフォールと同じように「既存の考え方を安易に否定する」のはダメですが、全体的な潮流を理解しながら技術の使いどころを俯瞰していくことは重要ですね。
JavaOne2015のサマリ
2015/10/25-29日で行われたJavaOne 2015に参加してきました。
来年のJavaSE 9および再来年のJavaEE 8に向けた端境期であったこともあり、近年まれに見る発表要素の少ないJavaOneでありました。
特に初日のキーノートでは、Java 20周年であったことから、スコット・マクニーリがやらかしたので最低限のお祭り気分は維持されたものの、昨年からのアップデートも少なく、特筆すべき話題はありません。
キーノートで言いたい放題のスコット・マクニーリ
一方、最終日に行われたコミュニティキーノートはバック・トゥ・ザ・フューチャーを模した寸劇の連続で、2009年に遡れば「SUNがORACLEに買収されちゃった！どうしようJavaが有償になっちゃう！」とか「OSGiは古い、これからはJigsawだ。ORACLEなら2010年か2011年には仕様になるよ！」と言ってみたり、2004年に遡れば「Javaがオープンソース化されてOpenJDKができるだって！なんてSUNは素晴らしいんだ。これでどっかに買収されるなんところはなくて未来は安泰だね！」などなどコミュニティメンバーが言いたい放題で大いに盛り上がりました。
コミュニティキーノートの寸劇の最後は20年後の未来で暴れていたDukeを子供が救ったというハッピーエンドで（だから40周年おめでとう）。後はみんなで檀上に上がってケーキを食い尽くす
「さしたる発表もなかった。Javaは勢いがない」という意見もあるところですが、直前にORACLEがJavaエバンジェリストの解雇を発表したりと、Java全体としては明るい話題は少ない中でも「Javaの独立性は保たれている」という気概は現れていました。
以前も書いたように、ORACLEの良さは淡々とスケジュール通りにリリースするであり、コミュニティとの関係をうまく保ちながら前に進んでいると思います。昔のような派手さがないことは寂しい一方で、イベントとしてはモスコーニから少し離れたHiltonとParc55を根城に好きにやらせてもらっているのだと思います。
少し技術側からの話題を。
IT業界全体としてはIoTブームではありますが「サーバサイドとしてのJava」「タブレットや組み込みとしてのJava（含Android）」は、もはや語る必要もないほど活用されていることでしょう。「IoT」というキーワードは出るもののORACLEとして製品が出るわけでもなく、普通に「使われているよ」というアナウンス程度だった気がします。
IoTについては「機械の稼働状況を広く収集し分析してメンテナンスに役立てる（広く言えばF1も含めて）」という定番はあるものの、そこから踏み越えた事例が出てきていません。ようは「これまでの技術の組み合わせ」であり「個別のニーズが多岐に渡りすぎる」ことからソリューション化がしくくく「ベンダーとしてIoTで儲けるのは困難」という結果として言葉の勢いが落ち着いてくると思われます。
むしろ、AWSやAzureをはじめとしたクラウドサービスとしては「収集と分析」という部分で強みを発揮しており、ここで乗り遅れているORACLEは存在感を発揮しきれていません。OOWではクラウドサービスの発表もあり、JavaOneでも「ORACLE CloudでJava」という内容は何度かは出てくるのですが「推してます！」というよりは「こういうものありますので…」程度のものでした。
JavaOneにおける僕の観測範囲では「DevOps」や「API」を基軸にした技術が注目だったのですが、そちらは別記事にて。
いずれにせよ、来年はJavaSE 9のリリースと合わせてJavaOneが開催されます。まだ、何が入るのかは議論の余地があるところですので続報を見ながら楽しみに待ちたいと思います！
お約束のトレジャーアイランドでのパーティ
柔軟なウォーターフォールはアジャイルと見分けがつかない
2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～』のレポートです。資料は以下。
講演の後の懇親会で「計画的なアジャイルと、柔軟なウォーターフォールは見分けがつかない。ていうか、名前だけの問題だ」という話になりました。
資料でも書いているとおりエンタープライズ案件はリリース日について厳密なコントロールを求められます。一方で、多くのプロジェクトではリスク管理が重要であることは間違いなく、だからこそ、アジャイルでもウォーターフォールでも（まともなプロジェクトであれば）実質的なオペレーションは似通ったものになるというのです。
確かに、僕の経験から言っても、一度アジャイルを経験してしまうと「ウォーターフォールかどうか」というのは希薄になって「計画すべきはどこか、作って試すべきはどこか」という問いが重要になります。
最近の案件でも「アジャイル開発でやりたい」と言われたところで、結局、リリース日や必須機能が決まっていれば、アーキテクチャ設計を入念にやって、確度が上がったら長めなバックログを作って、中期のマイルストーンを決めて、他システムを巻き込むテスト計画を立てて、となってきて「あれ、これウォーターフォールじゃね？」ということがあります。ただ、もちろんのことながら、必要なだけのプロトタイミングやオンサイトやペアプロやオンライン情報共有や自動化や、様々ないわゆるアジャイルなプラクティスはやればいいだけです。
よって、「十分に柔軟なウォーターフォールはアジャイルと見分けがつかない」というか「十分に計画的なアジャイルはウォーターフォールと見分けがつかない」わけです。こうなってくると、たしかに呼び方だけの問題かもしれません。
喩え話的に「COBOLからJavaが主流になった瞬間、もはやCOBOLで作ろうなんて誰も思わないけど、実際にはCOBOL的なJavaはあったし」というのが引き合いに出たのですが、つまり「ソフトウェア開発といえばアジャイルプロセス」というのが「常識」となった瞬間に「ウォーターフォールはアジャイルの亜種」になるのではないか、というのです。言語と開発プロセスを並べるのは簡単ではありませんが、言いたいことは良く分かります。
僕も「アジャイルを目的にした開発は嫌い」ということは言ってきたのですが、世の中の認識が「普通、アジャイルでしょ」となってきているのであれば「ウォーターフォール的な要素も残そうよ」という言い方にしていってもよいかもしれません。とはいえ、エンプラ系の講演で「もう普通はアジャイルですよね？」とかいうとぽかーんとされそうですが...。
なお、資料の方はプロセスとして「ウォータフォールとアジャイル」、アーキテクチャとして「SOAとMSA」と対比させ、現在は後者を主流としながらも、どちらも必要な要素であることをお話させていただきました。どちらも「トップダウンとボトムアップ」の対比として考えることができますよね。
（SOAとMSAの比較も盛り上がりましたが、それはまた別の機会にでも書きます）
アーキテクチャ設計の意味を問う - クリストファー・アレグザンダーの思考の軌跡
建築家クリストファー・アレグザンダーが「パターン」という概念を広め、それがウォード・カニンガムとケント・ベックによってソフトウェア開発のデザイン・パターンに応用されたことをご存じの方も多いでしょう。
（ご存じでない方には、江渡さんの「パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)
「クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う
この本を読むと、アレグザンダーは一貫して”数学的”であり、客観的に証明可能な構造を求め続けたからこそ、近年では”神”の視座へと導かれていったのだと分かります。
パターン・ランゲージと設計プロセス
アレグザンダーはパターン・ランゲージによって、モノの”形”と、それに対する人の”価値”の美しい関係性を探求していました。
ある形をデザインする際の難しさは、複数の要求に対して全体的な整合性を取ることです。ソフトウェアのアーキテクチャ設計でも性能と保守性、コストとセキュリティなどの要件は「こちらを立たせれば、あちらが立たず」になりがちです。
そこで、パターン・ランゲージと呼ばれる複数の「部分的な形の基準（＝パターン）」を用意しました。パターン・ランゲージを用いて要求を部分へと分解し、それらを再統合していく過程で、部分ごとに要求と形のギャップを解決していけば、美しい形を自動的に作り上げていけると考えたのです。
パターン・ランゲージが興味深いのは、単に「優れたパターンを用意しました」ということではなく、「パターンを基準として要求とのギャップを探索することで、段階的にデザインが進められる」という設計プロセス論であり、かつ、それは「誰が使っても同じ結果に至る」ことを前提にしていた点です。
機能の限界
しかし、こうした設計プロセスでは「形と価値への探求」が「形に与えるべき機能」と「機能がもたらす価値」という議論に分裂することが分かりました。そして、アレグザンダーは「機能」の議論を突き詰めていっても美しい形にはたどり着けないことに気づいたのです。
そもそも、人は「”形そのもの”に価値を感じる」のではなく、その「”形がもたらしうる機能”を通じて価値を解釈する」こと、言い換えると「形への意味づけ（≒機能）によって価値を考える」ことが脳の構造的に好きなのです。よって、価値と形を直接的には結びつけずに「価値から機能へ、機能から形へという変換」が発生していたのです。
この変換には、どうしてもデザイナーの志向性が反映されてしまうため「誰が使っても同じ結果に至る」ことができないのはもちろんのこと、美しいものとはなりませんでした。
なぜ通販番組で物が売れるのかと言えば、それは「触れて分かる形への直感的な価値を感じた」ではなく「機能への説明に対する概念的な価値を感じた」によるものなのでしょう。しかし、買った物を使い続けられるのかというと、それはまた別の話なのです。「美しいと感じる」ことと「機能が優れている（と納得した）」ことには乗り越えられない壁があるのです。
これは現代的に言われる「デザイン手法」に対する痛烈な皮肉とも捉えられます。つまり、「よく考えられたデザイン」であるほど、それは「機能と価値」という概念的な議論にすぎず、「形と価値」という具体的なモノ（存在）への探求ではないわけです。
中心的な価値基準の存在
この絶望は、アレグザンダーを次の段階へと進めます。
アレグザンダーは『（形に対する）諸価値基準の相違は、ある1つの中心的な価値基準に訴えることで解消できる。＜中略＞それをわれわれは一者（the One）や無（the void）や偉大なる自己（the great self）と呼んでもいいだろう』という、”いっちゃった”考えにたどり着きます。
とはいえ、論理は明快です。人は価値を機能によって考えがちではあるが、理由無く形に感動できるので、やはり、「形と価値はどこか深いレベルで直接的に関係している」としたのです。
そこで「価値は（形の）全体性からもたらされる」と考え、さらに「機能は全体性の動的側面に過ぎない」としました。
たとえば建物というのは、その形が独立して存在するものではなく、その周りにある庭や道路や隣家や、あるいは街や国のような存在から連続した全体性として存在します。そして、機能というのは「全体性の中で（構造が見いだされるときに）立ち現れてくるもの」だとしました。
こうなると機能を追い求めることは無意味となります。機能は全体性から生成されてくるものなので、機能そのものを直接定義することはできないのです。むしろ、優れた機能を提供し続けられる構造そのもの、つまり、形そのものを探求する必要があります。
よって、機能を部分的な静的構造と紐つけたパターン・ランゲージは否定され、価値ある機能を生み出し続けることができる構造を特徴づける幾何学的特徴を探求し、15個の幾何学的特徴を提示しています。
この15個は「自己と似ている形を探し続ける」という不思議な手法で見つけられています。アレグザンダーは形に対して感じる美しさ（≒価値）というのは「自己の中にある究極的な自己」と「全体性から現れる瞬間的な構造」が一体になることでもたらされるとしています。よって、「自己と似ているもの」を探すことが、美しいものを探すことになるのです。
この説明は形而上学的なので一見するとオカルト的ではありますが、形と自己に対する純粋な解釈によって成り立っています。この力強い精神は、納得感とは別として感銘を受けるものです。
戦い
2012年にアレグザンダーは"The Battle"を発表しています。これは日本の盈進学園東野高等学校で起きたことをまとめたものです。東野高校はアレグザンダーの成功例として知られていますが、これを作り上げるにあたり起きた様々な出来事をしるしています。
この部分はぜひ本で読んでいただければと思いますが、ソフトウェア開発の人にとっては「ウォーターフォールとアジャイルのせめぎ合い」を感じることができると思います。
そして、そこで語られるアジャイル的思想の純粋さに恐ろしくなるはずです。開始時点では完成形は分からない、費用は予算によってのみ決まる、実物を触ることでしか設計しない、完成した物に対して常にフィードバックを行って修正する。これをウォーターフォールしか知らない人たちと共にやりきろうとする。これがアレグザンダーが経験した戦いなのです。
ソフトウェア開発におけるアーキテクチャ設計
さて、せっかくですから最後にソフトウェア開発におけるアーキテクチャ設計に寄せましょう。
アレグザンダーがパターン・ランゲージを諦めたからと言って、デザイン・パターンが無意味であったわけではないでしょう。ただ、やはり現代においては意味が弱くなったとは考えたほうが良いように思います。
おそらく、現代のソフトウェアは、アレグザンダーの言う全体性の議論を考慮しないといけないほど、部分では語れない連続的なものへと成長したと捉えるべきなのでしょう。静的（クラスの構造）なパターンは、ある閉じた系においては美しく存在できますが、開いた系では周辺からの圧力によって美しくはなれず、むしろ、美しさとは動的（インスタンスの動作）に現れるものなのです。
これがマイクロサービスアーキテクチャの議論に結びつきます。マイクロサービスアーキテクチャは、静的な構造としてだけではなく、各システム間の依存性や開発プロセスといった動的な要素を取り入れています。これがソフトウェアアーキテクチャ論の進化の方向性であることを感じさせてくれるのです。
最後に「優れた物から見つけられた秩序を他者が実践しても優れた物ができるとは限らない」ことを付記しておきます。「成功した人の手法を真似ても成功するとは限らない」という身も蓋もない話です。アレグザンダーが言うようにデザインとは「する」ものではなく「成る」ものなのです。
企業システムとマイクロサービス #DF15
Salesforce.comのグローバルイベントであるDreamforce 2015（2015/9/15-18）に初参加してきました。仕事ではAWSもAzureも使うのですが、今回は最近なにかと縁があるSalesforceの雰囲気を感じに。
現地では事例セッションを中心に聞いて回りました。ご存じの通りSalesforceはエンタープライズ領域で使われるものなので、事例もエンタープライズ系が多くなります。エンタープライズということは「既存システムがある」ことが前提になるので、それらの既存システムとSalesforceをどのように統合するのか、というのがアーキテクチャ設計上の重要なポイントとなります。
（もちろん、スタートアップのベンチャーがSalesforceを活用してビジネスローンチを早めた、なんて事例もありますが、この場合は既存システムが存在しません）
各セッションでは既存システムを「ドメインサービス（Domain Service）」と表現しており、それらとSalesforce（あるいはHeroku）はAPIを通じて統合されます。
「ドメインサービス」というのはDDD用語ですが、特定のビジネスドメインにおけるサービスを指しています。企業システム全体の視点から見ているので、粒度は「棚卸システム」「商品カタログ」「支払」「顧客情報」なんで感じです。
ドメインサービスは、それがクラウドかオンプレかということは関係ありません。「企業内における特定ドメインのサービスである」ことが重要であって、サービスが提供できていれば実装方式はなんでもいいのです。
以下は百貨店Macy's（メイシーズ）の講演で使われていた資料です。
連携に使われるAPIはバッチ系、オンライン系、画面連携系と類別され、それぞれの統合するデータ量やタイミング、あるいはビジネス上の結合度などで使い分けられます。IoTクラウドも発表されたので、今後はリアルタイムストリーム系という統合も可能になるのでしょうね。
以下は家電量販店Target（ターゲット）の講演で使われた資料。バッチ連携をData、オンライン連携をBusiness、画面連携をUIと表現しています。
また、企業システム内の各サービスを総称して「マイクロサービス」と呼ぶのは一般的なようでした。「うちの企業にはXX個のマイクロサービスがあって、統合されている」という言い方です。
前回のSpringユーザー会の夏イベントでも話しましたが、マイクロサービスアーキテクチャは「マイクロ」という単語に惑わされず「サービスを複数のサービスから構成する」という関係性に注目して理解すべきです。
というわけで、各セッションは「当然そうだよね」という話ばかりだったので違和感もなく聞けました。やはり、エンタープライズの文脈からもマイクロサービスアーキテクチャ的な考え方は有効であり、クラウドも、その一部として配置すればいいだけです。
印象的だったのは上記のようなユーザー事例講演はユーザー企業内のアーキテクトが話をしている点です。やはり企業全体を理解したアーキテクトの存在というのは非常に大きいなと思います。
日本国内において、その役目を誰が担うべきかは簡単な議論ではありませんが、僕自身、そうした立ち位置での仕事も増えており、今後も大きなニーズがあるのだろうことは間違いないでしょう。
さて、来月はJavaOneですね。
マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャ（以下、MSA）という言葉を聞くようになりました。きっかけはファウラーのブログ「Microservices」（2014年3月）ですが、昨年10月のJavaOne SFでも多くの講演でMicroservicesという言葉を聞かれ、多くのエンジニアがすぐに共感していたことが分かりました。今後、日本でも広く知られる言葉になることでしょう。
一方でMSAは誤解を招きやすいバズワードとも言える気がします。というわけで、僕なりのMSAについての考えをまとめてみました。
MSAは「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」というものです。逆に言えば「大きなウェブサービスを作ろうと思ったときの定石」といえます。「各要素を疎結合に構成し、連携する」「それぞれの要素に適した技術を使う」といったアイデアは突飛なものではありません。
大きなウェブサービスであればMSAという言葉がある前からMSA的に作っていたでしょうし、僕自身もそのようにシステムを設計していました。もちろん、先進的な企業ならではの取り組みもありますが、基本的な思想は同一です。
ですから、MSAがブームになったからといって「MSAを目的にしたアーキテクチャ設計」をしたところで失敗することになります。対象システムにとって適切な手法を選択したら自然にMSAになるはずです。それを無理にMSAにすべきではありません。アジャイルを目的としたプロジェクトが失敗したように、手段を目的としてはなりません。優れたウェブサービスがMSAであっただけで、MSAを採用したから優れたウェブサービスになるわけではありません。
SOAとMSA
エンタープライズであればSOAとの違いについて考える必要があります。資料中にもありますが、僕はSOAがトップダウンの理想論であったのに対して、MSAはボトムアップの現実論として捉えています。これは時代背景の違いと言えるでしょう。
SOAは「バラバラであったシステム群をいかに統合していくか」が課題であった時代に創られた言葉であり、一方で、MSAは「巨大なサービスをいかに複数のシステム群で構成するのか」が課題の現代における言葉です。SOAからMSAまでの10年で状況が変わったのです。
MSAと政治学
個人的な興味ですが、SOAからMSAへというアーキテクチャ設計の移り変わりは、政治学における「封建制」「君主制」「民主制」という流れと似ていると考えています。
その昔は個別のシステムは個別の部署によって管轄されて独立して存在していました。それぞれの責任は明確であったものの境目は曖昧で、個別に問題解決をしていたといえます。
これが封建制の時代。各領主には主権があり、個別の法制度が許され、比較的独立していたのです。
しかし、1990年代ごろから各システム間の連携が多くなると全体整合性の観点からシステム資産の活用度を高めるニーズが出てきます。そこで提唱されたのがSOAでした。SOAでは各システムのインターフェースに統一のルールが求められました。EAIによるデータ交換のハブ化、MDM（マスタデータマネジメント）によるデータモデルの統制、BPMによるプロセスの自動化など、企業全体を俯瞰した考えです。
これが君主制の時代。一人の王によって法制度が定められ、各地方では領主たちが統治を預けられていた時代です。ただし、君主制には偉大な王が必要であり、多くの君主制は統制の限界を迎えて打倒されていきます。
そして、2000年代を超えてくるとウェブサービスと呼ばれる巨大なシステムが作り上げられるようになりました。ウェブサービスは全体が継続的に稼働することが求められ、それを構成する各システムは切れ目なく連携続けなくてはなりません。各システムはサービス全体に組み込まれるように作られるため、インターフェースは明確なものの、それら自身の構成はライフサイクルやメンバーにしたほうが効率的でした。
これが民主制の時代。国全体としては明確な境界線を持っており中央政府も存在しますが、地方の統治は個別の自治体に任されています。地方自治体には権利はあるものの国としてのまとまりが求められるわけです。
もちろん、細かいアラはあるのですが巨大な企業システムを国に例えると、時代と共に成熟していくのは当然のように思います。
ITサービス運営におけるアーキテクチャの役割
2014年11月15日に開催されたJJUG CCC 2014 Fallにて「Javaエンジニアのためのアーキテクト講座」と題して発表を行いました。資料は以下です。
「良いアプリケーションを作る」時代から「良いITサービス運営を実現する」時代になったことで、アーキテクトの役割はどうなったか、という内容を話しました。
今回は自分なりにITサービス運営というものをモデルを書いてみました。v0.1となっていますが、まだまだ見直せることはあると思っています。
元ネタはソフトウェア品質モデルです。ソフトウェア品質モデルでも「外部」「内部」といった静的な要素に加えて、「利用時」「プロセス」といった動的な要素も含めて、お互いに依存したり影響を与えたりするということが定義されていました。ITサービス運営ということを考えて、もう一歩、複雑な構成となっています。大きく分けて「ITサービスを構成する要素」と「ITサービス運営に関わる利害関係者」となります。
ITサービスを構成する要素
| 要素名 | 特徴 | 例 |
| 利用者の体験価値 | 利用者が体験して感じるもの 利用者によって評価が異なる |
AさんとBさんで評価が異なる |
| サービスの振る舞い | 外部から見てわかる振る舞い 誰がテストしても同じ結果 仕様（機能と非機能） |
仕様とテストケース 品質特性 API |
| 動的な構成 | システム実行時の要素と相互作用 流れ、実行、プロセス |
インスタンス 処理 実行環境/インフラ |
| 静的な構造 | 成果物が配置された静的な構造 後に残り、参照可能 |
ソースコード クラス、テーブル定義 ドキュメント |
ITサービス運営の利害関係者
| 要素名 | 特徴 | 関心事 |
| 企画プロセス | ITサービスの振る舞いを管理する 振る舞いの追加や変更を要求する |
売上 要求 |
| 開発プロセス | 静的な構造を作る 構造を追加し、変更する 素早さが求められる |
リリース計画 開発ツール |
| 運用プロセス | 動的な構成を管理する 動的構成の追加や変更を受け入れる 安定が求められる |
デプロイ 監視 |
| 業務プロセス | ITサービスを利用し、利用者にサービスを提供する 利用者からフィードバックを得る 安定が求められる |
現場 効率化 |
このITサービス運営モデルで考えるべきことは以下の4つです。
- 個別の関心事を持つ利害関係者がいる
- 価値は利用者の体験によって定義される
- 複雑な構成要素によって成り立つ
- フィードバックによって持続的に成長する
これらの観点を考慮しつつ、各要素のバランスをとることがアーキテクチャの役割であり、それをデザインすることがアーキテクトの仕事ということになります。アーキテクチャ設計を進める上でも、そういった各要素を意識することが大事です。
もっと書きたいのですが、時間がないので詳細については資料を確認してください...。
オンラインでのフィードバックを見ていると「内容が難しくて分かりにくかった」というのがいくつかありました。モデルまでは理解していただいていていたようですが、後半のアーキテクトに求められる作業やスキルあたりが飛ばしすぎました。ここは反省をしております。次回、こういった機会には、もっと分かりやすく伝えられるようにします。
最後に書きましたが「アーキテクト的な発想」は職業がアーキテクトでなくてもできます。むしろ、すべてのエンジニアがITサービス運営全体を意識するというのは非常に大事なことだと思っています。
