AWS Control Towerの活用で
変革を実現
金融業界におけるクラウド移行とビジネスの迅速な対応能力向上
はじめに
クラウド活用推進担当として、オブザーバビリティを中心とした領域のサービス化を担当しています。
今回、「オブザーバビリティとは？」というテーマでの第2回目として、もう少し具体的な導入に関してのお話をさせていただこうと思います。
目次
テレメトリーデータについて
前回、AWSのオブザーバビリティ成熟度モデルについてや独自の診断チェックシートについて、説明させてもらいました。では、オブザーバビリティ導入としてまず何から始めればいいのでしょうか。
まず一番最初に行うべきことは「テレメトリーデータ」の収集です。システムやアプリケーションの動作状況をリアルタイムでモニタリング・収集するためのデータのことを「テレメトリーデータ」と呼びます。
オブザーバビリティにおける「テレメトリーデータ」として、代表的なものを紹介します。
ログ
システムやアプリケーションの動作履歴など、システムやアプリケーションの内部状態を詳細に把握し、問題の早期検出や迅速なトラブルシューティングを行うため、ログを収集します。
前回のように「医療」に例えると、ログは「カルテ・診療記録」であり、「患者に何が起こったかの詳細な記録」が集まったものとなります。
メトリクス
システムやアプリケーションのパフォーマンスや状態を定量的に測定するための指標であり、CPU 使用率、メモリ使用量、ディスクI/O などのパフォーマンス指標が挙げられます。
システムやアプリケーションの状態を定量的に把握し、問題の早期検出やパフォーマンスの最適化を図るため、メトリクスを収集します。
こちらも「医療」に例えると、メトリクスは「検査値」であり、血圧、心拍数、体温、血糖値、酸素飽和度など、継続的に測定される数値データであり、変化を観察します。
トレース
システムやアプリケーション内でのリクエストの流れを追跡するためのデータであり、問題の発生箇所やパフォーマンスのボトルネックを特定するため、トレースを収集します。
こちらも「医療」に例えると、トレースは「症状の経路追跡」であり、どの臓器に症状が現れているか追跡します。造影剤による検査でどの臓器に問題があるのかを見極めるイメージです。
オブザーバビリティのツール紹介
この「テレメトリーデータ」をもとにしてオブザーバビリティを行うわけですが、サービスやツールによって「テレメトリーデータ」の収集方法が大きく変わります。
AWS上のシステムをモニタリング対象とする場合、AWSのマネージドサービスを利用したオブザーバビリティも可能ですし、3rdパーティー製のオブザーバビリティツールもたくさんあります。
3rdパーティー製のツールの一例としては、Dynatrace、NewRelic、Datadog、Splunkなどがあり、AWSのオブザーバビリティサービスにはない機能がたくさん用意されています。
例えばDynatraceで言えば、Davis AIという独自のAIを用いて、根本原因分析や対応案の提示を行ってくれるなど、より高機能なオブザーバビリティにおけるAIOpsを実現できます。
また、マルチクラウドにも対応し、システム全体を包括的にモニタリングすることが出来るため、障害の平均復旧時間(MTTR)を大きく削減することができるでしょう。
もちろん、新たなツールの導入により費用もかかりますので、AWSのマネージドサービスを利用するか3rdパーティー製のツールを使うかは、お客様とご相談しながら決めていきます。
なお、ガートナー社がツール毎のレビューサイトを用意していますので、こちらも是非ご確認ください。
オブザーバビリティの代表的なサービス紹介
前述のいずれのツールにも用意されているオブザーバビリティの代表的なサービスをいくつか挙げましたので、紹介させていただきます。
RUM
Real User Monitoring (RUM）は、実際のユーザーがアプリケーションをどのように体験しているかをリアルタイムでモニタリングするツールとなります。
RUM に関連したツールとして「Google Analytics」がありますが、これはウェブサイトやアプリのユーザー行動分析するためのツールであり、主に「ユーザーエンゲージメントとマーケティング分析」に利用されます。一方で、このRUM は「ユーザー体験とパフォーマンスのモニタリング」に利用され、よりパフォーマンスに重点を置いています。
[参考]RUMの実際の画面（Dynatrace）
外形監視
外形監視は、システムやアプリケーションをユーザー視点からモニタリングする手法です。実際のユーザーがアクセスするのと同じ方法で、外部からシステムやアプリケーションに対するパフォーマンスをモニタリングします。但し、RUM とは異なり実際のユーザーアクセスではなく、試験的なアクセスを使用したモニタリングとなります。
トレーシング
トレーシングは、アプリケーション内のリクエストの流れを追跡し、各コンポーネントのパフォーマンスを詳細に分析することを可能にします。サービスマップからリクエストの追跡を行い、ボトルネックの特定を行うことができます。
[参考]トレーシングの実際の画面（Dynatrace）
SLO
SLO（Service Level Objective）は、オブザーバビリティの重要な要素の一つであり、サービスのパフォーマンスや可用性に関する「目標」を設定するための指標です。
似たものとしてSLA（Service Level Agreement）がありますが、SLA は顧客とサービス提供者で取り決める「契約」であり、SLO は内部で定めた「目標」です。
このSLO が達成できているかをモニタリングすることもオブザーバビリティとして大事なポイントです。なお、実際の「測定値」を表すのは、SLI（Service Level Indicator）です。
オブザーバビリティ導入の進め方
工程としての進め方
オブザーバビリティ導入の進め方について、改めて整理します。前回お話させていただいた通り、現在のオブザーバビリティの能力を把握することから始めることを推奨します。
診断後、今後どのような姿を目指すか(Tobe像)を固めていきましょう。具体的な内容としては、オブザーバビリティ成熟度モデルにおいてどのステージを目指すか、まずはどこから手を付けていくか、どのツールを選定するかといった内容を固めていくことになります。
Tobe像を固めた後は、どのようなツールを利用するかによりますが、DTS独自の設計標準に基づいた設計を行い、用意されたテンプレートまたは構築手順書を基に構築します。
OpenTelemetryの選択
OpenTelemetry（OTel）は、アプリケーションやインフラストラクチャからテレメトリーデータ（メトリクス、トレース、ログ）を収集・処理・エクスポートするための統一的な標準規格です。ベンダーに依存しない仕様として業界標準として確立されつつあります。
但し、DynatraceやNewRelicといった3rdパーティー製のエージェントは、OTelには準拠しておらず独自のプロトコルとなります。ただ、OTelのデータの受信・処理ができることから、OTelをサポートしています。
これらのエージェントの特徴としては、導入が簡単で即座に価値を提供します。OpenTelemetryの学習コストと比較して、ビジネス価値を早期に実現することができます。
OTelは優れた技術標準ですが、導入の手軽さとビジネス価値の早期実現を重視し、まずはベンダーエージェントでオブザーバビリティを開始することが現実的だと考えます。
その後、組織の成熟度と要件に応じて、OTelの併用や移行を検討することもできます。重要なのは、完璧な技術選択よりも、オブザーバビリティを迅速に導入し少しでも早く恩恵を受け始めることではないでしょうか。
まとめ
前回のブログに引き続き、「オブザーバビリティとは？」というテーマで説明いたしました。「オブザーバビリティ」のイメージが漠然としていた方にも伝わりましたでしょうか。
今後も「オブザーバビリティ」を中心に情報発信していきたいと思います。今後とも宜しくお願いいたします。