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