デプロイとは？
ITに関わると、デプロイという言葉を頻繁に目にします。IT業界におけるデプロイは、システムの稼働に必要な実行ファイルやアーティファクト（実行に必要な情報など）を新環境に移すという意味で用いられています。
通常、デプロイでは稼働中のアプリなどを一旦停止させ、サーバの再起動を伴うことからダウンタイム（停止時間）が発生しますが、ホットデプロイという方法ではダウンタイムを発生させません。ここではホットデプロイのいくつかの手法を中心に解説していきます。
デプロイの名の由来
デプロイは英語の（deploy）のことで、「展開する、配置する」といった意味です。そこから、プログラムやプロジェクトなどを配置するという意味で、IT用語として使われるようになりました。
デプロイの用法
デプロイという響きはいかにもエンジニアらしいですが、デプロイの意味をしっかり押さえ、正しく使うことが求められます。
「テスト稼働が無事に終わったので、ローカル環境から本番環境にデプロイしよう」 「Javaで開発したアプリをユーザが利用できるようにデプロイしてください」
といった使い方をします。
デプロイの重要なポイント
システムやアプリケーションがある限り、デプロイは必ず行う必要があります。またデプロイには次のような重要なポイントがあります。
1.サービス停止となるダウンタイムは短ければ短いほど良い 2.デプロイに失敗した時に簡単に元に戻せること 3.ユーザから見た時に安定しており、サービスレベルの低下がないこと
「デプロイにリスクや失敗はつきもの」という認識ではなく、「デプロイによってユーザに不都合を与えないことが、デプロイを行う上で最も重要な方針」と考えましょう。
デプロイの類義語
ここまでデプロイについて解説しました。デプロイを理解すると、似たような用語が気になります。間違った使い方をすると恥ずかしい思いをすることがあるので、デプロイの類義語について確認しておきましょう。
リリース
リリースはサービスインとも言います。Webページの公開や、Webサービス開始の際に使われます。「〇〇サービスは4月1日にリリースされます」というように使います。一般ユーザに対しては、リリースやサービスインという言い方の方が分かりやすいでしょう。
また厳密に言えば、デプロイはリリース作業の1つのステップで、一般的なリリースは次のような手順で行われます。
1.稼働中のアプリケーションを停止する 2.サーバを停止する 3.デプロイを行う 4.デプロイ前とデプロイ後の状態について、問題がないか確認する 5.サーバを再起動する 6.動作確認をする
これはダウンタイムを伴う一般的なリリースの手順ですが、デプロイがリリース作業の1つのステップであることが分かります。
ローンチ
リリースやサービスインとも似ていますが、ローンチは製品やサービスなど提供開始の際に用いられることが多いです。また、機能やユーザを限定して、先行提供する際にもローンチは使われます。ローンチの後、一般公開する場合には「ロールアウト」と言います。
カットオーバー
IT業界ではかなり古くから用いられている和製英語です。今はほとんど死語になりつつありますが、ホームページの公開、Webサービスの開始の際に用います。主にクライアントと開発サイドとの間で使うのが一般的で、顧客や利用者に対して用いる事はありません。
本番公開
主にテスト環境にあったWebページなどを、本番環境で公開する際に用いられます。これもどちらかと言えば、システム関係者間の用語です。「修正を確認しました。本番公開してください。」といった使い方をします。
ホットデプロイのやり方
一口でデプロイと言っても、環境や要件によって方法はいくつかあります。ダウンタイムが生じるデプロイと、ダウンタイムを発生させないデプロイとがあり、ここでは、ダウンタイムを生じさせない「ホットデプロイ」の手法について紹介します。
プロジェクトにおいて、どの手法を採用すれば要件を満たせるかを考えながら選択することが大切です。
ブルー/グリーンデプロイ（Blue/Green Deployment）
ブルー（本番環境）とグリーン（新環境）の2つを用意し、ロードバランサーなどで切り替えができるようにしておきます。ブルーで本番を動かしたまま、グリーンに新環境をデプロイし、新環境の正常稼働を確認したら、ロードバランサーの向きを切替、グリーンを本番環境として利用します。
万一グリーンで問題が生じた際には、ブルーに切り戻す（ロールバック）ことで障害の影響を最小限にとどめられます。この方法ではダウンタイムをほとんど発生させませんが、新旧両環境を常に維持する必要があるため、余分な運用コストが発生します。
イミュータブルデプロイ（Immutable Deployment）
ブルー/グリーンデプロイとほぼ同じやり方ですが、大きく異なるのは、ブルー/グリーンデプロイでは旧環境を残さない点です。そのため、旧環境を残しておくブルー/グリーンデプロイ手法と比べて余分な運用コストが発生しないというメリットがあります。
シンボリックリンクデプロイ（Symbolic Deployment）
Linuxのコマンドを利用する方法です。稼働中のサーバ上の別環境にデプロイを実施して、サービスが利用しているシンボリックリンク（起動リンク）を新環境に切り替える手法です。サーバ増設の必要もなく、低コストで運用できますが、場合によっては再起動が求められることもあり、ダウンタイムが必ずしもゼロになるわけではありません。
ローリングデプロイ（Rolling Deployment）
ロードバランサーによって負荷分散しているサーバに対し、ロードバランサーから順次切り離してデプロイを行う方法です。ダウンタイムは基本的に発生しませんが、一時的に新旧サーバが混在するため、処理結果に違いが生じないよう気を付ける必要があります。
その他のデプロイの手法
紹介した以上4つのデプロイがメジャーですが、他にも次のようなデプロイがありますので、覚えておくとデプロイに詳しい人だと思われるかもしれません。
■カナリアデプロイ（Canary Deployment）
新しいプロダクトの新しい機能を稼働中のサーバの一部にデプロイ、リリースする方法です。特定のユーザにだけ新機能を利用してもらい、新サービスの検証を行います。カナリアリリースは炭鉱のガス漏れ事故を未然に防ぐために、カナリアをセンサー代わりに利用したことが由来と言われています。
■インプレースデプロイ（In-Place Deployment）
稼働中のサーバに対して、新しいアーティファクト（ソフトウェア開発で生まれた新たな制作物）をリリースします。このリリース方法では再起動が避けられず、ダウンタイムが発生します。
【参考】：AWS でデプロイの自動化を実現するベストプラクティスを図解
デプロイはビルドとリリースとどう違う？
ここでは、デプロイとビルドとリリースの違いについて解説します。システム開発において、これらがどういった役割を持っているのか順番にまとめました。
ビルドとの違い
ビルドとは、プログラミングによって記述されたソースコードを実行ファイルに変換することです。
プログラマーが記述するプログラミング言語はコンピュータには理解できないため、コンパイルと呼ばれるコンピュータ用の言葉（機械語）に訳します。それに加えて、コンパイルした別のファイル同士を連携させて実行できるようにするのがビルドであり、一般的には自動化ツールを利用します。
ビルドはデプロイを行う前工程に含まれます。開発における順番としては、ビルドによって実行ファイルを作成し、その後ビルドされた実行ファイルをサーバに転送して実行できるようにするのがデプロイの役割です。
リリースとの違い
リリースは前述の通り、Webページの公開やWebサービス開始の際に使用します。全ての工程を経て製品やサービスを公開することなので、順番としてはデプロイの後がリリースとなります。
デプロイを行うタイミングはリリースの直前であり、システム開発における大詰めにあたります。全体的には、ビルド→デプロイ→リリースの順番です。多くの場合、デプロイはユーザ稼働数の少ない深夜帯に行われます。
デプロイの簡略化ツール「DeployBot」を使うメリット
デプロイは最新のシステムやサービスのリリースに欠かせない作業ですが、エンジニアにとっては大きな負荷を伴う作業です。このデプロイを簡略化、自動化できるツールとしてDeployBotがあります。
DeployBotはデプロイ作業に手間をかけず、簡単に行うことができるGUIツールのことです。従来のデプロイ作業は、エンジニアがコマンドなどを使って手動で作業を行うため、特殊なスキルが必要となり、Linuxなどの運用経験がないシステムエンジニアにはハードルの高い作業でした。
しかし、DeployBotを利用することでGUI画面から簡単にデプロイ作業が可能です。
ここではデプロイツールとしてDeployBotを紹介しましたが、「Git」でデプロイ環境を構築する方法や、お馴染みのGAS（Google Apps Script）を用いたWebアプリのデプロイ方法などもありますので、デプロイに興味を持った方はさまざまなツールを研究してみましょう。
【参考】：DeployBot | Code Deployment Tools | Deploy Code Anywhere
サーバの再起動が不要
ホットデプロイ以外の従来型デプロイ作業では、デプロイ終了後にサーバの再起動が不可欠でしたが、サーバ再起動が不要となり、システムダウンタイムの大幅な短縮、回避が可能です。
直感的操作でデプロイが可能
DeployBotでは難しいコマンドを使わず、GUIツールを利用して、ボタン操作でデプロイが行えます。
他に特別なツールなどの必要がない
これまでのデプロイでは、サーバを操作するためのクライアントソフトなどを使い分ける必要があり、作業が大変煩雑でしたが、DeployBotでは1つのツールだけで作業が完結し、余計な手間を省くことができます。
ロールバックが容易に行える
デプロイでは作業に失敗した時に、元に戻す「ロールバック」という作業が必要になります。これは完全に元の状態に戻す必要があるため、大変神経を使いますが、DeployBotでは「Rollback to 」ボタンを押すだけでいとも簡単に前のバージョンに戻すことが可能です。
DevOpsエンジニアとは
DevOps（デブオプス）という言葉を聞いたことはありませんか？DevOpsは、開発を意味する「Development」と運用を意味する「Operations」を掛け合わせた新たな概念です。このDevOpsを推進する役割を担うのがDevOpsエンジニアで、今注目を浴びているエンジニア職です。
DevOpsエンジニアの仕事では、開発サイドと運用サイドの連携を強め、システム開発効率やサービス品質の向上、安定運用実現など、インフラの構築や運用改善など多岐に及びます。そのためDevOpsエンジニアには幅広いIT知識やスキルが求められます。
DevOpsエンジニアの将来性
従来型のシステム開発と運用の縦割り組織では、さまざまな弊害が存在していました。しかし、ITの進展に伴い、システムに対する要求は年々厳しくなっており、「サービスを止めずにシステムを改善する」ことが当然のことになっています。
またクラウド化の進展によって、開発と運用の一体化は必然のこととして受け止められています。こうした背景から、開発と運用の一体化を図るDebOpsエンジニアに対する需要が高まっており、将来性の高い職種の1つです。
DevOpsエンジニアの年収
ここでは、DevOpsエンジニアの求人状況や年収を平均年収と比較していきましょう。
マイナビITエージェントの求人検索でキーワード「DevOps」で検索したところ、年収400万円から1,500万円までの求人を確認できました。ちなみに、一般的なシステムエンジニアの年収は「マイナビITエージェント 職種図鑑」では431万円と出ています。（※2024年2月執筆時点）
また、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」からエンジニア/プログラマを参考にすると、平均年収592万円でした。
国税庁2020年発表の「民間給与実態統計調査」における民間企業平均年収は433万円なので、DevOpsエンジニアはやや高年収の部類であることが推察できます。
DevOpsエンジニアの枠は、今後需要が拡大していくと考えられます。特にクラウド事業を展開するGoogleやAmazonAWSではDevOpsエンジニアの強化に積極的であり、クラウドのフルスタック人材と言われるDevOpsエンジニアは更に重用されると考えられます。
【参考】：マイナビAGENT SE・システムエンジニア DevOps 【参考】：マイナビITエージェント 職種図鑑 ※【平均年収 調査対象者】2020年1月～2020年12月末までの間にマイナビエージェントサービスにご登録頂いた方 【参考】：IT関連産業における給与水準の実態① ~ 職種別（P7） 【参考】：民間給与実態統計調査-国税庁
クラウド時代をリードするエンジニアに
この記事ではシステムやサービスのリリースに欠かせない「デプロイ」をテーマにして、DevOpsエンジニアなど新たなITエンジニアについても紹介をしました。今やシステム環境はオンプレミスからクラウドに大きく舵をきっており、クラウドエンジニアが脚光を浴びています。
そしてクラウド環境で大きな力を発揮するのがDevOpsエンジニアです。エンジニアを目指す皆さんは、システム開発や運用という壁を越えて、顧客目線で最適なシステムの提供ができるDevOpsエンジニアを目指しましょう。
編集部オススメコンテンツ
アンドエンジニアへの取材依頼、情報提供などはこちらから
