可観測性とは、もはやエラーをキャッチしたり、サーバーが稼働しているかどうかをチェックしたりすることだけではありません。最新の分散システムでは、異なる環境で動作し大量のデータを生成する、何千とは言わないまでも何十ものサービス全体の動作を理解することだ。
その複雑さこそが、正しい観測可能性ツールを選ぶことが非常に重要な理由なのだ。間違った決断は、単にスピードを落とすだけではありません。予算を使い果たし、スケール時のパフォーマンスに影響を与え、製品が軌道に乗れば、もはや適合しないシステムに閉じ込めることになりかねない。
優れたアーキテクトであれば誰でも、製品に優れた観測可能性を構築するには、導入の容易さ、（規模が大きくなっても）高いパフォーマンス、そしてアプリケーション自体から独立したシステムが必要だと言うだろう。後から観測可能性ツールを乗り換えることは、苦痛を伴い、コストもかかる。最初からベンダーのロックインを避け、一緒に成長できるものを選ぶのがベストだ。
ステージ3のスケーリング問題
しかし、それは言うは易く行うは難しである。ほとんどのチームは、手遅れになるまで長期的な観測可能性のニーズについて考えません。アカマイのお客様からお聞きしたところによると、本当の問題は、企業が成長し始めた初期段階から始まります。
ステージ1 - オープンソース
これはスピードと低コストを重視するところだ。アイデアを検証し、何かを動かす必要がある。ELK Stackのようなオープンソースのツールは、柔軟性があり、（少なくとも最初のうちは）安価で、MVPをハックするのに適している。
ステージ2 - ブラックボックス
製品が成長している今、システムを稼働させ、安定させ続ける必要がある。そして多くのチームは、Snowflakeのような管理しやすいブラックボックスツールをデフォルトにしている。残念なことに、これらのツールは非常に高価であり、特に使用量が増えるにつれて高くなる。
ステージ3 - 拡張性
トラフィックとデータ量が増えるにつれ、ステージ2で行ったツールの決定が裏目に出始める。ステージ3は、ブラックボックス・ソリューションによる観測可能性の請求が法外に高価になるところである。企業は2つの悪い選択肢から抜け出せなくなる。法外なコストを支払って便利なブラックボックス・ツールを使い続けるか、より安価なものに置き換えるかである。
私たちは、このステージ3の問題は、企業がブラックボックス・ソリューションに移行するという誤った決断を下すという、実はステージ2に端を発していると考えている。その代わりに、企業がオープンソースから移行できるソリューションがあったとしたらどうだろうか。
最高の観測ソリューション
つまり、ここでの真の疑問は、どのソリューションが長期的に企業に最適なサービスを提供できるかということです。アカマイでは、ステージ 2 でブラックボックス・ソリューションに移行した結果、ステージ 3 の問題を経験した多くのお客様の声を聞いてきました。そこで当社は Hydrolix と提携し、これら 2 つの選択肢の中間に位置するソリューションを考案しました：TrafficPeakだ。TrafficPeakは、自動スケーリングと統合されたトラフィック観測機能を備えたクラウドネイティブなソリューションです。シンプルな使い勝手のまま、ユーザーにかなりの制御性を与えながら、マイクロサービス、CDN、エッジネットワークのような大容量環境向けに設計されている。TrafficPeakは、オープンソースのコントロールとSaaSのシンプルさを提供しますが、ブラックボックスツールのコストショックはありません。
ELKスタック（オープンソース）、Snowflake（ブラックボックス）、TrafficPeak（スケーラブル）が、セットアップとインフラ 複雑さ、スケール時のパフォーマンス、コスト管理、カスタマイズ、セキュリティ、メンテナンスに関して、どのように保持されるかを見てみよう。
真っ向勝負：ELK Stack vs Snowflake vs TrafficPeak
1.セットアップとインフラ 複雑さ
ELK Stack はチームに高度なコントロールを与えますが、運用の複雑さを伴います。完全なELKパイプライン（Elasticsearch、Logstash、BeatsまたはAgent、Kibana）を構築するには、思慮深い設定、依存関係の管理、各コンポーネントの組み合わせ方についての深い知識が必要です。ステージ 3 でのスケーリングには、ノード間でのシャーディング、インデックス作成、可用性の管理など、さらなる課題が発生します。動きの速い組織では、これらのインフラ 要件がボトルネックになる可能性があります。
対照的に、Snowflakeは完全に管理され、クラウドネイティブである。インフラ抽象化し、チームはサーバーよりもデータに集中できる。しかし、観測可能性のユースケースでは、ログとメトリクスをSnowflakeにフィードするインジェストパイプラインを構築する必要があり、通常はSnowpipe、Kafka、またはETLフレームワークを経由する。最初のセットアップは簡単なように見えるかもしれませんが、データウェアハウスモデル内で観測可能データをクエリ可能にし、アクション可能にするためのエンジニアリング作業は、待ち時間と複雑さをもたらします。これは強力ではあるが、リアルタイムのオペレーション可視化のために構築されたものではない。
TrafficPeakはシンプルなデプロイを念頭に構築された。クラウドネイティブなソリューションとして、Kubernetes環境にシームレスに統合され、SaaSまたはコンテナ化されたプラットフォームとしてデプロイできる。複雑なキューイングシステムやカスタムインジェストレイヤーは必要ない。データの収集、処理、可視化は同じパイプラインに組み込まれている。数週間ではなく数時間で稼働できるように設計されているため、専用の運用リソースやデータエンジニアリングリソースがないチームでも利用可能です。
2.規模に応じたデータの取り込みとパフォーマンス
ELKでは、大規模で高スループットのインジェストには、慎重なアーキテクチャが必要である。バーストを処理するためにKafkaやその他のキューシステムを導入するのが一般的で、取り込みパイプラインはログの取りこぼしやインデックスの更新失敗を避けるためにチューニングする必要があります。Elasticsearch 自体も、正しくシャード化されサイズ調整されていなければ、高負荷時にボトルネックになる可能性があります。これらの問題は対処できますが、そのためには時間とスキル、そして常に注意を払う必要があります。
Snowflakeはスケールに優れており、これは中核となる強みの1つである。ペタバイト級のデータを取り込んで処理することができ、ストレージとコンピュートを分離しているため、柔軟なスケーリングが可能だ。しかし、インジェストは即時ではない。Observabilityパイプラインでは、データがクエリに利用できるようになる前に、バッファリング、バッチロード、変換が行われることが多い。このためSnowflakeは、分単位以下のレイテンシが重要なリアルタイムのアラートやデバッグには適していない。
TrafficPeakは、大量のリアルタイム環境向けに設計された。TrafficPeakは、自動スケーリング・インジェスト・パイプライン、ビルトイン・バッファリングおよびロード・シェディング・メカニズムを備えており、トラフィックの変化に動的に適応することができます。TrafficPeakは、マイクロサービスのフリート、グローバルCDN、またはエッジデバイスからのストリーミングデータのいずれを実行している場合でも、高スループットのワークロードを処理し、洞察を迅速に表面化するように設計されています。
3.コスト管理
ELKは最初のうちは費用対効果が高く、特にSaaS課金を避けようとするチームにとっては好都合ですが、総所有コストはすぐに膨れ上がる可能性があります。特にログ、メトリクス、トレースがすべてElasticsearchに集中管理されている場合、インフラコストは水平方向にスケールするにつれて上昇します。メンテナンス、チューニング、インシデント対応は、貴重なエンジニアリング時間を消費します。無料のスタックとしてスタートしたものが、隠れたコストセンターになることはよくあることです。
Snowflakeは、異なる種類のコスト課題をもたらす。Snowflakeの従量課金モデルでは、コンピュートとストレージを正確にコントロールすることが可能だが、観測可能なデータは、大量で突発的であることで知られている。特にデータが長期に渡って保持されたり、頻繁にクエリが行われたりする場合、クエリ・コストは急速に上昇する可能性がある。厳密なガバナンスと最適化がなければ、特に観測可能データがアナリティクスのワークロードと混在している場合、コストは予想外に膨れ上がる可能性がある。
TrafficPeakはコスト効率を念頭に置いて一から構築されました。TrafficPeakの価格モデルは、使用量を認識し、コストの暴走を避けるように設計されています。データ圧縮、段階的リテンション、スマートサンプリングなどの機能により、ボリュームと支出をコントロールし、自動スケーリングにより、実際に使用するリソースに対してのみ支払いが行われます。TrafficPeakは、システムの健全性とシステムコストの両方を、どちらかが問題になる前に可視化します。
4.カスタマイズと拡張性
ELKの最大の強みは、その柔軟性にある。カスタムのパイプラインを構築し、フィルターを適用し、スキーマを定義し、特定のユースケースのために高度にカスタマイズされたダッシュボードを作成することができる。そのため強力ですが、複雑でもあります。カスタマイズには、Luceneクエリ、パイプライン構文、インデックスマッピングの理解が必要です。きめ細かなコントロールが必要なチームにとっては、他に類を見ないツールだ。他のチームにとっては、メンテナンスの負担になることもある。
Snowflakeはスキーマファーストであり、SQLを中心に構築されているため、観測可能性をビジネスデータと結合させたいデータアナリストやチームにとって非常に拡張性の高いものとなっている。しかし、ログの解析、トレースのスティッチング、アラートをネイティブにサポートしていない。このため、ライブ観測ワークフローでの使用は制限されます。ダッシュボードやオペレーション・ビューを得るためには、多くの場合、追加のツールを重ねる必要がある。
TrafficPeakは、カスタマイズに対して「十分な」アプローチをとっている。TrafficPeakには、すぐに使えるダッシュボードとワークフローが付属しているだけでなく、API、ラベリング、フィルタリングツールも用意されており、自分たちの環境に合わせてインサイトをカスタマイズすることができる。ログエンリッチメント、タグ付け、データ相関など、重要な部分には拡張性を提供しながらも、価値を生み出すまでの時間を最小限に抑えるように設計されている。
5.セキュリティとコンプライアンス
ELK Stackはセキュリティを提供するが、ターンキーではない。役割ベースのアクセス制御（RBAC）、TLS、監査ロギングはプラグインや設定によって実装できるが、継続的なメンテナンスが必要だ。規制産業にとって、ELKの導入で完全なコンプライアンスを達成するには、勤勉さと規律が要求される。
Snowflakeは、RBAC、行レベルのセキュリティ、静止時および転送時の暗号化、各種コンプライアンス標準のサポートなど、エンタープライズグレードのセキュリティをすぐに利用できます。厳しい要件を満たす必要があり、それらの機能をベンダーに管理してもらいたいチームに適している。
TrafficPeakにはセキュリティが一から組み込まれている。RBAC、監査、データレジデンシーコントロールなどの機能は、アドオンではなく、プラットフォームにネイティブに組み込まれています。TrafficPeakを使えば、金融、医療、政府機関のいずれであっても、バラバラのツールを寄せ集めることなく、最新のコンプライアンス要件を簡単に満たすことができます。
6.メンテナンスとサポート
ELKは、Elastic Cloudやサードパーティプロバイダにお金を払わない限り、完全に自己管理です。つまり、スケーリング、パッチ適用、パフォーマンスチューニング、トラブルシューティングは、あなたのチームが行うことになります。多くのチームにとって、この負担は、特に環境が大きくなるにつれて、インフラ 深い専門知識を持たないチームにとっては維持できなくなります。
Snowflakeはフルマネージドであるため、メンテナンスの負担を完全に取り除くことができる。アップグレード、パッチ適用、スケーリングを舞台裏で処理する。しかし、観測可能性のサポートが主な使用例ではないため、サポートチケットは、ライブシステムのデバッグに最適化されていないワークフローを経由する可能性がある。
TrafficPeakは、リアルタイム・サポートとオプションのSLAを備えたベンダー・マネージド・オブザーバビリティを提供する。TrafficPeakは、観測可能性特有の問題を理解するエンジニアへのアクセスを提供しながら、運用のリフトを最小化するように設計されています。その結果、遠隔測定スタックについて常に心配することなく、出荷と拡張を支援するプラットフォームとなります。
では、どれが最適なのだろうか？
これらの長所と短所を考慮すると、柔軟性と低コストを重視する成長第一段階の企業にとっては、現状維持のオープンソース・ソリューションが最良の選択肢であることに同意します。ステージ1の企業、オンプレミスやハイブリッド環境、あるいはインフラ 経験が豊富なチームを相手にする場合、ELK Stackは優れた選択肢となる。
しかし、ステージ2のほとんどの企業にとって、毎日の観測可能性タスクの突然の複雑さに対処するために、Snowflakeのようなブラックボックス・ソリューションをすぐにデフォルトにするのではなく、簡単で、調整可能で、同時にスケーラブルなものを選択することが、より長い寿命を示すと考える。
私たちは、まさにこの状況のためにTrafficPeakを構築し、それを使って、私たちはステージ3の問題を解決することに成功したかどうかについてのご意見をお待ちしております。
TrafficPeakの実例をご覧になりたい方は、ネイビー・フェデラル・クレジット・ユニオンのケーススタディをご覧ください！
コメント