これからのITサービス開発を考える上で鍵となるアーキテクチャの1つとして、寺田氏は「マイクロサービス」を挙げる。
これまでのエンタープライズJavaアプリケーションは、Java VM上でアプリケーションサーバを稼働させ、その上でアプリケーションを配備していた。そして、配備するアプリケーション(earファイル、warファイル)には、複数のサービスが実装されていた。こうした実装方法では、ある特定のサービスのパフォーマンスが低下したり、リソースの消費量が増大したりすると、全サービスが同じJava VM上で動いているため、他のサービスも影響を受けざるを得なかった。
また、アプリケーションを開発する際、最初に特定のJavaフレームワークを選択すると、機能を追加する際にも同じフレームワークを選択しなければならなかった。さらに開発規模が大きくなってくると、新しい開発者が投入されるが、新しく入ってきた人がアプリケーションの全体像を理解するのも非常に困難になる。
その点、マイクロサービスは個々のサービスを独立して稼働させるため、実装フレームワークの種類に関わらず、サービスを動かせる。また、開発するサービスの規模が小さいため、全体像を理解しやすくなる。さらに、あるサービスに加えた変更は、他のサービスに対して影響しないため、変更に強く、“継続的に成長していくシステム”を開発する上で適したアーキテクチャだといえる。
また、ある特定サービスのパフォーマンス劣化が、他のサービスのパフォーマンスに影響しないように実装することも可能だ。さらに、サービスの実装に用いるプログラミング言語も、個々のサービスごとに自由に選べる。その時々の最新技術を使ってサービス開発を柔軟に行える点は、従来にはない大きな利点だといえよう。
「マイクロサービスを実現することで、フレームワークやプログラミング言語にロックインされない環境を構築できます。今後出て来る予定の新しいフレームワークを試しやすくなるという利点もあります」
ただし、実際にマイクロサービスのアーキテクチャに則ってシステムを開発するには、「これまでのシステム開発/プログラミングの常識を根底から覆すようなパラダイムシフトが、企業と開発者の双方にとって必要です」と寺田氏は指摘する。
「マイクロサービスのメリットを十分に引き出すためには、それに適した設計を行うことが重要です。そのために、いくつかのデザインパターンが既に作られています。例えば『Circuit Breaker』というデザインパターンを使えば、あるサービスの障害、もしくはパフォーマンス低下が他のサービスに悪影響を及ぼさないように実装できます」
「逆に言えば、マイクロサービスは分散コンピューティングを意識し、ネットワーク越しに存在するサービスの『パフォーマンス低下』『サービスダウン』を念頭に、たとえサービスが落ちてもシステム全体としては動き続ける設計を行います。こうした設計を行うためには、従来の『何があっても落ちないシステム』の設計・開発思想を大きく転換する必要があります」
また寺田氏によると、マイクロサービスは、従来型のモノリシック(一枚岩)なアーキテクチャではなく、独立したサービス同士が協調動作することで全体としてのシステムを構成するため、全体のパフォーマンスを最適化するには、サービスの呼び出し方法やインタフェース設計が重要な鍵を握るという。
今までの、モノリシックなソフトウェアと同じ同期処理の考え方でマイクロサービスのシステムを設計すると、全てのサービスの処理待ち時間の合計がシステム全体の処理時間となり、レイテンシの低いサービスになる。これを避けるためには、「リアクティブ」が重要なポイントとなる。
「リアクティブ宣言」にあるが、即応性(Responsive)を高めるために、メッセージング駆動(Message Driven)を活用し、弾力性(Elastic)や耐障害性(Resilient)を考慮し、さらにサービス同士の連携に非同期処理やノンブロッキングI/Oを利用することで、レイテンシの高いサービスを提供できるようになる。
このように新しい考え方でプログラミングをしていく必要があると強調する寺田氏は、2016年9月に開催された「JavaOne 2016」におけるJava EE 8/9に関する発表との関連性を指摘する。
言うまでもなくJava EE(Enterprise Edition)は、Javaを使ったエンタープライズWebシステム開発における標準仕様として、大きな影響力を持ち続けている。一方で、Java EE 8以降の仕様がなかなか固まらない状況に対して、不安を持つ企業やエンジニアも多かったが、JavaOne 2016では、Java EE 8の2017年末までの開発完了と、その先のJava EE 9の開発も2018年の公開を目指すことが発表された。Java EEの今後について寺田氏は次のように付け加える。
「JavaOne 2016では、今後のエンタープライズWebシステムを開発するためには、クラウド、マイクロサービスのための新しいプログラミング手法が必要とされ、Java EEはそのために必要な機能を取り入れていくことが発表されました。この戦略が実現すれば、Java EEは良い方向に向かうでしょう。戦略のメインはJava EE 9で、その準備段階としてJava EE 8が開発される予定です」
Java EE 8/9が取り入れる予定の機能とは、例えば、マイクロサービスのデザインパターンのうち、下記に挙げるようなパターンだ。
特に、マイクロサービスにおいて重要な仕様がJAX-RS 2.1だ。JAX-RS(Java API for RESTful Web Services)は、RESTの原則に沿ったWebサービスをJavaで構築するための仕様だが、2.1では、クライアントAPIでリアクティブプログラミングを採用するという。
一方でJava EE 8での開発を停止する可能性がある仕様がMVC 1.0だ。Java EE 8で開発予定だった、その名の通りJava標準のMVCフレームワークだが、マイクロサービスの時代ではRESTful Webサービスが主流になるため不要になるのではという意見が出ている。MVC 1.0を開発するかどうかは、世界中のエンジニア自身が投票することで決定されることになっているが、その投票は2016年10月21日に終了したばかり。世界中のエンジニアが旧来のMVCという考え方を今後も必要とするかどうか――その投票結果は現在のプログラミングパラダイムの変化において大きく注目されている。
デジタルトランスフォーメーション時代に生き残れるエンジニアであるためには、今回寺田氏に聞いたさまざまなツールやテクノロジーについて、言うまでもなくいろいろと試してみることが必要になる。ただその際に、「自らが持つ“認知バイアス”を自覚し、それを取り除く努力も欠かせません」と寺田氏は強調する。
新しいチャレンジに乗り出す際には、それまでの思い込みや偏見が邪魔をして、なかなか一歩を踏み出せないことが多い。「エンジニアは、こうあるべき」「この開発には、この技術を用いるのが当たり前」「○○といえばこのベンダーの製品で決まり」「この人はどうせ、こういう人だから」。こうした認知バイアスが新たなテクノロジーや製品の価値を見極めるための目を曇らせ、せっかく目の前に開けている新たなチャンスをふいにしてしまうかもしれない。
こうした事態に陥るのを避けるためには、自らが持つ認知バイアスを意識化し、相対化した上で「自分が今持っているバイアスの正当性は、どの程度なのだろうか?」と常に自問する姿勢が欠かせない。
そして、高いマインドを持って継続的な努力を積み重ねていく原動力となるのは、究極的には個人の“夢”ではないかと寺田氏は言う。
「自分自身が将来どう成長して、どんな姿になっていたいのか。そして、自身の成長を通じてITでどんな社会貢献を成し遂げていきたいのか。そうした夢の実現を目指していれば、自ずと高いマインドを持てるようになります」
これまで寺田氏が話してきたように、ビジネスの中でITの重要性が高まる現在、エンジニアの役割は増す一方だ。求められるスキルや活用するべきテクノロジーや手法を学習、実践することを、大きな負担に思うかもしれない。一方で、大きなやりがいを感じることも多くなるはずだ。負担に思うか、やりがいを感じるかは、自身で決めること。寺田氏が言うように、まずは“認知バイアス”を捨て、“夢”を思い描くことから始めてみてはいかがだろうか。
物理の世界とテクノロジーを結び付け、新たな価値を創出する「デジタルトランスフォーメーション」が進む中で、ITサービス開発競争が国内外で激化している。これを受けて、今ビジネスの主役は、まさしくエンジニアとなりつつある。だが同時にこのことは、「スピード」を担保できない、「価値」を生み出せないエンジニアは活躍の場が縮小していくことも意味する。もはや従来型のスキル、スタンスだけでは対応できない時代が、すぐそこまで来ているのだ。ではIoT、FinTechにとどまらず、各業種でサービス開発競争が激化する中、「求められるエンジニア」であり続けるためにはいったい何が必要なのか? 本特集ではキーパーソンの声を通じて、「いま身につけるべきエンジニアのスキルセット」を明確化する。
Copyright © ITmedia, Inc. All Rights Reserved.