IBM MQ“らしさ”に迫ってみた〜MQが作られた背景からMQ開発者の想いまで〜

記事をシェアする:

今年、IBM MQ と Db2 は 30 周年。WebSphere は 25 周年を迎えます。長年にわたりお客様のIT基盤を支え続けている IBM ミドルウェア製品のアニバーサリーを記念して、ミドルウェア製品に携わるキーマンへのインタビューを実施しています。第 4 回目第二弾は、IBM MQの 開発元である英国ハーズレイ研究所から来日した2人のエキスパートにインタビューを行いました。

David Ware（デイビッド・ウェア）
IBM Distinguished Engineer、兼IBM のエンタープライズ向けのメッセージキューイングソリューションである IBM MQ のCTO。

Matt Leming （マット・レミング）
IBM MQ on z/OS のアーキテクトであり、シニア・テクニカル・スタッフ・メンバーの一員。ラフバラー大学で数学の学士号、オックスフォード大学でソフトウェア工学の修士号を取得し、2002年から英国IBM Hursleyを拠点に勤務。IBMではIBM MQ、WebSphere Application Serverを中心として活動。

インタビュアー
・IBM Data, AI and Automation テクニカルセールス 恩田洋仁
・IBM Data, AI and Automation テクニカルセールス 古川桃子

 

 

1.自己紹介をお願いします。

― （ウェア氏）私の名前はデイビッド・ウェアです。現在はIBMの技術理事、IBM MQのCTO兼チーフアーキテクトを務めています。イギリスのハーズレイ研究所に所属しています。IBM MQの開発と戦略に関してハーズレイよび世界中のチームを統括し、MQのすべてのプラットフォームと機能に関する責任を持っています。特に、数年にわたってMQのクラウドへの展開、拡張性、ユーザビリティの向上に取り組んできました。

私はIBMに28年間在籍しており、ほぼIBM MQと同じくらいの期間です。入社した頃は現在のような洗練された自動化システムではない中でMQ開発やテストを行っていました。実は私の初めての海外出張先は日本でした。日本のお客様向けにパブリッシュ/サブスクライブ・システムを開発し、イベント駆動アーキテクチャーの先駆けとなりました。その後、数年間はWebSphere Application Serverの開発をしたあと2010年に再びMQ開発に戻り、クラスタリング、パブリッシュ/サブスクライブ、高可用性の専門家となりました。2017年以降、MQの全体的なアーキテクチャー戦略を担当するようになり、最近ではIBMの技術理事として活動しています。

 

―（レミング氏）私はマット・レミングです。MQ on z/OSのシニア・テクニカル・スタッフ・メンバーで、アーキテクトです。2002年に大学院生としてIBMに入社しました。

私は約17年間MQに取り組んでおり、最初はWebSphere Application ServerにJMSサーバーとして組み込まれていたMQを担当していました。 ここ10年間は、z/OSエコシステムおよび広範なMQ製品との進化に焦点を当ててきました。不具合の修正など製品のコーディングを行うこともありますが、最近はお客様と話す時間も多いです。また、Syste zのエコシステムを一緒に形成するz/OSチームと共創する機会がたくさんあります。System zのエコシステムは非常に大きな要素で、ハードウェア面も含めた新たなテクノロジーについて理解し、それらをMQに組み込む方法を考えるため、彼らと話す時間を大切にしています。

 

 

2.MQはメッセージング市場で最も成功したソフトウェアですよね。全世界で30年に亘りBest of a Kindの地位をずっと維持してきています。ここまで世の中にMQが広まった理由は何でしょうか？何かきっかけとなるような出来事や、MQが持つ特別な価値などがあれば教えてください。

― （ウェア氏）MQは「異なるアプリケーション同士がシンプル、かつ信頼性の高い方法で通信できるようにする」という「簡単」ながらも重要なことを実現しました。

現在では当たり前と思われることですが、30年前はメインフレームとUNIXやWindowsの間のアプリケーション同士が会話することは本当に難しい課題でした。MQのメッセージングは疎結合でありながらも信頼性のあるコミュニケーションの手段を様々なプラットフォームに跨って提供し、課題解決に導いてくれました。これがMQが最初に広く市場に受け入れられたきっかけだと考えています。

