#gcp

RailwayがGoogle Cloud Platform（GCP）のアカウント停止に巻き込まれ、約8時間の大規模障害が発生した 影響はDashboard、API、ログイン、ビルド、デプロイに及び、最終的に全リージョンのワークロードが到達不能になった 直接の原因はGCP側の誤った自動処理だったが、Railway側にも「単一障害点」を作ってしまう構成上の課題があった キャッシュが効いていた間は一部の環境が生きていたが、route cacheの期限切れで障害が全体へ連鎖した Railwayは今後、Google Cloudへの依存を縮める、true mesh化する、database shardをAWSとMetalへ広げるといった対策を進める 個人的には、これは「クラウドは便利だが、依存の置き方を雑にすると一発で痛い目を見る」という、かなり教訓の大きい事故だと思う Railwayが公開したIncident Reportによると、2026年5月19日、同社は**Google Cloudの誤った処理により、production account

Terraformをローカル実行からGitHub Actions実行へ移した話 Pull Request時に `fmt`・`validate`・`plan` を回すことで、変更を先にレビューできる Applyは手動承認つきにして、勝手に本番変更されないようにしている 認証は Workload Identity Federation を使い、サービスアカウントJSONキーを置かない Terraform state は Google Cloud Storage に置き、チーム運用しやすい形にしている この記事は、GCP上のTerraform運用を「ひとりでローカルから叩く形」から、「GitHub Actionsで安全に回す形」に進化させる実践例です。 元記事の著者は、以前のラボではローカル端末でこんな流れだったと書いています。 `terraform plan` `terraform apply` 学習用途ならこれで十分です。 でも、少し実務っぽくなると話は別です。インフラ変更は、アプリコード以上に事故が怖い。うっかりVPCを消したり、