fbpx

ビジネスの俊敏性を育む分散型アプローチ「Joyce」#MongoDB #MongoDBAtlas #Joyce

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本ブログは、2021年12月22日に公開された、MongoDB社のパートナー企業であるSourcesense社のRaffaele CamanzoさんによるMongoDB社のブログ「Joyce, a Decentralized Approach to Foster Business Agility」の日本語翻訳です。



ここ数年でさまざまなツールや手法が登場しています。しかしそれにもかかわらず、事業データを新しいデジタル製品やデジタルサービスの開発に活用するという点では、多くの企業が悪戦苦闘しています。そして、市場での経験が何十年にも及ぶ企業ほど、この傾向が顕著です。マッキンゼーが過去数年にわたって実施した調査研究によれば、デジタルトランスフォーメーションの成功率は一貫して低く、自社の業績向上に成功している割合は30%未満です。その理由は様々ですが、その多くは「デジタルトランスフォーメーションは、まずはじめに組織や文化面での変革を目指すものであり、その後、技術的な変革に移行するもの」という一言に尽きるのです。

問題は、デジタルトランスフォーメーションの取り組みが良いことなのか、クラウドへの移行が良い選択なのか、ということではありません。企業にはデジタルトランスフォーメーションが必要であり、クラウドへの移行もデメリットよりメリットが上回る場合がほとんどです。

ここでは、デジタルトランスフォーメーションの取り組みで企業が直面している主要な問題から3つを取り上げ、詳しく分析していきます。

デジタル製品の開発

製品とは本来、顧客主導で生み出されるものですが、企業のビジネスを支えるさまざまなバックエンドシステムは、目的主導のシステムです。よほど小規模な企業でない限り、こうした製品やシステムのオーナーシップは、さまざまな目的を持った人たちによって担われています。このような状況下で、企業が新しいデジタル製品をスピード感を持って市場に送り出そうとするとどうなるでしょうか。CRMやeコマース、ERPなどのバックエンドシステムには、顧客への提供が必要なデータが格納されています。システムには、SaaSのシステムもあれば、レガシーのシステムもあります。かつては革新的なソリューションで市場の変革を促した企業が開発した、カスタムのアプリケーションもあります。これらすべてを統合する完璧な方法が果たしてあるのでしょうか。

プロダクトマネージャーは、仕様変更の要求が複数発生したときに、それらを調整し、各システムの責任者と交渉を行う必要があります。納期に間に合うように、必要な対応をバックログに追加するよう、責任者を説得する必要もあります。また、新製品がソースシステムの処理能力に依存し、追加トラフィックを処理できなければ、製品とコアサービスの両方に悪影響を及ぼす状況に陥ります。

第三者との連携

だれもが変化を求めつつ、実際に変わろうとする人はほぼ皆無と言えるでしょう。絶えず進化を続けるデジタルの世界では、相手が顧客であれ、サービスプロバイダーであれ、パートナー関係を築くことが不可欠です。しかし、それを試みただれもが、その困難さを知っています。非標準のインターフェイスや、FTPでCSVファイルをやり取りする際の変則的な更新ルール、セキュリティの問題など、障害となる要素は際限がありません。

SaaSの乱立

SaaS(サービスとしてのソフトウェア)のモデルは広く普及しています。基盤のインフラストラクチャを気にかけず、必要なサービスを使用できるため、導入の自由度が高く、利用までに時間がかかりません。しかし、大規模な組織の場合、複数のSaaS製品に頼って業務を行っていると、何が起きると考えられるでしょうか。遅かれ早かれ、SaaSの導入をコントロールできなくなり、環境全体を一貫性のある方法で把握するためのコストが増加し続けることになります。同じドメインのコンセプトでも見方が複数存在したり、エクスポートに予定外のコストが発生したりする状況に対応しなければなりません。また、個々のデータはSaaSの内部表現で表されるため、データ形式の異なるさまざまなソースのデータを解釈、統合する必要もあります。

 

統合の課題


