Profit.co社、Elasticsearchで検索とログ管理をスケールして優れたユーザーエクスペリエンスを提供

illustration-scalability-gear-1680x980_(1).jpg

Profit.co社はOKR管理ソフトウェアの構築を通じて、企業のリーダーの業務と進捗状況の測定を支援しています。Profit.co社のプラットフォームは、スタートアップ企業からFortune 500企業までを対象としており、ビジネス目標や、リソース、パフォーマンスを管理できる単一のビューで顧客の目的を達成できるように支援します。

Profit.co社はどのようにして顧客の生産性を向上させ、エンゲージメントを促進する機能を提供したのでしょうか?実は同社は、スケール可能な全文検索ソリューションを必要としていました。そこでProfit.co社は、Elasticの製品やソリューションを支える強力な検索エンジン、Elasticsearchを選択しました。これにより、検索エクスペリエンスを劇的に向上させることができました。検索分野での成功を受けて、同社のチームは一元的なログ管理もElasticsearchへと移行しました。

現在、Profit.co社ではElasticsearchを使用してポジティブな検索エクスペリエンスを生み出し、ログ管理を合理化し、継続的にパフォーマンスを最適化して、エンドユーザーのニーズを満たしています。ElasticがProfit.co社の課題を解決した方法を詳しくご覧ください。

Postgresは拡張性に欠けていた

当初、Profit.co社はさまざまなソリューションを使用していました。Profit.co社のバイスプレジデント兼エンジニアリング責任者であるクマル・デベラコンダ氏はこう話します。「当初、当社ではMySQLを使用していましたが、その後Postgresに移行しました。MySQLにない機能がいくつかあったからです」

しかし、Postgresはスケールが困難でした。Profit.co社のユーザーは、複数のフィールドを検索し、検索結果の取得を急ぎ、関連性に基づいて結果を並べ替える必要がありました。Profit.co社は、ユーザーを支援するために全文検索ソリューションが必要であると気づきました。デベラコンダ氏はこう述べます。「以前は、クエリの実行対象となる全テーブルにPostgresを組み合わせていました。オブジェクトを格納するときは、すべてのフィールドからすべてのデータをキャプチャし、1つの列に保存していました。しかし、この方法はあまりにも低速でした。また、スコアの関連性などに関する結果も不正確でした」

Profit.co社のチームの調査から、ほとんどのソリューションが非常に低速で、顧客が必要としているレベルの正確性が確保できていないことが判明しました。さまざまなソリューションを検討したのち、同社はElasticsearchに出会い、2014年にシステムを切り替えました。

「Elasticはアプリケーションのスケーラビリティの面で役立ちました」とデベラコンダ氏は述べます。Elasticへの移行はゆっくりと進みました。さらに同氏は、「当社は全文検索から導入し、PostgresとElasticsearchでデュアルストレージを運用していました。レコードをPostgresに格納しつつ、Elasticsearchにもデータをプッシュしていました」と話します。

さらにデベラコンダ氏は気づきました。「なぜデュアルストレージを維持する必要があるのだろう。なぜElasticsearchに直接アクセスできないのだろう?」 すべてをElasticsearchに格納することで、Profit.co社は業務を高速化し、エンドユーザーだけでなく社内チームのエクスペリエンスまでも合理化することができました。

速度を求めて

切り替えを決断した主な理由は速度でした。しかし、デベラコンダ氏はこうも言います。「当社は、スコアの関連性を示してくれるソリューションも探しはじめました。 Elasticがなかったら、お客様は情報の検索しづらさにストレスを溜め続け、正確な情報も得られなかったことでしょう」

Postgresを使い続けていたら、その速度の遅さがすべてのリソースに影響を与えていたでしょう。ユーザーは待たせられていました。エンジニアリングチームでも、変更を実装しようとすると遅延が発生しました。Elasticに移行してからは、速度が改善しました。従来のデータベースだと、検索クエリに10秒以上を要していました。Elasticを使用すると、複雑なクエリ(複数フィールドでの検索)でも100ミリ秒未満で応答が返されるようになりました。

