はじめに
（だいぶ前の話になりますが）とあるグローバル案件に参画していた際の出来事です。当時某国にもシステムを展開する必要があったため、現地の某パブリッククラウドサービスで環境を構築しました。当時の某クラウドはAWSなどの主流クラウドほど信頼性や可用性が高くなく、機能も充実していなかったため、苦労する点が多々ありました。今回は一番印象的な出来事を紹介しようと思います。
前提
- 某クラウド上で構築したインフラは基本的に全部Terraformで管理している
ユーザー管理のリソースが勝手に再作成される
契機
- インフラリソースのアップデートを行うため、Terraformコードを追加し、terraform planを実施した
事象
- plan時にsdk errorが発生。エラー内容としては、一部のリソースが実機に存在しないと表示された
- 該当リソースはアップデートを行うリソースとは関係のないリソースで、今まで問題なくTerraformで管理できていた
原因
- 調査を行った結果、tfstate上の該当リソースのuuid（リソースを一意に識別するid）が実機値と一致しなくなったことが判明した
- ユーザー側が該当リソースに対してアップデートを行なっていないため、某クラウドのサポートに問い合わせをすることに
問い合わせの結果
- 某クラウドプロバイダー側が該当サービスに対して実施したアップグレードによって、ユーザー管理のリソースが再作成されたことが判明した
- 再作成によってリソースのuuidがtfstate上の記載と乖離が乗じ、planが通らなくなった
対応
- 再作成されたリソース一覧を整理し、古いリソースのstate rm＆新しいリソースのstate importを実施（ちょっとしたスクリプトを書いたがリソースが大量にあったので結構時間がかかった）
- 某クラウドプロバイダー側が上記作業を実施してくれないのでユーザー側で実施した
（私が考えた）根本原因
- アップグレードに関する事前周知漏れ
- そもそも某クラウドプロバイダー側による事前周知がなかった
- アップグレードによる影響の調査不足
- 某クラウドプロバイダー側が影響の調査を十分に行わずにアップグレードを行なった
- サービス自体の設計がよくない
- なぜアップグレードによってリソースが再作成されなければならないかが不明
おわりに
普段AWSなどの主流パブリッククラウドサービスしか使っていない方には、「こんなこともあるよ」ということをぜひお伝えしたくて本記事を執筆しました。いかがでしたでしょうか！