上記の問題はどれも、情報テクノロジーにおける1つのカテゴリに分類できます。それは統合の問題です。何年にもわたって多くのベンダーが、決定的なソリューションを開発したと断言してきました。現在、検討できるソリューションとしては、ローコードやノーコードのプラットフォームがあります。既成のコネクタを多数搭載し、最新のグラフィカルインターフェイスを備えたプラットフォームです。これで問題は解決するのでしょうか。そんなことはありません。ローコードの統合プラットフォームは実装を簡素化でき、その点では優れていますが、実際の課題を過度に単純化し過ぎてしまうことがあります。ビジネスバリューに関するAPIのセットを一貫性のあるかたちで作成、維持したり、インターフェイス内部の複雑さが外部に漏れ出すのを防いだりしなければならないといった課題があります。本来であればアーキテクチャの選択と適切なスキルを通じて問題を明確化し、対処しなければならない部分です。このような問題は、このプラットフォームのセールスポイントに完全に隠されてしまっています。

統合の問題を解決する方法には以下の2つがあります。

  • アダプターでの集約:このケースでは、ロジックを中央のオーケストレーションコンポーネントにプッシュし、アダプターのセットを通じて統合の管理を行います。これはどちらかと言えば保守的なSOAアプローチであり、市場に出回っている統合プラットフォームのほとんどがこのアプローチに基づき構築されています。
  • 分散型のソリューション:エッジにロジックをプッシュします。ビジネスバリューを実現するためにドメインが公開する必要のある境界とAPIを、開発チームが自由に定義できるようにします。これはマイクロサービスと並んで最近になって登場した比較的新しいアプローチで、解析の分野で使用されており、データメッシュのコンセプトを取り入れています。

前者の方法は、開始時点で必要なスキルや選択肢が限られるためスピーディーに作業を始められます。しかし長期的に見ると、この方法は技術的意味での負債が累積するのを避けられません。本来必要な自由度が限られるため、時間の経過に合わせて統合周りを進化させることができません。SOAがマイクロサービスアーキテクチャに置き換えられているのも同じ理由です。後者の方法では、その実行にあたって適切なスキルやビジョン、能力が必要になりますが、すぐに結果が得られ、時間の経過に合わせてアーキテクチャを柔軟に進化させることができます。

 

古くから存在する問題と新しい解決策


Sourcesense社では、過去20年にわたり、お客様が俊敏性とスピードを獲得し、新たなオープンソースのテクノロジーを活用できるよう、数多くのプロジェクトを支援してきました。そしてその間に幾度となく上記のような統合の課題に直面し、当時利用できるテクノロジーで問題の解決に努め、SOA上でいくつかの統合ソリューションを開発しました。当時はそれが最良のソリューションだったのです。また、市場に出回っていた数多くの統合プラットフォームとの連携も実施しました。それでも、さまざま問題と、この分野のソリューションの限界に苦しめられました。そこで顧客のニーズに耳を傾け、お客様の期待に応えられていないポイントを探りました。アジャイルの手法やクラウドコンピューティングや、新たな手法、テクノロジー、アーキテクチャスタイルの登場により、これまでにないレベルで、ソフトウェアと、ビジネスニーズへの対応力が進化しています。そのため、弊社ではこのような新たな動きを取り入れ、これらのツールで問題の解決に努め、経験を積んできました。

この過程で統合の問題に遭遇するたびに、繰り返し同じパターンを目撃しました。そして、企業のアーキテクチャにおける、これらの課題を解決する要素として、データハブが有用なコンポーネントであることもわかりました。このような経緯から、弊社では独自のソリューションを開発したのです。それがJoyceです。

データハブ

これは比較的新しい用語です。データの分散と共有を主要な目的として、さまざまなソースからデータを収集するソフトウェアプラットフォームを意味します。この定義はおおざっぱで曖昧であるため、重要な別の要素をいくつか加え、弊社が考えるデータハブの概要をご説明します。異なるデータソースからデータを収集することで得られるメリットとして、主に次の3つが挙げられます。

  • コンピューティングをソースと分離:元のシステムからデータをプル、または元のシステムへデータをプッシュするということは、クライアントアプリケーションやクライアントサービスはハブとのみやり取りをして、ソースシステムとは直接やり取りをしないことを意味します。このため、追加のトラフィックが発生しても元のシステムへの影響はなく、処理が遅くなるのを防ぐことができます。
  • カタログと検出機能:データを正しく収集すれば、カタログを作成できます。組織内のユーザーは、カタログを利用することで、データをハブから検索、探索、利用できます。
  • セキュリティ:ハブの主な目的は、分散と共有の実現にあります。これは、アクセス制御とセキュリティに重点を置いた機能強化に直接つながります。アクセスポイントが単一であると、必要なデータの収集でクライアントがやり取りしなければならないシステムの数が大幅に減るので、データに関するセキュリティを全体的にシンプルにできます。

 

