Amazon Web Services ブログ
【開催報告】AWSで実践！Analytics Modernization ～第4回 今アツい！分析ソリューション編～
2022年11月24日に「AWSで実践！Analytics Modernization ～第4回 今アツい！分析ソリューション編～」を開催しました。今回は、AWSのAnalytics チームより、IT 部門/分析担当者向けに、今日から使える Analytics ソリューションをデモと共にご紹介いたしました。本ブログでは当日の各発表内容を紹介いたします。
OpenSearch で始めるモダンなログ分析とオブザーバビリティ
アマゾンウェブサービスジャパン合同会社 シニア事業開発マネージャー 甲谷 優
本セッションでは、検索エンジンである OpenSearch と、マネージドサービスである Amazon OpenSearch Service で、どのようにモダンなログ分析基盤を構築し、オブザーバビリティを実現するかご紹介しました。
システムを開発、運用する上でのお客様のゴールは、あくまでビジネスの成功となります。それは新規ビジネスの追加かもしれませんし、工数やコストの削減かもしれません。あるいは、ビジネスリスクの低減かもしれません。一方で、そのようなビジネスを支えるシステムには、常に不具合がつきものです。まったく変更をかける必要のないシステムであれば、不具合の修正を続ければいずれ不具合がなくなるかもしれませんが、ビジネスが相対する外部環境は常に変化し続けるため、それに追従するためにシステムの変更は不可欠です。そうなると、システム運用上不具合は避けて通れないところになります。これは Amazon の CTO、Werner Vogels も “Everything fails, all the time” という言葉で表現しております。
一方、システムダウンタイムには大きなコストが伴います。Gartner 社の調査によりますと、年間で 87 時間のシステムダウンタイムが発生しており、1 時間あたり $42,000 のコストが発生していると見積もられています。これには、IT 部門の作業が阻害されているものによるもの、機会損失、SLA 違反によるペナルティや、ブランド力低下によるコストが含まれています。
一方、システムダウンの原因を調査するためにシステムデータの分析が必要となりますが、そのシステムデータは多様化し、増加の一途を辿っています。したがって、従来のようにログファイルのパスを人手で特定し、そのログファイルの該当の箇所を目で確認するという作業は機能しなくなってきています。この状況を、本セッションでも「トラブルシューティングは藪の中から針を探すかのうようだ」と例えさせていただきました。
このような状況を解決できる選択肢の一つに、Amazon OpenSearch Service があります。Amazon OpenSearch Service はマネージドで高セキュリティな、全文検索、ログのリアルタイム検索、モニタリング、分析基盤で、本セッションでご紹介するオブザーバビリティの実現も可能なサービスです。
一方で、OpenSearch は Amazon OpenSearch Service のコアとなっているエンジンであり、Elasticsearch 7.10.2 からフォークした、検索・分析ソリューションです。Apache Lucene ベースの分散検索エンジンだけでなく、可視化・ユーザインタフェースである OpenSearch Dashboards と Open Distro for Elasticsewarch から移行された全ての最新機能を含みます。
またここで、Amazon OpenSearch Service にてログ分析基盤を構築された、いくつかのお客様事例をご紹介させていただきました。
AUTODESK 社では、製造、建築、土木インフラ、CG、エンターテイメント業向けのソフトウェアを提供しています。AUTODESK 社では、日次のログデータは 2 ～ 10 TB に達し、スピーディな問題検出が困難になっていました。そこで、Amazon OpenSearch Service を中心としたログ分析基盤を構築することにより、現在は継続的なソフトウェアプロダクトおよび提供サービスの改善が可能になっています。
Pinterest は、4 億人を超える月間アクティブユーザの画像 SNS です。ログの量は日次で 1.7TB を超えており、当時はサードパーティの Elasticsearch ソリューションを使っておりセキュリティ、コスト、スケール性に課題があったようです。こちらを Amazon OpenSearch Service に移行したことにより、急速に成長するサービスに対応できるスケーラビリティを実現したようです。また、運用のリソースの削減にも成功することができたとのことでした。
ここでさらに、Log Hub という、Amazon OpenSearch Service でログ分析基盤をスムーズに構築するための AWS ソリューションをご紹介させていただきました。
自前でログ分析基盤を構築する上で、ログを Amazon OpenSearch Service に蓄積するための基盤を構築するための学習コストや開発、運用にかかるコスト、またログを OpenSearch Dashboards でどのように可視化するのかが課題になります。
実際に、ログ蓄積のパイプラインに関する技術スタックは幅広く、学習コストが大きくかかります。少なくとも、生成されるログの種類ごと (1st-party アプリケーションログ、3rd-party アプリケーションログ、AWS サービスログ、セキュリティログ) に適切なパイプラインが必要です。またパイプラインを構成する要素としても、Fluentbit や Cloudwatch Agent、Kinesis ファミリーなど多様です。
開発コストも問題になります。たとえば Web サーバである Nginx のログ分析基盤を構築することを考えると、アーキテクチャをデザインし、スクリプトを実装してデプロイするのに少なくとも 2 ～ 3 人日の工数はかかります。
そこでご活用いただけるのが、Log Hub という AWS ソリューションです。Log Hub では、一定の AWS サービス、1st-party/3rd-party アプリケーションのログを対象として、事前にテンプレート化されたログパイプラインを自動で構築します。必要なログの加工、ETL も、コードレスに処理を行うことができます。また AWS サービス、3rd-party アプリケーションを対象として即時利用可能な、予め定義されたダッシュボードを提供します。またこの Log Hub は AWS ソリューションでありながらマネジメントコンソールでサポートされています。
実際に Log Hub で先程ご説明した Nginx のログ分析基盤を構築してみると、わずか 20 分で Nginx のログを可視化することができました。
最後に、オブザーバビリティについてご紹介しました。オブザーバビリティとは、いかに素早く「問題を検出し、事象を調査し、対応策を実施して復旧する」か、システム内部の可観測性を指します。
オブザーバビリティを実現するために、システムのログデータだけではなく、メトリクスデータ、トレースデータを分析し可視化することが必要になります。ここでメトリクスデータとは、予め定めた一定の指標について、一定の期間にわたり測定されたデータで、「何が起きているか」を表すものになります。トレースデータは、分散システムにおけるリクエストの処理経路をエンドツーエンドで追うことのできるデータ、「どこで問題が起きたのか」を表すものです。
これらのデータが揃うことで始めて、メトリクスを継続的にモニタリングし不具合を検知して、不具合検知時にまずはトレースを分析し不具合の発生箇所を特定、その上で不具合発生箇所の不具合発生日時におけるログを分析することで素早く不具合の原因を特定することができます。
また、オブザーバビリティを実現するにはさらに技術スタックが増えますが、本セッションでは OpenSearch プロジェクトの一つのソフトウェアである DataPrepper をご紹介させていただきました。
DataPrepper を活用いただくことで、OpenSearch へのログ、トレースの取込みを簡単に実現していただくことができます。
また、OpenSearch の Observability プラグインを使っていただければ、トレースの可視化手法としてよく使われる Trace-Span details, Service Maps, Trace Groups の 3 つの可視化が容易にできます。Trace-Span details ではリクエストの処理経路をエンドツーエンドで追った際に、どのマイクロサービス、システムコンポーネントで処理が遅延しているかすぐに確認できます。Service Maps ではエラー率や処理の遅延時間といったメトリクスでどのシステムコンポーネントに問題がありそうかすぐに特定することができます。Trace Groups ではシステムコンポーネント、マイクロサービスをグルーピングすることにより、問題の発生箇所をスムーズに特定できます。
最後にこれまでのまとめとして、ログ分析、オブザーバビリティはシステムダウンタイムを短くし、システムのビジネス価値を高めるためのキーであり、それらを実現する手段として Amazon OpenSearch Service は有効である、として本セッションを締めくくらせていただきました。
OpenSearch / Amazon OpenSearch Service 最新アップデート
アマゾンウェブサービスジャパン合同会社 アナリティクスソリューションアーキテクト 榎本 貴之
AWS の榎本からは、検索エンジンである OpenSearch と、マネージドサービスである Amazon OpenSearch Service の最新機能を、デモを交えてご紹介しました。
Amazon OpenSearch Service がバージョン 2.3 をサポートしたこと、OpenSearch も 2.4 をリリースしたことをアナウンスしました。OpenSearch 2.3 がサポートされたことで、Amazon OpenSearch Service でも OpenSearch 2.0 から 2.3 にかけてリリースされた数多くの新機能やパフォーマンス改善を得ることができるようになりました。また、OpenSearch 2.4 では、検索可能なスナップショットや自然言語検索の機能が試験的に追加されたことを解説しました。
数あるアップデートの中でも、OpenSearch が力を入れている機械学習関連のアップデートについて、SageMaker と組み合わせた画像検索やセマンティック検索のソリューションとともに紹介しました。また、OpenSearch 2.4 で試験的に追加された Neural Search の機能について、デモも交えて解説を行いました。Neural Search はこれまでの OpenSearch を活用したベクトル検索を更に進化させた機能で、これまで外部で実行する必要のあったモデルによる処理を OpenSearch 内部で実行することで、ベクトル検索をワンストップで実行することを実現しています。
また、OpenSearch が力を入れているもう一つの分野であるオブザーバビリティについては、トレース分析とログ分析を組み合わせてアプリケーション上の問題を特定する様子を、デモを交えながら紹介しました。
マネージドサービスとしてのアップデートについては、gp3 ボリュームのサポートにより対 gp2 比で EBS のコストを 9.6 % 削減可能な点や、今年アップデートされた周辺サービス Session Manager、WorkSpaces Web に加えて、新規に Amazon OpenSearch Service がサポートした AWS Private Link を使用した VPC 内のドメインへの接続方法について解説を行いました。
また、現状は Amazon OpenSearch Service でサポートされていないものの、運用やコスト効率を改善することができる機能として、コンソールからスナップショットを管理できる Snapshot Manager、オブジェクトストレージにシャードのレプリカを配置可能な Remote Backed Storage の機能を紹介いたしました。
このように、 Amazon OpenSearch Service はエンジンである OpenSearch の成長に合わせ、様々な新機能を次々とリリースしています。動画および資料内では、その他の機能や有用なワークショップについても紹介しておりますので、是非ご覧いただくと共に、紹介した新機能をお試しいただければ幸いです。
進化し続けるRedshift〜Amazon Redshiftで行うデータ分析〜
アマゾンウェブサービスジャパン合同会社 APJ ACE Specialist 松山 航平
本セッションではAmazon Redshift に備わるクエリエディタにまつわる画期的なアップデートについてご紹介したのち、実際にこのエディタを用いた分析作業をデモ形式にて実演させていただきました。
従来より Redshift には SQL を実行するためのエディタが備わっていましたが、これ利用して分析者の方が日々のデータ分析を行うには機能不足な観が否めず、実際お客様からも「どちらかというと管理者向けで、アナリストの業務には向かない」とフィードバックをいただくこともありました。
こうしたエディタにまつわるご要望を背景に、実は Redshift のエディタは最近大きく生まれ変わりました。ここに表形式にて従来のエディタ（遡及的にエディタ v1と呼ばれています）と新しいクエリエディタ v2（以下QEv2）との対比を掲載しておりますが、従来のエディタには備わっていなかった多数の機能が利用できるようになっていることがお分かりになるかと思います。
QEv2 の機能について一つずつ見ていきましょう。まず、当然のことながら QEv2 上にて SQL を実行し、その結果を閲覧することができます。もちろんこの結果を表形式のままcsvやjsonで出力することもできますし、画面右下の Chart というボタンを押下することでエディタ上でクエリ結果を可視化することができます。
こちらがクエリ結果を可視化したものです。これは何らかの他の BI ツールを接続しているものではなく、あくまで Redshift のエディタ上で行われている点に注意してください。分析者の方はエディタさえ利用可能ならば、わざわざデータをローカルに落としたり外部に接続したりすることなくその場でクエリ結果について可視化することができるのです。
後段でも触れますが、可視化にはさまざまなオプションが用意されています。線グラフや棒グラフ、散布図といったベーシックな図はほぼ網羅されており、分析者の方が可視化を行うための選択肢としてはかなり実践的といえるのではないでしょうか。
加えて、QEv2 上では SQL Notebook が利用できます。
聞き間違いではありません。Redshift に備わったエディタである QEv2ではNotebook にて分析を行うことができます。データアナリスト・データサイエンティストの方で Notebook での分析を好む方は多いかと思いますが、通常のエディタに比べ Notebook を用いることによるメリットには想像を凌ぐものがあります。その中で最も大きな要素の一つは、実行したクエリの結果を残しながらインタラクティブな分析ができることにあるでしょう。エディタ上で SQL をひとつひとつ実行するのではなく、Notebook では実行した SQL とその結果、そしてユーザによるコメントを記録しながら順を追ってデータを取り扱うことができます。もちろん Notebook 上でも可視化を行うことが可能です。
百聞は一見に如かず。実際に QEv2 を用いてデータを分析してみましょう。今回テーマとして扱うのは一般に公開されている、アメリカの飛行機国内線についてのデータです。SELECT * してみると、出発地/目的地のほかそのフライトがどのくらい遅れたのか、はたまたキャンセルされたのかといった航空機ならではのデータが入っていることがわかります。
出発遅れのデータが格納されていると言いましたが、その実、飛行機というのはどのくらい遅れるものなのでしょうか？ こうした疑問にすぐに答えてくれるのが可視化です。横軸に遅延時間、縦軸に n 数をとったエリアチャートを作成してみると、上のような図が出力されました。驚きなのが、定刻通り（横軸= 0）に山がある一方で、むしろ分布のピークは定刻の少し前の位置にあることです。こうした小さな驚きは実際のデータ分析にはつきものです、慣れ親しんだ事象についてのデータであってもこのような予想しない特性が見られることは多く、こうした細部を把握しないがために足元を掬われた経験のある分析者の方も多いのではないでしょうか？ 重要なディテールを見逃さないための手段として、データの可視化は手軽でいてかつ非常に強力な方法です。Redshift が QEv2 を用いた即座の可視化を可能にしていることの素朴で大きなメリットについて納得いただけるのではないかと思います。
ここまではごく簡単な可視化を行なってきましたが、もちろんクロス集計のような複数の軸を持つクエリの可視化も可能です。こちらではフライトのあった年と航空会社の2つの軸にてフライト回数をカウントしています。国内線についてのシェアの推移を調べる必要がある場合、おそらくこうした SQL を叩くことになるでしょう。
利用すべき軸が複数存在する場合は、可視化時のオプションとして GUI にて Transforms の項目を指定します。これによって横軸に年、縦軸にフライト数をとったキャリア別の積み上げ図を作成することができました。
最後にこれまでの分析結果を保存しましょう。右上のボタンより、作成した Notebook を保存したりチーム内の他のユーザへ共有することができます。もちろん Export から jupyter Notebook 形式にてダウンロードすることも可能です。
保存した Notebook は左メニューの Notebooks からいつでも参照することができます。仮に誤って Notebook のコードを削除してしまったとしても、保存した場面に復旧することが可能です。
本日は Redshift の QEv2 を用いた実際の分析作業をご紹介させていただきました。QEv2 と、そして本日のご紹介がみなさまのデータ活用の一助となることがあれば嬉しく思います。
サーバーレスで手軽に始めるデータ分析
アマゾンウェブサービスジャパン合同会社 アナリティクスソリューションアーキテクト 平間 大輔
本セッションでは、AWS のサーバーレス分析サービスを活用することで、データ分析を手軽に始めることができるということをデモを交えてご紹介しました。
まず、データ分析を行う理由は、ビジネス課題に対してデータに基づいた意思決定を行うためである、という原則を確認し、その意思決定の流れについて俯瞰しました。
そして、データ分析を行う際の課題と、サーバーレスサービスを活用することによってその課題が解決できることを確認しました。活用できていないデータの活用、新たな分析手法へのチャレンジ、小規模から大規模までどのデータ量にも対応したい、低コストでの運用といった課題を、サーバーレスサービスは効果的に解決することができます。
次に、データの加工 → クエリの実行 → 可視化というデータ分析の一連の流れに対して利用可能な AWS のサーバーレス分析サービスについてご紹介しました。最初は AWS Glue DataBrewです。このサービスは、普段コードを書かないビジネスアナリストやデータサイエンティスト向けに、事前に用意されたデータ整形・加工処理を GUI の画面上で組み合わせることで、ノーコードでデータの前処理を行うことができます。
加工したデータは、次にデータウェアハウスに取り込んで高速にクエリできるようにします。このデータウェアハウスのサービスとして AWS では Amazon Redshiftというサービスを従来から提供してきました。今年からは新たにこのサーバーレス版、Amazon Redshift Serverless が利用可能になっています。利用開始にあたってクラスターのサイジングなどを行う必要なく、これまでの Amazon Redshift と同様の性能・機能を手軽に利用できるようになるサービスです。
高速なクエリが実行できるデータウェアハウスが準備できれば、最後はそのデータウェアハウスに接続して SQL を書かずに高度な可視化を行うビジネスインテリジェンス（BI）のツールが欲しくなります。これを実現する AWS のサーバーレス BI サービスが Amazon QuickSight です。Amazon QuickSight は、月単位のサブスクリプションで手軽に高度な可視化を行うことができるサービスです。画面のデザインを行わない、グラフのドリルダウンや条件変更などだけを行うユーザーは閲覧者と呼ばれ、使わなければ料金不要というより低廉な料金体系が用意されています。このため、大規模な環境へ BI を展開する際にも低コストでの展開が可能です。
最後に、これらのサービスをつなぎ合わせて売上データの分析を行うデモを実施しました。デモでは、まず Glue DataBrew を使って、Amazon S3 上のデータの前処理を行いました。ここでは日付のデータを、他のサービスで利用する際により適切な形式へ変換しました。次に Amazon Redshift Serverless へデータを取り込みました。データ取り込みには、前のセッションでもご覧いただいた、Amazon Redshift 付属の Web アプリケーションである Query Editor v2 を利用し、SQL 文を直接書くことなくテーブル作成とデータロードが行えることをお見せしました。最後に Amazon QuickSight を Amazon Redshift Serverless へ接続し、商品カテゴリー別の売上を簡単にグラフ化できることをお見せしました。
このように、AWS が提供しているサーバーレスな分析サービスを組み合わせることで、IT インフラストラクチャのバックグランドを持たないビジネス部門の方であっても、簡単にデータ分析を始めることができます。ぜひこれらのサービス利用からデータ分析を始めてみてください。
まとめ
AWSで実践！Analytics Modernization セミナーでは、第一回・第二回・第三回の事例祭りに続き、今年ラストとなる第四回で、すぐにお試しいただける分析ソリューションを沢山ご紹介させていただきました。
AWSでは日本のお客様向けに AWS アナリティクスサービスの最新動向を発信しています。AWS サービスにご興味ある場合は無料で個別相談会を開催しております。是非、皆様からのお申込みをお待ちしております（お申込みリンク）
アナリティクス事業本部 ソリューションアーキテクト 平間大輔・ 榎本 貴之
アナリティクス事業本部 事業開発 甲谷 優・伊東 大騎・松山航平・藤沢 夏美