proxmox.blog

どのサーバーで何が起きたかを記録し、CloudWatchなどで状態を確認できる。更新がちゃんと終わったか、どのステップでエラーがあったかを一目で追跡可能。大規模デプロイでも安心して管理できるんだ。

デプロイに使うファイルやパッケージをS3やCodeCommitから持ってこれる。Gitリポジトリに置いてあれば、そのまま自動で引っ張ってEC2に配布できるし、複数のアプリを一度に更新するのも簡単なんだ。

デプロイが成功したか失敗したかをSNSやメールでお知らせしてくれる。いちいちコンソールを見に行かなくても結果がわかるし、失敗時にすぐ対応できる。開発チーム全員で情報共有するのにも便利だね。

デプロイ中にエラー率や応答時間が基準を超えたら自動でストップ、あるいはロールバックする仕組み。運用者が気付く前にシステムが安全に戻してくれるから、本番へのダメージを最小化できるんだ。

ロードバランサーを使って、新旧アプリへのアクセス割合を調整する。たとえば新アプリがOKなら割合を増やし、ダメなら戻す、とコントロールできる。Blue/GreenやCanaryデプロイでよく活用される機能なんだ。

時間をかけて“均等に少しずつ”トラフィックを新Lambdaへ移行する仕組み。例えば10分ごとに10%ずつ増やすとか設定できる。急にガラッと変えないから、トラブルがあってもすぐ気づいて対処できるんだ。

リクエストの一部だけ新しいLambdaに流して、問題ないか様子を見る方法。徐々に配分を増やして最終的に完全移行するから、大きなリスクを避けながら新バージョンを導入できるよ。

今使っている同じサーバー内でアプリを上書きするデプロイ方式。追加の環境を用意しなくていいぶん簡単だけど、本番を止める時間があったり、失敗するとすぐ影響が出たりする。一長一短なんだ。

新しい環境(Blue)を用意して、テストして問題なければ一気にトラフィックを切り替える手法だよ。失敗してもすぐ元に戻せるし、ユーザーに影響も少ない。安全にリリースしたいときによく使われるんだ。

デプロイの前後で“スクリプトを実行”するなど、特別な処理を差し込める仕組み。たとえばバックアップを先にとる、終わったらログを整理するなど、自由にカスタマイズ可能。柔軟な運用ができるんだ。