一般 - よくある質問
ログとトレースはどのように異なりますか？
ログは単一のアプリケーションとそれに関連するイベントに限定されます。例えば、 ユーザーがマイクロサービスプラットフォームでホストされているウェブサイトにログインし、購入を行う場合、複数のアプリケーションから、そのユーザーに関連するログが生成される可能性があります：
- フロントエンドウェブサーバー
- 認証サービス
- 在庫管理サービス
- 決済処理バックエンド
- ユーザーに領収書を送信するアウトバウンドメーラー
これらのそれぞれが、このユーザーに関する何らかのログを記録する可能性があり、そのデータはすべて価値があります。しかし、トレースは、これらの個別のコンポーネントすべてにまたがる、ユーザーの単一のトランザクションにおける相互作用の全体像を一貫した形で提示します。
このように、トレースはアクティビティの単一のビューを示すことを目的とした、複数のサービスからのイベントのコレクションであるのに対し、ログはそれを作成したアプリケーションのコンテキストに紐付けられています。
どのシグナルタイプがイミュータブルですか？
基本的な 3 つのシグナルタイプ（メトリクス、ログ、トレース）は、実装によって保証レベルは異なります が、すべてイミュータブルです。 例えば、ログのイミュータブル性は多くのガバナンスフレームワークにおいて厳格な要件であり、これを確保するための多くのツールが存在します。 同様に、メトリクスとトレースも 常に イミュータブルであるべきです。
これは「不正確なデータ」や誤ったデータの処理に関する疑問につながります。 AWS オブザーバビリティサービスでは、誤って送信されたメトリクスやトレースを削除する機能はありません。 CloudWatch Logs ではログストリーム全体の削除は可能ですが、一度収集されたデータを遡って変更することはできません。 これは設計上の仕様であり、お客様のデータを最大限の注意を払って扱うための重要な機能です。
オブザーバビリティにとってイミュータブル(不変性)が重要な理由
イミュータブル(不変性)は、オブザーバビリティにとって最も重要です！過去のデータが変更可能であれば、システムやオペレーションを進化させる際の 選択 に影響を与える重要なエラーや異常な動作を見失ってしまいます。
例えば、時系列データに大きな時間的なギャップがあるメトリクスのデータポイントは、単にデータ収集の欠如を示すだけでなく、インフラストラクチャにおけるより大きな問題を示している可能性があります。同様に、「null」データについても、空の時系列であっても価値があります。
ガバナンスの観点からは、アプリケーションのログやトレースを事後に変更することは、否認防止 の原則に違反します。これにより、システム内のデータがソースアプリケーションによって意図された通りのものであると信頼することができなくなります。
Blast Radius とは何ですか？
変更の Blast Radius とは、環境内で発生する可能性のある影響範囲のことです。たとえば、データベーススキーマを変更する場合、潜在的なリスクには、データベース内のデータと、それに依存するすべてのアプリケーションが含まれる可能性があります。
一般的に、変更の Blast Radius を小さくすることはベストプラクティスとされています。また、可能な限り変更を小さく、安全で、元に戻せる単位に分割することが推奨されています。
クラウドファーストアプローチとは何か？
クラウドファース ト戦略とは、組織がインフラストラクチャの全部または大部分をクラウドコンピューティングプラットフォームに移行することです。物理的なサーバーなどのリソースを使用する代わりに、クラウド上にリソースを配置します。
コロケーション型のハードウェアに慣れている人にとっては、これは急進的に思えるかもしれません。しかし、その逆も真実です。クラウドファーストの考え方を採用した開発者は、サーバーを物理的な場所に縛り付けることを考えられないと感じています。クラウドファーストのチームは、サーバーを個別のハードウェアや仮想サーバーとしてではなく、ビジネス機能を実現するためのソフトウェアとして考えています。
クラウドファーストは、2010 年代のモバイルファースト、2000 年代初頭の仮想化に相当する 2020 年代のトレンドです。
技術的負債とは何か？
Wikipedia から引用：
ソフトウェア開発において、技術的負債（デザイン負債やコード負債とも呼ばれる）とは、より時間のかかる適切なアプローチを採用する代わりに、容易な（限定的な）解決策を現時点で選択することによって生じる、追加の手直しの暗黙的なコストのことです。
基本的に、レガシーなコード、アプリケーション、人的プロセスを取り除くことなく作業を追加していくと、時間とと もに負債が蓄積されていきます。 技術的負債は、絶対的な生産性を低下させます。
例えば、ビジネスにほとんどまたはまったく直接的な価値を提供しないレガシーシステムのメンテナンスに時間の 10% を費やさなければならない場合、その 10% は支払わなければならない コスト となります。 技術的負債を減らすことは、価値を生み出す新しい製品を作るための実質的な時間を増やすことと同じです。
関心の分離とは
オブザーバビリティソリューションのコンテキストにおいて、関心の分離とは、ワークロードやアプリケーションの機能領域を、独立して管理される個別のコンポーネントに分割することを意味します。 各コンポーネントは、個別の関心事（ログ構造やログの 出力 など）に対応します。 基盤となるコードを変更せずにコンポーネントの設定を制御できることで、開発者は自身の関心事（アプリケーションの機能や機能開発）に集中でき、DevOps 担当者はシステムのパフォーマンスの最適化やトラブルシューティングに集中できます。
関心の分離は、コンピュータサイエンスにおけるコアコンセプトです。
オペレーショナルエクセレンスとは何か？
オペレーショナルエクセレンスとは、ワークロードの運用に関連するベストプラクティスを実践することです。AWS には Well-Architected に特化したフレームワーク全体があります。オペレーショナルエクセレンスを始めるには、このページをご覧ください。