また、MQは非常に汎用性の高いソリューションです。小規模なアプリケーションから大規模なソリューションにまで適用できますし、特定の業種に限らずあらゆる業界に適用することができます。さらにMQは常に市場で最高のメッセージング製品であり続けるために継続的に進化を続けてきました。これらがMQが多くのお客様にご利用いただけている理由だと思います。

 

（インタビュー中のウェア氏）

 

 

3.ハーズレイ研究所からはIBM MQのほかCICS, WebSphere , IBM Java, App Connect Enterpriseなど長期に亘って成功を収めた製品が数多くあります。MQを産んだHursley研究所は何が特別なのでしょうか？

―（レミング氏）ハーズレイは働くのに最適な場所です。おっしゃる通り、IBMの主要な製品のいくつかがここで生まれています。これには複数の要素があります。

1つは、優秀な人材をが採用されていることです。IBMは、優秀な大学から優秀な学生を採用しています。学業中にIBMで1年間を過ごすインターンのプログラムで学生の適性を見極めたり、IBMでの経験を大学に持ち帰ってもらってスキルを磨いて、またIBMに戻ってきてもらったりということも行っています。新卒採用以外でも我々の仕事に関連する分野で優れた業績を残している人を見つけて採用も行っていますが、そちらもとても上手くいっていると思います。

もう1つの理由は、お客様との接点を重視していることです。ハーズレイにはカスタマー・ブリーフィング・センターがあり、多くのお客様と密に協働しながら業界のニーズや課題などを把握するようにしています。そこでは誰も解決したことのない問題を拾い上げて製品化します。その時代に必要とされているものを正しく見極めて集中的に投資し、製品開発を行うということが特別なのだと思います。その意味でもお客様との関係性は非常に重要で、ハーズレイがユニークな点としてはお客様をお招きするのに素晴らしい環境があるということも挙げられます。

 

（インタビュー中のレミング氏）

 

 

4.日本ではMQが銀行や航空会社、半導体工場など社会の重要なインフラを支える基盤として広く使われています。社会インフラを支えるミッション・クリティカルな製品を開発する上で気を付けていること、大切にしていることがあれば教えてください。

―（レミング氏）IBM MQは、金融、保険、商業など、世界中のミッション・クリティカルな業界で使用されています。

開発チームとしては、製品に変更を加えた際の影響というものを非常に強く意識しています。新しく配属されてきた開発者はMQのことを知らない人も多いです。まず彼らに説明するのは社会の中でMQがどのように使われているか、どのような顧客が利用しているのかを説明し、開発者として向き合う仕事の重大さを理解してもらいます。

MQに変更を加える際には、具体的には製品のリリースまでのプロセスには厳格な手続きがあります。すべてのコードに対する変更は、問題を適切に解決できるかだけでなく、既存コードに対して最もリスクが少ない方法であること、以前に行った作業と一貫性があり、既存のユーザーに予期しない影響を与えないことを確認するために、ピア・レビューが行われ、Davidと私を含むアーキテクチャー・チームによって承認されます。

そして、非常に我々が重要視しているのはテストです。すべての新機能には、製品開発サイクル中に定期的に実行される新しい自動化テストスイートが付属されています。これは、非常に重要で、新機能のためにかける時間の中で最も大きな部分になります。何かしらのコード修正の作業を行う場合、６割から７割の時間はテスト・コードの作成に使われます。テストの自動化のためには膨大な時間が費やされますが、30年間にわたって20種類のプラットフォーム向けに追加してきた機能をテストするためには自動化が絶対に必要なのです。

MQには数千の自動化テスト・スイートがあり、テスト・スイートには100個のテスト項目を持つものもあります。テスト項目は個々の機能に焦点を当てたシンプルなものからシステム全体の動作をテストするものまで様々です。MQは多くの他の製品と緊密に統合されているため、これらのシナリオに対する幅広いテストもあります

MQの耐障害性と高可用性は、MQの中心的な価値であり、特に重要です。例えば、キューマネージャーやz/OSのカップリング・ファシリティーなどにあえて障害を発生させてMQがこれらの障害から最小限の時間で、もしくはダウンタイムなしで回復できることを検証する拷問のようなテストなどもあります。

テストは、すべてのMQのサポート・プラットフォーム上で常時実行されています。さらに、お客様の要求する高スループットを達成できるかどうかを確認するために、専用のハードウェアでさまざまなパフォーマンステストを行っています。製品の新バージョンをリリースする際には、あるタイミングでコードベースを凍結し、サポートされているすべてのプラットフォームでテストを実行する「コードチル」フェーズに入ります。全部のテストが合格するまで、製品の出荷準備を行うことはできません。

 

 

