Flowhub、MongoDBを活用して法規制の頻繁な改定に対応し、ビジネスを拡大　#MongoDB #MongoDBAtlas #海外事例

本ブログは「MongoDB」社のブログで2021年1月20日に公開された「Flowhub Relies on MongoDB to Meet Changing Regulations and Scale Its Business」の日本語翻訳です。

米国では、大麻を取り締まる法的環境が絶えず変化しており、毎年、新たな州や司法管轄区が大麻を合法化、または解禁しています。そして、大麻の販売や使用を取り締まる法規制はさらに頻繁に改定されており、それによって大麻業界では、ビジネスの進め方だけでなく、データの管理方法にも大きな影響が生じています。法規制の変化に対応するには、ソフトウェアやデータベースの迅速なアップデートが必要です。これが可能になれば、飛躍的に成長している業界のスケーリングのニーズに対応できるのは当然のことながら、必要に応じて容易にデータの構造を変更することも可能になります。

Flowhubは大麻業界向けのソフトウェアを開発している企業であり、これから説明するようなさまざまな課題を日々軽々とクリアしている企業なのです。Flowhubでリードアーキテクトを務めるBrad Beeler氏に最近お話を伺う機会がありました。話題になったのは、同社の概要や、規制が複雑な業界における業務上の課題のほか、ビジネスの強化で同社がMongoDBを選択した理由です。また、MongoDBのコンサルティングがパフォーマンスの向上はもとよりコストの削減にも寄与し、同社が1か月もかけずに投資を回収しているのに役立っていると伺い、この点についてもいろいろとお聞きしました。

Eric Holzhauer：まず、貴社の企業概要について少しお聞かせください

Brad Beeler氏：Flowhubでは、大麻の薬局で必須となるテクノロジーを提供しています。2015年に設立されたFlowhubは薬局が法令を遵守できるよう、業界で初めてMetrc APIの連携機能を提供しており、この分野の草分け的存在です。現在では1,000を超える薬局がFlowhubのPOSや在庫管理、ビジネスインテリジェンス、モバイルのソリューションを利用し、年間売上30億ドル以上にもなる大麻ビジネスに役立てています。

Eric Holzhauer：貴社ではMongoDBをどのように活用しているのでしょうか

Brad Beeler氏：実際のところ、POSや在庫管理をはじめとするすべてのアプリケーションがMongoDBをベースに開発されています。弊社では当初より、MongoDB Atlasを使用してきました。
私が2年半前に入社したときには、運用環境のメインクラスターはM40のクラスター階層のクラスターでしたが、現在では、M80のクラスターに拡張されています。対象のロケーションを増やして新たな顧客にオンボーディングを行い、既存の顧客ベースでは売上を伸ばして、ビジネスを大きく拡大してきました。顧客との間には現在、年30億ドルの取引があります。このような成長の過程では、弊社はまず、データベースへのリソースを増やす前にデータベースのレベルで最適化を行い、それからクラスターのスケーリングを実施しています。Atlasが優れている点としては、自社の成長を把握するうえで必要な指標が得られることが挙げられます。何らかの最適化を施したら、CPUとメモリの利用状況を確認し、インデックスでクエリを実行する際にそのパフォーマンスをさらに高める方法がないかをチェックしてから、スケーリングのタイミングを見極めます。ユーザビリティを確保するためには、遅延を抑え、アプリケーションのUIの応答性を高めることが本当に重要です。そしてそのようなパフォーマンスを実現するうえで、Atlasの優れた拡張性が役立ちます。
Atlasには、特別なアナリティクスノードを導入しており、このノードでレポート用のクエリを実行します。ほとんどのアプリケーションのデータアクセスでは比較的直截なCRUDが使用されますが、弊社のアプリケーションでは集約パイプラインを実行して日々の売上のレポートや財務レポートなどを作成しています。これらのレポートは月末や年末に特別に集計しており、その内容を念頭に置いて前の期間を振り返れば、お客様はビジネスのトレンドを把握できます。コアのアプリケーションクエリとワークロードを分離できるのは非常に役立ちます。そして、集約パイプラインの作成で驚くべき能力を発揮したツールがMongoDB Compassでした。

Eric Holzhauer：業界が特殊である理由を詳しく教えてください。また、MongoDBが最適なソリューションである理由も教えてください。

Brad Beeler氏：規制を取り巻く環境が大きく影響しています。米国の場合、つぎはぎ型で規制が適用され、その内容は変化し続けます。ご存知のように、2020年の選挙サイクルでは、いくつかの州が新たに大麻を合法化しました。各州では、この業界をどう規制する必要があるのか依然模索している段階であり、効果のある規制とない規制がわかると規制の内容を変更するので、変更の頻度があまりにも多くなるのです。
このような常に変化を続ける状況に適応する必要があるのですが、その際には、MongoDBに大いに助けられました。新しい規制に対応する場合、アプリケーションのレイヤーを変更して対応できます。データベースのレイヤーの変更に関するメンテナンス作業は最小に抑えられます。この結果、開発のサイクルが短くなり、製品を市場に送り出すまでの期間が短縮されます。新たなデータの要件にすばやく対応するうえで、MongoDBの柔軟性が大いに役立ったのは間違いありません。

