継続的進化のための設計

During his keynote at QCon New Yorkにて、Eric Brewer氏は、継続的デリバリから高速で安定的な継続的進化へ進むこと、独立した構築ステップによるシステムの不変的なモデル定義を要求することについて話をした。Googleでの氏の計算インフラ設計チームはKubernetesのパッケージマネージャであるHelmを使って本番の配置を試す前に新しい配置モデルの構築と検証を行っているが、この考え方は技術に依存しない。Brewer氏が説明するパターンは、配置の流れの中の各ステップでの不変性に依存しており。クラウドでのソフトウエアの設計上の重要な検討事項になる。

配置プロセスはシステムの不変モデルの構築を定義するための独立したステップを挿入することで改善される。配置の流れの各ステップが不変性に依存しているため、システム全体の高速で安定的な進化が見込まれる。QCon New Yorkでのこの講演で、Eric Brewer氏はGoogleでのソフトウエアの進化の改善と関連する設計の課題について話した。同社はKubernetesのパッケージマネージャであるHelmを使っているが、彼のチームの考え方自体は技術に依存しないものであり、どのようなクラウドネイティブなソフトウエアにも導入できる。

Brewer氏は不変性のある構成要素がどのようにしてテスト可能で再現可能な、機能のカプセル化を提供するのかについて説明した。下の氏のスライドに示されるように、コンテナにバイナリがパッケージ化され、コンテナはポッドに設置される。複製されたポッドがサービスの構成要素になる。新しい構築ステップは配置に先立って、システムで使われるサービスのモデルを定義する。

Brewer氏は、"構築"という言葉は配置プロセスにおいて新出の言葉であることを認めている。この言葉はふたつのステップに分解される。まず、配置対象のモデルを定義し、トポロジ、システムの構成、物理リソースを特定すること。そして、このモデルは配置対象のグラフを構築し、それぞれの個別のコンポーネントの作成知識からは分離される。オフラインで配置グラフを構築するのは全くリスクがなく、実装から完全に切り離されている。実際の配置の前であり、エラーにはならずに、決定的で繰り返し可能でテスト可能なのだ。

Brewer氏は構築コードを配置時ではなく構築時に実行することを強調する。これは構築コードを書くための新しい宣言的なフレームワークを要求する。言語としては、配置の自動化で使われている典型的な汎用スクリプト言語というよりは、この構築というタスクだけに特化した言語だ。Brewer氏がこのプロセスを構築と好んで呼ぶのは、それぞれの配置型がオブジェクトのコンストラクタのように引数を受け取るからだ。この場合は、配置型はフロントエンドやバックエンドの監視などのシステムのコンポーネントであり、引数はどのようなタイプのフロントエンドを構築するを決める。構築のプロセスは追加可能であり、ひとつの型のコンストラクタは他のコンストラクタを呼ぶ場合もある。ロードバランサやオートスケーラー、ディスクのようなプリミティブな型に依存する場合もある。

配置の意図を定義することで現在のシステムと望ましい状態の間の不一致を観察するプロセスが生まれる。状態(意図)の変化の理由に関わらず、強靭なシステムは望ましい配置のゴールが達成でき維持できることを保証するためのアクションを取る。

皮肉なのは不変性はソフトウエア進化の安定的なプロセスの必要な基礎であることだ。より多くの変化が起きれば起きるほど、同じ場所に止まる必要性も増していく。