Datadog コース / Chapter 02

cost-api の全体像

この章で作るのはDatadogの設定ではなく、後で観測する対象です。HTTP、gRPC、外部APIの境界と、講座特有のECS配置判断を一本につなぎます。

01

処理の往復を一本で追う

誰が次の誰を呼び、どこでデータを整形するかを固定する。

cost-apiのリクエストとレスポンス経路
要求は右へ進み、providerが取得した結果をaggregatorが整えて返す。

PostmanからGET /api/costを受けるのはcost-aggregatorです。aggregatorはgRPCでcost-providerを呼び、providerがAWS Cost and Usage APIへ到達します。

境界プロトコル役割
Client → aggregatorHTTP利用者向けAPI
aggregator → providergRPC内部サービス呼び出し
provider → AWSAWS API実コスト取得
観測では、どの境界で遅延・エラーが起きたかをこの順序に沿って切り分けます。
02

責務は分け、配置はあえて同居させる

論理的なサービス境界と、ECS上の配置単位は同じではない。

同一ECS Taskに同居するaggregatorとprovider
責務は別でも、講座ではネットワーク探索を省くため同じTaskに置く。

本来は独立スケールできる別ECS Serviceも候補です。しかしその場合はService ConnectやCloud Mapが必要です。この章では同一Taskに置き、localhost:50051でgRPC接続します。

観点講座の構成独立Service
通信localhostService discovery
スケール2コンテナ一緒個別に可能
学習負荷低い高い
同居は「マイクロサービスなら常に正解」ではなく、Datadogの観測学習へ集中するための教材上の選択です。
03

三段階で観測対象を成立させる

起動、内部連携、外部API接続を一度に検証しない。

cost-apiの三段階動作確認
最小のhealthから始め、mock、実APIへ段階的に外部依存を増やす。
  1. aggregatorの/api/healthがokを返す
  2. AWS_USE_MOCK=trueで固定データが返る
  3. AWS_USE_MOCK=falseで実コストが返る
curl -f http://localhost:8080/api/health
curl http://localhost:8080/api/cost
ここまで通れば、後続章でMetrics・Logs・Tracesを導入したとき、観測設定ではなくアプリ疎通の問題に迷いにくくなります。