「ブルーグリーンデプロイメントの仕組み」を理解する:OpenStack上に構築する、ブルーグリーンデプロイメント実践入門(2)(1/3 ページ)
本連載では、「OpenStackを基盤としたブルーグリーンデプロイメント」を実現する“現場目線”のノウハウを解説していきます。今回は、「ブルーグリーンデプロイメントの利点とその仕組み」を説明します。
前回はシステムのリリースにおける6つの課題を「ブルーグリーンデプロイメント」と呼ばれる手法によって解決できることを説明しました。今回は、この6つの課題を具体的にどのように解決できるのかを深掘りしていきます。参考例として、筆者の所属するユニアデックスで手法を開発し、提案しているOpenStackにおけるブルーグリーンデプロイメント展開ノウハウから、その実現方法を紹介します。
システムのリリースにおける「6つの課題」とその背景
前回説明した、システムリリースにおける「6つの課題」と、その背景を整理しましょう。
- システムの停止時間が発生する
- システムを停止できる時間は限られる。時間に追われた作業となり、ミスの発生が懸念される
- 時間の制約から、十分なテストを実施できない
- 本番環境とテスト環境の差異が生じやすく、この違いが不具合を招く可能性がある
- (4)のために綿密な作業計画や調査などの準備が必要で、一度のリリースに大きな工数が掛かる
- (5)のために大掛かりなリリースとなりがちで、リリースの複雑さを原因とする不具合が発生する可能性が高まる
1つ目の課題「システムの停止時間が発生する」は、システムを停止しなければ更新できないという制約が原因です。システム観点では「仕様だから仕方ない」と思いがちですが、ビジネス観点では「そんなの関係ない」となります。機会や売上の損失につながる停止時間などはないに越したことはありません。ここがシステム側とビジネス側に存在する大きなギャップです。これは続く2つの課題を派生させます。
続く課題「システムの停止時間は限られ、時間に追われてミスが懸念される」と「時間の制約から十分なテストができない」は、一言で言えば、与えられた時間に対して、すべきことが多すぎることが要因です。
一般的に、リリース作業までには以下の項目が発生します。
- リリース前に戻すためのバックアップ
- OSやミドルウェアの配備や設定
- データベースのスキーマ追加やデータの洗い替え
- アプリケーションの配備と設定
- 妥当性を確認するためのテスト
さらに、
- 切り戻すための時間を別に確保する
という工程も必要となります。やはり時間のやりくりは苦しいことでしょう。だからといって、苦しまぎれに──例えば、テストを省いて時間の帳尻を合わせたり、作業を無理やり詰め込んだりしてしまうと、もっと重大なデグレード(新しいバージョンのソフトウェアのパフォーマンスが、以前より悪くなってしまうこと)やヒューマンエラーによる失敗やミスを招いてしまいます。
さらには、足りない時間をやりくりするために「バックアップや切り戻しを考慮しないで突き進む」という暴挙に出てしまうことも、トラブルが発生した現場では、皆さんの想像以上によく聞かれます。これでは、何かあった場合にリリース時間内の切り戻しができず、結果として長時間のシステム/サービス停止に陥るという最悪の事態になるのは言うまでもありません。
4つ目の「本番環境とテスト環境の差異が不具合を招く」という問題は、本番環境として稼働してから初めて発覚するので、非常に厄介です。ライブラリのバージョン違いがバグの引き金となるケースや、本番環境だけに存在する緊急パッチを上書きした結果、デグレードを起こすケースが挙げられます。これらはいくらテスト環境でテストをしても防ぎようがありません。
こうした懸念を払拭するために、皆さんは事前に環境の調査を行うはずです。しかしこれは、5つ目の課題である「綿密な作業計画や調査などの準備が必要となり、リリースまでに大きな工数が掛かる」ことの要因になります。本番環境への移行に際し、悩ましい問題は数多くあるはずですが、この手順の策定には、やはり多くの工数が必要です。行程が多くなればなるほど、手順を作成する難易度も高くなるでしょう。当然、時間が限られる中で多くの作業を確実に行わなければならないことも、綿密な作業計画が必要とされる、つまりは、多くの工数が必要となる理由です。
最後の課題である「大掛かりなリリースで、かつリリースが複雑になるために不具合が起きやすい」では、例えば、ビジネス観点でシステム/サービス停止自体を設けにくいことが背景にあれば、各部署と連携しながら、綿密な作業計画を立てるために、長い準備期間を要することが想定されます。作業も準備も大変なので、リリースの頻度が減り、一度のリリースにまとめてしまう。結果として大掛かりなリリースになります。課題(5)と同様に、一度にリリースする内容が多ければ、それだけ機能間の依存関係なども複雑化します。リリースの複雑度が増すことで、難易度が高く、リスクの高いリリースとなってしまうわけです。
これら6つの課題を、ブルーグリーンデプロイメントの仕組みによって回避/改善することが可能となります。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- OpenStackが今求められる理由とは何か? エンジニアにとってなぜ重要なのか?
スピーディなビジネス展開が収益向上の鍵となっている今、システム整備にも一層のスピードと柔軟性が求められている。こうした中、なぜOpenStackが企業の注目を集めているのか? 今あらためてOpenStackのエキスパートに聞く。 - いまさら聞けないOpenStack〜よく知られた「常識」と知っておくべき「常識」
日本OpenStackユーザ会の全面協力を得て、OpenStackを徹底的に深掘りする本特集。第2回はレッドハット クラウドエバンジェリストの中井悦司氏が「OpenStackでできること」「OpenStackを使う上で必要なこと」を分かりやすく解説する。 - いまさら聞けない「DevOps」
最近さまざまなイベントやブログエントリで見かける「DevOps」。この言葉をひもとき、なぜ「Dev」と「Ops」が衝突するのか、その解決に必要な要素とは何かを分かりやすく解説します。 - 継続的デリバリ/デプロイを実現する手法・ツールまとめ
バージョン管理や継続的インテグレーションとも密接に関わる継続的デリバリ/デプロイメントの概要や主なツール、経緯、実践事例を紹介。実践手法として「ブルーグリーン・デプロイメント」「Immutable Infrastructure」が注目だ。 - 現代のソフトウェア/サービス開発で構成管理が重要になった5つの理由
「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする