イミュータブル容易化設計

クラウドや継続的デブロイの文脈でImmutable Infrastructureが語られることが増えてきました。Immutableとは「不変」と言う意味で、インフラを作成後変化させないことで、いつでも初期状態に戻せ、簡単に置き換えられる状態にしておくことです。

クラウドがなかった頃は、ハードウェアの立ち上げからOSの起動までに多くの時間が必要でした。多数のマシンでネットワークを組まない限りは、その後の設定やアプリケーションのデプロイに時間がかかっても大きな問題ではありませんでした。

しかし、クラウドを用いると手作業でも簡単にインスタンスを作成できますし、CLIを使ったスクリプトやChefなどを用いると簡単に作成できます。それに伴ってデプロイ作業もトータルで効率化したくなるでしょうし、逆にデプロイを自動化したならそのターゲットも自動化したくなるでしょう。

しかし、これらの延長上でイミュータブルを実現しようとすると、大きな工数が必要になる場合があります。 あらかじめデータの配置や運用を考慮した設計がされていないからです。ここでは

　　イミュータブル = リセット + サイドエフェクトの分離と保存

と定義して、どのような設計が必要かを考えてみます。

リセット：常に初期状態を再現できる

リセットは最初の状態に簡単に戻せる仕組みで、古くから計算機にありました。電源の入り切りではなく、独立したボタンとして存在することで想定外の状態から復旧することができます。

リセットが一般に認識されたのは、ファミコンの登場からでしょう。やがてソニーのVHSデッキにもリセットボタンがつけられるようになり、当時は組み込み屋さんだった私はその割り切りに驚いたものです(業務系では業務時間外やバックアップなどのメンテナンスのタイミングで定期的な再起動をしていることもあるようです）。

初期状態の再現

初期状態の再現を考えると、以下のようなレベルがあるでしょう。

1. 考えながら手作業
2. scriptコマンドなどで履歴を残す
3. 手順書を作成する
4. 汎用のスクリプトを作ってから実施する
5. 自動化ツールの導入

下に行くほど初期状態の再現が容易にできています。人間は失敗する動物ですので、考えることが少なく、単純な操作で再現できることが望ましいでしょう。

ここで、効率を考えるなら必ずしも自動化ツールが最適ではないことを考慮してください。一度だけの作業なら、手作業であっても並列作業やパイプラインによって効率を上げることが可能だからです。初期状態の再現性を高めると言う視点が重要です。

初期状態に確実に戻るなら、その方法が運用のリセットボタンになります。変な状態になっても特定の状態に確実に戻すことができます。

サイドエフェクトの分離

サイドエフェクトとは状態を持つことです。ソフトウェアに関係するデータは、不変な部分、変化するが保存の不要な部分、変化して保存の必要な部分、の３つがあります。これらが混在した状態だと運用が難しくなります。

AWSならそれぞれ、インスタンスイメージ、エフェメラルディスク、データベースやEBS・S３などにあたります。UNIX系のOSのパーティションもそのような分類になっていてバックアップが容易になっています。

これらを混ぜてしまうと管理が混乱します。プライベートのLINUXマシンでディスクがあふれて、一時しのぎで異なる分類のパーティションを使ってしまって面倒なことになったのは私だけではないでしょう。

サイドエフェクトの分離は運用でもある程度可能ですが、それぞれの配置場所をソフトウェアの設計時から意識して分離して、設定できるようにしておく方が良いでしょう。

状態の保存

状態を分離したサーバのバックアップは全体の保存と差分の保存を組み合わせます。常にフルダンプの様な全体の保存をしていれば特定の状態をいつでも取り出せる様になりますが、時間がかかり、データ量も膨大になります。実際の運用を想定してコストと安全性、利便性バランスをとります。

動画の圧縮からバランスの取り方を考えてみましょう。静止画を時間順に並べることで動画を作れますが、動画ではGOPと呼ばれる単位で動画を区切ることでデータ量を減らしています。GOPの期間が長いとデータ量は少なくて済みますが、何らかのエラーがあると次のGOPの先頭にある静止画までのデータを見ることができなくなります。そこで、許容できる時間で復旧できるように、一貫性のあるデータ一式（静止画）を一定のの期間ごとにはさみます。また、差分が大きくなる場合にはより効率の良い静止画を挟んでGOPを分けることも行われます。

サーバーに当てはめると定期的に全体の保存をとることが必要なほか、大きな修正時にも全体の保存をすることになります。差分の作業で済むからといってそれだけで済まさず、warファイルやDDLを用意しておくなど、全体に作り直しておくと管理が容易になります。

まとめ

イミュータブル容易化設計を考えてみました。インフラを作成後は変化させないことで、いつでも初期状態に戻せ、簡単に置き換えられる状態にするには

• 初期状態が容易に再現できるように、運用のスクリプト化を進める
• 状態を持つ部分（サイドエフェクト）を分離する
• 復旧を考慮して特定の状態を取り出せるようにする

といったことが必要です。初期化状態で運用できる(Immutableな)部分がリセットできるだけでなく、それ以外の部分も問題なく運用できることが重要です。安定して運用ができたなら、徐々にImmutableな部分を増やせるでしょう。

Immutable Infrastructureの考え方は特定のツールがなければできないものではなく、その考え方を踏まえれば、スクリプトなどでもかなりのことができるでしょう。

Immutable Infrastructureはクラウド環境のようにサーバの構築が容易な場合や、多くの台数を用意する場合には非常に有効な考え方です。立ち上げ時の負担が減るほか、トラブル時の対処が大きく改善されるでしょう。

その反面、サーバ数が少ない場合や自前サーバの場合などでは、効率はそれほど良くないかもしれません。そのような場合は以前紹介したYggdrasil（ゆぐどらしる）の利用するなど、より良い方法を設計したいですね。

いずれにしろ、力技で頑張ることだけが唯一の方法であってはいけません。神経をすり減らすのではなく、無駄な作業を減らして技術者らしく「楽」をしましょう。