5.ここ数年での大きなMQのイノベーションの例を紹介してもらえますか？

― （ウェア氏）思い浮かぶのは2つあります。どちらも MQ が最新のクラウド・ネイティブなソリューション、最新の環境向けに進化していることを示すものです。1つ目は、ユニフォーム・クラスターの機能です。ユニフォーム・クラスターは、アプリケーションから、MQ キューマネージャーのグループへの接続を自動で動的にリバランスする機能です。負荷に応じてリソースを動的に増減させることができるためにシステムの拡張性が担保されます。また、一部の MQ がダウンしてもアプリケーションからの接続は残った MQ に再接続されるのでサービスの継続性が保たれます。

もう1つはNative HAの機能です。Native HAは障害が発生したMQ上のメッセージを復旧するためのフェールオーバーの機能を最もモダンなやり方で実現しています。分散合意アルゴリズムであるRAFTに基づく一貫したデータ・レプリケーションによって100％のデータ整合性を保ち、ゼロのRPO（ Recovery Point Objective : 目標復旧時点）を実現し、数秒でのフェールオーバーを実現しています。任意のKubernetesクラスタ、クラウド、オンプレミスに展開できます。

これらの機能はMQの継続的な革新の例ですが、同時にMQの普遍性を示す例でもあります。実はこれらの機能を追加するためにMQ製品のコアには大きく変更していないのです。MQの製品コアは継続的な革新の土台となる堅牢な基盤を持っています。

 

―（レミング氏）最近の4年ほどの間に、z/OS版のMQで注目されているトピックはAIです。ほとんどのお客様のビジネスにとって、MQは非常に重要な役割を果たしているため、問題が発生した後に対応するのは望ましくありません。その代わり、お客様はシステムが平常の運用状態から逸脱し始めたときにすぐに通知を受け、問題発生前に調査・予防できるのが理想的です。そのような予兆検知をMQで行おうとした場合のアプローチとしては、MQが出力するSMF (System Management Facility) データを取得し、それを解析するモデルを構築。そしてモデルが構築されたら、SMFのデータほぼリアルタイムで取得できるので、平常運用時のモデルと継続的に比較して逸脱をチェックします。逸脱が大きくなったら、アラートを生成するという方法になります。

以前はこれをお客様自身で行う必要がありましたが数年前、私たちはIBM Z Anomaly Analyticsチームと協力しての予兆検知のモデルにIBM Zの機能を利用できるソリューションを開発しました。数ヶ月分のMQの運用で蓄積したSMFデータを取り込むだけで予兆検知のためのモデルを自動で作成してくれます。このモデルを日々のMQの運用で出力されるSMFデータとリアルタイムに比較して異常発生時や何か変化が起きた時にアラートを受け取ることができます。

同時に、私たちはSMFデータの改善にも取り組んできました。重要な改善の1つは、データの取得頻度に関するものです。高頻度のデータは高い信頼性のあるモデルと変化への迅速な対応に欠かせません。今では、MQは必要に応じて毎秒の頻度でデータを取得することができるようになっています。また、データの収集によるパフォーマンスに影響がほとんど出ないように性能面での改善も行っています。さらに最新のLTSリリースであるMQ v9.3では、キューごとにSMF統計情報の取得有無を制御できるようにすることで本当に必要な情報だけが収集されるようになっています。

これらの改善によってSMFのデータはAIと組み合わせて使用するための完璧なデータセットとなりました。

 

（インタビュアー、左から古川・恩田）

 

6.MQの将来の展望について教えてください。今後MQはどのような方向に進化していくのでしょうか？

―（ウェア氏）MQに対する基本的な要求は30年間変わっていません。メッセージを信頼性のあるスケーラブルな方法で伝達・配信ができることです。私たちはこのMQの基本的な価値を追及していくことを変えるつもりはありません。しかし、同時にモダンで新しいアプリケーション・スタイルや環境においてMQの価値を提供できるようにしていく必要があります。

最新の環境サポートを行い、最新のセキュリティにも対応し、クラウド・ネイティブなアプリケーションやクラウド・デプロイを含め、より大規模で信頼性の高いセキュリティを提供するよう進化させていきたいと考えています。またアプリケーション開発者の労力を最小限に抑え、MQの恩恵を最大化する方法で進化させていきたいです。

 

