DevOpsとスノーフレークについて

昨今のIT業界では、DevOpsについて聞かずにいられないほど話題になっています。DevOpsはクラウドの話題を引き継いで業界で注目の新トレンドであり、その話を聞くと伝統的なシステム管理はすでに過去のものになったと思わされるかもしれません。

まず、DevOpsが何を意味するかについて話す必要があります。これはクラウドと同様に、以前の用語が別のものを意味するために乗っ取られることがあるため、混乱する可能性があります。あるいは少なくとも、すでに存在していたものに関連するものを意味するために使われています。伝統的なDevOpsは、開発者と運用の役割の統合でした。1960年代から1990年代にかけて、これがシステムを運用する標準的な方法でした。この世界では、ソフトウェアを書いた人々は一般的にそれをデプロイし、維持する人々でもありました。したがって「デベロッパー」と「オペレーションズ」の統合であり、オペレーションズはシステム管理者の役割の半標準的な用語です。これらの役割は1990年代の「IT部門」の台頭と2000年代まで一般的に分離されていませんでした。それ以来、二つの役割の統合への回帰は、特に現代のホスト型Webアプリケーション状況において二つが連携することで大きな価値を生み出す方法のために、人気が再び高まっています。

今日DevOpsについて語られる場所は、開発者と運用スタッフの厳密な統合としてではなく、クラウドアーキテクチャの自然な拡張としてアプリケーション自体ではなくアプリケーションインフラをコードで定義することにはるかに高い焦点を当てたコーディングへの修正として運用スタッフに変更を加えることです。これは最初は少し混乱するかもしれません。重要なのは、伝統的なDevOpsは今日一般的に起こっていることではなく、新しい「フェイク」DevOpsであり、開発者は開発者のままであり、運用は運用のままですが、運用は開発者が提供するコードを実行するサーバーを管理し続けるための新しい「コード重視」の役割に進化しているということです。

今日重要なのは、システム管理者の役割が二つの関連するが著しく異なる役割に分岐し始めており、そのうちの一つが今日の業界のほとんどによって誤ってDevOpsと呼ばれていることです（業界のほとんどはDevOpsが例外ではなく規範だったとき、そして確かに新しく斬新なものではなかったときを覚えるには若すぎる）。ここでは、これら二つのシステム管理者の役割の側面をDevOpsとスノーフレークのアプローチと呼びます。

各サーバーが「固有のスノーフレーク」として見ることができるため、「スノーフレーク」という用語を使用してシステムの伝統的なアーキテクチャを指します。それらはすべて異なり、少なくとも同一に保つような方法で管理されているわけではありません。これは必ずしもすべてがユニークである必要があるという意味ではなく、単にユニークになる可能性を保持しているということです。伝統的な環境では、システム管理者は各サーバーに個別にログインして作業します。管理タスクを容易にするためのある程度のスクリプト作成は一般的ですが、その核心は個々のシステムで多くの時間を費やすことを含む役割です。

スノーフレークアーキテクチャの管理を容易にすることは、多くの場合、合理的な方法でシステム間の差異を最小化しようとする試みを伴います。これは一般的に、すべてのサーバーのインストールを異なるOSやバージョンにするのではなく、単一の標準オペレーティングシステムとバージョン（Windows 2012 R2またはRed Hat Enterprise Linux 7など）を選択することから始まります。この標準化は基本的に見えるかもしれませんが、今日でも多くのショップにはこの標準化が欠けています。

次のステップとしては、一般的に標準的なデプロイ方法論やゴールドマスターイメージを作成して、すべてのシステムが同じベースオペレーティングシステムとすべてのベースパッケージ（システムカスタマイズ、監視パッケージ、セキュリティパッケージ、認証設定および同様の変更を含むことが多い）を持つように、標準的かつ均一にデプロイされるようにします。これはすべてのシステムに共通の出発点を提供し、乖離を最小化します。しかし技術的には標準的な出発点のみを確保し、時間の経過とともに設定の乖離は予期する必要があります。

これらのステップを超えて、スノーフレーク環境は通常、カスタムの特注管理スクリプトや管理ツールを使用して、時間の経過とともにシステム間の標準化を維持します。システム間に存在する共通点が多ければ多いほど、保守やトラブルシューティングが容易になり、管理スタッフが必要とする知識が少なくなります。標準化が多ければ多いほど、驚きが減り、未知数が少なくなり、テスト機能が大幅に向上します。

良い実践とツールを持つ単一のシステム管理者環境では、スノーフレーク環境は高度な標準化を実現できます。しかし多くのシステム管理者を持つ環境、特に多くの地域から24時間サポートされ、多数のシステムがある環境では、非常に精勤な実践を持ってしても標準化は非常に困難になる可能性があります。そして、それは異なる役割を果たすシステムで異なるパッケージおよび場合によっては異なるパッケージバージョンが必要だという明らかな問題を取り組む前の話でさえあります。

DevOpsアプローチはクラウドアーキテクチャモデルから有機的に成長します。クラウドアーキテクチャは、プログラムのインターフェイスまたはAPIを通じて制御される、自動的に作成および自動的に破壊される、広く同一のシステム（少なくともグループ内では）を中心に設計されています。このモデルは、明らかに、システム管理者の手動作業を通じてではなく、管理システムを通じて一元的に制御されることに適しています。このモデルでは手動管理は事実上不可能であり、完全に非実用的です。個々のシステムはスノーフレークモデルのようにユニークではなく、乖離が生じると深刻な問題が生じます。

クラウドアーキテクチャの世界から生まれてきたアイデアは、システムアーキテクチャはサーバー自体ではなく、「コードで」中央定義されるべきというものです。これは最初は混乱するように聞こえますが、より深く見ると多くの意味があります。このモデルをサポートするために、まだ本当に標準的な名前を持たないが、しばしばシステム自動化ツール、DevOpsフレームワーク、IT自動化ツール、または単に「インフラストラクチャ・アズ・コード」ツールと呼ばれる新しいタイプのシステム管理ツールが登場し始めています。このレルムの一般的なツールセットにはPuppet、Chef、CFEngine、SaltStackが含まれます。

これらの自動化ツールセットの背後にあるアイデアは、すべてのシステムを管理し制御するために中央サービスが使用されることです。この中央機関は、システムがどのように見え、どのように動作するかのコードベースの記述によって個々のサーバーを管理します。Chefの世界では、これらはキュートに「レシピ」と呼ばれますが、比喩はうまく機能します。各システムのコードには、どのパッケージとパッケージバージョンをインストールする必要があるか、どのシステム設定を変更するか、ボックスにコピーするファイルなどの情報が含まれる可能性があります。多くの場合、これらのデプロイや変更に関する決定は、潜在的に複雑なロジックを通じて処理されるため、マークアップやテンプレートなどのより単純なものではなく、実際のコードが必要です。システムはその後、役割によってグループ化され、グループとして管理されます。「Webサーバー」の役割は、一連のシステムにApacheとPHPをインストールし、メモリのスワップを非常に少なくするよう設定することかもしれません。「SQLサーバー」の役割は、MS SQL Serverとそのアプリケーションにのみ使用される特別なバックアップツールをインストールし、メモリをSQLサーバーのプールに必要なように調整するよう設定することかもしれません。これらは単なる例です。通常、組織は非常に多くの役割を持ち、一部は「Webサーバー」のように汎用的であり、他はより特定のアプリケーションをサポートするためにはるかに特定的です。役割は一般的に重ねることができるため、システムは「Webサーバー」と「Javaサーバー」の両方であり、両方の組み合わせたニーズを満たすことができます。

これらの標準定義は、一つの役割または別の役割に属するものとして指定されたシステムが自動的に「自分自身をビルド」できることを意味します。新しいシステムは管理者によって要求されるか、または容量監視システムが役割に追加容量が必要と判断し、いかなる人間の介入もなしに自動的に新しいサーバーインスタンスを生成する可能性があります。システムが要求された時点（人間または自動的に）で、役割が指定され、システムは自動化フレームワークによって、完全に設定され最新の「ノード」に変換されます。人間のシステム管理の介入は必要ありません。プロセスは速く、シンプルで、最も重要なことに、完全に再現可能です。

コードでシステムを定義することには、自明ではない結果があります。一つはシステム全体のバックアップが不要になることです。最小限の努力でほぼ即座に再作成できるシステムをなぜバックアップするのでしょうか？データベースシステムのローカルデータはバックアップが必要ですが、データベースデータのみであり、システム全体ではありません。これはバックアップインフラへの負担を大幅に軽減し、リストアプロセスを速く、より信頼性の高いものにすることができます。

コードですでに定義されているシステムに必要なドキュメントは非常に最小限です。スノーフレーク環境では、システム管理者はすべてのホストに特有のドキュメントを保持し、そのドキュメントを手動で維持する必要があります。これは非常に時間がかかり、エラーが発生しやすいです。中央コードによって定義されたシステムはほとんどまたはまったくドキュメントを必要とせず、ドキュメントは個々のノードレベルではなく、グループレベルで処理できます。

コードで定義されたシステムのテストも簡単に行えます。コードでシステムを作成し、テストし、そのテストと同じようにその定義を本番環境に移行するときに、本番システムがテストと同じように繰り返し作成されることを知ることができます。スノーフレーク環境では、これを行おうとするテスト実践が非常に一般的ですが、手動作業によって行われるため、ずさんで正確に再現性がなく、繰り返し可能性を模倣する方が実際にそれを目指すよりも速いとポリティクスが示すことが非常に多くあります。コードで定義されたシステムはこれらの問題を迂回し、テストをはるかに価値あるものにします。

各役割内に存在するノード数を定義する必要がある以外、システムはゼロからアーキテクチャ全体を自動的に再プロビジョニングすることができます。災害後の再構築やセカンダリサイトの立ち上げは非常に迅速かつ簡単に行えます。また、Amazon、Microsoft、IBM、Rackspaceなどの企業のものを含む、ローカルにホストされたシステムとリモートにホストされたシステム間の移行は非常に簡単です。