具体的な例をいくつか挙げてみます。

• オレゴン州では、購入する大麻の量をその形状にかかわらず消費者が正確に把握できるようにすることを義務付けました。一部の薬局では紙巻の製品を販売しているため、それらの製品の紙の重さを記録する必要がありました。つまり、収集すべき新たなデータポイントが増えたわけです。そこで、アプリケーションのUIを変更し、大麻の形状に関するフィールドを設け、薬局が紙の重さを入力できるようにしました。入力されたデータはデータベースへと送られます。
• 薬局では領収書だけでなく、処方内容などがわかる処方ラベルも発行します。州によっては、このラベルに、大麻の効能のレベルやカンナビノイドの含有率のほか、処方された大麻がどのバッチやパッケージの大麻であるかなどの情報も記載されています。これらの情報はどれも保存が必要な情報であり、州の固有の要件に基づき、計算を加えたり、別のフォーマットで表記し直したりしなければならないこともあります。
• この業界では、大麻の栽培から販売に至る過程のすべてが追跡されています。農園には非常に早くからバーコードが導入されており、大麻が栽培の個々のサイクルを経て梱包されるまでのすべてが追跡されています。たとえば、リコールがあった場合は、その大麻が生産された農園や生産地域を絞って、すべての製品の状況を追跡することが可能です。データを追跡してシステムに統合し、サプライチェーンへと伝えることが、不可欠になっているのです。

データはすべてが、規制当局のシステムで追跡されています。弊社では、米国最大の大麻追跡システムであるMetrcとシステムを連携させています。それゆえ、弊社のシステムはMetrcにフィードバックを行います。そして、必要な情報についてはどれも、レポーティングのプロセスを自動化しています。スプレッドシートをMetrcにアップロードしたり、薬局が私たちに変わって同じことをしたりするようなマニュアルでの作業と違ってずっと簡単に処理が可能です。そして一方では、Metrcから情報を取得することもあります。薬局に大麻が入荷すると、薬局はパッケージの記録を弊社のシステムにインポートするので、弊社はこの情報を在庫情報として保存し、関連する情報をMetrc APIから取得します。

Eric Holzhauer：貴社のビジネスにおけるMongoDBの導入効果を教えてください

Brad Beeler氏：製品やサービスを市場に投入するまでの期間をさまざまな手法を通じて確実に短縮できました。規制やデータに関する要件は州によって異なりますが、MongoDBの持つ柔軟性のおかげで、どの州で新規にビジネスを始めるのも容易です。適切なデータを収集したり、データに基づき必要な計算をしたりする場合も簡単に処理できます。また、開発者の生産性の向上も、市場投入期間の短縮に寄与しています。弊社はJavaScriptの専門家集団であり、JSONのスキルは開発者の第二の天性であるため、MongoDBのドキュメント構造は非常に理解しやすく、扱いやすいものになっているのです。

Eric Holzhauer：MongoDBのどのバージョンを使用されていますか

Brad Beeler氏：MongoDB 3.4から使い始め、今では4.0にアップグレードしています。そして、データベースとMongoDB Cloudにおけるいくつかの新たな機能を利用するべく、4.2へのアップグレードを準備しています。特に注目している機能の1つにAtlas Searchがあります。データの近くで完全な検索エンジンを実行できれば、大幅なパフォーマンスの向上が実現するものと期待しています。

弊社のインフラストラクチャはそのほとんどが、Node.js上に構築されており、弊社では、Node.jsドライバーを使用しています。MongoDBのレプリケーションとドライバーが特に優れているのは、フェイルオーバーが発生したり、プライマリのシステムが切り替わったりしても、ドライバーは機能し続け、リプリカセットとの接続が維持され、必要に応じて読み出しや書き込みのリトライができる点です。この仕組みがあれば、ダウンタイムや接続の問題を回避できます。

Eric Holzhauer：MongoDBのセキュリティはどのように確保しているのですか

Brad Beeler氏：セキュリティは弊社にとって非常に重要な要素です。弊社では、Atlasのセキュリティ制御機能でデータを保護しています。開発者が開発環境で容易に作業ができるよう、また、運用環境では限られたユーザーのみにデータのアクセスを許可するよう、アクセス制御の設定を行っています。Flowhubに統合しているいくつかのサードパーティ製アプリケーションへのアクセスやデータベースへのアクセスをどのユーザーやシステムに許可するか、IPアクセスリストで制御しています。また、現在はIPアクセスリストで制御しているアプリケーションの接続では、VPCピアリングの使用も検討しており、その実装の調査を進めています。
Client-Side Field-Level Encryptionにも興味があります。弊社ではすでに、収集および保存する個人情報（PII）の数を制限しており、保存が必要なPIIの保護には細心の注意を払っています。Client-Side Field-Level Encryptionを活用すれば、PIIがデータベースに届く前にクライアントレベルで暗号化できるでしょう。

Eric Holzhauer：Atlasはどのクラウドプロバイダーのシステム上で運用しているのでしょうか

Brad Beeler氏：弊社では、すべての環境をGoogle Cloud上で運用しています。AtlasはGoogle Cloudのインフラストラクチャ上で使用しており、アプリサーバーはGoogle Kubernetes Engineで動作しています。
そしてほかにもGoogleのサービスをいくつか利用しています。イベント駆動型のアーキテクチャを実現するためのメッセージングバックボーンにはGoogle Cloud Pub/Subを使用し、これに大きく依存しています。コアのアプリケーションは当初、完全にモノリシックなアーキテクチャで構築しました。すぐにシステムを稼働させるにはそれが最も簡単なアプローチだったからです。そして、ビジネスが拡大するのに伴い、マイクロサービスへの移行を進めました。Pub/SubはMongoDB Atlasと接続しました。データの運用は公開のイベントへ移し始めています。マイクロサービスはイベントトピックに登録が可能で、イベントを通じ、アクションを実行したり、ローカルデータストアを維持/監査したりできます。
弊社のデータサイエンスチームは、弊社独自のアナリティクスツールのほとんどで、バックエンドにGoogle BigQueryを活用しています。弊社ではほとんどのユーザーを対象として、社内のETLプロセスを通じ、データをMongoDB AtlasからBigQueryへと移動していますが、リアルタイムのニーズが増えているため、Google DataflowでMongoDBのoplogとストリームデータをBigQueryと連携させる取り組みを始めています。

Eric Holzhauer：ビジネスが成長し、MongoDBの利用を拡大していく中で、最も重要になったリソースは何でしょうか

Brad Beeler氏：パフォーマンスを最適化したり、効率的なスケーリングを実現したりするうえで、MongoDBのFlex Consultingが大いに役立ちました。Flowhubは長年にわたって事業を展開しており、成長に伴い、弊社のデータベースも拡大を続けてきました。数年前にスキーマ、クエリ、インデックスに関して下したいくつかの判断は、現在運用している環境に照らすと、最適な判断とは言えないものでした。しかし、それらを包括的に見直すことができないままでした。クラスターのスケーリングをするときは特に、改善の余地のあることがわかっていました。そこで、MongoDBのConsulting Engineerに弊社のデータの構造を調査してもらうことにしたのです。データのアクセス手法やパフォーマンス、インデックスの内容などについても調べてもらいました。WiredTigerのストレージエンジンの内部までも調べ、どのような最適化の可能性があるのかを探ったのです。MongoDBについて数多くを学び、MongoDBのConsulting Engineerから各種のツールを紹介してもらったおかげで弊社は、パフォーマンスの問題を自ら診断できるようになりました。

Consulting Engineerのアドバイスに基づき、いくつかのデータに関して保存のための構造を変更し、特定のクエリを無効にしてパフォーマンスを高めました。また、不要なインデックスのグループも一掃しました。弊社では、長年にわたってさまざまなクエリのパターンに合わせて数多くのインデックスを作成してきましたが、MongoDBのConsulting Engineerはこの中から、まとめて削除できるインデックスや、多様なクエリのパターンに対応する新たな単一のインデックスで代替できるクエリを特定しました。さらには、Atlasにおいてもいくつかの最適化を行いました。ワークロードの性質に応じ、CPUの使用率が低いインスタンスへ環境を移したり、より効率性の高いバックアップオプションへと既存のオプションを変更したりしています。

コンサルティングサービスを通じて得られた最適化のアドバイスに従った結果、コストを35%以上削減することができました。そして、MongoDBのコンサルティングサービスは1か月未満で投資を回収できました。これは驚くべきことです。社内向けにコンサルティング投資の効果を示す必要がありましたが、これほどのコスト削減効果を示せれば十分でしょう。

コンサルティングサービスを通じて得られたナレッジはきわめて価値の高いものでした。このナレッジを今後も生かしていけば、さらなる効果を期待できるでしょう。たとえば、インデックス戦略では大きな成果がありました。新しいタイプのクエリを導入するときや、インデックスの追加を検討するときに、どのような点を確認しておくべきか、理解できるようになったのです。クエリを実行する頻度や、クエリを変更して既存のインデックスを使用できる可能性、既存のインデックスを変更して新たなクエリに対応できる可能性を確認したり、新しいインデックスが必要であると判断したときに既存のインデッスを破棄する必要があるかどうかを判断したりするようになっています。

コンサルティングサービスを通じて得られた最適化のアドバイスに従った結果、コストを35%以上削減することができました。そして、MongoDBのコンサルティングサービスは1か月未満で投資を回収できました。これは驚くべきことです。

Eric Holzhauer：今後のプロジェクトでMongoDBの利用を検討されている方に向けて何かアドバイスをお願いいたします

Brad Beeler氏：今扱っているデータの内容と、そのデータがどのように利用される予定であるのかを、事前に十分な時間をかけて把握することをお勧めします。MongoDBでデータを構成したり、クエリを設計したり、インデックスを実装したりする際に十分な準備が整います。弊社の場合、この点で、Flex Consultingが非常に有用であったのは明らかです。Flex Consultingの利用をぜひご検討ください。

MongoDB Atlasに関するご質問やご相談はこちらからクリエーションラインにお問合せください。