背景
CloudFormationでEFSのマウントターゲットを作成しようとしたら、以下のようなエラーが発生しました。
fsmt-xxxxxxxxxxxxxxxx already exists in stack
fsmtはおそらくマウントターゲットのことであろう。
マウントターゲットが既に存在している？？
どういうことだろうか。
1AZ, 1Target
今回作ろうとしていたもののアーキテクチャは以下のようなものである。
１つのAZに2つのプライベートサブネットが存在し、それぞれにapp1とapp2が存在する。
そして、それぞれのサブネットにマウントターゲットを設置している。
公式サイトを見てみると、以下のような記述があった。
Amazon EFS ファイルシステムを作成した後、マウントターゲットを作成できます。標準ストレージクラスを使用する Amazon EFS ファイルシステムの場合は、AWS リージョン の各アベイラビリティーゾーンにマウントターゲットを作成することができます。
これだけだとAZに1つしか作れないのか、複数作れるのかわからない。
英語版を見てみる。
For Amazon EFS file systems that use Standard storage classes, you can create a mount target in each Availability Zone in an AWS Region.
[a mount target in each Availability Zone] とあるが、これは1AZにつき1つを表しているのだろうか。
複数作れるのなら[mount targets]になりそうだが、ちょっと微妙なところ...
ただ、実際に1AZにつき1つのマウントターゲットというアーキテクチャ、つまり以下のような構成にCloudFormation用のyamlファイルを修正したところ、エラーは解決した。つまり、1AZにつき、つくれるマウントターゲットは1つなのであろう。
EFSはフェイルオーバーしない
今回は1AZでの話であった。
これとは別に、本記事の調査を進めていくうえでフェイルオーバーの話が出てきていたので軽くメモ。
マウントターゲットには、AZを跨ぐフェイルオーバー機能が実装されていないらしい。
そのため、フェイルオーバーを実現したい場合は、OSレイヤー以上で障害を検知してフェイルオーバーを実現する仕組みが必要とのこと。詳しくは以下のブログを参照のこと。
https://dev.classmethod.jp/articles/efs-failover/
感想・まとめ
日本語サイトだけでは正確な理解ができないということを身をもって知りました。厳密な一次資料は英語版ということは覚えておきたいですね。（ちなみに、EKSのような更新が頻繁に起きているサービスは、翻訳の精度という以前にそもそも中身が違っていることもあります。）
あと、drow.ioは便利すぎる。まだちょっと使い慣れていないところもあるが、それでもかなり図が書きやすい。
議論の際は、特にアーキテクチャの議論の際は図を用いて議論することが大事という話は多くの先輩から聞くし、実際にそうだと思う。息をするように図が描けるようになりたい。