【解説】
「イミュータブル」とは「変更不可能な」という意味で、言い換えると「一度作成したら、その状態を変えることができない」と表現することもできます。反対語は「ミュータブル (変更可能な)」となります。
現実世界の例を出してみましょう。例えば「重要な書類を書く場面」を想像してみるのはいかがでしょうか ? ボールペンで書類を書くことを「イミュータブル (変更不可能な)」だとすると、鉛筆で書類を書くことを「ミュータブル (変更可能な)」と考えることができます。
【メリット】
1. 書類を書き換えられなくなる
ボールペンで書類を書くことにより、書類を書き換えられなくなるというメリットがあります。重要な書類のほとんどはボールペンで書くことにより、書いた内容を保証しています。これは「一度書いた書類の状態を変えることができない」と言い換えることもできます。提出した重要な書類を勝手に書き換えられてしまったら困ります。
2. 書類が汚れない
例えば、住所を書き間違えてしまうこともあります。そのときに鉛筆で書類を書いていれば、繰り返し書き換えられるため便利に感じるかもしれません。しかし、実際には消しゴムを使って消すことになります。消そうと思っても「キレイに消えなかったり」、消えるには消えたけど「消しカスが大量に出てしまったり」、繰り返し書き換えることにより、書類が汚れてしまいます。書き換えによって書類が汚れないという点もメリットの 1 つと言えます。
【まとめ】
本記事では、重要な書類を書く場面を比喩に「イミュータブル」を紹介しました。実際のワークロードでは、例えば Amazon EC2 インスタンスを「イミュータブル」に運用し、修正をする場合には新しくインスタンスを作り直せる仕組み作りが重要です。
【所感】
イミューダブルインストラクチャとは、インフラ（OS、ミドルウェア）へのパッチ適用は一切行わず、脆弱性が見つかったら、脆弱性対策が行われた最新版のインスタンスに移ることで脆弱性対策を行うということである。
つぎはぎでパッチ適用を行う事が将来的なシステムの安定化に危害を及ぼすという考え方で、IaaSならではの発想である。
実際はOSやミドルのバージョンが変わっちゃうとその上のアプリも影響を受けてしまうため、運用工数といった観点では地道にパッチ適用するのと変わらない気がする。
ただ、脆弱性対策の観点でこのようなアプローチがあるというのはとても勉強になった。
【参考】
https://aws.amazon.com/jp/builders-flash/202005/metaphor-immutable/