Snowflakeサーバー

本番サーバーの稼働を維持することは、厄介な作業です。オペレーティングシステムやその他の依存ソフトウェアが適切にパッチ適用され、最新の状態に保たれていることを確認する必要があります。ホストされているアプリケーションは定期的にアップグレードする必要があります。環境を効率的に実行し、他のシステムと適切に通信できるようにするために、構成変更が定期的に必要になります。これには、コマンドラインの呼び出し、GUI画面間の切り替え、テキストファイルの編集など、さまざまな方法が混在します。

その結果、スキーリゾートには良いがデータセンターには悪い、独自の「スノーフレーク（雪片）」が生まれます。

スノーフレークサーバーの最初の問題は、再現が困難であることです。ハードウェアに問題が発生した場合、同じ機能をサポートする別のサーバーを起動することが困難になります。クラスタを実行する必要がある場合、クラスタのすべてのインスタンスを同期させることが困難になります。テストのために本番環境を容易にミラーリングできません。本番障害が発生した場合、開発環境でトランザクション実行を再現して調査することはできません。[1]

スノーフレークのディスクイメージを作成することで、ある程度はこの問題を解決できます。しかし、そのようなイメージには不要な構成要素や間違いなどが蓄積されやすく、永続化します。

しかし、スノーフレークの真の脆弱性は、変更が必要になったときに現れます。スノーフレークはすぐに理解しにくくなり、修正も難しくなります。わずかなソフトウェアのアップグレードでも、予期しない波及効果が発生します。どの構成部品が重要で、どれが何年も前に初期設定のままのものなのかが分からなくなります。その脆弱性から、長くストレスのたまるデバッグ作業につながります。監査要件を満たすためには、手動プロセスとドキュメントが必要です。これが、重要なソフトウェアが古いオペレーティングシステム上で動作していることが多い理由の一つです。

スノーフレークを回避する良い方法は、サーバーのオペレーティング構成全体を何らかの自動化されたレシピ形式で保持することです。最近では、PuppetとChefの2つのツールが非常に人気があります。どちらも、ドメイン固有言語でオペレーティング環境を定義し、それを特定のシステムに簡単に適用できます。

レシピを使用する目的は、サーバーを簡単に再構築できる（イメージングでも可能ですが）というだけではありません。構成を簡単に理解できるため、より簡単に修正できるようになります。さらに、この構成はテキストファイルであるため、バージョン管理に格納し、そのメリットを活用できます。

サーバーへの直接的なシェルアクセスを無効にし、バージョン管理からレシピを実行することですべての構成変更を強制的に適用すれば、環境へのすべての変更がログに記録される優れた監査メカニズムが実現します。このアプローチは、規制された環境で非常に役立ちます。

アプリケーションのデプロイメントも同様のアプローチに従うべきです。完全に自動化され、すべての変更がバージョン管理されます。スノーフレークを回避することで、テスト環境を本番環境の正確なクローンにすることがはるかに容易になり、構成の違いによって発生する本番バグを削減できます。

スノーフレークを回避していることを確認する良い方法は、Phoenixサーバーを使用することです。バージョン管理されたレシピを使用してサーバー構成を定義することは、継続的デリバリーの重要な部分です。

参考文献

Visible Ops Handbookは、スノーフレークの危険性とその回避方法について述べた先駆的な書籍です。継続的デリバリーでは、このアプローチが健全なビルドとデリバリープロセスの必要不可欠な部分であることについて説明しています。しかし、真のアーティストはスノーフレークを好むでしょう。