7.よく聞かれる質問としてIBM MQとApache Kafkaの違いというものがあります。今後MQはKafkaに取って代わられると思いますか？あるいは棲み分けていくようなものなのでしょうか？

―（ウェア氏）とても良い質問ですね。MQは過去30年にわたりメッセージング業界で大きな存在でした。一方Apache Kafkaはここ5年くらいの間で急速に普及していてこちらもメッセージングを提供します。多くの人はどちらがベストなソリューションなのかと聞いてきますが、MQもKafkaも「メッセージング」を提供していることは同じで、ただ、それぞれの核となるユースケースは異なります。

MQは耐久性と信頼性が重要な場面（個々のメッセージが非常に重要な場面）でのメッセージ交換を念頭に設計されています。例えば1つのメッセージが十億円の価値があるような最もミッション・クリティカルな用途で利用されています。

一方、Kafkaも重要なユースケースに利用されていますが、MQとは異なります。それは何らかの事象が起きたことを表す一連のイベントによって様々なアプリケーションに対して何が起きたのかを理解できるようにするというものです。周囲で発生したイベントをリアルタイムに活用してより良い顧客体験を生み出したり、予兆を検知してシステムの問題を未然に防いだりといったことに利用されます。

2つのシステムは核となるデザインに大きな違いがあり、それはアプリケーションのデザインに違いを生みます。MQは個々のメッセージの処理に適しており、Kafkaはイベントのシーケンスに適しています。どちらかのソリューションを他方のユースケースに使用することは、最良の結果が得られないことになります。両方ともより広範なシナリオに使用でき、そのために常に進化していますが、核となる設計原則と適合しない選択をしてしまうと妥協が生じてしまうことは避けられません。従って、完璧な最適解を求めるのであれば、アプリケーションのユースケースと解決すべき問題について考え、最も適したテクノロジーを選択する必要があります。つまり、多くのシナリオでは、一方を他方の代替手段とするのではなく、両方を併用することが最良の選択肢になります。

 

 

8.MQについて好きなところを教えてください。

―（レミング氏）MQの本質的な部分はかなりシンプルで、家族や友人に説明するのもとても簡単です。メッセージの送受信というSNSのメッセンジャーやメールに似たことを信頼性高く行っているに過ぎないという言い方もできます。

一見シンプルに見えて、周辺には多様な興味深い課題が溢れており、常に「次に何をしようか」と考えることができて飽きることがありません。世界中の人と興味深い対話も行われ、退屈と感じることはなく、むしろ仕事を楽しんでいます！

 

―（ウェア氏）私たちが日々働くことで、MQを通じて社会を支えているというのは素晴らしいことです。MQは非常に大規模かつ素晴らしい耐久性を備えており、旅行をしている時も、買い物をしている時も、医者に行く時でさえ、どこかにMQが存在しています。

 

 

9.最後に日本のお客様、ビジネスパートナー様、IBM社員に向けて、メッセージをお願いします。

―（レミング氏）MQをご利用いただき、これまでのすべての長い年月の間にわたってIBMと一緒にいていただき、本当に感謝しています。MQを使用しているお客様とは、過去30年間、共に旅をし、皆様が解決しようとしている問題を一緒に解決してきました。そして、もしIMSやz/OSなど他のプラットフォームに関する質問があれば、私たちはお客様のためにここにいます。私たちはお客様のニーズを理解するために、お話しし一緒に取り組む準備ができています。

―（ウェア氏）レミング氏と同じく、皆様ありがとうございます。今週、お会いできたすべてのお客様に感謝します。この日本に滞在中、日本のお客様と交流できたことはとても素晴らしい経験でした。今回はアニバーサリー・イベントでの来日だったため、どうしても過去に目が向きがちですが、私が皆様にお伝えしたいことは、過去のやり方に基づいてどのようにテクノロジーを使用するかを決めないでほしいということです。現在のテクノロジーが問題をどのように解決しているかを見てみてください。思ってもみなかったことができるようになっていることにきっと驚かれるはずです。

最後に、皆様に全員に感謝いたします。ありがとうございます。

 

（最後の記念撮影写真：左からインタビュアー・恩田、ウェア氏、レミング氏、インタビュアー・古川）

記事執筆：アニバーサリー広報チーム（Data, AI and Automation 事業部）
撮影者：鈴木智也