Carousell のような企業がクラウド データ プラットフォームにさらに多くのレポートをプッシュするにつれて、ビジネス インテリジェンス スタックの内部にボトルネックが現れています。かつては小規模では問題なく動作していたダッシュボードが遅くなり始め、クエリが数十秒に伸び、軽微なスキーマ エラーがレポートに波及します。つまり、チームは、安定した経営指標とアナリストのための柔軟な探索という 2 つの相反するニーズのバランスをとる必要があることに気づきました。
この緊張は、ビジネス インテリジェンス (BI) ツールが運用レポートや詳細な実験に役立つことが期待されているクラウド分析環境では一般的になってきています。その結果、多くの場合、単一の環境が過剰な機能を果たし、プレゼンテーション層、モデリング エンジン、アドホック コンピューティング システムとして同時に機能することになります。
東南アジアのマーケットプレイスであるカルーセル内の最近のアーキテクチャ変更は、一部の分析チームがどのように対応しているかを示しています。同社の分析エンジニアが共有した詳細では、過負荷になった単一の BI インスタンスから、パフォーマンスが重要なレポートを探索的なワークロードから分離する分割設計への移行が説明されています。この事例は 1 つの組織の経験を反映していますが、根底にある問題はクラウド データ スタックに見られる広範なパターンを反映しています。
BI がコンピューティングのボトルネックになる場合
最新の BI ツールを使用すると、チームはレポート層でロジックを直接定義できます。その柔軟性により、初期の開発をスピードアップできますが、同時にコンピューティングの負荷を最適化されたデータベースから可視化層に移します。
Carousell のエンジニアは、分析用の「Explore」が非常に大規模なデータセットに頻繁に接続されていることを発見しました。アナリティクス リードの Shishir Nehete 氏によると、データセットのサイズは「数百テラバイト」に達することもあり、結合はウェアハウスの上流ではなく BI レイヤー内で動的に実行されました。スケールの限界が露呈するまで、設計は機能しました。
Nehete 氏は、大量の派生結合が実行パスの遅延につながったと説明しています。大規模なトランザクション データセットを取得する「Explore」がオンデマンドで組み立てられたため、コンピューティング負荷が増加し、クエリのレイテンシが高くなりました。チームは、98 パーセンタイルのクエリ時間は平均約 40 秒であり、ビジネス レビューや関係者会議を中断させるのに十分な長さであることを発見しました。この数値は、分析チームから提供されたカルーセルの内部パフォーマンス追跡に基づいています。
パフォーマンスは課題の一部にすぎませんでした。ガバナンスのギャップによりさらなるリスクが生じ、開発者は厳密なテストを行わずに変更を運用モデルに直接プッシュすることができました。これにより、機能の提供には役立ちましたが、脆弱な依存関係が生じました。フィールド定義の小さなエラーにより、下流のダッシュボードに障害が発生する可能性があり、エンジニアは事後対応的な修正を実行する必要があります。
安定性を実験から切り離す
カルーセルのエンジニアは、現在の環境を微調整し続けるのではなく、コンピューティング作業をどこに配置すべきかを再考することを選択しました。大量の変換は上流の BigQuery パイプラインに転送され、データベース エンジンは大規模な結合を実行するように設計されています。 BI レイヤーは、メトリクスの定義とプレゼンテーションに移行しました。
より大きな変化は、責任を 2 つの BI インスタンスに分割することによってもたらされました。 1 つの環境は、事前に集約されたエグゼクティブ ダッシュボードと週次レポート専用でした。データセットは事前に準備されており、生のトランザクション量ではなく、最適化されたテーブルに対してリーダーシップ クエリを実行できるようになりました。
2 番目の環境は、探索的分析のためにオープンなままです。アナリストは、幹部の同僚のワークフローのパフォーマンス低下を招くことなく、詳細なデータセットに参加して新しいロジックをテストできます。
この二重構造は、より広範なクラウド分析原則を反映しています。つまり、高リスクまたは実験的なワークロードを運用レポートから分離します。現在、多くのデータ エンジニアリング チームがウェアハウス ステージング レイヤーやサンドボックス プロジェクトに同様のパターンを適用しています。この分離を BI 層に拡張することで、成長中でも予測可能なパフォーマンスを維持することができます。
インフラストラクチャの一部としてのガバナンス
安定性は、より強力なリリース制御にも依存します。 BI エンジニアの Wei Jie Ng は、コードが運用環境に到達する前にモデリング ルールを検証するツールである Looker CI と Look At Me Sideways (LAMS) を介して、新しい環境で自動チェックがどのように導入されたかを説明します。 「システムは SQL 構文エラーを自動的に検出するようになりました」と Ng 氏は言い、チェックに失敗すると問題が修正されるまでマージがブロックされると付け加えました。
構文の検証を超えて、ガバナンス ルールにより文書化とスキーマの規律が強化されます。各ディメンションにはメタデータが必要であり、接続は承認されたデータベースを指す必要があります。このコントロールにより、人的エラーが削減され、より明確なデータ定義が作成されます。これは、分析ツールが会話型インターフェイスを追加し始める際の重要な基盤です。
カルーセルのエンジニアによると、構造化メタデータは自然言語クエリ用のデータセットを準備します。会話型分析ツールが明確に定義されたモデルを読み取ると、関係を推測するのではなく、ユーザーの意図を一貫した指標にマッピングできます。
パフォーマンスの向上 – 銃撃戦の減少
再設計後、分析チームは目に見える改善が報告されました。内部追跡では、98 パーセンタイルのクエリ時間が 40 秒を超えて 10 秒未満に減少していることが示されています。この変更により、ビジネスレビューの展開方法が変わりました。関係者は、ダッシュボードが壊れているかどうかを尋ねる代わりに、データをライブで評価することに集中できます。同様に重要なことは、エンジニアが継続的なトラブルシューティングから離れることができるということです。
すべての分析環境には固有の制約がありますが、広範な教訓は単純です。BI レイヤーは重いコンピューティング エンジンの役割を果たしてはいけないということです。クラウド データの量が増加するにつれて、プレゼンテーション、変換、実験を分離することで脆弱性が軽減され、レポートの予測可能性が維持されます。
分析スタックを拡張するチームにとって、問題はツールの選択ではなく、アーキテクチャの境界、つまりどのワークロードがウェアハウスに属し、どのワークロードが BI に存在するかを決定することです。
(写真提供: シャッタースピード)
業界リーダーからクラウド コンピューティングについて詳しく知りたいですか? チェックアウト サイバーセキュリティ＆クラウドEXPO アムステルダム、カリフォルニア、ロンドンで開催されます。この総合イベントは、 TechEx 他の主要なテクノロジー イベントと同じ場所で開催されます。 ここ 詳細については。
CloudTech ニュースの提供元は次のとおりです。 テックフォージメディア。今後開催されるその他のエンタープライズ テクノロジー イベントやウェビナーを確認する ここ。
#クラウドでの #のスケーリングについてカルーセルが学んだこと