ソフトウェアデプロイメント
 | この記事の文章は日本語として不自然な表現、または文意がつかみづらい状態になっています。 |
ソフトウェアデプロイメント（英: Software deployment）または単にデプロイとは、ソフトウェアシステムを利用可能にする活動全般を指す用語である。デプロイメント（Deployment）とは「展開、配備、配置」などの意。
一般にデプロイメントは相互に関連したいくつかの活動から構成される。それらの活動は、ソフトウェア開発者の側で行われるものもあれば、顧客側で行われるものも、あるいは両者が共同で行うものもある。ソフトウェアは非常に様々なものがあり、ソフトウェアデプロイメントのプロセスやプロシージャを正確に定義することは難しい。従って、ソフトウェアデプロイメントは、個々の事情や要求に応じてカスタマイズされる「汎用プロセス」と理解されるべきである。ソフトウェアデプロイメントに含まれる個々の活動については以下で解説する。
また、アプリケーションサーバにおいて、各種アプリケーションモジュールを実際に使用される環境に配備することをアプリケーションデプロイメントと呼ぶ。
自動化されたデプロイメント手法を用いた（従来に比べて）素早く高頻度すなわち継続的なソフトウェアデプロイメントを継続的デプロイという。
デプロイメントの中で行われる作業
[編集]- リリース
- リリース活動は、ソフトウェア開発工程の完了後に行われる。開発されたものをまとめ、顧客のサイトに送ることができる形態にする。市販される製品の場合、注文を受けて出荷されるもの（出荷数が少ない高価な製品）と見込み生産されるもの（出荷数が多い安価な製品）があり、リリースに際しての手続きも異なる。
- インストール
- インストールは顧客のサイトで行われる最初の作業である。通常、インストーラと呼ばれる専用のツールを用いて行われる。作業は、ファイル群のターゲットシステム上への転送と設定に分けられる。
- アクティベート
- 通常、そのソフトウェアの実行ファイルを起動することを意味する。プロプライエタリなソフトウェアでは、ライセンスの確認をすることで実行ファイルを起動可能にする作業をアクティベートまたはアクティベーションと呼ぶ。例えば、メーカーのサイトにシリアル番号などを送信することで何らかのキーコードを入手し、それを使ってアクティベートするなどの方式がある。
- ディアクティベート
- アクティベートの逆、すなわち実行していたシステムをシャットダウンすることを意味する。例えば、同じソフトウェアの新しいバージョンに更新する場合、一旦実行をやめないと更新できないことが多い。
- アップデート（更新）
- 既存のソフトウェアの新しいバージョンを導入したり、パッチを適用したりする活動。
- アンインストール
- インストールの逆の活動。必要のなくなったソフトウェアをシステム上から削除する。
- サポート停止
- 古くなったソフトウェア製品は、ある時点で開発側のサポートが停止される。これはその製品のライフサイクルの終了を意味する。
アップデート
[編集]既にデプロイされたソフトウェアを、類似する構成のソフトウェアへ更新する活動をアップデートという。例えばソフトウェアを構成するデータベースのバージョンアップはアップデートにあたる。
アップデートには様々な手法がある。なぜならアップデートはデプロイ後のソフトウェアが提供するサービスへ様々な影響を与えるからである。影響の例を以下に挙げる。
- 一時的なサービス停止: ソフトウェア更新に伴うデプロイ済みソフトウェアの一時停止
- サービスレベル低下: バグが混入したアップデート版ソフトウェアのデプロイ
例えばアップデートが重要な既存サービスに意図せず影響してしまった（デグレードした）場合、アップデートを取り消すロールバックを行う必要がある。ロールバックを考慮しないアップデート手法を用いた場合、データ形式の不整合や新旧バージョンの並列などによってロールバックが困難になる可能性がある。
これらの問題を解決するための様々なソフトウェアデプロイメント手法が存在する。
- ローリングアップデート/Rolling updates: 新バージョンデプロイ → 新旧バージョン並行動作 → 旧バージョン停止による無停止アップデート[1]
- カナリアリリース/Canary release: 本番環境での可用性確認を主目的として一部のユーザー（カナリア）のみへアップデート版を提供し順次アップデートをおこなう手法[2]。ローリングアップデートと同様の構成になる
- Blue-Greenデプロイメント: 稼働中のソフトウェア（Blue）と同等のプロダクション構成を持つアップデート版（Green）を準備してテストを行い、アップデート時にDNSルーティング等を用いてBlueからGreenへ全てのリクエストを切り替える手法[3]
既存ソフトウェアに手を加えて（mutableな）アップデートをおこなった場合、問題発生時に元の構成を再現することが難しくなる。上記の手法はコードによるインフラ構成（Infrastructure as Code）やコピーインスタンスへのmutableアップデートと保存による、Immutable Infrastructureが基盤となっている。バージョン管理されインスタンス化可能なソフトウェアの存在が、新旧バージョンの同時稼働やBlue/Green 2系統のリリースを可能にしている。
コンテナ化されたアプリケーションでサービスを構成する場合、Kubernetes等のコンテナオーケストレーションシステムを用いたアップデートが可能である。例えばk8sはローリングアップデートに対応している[4]。
脚注
[編集]- ^ Rolling updates allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. Kubernetes - Tutorial - Performing a Rolling Update
- ^ Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody. martinFowler.com - CanaryRelease
- ^ The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible. At any time one of them, let's say blue for the example, is live. As you prepare a new release of your software you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment - the blue one is now idle. martinFowler.com - BlueGreenDeployment
- ^ Perform a rolling update using kubectl. Kubernetes - Tutorial - Performing a Rolling Update
参考文献
[編集]- Carzaniga A., Fuggetta A., Hall R. S., Van Der Hoek A., Heimbigner D., Wolf A. L. — A Characterization Framework for Software Deployment Technologies — Technical Report CU-CS-857-98, Dept. of Computer Science, University of Colorado, April 1998. http://serl.cs.colorado.edu/~carzanig/papers/CU-CS-857-98.pdf