このページの本文へ

前へ 1 2 3 次へ

開発者を魅了するマイクロソフトの開発プラットフォームを探れ 第10回

Java on Azure Day 2022でヴイエムウェア、日本IBM、レッドハットが登壇

Java on Azureを支えるテクノロジー Spring、Open Liberty、KEDAの基礎を学ぶ

2022年05月16日 09時00分更新

文● 大谷イビサ 編集●ASCII

提供: 日本マイクロソフト

  • この記事をはてなブックマークに追加
  • 本文印刷

イベント駆動アーキテクチャのメリット、ユースケース

 3番手となるレッドハット 井上貴博氏は、もともとは、J2EEサーバの開発者で商用J2EEサーバのServlet/JSPエンジンの実装に携わっていたという。現在は、スペシャリストソリューションアーキテクトとして、JBoss Enterprise Application ServerやRed Hat Single Sign-on、Quarkausなどミドルウェア製品のソリューションアーキテクトを担当している。

 まず今回のテーマである「イベント駆動」の考え方から。イベントはソフトウェアから認識されるアクションや事象を指しており、通常は外部環境から非同期に発生し、それを受け取ったソフトウェアによって処理される。実世界でも何らかのきっかけをもって、反応やアクションがあるのは一般的だ。

 ここでは「サービス間の処理において発生したある特定エンティティのイミュータブルな状態と値」であるイベント(ex.株の約定)、「受信者がなにをすべきかの指示を含み、状態の変更が発生する場合がある」というコマンド(ex.株を指し値で注文)、そして「コマンドと似ているが、結果を返す応答があることを想定している。ただし状態の変更はともなわない」というクエリ(ex.検索)の3つをイベントとして定義する。DBの操作で言うと、コマンドがUpdateやInsertでDBを変更するが、クエリがSelectでDBの変更はともなわない。実にわかりやすい説明だ。

 さて、イベント駆動型アーキテクチャだが、アプリケーションやサービスがイベント通知の送受信に対してほぼリアルタイムに応答するようなアーキテクチャを指す。昨今だとApache Kafkaなどのキューを間に挟み、実現されることが多い。

 なぜイベント駆動型アーキテクチャなのか? 井上氏は、「現実世界がイベント駆動なので、イメージしやすい」という点を挙げる。イベントベースで設計すると、RDBベースのERモデルより設計しやすいという利点があり、業務フローもわかりやすいため、現場の担当者が設計しやすい。その他、システム連携の疎結合化がやりやすい、キュー自体を細かい粒度でスケーリングできる、ほぼリアルタイムといった理由がある。

 一般的なリクエスト/リプライ型は、同期型なので、作りやすい、わかりやすいといったメリットがある。しかし、リクエストの送信元が落ちている場合は動作することはなく、処理が多段になっている場合は、エラーが伝播してしまうため、障害耐性は低い。一方、イベント駆動型は非同期で、リクエストをキューなどで吸収できるため、送信先がキューからリクエストを取り出せば処理が継続できる。また、Pub/Subなどの形式で、イベントを複数のサービスに分岐することも可能なので、1対1に比べて組み合わせのも豊富だ。現在は、ベストプラクティスがまだまだ発展途上という状態だが、今後はマイクロサービスの普及とともにどんどん浸透していくのでないかという。

イベント駆動とリクエスト/リプライ型

 井上氏は、「アプリケーションとサービス間の疎結合な連携にすることで、アジリティも上がるという効果もある。これに関してはマイクロサービスもほぼ同じ。鶏と卵になるかもしれませんが、イベント駆動を用いることで、マイクロサービス的な実装になるかもしませんし、マイクロサービス化することでキューを介したイベント駆動になるかもしれません」とイベント駆動の重要性をアピールする。

 RDBに比べてイベント駆動型が向いているというアーキテクチャのユースケースとしては、コマンドはRDBで、検索はインメモリキャッシュと役割を分離する「CQRS(コマンドクエリ責務)」が挙げられる。また、行動追跡はあらかじめイベントを集めておいて、将来のビジネス行動を予測。監査についても状態を変更したすべてのイベントを格納しておくことで、監査担当が任意の時点でシステム変更を追跡するための有益な情報を提供できる。

