(1/3)2000年前後からのアプリケーションアーキテクチャやEJB、SOAに触れながら、今後、大規模システム構築で主流になるであろう「マイクロサービス」アーキテクチャの意義と価値を考える。});近年、「マイクロサービスアーキテクチャ」という言葉が徐々に広がりつつある。「何年か前からあるSOAの概念の焼き直しでは」という意見もあるが、「SOA」の概念自体、さまざまな解釈があるなど、その正しい理解はなかなか難しいのではないだろうか。本稿では、2000年前後からのアプリケーションアーキテクチャにおける代表的なフレームワークについて簡単に触れながら、今後主流になってくると思われるマイクロサービスアーキテクチャの理解を試みる。マイクロサービスアーキテクチャの実例と9つの特徴マイクロサービスアーキテクチャを含む統合アーキテクチャを理解するに当たり、まずはマイクロサービスアーキテクチャの採用事例を参照されたい。日本国内で有名な事例として、下記の企業のケースが挙げられる。クックパッドLINEビズリーチGunosySkyWayアーキテクチャの変遷は、主にそれを支える要素技術の文脈で語られることが多いが、その変遷を技術だけで語ることは難しい。Fowler氏との共著の記事「Microservices」において詳細な説明を行っている。ここで語られているマイクロサービスアーキテクチャの9つの特徴を挙げる。主な機能はライブラリとして配布するのではなく、サービスとしてAPIで公開するビジネス上の組織力に基づいたIT組織作り従来のレイヤー単位での組織化ではなく、ビジネスにおいて組織されたチームに準じてITチームを組織するプロジェクトではなくプロダクト成果物は常にマイクロサービスであり、プロジェクトに閉じた議論は意味を成さない。マイクロサービスは継続的なプロジェクトである洗練されたインターフェースと太いメッセージングバスAPIはシンプルかつ過不足のなく構成し、軽量プロトコルで通信する。他のサービスの障害を受けにくい設計を施す進化的設計マイクロサービスを適切に汎用化できるような設計を目指すこれらの詳細な解説はここでは避けるが、組織への言及がなされていることからも「技術以外の要素」が大きな割合を占めることが分かるのではないだろうか。その観点を含め、ここでは筆者の考え方も交えながら、より俯瞰的な視座からマイクロサービスアーキテクチャを理解することを目標としたい。マイクロサービスアーキテクチャのイメージなお、文中で特定の技術について触れた場合については、誤解のない範囲で一般的な解釈において用いるものとする。何らかのサービスを提供する情報システム(例えばECシステムやポータルサイトなど)の構築を実施する場合、単一のDBスキーマに全データを保存するようデータ構造を設計したり、全機能を一つのアプリケーションサーバーに構築したりする。いわゆる「モノリシックな構造」にするのが一般的である。スタートアップのサービスであればなおのこと、将来を見越した汎用的な“ものづくり”よりは、スピードを優先して、「提供するサービスに特化した情報システム」を構築する。したシステムは、利用頻度の低い時期は特に問題が生じないことが多いが、サービスがスケールした際に、課題が顕在化する例が少なくない。起こりがちな課題から列挙しよう。一般的な情報システムのアーキテクチャDBへの負荷集中システムの構造にも依存するため一概には言えないが、おおむね初めに直面するのがこの事象である。全てのデータが一つのDBに保存されているために、複数のテーブルを複雑に結合したデータ取得が多くなること、論理設計がそのまま実装されるケースが多いため、SQLにビジネスロジックが入り込み、パフォーマンスへの考慮が行き届かないこと、などが主な要因として挙げられる。昨今のITサービスにおいては、単一機能で収益が上がるほど単純ではなく、複数の機能を適切に組み合わせて顧客満足度の向上を図る場合がほとんどである。全機能にオリジナリティがあり、他社を凌ぐ価値を提供できるに越したことはないが、一般的には一部の機能に価値が集中し、周辺機能は付加的に一般的なレベルで提供されることがほとんどである。その場合、周辺機能に投入する経営資源は限りなく少なくなっていくばかりでなく、それを担当するメンバーのモチベーションも下がり、最低限の価値の維持すら困難になることが多い。機能間の負荷バランス事業規模が拡大するにつれて、一部の機能の負荷が情報システム全体の負荷に占める割合が増大する、いわゆる「パレートの法則」のような事態に陥ることが多い。この課題は、初期はロジックの組み換えやハードウエアの交換などにより、“もぐらたたき”的に一つ一つ力技で解決していくことが多いが、徐々に「情報システム全体の構造」が問題として顕在化し、その改善に投資すべきことが次第に明らかになってくる。複雑化した情報システムにおいて、対象となる機能を単体で改善することは非常に困難になっていることが多い。「さまざまな機能から単一のDBスキーマを参照、更新する構造」においては、トランザクションの増大に伴い、同じデータに対する更新処理が同時多発的に発生するケースが増える。データの安全性を保つための排他制御が、サービスを停止させるデッドロックを招くであろうことは容易に想像がつくはずだ。情報システムの規模が拡大すれば、その可能性は指数関数的に増大する。開発プロセスを適切に管理すれば起こり得ない事態とはいえ、成長速度が求められる最近においては、そのような管理が完璧にできる事業体はほぼないのではないだろうか。影響範囲の増大(アプリケーション複雑度の増大)前述のデッドロックと様相は類似するが、長いビジネスプロセスの冒頭部分を担うアプリケーションの改修が、後続の処理に悪影響を与えるケースが増加してくる。これはビジネスプロセス自体の複雑さにも起因するが、情報システムの規模が人間の理解の限界を超過することによって起こる。これを防ぐために、設計工程とテスト工程を手厚くすることが考えられるが、完璧に防止する策は徐々に限られてくる。単機能の改修であっても、さまざまな機能が複雑に絡み合う巨大なシステムにおいては、全ての可能性を網羅的に検討し、徹底的に調べ上げるプロセスが設けられる。調査・設計といったプロセスから、サブシステム単位、ベンダー単位、レイヤー単位で組まれるチーム体制など、複数のチームを多層的に管理する体制を構築する必要が出てくる。情報システムの複雑度と体制の複雑度は比例するものと考えてよい。Shafer氏に、DevOps、継続的インテグレーション(CI)、マイクロサービスについて聞いた。Lambda」を発表した。誤解されそうな部分を含めて、これらのサービスの内容と狙いを探った。JAX-RSを活用して、JavaクラスをWebサービス化しようJAX-RSを使用すると、通常のJavaクラスをいとも簡単にWebサービス化できる。本稿では、ごく簡単なJavaプログラムを例に、その方法とJAX-RSの動作について解説する。4.0」の正式版をリリースした。JavaScriptを中心としたWebアプリ開発の栄枯盛衰まとめ——LiveScriptからAngularJS/React.jsまで@ITが誕生した2000年頃はJavaScriptが不遇だった時代。そこから現在のような人気のプログラミング言語になるまでには、どのような歴史があったのか。15周年を迎えた@ITの豊富なWeb開発関連記事とともに振り返る。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。