もちろん、DevOpsの世界では、最も極端なレベルの自動化を可能にするためにクラウドアーキテクチャを使用することに大きな価値がありますが、これらのタイプのツールを活用するためにクラウドアーキテクチャを使用することは不必要です。そして、もちろん、コードで定義されたアーキテクチャを部分的に使用しながら、手動管理をハイブリッドアプローチとして実装することもできますが、これは個々のシステムに対してはほとんど推奨されません。二つのアプローチが必須とされる場合、スノーフレークとして管理される環境とDevOpsとして管理される環境の二つを持つ方が一般的にはるかに良いです。これにより、はるかに優れたハイブリダイゼーションが実現します。私はこれが、各々が非常にユニークでありながらすべてのノードが二つの可能な設定のいずれかを使用して同一で交換可能であったため、DevOpsの方法で管理された数万ノードの専用環境を持つ、数万台の「スノーフレーク」サーバーが各々が非常にユニークなエンタープライズ環境で非常にうまく機能するのを見ました。ハイブリダイゼーションは非常に効果的でした。

しかしDevOpsアプローチには重大な注意点もあります。この方法でシステムを管理するために必要なスキルセットは、伝統的なシステム管理に必要なものよりはるかに大きく、少なくともすべての伝統的なシステム管理の知識が引き続き必要であり、さらにPythonやRubyなどの現代的な言語の確固たるプログラミング知識と特定のフレームワークの知識も必要です。この拡張された知識ベースの要件は、DevOps実践者が希少なだけでなく高価でもあることを意味します。また、大学教育が既にシステム管理者と開発者の両方を専門の世界に準備するには遠く及ばず、現在DevOpsモデル下で作業する卒業生を準備するにはさらに遠いことを意味します。

これら二つの陣営で働くシステム管理者は、すべてのシステムが自分自身の型に合わせる必要があると見る傾向があります。新しいDevOps実践者は、スノーフレークシステムがレガシーであり更新が必要だと信じることが多いです。スノーフレーク（伝統的な）管理者は、「インフラストラクチャ・アズ・コード」運動を愚かで、不必要なオーバーヘッドを持ち、過度に複雑でニッチすぎると見る傾向があります。

現実は、両方のアプローチに非常に大きなメリットがあり、両方とも非常に実行可能であり続けるということです。両方ともまったく異なるワークロードに対して意味があり、大規模な組織では、何らかのハイブリダイゼーションを通じて両方が一般的に見られると予想されます。通常非常に少数のサーバーしかなく、クラウドアーキテクチャを正当化するためのスケーリングのレバレッジがなく、システム間の高い格差があるSMB市場では、DevOpsが機能するために必要なオーバーヘッドと追加のスキルが非現実的または取得不可能なため、DevOpsはほぼ無期限に規範の外に留まると予想します。大規模な組織は自社のワークロードを検討する必要があります。多くの伝統的なワークロードと従来のソフトウェアの多くは、特にクラウド自動化のDevOpsアプローチに適していないため、ハイブリダイゼーションか、またはシステムごとに非常に高レベルのコーディングが必要となり、DevOpsモデルを正当化できなくなります。しかしWebアーキテクチャに構築されたワークロードや非常にうまく水平にスケールできるワークロードは、スケールでDevOpsモデルから大きな恩恵を受けます。これは大企業や外部消費のためのホスト型アプリケーションを生産している可能性が高いより小さな企業にも当てはまる可能性があります。

このアプローチの違いは、たとえば米国では、米国のほとんどがスノーフレーク管理モデルに焦点を当てたままの企業で構成されており、一部の東海岸企業がDevOpsモデルを効果的に評価し始めてその方向に動き始める可能性があることを意味します。しかし西海岸では、より現代的なアーキテクチャとホスト型アプリケーションと外部消費のためのアプリケーションへのより大きな焦点が経済を動かす要因であり、DevOpsはすでに新参者から成熟した確立された標準へと移行しています。DevOpsとスノーフレークのアプローチは、IT一般が異なるスキルセットが異なる地域に移行するのを見るのと同様に、このように地域によって大きく分離されたままである可能性が高いです。伝統的なITが比較的うまく機能していないオースティンのような市場でDevOpsが根付き始めることは驚くべきことではないでしょう。

どちらのアプローチが良いとか悪いということではなく、システムをプロビジョニングする二つの非常に異なる方法と、それらのシステムの二つの異なる基本的なニーズをサービスする二つの異なるアプローチです。しかし、クラウドアーキテクチャとDevOpsモデルの台頭により、既存のシステム管理者がDevOpsモデルが何を意味し、いつ適用されるかを理解して、独自のワークロードとユニークなニーズを正しく評価できるようにすることが非常に重要です。伝統的なスノーフレークシステム管理の世界の大部分は、時間をかけてDevOpsモデルに移行していきます。業界においてこれら二つのモデルのバランスの定常状態に達するまでには、まだ非常に遠い道のりがあります。

Originally published on the StorageCraft Blog.