AWSで筋トレ進捗記録2

背景（初めてのAWSアーキテクチャ構成と実装）

これまで筋トレの記録は、Googleスプレッドシートへ種目・レップ数・重量・セット数を書き込んでいました（有酸素運動も同様です）。しかし、データ量が多くなるとスプレッドシートが重たくなり、月別で手動でスプレッドシートを移動させていました。これが面倒でどうにかしたいと考えていました。また、iphoneやipadのスプレッドシートは入力がしづらく記録を後でまとめてやるのも手間でした。

そこでAWSを活用して、自分の運動記録を可視化・通知してくれる仕組みを作ってみることにしました。

具体的には、筋トレの重量やセット数の可視化や週ごとの運動量を自動で集計て定期的にメール通知する仕組みを想定しています。これによって以下の恩恵を得られます。

• 週の運動量を手軽に把握できる
• 記録と集計の手間が減る（これが一番大きい）
• 可視化や通知によってモチベーションが維持しやすくなる

前提条件

• 利用者は 1 名：user_id は "user01" にハードコード
• 個人利用・低トラフィック：1 日あたり数レコード程度を想定
• コスト最小が最優先：常時課金されるリソース（EC2・RDS・NAT Gateway など）はなし
• IaC なし：すべて AWS マネジメントコンソールでの手動構築（ここは改善点）
• SES はサンドボックスモード。検証済みアドレス宛にしか送信できない。
• リージョンは ap-northeast-1（東京）
• 週の起点は日曜レポートは毎週土曜 21:00 JST に送信

入力

運動情報（筋トレの種目など）は、AppSheetを使っています。個人で使う分には一番手軽だと思い使い始めました。

アプリ画面はこんな感じです。前回の記録を確認するために、部位ごとに種目や重量がわかるようにしています。

アーキテクチャ全体構成

構成はこのようになっています。

※ ボリューム：総負荷量。重量×回数×セット数で決まるトレーニングの総量。

使用したAWSサービス一覧

• Amazon API Gateway (HTTP API) — HTTP リクエストを受け取り Lambda に橋渡しするためのフルマネージドな API。
• AWS Lambda — サーバーレスにコードを実行する。リクエストが来た時だけ起動し、実行時間分だけ課金される。
• Amazon DynamoDB — フルマネージドの NoSQL データベース。キー指定のアクセスに強く、容量設計が不要。
• Amazon SES (Simple Email Service) — メール送信サービス。ここでは整形済みの週次レポート本文の送信に使用。
• Amazon EventBridge Scheduler — cron 式でジョブを定時起動するスケジューラ。タイムゾーンを直接指定できる。
• Amazon S3 — オブジェクトストレージ。ここでは静的ウェブサイトホスティング機能でダッシュボード HTML を配信。

設計意図

サーバーレス重視

個人開発のためコスト最小限を優先したこと、Well-Architected Framework のパフォーマンス効率の設計原則として「サーバーレスアーキテクチャを使用する」ことが挙げられていたことから、S3 + Lambda + DynamoDB 構成を採用しました。

DynamoDB のオンデマンドモードを採用

予測可能なワークロードにのみプロビジョンドモードを使用することがWell-Architected の Serverless Lens で勧められています。記録時間は予測が難しいため、オンデマンドを採用しました。

HTTP API vs REST API → HTTP API を採用

機能を絞ることでコストとレイテンシで有利になるため採用しました。

EventBridge Scheduler vs EventBridge Rule → Scheduler を採用

「毎週土曜 21:00 JST」を UTC に直すと曜日跨ぎの計算が必要になり、煩雑となります。そのため、cron 式にタイムゾーン（Asia/Tokyo）を直接指定でき、UTC 変換のミスが起きないSchedulerを採用しました。

週次レポートはSESを採用

集計済みの長文レポートを「メール本文」として整形して送りたいため採用しました。

S3 静的ホスティング vs Amplify / CloudFront → まず S3 単体

ダッシュボード（後述）は Chart.js を CDN から読む単一 HTML ファイルであり、ビルド工程がありません。最小構成で動くところまでを優先しました。

計算を Lambda 側に置いた理由

ボリューム（重量 × レップ × セット）、progress（累積ボリューム）、ランニング時の平均速度（距離 ÷ 時間）といった計算は、すべて Lambda 側で行い、結果を DynamoDB に保存しています。また、週次で各項目で値を集計します。

実行結果

ダッシュボード

1,2枚目が筋トレ、3枚目が有酸素運動のダッシュボードです。いつでも可視化してみれることで、積み重ねている実感を得られます。

インクラインダンベルプレスのボリュームの推移

インクラインダンベルプレスの重量とレップ数の推移

ランニングの距離の推移

週末のメール通知

今週の記録が自分宛に届きます。

今週の筋トレの内訳

今週のランニングの内訳

有酸素運動は時間を記録していなかったので、0になっています…（今日からは時間を記録します）。

所感・今後の改善点

初めてAWSでアーキテクチャを実装してみて、実際にアーキテクチャを考えることの難しさを感じました。しかし、アーキテクチャを実装している最中の没入感がとても楽しかったです。（特にSESでメール通知が届いたときの高揚感）そのため、とてもいい経験になりました。

次からは

• DynamoDB Streams の追加
• CloudFront + OAC を前段に置き、S3 の直接公開をやめる
• IaC 化（AWS SAM / CDK）

に挑戦したいです。特に3番目のIaC 化はできたら楽にインフラ構成できるので、優先してやってみたいです。