イベント駆動型のユースケース

イベント駆動を実現するQuarkusとKEDAとは?

 次にイベント駆動をJavaで実現するための方法についての説明に移る。いつ起こるかわからないイベント駆動と言えば、やはりサーバーレスがコストや運用の面でオススメだ。そして、このサーバーレスのイベント駆動を実現するため、今回はイベントを待ち受けて処理を実行するサーバーレス向けのランタイム「Quarkus」とイベント駆動のオートスケーラーの「KEDA」が紹介された。

 「Supersonic,Subatomic Java(超音速・原子より小さいJava)を標榜するQuarkusは高速・軽量なJavaフレームワークで、コンテナやサーバーレスに向いている。レッドハットが中心に開発を手がけており、認可認証機能のKeycloakも最新バージョンではQuarkusをベースで実装されている。また、Quarkusはライブコーディングにも対応しており、アプリケーション実行中に、Visual Studio Codeなどの開発ツールでソースコードを修正すると、勝手にリロードが走ってソースコードの修正内容を反映してくれる。

 Quarkusはコンパイル時に必要なクラスファイルのみ取り込んで動作するため、省メモリで、起動も高速。実際、REST応答のみのアプリケーションのメモリ消費量を調べると、通常のJavaが136MBなのに対して、Quarkusは73MB。起動時間に関しても、従来4.3秒だったのが、0.9秒にまで高速化している。REST応答+CRUD(データベースアクセス)も同じく高速で、JavaVMを付与しないネイティブコンパイルの場合は、さらに省メモリ・高速になるという。井上氏は「この起動の速さがサーバーレスに向いており、軽量化・コンテナの集積度を挙げるのに役に立つ」とアピールし、Azure上でQuarkusを動作させるためのドキュメントを紹介した。

Quarkusのパフォーマンス

 一方、Kubernetes Event-Driven Autoscalingを意味するKEDAは、Kubernetes上のイベント駆動を実現するオートスケーラーでマイクロソフトとレッドハットが中心になって開発している。特徴的なのはPodsのCPUやメモリ以外に、イベント元のリソースキューの長さにあわせて業務アプリ寄りにスケジューリングできる点や、非HTTPの利用も可能。もちろんAzure Functionsにも対応し、現時点ではCNCFのインキュベーションプロジェクトにもなっている。

 KEDAでは、「スケーラー」がイベントソースからキューの長さ、DBの秒数などのメトリクスを取得し、これに応じて「メトリックアダプター」がスケーリングを実施する。このスケーラーは2022年4月時点でAzureのサービスのほか、kafka、MQ、Prometheus、各種DBなど約50個から選択できるという。

KEDAのスケーラー

イベント駆動の基盤としての「Azure Red Hat OpenShift」

 最後はイベント駆動を動かす基盤の紹介。KEDAはいろいろなKubernetesディストリビューションで動かすことができ、もちろんOpenShiftでも動作する。また、OpenShiftのサブスクリプションではQuarkusがサポート付きで利用できる。

 Azure上で利用する場合は、フルマネージドの「Azure Red Hat OpenShift」がオススメとなる。マイクロソフトとレッドハットの両社で統合されたサポート体制や設計・運用の支援を提供。「なによりAzureとの親和性が高い。たとえばAzureADとは管理者やアプリ開発者の認証でインテグレーションされているので、使い慣れたシングルサインオンでOpenShiftにログインできる」と井上氏は語る。

 まとめとして井上氏は、「Azure上では便利なサービスが数多く用意されており、Javaの技術やノウハウを活用できる点も魅力的。今後のDXやビジネススピードのアップで、ぜひイベント駆動の考え方を取り入れて欲しい」とコメントした。

■関連サイト

 マイクロソフトのエコシステムを構成するヴイエムウェア、IBM、レッドハットの各社がどのような姿勢とテクノロジーでJavaの開発を支援するのか、基礎から最新動向までしっかり理解できたセッションだった。

(提供:日本マイクロソフト)

前へ 1 2 3 次へ

カテゴリートップへ

この連載の記事
  • 角川アスキー総合研究所
  • アスキーカード