オーストラリアに本社を置く、世界クラスのソフトウェアプラットフォームと製品を構築し、幅広い分散エネルギー資源とユーティリティ規模の資産の監視、制御、最適化、オーケストラを可能にします。 エヴァンゲン エヴァンゲン Evergenの使命は、耐久性の高い再生可能エネルギーシステムへの移行を促進することによってエネルギーシステムを脱炭素化することです。そのクラウドネイティブなアプローチは、再生可能エネルギーチェーンのすべての利害関係者が、エネルギーの使用と生産に関する明確な決定を下すために必要な情報にアクセスできるようにします。 Evergenのインフラストラクチャが拡大するにつれて、Evergenがそのニーズに応じて拡大できるタイムシリーズとリアルタイムの分析プラットフォームを模索し、EvergenがTigerData(TimescaleDBの作成者)を発見し、TigerDataがEvergenの主要ソフトウェアエンジニアであるJose Luis Ordiales Cosciaとのインタビューに基づいて、その運用をどのように変えたかを紹介します。 なぜEvergenはタイムシリーズデータベースが必要だったのか 「再生可能エネルギーの最適化は、Evergenのビジネスの大きな部分であり、時間連続データはそのために不可欠です。 Evergen は、MongoDB を使用したタイム シリーズ データのデフォルト データベースであったため、MongoDB アトラスをタイム シリーズ データのためのデフォルト データベースに使用していましたが、MongoDB を使用した Evergen のタイム シリーズ セットアップはコスト制限的で技術的に制限的でした: 「私たちのチームは、データをバケットに保存し、それぞれのバケットが 1 日であることにより、MongoDB の上に独自のスケジュールを作成しました。 MongoDBの突破点は、システムにインボードされたデバイスの数と、それらが生成した分間周波数データでした。 「データが通過するにつれて、MongoDBはより多くのデータをパッチし、より多くのデータを同時に保存していたので、使用が難しくなりました」とJose氏は言います。 技術的複雑性とスケーラビリティの制限 技術的な課題は、MongoDBの原料データストレージの限界から始まりました。Evergenは、デバイスメーカー間の互換性を確保するために何百もの統合を有しており、定期的に、これらの統合のそれぞれからデータを抽出し、すべての原料サンプルを公開するカフカのトピックに送信します。Kafka Streams(Kafkaのストリーミングライブラリ)は、これらの原料サンプルを読み、5分と30分のデータのためのメモリ内で事前集計を行いました。 “We did pre-aggregations in-memory,” says Jose, “because it was too expensive for us to store all the raw observations in MongoDB. MongoDB does not really support aggregations on the fly, as TimescaleDB does with MongoDB. MongoDB は、MongoDB ですべての原始的な観測を保存するのにあまり費用がかかりませんでした。 私たちが原始データと合計データを両方持っていたら、それらをすべて手動で行わなければならなかった」と述べた。 連続集計 連続集計 高データ量のため、彼らのKafkaストリーム処理サービスは膨大でした。Evergenはそのサービスの約30のインスタンスを実行し、Kubernetesでの使用の大半を占めました。 遅く到着したデータ(5分間の集約で15分以上、30分間の集約で1時間以上)は、以前集約したデータがメモリ内になくなったため失われた。 原始データがなければ、監査トラックとデバッグの透明性が欠如した。 MongoDBのタイムシリーズのパフォーマンスは、Joseによると、次のようなものでした: 「誰もが理想的ではないことを知っていたが、それはあなたが考えるものの一つだったが、ある時点で我々はそれを修正するつもりだったが、実際には誰もやらなかった。 データベース評価プロセス 彼らの評価プロセスでは、EvergenはInfluxDBを短く見たが、当時オーストラリア地域のサポートを減らしていたため、それは最初からダメだった。 彼らのインフラストラクチャはすべて AWS にあり、他の AWS サービスを使用しているため、Evergen は最初に Amazon Timestream を評価しました。   パフォーマンスの遅延(1日または1週間のデータの取得さえ2〜5秒の順序で)とクエリやパフォーマンス調節の欠如。 Docker を使用して Timestream データベースをローカルに実行できない(Postgres や TimescaleDB をローカルに実行することは容易でした) - Timestream を使用してローカルテストを実行するには、実際のデータベースを作成するために AWS に接続する必要があります。 再生可能エネルギーの予測には使えません - Timestream により、将来のデータの保存は 15 分までしかできませんでした。 Evergen は Timestream を使用して歴史的なタイム シリーズ データと Redis を予測されたタイム シリーズ データに使用しようとしました。 彼らは Redis から Timestream にデータを移行する仕事と論理を持っていましたが、デバイスやサイトに関連するデータはまだ MongoDB にありました。 それはただの痛みでした。私たちがこの評価プロセスを開始したときの重要な点の1つだった――すべてのデータのための1つのデータベースを使用できるようになること:タイムシリーズと非タイムシリーズ。それはTimescaleDBに関わったときに私たちにとって大きなセールスポイントでした、なぜならそれは下のPostgresだからです。   Evergen はまた、MongoDB でタイム シリーズ サポートを試みました: 「MongoDB でタイム シリーズ データを処理するこの新しいタイプのコレクションを持っています。 TigerDataの発見とテスト ジョセは最初、バックエンドエンジニアとして働いていた友人を通じてTigerDataについて知りました。製品について学んだ後、ジョセは以前の会社から役割を切り替えようとしていたとき、TigerDataで働くよう申請していました。 その後、彼がEvergenに加わったとき、彼はチームがそれを検討し始めたときにTimescaleDBを使用するための大きな擁護者となった - 彼はすでにその機能を知っていたし、それは戦闘でテストされた退屈な古いテクノロジーに基づいて構築され、それは「データベースにとって素晴らしい - あなたはそこでサプライズを望まない。 TimescaleDB を評価しながら、Evergen は TigerData リソースを活用しました。 「公式ドキュメンタリーは非常に包括的で、理解し、フォローしやすいものでした。TigerDataのブログには、さまざまなアプローチの妥協についての本当に素敵な議論もあった。   Evergenのコンセプトの証明には、MongoDBとTimescaleDBを並行して実行することによって二重書き込みと二重読み込みの設定が含まれていました。これにより、彼らは操作を妨げたり顧客に影響を与えることなくTimescaleDBをテストすることができます。TimescaleDBに数ヶ月のデータが保存されると、彼らはスイッチを作りました。スケーラビリティ、操作性、開発者体験の観点から、TimescaleDBはすべてのボックスをチェックしました。 「私たちは何十万ものデバイスを持っており、将来何百万ものデバイスを見ている可能性があるため、摂取率がスムーズであることを確認する必要があります。 「私たちは何十万ものデバイスを持っており、将来何百万ものデバイスを見ている可能性があるため、摂取率がスムーズであることを確認する必要があります。 「我々は何十万ものデバイスを持っているため、将来何百万ものデバイスを見る可能性があるため、私たちは摂取率がスムーズであることを確認する必要があります。これまでTigerDataは素晴らしいものでした」とJoseは言います。Evergenはまた、TimescaleDBのクエリパフォーマンスを評価しました。 開発者ツールの可用性も決定的な要因でした: 「Postgresは市場でそのような確立されたプレーヤーであるため、何千ものライブラリとツールが使用できるようになりました」 したがって、データをクエリする方法についての熟知性は「誰もが何らかのレベルでSQLを知っています。 データサイエンスチームや顧客サポートチームの誰かにTimescaleDBへのアクセスを与え、彼らはMongoDBではそうでなかったデータをクエリする方法を見つけることができます」 - Jose Luis Ordiales Coscia、Evergenの主要ソフトウェアエンジニア データサイエンスチームや顧客サポートチームの誰かにTimescaleDBへのアクセスを与え、彼らはMongoDBではそうでなかったデータをクエリする方法を見つけることができます」 - Jose Luis Ordiales Coscia、Evergenの主要ソフトウェアエンジニア セキュリティも考慮事項でした。 エヴァーゲンの要求を満たす。 TigerDataのセキュリティ機能 TigerDataのセキュリティ機能 Evergen が TigerData を使用する方法 MongoDB を TimescaleDB でタイム シリーズ データに置き換え、「テレメトリー サービス」を構築すると、これまで不可能だったデータの集中化が達成されました。 「タイム シリーズ データを処理している 1 つのサービスへのアクセスをカプセル化して孤立させようとしています。 この移行の目的の1つは、すべての読書と書き込みを1つの場所に統合することである「テレメトリサービス」で、タイムシリーズとリレーショナルデータを処理し、ほぼ独占的なアクセス権を持っています。 (Managed TimescaleDB) instance at Evergen. One exception is the access they provide to their data science team for exploratory querying of the data. This is where having a メインデータベースの機能は、そのチームにとってのみ、パフォーマンスに影響を及ぼさずにアクセスを提供するため役立ちます。 タイガー雲 読み返し タイガー雲 読み返し Evergenはまた、TigerDataの統合されたPopSQL IDEを使用しています。Jose氏は、「データベースを探索し、クエリを共有するための素晴らしいツールです。MongoDBではそうではありませんでした。私たちは毎回MongoDBアトラスページにログインし、クエリを手動で書き込む必要があります。 タイガー・クラウドの利益が最終顧客にどのように与えるか MongoDB では、Evergen はコスト制限のためにデータを 3 か月しか保存できませんでした。 「TigerData では、これらの保存ポリシーを定義するのが私たち次第です。 それは間違いなく、我々の製品チームにとって売上ポイントであり、過去1年間のホームエネルギーレポートを、過去3ヶ月のうちの1つに比べて提供できる」と語った。   クエリのパフォーマンスはもう一つの大きな勝利でした: 「以前は、ウェブアプリケーションやモバイルアプリケーションにアクセスするときに数秒間待たなければならなかったので、そのグラフを見ることができます。 TigerData が処理するタイム シリーズ データは、Evergen のエネルギー最適化サービスにも不可欠です. そのサービスには、バック・ザ・メーターの最適化(高度な個別化された電力コストの最小化を提供する機械学習の最適化)と、フロント・オブ・メーターの最適化(配送可能な資産の貨幣化を可能にする)が含まれます。 タイガー・クラウドの採用がEvergenにとって意味したこと Evergen では、MongoDB を Tiger Cloud に置き換えると、Kubernetes クラスターのリソースの使用量が 50% 以上削減され、コストの節約、効率的な圧縮、レイヤードストレージ、そして歴史データへの常時アクセスを達成することで、技術的およびビジネス的な柔軟性が新たに発見されました。 「どのくらいのデータを保管するか、何が役に立つか、何が役に立たないかを決定する自由を持っていることは、以前はどのくらいのデータを保管できるかという厳しい制限があったため、大きな勝利だった」とホセは言います。今では、この古いデータをS3に保管したいという柔軟性があります。 Tiger Cloudはまた、Evergenのスタックを簡素化しました。 「私たちのアーキテクチャを単純化すること、すなわちこれらのさまざまな特定のデータベースをすべて置き換えることは、アーキテクチャの全体的な複雑さにとって大きな問題であり、これを将来的に拡張することも容易にします」   すべての原始データにアクセスすると、デバッグのためにそれらを参照し、特定のデバイスに追跡することができます - これは、事前集計データよりも原始データで行うのがはるかに簡単です。 「すべての原始データを格納する能力」とJose氏は説明する「それは、私たちが考えたことすらない新しいアグレグレーションを作成することができることを意味します - 飛行中です。私たちはそれ以前にはできませんでした。TigerDataで、明日私たちが原始データから得られたこの新しいデータを必要と判断する場合、私たちは単に新しいアグレグレートを作成し、バックフリープロセスを実行することができます。 よく知られている Postgres に基づいて構築された Tiger Cloud はチームのオンボードにポジティブな影響を与えました。 「誰もがあるレベルで SQL を知っていて、誰もがキャリアのどこかで SQL で作業してきたので、新しく雇われたエンジニアは単にストレージ コードにジャンプして何が起きているのかを見つけるのは簡単でした」 TigerDataを使った未来計画 TigerData を選択することで、Evergen は将来的にそのアーキテクチャを拡張するのに役立ちました。 「これは本当です──あなたは今日、すべてのものに Postgres を使用できます。 絶対にすべてのものに拡張があります。 それは決定のもう一つの大きな要因でした──将来、このタイプのデータを保存する必要があるとしたらどうでしょうか? はい、この拡張機能はすでに利用可能です。 TigerData を使用して、Evergen は新しい市場に到達する計画をサポートするためにスケーラビリティのためのデータベースを構築し、彼らが持っているデバイスの数を規模の順に増やす予定です。 ジョセのアドバイスは、スイッチを検討するエンジニアに、「あなたのコードベースで抽象を作成するとき、コードの残りの部分から特定のテクノロジーに関連するすべてを隔離し、それは私たちが二重読み取りと二重書き込み実験を実行することを容易にしました - なぜなら、コードベースに1つの場所があり、それは起こるために変更しなければならなかったからです。

This story contains new, firsthand information uncovered by the writer.

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

このオーディオは、ストーリーの元の言語で制作されています。

Evergenが再生可能エネルギーモニタリングアーキテクチャをスケールするためにTigerDataを使用する方法

About Author

コメント

ラベル

この記事は

Related Stories

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps