今日の日記

出来事を箇条書きで

• Fargateにすると、OSのログの管理が少し変わるらしい。たしかにOSが手元にないので、どうやって計測するんだろう。

• RDSでデータを自動的に保存する仕組みは、s3へダンプをためることではなくって、スナップショット+トランザクションログである。スナップショット＝1日ごとにDB全体を、トランザクション＝約5分毎にS3へ差分用ログをアップロード

• もし手動でバックアップやスナップショットを取る場合はS3に保存したりもする

• “Instance Refresh(AWS)“とは、ASGにあるインスタンスを１台ずつ対象にして、OSの更新などを「稼働を維持したまま」行う方法。稼働が確保されたものに対して接続を振り分けるのを自動でやってくれるので、ダウンタイムが無い。ただし初期OS+User Dataの状態になるので、EC2ホストDBなどのデータは失われるので注意。あと、最低1台の設定だとASGであってもダウンタイムが生じるのは仕方ない。

• DeployerはLaravelを使ってデプロイ作業をするときに便利なツール。さっとやるにはすごく良い。ただ使うインフラやデプロイ方法をもっとカスタマイズしたくなってきたら、Laravelを基準にデプロイするというより、インフラを基準にデプロイしていく。すなわちGithub Actions+AWS(ASG + User Data)のようになっていくのが自然という考え方もある。

• EC2へのデプロイとEC2/Fargateへのデプロイにおいて、アプリケーション側は何か変更が必要なのかというと、特に”.env"が変わる。基本的にローカルに何かを保持するのが難しいので「ファイル保存」の部分は変える必要あり。例えばstorage/appはFargateだと揮発してしまうので、S3にしないといけない。そもそもEC2でもMulti-AZならここは気を付けるべきなので、インスタンスに依存しすぎるべきではない、という点ではまあ同じ。

• 例えば"laravel.log"とかは、Amazon CloudWatch Logsに移管する。具体的にはLaravelアプリケーションの標準エラー出力先をファイルではなく、出力ストリームに書き込み、CloudWatchへつなげるという感じ。.envでLOG_CHANNEL=stderrにする。

• リリースベース管理をFargateでするにはどうするのか？OSならディレクトリを置いておけるけど。→タスク定義ごとに新しいイメージを作成する。“releases/41"が"laravel-app:v41"になるような感じ。v41の"タスクを起動する"のである。

• Fargateだと、2つ以上のタスク定義がある場合、新旧2つのバージョンが共存できるという良さがある。ただしマイグレーションなどが含まれる場合は、RDSとの不整合によって動かないこともある

• じゃあ類似したサービスをいくつか立ち上げるにあたって、VPCの設定ってどうしたらいいか？→VPCを統合するメリットは、ネットワーク構築や管理のコスト、また実金額コストの削減などが挙げられる。しかし、共通設定により障害は一斉に起こるというのと、内部リソースの管理を分離しようとしたときに切り離しにくいというデメリットはある。ちなみにVPC自体の障害というよりは、それを取りまとめるNACLやNAT Gatewayなどの障害を指す。

• FargateではOSの自動更新が行われるが、それを更新したときにアプリケーション障害が起こる可能性はどのくらいあるのか。→Linuxの更新は後方互換性を重視しているので、障害が起こる可能性は低いと見積もる。むしろOS更新時に一時的にタスクが止まるときのヘルスチェックなどを重視すべき。