Live:CloudOps Webinars & Hands-on Workshops ·Register ↗
メインコンテンツまでスキップ

開発者

オブザーバビリティは、生産性の向上、アプリケーションパフォーマンスの改善、より良い意思決定と迅速な問題解決によるビジネスの成功を促進するため、開発者にとって非常に重要です。このガイドでは、オブザーバビリティを効果的に活用するためのベストプラクティスと推奨事項を提供します。

開発者にとってオブザーバビリティが重要な理由​

開発者は、いくつかの重要な目的でオブザーバビリティを使用します。

  • 迅速な問題の特定と解決:
    • オブザーバビリティにより、開発者は問題を迅速に特定して診断でき、問題解決までの時間 (MTTR) を短縮し、全体的なソフトウェア配信パフォーマンスを向上させます
    • 本番環境でシステムがどのように動作するかを理解できるため、開発者は情報に基づいた意思決定を行い、運用を改善できます
  • カスタマーエクスペリエンスの向上:
    • システムの動作を分析することで、開発者はパフォーマンスと信頼性を最適化し、より良いカスタマーエクスペリエンスとユーザー満足度の向上につながります
    • オブザーバビリティツールはユーザーインタラクションを監視するのに役立ち、開発者が UI/UX の問題を迅速に特定して対処できるようにします
  • チーム効率とイノベーションの強化:
    • オブザーバビリティプラットフォームは、運用データの単一の情報源を提供し、チーム間のコラボレーションを促進し、トラブルシューティング時間を短縮します
    • 自動化されたインサイトとアラートにより、開発者は手動デバッグに費やす時間を減らし、イノベーションにより多くの時間を費やすことができます
  • データドリブンな意思決定:
    • オブザーバビリティは、システムパフォーマンスに関する詳細なインサイトを提供し、開発者がコードの改善とリソース割り当てについてデータドリブンな意思決定を行えるようにします
    • 改善すべき領域を特定することで、組織が投資を最適化し、市場投入までの時間を短縮するのに役立ちます
  • 複雑性の管理:
    • オブザーバビリティは、システムの相互依存関係の包括的なビューを提供することで、最新のクラウドネイティブおよびマルチクラウド環境の複雑性を管理するのに役立ちます
    • 開発者が複雑性を整理し、関連するデータに焦点を当てることができるため、より効率的な開発プロセスを促進します

コード品質のベストプラクティス​

  • 課題追跡メトリクスの監視:

    • JIRA、Trello、またはその他の課題追跡プラットフォームなどのツールを使用して、次のようなメトリクスを追跡します。
      • チケットがコードレビューからテストレビューに移動し、進行中に戻る回数。回数が多い場合は、スキル不足、複雑性の高さ、またはツールの不備を示している可能性があります。
      • 外部依存関係によりチケットがブロックされる回数。回数が多い場合は、依存関係間の結合度が高い、または複雑性が高いことを示している可能性があります。
    • 推奨事項:
      • Amazon Q Developer などのツールを使用して、自動化されたコードレビューにより生産性とコードの品質を向上させます。Amazon Q Developer は、ソフトウェア開発タスクを最大 80% 高速化し、迅速な開発サイクル中の人的エラーの可能性を減らすことで、より高品質なコードに貢献します。
      • 改善点を特定し、継続的改善のマインドセットを育成するために、レトロスペクティブの一環として定期的なメトリクスのレビューをスケジュールします

  • パフォーマンスメトリクスのためのコードのインストルメント化:

    • コードをインストルメント化して、以下を測定できるようにします。これらは、コード実装のパフォーマンス効率とスケーラビリティを評価することで、コード品質の間接的な指標を提供します
      • RED メソッド: マイクロサービスのリクエスト、エラー、期間を監視します。これにより、サービスのパフォーマンスと信頼性に関する洞察が得られます。
      • USE メソッド: システムリソースの使用率、飽和度、エラーを追跡します。これにより、ボトルネックとリソースの制約を特定できます。
    • リクエスト処理パスにおける、他のサービス、データベース、キャッシュなど、すべての外部依存関係への呼び出しの周辺にインストルメンテーションを追加します。これにより、リクエスト処理時間の突然の変化を調査するために必要な情報が得られ、問題の根本原因をより迅速に特定できるようになります
    • 推奨事項:
      • リクエストレイテンシーとエラー率に SLO (サービスレベル目標) を設定し、それを使用してより良い品質とパフォーマンスのための改善を推進します
      • 重要なデータフローとリクエスト処理パスを実行する自動テストに、インストルメンテーションの検証を追加します
      • システムパフォーマンスとコード品質測定のベースラインを作成するための自動負荷テストタスクを構築します
      • 単一のリクエストのパフォーマンスへの影響を特定できるように、インストルメンテーションにコンテキストが追加されていることを確認します
      • SDK によって提供される自動インストルメンテーションを設定して利用し、インストルメンテーションの追加に伴う手動作業を削減します

