re:Invent 2024: AWSがOpenSearchの新機能と活用事例を紹介
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Enhance performance with observability, security, and log analytics (ANT341)
この動画では、AWSのPrincipal OpenSearch SAのMuhammad Aliが、Amazon OpenSearch Serviceの既存機能と新機能について解説しています。アプリケーションのObservabilityプラットフォームとしてのOpenSearchの活用方法や、CiscoのWebex ConnectプラットフォームがOpenSearchに移行した事例が紹介されています。特に、8つのリージョンで140TBのデータを3ヶ月で移行し、コストを17%削減できた具体的な成果が示されています。また、新しく発表されたOpenSearch UIの機能として、複数のクラスターやコレクションを1つのビューで管理できるWorkspaces、CloudWatch LogsやSecurity Lakeとの統合、SQLやPPL、Natural Language Assistantなどの多様なクエリ言語のサポートについても詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
OpenSearch Serviceを活用したObservabilityプラットフォームの構築
こんにちは、Yvonneさん。セッションにご参加いただき、ありがとうございます。私はMuhammad Aliと申します。AWSのPrincipal OpenSearch SAを務めております。皆様がヘッドフォンを装着されるのをお待ちいたします。皆様、本日のセッションにご参加いただき、ありがとうございます。私はMuhammad Aliと申します。AWSのPrincipal OpenSearch SAとして、約6年間、AWSのお客様のObservabilityとログ分析ソリューションの構築をAmazon OpenSearch Serviceで支援してまいりました。本日は、Amazon OpenSearch Serviceの既存機能と新機能が、アプリケーションの最高のパフォーマンスと信頼性を実現するObservabilityプラットフォームの構築にどのように役立つかについてお話しさせていただきます。CiscoのRama Krishna Bapalleさんにもご参加いただき、Amazon OpenSearch Serviceへの移行についての経験を共有していただきます。また、Joshua Brightが新しく発表された機能についての概要とデモをご紹介いたします。
多くの産業と同様に、スポーツにおいてもパフォーマンスと信頼性は非常に重要です。 100分の1秒という僅かな差が、勝敗を分けることもあります。しかし、それは単に身体能力やスキル、スピードだけの問題ではありません。選手の長期離脱につながるような深刻な怪我を防ぐため、信頼性と選手の負荷管理も同様に重要なのです。現代では、テクノロジーが重要な役割を果たしており、 パフォーマンスと信頼性への期待も高まっています。例えば、7月19日に起きた出来事は、Fortune 500企業に数十億ドルもの損失をもたらした可能性があります。このような障害は避けられません。重要なのは、いかに迅速に立ち直り、優雅に回復できるかということです。障害発生時にどれだけ効果的に対応し、影響を最小限に抑えられるかが、競合他社との差別化要因となるのです。
競争と言えば、東京オリンピックの前に、 私はオーストラリア水泳チーム（Australian Dolphins）と仕事をする機会に恵まれました。そこで、わずか0.1秒を縮めるためにどれほどの努力を重ねているか、また、選手のパフォーマンスを理解し改善の余地を見つけるために、何十万ものデータポイントがどのように分析されているかを学びました。彼らのパフォーマンスマネージャーと協力する中で、 選手のパフォーマンス向上には計測が不可欠だということを学びました。つまり、ガジェットやビデオフィードを通じて、実際の動作中にリアルタイムでデータを収集するのです。コーチたちは、競技中の戦術的優位性を得るために必要な指標や測定値、インサイトを算出する経験を持っています。水泳の場合、ストロークレート、ラップタイム、心拍数などの指標が該当します。
これらの戦術的インサイトは競技中の競争優位性をもたらしますが、選手のパフォーマンスをより戦略的に向上させるためには、様々な大会やレース、合宿で実施される健康・体力テストから得られる幅広いデータを分析する必要があります。これにより、コーチは選手たちが長期間にわたってピークパフォーマンスを維持できるよう、バイオメカニクス、スキル、総合的な体力を向上させるための長期的な戦略プランを立てることができます。アプリケーションを運用し、ピークパフォーマンスを維持する任務を担う場合、 同様の戦略を採用する必要があります。アプリケーションの状態を把握するために、パフォーマンスと健康データを収集するための計測を行う必要があります。そして、アプリケーションの状態を素早く把握するために、レイテンシーやエラー率などの重要なインサイトを自動的に測定する目的に特化したツールとレポートが必要です。障害が発生した場合には、問題をデバッグして解決するためのガイド付きの体験が必要です。しかし、アプリケーションを長期的に改善するためには、インフラストラクチャのあらゆる部分からデータを分析し、特定の状況下でのアプリケーション、ユーザーの行動、インフラストラクチャの動作を理解する必要があります。
これこそが、Observabilityプラットフォームが開発者に約束するものです。つまり、アプリケーションを理解し、障害発生時の根本原因分析を実行するためのツールを提供する能力です。ワークロードのObservabilityは、スケーラビリティやルーズカップリングなどの他の側面と同様に重要です。Observabilityプラットフォームは、 システムの様々な部分からリアルタイムで情報を収集し、予期せぬ、あるいは未知の問題を発見して解決するのに役立ちます。ログ、メトリクス、トレースなどのテレメトリーを収集し、インサイトを生成することで、ビルダーや管理者が問題を迅速に検出、調査、修正できるようサポートします。
Amazon OpenSearch Serviceの特徴と活用事例
OpenSearchはそのようなツールの1つです - リアルタイムの分析と検索機能を備えた純粋なオープンソースの検索・分析スイートで、大量のテレメトリーデータの保存や、アプリケーションのニードル・イン・ザ・ヘイスタック検索、根本原因分析に非常に役立ちます。何十万ものAWSカスタマーがObservabilityプラットフォームとしてOpenSearchを使用しています。これは多くのマシンで実行される分散システムで、ペタバイト規模のデータを分析できます。このObservabilityの重要な機能を実行するために、 信頼性の高い安全なプラットフォームが必要です。それこそがAmazon OpenSearch Serviceが提供するものです。これは、OpenSearchを安全かつ確実にスケールして実行できる完全マネージド型サービスで、お客様はインフラの管理やソフトウェアのインストール、アップグレードの管理ではなく、最も重要なObservabilityデータからの洞察に集中できます。
典型的なOpenSearchソリューションは、ログ分析や一般的な検索において、このように機能します。 検索とログ、トレース、メトリクスを生成するインフラストラクチャがあり、そのデータをREST APIを使用してOpenSearchにロードし、OpenSearch DashboardやREST APIを使用して洞察を得ます。OpenSearchは堅牢なツールのエコシステムです。 テレメトリーデータを収集するObservabilityプラットフォームの構築を非常に簡単にします。データの収集、エンリッチメント、OpenSearchへの保存に使用できるOpenSearch Ingestionサービスがあります。このデータをOpenSearchで実行または保存するには、OpenSearch GitHubからダウンロードしてインスタンス上で実行するか、マネージドサービスを使用するという選択肢があります。また、マネージドサービスのサーバーレスバージョンもあり、洞察や根本原因分析にはOpenSearch Dashboardがあります。
アプリケーションのテレメトリーをどのように計測、測定、分析するかについて説明させていただきます。まずは計測とデータ収集から始めましょう。 アプリケーションはAWSネイティブサービスでも、コンテナやEC2インスタンスで実行されるカスタムアプリケーションでも構いません。これらのアプリケーションからのテレメトリーデータは、エージェントを実行して収集します。エージェントは、アプリケーションの隣で実行される小さなソフトウェアプロセスで、 アプリケーションコンテナの隣のコンテナとして実行され、ログ、トレース、メトリクスを収集してObservabilityプラットフォームに転送します。
最も人気のある収集メカニズムの1つであるOpenTelemetryについて強調しておきたいと思います。これは多くのお客様に利用されており、アプリケーションの計測を支援するベンダー中立のSDKとライブラリのセットです。ログ、メトリクス、トレースをサポートしています。その普及により、業界の多くのObservabilityベンダーがこれをサポートしており、つまり、OpenTelemetryでアプリケーションを計測した後、バックエンドのObservabilityプラットフォームを変更することにしても、アプリケーションの計測の多くはそのまま使用できます。
AWSもまた、OpenTelemetryの独自のディストリビューションを提供しています。これはOpenTelemetryに、AWSサービスからテレメトリーを収集してAWSサービスにプッシュするための追加ライブラリを組み合わせたものです。OpenTelemetryにはCollectorがあり、これがアプリケーションから計測データを収集し、洞察を生成し、そのデータをObservabilityプラットフォームにプッシュバックします。OpenTelemetry CollectorをAmazon OpenSearch Ingestion Serviceに向けることができ、これらのシグナルを収集し、必要に応じてバッファリングします。 また、それらのシグナルをエンリッチメントし、OpenSearchに保存し直すこともできます。
OpenSearchを使用することで、長期間にわたってデータを保持することができるようになりました。 Amazon OpenSearch Serviceは階層型ストレージを提供しており、即時検索が可能なHotストレージに通常5〜15日分のデータを保存できます。より長期間のデータについては、Ultra-warm機能を使用できます。リアルタイムでの参照があまり必要ないログについては、Amazon S3に保存し、S3のZero機能を使用してオンデマンドでデータを取得することができます。
最後に、このデータを扱うための専用ツールとして、ガイド付きのユーザーエクスペリエンスがあります。これがOpenSearchダッシュボードで、後ほど詳しくご説明します。スポーツの世界では、コーチやパフォーマンス管理スタッフは、何を測定し、どのように解釈するかを正確に把握しており、その解釈は選手のパフォーマンス向上プランへと反映されます。では、私たちのアプリケーションではどのように実現すればよいのでしょうか？これは開発者が直面する一般的な課題です。大量のテレメトリーデータを扱うことは、適切なガイダンスがないと困難です。正しい洞察を得るのは本当に難しく、時間がかかることがあります。私たちは異なるアプリケーションからデータを収集して相関関係を分析しますが、生データを扱うのは非常に困難です。しかし、スポーツのコーチが何を測定し、どのようにこれらのシグナルを統合するかを知っているように、OpenSearchダッシュボードにもそのようなガイド付きの体験があります。
OpenSearch Dashboardsの機能と最新アップデート
OpenSearchダッシュボードは、観測可能なデータを最大限に活用するための専用ユーザーエクスペリエンスです。ログやトレースデータを使用して根本原因分析を実行するために必要な洞察を提供するウィジェットが事前に設定されています。また、ドラッグアンドドロップ機能を使用して新しいビジュアルを作成することもできます。ビジュアルに満足したら、それをアプリケーションに埋め込むことができます。マルチテナント対応なので、複数のチームに異なるログを割り当て、異なるテナントを作成し、それぞれが担当するデータを確認することができます。
ビジュアルは、実際に見ている時は非常に便利ですが、不在時にはObservabilityプラットフォームにアプリケーションのテレメトリーを監視してもらいたいものです。OpenSearchには堅牢な監視と異常検知機能があり、データを監視し、障害が発生した場合やデータに異常なパターンを検出した場合にアラートを送信します。この異常検知器を設定するために機械学習の経験は必要ありません。単に作成するだけで、過去のデータを分析し、新しく入ってくるデータに応じて自動的に調整されます。
また、フィルターや特定のルールベースの条件に基づいてアラートを設定できるアラート機能も利用できます。これは特定の状況で自分に通知する一般的な方法です。これらの通知は様々なチャネルを通じて受け取ることができます。Slackチャンネルにメッセージを送信したり、PagerDutyやOpsGenieなどのインシデント管理ツールを使用してモバイルデバイスにルーティングしたりできます。通常、開発者が素早く調査を開始できるよう、ダッシュボードへのリンクが含まれています。
現在のアプリケーション開発において、Microservicesが最も一般的なアーキテクチャとなっています。Microservicesを扱う際には、多くの要素が動いており、それらの要素やネットワーク上でやり取りするサービス間の通信を調査するのは困難です。これを簡単にするために、Tracesと呼ばれるものを使用します。Tracesは異なるサービス間の通信を捕捉し、あるサービスが別のサービスを呼び出した際に何が起きたのか、その呼び出しが成功したのか、エラーだったのか、どのくらい時間がかかったのか、またはどのくらいの頻度で発生したのかなどを把握することができます。
OpenTelemetryはTracesをサポートしており、それらを収集してOpenSearchに送信することができます。OpenSearch Dashboardは、そのデータを分析するための視覚的なツールを提供します。Service Mapsを使用すると、アプリケーション内のサービスで高いレイテンシーやエラー率などの問題が発生している領域を一目で確認できます。また、Trace Group Metricsでは、関連するTracesを1つのウィジェットにグループ化することで、例えば決済機能など、アプリケーションの特定の機能に問題が発生していないかを確認できます。
これらのグループを詳しく調べると、Trace Span Detailウィジェットで個々のTraceを確認でき、すべての呼び出しの詳細を把握することができます。これにより、サービス間の通信で問題が発生している箇所を正確に特定できます。調査すべき箇所が特定できたら、ログを確認して分析を始めることができます。 しかし、ログを扱う際には数分で何千行ものログが生成される可能性があります。開発者はフィルタリングできますが、一般的なログパターンを最初から知っておくことを好みます。OpenSearchにはML搭載のロググループ化機能があり、開発者が一般的なイベントを素早く発見できるようサポートします。問題が発生すると、グループ化できる繰り返しのエラーが表示され、その分布を観察することができます。
注目すべきログラインを見つけたら、OpenSearchにその前後で発生したイベントを表示するよう指示することで、その特定の問題の原因と結果を確認することができます。アプリケーションのデバッグ時には、 データのフィルタリング、ソート、統計の計算が必要です。そのために、OpenSearchには強力なPiped Processing Language（PPL）があり、アプリケーションのテレメトリーに対してメトリクスやKPIを計算しフィルタリングすることができます。一連のコマンドを順序立てて実行することで、各ステップが目的の結果に近づいていくような形で、望む結果を構築することができます。
PPLを知っているのは素晴らしいことですが、Generative AIを使って生成できるとさらに良いでしょう。OpenSearch Dashboardには自然言語クエリ機能があり、ログに対して会話形式でクエリを行うことができます。英語でプロンプトを入力すると、OpenSearchがPPLを生成してくれます。OpenSearchと対話を始め、目的のログラインが見つかるまでプロンプトを調整することができます。 Observabilityはアプリケーションだけでなく、セキュリティにおいても重要です。むしろアプリケーション以上に重要かもしれません。多くの顧客がOpenSearch Serviceを使用してセキュリティログを監視しており、2,200以上のルールが組み込まれた標準のセキュリティ分析機能を利用できます。
セキュリティログを扱う際には、アクセスパターン、無効なログイン、セキュリティ脅威などを探します。これらのルールによってこうしたイベントを発見でき、自動的に相関付けられます。トレース機能やウィジェットと同様に、OpenSearch Security Analyticsプラグインには、これらの発見事項を扱うための専用ウィジェットが用意されています。セキュリティ脅威や攻撃の全体像を把握することができます。Security Analyticsは、セキュリティログや機密性の高いログを扱う際にAWSで人気のあるプラグインです。機密性の高いログと言えば、これらのアプリケーションやセキュリティログは、安全で保護された場所に保存したいものです。セキュリティはAWSの最優先事項であり、Amazon OpenSearch Serviceはその堅牢なセキュリティ機能でこのコミットメントを体現しています。
堅牢なセキュリティ機能を提供し、データを安全に暗号化して保管できます。SAMLやIAMで認証を設定し、きめ細かなアクセス制御を使用して、開発者が閲覧できるログを制限することができます。また、HIPAAやFedRAMPなどのコンプライアンス認証にも標準で対応しており、これもAmazon OpenSearch Serviceを検討する理由の一つとなっています。
CiscoのWebex ConnectにおけるAmazon OpenSearch Service導入事例
ここで、Rama Krishna Balapalle氏をステージにお招きして、Webex Connectと呼ばれる通信プラットフォームサービスの可観測性を実現するためにAmazon OpenSearch Serviceへ移行した journey についてお話しいただきます。皆さんは、アカウント通知や支払い通知、OTPメッセージなど、企業からのメッセージを受け取っていますよね？ほぼ全員が受け取っているはずです。企業はCPaaSと呼ばれるプラットフォームを使用して、顧客とのやり取りを管理しています。これらのCPaaSプラットフォームは、SMS、WhatsApp、Facebook Messenger、Twitter DMなど、複数のメッセージングチャネルをサポートし、メッセージングチャネルとビジネスシステムを連携させて顧客体験を構築するためのオーケストレーションエンジンを備えています。
Webex ConnectはCiscoが提供するエンタープライズCPaaSで、私はWebex Connect製品群のエンジニアリングを統括しています。Webex ConnectはSMS、RCS、MMSなどの通信キャリアチャネルや、WhatsApp、Facebook Messenger、Twitter DM、さらに今後登場するApple Business MessagingなどのOTTチャネルをサポートしています。私たちは常に新しいチャネルを追加しています。このCPaaSプラットフォームの重要な要素の一つが、ビジネスが顧客体験をオーケストレーションするのを支援するワークフローオーケストレーションエンジンです。顧客体験のオーケストレーションとは、顧客にリーチできるメッセージングチャネルと、ビジネス情報を含む企業が投資してきたエンタープライズシステムの両方を連携させて顧客体験を推進することです。このオーケストレーションジャーニーは、ドラッグアンドドロップのフロービルダーツールで、ノーコード・ローコードプラットフォームとして、フロービルダーが顧客体験を作成し、実装できます。
Webex Connectは世界中の複数のリージョン、具体的には8つのリージョンにデプロイされており、毎月50億以上のワークフロー実行と10億以上のさまざまなチャネルを通じたメッセージングを処理しています。本日のセッションでは、特定の課題とその解決方法についてお話しします。先ほど申し上げたように、ワークフローエンジンはCPaaSの中核部分です。ワークフローエンジンには、メッセージングAPI、ビジネスシステムなど多くの要素があり、これらのフローは非常に複雑になる可能性があります。フロー開発者は、フローのパフォーマンス、ノード実行中の動作、ノード実行後の動作、変数の状態など、広範な洞察を必要とします。
開発者は何が起きているのかを完全にコントロールする必要があり、そのためには標準で広範なロギングが必要です。広範なロギングと言いましても、実行される何十億ものフローがあるため、非常に高いスループットが求められます。30日間のデータ保持ポリシーがあるため、これがデータ量の増加につながります。このプラットフォームに蓄積された高スループットで大容量のデータは、セルフデバッグログインターフェースとして公開され、ワークフロー開発者はプラットフォームにログインしてトランザクションIDを入力し、トランザクションの各ステップを確認できます。つまり、これらのログはほぼリアルタイムである必要があります。課題は、広範なロギング、高スループット、そしてほぼリアルタイムのアクセスです。また、これらのログすべてがインサイトを提供できる他のユースケースもあるため、モニタリングとデータの可視化・検索を素早く行える方法が必要です。データを効果的に可視化し検索するソリューションが必要なのです。
フローとプラットフォームの両方で利用可能なフローとインサイトを理解するために、問題提起を見てみると、高速な書き込みと30日間の保持ポリシーを備えたソリューションが必要です。なぜなら、30日間は膨大なデータ量を意味するからです。デバッグログデータの30日間など、保持ポリシーの異なる様々なデータクラスがあります。データの削除が毎日頻繁に発生する際、プラットフォームの問題やデータの入出力レートに影響を与えてはいけません。
私たちの journey は2015年、Webex Connect の最初のベータ版がリリースされた時に始まりました。当初はスケールしないことを承知で MySQL からスタートしました。すぐに、水平スケーリングをサポートし、必要な多くの機能を提供できる Elasticsearch をプラットフォームとして特定しました。Elasticsearch の採用を開始し、2016年に本番稼働を開始しました。セルフホスト型のオープンソース Elasticsearch システムを選択しましたが、独自の課題に直面しました。プラットフォームはすべての機能をサポートしていましたが、オープンソースではすぐに使える認証機能がなかったため、ラッパーを構築して認証を管理する必要がありました。さらに、アップグレードは慎重に計画する必要がありました。時間とともに、技術を効果的に活用するよりも、Elasticsearch クラスターの管理に重点を置くようになってしまいました。
運用上のオーバーヘッド、構築・維持が必要なセキュリティ管理レイヤー、そしてアップグレードパスの慎重な管理が必要でした。2018年頃、運用と管理の作業を外部に委託し、技術の運用よりも活用に重点を置くことを検討しました。Elastic.io のマネージドサービスを試し、一部のワークロードを移行しましたが、何らかの理由でそのプロジェクトは中断され、セルフホスティングを継続することになりました。2021年に、状況が変化し、Elastic.io がライセンスモデルを変更しました。同時に、OpenSearch が9月に初回リリースとして発表されました。OpenSearch が発表された時、私たちのニーズに完璧にマッチしていました：ライセンスコストなし、オープンソース、AWS による完全マネージド、そしてエンタープライズサポートです。
すぐにチームを編成して POC を実施し、アプリケーションとの互換性を検証しました。3〜4ヶ月以内に、ダウンタイムなしで全クラスターを OpenSearch に移行しました。移行後も、OpenSearch が Graviton プロセッサーのサポートや Hot-warm-cold ストレージのサポートなど、新機能をリリースするたびにアップグレードを続けてきました。これらの機能を実装して恩恵を受け続けており、すべてのアップグレードはシームレスで、運用上のオーバーヘッドも最小限で済んでいます。
OpenSearch UIの新機能：Workspacesとデータソース統合
アーキテクチャレベルでは、シンプルな構成となっています。マイクロサービスにはエージェントが組み込まれており、メッセージログをバッファとして機能するKafkaにプッシュします。カスタムログシッパーがこれらのログに付加価値を加えてからOpenSearchに送信します。OpenSearchからは、データの抽出と表示のための複数のユースケースがあります。エンドユーザーに直接表示されるプラットフォームダッシュボード、ノード間のユーザーの動きを追跡してよく使用されるノードやフローの遅延を特定するOpenSearchプラットフォーム上のフロー分析などです。また、ノードの実行詳細を含むプラットフォームの使用状況やシステムメトリクスを表示する社内向けダッシュボードもあります。このデータには価値のある洞察が含まれているため、これらを活用した監視プラットフォームを構築しました。
得られた効果は大きく、コストを17%削減することができ、8つのリージョンにまたがる10以上のクラスターを3ヶ月以内に移行することに成功し、約140 TBのデータを処理しました。
現在では、より少ない労力で環境を管理できるようになっています。プラットフォームの成長と機能強化に伴い、Hot-Warm-Coldデータストレージを採用し、Gravitonインスタンスのダウンタイムなしの更新と移行を実現しました。また、AWS Enterprise Supportのサポートを受けることで、私たちのニーズに最適なインデックスとローリングパターンの最適化を行い、メモリ設定のファインチューニングも実施することができました。
移行の実績は次の通りです：先ほど述べた通り、8つのリージョンで140 TBのデータを扱いました。すべてを3ヶ月で完了することができました。3ヶ月というと長く感じるかもしれませんが、お客様への通知に2週間前の事前告知が必要でした。また、既に決まっていたスケジュールに合わせる必要があったため、3ヶ月というのは全体の暦上の期間であり、実際の作業に要した時間ではありません。
今後の展開についてですが、現在は適切なサイジングが確認できており、チームと相談しながらReserved Instanceの活用を検討しています。また、最新のエンジンへのアップグレードも継続的に行っていきます。現在、8～10のクラスターが存在し、複数のKibanaエンドポイントが存在している状況です。これらのエンドポイントを共通のゲートウェイに統合できないか検討しており、すべてのクラスターのデータにアクセスできる統一されたダッシュボードと可視化システムの実現を目指しています。
簡単なアンケートを取らせていただきたいと思います。RKが説明したような、複数のクラスターやコレクションを運用しているような複雑な環境を運用している方は何人いらっしゃいますか？かなりの数の方がいらっしゃいますね - 実は、これほど多くの手が挙がるとは思っていませんでした。 私たちが見ているところでは、大規模なワークロードを持つお客様が、運用分析のニーズに対してますますAmazon OpenSearch Serviceを選択するようになってきています。 しかし、データが増え続けるにつれて、ダッシュボードの管理が難しくなってきています。先ほど手を挙げていただいた方々には共感していただけると思いますが、成長してクラスターの数が増えていくと、誰もが独自のダッシュボードを持つような状況になります。
私たちはこれを統合して、より使いやすくしたいと考えました。数週間前、OpenSearch UIをリリースしました。これは、1つのビューから複数のドメインやコレクションに接続できる新しいダッシュボードアプリケーションです。 特定のアカウントやログタイプに関連するダッシュボードやクエリがまとめられているため、ダッシュボードを分けることにはメリットがあります。ダッシュボードを1つのアプリケーションに統合する際の整理を支援するため、最近Workspacesをリリースしました。Workspacesを使用すると、チームのすべてのダッシュボードを、必要なものを簡単に見つけられるように整理することができます。例として、私は以前、複数のサービスを担当するアプリケーションチームで働いていました。
私たちは以前、Wikiページを使って、アプリケーションオーナーとして、すべてのダッシュボード、アラート、重要なクエリを整理していました。同様に、SREと協働する際には、彼らは私たちのWikiページを参照して、キュレーションされたダッシュボードやクエリにアクセスし、アプリケーションの詳細な分析を簡単に行えるようにしていました。
Workspacesをリリースしましたが、OpenSearchエクスペリエンスの刷新はそれだけではありません。ルック＆フィールも更新し、より密度の高いビューにするとともに、より軽く、より明るくしました - 言葉遊びのつもりです。データにすばやくアクセスし、Discoverの重要な領域に焦点を当てることができます。Workspacesをリリースしたことで、新しい左側のペインができました。Workspace自体の左側のペインと、選択されたフィールドと利用可能なフィールドを表示する別の左側のペインがあり、これらを統合して閉じることで、クエリバーと結果スキャナーのビューだけを表示することができます。
サービスに移行してくるお客様は様々なバックグラウンドを持っているため、全員がDQL（Dashboard Query Language）やLuceneを好むわけではないことを私たちは知っています。データベースの世界から来てSQLを好む人もいれば、UNIX世界から来てパイプ言語を好む人もいます。これらの言語は以前からツール全体に存在していました - SQLクエリやPPLクエリを実行できるQuery Workbenchがあります。以前はPPLはObservable内のログ分析ビューでのみ使用可能でしたが、今では好みの言語を簡単に使用できるよう、すべてをDiscoverに統合しています。 Amazon OpenSearch Serviceを数年間使用している方々から、クエリの構築を支援するオートコンプリート機能の追加要望を長年いただいていました。Discover内の全ての言語でオートコンプリートを含めることを、大変嬉しく発表させていただきます。DQL、SQL、PPLのいずれであっても、クエリの作成をサポートし、さらにAliが先ほど言及したNatural Language Assistantも、Discoverに追加しています。
新しいOpenSearch UIのデモンストレーション
これまで私たちが話してきたのは、この新しいOpenSearch UIを使って、エコシステム内のさまざまなクラスターやコレクションにどのように接続できるかということでした。Discoverにある既存のデータピッカーをアップグレードして、ローカルに設定されたインデックスパターンだけでなく、リモートクラスターやコレクション上のインデックスも扱えるようにする必要がありました。もちろん、Amazon S3でDirect Queryを使用している方々のためのサポートも用意しています。 ここまでは、主にOpenSearchエコシステムのクラスターとコレクションに焦点を当ててきました。 しかし、分析したいデータはOpenSearch以外にも存在することを私たちは知っています。リアルタイムやニアリアルタイムの分析には使用していない二次的なデータも存在しているのです。
ちょうど1年前の今頃、私はここでAmazon S3とのDirect Query統合の新機能を発表しました。お客様との対話を通じて、観測可能なデータやログ分析のデータが存在する場所はAmazon S3だけではないということがわかりました。エコシステム内には他のサービスにもデータが存在しており、それらをOpenSearchに完全にコピーすることなく、直接アクセスする方法が欲しいとのことでした。 昨日のKeynoteやInnovation Talkに参加された方々は、NandiniがAmazon CloudWatch LogsとAmazon Security Lakeとの新しい統合について発表したのをご存知でしょう。
データは必ずしも完璧ではなく、常にOpenSearchにあるわけではないということを私たちは認識しています。私たちが実現したいのは、分析を行うために一回限りの取り込みパイプラインを作成したり、異なるツール間を行き来したりする必要のない統合されたビューを作ることです。今、私たちはOpenSearchの豊富な分析機能を、データが存在する場所に持っていこうとしています。 そろそろデモの時間だと思います。録画したものを用意していますが、その中には必ず犬が出てくることをお約束します。このデモでは、AWSコンソールから新しいCloudWatch Logsデータソースを作成する方法をお見せします。その後、OpenSearch UIに移動してWorkspaceを作成し、OpenSearchリソースだけでなくCloudWatch Logsリソースにまたがるデータの分析方法をご紹介します。
では始めましょう。まず、OpenSearchコンソールに移動します。コンソールが読み込まれると、左側に「Central Management」という新しいセクションが表示されます。このCentral Managementセクション内に、2つの新しいセクションがあります。 1つは「Connected Data Sources」で、もう1つは「OpenSearch UI」です。 Connected Data Sourcesをクリックしてみましょう。ここから新しいデータソースを作成できます。 このデモではCloudWatch Logsに焦点を当てますが、Amazon Security Lake用のコネクターを設定する場合も、非常によく似た手順になります。
データソースを作成し、「reinvent_demo」という名前を付けます。IAMパーミッションセクションでは、CloudWatch LogsにアクセスするためのロールにいくつかのIAMパーミッションが必要です。OpenSearch UI内でロググループを表示できるように、CloudWatch Logs内の既存のロググループを記述できる必要があります。それらのログをクエリできる必要があり、さらにOpenSearch固有のサービスプリンシパルを作成する必要があります。完全なIAMパーミッションの詳細については、ドキュメントを参照してください。簡単な方法として、新しいロールを作成しましょう。新しいロールに「reinvent-demo-role」という名前を付けます。ロググループへのアクセス提供に関しては、CloudWatch Logs内のすべてのロググループへのアクセスをこのデータソースに提供するか、Observabilityの用途が非常に限定的な場合は、特定のグループを選択することもできます。
これにより、特定のロググループを複数選択することができます。ご覧のように、Petサイトが立ち上がっており、これが後ほど確認する観測データの一部となります。
では、すべてのロググループの権限を付与して、nextを選択していきましょう。 ここでは、この新しい統合に必要なセットアップとコンポーネントについて説明しています。まず、CloudWatch Logsとロググループが必要です。次に、バックグラウンドでAmazon OpenSearch Serverlessコレクションを起動します。これが中継役として機能します。そして最後に、OpenSearch UIが必要になります。
私は後で見つけやすくするために、名前をつけることにしています。そこで、コレクション名をreinvent demo nameとしましょう。 すでにOpenSearch UIアプリケーションをお持ちの方は、既存のものを指定することができます。 今回は新しく作成して、OpenSearch UI reinventと名付けることにします。 そして、Workspaceも作成します。Workspaceは、クエリやダッシュボードなど、すべてのダッシュボードオブジェクトを調整・整理するために使用されます。ここではreinvent demo workspaceという名前で作成します。
これが確認ページで、すべての詳細をレビューします。接続の詳細はすべて問題なさそうですね。では、始めましょう。これには数分かかりますが、このデモではその時間がないので、ダッシュボードに直接移動しましょう。今、OpenSearch UIの中にいます。ホーム画面では、異なるWorkspaceから選択することができます。新しいWorkspaceを作成しましょう。今回はObservabilityについて話しているので、Observableのものを作成します。
異なるタイプのWorkspaceがある理由は、ユースケースごとのニーズを区別するためです。例えば、Observabilityの側面では、アラート、ダッシュボード、トレース分析、メトリクスなど、Security Analyticsのユースケースとは異なる一般的な機能があります。Security Analyticsでは、セキュリティ分析検出器があります。そして、検索に関しては、さらに別のユースケースセットが存在します。
それでは、Workspaceを作成してみましょう。「demo land」と名付けることにします。ここで、データソースを関連付けることができます。これらはOpenSearchのデータソースです。ご覧の通り、1つのObservabilityがAOSS上で動作しているカスタムインスタンスで、そしてreinvent24 OpenTelemetryデモがAOSドメイン上で動作しています。これらを関連付けて、次にDirect Queryデータソースを関連付けていきます。すでにライブログ用のものが設定されています。では、このデータソースとWorkspaceを作成しましょう。Workspaceの大きな利点の1つは共有できることです。データやアセットを整理できるだけでなく、チームと共有することができます。特定のアプリケーションに焦点を当てて運用しているアプリケーションチームがある場合、その特定の目的のためのWorkspaceを作成して、同僚と共有することができます。
SREとして幅広い責任を持っている場合は、その広範な範囲のWorkspaceを作成するか、より小さな単位に分割することができます。これらのWorkspaceをどのように使用するかは完全にあなた次第で、IAMユーザーやロールと共有することもできます。
早速中を見ていきましょう。すでにdemo landのコンテキスト内にいるので、新しいDiscoverを見るために、こちらのDiscoverに移動します。ここでは、従来通りのDiscoverの機能が見られますが、より軽量化され、明るい外観になっています。重要なものに集中できるように、統合や折りたたみができるようになりました。Workspace自体の左ナビゲーションを折りたたんでみましょう。
Discoverに入ると、データを選択する機能があります。先ほどの会話で触れたように、データピッカーをアップグレードしました。インデックスパターンやインデックスなどの従来の要素だけでなく、Amazon S3、CloudWatch Logs、Security Lakeなどの追加のデータソースタイプもサポートするようになりました。IDAの簡単なビューを見てみましょう。これはクラスターを検索しています。今日のObservableログを見てみましょう。SQLから始めます。データは、OpenSearchインデックスで慣れ親しんだ方法で非常に素早く表示されます。
次にPPLに移ることができます。headステートメントを移動すると、PPLの表示もすぐに現れます。最も使い慣れたクエリ言語を使って、興味のあるデータを検索することができます。では、CloudWatch Logsに移りましょう。以前に作成した1つのObservableデータソースから選択します。ペットアプリケーションについて触れましたが - これらの犬たちを見てください。このペットアプリケーションはバックグラウンドで動作していて、犬を譲渡したりクレジットカードを扱ったりする素晴らしい機能を備えています。
Lambda に対してクエリを実行する簡単な例をお見せしましょう。新しい SQL で更新して、 に進みましょう。すぐに、そのロググループ内のサンプルデータの取得を試みます。データが読み込まれているのが見えますね。14秒以内に完了しました。 もちろん、OpenSearch クラスターやコレクション内に存在するデータは非常に速く返されます。CloudWatch Logs や Amazon S3、Security Lake などの外部データソースに接続する場合は、データが返されるまでに少し時間がかかります。
本日お話しした新しいサービスについて、様々な機能をご紹介してきました。新しいデータソースについて説明し、新しい Workspace について説明し、新しいユーザーインターフェースをお見せしました。そして、OpenSearch クラスターやコレクション内に存在するデータでも、この場合の CloudWatch Logs のような外部データソースでも、このような新しいデータビューをご覧いただきました。
まとめと今後の展望
素晴らしいですね。このデモが参考になり、興味深いものであったことを願っています。ただ、何か言い忘れていることがある気がします。私たちは、クラスターやコレクションへの接続が可能な様々なデータソースについて見てきました。Workspace について話し、言語を統合した新しいクエリインターフェースについても説明しました。
Dashboard アプリケーションは無料です。Dashboard アプリケーションの実行に追加コストはかかりませんし、追加のライセンスも必要ありません。CloudWatch Logs や Amazon Security Lake のデータへの接続に興味をお持ちの方々のために、現在無料トライアルを実施しています。ぜひ POC を作成して試してみてください。皆様からのフィードバックをお待ちしています。
OpenSearch Service におけるオブザーバビリティの詳細については、こちらの QR コードをご覧ください。先ほど発表した新しい OpenSearch UI についてもっと知りたい方は、もう一つの QR コードがあります。また、Direct Query に興味がある方は、そちらをご覧ください。私たちはこの後すぐ外におりますので、ご質問がありましたら、ぜひお声がけください。
最後に、AWSの社員として、アンケートへのご記入をお願いするのを忘れてはいけませんね。皆様からのフィードバックを大切にしており、より良いサービスを提供するために、本当に一つ一つ目を通させていただいています。 本日は皆様、ご参加いただき誠にありがとうございました。皆様とお話しできて大変光栄でした。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion