S3コピー

#!/bin/bash

# S3バケットのパス指定
S3_PATH="s3://your-bucket/path"

# ファイル一覧取得とコマンド生成
aws s3 ls --recursive $S3_PATH | while read -r line; do
   filename=$(echo "$line" | awk '{print $4}')
   case "$filename" in
       *.html)
           echo "aws s3 cp ${S3_PATH}/${filename} ${S3_PATH}/${filename} --content-type \"text/html; charset=utf-8\" --metadata-directive REPLACE"
           ;;
       *.js)
           echo "aws s3 cp ${S3_PATH}/${filename} ${S3_PATH}/${filename} --content-type \"text/javascript; charset=utf-8\" --metadata-directive REPLACE"
           ;;
       *.css)
           echo "aws s3 cp ${S3_PATH}/${filename} ${S3_PATH}/${filename} --content-type \"text/css; charset=utf-8\" --metadata-directive REPLACE"
           ;;
   esac
done > update_content_type.sh

chmod +x update_content_type.sh

system jj event text usage aidd index crawl pii ghc-cc ecs-mi-llm secr

S3へのファイル出力方法に関して再検討したい。

現状は１会話１ファイルで出力してます。
これは、いままでは 音声ID一覧取得API＋音声情報取得API の組み合わせで、結局１件１件会話を取得してきたから、１会話１ファイルのほうが扱いやすいと思ったからです。
ただ、今回、音声情報一覧APIで一括取得する実装になったことで、１ファイルに複数の会話があっても良いように思いました。


最終的に、出力した会話のファイルは以下の目的で利用します。

---
該当日分の会話（いまの設計でもS3の特定のフォルダに配置されてるJSONファイルすべて）を読み込み、
ある一定の項目を抜き出したうえでExcelファイルを１ファイル作成する。
この１つのExcelファイルに、該当日分の全会話が含まれてる。

上記のような処理をするバッチを別途作成予定
---

この目的に照らし合わせた場合に１会話１ファイルがふさわしいのか？を慎重に再検討したい。
性能や、運用・保守面、料金面等検討の軸は複数あると思います。

このバッチは
・１時間に１回動く（ただし、プログラム内部で対向側のエンドポイントにリクエストは最大２５回投げる）
という動きをする必要があることも考慮する（つまり、１時間分の会話のみを抽出するように条件を毎回変更する）必要があることも考慮しないといけません。

このことを考えると、例えば、

1. 現状の実装のまま。つまり、１会話１ファイル。ただし、現状の設計で１時間に１回動く前提で、どうやって抽出条件を変えるか？の検討がされてるかがわかりませんでした。AWS側で制御（引数を可変にするとか？）ですかね？
2. １ファイルですべての会話を保持。ただし、この方法には何個かパターンがあると思う
  2-a. S3の該当日フォルダ内には常に１ファイルのみ配置。そのファイルを上書きしていく。この場合、１時間単位抽出の条件変更の仕組みも考える必要があると思う。
  2-b. S3の該当日フォルダを細分化し、サブフォルダを作って、時間ごとのフォルダを作ってそこにリクエスト結果を保存。別のサブフォルダに１ファイルに纏めたファイルを作成する。両方のフォルダ内のファイルを使って、その時間帯の会話ファイルを上書きする。この場合、１時間単位の抽出条件はS3のサブフォルダ名をベースにすることも可能かも。
2. １ファイルで全会話を保存する場合でも、JSONにするかJSONLにするかは要検討だとは思う。

### Link https://repost.aws/questions/QUzjhLe0bZQ5SdSgurjrno8g/amazon-sns%E3%81%A7%E3%83%A1%E3%83%BC%E3%83%AB%E9%80%81%E4%BF%A1%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AE%E5%AE%9B%E5%85%88%E6%95%B0%E3%81%AE%E5%88%B6%E9%99%90 ### =============================

fix: Athena クエリにパーティション刈り込みを追加し、並列実行時のタイムアウトを解消

- レポートの各クエリに year/month/day パーティション列への直接比較
  （実行時の日付リテラル・上下限つき）を注入。event_time（導出列）だけでは
  パーティション射影の刈り込みが効かず、射影範囲の全列挙（約28,600 個の
  S3 プレフィックス）が 1 クエリ数十秒〜数分の主因だった。並列化で 5 本が
  競合して各クエリが POLL_TIMEOUT（120 秒）を超過し、タイムアウトしていた
- ポーリング打ち切り時に StopQueryExecution でクエリをキャンセル
  （放置クエリ + Scheduler リトライによるワークグループ滞留を防止）
- 根本修正を前提に POLL_TIMEOUT_SECONDS 120→300 / Lambda Timeout 300→600 とし、
  「Timeout > ポーリング上限 + 余裕」の関係をコメントで明文化
- projection.year.range を 2024,2100 → 2024,2050 に縮小（コンソール用
  NamedQuery の列挙数対策。既存環境はスタック出力 PartitionProjectionNote の
  ALTER TABLE 再実行が必要 — architecture.md のチェックリストに追記）
- pytest を 8 件追加（刈り込み述語の境界日・ゼロ埋め・上下限・年跨ぎ・
  タイムアウト時キャンセル）。build.py で生成テンプレートを再生成