効率的なログ記録とモニタリング​

  • 構造化されたログ形式（例：json）を使用します。既存のアプリケーションの場合は、ログ変換機能を使用してより多くのコンテキストを注入し、フィールドを追加または削除することを検討してください
  • 意味のあるシグナルを導き出し、シグナル間で相互に関連付けることができる十分なメタデータを含む広範なイベント形式を使用します
  • OpenTelemetry または ADOT SDK を使用します。これらはログに追加のコンテキストを注入し、クロスシグナル相関を可能にし、平均特定時間（MTTI）を短縮することで平均復旧時間（MTTR）を短縮します
  • ログレベルを適切に使用します。これにより、ログの量を制御でき、取り込みコストを削減できます
    • ERROR は、予期しないエラー状態と予期されるエラー状態に使用します。根本原因分析を加速できるように、できるだけ多くの追加コンテキストを追加します
    • INFO は、ユーザーログインなどの一般的なランタイムイベントに使用します。これらはコンテキストを提供し、重要です
    • DEBUG は、処理パス内の呼び出しをログに記録して、アプリケーションのフローと状態をより深く理解するために使用します
  • PII や PHI などの機密情報と見なされる可能性のあるデータのログ記録は避けてください。要件が存在する場合は、データ保護ポリシーの使用、または取り込み時のデータの編集を検討してください。IAM ポリシーを使用して、生データを表示できるユーザーを制御します
  • 埋め込みメトリクス形式（EMF）を使用して、ログ内にメトリクスを埋め込み、Observability プラットフォームへの API 呼び出し数を削減し、コストを削減します
    • requestId などの高カーディナリティディメンションを持つメトリクスには EMF を使用しないでください
  • アラート
    • 異常検出を使用して、アラートに厳格なしきい値を設定することを避けます。これにより、システム使用量が時間の経過とともに変化する際にしきい値を更新するオーバーヘッドを回避し、アラートノイズを削減できます
    • メトリクス計算と組み合わせアラートを使用して、特定の障害に対して生成される個別のアラートの数を削減します
    • SLO が失敗のリスクにある場合、または失敗している場合にのみアラートを送信します。これにより、チームが不必要に起こされることを避け、認知的およびコンテキストの過負荷を軽減できます
    • 障害の通知に対して誰かが対処できる場合にのみアラートを送信します
    • 可能な限りアラートの解決を自動化します。たとえば、オートスケーリング、レプリカまたはスタンバイインスタンスへの自動フェイルオーバーなどのネイティブプラットフォーム構成を活用します
    • アラート通知に十分なコンテキストを追加して、通知を受けた人が確認すべきダッシュボード、使用すべきプレイブック、影響を受けているサービスを迅速に特定できるようにします
  • ダッシュボード
    • ペルソナ/ステークホルダーごとに 1 つ以上のダッシュボードを作成します
      • アプリケーション開発者は、問題を診断し、アプリケーションのパフォーマンスを理解するのに十分なコンテキストが必要です
      • プラットフォームエンジニアは、SLO への影響と注意が必要なインフラストラクチャコンポーネント、およびそれらを使用するサービスへの影響を特定するためのコンテキストを含むダッシュボードが必要です
      • プロダクトマネージャーは、ユーザージャーニー、製品機能の使用状況メトリクス、採用率、放棄ポイントなどを示すダッシュボードが必要です
      • ビジネスステークホルダーは、製品採用率、サブスクライバーの離脱、またはビジネスパフォーマンスと収益に影響を与える可能性のあるものを示すウィジェットに関心があります
    • すべてのダッシュボードで一貫したタイムゾーン（例：UTC）を使用します
    • ダッシュボード上のすべてのウィジェットで同じ時間範囲を使用します
    • 注釈を使用してダッシュボードにより多くのコンテキストを追加します
    • エラー解決を支援するコンテキストを追加するウィジェットのみがダッシュボードにあることを確認します。ウィジェットが多すぎるとノイズと認知的過負荷が追加され、MTTR が高くなります
      • その他のあると便利なウィジェットは、別のダッシュボードに移動するか、ウィジェットがまだ多すぎない場合はダッシュボードの下部に移動します。ウィジェットが多すぎると、読み込み時間に影響し、ストレスと認知的過負荷が高まります
    • ダッシュボード全体が 1 つの画面に収まり、ラップトップの解像度と画面サイズでトレンドが表示されることを確認します
    • ダッシュボードの説明とダッシュボードの使用方法に関するガイダンスを含むウィジェットを配置します
    • ウィジェットにしきい値を構成して表示します
    • 1 つのウィジェットにより多くのメトリクスを詰め込まないでください。トレンドとスパイクが平滑化され、目的が損なわれる可能性があります。これにより診断も困難になります
    • トレンドとスパイクが表示されるように、動的に調整される Y 軸を使用します
  • 推奨事項
    • コストの管理
      • ステークホルダーの特定
        • 機能、可用性、セキュリティ、コスト、販売、製品使用状況など、機能のパフォーマンスに関心のあるさまざまなペルソナを決定します
        • ステークホルダーには、開発チーム、エンドカスタマー、社内ビジネスステークホルダー、プラットフォーム運用チーム、またはアプリケーション開発者が含まれます
      • 主要な成果の特定
        • 各ステークホルダーについて、通常はサービスレベル目標（SLO）を使用して測定される定量化可能な成果（例：エラー率、リクエスト処理時間、1 分あたりのログイン数、1 分あたりの購入製品数、放棄されたカートの数など）を定義します
        • これらのペルソナごとの SLO を使用して、必要な計装を特定します
      • 適切なシグナルの選択
        • 十分なコンテキストを持つ広範なログは、メトリクスとトレースに変換でき、単一の信頼できる情報源を提供し、コストを管理し、シグナル相関を可能にします
        • Observability Strategy Workshop を実行して、アプリケーションに計装すべき適切なシグナルを特定します
    • 適切なシグナルの選択
      • ログとトレースは、障害または予期しない動作の根本原因を見つけるのに役立ちます。「特定のリクエストが失敗した理由は何か？」や「リクエスト処理時間の p50 または p99 が増加した場合、リクエスト期間に関連する SLO について何を知る必要があるか？」などの質問に答えるのに役立つログを追加してください
      • メトリクスは、ベースラインパフォーマンスを理解し、トレンドと異常を予測するのに適しています。予期しない動作の兆候を事前に示すことができます。ただし、カスタムメトリクスは高価です
    • アラート疲労の軽減
      • 構成に応じて、アラートはシステムの問題を事前または事後的に強調表示できます。アラートが多すぎると、アラート疲労と非効率的なチームにつながり、コード品質と製品提供が悪化します
    • 定期的なレビューと継続的改善
      • チームのメンバーがダッシュボードを監視し、特定された新しいトレンドやパターンを報告するための定期的なローテーションを設定します
      • 各リリースの一部を、レトロスペクティブとローテーション観察中に特定されたギャップに基づいて、シグナルの改善、アラートしきい値の調整、ダッシュボードの調整に割り当てます
      • 解決の労力とアラートがトリガーされる回数に基づいて、繰り返し発生するアラートの根本原因の修正に優先順位を付けます

