MarkLogic 11のご紹介

MarkLogic 11では、マルチモデルデータ用の新しい分析手法が導入されたほか、データエコシステムとの統合方法が増えました。また、MarkLogicの導入、管理、監査がさらに容易になりました（クラウドを含む）。

私たちは、より強固にまた管理しやすくなったプラットフォームを使って、複雑なものをシンプルにし、データおよびナレッジのサイロを解消することに継続して取り組んでいきます。

マルチモデルデータの新しい分析方法（Optic APIのアップデート）

マルチモデルデータベースであるMarkLogicは、実際には使う言語によってクエリが制約を受けます。例えば、SPARQLでは結果はグラフ形式となり、SQLではリレーショナル形式となります。

MarkLogic 9で初めてリリースされた Optic APIは、マルチモデルデータのクエリ用に特別に作られたものです。MarkLogic 11ではこれを拡張し、地理情報分析のニーズにも応えられるようにしました。具体的には、Optic APIで、地理情報データのインデックス付けおよびクエリ、大規模な地理情報結果セットのスケーラブルなエクスポート、およびGISツールとの相互運用（OpenGISおよびGeoSPARQL）をサポートするようになりました。

また、インジェスト/ストレージに関してすでに備わっていたマルチモデル機能を、リトリーブ/リクエストでも利用できるようになりました。これは、MarkLogicの全機能を1つのクエリアプローチで統一するという点で重要です。つまり、これは標準に基づいており、開発者が利用可能であり、将来のMarkLogicのコネクタ戦略の基礎となるものです。

GraphQLによるBIツールなどとの接続

MarkLogicは、データプラットフォームとして外の世界と繋がる必要があります。現在、BIなどの多くのツールにおいてGraphQLが普及してきており、GraphQLエンドポイントからデータをフェッチできるようになっています。

私たちは既存の製品ですぐに使えるように、データを公開したいと考えました。今やリレーショナルモデルに対して、GraphQLを使ってMarkLogicから必要なデータを取得できます（データに対する従来の分析やアナリティクスなどをすべて行うことができます）。

GraphQL機能は、Optic機能上に構築されています。GraphQLエンドポイントを使うと、Optic APIでモデリングやクエリしたデータをGraphQLで公開できます。リレーショナルビューやクエリベースのビューにおいて、アクセス対象データの射影を作成する複雑なOpticクエリを記述している場合、これをGraphQL APIとして公開できます。

これによって開発が楽になるだけではありません。これはMarkLogicプラットフォームと既存のツールの相互運用性を高めるという大きな流れの一部でもあります。MarkLogicでは、すでに強力なマルチモデルクエリ機能が活用されていますが、それをGraphQLのような業界標準のクエリメカニズムで公開できるようになります。

増大するデータの管理および監視

お客様が所有するデータが今後減っていくことはないでしょう。扱われるデータフローそしてアーカイブも常に増大し続け、MarkLogicが処理しなければならないデータの量も直線的な増加をはるかに超えて増大しています。例えば、先日あるお客様の現場で、ほぼ指数関数的な増加を示すグラフを見たこともあります。

では、より多くのデータをシステムに流し込むことに関して、私たちはお客様をどのようにお手伝いできるのでしょうか。

そのなかには「ハードウェアを増やしてノードを追加する」という簡単な方法もあるでしょう。しかしこの場合でも、観察、監査、管理を改善することで、お客様自身がヘルスチェックやモニタリングを行い、限界に達していることを把握できるようにする必要があります。つまりこれらを管理するための、使いやすいユーザーインターフェイスが必要となります。MarkLogic 11では、これを支援するために管理画面を刷新しました。

また、クエリ時に大きな結果セットを扱えるようにもしました。このために、適応的メモリアルゴリズム、外部のソートやジョインを今回追加しています。このテーマは、今後MarkLogic 12でも継続していきます（ビジュアルTDEなどを検討中です）。これらの手法では、大規模データセットに対する複雑なクエリをインデックス作成時ではなくランタイム時に評価することで、必要なメモリを削減できます。

