実行環境に応じたバイナリの作成が重要
振り返り
学び
Discord上で、対面活動を定期アナウンスするBotを作成した。
以下、振り返り。
実装した機能
メンション付きで全員に通知。
Botがリアクションをあらかじめセット → メンバーは押すだけで反応できる
AWS Lambdaにデプロイし、クラウド環境で定期実行（手動実行ではない）
実装の流れ
１．手動実行でBotの動作確認
Discord APIとやり取りできるか確認
メッセージが正しく投稿されるか確認
２．AWS Lambdaに対応する形へコード変更
WebSocket通信やそれに関した部分の消去
handler関数をエントリーポイントに設定
３．AWS Lambdaへのデプロイ準備として、バイナリファイルの作成
実行環境に合ったバイナリが必要
Lambda用のアーキテクチャでビルドする（Windows環境でのビルド方法）
４．デプロイ & テスト
zipに圧縮したバイナリをAWS Lambdaにアップロード。
テスト、デバック。
正しい動作確認後、トリガー設定（CloudWatch Eventsでスケジュール実行を設定）。
※ UTC基準より、日本時間の22時に実行する際は cron(0 13 ? MON,THU )
学び
１．バイナリの実行環境を考慮する重要性
WindowsとAWS Lambdaの違い
開発環境（Windows）：GOOS=windows、GOARCH=amd64
本番環境（AWS Lambda）：GOOS=linux、GOARCH=arm64
Windowsでビルドしたバイナリ（`.exe`）は Linuxでは動かない ため、 Linux & ARM64用のバイナリを作成する必要あり。
GOARCH や arm64とは？
GOARCH（Go Architecture） → ターゲットアーキテクチャ（amd64, arm64 など）
GOOS（Go Operating System） → ターゲットOS（windows, linux など）
Goコンパイル時は、他の環境下でも動作するよう、どのOS・CPUアーキテクチャ向けにビルドするか決める必要がある。 AWS Lambdaではarm64を使うため、Windows上で GOARCH=arm64 と GOOS=linux を設定してビルドする。
２．WindowsでのLinux向けバイナリ作成方法
Windows上でのバイナリをビルドすると、デフォルトは「GOOS=windows, amd64」のバイナリになってしまう。
↓
Linux + ARM64向けのバイナリを作成（クロスコンパイル）するには、以下のようにプロセス変数を設定する必要あり。
～～WindowsのPowerShellでの、クロスコンパイル方法～～
$env:GOOS = "linux"
$env:GOARCH = "arm64"
『このように、PowerShellでプロセス変数を使い、一次的にGoのビルド対象をWindows → Linux へ変更している』
（$env：PowerShellのシェル変数（プロセス変数） を設定する書き方）
３．シェル変数設定後のgo buildコマンド
go build -tags lambda.norpc -o bootstrap main.go
-o bootstrap → 出力ファイル名を bootstrap に指定
AWS Lambda では、Goのバイナリ名を bootstrap にする必要がある。main.go → コンパイル対象のGoファイル
-tags lambda.norpc → AWS Lambdaで RPC通信を無効化→Lambda用にいい感じにしてる、なくてもよい。
結論
Windowsでの開発は AWS Lambdaと環境が違う ため、ビルド時に 環境変数を設定することがめちゃ大事。
Windowsでクロスコンパイルする際は、プロセスごとに毎回Powershellで設定すること。
