Observability
通信

RTL GermanyがElastic ObservabilityのFrozenティアでカットオーバー時のダウンタイムなしでリテンションを3倍に増やした方法

  • 3倍
    標準的なデータ保持期間は30日から90日間、一部のデータセットは1年間保持
  • 235 TB
    合計ストレージ容量は同じライセンス範囲で約100TBから増加
  • 18 → 10
    再設計後のハイパーバイザーノードはそれぞれ、より新しいハードウェア上でElasticsearch VMを実行
  • ゼロ
    3か月間の切り替え期間中のダウンタイムとデータロス
  • 30倍
    Frozenティアでの初回クエリのレイテンシ。以降のクエリはすべてHotティアでの速度。

RTL Germanyは、一元化されたデータレイクを再考し、30日間の標準保存から90日間の標準保存に移行し、ノード数をほぼ半分に減らし、データ損失なしで移行を完了しました。

概要

RTL Germanyは全社的にElasticデータレイクを実行しており、これはほぼ10年にわたって、部門を横断するログ、アプリケーションデータ、およびビジネスインテリジェンスの標準プラットフォームへと成長してきました。オンプレミスストレージの容量制限が100TBだったため、標準的なデータ保持期間は約30日間に制限されており、KPIが数か月にわたってどのように変化したかを確認したいチームは作業が制限され、コンプライアンスデータは検索可能なデータレイクとは別のS3バケットに保存せざるを得ない状態でした。プラチナからエンタープライズにアップグレードし、検索可能なスナップショットとFrozenティアを中心に再設計した結果、標準保持期間は3倍の90日間となり、同じライセンス容量で合計容量は235TBに増加し、ハイパーバイザーの物理ノード数は18から10に減少しました。また、切り替え作業全体はダウンタイムとデータ損失ゼロで完了しました。

データレイクがストレージの限界に到達

RTL GermanyのElasticデータレイクは、放送およびメディア事業全体にわたる約10年分の企業全体のログ、アプリケーションデータ、ビジネスインテリジェンスを網羅しています。2024年になると、このデータレイクは限界に達しました。オンプレミスのストレージは約100TBで標準的な保存期間は約30日でしたが、いくつかの部門はKPIの時間経過による変化を追跡するために数か月の履歴が必要であり、内部ポリシーに基づく6か月の保持要件に該当するコンプライアンスデータは、検索可能なPlatform外の別個のS3バケットに保存されていました。プラチナからエンタープライズにアップグレードし、検索可能なスナップショットとFrozenティアを中心に再設計した結果、RTL Germanyの標準保持期間は3倍の90日間となり、同じライセンス容量で合計容量は235TBに増加し、ハイパーバイザーの物理ノード数は18から10に減少しました。また、切り替え作業全体はダウンタイムとデータ損失ゼロで完了しました。

「ビジネスインテリジェンスを担当するチームにとって30日間では足りませんでした。KPIが数か月間でどのように変化したかを確認したかったのですが、ストレージ容量の制限のため、それを提供することができませんでした。今では標準が90日であり、一部のデータセットは1年分となっています。」

– Daniel Moreira Marques氏、ITセキュリティ担当システムエンジニア、RTL Germany

30日間という期間で区切る理由は、単に長い履歴だけでなく、四半期ごとの比較、前年比の季節変動、トレンドラインを信頼できるものにするのに十分な期間の基準値といった、一連の問いに対応するためのものです。RTL GermanyのBIユーザーにとって、このデータレイクには運用データはありましたが、分析に関する質問が始まる段階には及んでいませんでした。標準で90日間の履歴データ、一部の指標では1年間の履歴データが利用できるようになったことで、運用チームがリアルタイムで監視しているデータレイク内で、同じデータに対して、データを別の場所にエクスポートすることなく、こうした種類の質問に答えることができるようになりました。

この成果は、プラットフォームのライフサイクルにおける2つの明確な移行に基づいています。1つは、企業合併によって2つ目のログ記録プラットフォームが加わった後の2023年のElasticへの統合、もう1つは、ライセンス容量を増やすことなくデータ保持期間を3倍に延長できるようにストレージアーキテクチャを再構築したその後のライセンスアップグレードです。

RTL Germanyがここに至るまでの経緯