プロファイリングとパフォーマンスの最適化​

  • Real User Monitoring(RUM):
    • AWS X-Ray や New Relic などのツールを使用して、実際のユーザーインタラクションを監視し、パフォーマンスのボトルネックを特定します。主要なコンバージョンポイントに焦点を当て、技術的なパフォーマンスとビジネス成果（コンバージョン率、離脱ポイント）の両方を測定します。
    • チェックアウトフローや登録プロセスなどの重要なユーザーパスの監視を優先します。
    • ベースラインのパフォーマンスとユーザー行動を確立し、ビジネス成果に影響を与える可能性のある異常や傾向を迅速に特定できるようにします。
  • Synthetics:
    • Amazon Cloudwatch Synthetics などのツールを使用して、ユーザーインタラクションをシミュレートし、さまざまな条件下でアプリケーションのパフォーマンスをテストします。Synthetic Canary は、ユーザーへの影響が検出される前に問題を特定するのに役立ちます。
    • Synthetic Canary を使用してヘルスチェックとシステムの稼働時間を検証します。
  • プロファイリングツール:
    • AWS X-Ray などのツールをプロファイリングに使用して、パフォーマンスのボトルネックを特定し、リソース使用率を最適化します。
    • トラフィックパターンに基づいて調整される動的サンプリングレートを設定し、エラートレースと外れ値の適切な保持を維持します。これにより、データ量とコストを効果的に管理しながら、重要な問題への包括的な可視性を確保できます。
    • テールサンプリングを使用して、エラーステータス、期間のしきい値、カスタム属性に基づいて価値の高いトレースを優先する複数のサンプリングポリシーでコレクターを構成します。これにより、サンプリングされたトレースに最も価値のあるものが含まれるようになります。
  • OpenTelemetry:
    • OpenTelemetry を自動計装に使用して、パフォーマンスメトリクスとトレースの収集を簡素化します。手動計装を追加する前に、自動計装によって提供されるテレメトリを検証し、要件に基づいて自動計装を調整してシグナルとコストを制御します。

