1. はじめに

Spotifyの再生履歴取得するアプリケーションをローカールのPC起動からAWSのLambda起動に変更しました。

ローカルだとパソコンを常に電源を入れておく必要があり、起動するとかしないというのを気にするのがとても嫌でした。やはりクラウドで動かしたいなと思って、Lambdaから起動するように変更しました。

また、ローカルで動かしていたときは、PCの再起動やスリープ、ネットワークの切断などで処理が止まってしまうことも多く、安定してデータを取得し続けるのが難しいという課題もありました。クラウドであれば、こうした心配から解放され、24時間365日安定して動作させることができます。

2. なぜLambdaにしたか

Spotifyの再生履歴を取得するアプリケーションを開発するにあたり、実行環境としてAWS Lambdaを選択しました。主な理由は以下の通りです。

2.1. 低コスト

Lambdaはリクエストごとに課金されるため、常時稼働させる必要がないバッチ処理やAPIには最適です。今回のアプリは定期的にSpotifyのAPIを叩くだけなので、サーバーを常時起動しておく必要がなく、無料枠の範囲で十分運用できます。

なお、Lambdaの無料枠は以下です。SpotifyのAPIをたたくぐらいなら、問題ないです。

  • リクエスト数：月間 1,000,000 件まで無料
  • コンピュート時間：月間 400,000 GB-秒まで無料
  • HTTP レスポンス ストリーミング：月間 100 GiB まで無料（リクエストあたり最初の 6 MB までは別途カウントなし）

また、約1週間動かしてのコストは以下のとおりです。Lambdaのコストは本当に安く、個人開発や趣味のプロジェクトには最適だと実感しました。

2.2. インフラ管理不要

サーバーレスのため、OSやミドルウェアの管理が不要です。セキュリティパッチの適用やスケーリングもAWS側で自動的に行われるため、運用負荷が大幅に下がります。

また、障害時の自動リトライや、スケールアウトも自動で行われるため、インフラの知識がそこまでなくても安心して運用できます。EC2やVPSのようにサーバーの死活監視やメンテナンスを気にしなくて良いのは、精神的にもとても楽です。

2.3. 他の選択肢との比較

最初はEC2やVPSも検討しましたが、コストや運用負荷、スケーリングの柔軟性を考えるとLambdaが最適でした。特に、バッチ処理やAPIのような「必要なときだけ動かす」用途には、Lambdaの従量課金が大きなメリットです。

3. 工夫したポイント

3.1. Docker化

可搬性をもたせたく、Lambdaで動かすならとDocker化しました。

Dockerfileで環境がコードとしてまとまるので、別のパソコンでも動作確認しやすくなります。Lambdaのコンテナイメージ対応を活用することで、ローカルでも本番と同じ環境で動作確認でき、依存パッケージの違いによるトラブルも減りました。

また、将来的にチーム開発や他のクラウドサービスへの移植も容易になります。DockerイメージをECR（Elastic Container Registry）にプッシュし、Lambdaから直接参照できるのも便利です。

3.2. APIのリフレッシュトークン自動更新

Spotifyのアクセストークンは有効期限が短いため、DynamoDBでリフレッシュトークンを管理し、自動的に更新する仕組みを実装しました。

もともとはファイルで管理していたのですが、ファイルの読み書きが難しいので、DynamoDBに変更したというわけです。DynamoDBを使うことで、Lambdaの実行環境が変わってもトークン情報を安全に一元管理できるようになりました。

また、DynamoDBはスケーラブルで高可用性なので、今後ユーザーが増えても安心です。テーブル設計もシンプルで、トークンの有効期限や更新日時なども一緒に管理できるようにしています。

3.3. AWS SAMを使ったデプロイ・テストの工夫

今回の開発では、AWS Lambdaのデプロイやローカルテストの効率化のために AWS SAM（Serverless Application Model） を活用しました。

SAM CLIを使うことで、Lambda関数をローカル環境で簡単にテストできます。Spotify APIへの通信などを本番環境に近い形で動作確認できるため、バグの早期発見や開発効率の向上につながります。

また、SAMテンプレート（template.yaml）でインフラ構成をコード化し、sam deploy コマンド一つでLambdaやIAMロールなどの関連リソースをまとめてデプロイできるようにしました。これにより、手作業による設定ミスを防ぎ、再現性の高いインフラ管理が実現できました。

具体的には以下のように書いています。ここでは使用するDyanmoDBのテーブルやIAMの定義を記述しています。

      Environment:
        Variables:
          SPOTIFY_TOKEN_TABLE: SpotifyToken
          SPOTIFY_HISTORY_TABLE: SpotifyHistory
      Policies:
        - Statement:
            - Effect: Allow
              Action:
                - dynamodb:PutItem
                - dynamodb:GetItem
                - dynamodb:UpdateItem
                - dynamodb:DeleteItem
                - dynamodb:Scan
                - dynamodb:Query
              Resource: 
                - arn:aws:dynamodb:ap-northeast-1:449671225256:table/SpotifyToken
                - arn:aws:dynamodb:ap-northeast-1:449671225256:table/SpotifyHistory
yaml

また、2時間に1回動かすようにしており、２時間に1回という記述ScheduleExpression: "rate(2 hours)"をしています。

  SpotifyHistorySchedule:
    Type: AWS::Scheduler::Schedule
    Properties:
      Name: spotify-history-schedule
      Description: "Spotify再生履歴取得 - 2時間ごとに実行"
      FlexibleTimeWindow:
        Mode: "OFF"
      ScheduleExpression: "rate(2 hours)"
      Target:
        Arn: !GetAtt SpotifyTokenFunction.Arn
        RoleArn: !GetAtt SpotifySchedulerRole.Arn
        Input: '{"action":"fetch_history"}'
yaml

これ以外にもECRのリポジトリだったり、スケジュラーを動かすためのIAMなどもこのファイルで表現できるので、再現性が高くなります。

3.4. 運用・監視の工夫

Lambdaの実行ログはCloudWatch Logsに自動で送られるため、エラーや異常終了があった場合もすぐに気付けます。必要に応じてアラートを設定し、障害時にはメールやSlackで通知が飛ぶようにしています。

また、Lambdaのメトリクス（実行回数、エラー回数、実行時間など）もCloudWatchで可視化できるので、運用状況の把握やパフォーマンスチューニングにも役立っています。

4. 今後の展望

今後は、Spotify以外の音楽サービスとの連携や、取得した再生履歴データの可視化・分析にもチャレンジしたいと考えています。

また、Lambdaの他の活用例として、定期的なデータ収集や通知、APIの自動化などにも応用できそうです。サーバーレスの世界はまだまだ奥が深いので、引き続き色々と試していきたいと思います。

ここまで読んでいただきありがとうございました！Lambdaやサーバーレス、Spotify APIに興味がある方の参考になれば幸いです。