RTL GermanyのElastic環境は、10年近く前に共有インフラストラクチャツールとしてスタートし、チームごとに全社的なデータレイクへと成長しました。2つの出来事が、現在のプラットフォームの姿を形作りました。

最初の統合は2023年に行われました。新たに加わった企業は、異なるロギングプラットフォームを使用していた。RTL GermanyのElastic環境はすでにオンプレミスで容量に余裕があり、2つのプラットフォームを並行して運用することは経済的にも運用上も意味がありませんでした。従来のログツールからの移行には約5か月かかり、最も大変だったのはコミュニケーション、チームが長年にわたって構築してきたダッシュボードと通知ワークフローの再構築、そしてデータ取り込みパイプラインの再構築でした。

2つ目はストレージの天井と、そこから抜け出す道でした。Elastic{ON} Munichで検索可能なスナップショットとFrozenティアを目にした後、同社チームはストレージの問題に直接対応する設計を見出しました。ライセンス容量を維持しつつ、ロングテールデータをS3をバックアップとしたFrozenストレージに移動し、解放されたHotティアの余裕を利用してデータ保持期間を延長するというものです。チームは本格的に取り組む前に、最も重要な一つの疑問に焦点を当てた概念実証を構築しました。それは、Frozenティアの古いデータに対してクエリを実行した場合、どれくらいの速度で処理できるか、という点です。結果は十分に速かったため、クラスター全体をHot/ColdからHot/Frozenに再設計する決定は簡単でした。

以前：30日間の時間枠を超えるレベルまで成長

再設計以前、RTL Germanyの標準保持期間は、オンプレミスストレージの100TBで約30日に制限されていました。データレイクは健全でしたが、3つの運用上の課題が同時に限界に達していました。

30日に収まらないビジネスインテリジェンスのニーズ。一部の部署では、KPIが時間の経過とともにどのように変化したかを追跡したいと考えていましたが、データレイクでその作業を行うには、30日分の履歴データでは不十分でした。チームは業務に必要なデータを保有していましたが、分析に必要な期間は持ち合わせていませんでした。

コンプライアンスデータはデータレイクの外に存在。社内ポリシーで6ヶ月間の保存が義務付けられているファイアウォールデータは、検索可能なプラットフォームではなく、個別のS3バケットに保存されていました。データは保持されていたものの、調査中にアクセスするには、オブジェクトストレージからデータを取り出して検索可能な場所にロードする必要があり、チームはこれを実際の事件では非常に面倒な作業だと述べていました。

老朽化したハードウェア。クラスターはおよそ5-6年前のサーバーで動作しており、NVMeではなく標準的なSSDを使用していました。チームは、アーキテクチャが変更されるかどうかに関わらず、ハードウェアの刷新が間近に迫っていることを認識していました。

チームの時間は、既存のプラットフォームを上限まで健全に保つことに費やされており、事業の残りの部分のためにプラットフォームができることを拡大することには費やされていませんでした。

再設計：エンタープライズでのHot/Frozen

チームは、検索可能なスナップショットとFrozenティアを有効にするために、プラチナプランからエンタープライズプランにアップグレードし、その後、S3を基盤として、ストレージ構成をHot/ColdからHot/Frozenモデルに再設計しました。

エンドツーエンドのデータフローは従来通りで、Logstashノードは組織全体のデータソースからデータを取り込み、Elasticに書き込みます。Hotインデックスは新しいクラスターのローカルNVMe SSDに保存されています。古いインデックスはFrozenティアに移動し、S3に格納され、クエリ時にローカルキャッシュにオンデマンドで取り込まれます。クラスター横断検索により、切り替え時に古いクラスターと新しいクラスターが連結され、ユーザーは環境を切り替えることなく履歴データにアクセスできます。

性能面でのトレードオフは、許容範囲内であることが判明しました。Frozenティアのインデックスに対する最初のクエリは、関連データがFrozenノードのキャッシュに読み込まれるまで、約30秒かかります。その後は同じデータに対するクエリもHotティアの速度で実行されます。

「最初のクエリには2倍の時間がかかるかもしれませんが、その後は違いはありません。」

– Daniel Moreira Marques氏、ITセキュリティ担当システムエンジニア、RTL Germany

