マネージド クラウド データベースで ecobee のユーザーにスピード、スケーリング、新機能を提供

※この投稿は米国時間 2020 年 12 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

ecobee は、トロントを拠点とするスマートホーム ソリューション メーカーで、ユーザーの日常生活の向上を支援するとともに、より持続可能な世界の実現に貢献しています。ecobee はオンプレミス システムから Google Cloud を使用したマネージド サービスに移行することで、容量や規模を拡大し新しい製品や機能を迅速に開発できるようになりました。ここでは、同社がどのようにしてこれを実現し、時間と費用を節約したのかを紹介します。

ecobee が構築するのは単なるスマートホームではなく、インテリジェント ホームです。ニーズ、行動、好みに基づいて学習、調整、適応を行います。当社が設計するのはスマートカメラ、照明スイッチ、サーモスタットなどと連携して機能する有用なソリューションで、今では日常生活に溶け込んで欠かせない存在になっています。

最初の製品は世界初のスマート サーモスタット（本当です）で、発売は 2007 年でした。SmartThermostat の開発では、当初はリレーショナル データベースを使用した自社開発のソフトウェア スタックを使用し、これを拡張し続けました。ecobee のサーモスタットは、デバイス テレメトリー データをバックエンドに送信します。このデータで Home IQ 機能を駆動し、HVAC システムのパフォーマンスと快適設定の維持状況に関するデータをユーザーが確認できるようにしています。これに加えて、SmartThermostat を強化して効率性をさらにアップする eco+ 機能があり、自宅のピーク時における冷暖房を最適に調整するのに役立っています。オンラインになる ecobee のサーモスタットが増えるにつれて、容量不足を実感するようになりました。処理する必要のあるテレメトリー データの量は増え続け、コロケーション型データセンターで既存のソリューションをスケールアウトするのは非常に困難になっていました。

さらに、データベース レプリカで優先度の高いジョブを実行すると、タイムラグが発生していました。繰り返し発生する問題を修正してデバッグするためだけに、スプリントで多くの時間を費やしていました。積極的な製品開発の目標を達成するには、より適切に設計された、柔軟性の高いソリューションを見つけるために迅速に行動する必要がありました。

スピードとスケーリングを実現するクラウドの選択

スケーラビリティと容量の問題を抱える中、クラウド サービスに目を向け、マネージド サービスが必要だと認識するようになりました。まず、データストアで使用するソリューションとして BigQuery を採用しました。6 か月以上経過したクール ストレージでは、BigQuery からデータを読み取るようにして、ホット データストアに保存する量を減らしました。

ただし、クエリ単位の課金モデルは当社の開発データベースには適さなかったため、Google Cloud のデータベース サービスを検討しました。まず、データベースで実行するデータのアクセス パターンを把握することから始め、リレーショナルである必要はないことに気づきました。データには定義されたスキーマはありませんでしたが、低レイテンシと高スケーラビリティが必要でした。また、この新しいソリューションに移行するデータが数十テラバイトありました。そして、水平方向のスケーラビリティ、読み取り速度容量の拡張、スケーリングを阻止するディスクではなく必要なだけスケーリングできるディスクといったニーズを満たすには、Cloud Bigtable が最良のオプションであることがわかりました。こうして可能な限り多くの SmartThermostat にスケーリングして、そのデータをすべて処理できるようになりました。

改善されたバックエンドの結果を活用

Bigtable に切り替えたことで得られた最大のメリットは、費用の削減です。Home IQ 機能の稼働コストが大幅に削減され、ホットとコールドのすべてのデータを Bigtable に移行することで、機能のレイテンシが 10 分の 1 に大幅に削減されました。Bigtable を追加したことで、さらに多くのユースケースに利用を拡大したにもかかわらず、Google Cloud の費用は月額約 $30,000 から月額 $10,000 に減少しました。これは非常に大きな改善です。

また、バックエンドで Bigtable を使用することで、エンジニアリング時間が大幅に削減されました。もう 1 つの大きなメリットは、トラフィック ルーティングを使用できることです。これにより、ワークロードに基づいてトラフィックを別のクラスタにシフトすることがはるかに簡単になりました。現在、単一クラスタ ルーティングを使用して、書き込みと優先度の高いワークロードをプライマリ クラスタにルーティングし、バッチや優先度の低いその他のワークロードをセカンダリ クラスタにルーティングしています。アプリケーションが使用するクラスタは、特定のアプリケーション プロファイルを介して構成されます。この設定の欠点は、クラスタが使用できなくなった場合、レイテンシが急増するためユーザーに目に見える影響を及ぼすことになり、結果的にサービスレベル目標（SLO）が損なわれることです。また、この設定では別のクラスタへのトラフィックの切り替えは手動になります。これらの問題を軽減するために、複数クラスタのルーティングへの切り替えを予定しています。そうすることで、クラスタが使用できなくなった場合に Bigtable でオペレーションを別のクラスタに自動的に切り替えるようになります。

マネージド サービスを使用するメリットは膨大です。今ではインフラストラクチャを常時管理する必要がなくなり、さまざまな可能性が広がりました。そして、製品の機能の改善や拡張に集中して取り組めるようになりました。当社は Terraform を使用してインフラストラクチャを管理しているため、スケールアップは Terraform の変更を適用するのと同じくらい容易に行えます。Bigtable インスタンスは、現在の負荷をサポートするのに適切なサイズで、インスタンスをスケールアップしてより多くのサーモスタットをサポートすることも容易です。既存のアクセス パターンを考えると、ストレージのニーズの増加に合わせて Bigtable の使用量をスケーリングするだけで済みます。データの保持期間は 8 か月のみで、これはオンラインにするサーモスタットの数によって決まります。

Cloud Console には、キーへのアクセス方法、存在する行数、使用されている CPU の量などを示すヒートマップも、継続的に更新されて表示されます。これは今後、適切なキー構造やキー形式を確実に設計するのに非常に役立ちます。また、モニタリング システムで Bigtable にアラートを設定してヒューリスティックを使用し、クラスタを追加するタイミングを把握できるようにしています。

現在、ユーザーが自宅で最新のエネルギー使用量を確認するとき、またサーモスタットが必要に応じて冷房や暖房を自動的に切り替えるとき、これらの操作はすべて Bigtable によって裏付けられた情報に基づいて行われています。

ecobee と Google Cloud のデータベースの詳細をご覧ください。

-ecobee 社 One Platform バックエンド デベロッパー Joshua LEO-Irabor 氏

-ecobee 社 One Platform バックエンド デベロッパーEmmett Underhill 氏