スケールのしづらさ

Elasticへの移行は、検索エクスペリエンスの向上だけでなく、Profit.co社の規模の拡大にも役立ちました。デベラコンダ氏はこう話します。「Postgresでは接続数の制限に苦労させられました。Elasticでは分散型のスケーラビリティを利用できるため、あらかじめ決められた接続数ではなく、インフラストラクチャー用リソースの可用性に基づいて任意の数のクライアントを接続することができます」

今ではProfit.co社は、ユーザーがクラスターに分割されることを心配することなく、複数のクラスターを持つことができます。Elasticは、ネストされたフィールドもサポートしています。Profit.co社は、ドキュメントの規模が大きくとも、ドキュメント内のあらゆるデータを保存できるようになりました。デベラコンダ氏はその効果について、「格納前にデータを分析する必要がなくなりました」と話しました。 これにより貴重な開発時間が確保され、より高価値なタスクに集中できるようになりました。

Elasticを選ぶ理由

Profit.co社がElasticを選んだ理由は、速度とスケールの他にもありました。デベラコンダ氏はチームの能力向上に役立つ、とある機能を求めていました。「ネストされたフィールドに対するクエリも、Elasticを選んだ理由でした。さらに統合もサポートされていたので、最終的にElasticを選ぶことになりました」

チームメンバーにとって、切り替えは簡単でした。「Elasticの使い方は、開発者にとってはわかりやすいものです。オンボーディングはすばやく実施できました」とデベラコンダ氏は語ります。また、Elasticは、期待を上回る安全性をもたらします。デベラコンダ氏はElasticを使うことで、普通のSQLでは不可能なほど厳密にコーディングを制御できるようになりました。同氏はこうも述べています。「カスタムクエリを記述する必要がありません。すべてをAPIとして利用できるので、コーディング中のエラーが少なくなりました」。 エラーが少なくなったことで、機能が向上し、ユーザーエクスペリエンスがさらに良くなりました。

一元化されたログ管理

Elasticの検索を使用しはじめると、Profit.co社のチームはさらなるメリットが組織にもたらされたことに気づきました。ElasticとGoogle Cloudの組み合わせが、ログ監視機能の最適化に役立ったのです。「一元化されたロギングシステムは、Google Cloudに移行する前から目標としていたものでした」。 さらにデベラコンダ氏はこう続けます。「Elasticを使用することで、自動化されたスクリプトによってデバッグなどに必要なログファイルを簡単に確認し、見つけ出せるようになりました」

Profit.co社のCEOであり、創立者でもあるバスティン・ジェラルド氏も、ここに計り知れない価値を見出しました。「送受信されるデータはすべて、別のElasticクラスター内にあるデータベースに記録され、確認のために使用されます」。 現在、チームはElasticを使用して、1日あたり約200万件のリクエストについてデータ損失を特定したり、防御策を講じたりできるようになりました。Elasticsearchを使用することにより、Profit.co社は総コストの約90%を節約できます。すべてのアプリケーションノードとマイクロサービスからログをインジェストしても、1日あたりわずか5 GBのデータ増にしかなりません。

ジェラルド氏はこのように説明します。「当社を出入りするリクエストと応答を監視するため、当社ではそれらすべてを別のクラスターに記録しています。特定のクライアントのパフォーマンスが悪いか、データサイズが大きい場合は、そのようなリクエストの分析を行います」。 パフォーマンスを俯瞰的に把握することで、顧客の懸念が大きな問題になる前に対処できます。

Profit.co社の未来

Profit.co社は、現在約500人の顧客をサポートしています。顧客ベースの拡大とともに、Elasticも拡張されていくでしょう。

Elasticsearchの詳細を確認し、お好みのクラウドに数分でデプロイしましょう。Elasticsearchには14日間の無料トライアルがあります。今すぐご登録ください。