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

開発者向け

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

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

開発者は以下の主要な目的でオブザーバビリティを使用します：

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

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

  • 課題追跡メトリクスのモニタリング:

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

  • パフォーマンスメトリクス用のコード計装:

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

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

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

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

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

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

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

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

  • チケットの詳細化：
    • 機能の詳細化プロセスの一部としてオブザーバビリティの要件を特定します。これには以下が含まれます：
      • 影響を受けるステークホルダーと関連する SLO
      • 必要なテレメトリ/シグナル
      • 必要なアラート
      • 作成または更新が必要なダッシュボードのリスト
  • ブレームレス（非難なし）レトロスペクティブ：
    • インシデント発生後は必ずブレームレスレトロスペクティブを実施し、プロセスの改善や自動化の追加機会を探します。
    • 変更のコストを常に考慮し、ポストモーテム（事後分析）の際には、必ず実行可能な項目を少なくとも 1 つ合意し、その完了までの期限を設定してください。
  • 運用準備状況レビュー：
    • プラットフォームチームと運用チームと共に運用準備状況レビューに参加し、オブザーバビリティ体制のギャップを特定します。
    • これはチェックリストとして、本番環境へのデプロイ前の必須の演習となります。
    • 複数のチームを持つ大規模な組織では、このプロセスがボトルネックとなることを避けるため、新機能やリリースのサイクルに応じて定期的に実施します。
  • 推奨事項：
    • インシデント後の分析をガイドするために、AWS Systems Manager Incident Manager のようなツールを使用します。
    • 運用準備状況レビューのチェックリストやプロセスに含める質問の参考として、Operational Readiness Review を参照してください。
    • レトロスペクティブや運用準備状況レビューから得られた知見は、常に wiki やメーリングリストを通じて共有してください。

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

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