技術的なハイライト

  • 現在のデータに対するHotティアのクエリ速度：KVM上で動作する新しいサーバーでは35 TBのNVMe SSD。
  • 低コストで数ヶ月から数年にわたるデータ保持を実現：S3をバックアップとした200TBのFrozenストレージを検索可能なスナップショット経由で提供。
  • 同じライセンス対象フットプリントで3倍の容量：235TB の合計（35TBのHot + 200TBのFrozen）、ライセンス対象リソースユニットの増加なし。
  • より小さく、より高速なクラスター：新しいハードウェアで1ノードあたりのコア数が増えたため、ハイパーバイザーのフットプリントは物理ノード18件から10件に削減されました。
  • パイプラインの再構築を行わずにワークロードごとに切り替えを実施：Logstashは引き続きインジェストを処理し、移行中はデータソースごとに宛先がリダイレクトされました。
  • 移行中の過去データへのアクセス喪失はなし：クラスター横断検索が常に有効だったため、新しいデータが新しいクラスターに流れる間も、ユーザーは従来のクラスタ上の古いインデックスを引き続き読み取ることができました。
  • 最初のクエリ後の古いデータに対するHotティア速度：初回クエリでFrozenティアのキャッシュ再構築に約30秒かかり、その後のクエリはHotティアの速度で実行されます。

並列のゼロダウンタイムカットオーバー

チームは一気に切り替えるのではなく、既存のクラスターと並行して新しいクラスターを構築し、最大のデータソースから始めて、ワークロードごとに移行していきました。Logstashを介してインジェストが実行されるため、ワークロードの移動は、Logstashノード上の宛先を古いクラスターのマスターから新しいクラスターに変更するだけで済むことが多くなりまいsた。クラスター横断検索により、ユーザーは新しい環境にとどまり、古いクラスター上のデータへの読み取りアクセスが可能だったため、履歴データは常にアクセス可能でした。

チームはまた、可能な限りElasticのメンテナンスされた統合にカスタム取り込みパイプラインを移行する機会を捉えました。これが将来に向けたより良い道であると説明しています。

Elasticサポートにより、ハードウェアの出荷が遅れた際に重複期間が延長され、チームはこれをタイムラインを機能させた要因の1つとして特に指摘しました。

「3か月かけて、部署ごとに移行作業を行いました。ユーザーにとって変更されたのはURLのみで、クラスター横断検索機能が有効になっているため、誰も古いデータへのアクセスを失うことはありませんでした。ダウンタイムもデータ損失もありませんでした。」

– Daniel Moreira Marques氏、ITセキュリティ担当システムエンジニア、RTL Germany

概念実証自体には約2週間かかりました。6～8週間の概念実証（PoC）スケジュールのほとんどは、テストではなく、ハードウェアの調達とプロビジョニングに費やされました。完全なカットオーバーは約3か月間行われ、ダウンタイムやデータの損失なく終了しました。

ユーザー側から見ると：ほとんど何も起こらなかった

データレイクを日常的に利用している部署にとっては、この変更はほとんど気づかれないものでした。ユーザーは、一時的な重複期間中に新しいURLをブックマークに設定し、切り替え後、標準ドメインに戻す必要がありました。クラスター横断検索で新しいクラスターから履歴データにアクセスできる状態が維持されたため、古いデータを見つけるために新しいワークフローを学んだり、2つのシステムをクエリしたりする必要はありませんでした。

コンプライアンス面では、これまで個別のS3バケットに保存されていたデータが、検索可能なデータレイク内に統合されました。ファイアウォールの6か月間の維持はもはやワークフローの問題ではなくなりました。部署がデータ保持期間全体にわたって過去を遡って調べる必要がある場合は、データバンク内の他のデータを調べる場合と同じ方法でクエリを行います。

ビフォーアフター