エラー処理とデバッグ技術​

  • 全般:
    • 一時的な障害に対して指数バックオフを使用した再試行メカニズムを設計します。外部依存関係に対してサーキットブレーカーを実装します。これは分散システムで特に役立ち、ダウンストリームのコンポーネント/サービスへの過度な負荷を防ぎます。すべてのシナリオに適用できるわけではないため、この設計を採用する前に十分な検討を行ってください。
    • 重要な操作のためのフォールバックメカニズムを作成し、失敗したトランザクションのための明確なロールバック手順を維持します。
    • すべてのエントリポイントで入力検証を追加します。
    • 再試行可能な操作が冪等であることを確認します。
  • ログ記録:
    • 保存された CloudWatch Log Insights クエリのリポジトリを維持します。フォルダを使用してクエリをグループ化します。
    • エラーを無視しないでください。常にログに記録するか、適切に処理します。
    • 他の関連するコンテキストに加えて、相関 ID やリクエスト ID などの識別形式をログに追加します。
  • プレイブックとランブック:
    • プレイブックを作成する際は、必要な権限、ツール、期待される結果を含む明確で実行可能な手順を含めます。
    • プレイブックとランブックに検証手順、ロールバック手順、関連するダッシュボードへのリンクを含めます。
    • プレイブックをバージョン管理し、インシデント後に学習と重要な洞察を含めて更新します。
  • サンプリングルールの調整:
    • サービスの重要度とトラフィックパターンに基づいて動的なサンプリングルールを実装します。
    • エラー状態とビジネスクリティカルなパスに対して、より高いサンプリングレートを設定します。
    • 運用ニーズとコストの考慮事項に基づいて、サンプリングルールを定期的に見直して調整します。

コードレビューとコラボレーション戦略​

  • チケットの詳細化
    • 機能の詳細化プロセスの一環として、Observability 要件を特定します。これには以下が含まれる場合があります
      • 影響を受けるステークホルダーと関連する SLO
      • 必要なテレメトリ/シグナル
      • 必要なアラート
      • 作成または更新するダッシュボードのリスト
  • ブレームレスな振り返り
    • インシデントの後は必ず、ブレームレスな振り返りを実施して、プロセスを改善したり自動化を追加したりする機会を探します。変更のコストを常に考慮し、各事後分析の演習から、完了までのタイムラインが関連付けられた、少なくとも 1 つの合意された実行可能な項目を必ず残すようにします。
  • 運用準備状況レビュー
    • プラットフォームチームおよび運用チームと運用準備状況レビューに参加して、Observability 体制のギャップを特定します。これはチェックリストにすることができ、本番環境へのデプロイ前の必須の演習にすることができます。複数のチームを持つ大規模な組織では、このプロセスがボトルネックにならないように、新機能ごとおよびリリースの頻度に応じて定期的に実施します。
  • 推奨事項
    • AWS Systems Manager Incident Manager のようなツールを使用して、インシデント後の分析をガイドします
    • 運用準備状況レビューのチェックリストまたはプロセスに含める質問のインスピレーションとして、運用準備状況レビューを参照してください
    • 振り返りや運用準備状況レビューから得られた学びは常に共有します。これは Wiki やメールグループのサブスクリプションを通じて行うことができます

API 設計とドキュメントのガイドライン​

  • バージョン管理:
    • API がバージョン管理されており、処理されるすべてのリクエストにコンテキストとしてバージョンが追加されていることを確認します
    • カスタムメトリクスを送信する場合は、該当する場合はバージョンにディメンションを追加します
    • ダッシュボードにアノテーションまたは識別子を追加して、あるバージョンから別のバージョンへの切り替えを明確に区別します
    • 各バージョンへのリクエストを追跡し、バージョンの使用状況を視覚化するウィジェットを追加します。これは、リクエストが期待どおりにルーティングされていることを確認し、根本原因を特定する時間を短縮するためです。これにより、古いバージョンを非推奨にして削除する際の信頼性が向上します
  • 下位互換性:
    • 古い API バージョンに関連するコードパスを削除する前に、古いバージョンへのリクエストがないことを確認します
  • バッチ API:
    • 個々のリクエストのステータスと、バッチリクエスト全体のステータスの両方についてシグナルを発行します
    • バッチリクエスト ID と個々のリクエストを識別するコンテキストがログに追加されていることを確認します