プラットフォームに関しては、ツール、OS、CPUの最新アーキテクチャへの対応、ARM対応、ハイパーバイザーの見直しなども行いました。

現在、MarkLogicは物理ハードウェア上のオンプレミスとして運用されていることはほとんどなく、その多くがVM上で実行されていますが（プライベートクラウド、パブリッククラウドなど）、それぞれ利用できるストレージや演算処理能力が異なります。このため私たちは、今後時間をかけてベストプラクティス、制約、推奨、デフォルト設定を見直していくつもりです。

とりあえずMarkLogic 11では、MarkLogicの観測性（ヘルスチェックやメモリ診断など）を向上させることで、クラスタの理解を促進し、システムをより的確に保守できるようにしました。

また、コールドストレージの検出機能も追加しました。クラウドアーキテクチャの採用が進むなか、ストレージがノード上に置かれることはほとんどなくなっています。今は、クラウド業者が提供する各業者独自のストレージあるいは他社のストレージが使用されていますが、これにより遅延が発生します。つまり、マウントされたドライブのネットワーク可用性が問題となります。これによる影響は多岐に渡りますが、そういったボリュームの可用性やパフォーマンスは、MarkLogic側でのサービス低下につながる可能性もあります。そこで、MarkLogic 11では、コールドストレージを検出し、そのノードをクラスタから実質的に除外する機能を追加しました。

MarkLogicサーバーは、これまでもずっとエンタープライズクラスのソフトウェアでした（高可用性や強力なセキュリティ機能など）が、従来からの継続的な改善の一環として、MarkLogic 11ではストレージ障害検知、フェイルオーバー、お客様のニーズをサポートするセキュリティ機能を追加しています。

データセキュリティの確保

セキュリティは、常に私たちが極めて得意とする分野です。MarkLogicのお客様の多くにとっては、「セキュリティ/安全性」はMarkLogicの代名詞でもあります。私たちはさらに、バックアップの作成、クラスタ間通信の証明書管理の改善、暗号鍵管理のOAuth対応など、セキュリティ向上のための投資を続けています。

エンタープライズクラスのデータ管理プラットフォームとしての長い伝統を持つMarkLogicは、今後もセキュリティ、可用性、モニタリングなど、大企業のお客様に信頼される機能を強化していきます。私たちにとって、お客様からの信頼はとても重要なのですから。

クラウド戦略対応

MarkLogic 11リリースにおいても、MarkLogicは従来通り、CloudFormationテンプレートおよびDockerイメージとして提供されます。

また、お客様から近年のデプロイ手法（Kubernetesによるコンテナ化など）のご要望がありましたが、これにお応えするため、デプロイやオーケストレーションの仕組みとして非常に重要なKubernetesのサポートを開始しました。私たちのSaaSサービスもこれをベースにしていることからもおわかりいただけるように、私たちはこれに本気で取り組んでおり、今後１年かけて機能を拡張していきます。

今後について

2021年にSemaphoreを買収したことで、MarkLogicは新たな時代に突入しました。今後はMarkLogicサーバーおよびSemaphore製品の「DNA」に投資を続けるだけでなく、これらを一元化したプラットフォームの進化にも注力していきます。

MarkLogic 11のリリースでは、これら2つの面に関して新機能が追加されています。

• マルチモデルデータベース、検索、セキュリティ、その他のエンタープライズ機能など、MarkLogicサーバーのコア機能への投資
• お客様のデータエコシステムの一部としてデータプラットフォーム機能を拡張し、新たにGraphQLのサポートとOptic APIの強化を行い、私たちのコネクタ戦略も実現する

私たちは、この「DNA」と「プラットフォーム」の両方の目標をサポートするために、定期的なリリースのサイクルに移行していきます。これによりお客様が求めるものを的確に提供し、お客様自身のプロジェクトライフサイクルのプランニングが改善されるようにします。

今後のリリースについてここでは詳細に説明はしませんが、私たちは安定性、堅牢性、信頼性をもたらす機能への投資を続け、お客様のビジネスに役立つ現実的な問題の解決への支援に重点を置いていきたいと考えております。