ディメンション導入前導入後
標準保持ストレージによって最大約30日間に制限標準90日、一部のデータセットは1年間保持
ストレージ容量オンプレミスで約100TB合計235TB：35TBのNVMeHotティアと200TBのS3バックアップFrozenティア
ライセンス済みリソースユニットベースライン同じ基本設定、追加ライセンスなし
ハイパーバイザーノード1810（ノードあたりのコア数が多い新しいハードウェアの場合）
ハイパーバイザーとハードウェア古いクラスター、約5～6年前のサーバー、標準的なSSDリフレッシュされたサーバーでのKVM、NVMe SSDでの使用
コンプライアンスデータ（ファイアウォール、6か月の保存など）データレイク外の別々のS3バケットに保存されているため、検索が遅く、手間がかかる検索可能なデータレイクに存在し、他のインデックスと同様にクエリを実行可能
古いデータに対するクエリ速度レイク外の古いデータにアクセスするにはS3バケットからデータを取得し、検索可能な場所にロードする必要あり最初のFrozenティアのキャッシュのハイドレーションに約30秒、以降のクエリはHotティアの速度で実行
移行リスクモデル該当なし並列クラスターのクラスター横断検索でダウンタイムゼロ、データ損失ゼロ

 

RTL Germanyが学んだこと

このプロジェクトから、際立つ実践的な教訓がいくつか得られました。

可能な限りマネージド統合を活用する。RTL Germanyは長年にわたり独自のデータ取り込みパイプラインを使用していましたが、切り替えの際にその多くをElasticが管理する統合システムに移行しました。チームはこれを、このプロジェクトだけでなく、将来に向けたより良い道筋だと説明しました。

移行をフェイスリフトのように扱う。老朽化したハードウェアの交換、アーキテクチャの近代化、統合の再検討を同時に行うと、いずれかを単独で行う場合と比較して、プロジェクトの価値が倍増しました。

ホスティングモデルを正直に評価する。RTL Germanyの既存のリソースと商業上の考慮事項を考えると、オンプレミスは理にかなっています。クラスターを立ち上げて実行する能力を社内に持たない小規模な組織の場合、チームは運用のオーバーヘッドを回避するためにElasticのSaaSオプションをおすすめします。

難しいのはボリュームで、複雑さではない。一つのクラスターから別のクラスターへのインジェストの切り替えは簡単でした。本当の苦労は、パイプラインの膨大な数と、その単純な変更を通して処理しなければならないデータの規模にありました。

次のステップ

今後の展開は、2つの結果によって決まります。1つ目は、Elastic AI AgentをRTL Germanyの社内大規模言語モデル（LLM）に接続することで、新しいチームメンバーが適切なデータビューを見つけるのにかかる時間を短縮することです。これにより、新しいチームメンバーがプラットフォームを操作し、適切なデータビューをより迅速に見つけられるようになります。これは、従来のオンボーディングにおける最も難しいステップの1つでした。

2つ目は、ライセンスの規模を見直すことなく、さらに多くのアプリケーションログをデータレイクに取り込むことです。これは、すべてのアプリケーションからさらに多くのアプリケーションログをデータレイクに取り込む内部プログラムです。新しいアーキテクチャは、この成長を念頭に置いて意図的に設計されています。S3対応の容量は200TBで、そのストレージを簡単に拡張できるため、チームはライセンスの使用状況を見直すことなくボリュームを取り込む余裕があります。

「今では十分な空き容量があり、S3ストレージを簡単に拡張できるようになったことは、以前にはなかった大きなメリットです。」今後は、さらに多くのデータをオンボーディングしていく予定です。」

– Daniel Moreira Marques氏、ITセキュリティ担当システムエンジニア、RTL Germany

貴社の組織では現在、放送・メディア事業全体を網羅する10年以上前のデータレイクを運用しているわけではないかもしれませんが、数テラバイトのログデータから始める場合でも、235テラバイトのHot/FrozenFrozenアーキテクチャに拡張する場合でも、同じ原則が適用されます。つまり、ライセンスのフットプリントは保持期間に合わせて拡大する必要はありません。

RTL Germanyは、テレビ、ストリーミング、コンテンツ制作にまたがる事業を展開するドイツ最大の放送・メディア企業であるRTL Groupの一員です。

Elastic ObservabilityのFrozenティアがコストを増やさずに保持を延長する方法をご覧いただくか、今すぐ無料トライアルから始めましょう。

関連リソース

トピック：Elastic Observability、Elasticsearch、Logstash、Frozenティア、検索可能なスナップショット、階層型ストレージ、クラスター横断検索、ログ分析、データレイク、コンプライアンスデータ保持、メディアと放送、メディア＆エンターテインメント