古賀政純「Dockerがもたらすビジネス変革」

DockerでIT部門を悩ます本番環境の更新を一切放棄する - (page 2)

古賀政純(日本ヒューレットパッカード)

2017-01-11 07:00

コロンブスの卵「イミュータブル・インフラストラクチャ」

 たとえ、資産管理台帳で正確に管理できたとしても、パッチ適用や変更が増えてくると、アプリケーションを含めたシステム全体の正常稼働の可否判断が徐々にあいまいになってきます。アプリケーションの増加やパッチの適用が増えるほど、IT基盤全体の整合性をチェックする管理業務は急激に煩雑になる傾向があるため、変更が発生する本番環境の正常稼働の判断可否は、IT部門にとって非常に頭の痛い問題です。

 「システム全体の管理をしなければならない、しかし、やりたくない」――そんな思いが渦巻く中、1つのアイデアが提唱されます。それがイミュータブル・インフラストラクチャ(Immutable Infrastructure)です。

 イミュータブルとは「不変」を意味します。つまり、イミュータブル・インフラストラクチャとは「本番環境に手を加えない」という意味です。コロンブスの卵の発想ですが、アプリケーションの設定変更、パッチの適用状況の把握など、本番環境の状態を厳密に管理することが非常に煩雑になるならば、「本番環境であっても、バージョンアップやパッチ適用などの煩雑な管理を一切放棄するシステムにしよう」というのがイミュータブル・インフラストラクチャの根底にある基本的な考え方です。


イミュータブル・インフラストラクチャ

レッド・ブラック・デプロイメント

 イミュータブル・インフラストラクチャが生まれた背景には、「煩雑なシステム更新作業から解放されたい」といった現場の要求があります。イミュータブル・インフラストラクチャにおいては、本番環境のハードウェア、OS、ミドルウェア、アプリケーションに一切手を加えず、ずっと「不変の状態」を保つことを徹底します。ハードウェアのBIOS更新、ミドルウェアの改変、アプリケーションのバージョンアップ等の更新作業は、一切行われません。

 本番環境において、なんらかのハードウェアやミドルウェアの不具合を発見した場合や、セキュリティパッチを適用しなければならなくなった場合、さらには、新しいアプリケーションの機能追加を行うといった場合、システムの更新が必要になります。しかし、イミュータブル・インフラストラクチャでは、不具合があるかといって、本番環境のハードウェア、OS、ミドルウェア、アプリケーションを直接更新しません。もし本番環境に手を入れてしまうと、結果的に更新履歴を追跡する必要が生じて、資産管理台帳の悪夢が再来してしまうのです。

 では、イミュータブル・インフラストラクチャにおいて、本番環境を更新するには、どうすればよいのでしょうか。

 イミュータブル・インフラストラクチャは、本番環境と開発環境の2系統で構成されるのが一般的です。その2系統は、まったく同一の能力を有するハードウェア構成をとります。そして、その本番環境と開発環境を負荷分散装置やルータで切り替えます。本番環境は不変ですが、まったく同じハードウェア構成の開発環境に対しては、次々と新しいOS、ミドルウェア、アプリケーションの更新が適用されます。そして、開発環境において、ハードウェアからアプリケーションにいたるまで全ての整合性を満たすことができ、十分な稼働テストを経て本番転用が可能と判断できたら、負荷分散装置・ルータの通信の向きを開発環境に切り替えることで、開発環境が本番環境に入れ替わるのです。

 そして、元の本番環境が今度は開発環境となり、IT部門のメンテナンス、開発部門によるアプリケーション開発に利用されます。もし、新しく切り替えた本番環境に問題があっても、負荷分散装置の通信の向きを元に戻せば、旧本番環境をすぐに使うことができます。開発環境と本番環境を入れ替える一連の作業を繰り返すことで、本番環境におけるシステムの整合性の追跡、パッチ適用業務など、骨の折れる作業を削減することが可能になります。

 このように、本番環境と開発環境を切り替えて、本番環境をユーザーに提供するシステムの配備方法は、開発環境をレッド、稼働中の本番環境をブラックとして表現する「レッド・ブラック・デプロイメント」と呼ばれ、Netflixなどの大規模なウェブシステム基盤で採用されています。

 本番環境と開発環境の切り替えは、負荷分散装置で業務のトラフィックの配分をうまく制御し、本番環境の一部のサーバ環境から徐々にアップデートや変更を行う方法(ブルー・グリーン・デプロイメントと呼ばれます)が一般的ですが、それに対して、稼働中の本番環境に一切手を加えず、本番環境と開発環境を一気に切り替えるのが、レッド・ブラック・デプロイメントです。


レッド・ブラック・デプロイメント

 レッド・ブラック・デプロイメントでは、必要に応じてサーバ、ストレージ、OS、ミドルウェア、アプリケーションを迅速に配備できる仕組みが必要です。また、それらの環境が不要になった場合も、すぐに廃棄し、別の用途向けにすぐに再構築できなければなりません。クラウドコンピューティングでは、仮想化技術がその役目を担いますが、レッド・ブラック・デプロイメントでは、仮想化基盤やクラウド基盤に限らず、ハードウェアを含めた自動構築を実現できなければなりません。

 また、レッド・ブラック・デプロイメントの本番環境において、1つの目的を持った全てのサーバは、まったく同じ状態で、全く同じ挙動を示すことが保証されなければなりません。

 さらに、環境の配備だけでなく、外部からの接続要求の増大に応じて、自動的にスケールしなければなりません。ここでいうスケールとは、サーバの台数を増やすことにより、負荷分散能力または、並行処理の性能を向上させるスケールアウトと、サーバ単体の性能を増やすスケールアップの両方を指します。アプリケーションの特性に応じて、負荷に応じた「自動スケール」が適切に行われなければなりません。本番環境では負荷に応じてアプリケーションの稼働するサーバ台数やプロセスを自動的に増やす必要があり、それは開発環境でも同様です。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    「デジタル・フォレンジック」から始まるセキュリティ災禍論--活用したいIT業界の防災マニュアル

  2. 運用管理

    「無線LANがつながらない」という問い合わせにAIで対応、トラブル解決の切り札とは

  3. 運用管理

    Oracle DatabaseのAzure移行時におけるポイント、移行前に確認しておきたい障害対策

  4. 運用管理

    Google Chrome ブラウザ がセキュリティを強化、ゼロトラスト移行で高まるブラウザの重要性

  5. ビジネスアプリケーション

    技術進化でさらに発展するデータサイエンス/アナリティクス、最新の6大トレンドを解説

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]