Joyceの機能


Joyceの基盤となっているコンセプトはスキーマです。スキーマを利用することで、取り込むデータの形と、このデータがどのようにクライアントサービスで利用できるようになるかを形作ることができます。スキーマは、Kubernetesでよく知られるようになった宣言型のアプローチを通じ、期待する結果を表現します。そしてプラットフォームはその結果が得られるよう、アクションを実行します。

スキーマは、カタログに保存、分類される標準のJSONスキーマファイルです。スキーマの定義は、以下の3つのカテゴリに分けて考えることができます。

  • インプット – ソースデータを収集、形成する手段です。さまざまなソースに対応できる既成のコネクタを、Kafka Connectフレームワークを活用して提供します。取り込んだデータは、トランスフォーメーションハンドラー(JSONスキーマにおけるドメイン固有の拡張機能)でフィルタリングやフォーマット、情報の追加ができます。
  • モデル – プラットフォームに保存されているデータから新たなデータの集合を生成することができます。この機能により、クライアントサービスの必要性に合わせて自由にデータをモデリングできます。
  • エクスポート – バルクデータのエクスポート機能です。既存のデータに対して、任意の一時的フィルターを使用しクエリを行えば、エクスポートできます。

インプットデータとモデルデータは、自動的に生成されたREST APIとGraphQL APIを通じて、適切に認証されたすべてのクライアントサービスに提供されます。イベント主導のアプローチがよりユースケースに適している場合は、専用のトピックを登録することも可能です。

柔軟性と拡張性に優れたモデルを実現するために不可欠なMongoDB

Joyceにとって、MongoDBは不可欠な存在です。その柔軟性のおかげで、データを収集するためにユーザーが定義するどのデータ構造も簡単にマッピングできます。スキーマの定義の半分は基本的に、MongoDBのスキーマの定義です。(データの整合性を保証できるよう、併せてコレクションごとに1つのスキーマを自動生成します)

JoyceはKubernetesクラスターで機能します。水平スケーリングの機能を最大限に活用できるよう、サービスのすべては本質的にステートレスになっています。アーキテクチャはCQRSパターンをベースにしています。書き込みと読み取りが完全に分離されており、運用環境の固有のニーズに合わせて書き込みと読み取りの独立したスケーリングが可能であることを意味します。MongoDBはAPIレイヤーを支えるデータベースでもあるので、どのスタックコンポーネントでも、低レイテンシー、高スループット、継続的可用性が保証されます。

このプラットフォームは、主要な3つのクラウドプロバイダー(AWS、Azure、GCP)で、フルマネージド型のPaaSとして提供されます。ただし、必要に応じ、既存のインフラストラクチャ(クラウドまたはオンプレミス)にインストールすることもできます。

 

最後に考慮すべきいくつかのポイント


デジタルトランスフォーメーションで成功を収めるために数多くの課題に直面するのは間違いありません。その変革の過程において、さまざまなレベルでリーダーは、組織を正しい方向へと導かねばなりません。過去数年の間にテクノロジーソリューションが急激に成長したのに伴い、複雑な要素が増え、混乱も増しています。一方で、組織のモデルと組織で利用される手法の進化に伴い、中央のガバナンスは必要最低限に抑え、責任の共有、従業員への権限の委譲、チームの独立を尊重する動きが組織の中に生まれています。同時に、この進化のおかげで、データメッシュなどのまったく新しいアプローチが企業のアーキテクチャに浸透しました。

残念ながら、すべての問題を魔法のように確実に解決することは不可能で、状況に合わせて最適な選択肢を選ぶしかありません。デジタルトランスフォーメーションに関するあらゆるニーズに対して、あれこれとマーケティングや宣伝が行われていますが、長期的な視点でトランスフォーメーションを成功させるには、適切なガイダンスとコンピテンシー、権限委譲が必要です。弊社はJoyceの開発を通して、反復的な作業やボイラープレートコードの負荷を抑え、容易に解決できる問題から着手してすばやく結果を出すということを目指しました。顧客の企業アーキテクチャの現状と進化を適切に定義するために必要な思考力を代替することではありません。この記事の最初に列挙した課題でお悩みであれば、ぜひJoyceをお試しください。

New call-to-action
新規CTA